Una lista de comprobación antes del lanzamiento de sitios web profesionales de WordPress

Llegar a la etapa de lanzamiento de un proyecto puede sentirse como un gran alivio. Finalmente has concluido tu trabajo de desarrollo, creando un sitio conforme al "brief" o especificaciones de tu cliente o tus propios requisitos, y ahora puedes presionar ese metafórico botón y lanzar el sitio para que todo el mundo lo vea.

Pero espera.

Antes del lanzamiento, debes ejecutar algunas comprobaciones para asegurarte de que es un producto robusto y sólido de cara al futuro. Al ejecutar estas comprobaciones antes de lanzar cada nuevo sitio, podrás evitar que más adelante surjan problemas. En concreto, puedes evitar los dolores de cabeza, la vergüenza y el daño a tu reputación debidos a que los clientes o usuarios detectan problemas en el sitio una vez este está en funcionamiento.

En este artículo, compartiré la lista de comprobación que yo mismo uso antes de migrar un sitio y hacerlo público. No estoy afirmando que este sea el santo grial de las listas, habrá algunas cosas que figuran en ella que tú no hagas, cosas que hagas de otra manera, o cosas que hagas que no aparecen en ella.

Vale la pena señalar que las comprobaciones previas al lanzamiento no solo son relevantes inmediatamente antes de lanzar un sitio, dependiendo de la complejidad de tu proyecto, tendrás que llevar a cabo muchas de ellas a medida que avanzas en él. Esto te ahorrará tiempo y reelaboraciones una vez el sitio esté ya listo para entrar en funcionamiento, y te ayudará a obtener la aprobación final del cliente y a ganar credibilidad en las distintas etapas a lo largo del desarrollo en las que tu cliente revise el trabajo en el propio sitio.

Pero, habiendo dicho esto, creo que vale la pena darle a esa lista un último repaso antes del lanzamiento, sólo para estar seguro.

Mi lista se divide en cuatro categorías:

1. Comprobaciones del proyecto o de las especificaciones del brief
2. Robustez
3. Solidez de cara al futuro
4. Acciones finales

A continuación describiré en qué consiste cada una de ellas y proporcionaré un listado de puntos para cada categoría.

1. Comprobaciones del proyecto o de las especificaciones del brief

Asegurarte de que el sitio cumple con el "brief" o informe previo acordado con el cliente es algo que deberías estar haciendo durante todo el tiempo, no obstante, vale la pena ejecutar una comprobación final antes del lanzamiento.

Esta lista de verificación será diferente para cada proyecto, por ello no puedo proporcionarte realmente una lista estándar, aunque sí existen algunos puntos clave que puedes emplear. Deberías realizar una revisión siguiendo esta lista antes de migrar el sitio al servidor público definitivo:

1. Revisa el brief. Si el informe que acordaste con el cliente tiene una lista de comprobación de características o elementos del sitio, comprueba que queden todos cubiertos, y si no es así, asegurate de haber llegado a este acuerdo con el cliente.
2. Comprueba objetivos o tareas. Si utilizas un sistema de seguimiento de tareas u objetivos (por ejemplo, aspectos relacionados con GitHub), comprueba que se hayan cerrado todos estos aspectos o que se hayan completado las tareas y que no existan errores o queden preguntas pendientes.
3. Comprueba los cambios solicitados. Comprueba que los cambios solicitados durante el desarrollo (que posiblemente no figuren en el brief original) hayan sido realizados, a menos que se hayan pospuesto para después del lanzamiento.
4. Prueba los procesos in situ. Si el sitio incluye procesos o interacciones que los usuarios van a tener que realizar, ejecuta esos procesos en distintos navegadores y dispositivos para asegurarte de que funcionan de acuerdo con el brief.
5. Organiza a los usuarios. Si has creado inicios de sesión ficticios o, por ejemplo, has vinculado el sitio a una configuración de prueba de PayPal, cámbialos a las versiones en vivo (es posible que tengas que comprobarlo de nuevo tras la migración).
6. Comprueba los derechos y/o atribuciones de autor, como los créditos fotográficos.
7. Limpia el texto. Si has usado texto de relleno (como lorem ipsum), asegúrate de que todo haya sido reemplazado por contenido adecuado. Hasta una nota que notifique a los visitantes de que el contenido de una página está en desarrollo es mucho más útil y da una impresión más profesional que el texto lorem ipsum.
8. Comprueba las personalizaciones del escritorio. Si has personalizado el escritorio de WordPress, comprueba que esto funciona para todos los roles de usuario que vaya a usar tu cliente.
9. Comprueba los servicios de terceros. Si el sitio está integrado con servicios de terceros, comprueba que todo esto funciona y que el software esté actualizado (es posible que tengas que comprobarlo de nuevo tras la migración).

Esta no es una lista exhaustiva, ya que su proyecto puede tener elementos adicionales que debe considerar, pero le dará una base para trabajar.

2. Robustez

La mayoría de los elementos de esta lista de comprobación serán aplicables a todos los sitios, pero puede haber algunas variaciones para diferentes proyectos, por ejemplo, si un cliente requiere que des soporte a dispositivos concretos (aunque yo siempre abogaría por un enfoque de desarrollo que sea independiente del dispositivo).

Trabaja a través de la primera parte de esta lista antes de migrar el sitio al servidor público:

1. Pruebas de navegador. Comprueba tu sitio en todos los navegadores a los que estés dando soporte (algo que deberías haber acordado previamente con tu cliente). Debes hacer esto a medida que avances y lo ideal es usar la mejora progresiva, pero debes hacer comprobaciones finales antes de publicar en vivo el sitio. Prueba el contenido con cada plantilla de tu tema: entradas individuales, páginas, páginas de archivo y tipos de entradas personalizadas.
2. Compatibilidad de dispositivo. Comprueba tu sitio en todos los dispositivos a los que des soporte. Una vez más, deberías haber hecho esto mientras trabajabas en el sitio, y utilizado el diseño responsivo para acomodar diferentes tamaños de pantalla. Si tu sitio utiliza plugins o mejoras con diferentes niveles de soporte en todos los dispositivos, comprueba lo que van a experimentar los usuarios cuando lo visualicen en estos dispositivos e implementa una alternativa, o un enlace a un lugar desde el que puedan acceder al contenido que no esté disponible para ellos.
3. Valida tu código con el validador de W3C: nuevamente, deberías estar haciendo esto a medida que avances. Si el código no es validado, en ocasiones podrías decidir no cambiarlo, por ejemplo, si usas características HTML5 que todavía no han sido validadas. Si este es el caso, asegúrate de que no causará problemas en los navegadores que no admitan las características más recientes (utilizando el enfoque de mejora progresiva ya mencionado).
4. Comprueba que tu sitio es accesible. Para obtener consejos sobre accesibilidad en WordPress, consulta la excelente guía de accesibilidad web de Graham Armfield y las instrucciones del códice de WordPress.

Después de migrar el sitio al servidor en vivo, habrá pruebas adicionales de robustez que posiblemente debas realizar:

1. Pon a prueba tu navegación y tus enlaces, especialmente cualquier redirección.
2. Comprueba que la base de datos se lea correctamente y desde el lugar correcto: si el sitio en vivo está leyendo contenido de la base de datos de desarrollo, no será inmediatamente evidente si has copiado el contenido de la antigua base de datos, ya que ambas serán idénticas. En particular, comprueba los enlaces en los widgets de texto e imágenes.
3. Comprueba dos veces la integración con software y servicios de terceros. Todos ellos deben estar comunicándose con tu sitio público, no con tu sitio de desarrollo.
4. Comprueba que los ajustes del sitio hagan referencia a la URL pública (por ejemplo, la URL del sitio y la URL de WordPress).
5. Asegúrate de que los enlaces permanentes funcionan correctamente para todos los tipos de contenido, es posible que debas configurarlos o visitar la pantalla de ajustes de los Permalinks para purgarlos.
6. Usuarios. Comprueba tu sitio (front-end y escritorio) usando todos los roles de usuario de WordPress que tu cliente va ha utilizar. Configura cualquier usuario que necesites.

3. Prueba futura del sitio

La tercera lista consiste en asegurarte de que el sitio esté listo para el desarrollo futuro y para adiciones. Esto será especialmente importante si vas a entregar el sitio a tu cliente para que él mismo lo administre y actualice.

1. Asegúrate de haber configurado el SEO básico. Los títulos y descripciones meta deben haberse trabajado en tu tema o añadirse usando un plugin SEO. Dependiendo de las necesidades del proyecto, es posible que tengas que dedicar tiempo a configurar el plugin para satisfacer las necesidades de tu cliente. Otra comprobación importante pero que se suele pasar fácilmente por alto: si bloqueaste el acceso a los motores de búsqueda durante el desarrollo, elimina el bloqueo tras el lanzamiento, ya sea usando los ajustes de WordPress o mediante un archivo robots.txt.
2. Realiza una copia de seguridad de los archivos y la base de datos en el momento del lanzamiento.
3. Configura un sistema de copia de seguridad automatizado para los archivos del tema, los plugins y la base de datos. La forma en la que se administre esto y quién vaya a responsabilizarse de ello dependerá de lo que hayas acordado con tu cliente y de la configuración de alojamiento que este tenga. Existe una amplia gama de plugins de WordPress para esta tarea, incluyendo plugins premium como Backup Buddy o plugins gratuitos como WordPress Backup to Dropbox.
4. Configura el sitio para Google Analytics, ya sea mediante un plugin o añadiendo el código de seguimiento a tu tema.
5. Pon en marcha un sistema para mantener el sitio actualizado. Esto no solo incluye WordPress en sí, sino también los temas y plugins. Si vas a ser tu quien se va a ocupar de esto, va a ser el cliente o su proveedor de alojamiento, todo dependerá de lo que hayas acordado con tu cliente. Es posible que debas acordar un contrato específico para el mantenimiento del sitio.
6. Acuerda una programación para las revisiones del sitio. Una vez lanzado, un sitio web no debe dejarse abandonado a su suerte. Acuerda con tu cliente la frecuencia con la que revisarás el rendimiento y la eficacia del sitio, y asegúrate de mantenerte en contacto con tu cliente para que recurra a ti cuando necesiten más trabajo de desarrollo.

4. Acciones finales

La cuarta y última parte de mi lista de verificación es muy breve, y completa el proceso de lanzamiento.

1. Vuelve a visitar cualquiera de las comprobaciones anteriores según sea necesario. Si has realizado cambios después de cualquiera de tus comprobaciones (por ejemplo, si has editado el tema después de encontrar código que no fué validado), vuelve a realizar la comprobación que ha provocado el cambio y las que hiciste antes cuyos resultados puedan haberse visto afectados. Por ejemplo, ¿funciona el nuevo código validado en todos los dispositivos o navegadores?
2. Aprobación. Si han tenido lugar cambios significativos después de tus comprobaciones, es posible que debas obtener de nuevo la firma del cliente.
3. Comunicación. Asegúrate de que tu cliente y cualquier otra parte interesada sean conocedores de que el sitio ha vuelto a estar en funcionamiento de forma pública. Si es tu propio sitio o tu cliente te ha pedido que lo publiques, difundelo haciendo uso de las redes sociales así como otros canales y publicando entradas de blog. ¡Añádelo a tu portafolio si te sientes orgulloso de él!
4. Cobra. No olvides enviar a tu cliente una factura para la etapa de lanzamiento del proyecto.

Resumen

Como mencioné anteriormente en este artículo, esta lista no tiene como objetivo ser una lista definitiva para todos los desarrolladores de WordPress, pero espero que le resulte útil a cualquiera que quiera introducir algo de coherencia en su proceso de migración de sitios.

Toma esta lista y edítala de manera que funcione para tu forma de trabajar y tus proyectos, añade, cambia y desguaza las cosas que no sean relevantes para ti. Pero si usas esto para desarrollar tu propia lista de verificación a la que hagas referencia cada vez, puedes estar seguro de que no olvidarás nada importante, y que tú mismo detectarás cualquier problema antes de que el sitio entre en funcionamiento, y que no lo harán tus clientes o posteriores usuarios.