Saltar al contenido 
Lista de lanzamiento web: antes y después de publicar
Una lista de lanzamiento debe decir algo más que qué probar. Debe mostrar quién asume cada comprobación, qué demuestra que se ha superado y qué ocurre si falla. Esta guía ofrece a fundadores, responsables de marketing y de proyecto una forma práctica de controlar un lanzamiento. Cubre el trabajo previo, el cambio a producción y la etapa posterior.
No marques una tarea como completada sin evidencias. «El formulario funciona» es una opinión hasta que alguien lo envía, recibe la respuesta prevista y registra el resultado. Ese registro convierte una lista informal en un plan para decidir claramente si continuar o detenerse.
La lista empieza por las responsabilidades
Cada tarea crítica necesita responsable, revisor cuando corresponda, evidencias y respuesta si falla. Una persona puede asumir varios roles en proyectos pequeños. Aun así, cada fila debe identificar a alguien, no solo un departamento o agencia.
Adapta esta matriz a tu sitio:
| Fase | Tarea | Responsable sugerido | Evidencia de aceptación | Respuesta si falla |
|---|---|---|---|---|
| Antes del lanzamiento | Aprobar contenido y medios finales | Responsable de contenido | Aprobación fechada o control de calidad firmado | Excluir la página afectada o aplazar |
| Antes del lanzamiento | Probar navegación, búsquedas, formularios y conversión | Responsable de calidad o proyecto | Registro con URL, dispositivos y resultados | Corregir el recorrido crítico y repetir |
| Antes del lanzamiento | Revisar accesibilidad con criterios acordados | Diseñador, desarrollador y revisor | Revisión completa con incidencias pendientes registradas | Resolver bloqueos o documentar la decisión de publicar |
| Antes del lanzamiento | Confirmar indexación, URL canónicas, sitemap y redirecciones | Responsable SEO o desarrollador | Informe de rastreo y mapa de URL aprobado | Corregir la configuración antes de publicar |
| Antes del lanzamiento | Confirmar copia y preparación para revertir | Responsable técnico | Copia restaurable confirmada y pasos de reversión registrados | No iniciar el cambio |
| Día del lanzamiento | Comprobar DNS, TLS y disponibilidad | Responsable técnico | Pruebas satisfactorias desde ubicaciones y dispositivos acordados | Seguir el plan de reversión o incidentes |
| Día del lanzamiento | Verificar URL y redirecciones prioritarias | Responsable SEO o calidad | Comprobaciones registradas de estado y destino | Reparar rutas antes de promocionar |
| Día del lanzamiento | Completar revisión de detener o continuar | Responsable del lanzamiento | Registro de decisión, riesgos y aprobadores | Pausar si persiste un bloqueo definido |
| Después del lanzamiento | Enviar formularios y probar conversiones en producción | Responsable de marketing o calidad | Envíos de prueba y evidencia de recepción | Escalar y corregir el recorrido roto |
| Después del lanzamiento | Validar analítica y consentimiento | Responsable de analítica | Visitas o eventos de prueba registrados | Diagnosticar antes de confiar en informes |
| Después del lanzamiento | Supervisar errores, señales de indexación y recorridos críticos | Responsables operativos asignados | Registro fechado y tickets de incidencias | Priorizar por impacto y asignar resolución |
Las etiquetas importan menos que la responsabilidad. El fundador puede aprobar el contenido y el socio de desarrollo publicar. En ambos casos, el responsable de lanzamiento mantiene la matriz y registra la decisión final.
Los sitios nuevos y las migraciones necesitan controles diferentes
Comparten comprobaciones de contenido, funciones, accesibilidad y medición. Una migración también tiene historia que proteger. Las URL existentes pueden tener enlaces, marcadores, señales de búsqueda o tráfico de campañas; cambiarlas crea dependencias adicionales.
| Área de decisión | Sitio nuevo | Rediseño o migración de CMS |
|---|---|---|
| URL anteriores | Normalmente no hay conjunto previo de URL publicadas | Exportar y comparar el inventario actual |
| Redirecciones | Solo para rutas temporales o de campaña modificadas | Asignar a cada URL anterior modificada el destino publicado más pertinente |
| Referencia inicial | Registrar rendimiento y ajustes de medición iniciales | Guardar referencias previas de tráfico, conversión, rastreo y páginas prioritarias |
| Reversión | Restaurar la publicación o estado de espera anterior | Considerar sitio antiguo, base de datos, DNS y redirecciones |
| Comprobaciones de búsqueda | Confirmar indexabilidad y disponibilidad del sitemap | Comparar también URL antiguas y nuevas, redirecciones, canónicas y controles de indexación |
Si cambian las URL, usa un mapa explícito en lugar de redirigir todo al inicio. Las pautas de Google Search Central sobre traslados explican el mapeo, las redirecciones del servidor y la supervisión. Revísalas según la plataforma y el alcance reales.
Un rediseño con el mismo dominio también puede ser una migración. Si cambian rutas, responsables de contenido, plantillas, analítica o CMS, compara ambos estados. Un dominio nuevo sin páginas anteriores no necesita inventar un proyecto de redirecciones. Sigue necesitando un plan de indexación, sitemap, analítica y control de producción.
Las comprobaciones previas necesitan evidencias
Prueba la versión candidata en un entorno tan parecido a producción como sea práctico. Busca dependencias pendientes cuando aún puedas pausar sin afectar al sitio público.
Aprueba contenido y estructura
Revisa cada página incluida. Confirma encabezados, textos, llamadas a la acción, contacto, imágenes, descargas, metadatos y textos legales aportados. Revisa también estados vacíos, errores y páginas de agradecimiento, fáciles de olvidar visualmente.
Registra la aprobación mediante una lista fechada, relación de páginas anotada o gestor de incidencias. Si alguien no ha aprobado una afirmación crítica o página de conversión, trátalo como riesgo abierto en lugar de asumir que el silencio significa consentimiento.
Prueba recorridos completos
Prueba recorridos, no botones aislados. El contacto puede incluir página de destino, navegación, validación, envío, notificación, agradecimiento y destino posterior. El comercio electrónico o las cuentas tendrán más pasos, pero el principio es el mismo.
Usa los dispositivos y navegadores acordados. Registra URL, entrada, resultado esperado y real y persona que prueba. Si falla, crea una incidencia trazable y repite todo el recorrido después de corregir.
Usa criterios de accesibilidad verificables
La aceptación debe referirse a un estándar definido, no a «comprobar accesibilidad». Las Pautas de Accesibilidad para el Contenido Web 2.2 del W3C ofrecen criterios de éxito comprobables como referencia.
Las herramientas automáticas ayudan, pero el registro también debe cubrir interacciones que requieren criterio humano: teclado, foco visible, enlaces significativos, instrucciones, recuperación de errores, orden del contenido y alternativas textuales. Documenta hallazgos pendientes y quién aprobó publicar con ellos.
Confirma controles de búsqueda y URL
Comprueba qué determina cómo descubren e interpretan los buscadores el sitio: directivas robots, indexación por página, URL canónicas, estados HTTP, enlaces internos y sitemap XML.
En una migración, compara el mapa de redirecciones con las URL finales. Prueba rutas representativas y páginas prioritarias. Confirma además que no se hayan trasladado restricciones o canónicas del entorno de pruebas a producción.
Prepara medición, copias y reversión
Escribe antes qué constituye una prueba satisfactoria de analítica. Puede ser ver una visita, envío u otro evento en la propiedad correcta. No aceptes una etiqueta solo porque su código aparezca en la página.
El responsable técnico también debe confirmar la copia o estado de recuperación adecuado al alojamiento. El plan de reversión debe identificar quién decide, desencadenantes, pasos, accesos y vía de comunicación. No sirve si durante el cambio no se puede acceder a credenciales o versión anterior.
Si aún necesitas definir la gestión del desarrollo, revisa cómo se planifica el desarrollo web profesional antes de fijar una fecha.
El día de lanzamiento necesita una decisión registrada
Sigue un procedimiento breve con coordinador identificado. Debe confirmar versión correcta, disponibilidad de personas, copias y reversión preparadas y ausencia de incidencias críticas previas.
Una secuencia práctica es:
- Congelar cambios imprevistos de contenido y configuración.
- Confirmar paquete, responsables, canal de comunicación, copia y reversión.
- Iniciar la publicación o cambio DNS aprobado.
- Comprobar disponibilidad, TLS, páginas prioritarias y recursos críticos.
- Probar navegación, formularios, accesos, búsquedas, pago u otros recorridos críticos pertinentes.
- En migraciones, verificar muestras de redirecciones y comparar URL anteriores prioritarias con sus destinos.
- Validar analítica y registrar el resultado.
- Registrar defectos, responsables, gravedad y próxima revisión.
- Registrar la decisión de continuar, mantener en espera o revertir.
Un fallo no siempre exige revertir. Una errata en una página poco visitada y un formulario roto implican riesgos distintos. Define los bloqueos antes. Pueden incluir páginas prioritarias no disponibles, transacciones o formularios fallidos, accesos inseguros, errores generalizados de redirección o imposibilidad de medir un lanzamiento ligado a una campaña activa. Los responsables deben aprobar los criterios reales.
No permitas que una fecha comprometida se imponga a un bloqueo sin una decisión registrada. Indica qué falló, impacto probable, alternativa si existe y quién acepta el riesgo restante.
Las comprobaciones posteriores detectan problemas exclusivos de producción
La validación empieza cuando el sitio público es accesible. Comienza por los recorridos más relevantes y amplía la revisión. Busca regresiones que el entorno de pruebas no revela, como configuración, integraciones, caché, redirecciones o medición.
En el período inicial, vuelve a comprobar:
- inicio y páginas de destino prioritarias;
- navegación, búsquedas internas, formularios y conversión;
- TLS y avisos de contenido mixto;
- estados HTTP, canónicas, indexación y sitemap;
- destinos de redirecciones migradas;
- visitas y eventos de conversión acordados;
- errores del servidor o aplicación disponibles para el equipo;
- problemas de accesibilidad introducidos al publicar;
- enlaces de campañas e integraciones externas incluidas.
Usa dos ventanas prácticas: comprobaciones inmediatas tras el cambio y revisión de la primera semana. Son ventanas de planificación, no garantías universales. Un sitio transaccional con mucho tráfico necesita observación más estrecha; uno informativo pequeño, menos controles. Ajusta la frecuencia al riesgo, tráfico, momento y disponibilidad.
Cierra cada incidencia con evidencia de repetición de pruebas. Compara además el comportamiento con la referencia previa a la migración. Mantén las responsabilidades hasta resolver defectos prioritarios y aceptar los elementos restantes.
Una vez estable, actualizaciones, copias, seguridad y compatibilidad pasan a operaciones. Esta guía de mantenimiento WordPress tras el lanzamiento explica la diferencia.
Una lista completa hace visible la decisión
Un documento útil responde cinco preguntas por comprobación crítica: qué probamos, quién se responsabiliza, qué demuestra que pasó, qué ocurre si falla y quién decide continuar. Ayuda tanto a pequeños equipos como a grupos de especialistas.
Antes de aprobar, confirma:
- que cada fila crítica tiene responsable identificado;
- que las evidencias están adjuntas o enlazadas;
- que se aplicaron controles de migración al cambiar URL o sistemas anteriores;
- que se entienden bloqueos y motivos de reversión;
- que están asignadas las pruebas y horas de supervisión;
- que los riesgos abiertos tienen responsable y decisión explícita.
ID7 Studio es un estudio de diseño y desarrollo web para empresas internacionales. Nuestro equipo aporta más de 15 años de experiencia y ha trabajado con más de 800 clientes. Si quieres un proyecto con planificación del lanzamiento incluida en el alcance, solicita una propuesta a medida.
