Publicar no consiste en comprobar que la portada abre. Una web real tiene formularios, permisos, analítica, multimedia, integraciones, SEO, caché y errores que solo aparecen cuando abandonamos localhost.
Rendimiento
Comprueba peso de recursos, imágenes, JavaScript, fuentes, peticiones externas y tiempos de respuesta. Repite la prueba en móvil.
Accesibilidad
Teclado, foco visible, contraste, etiquetas de formularios, estructura de encabezados y textos alternativos son parte del producto. Una interfaz bonita no es accesible automáticamente.
Formularios
Prueba entradas válidas, inválidas, vacías y excesivamente largas. Comprueba qué ocurre después del envío y qué datos llegan realmente al servidor.
Seguridad
Revisa cabeceras, CSP, cookies, CORS, autenticación, autorización y secretos. Intenta conscientemente las acciones que deberían fallar.
SEO
Comprueba títulos, descripciones, canonical, sitemap, robots, códigos de respuesta y contenido indexable. Una página perfecta que Google no puede entender tiene un problema de producto.
Producción
Abre el dominio real, usa una ventana privada y prueba la aplicación después del despliegue. Revisa consola y Network. Un error 401, 403, 404 o 500 necesita diagnósticos diferentes.
Integraciones
Analítica, vídeo, pagos, mapas, captcha y servicios de terceros pueden comportarse de forma distinta según el dominio y las políticas de seguridad.
Regresión
Después de arreglar un problema, repite las rutas principales. La corrección más peligrosa es la que arregla una página y rompe otra.
Checklist final
- Móvil y escritorio.
- Rendimiento.
- Accesibilidad.
- Formularios.
- Autenticación y permisos.
- CSP y cabeceras.
- SEO técnico.
- Integraciones externas.
- Errores de consola y Network.
- Regresión después del despliegue.
Conclusión
Una publicación profesional no significa que no existan errores. Significa que conoces los flujos críticos, has probado los caminos buenos y malos y tienes observabilidad suficiente para corregir rápido cuando algo cambie.
La revisión previa al lanzamiento como proceso repetible
Publicar una web no debería ser un momento de intuición. Conviene convertir el lanzamiento en una serie corta de comprobaciones que cualquier persona del equipo pueda repetir.
Contenido y navegación
Comprueba que las páginas importantes tienen contenido real, que los enlaces principales funcionan y que no existe texto provisional, títulos duplicados o rutas que terminan en páginas vacías.
Formularios
Prueba envío correcto, campos obligatorios, errores de validación y respuesta después del envío. Si existe correo o CRM, comprueba también el recorrido completo y no solo el mensaje visual de éxito.
Responsive
Una página que se ve bien en un monitor puede tener problemas reales en un teléfono. Comprueba navegación, imágenes, tablas, modales, formularios y botones con una pantalla pequeña.
Rendimiento
Mide las páginas principales en una carga limpia. Observa imágenes, fuentes, JavaScript, llamadas externas y recursos que bloqueen la representación. No optimices únicamente una métrica: identifica qué parte del recorrido importa para el usuario.
Imágenes
Utiliza dimensiones adecuadas y formatos eficientes. Una portada grande que se muestra dentro de una tarjeta pequeña es trabajo innecesario para la red y el dispositivo.
Scripts de terceros
Analítica, chat, publicidad, mapas y widgets pueden añadir peso. Decide cuáles son esenciales y cuáles pueden cargar después de la interacción o del consentimiento correspondiente.
Seguridad
Revisa autenticación, autorización, cookies, cabeceras, CSP, CORS y almacenamiento. Prueba también caminos que deberían fallar: usuario sin permisos, ID ajeno, sesión inexistente o recurso privado solicitado directamente.
No confíes en la interfaz
Ocultar un botón no protege una operación. El servidor debe rechazarla igualmente cuando se construye una petición manual.
SEO y descubrimiento
Comprueba títulos, descripciones, canonical, sitemap, robots, datos estructurados y enlaces internos. Una página técnicamente correcta también necesita ser descubrible y entendible para buscadores.
Indexación real
No basta con tener un sitemap. Comprueba que las URL importantes pueden ser rastreadas y que no existen directivas contradictorias.
Observabilidad
Antes de publicar, decide qué errores necesitas detectar. Un sistema profesional debería permitir saber si una ruta dejó de responder, si un proveedor externo falló o si un formulario comenzó a producir errores.
Plan de rollback
La pregunta incómoda del lanzamiento es qué ocurre si algo rompe. Debes saber qué versión es la estable, cómo volver a ella y qué cambios de datos no pueden deshacerse automáticamente.
El criterio de salida
Un lanzamiento está listo cuando las funcionalidades críticas han sido comprobadas y existe una forma razonable de detectar y revertir un problema. No necesitas probar absolutamente todo; sí necesitas probar lo que puede causar más daño.
Checklist final
- rutas principales;
- navegación y enlaces;
- formularios;
- móvil y escritorio;
- imágenes y multimedia;
- errores de consola;
- rendimiento;
- autenticación y permisos;
- SEO;
- analítica y monitorización;
- rollback.
Cierre FMCP
La publicación debería ser la confirmación de un proceso, no el comienzo de una prueba. Una checklist pequeña pero consistente reduce sorpresas y hace que cada lanzamiento sea más predecible.
La checklist que separa una web preparada de una web simplemente publicada
Publicar una web no debería ser el último paso del desarrollo, sino el inicio de una etapa de verificación. Antes de abrirla al público hay que comprobar contenido, rendimiento, accesibilidad, SEO, seguridad, observabilidad y capacidad de recuperación. Una web que “carga” puede seguir teniendo errores que aparecerán con el primer usuario real.
Contenido y experiencia
Primero se revisa lo visible: títulos, textos, enlaces, formularios, navegación, estados vacíos y errores. Hay que probar tanto el camino feliz como los casos incómodos. ¿Qué ocurre si el formulario falla? ¿Y si el usuario pulsa dos veces? ¿Y si llega una URL antigua?
Rendimiento real
No basta con optimizar una captura local. Hay que comprobar tamaño de JavaScript, imágenes, fuentes, caché, renderizado y tiempos de interacción. El objetivo no es conseguir una cifra perfecta aislada, sino localizar qué parte del sistema consume más tiempo y qué experimentará el usuario.
Accesibilidad
La accesibilidad debe revisarse con teclado, foco visible, contraste, textos alternativos, etiquetas de formulario y jerarquía de encabezados. Una auditoría automática es útil para detectar problemas repetitivos, pero no sustituye una prueba manual.
SEO técnico
La web necesita títulos únicos, descripciones razonables, URLs canónicas, sitemap, robots y datos estructurados cuando corresponda. También hay que revisar qué páginas deben indexarse y cuáles no. Una página perfecta técnicamente puede no posicionarse si bloqueamos accidentalmente su rastreo.
Seguridad mínima de producción
Antes del lanzamiento se revisan HTTPS, cookies, headers, CORS, límites de entrada, protección de formularios, permisos, secretos y endpoints administrativos. Las credenciales nunca deben aparecer en el bundle público ni en logs.
Observabilidad y recuperación
Una web profesional necesita saber cuándo deja de funcionar. Uptime, logs, errores, alertas y una forma clara de revertir un despliegue reducen mucho el tiempo de recuperación. El mayor error operativo es descubrir un problema solo después de que lo comunique un cliente.
El último test: actuar como usuario
La prueba final debe hacerse desde un dispositivo diferente y, cuando sea posible, una red distinta. Abrir la portada, buscar, enviar un formulario, visitar un artículo, cambiar idioma, probar una URL inexistente y volver a la página principal revela errores que no aparecen en el navegador del desarrollador.
Publicar bien significa que el sistema no solo funciona en tu máquina, sino que puede ser usado, encontrado, medido y recuperado cuando algo sale mal.
Qué debería incluir una revisión técnica antes del lanzamiento
Una revisión útil debe dejar una lista accionable, no una nube de observaciones. Cada hallazgo necesita severidad, evidencia, responsable y criterio de cierre. Así el lanzamiento puede tomar una decisión informada sobre qué bloquea y qué puede corregirse después.
Bloqueadores frente a mejoras
Una contraseña expuesta, una ruta administrativa pública o un formulario que rompe en móvil son problemas de distinta naturaleza. La clasificación ayuda a priorizar sin convertir cada imperfección visual en una crisis.
Prueba de regresión
Cuando se corrige un problema, hay que comprobar la función afectada y también los caminos cercanos. Cambiar una política de caché, por ejemplo, puede arreglar contenido antiguo pero introducir inconsistencias en una ruta dinámica. Las mejoras deben medirse en contexto.
Cómo convertir una lista de requisitos en un sistema de cumplimiento
Una checklist útil no termina en casillas marcadas. Debe indicar qué se comprueba, con qué evidencia y qué ocurre cuando la respuesta es negativa. En una empresa pequeña esto puede ser una tabla sencilla; en una plataforma con varios equipos conviene relacionar cada control con un propietario y una frecuencia.
El orden importa
Primero se corrigen fallos que puedan impedir publicar o exponer información. Después se atacan problemas de rendimiento y experiencia. Finalmente se optimizan detalles de mantenimiento. Esta secuencia evita dedicar horas a pulir una página que todavía tiene un formulario roto.
Revisar después del despliegue
Una publicación no congela el sistema. APIs externas cambian, certificados se renuevan, dependencias se actualizan y los contenidos se editan. Una revisión periódica es la forma de detectar regresiones antes de que se conviertan en incidencias.
Una publicación profesional tiene un criterio de salida
Define de antemano qué condiciones deben cumplirse para considerar el lanzamiento terminado: rutas críticas operativas, analítica comprobada, formularios probados, SEO indexable donde corresponda, errores monitorizados y rollback disponible. El criterio evita que el lanzamiento termine simplemente porque alguien decidió dejar de probar.
El contenido también necesita mantenimiento editorial
Una buena web puede perder calidad aunque el código permanezca estable. Precios, servicios, fechas, capturas y enlaces cambian. Por eso una checklist de lanzamiento debe convertirse en una checklist de mantenimiento.
Revisar contenido importante varias veces al año evita que una web técnicamente correcta transmita información obsoleta.
