Checklist de lanzamiento web: qué revisar antes de publicar y en los primeros 90 días

Un checklist de lanzamiento web es la lista ordenada de comprobaciones que un equipo hace antes, durante y después de publicar una web nueva: revisión de textos, formularios, analítica y consentimiento de cookies, SEO y redirecciones, rendimiento, accesibilidad, seguridad, textos legales, el cambio de DNS y las primeras semanas de seguimiento. Existe porque la mayoría de los problemas de un lanzamiento cuestan poco de detectar en el entorno de staging y mucho cuando Google ya ha rastreado la versión equivocada.

Este checklist está pensado para equipos que lanzan una web de empresa nueva o rehecha, por su cuenta o con una agencia, y para cualquiera que quiera publicar una web sin perder el tráfico que había conseguido la anterior. Sigue las tres fases en las que se trabaja de verdad: antes del lanzamiento, el día del lanzamiento y los primeros 90 días. Cada punto indica qué revisar y, cuando importa, qué herramienta te dice si está bien.

Si la web nueva sustituye a otra, lee dos veces la sección de redirecciones. Ese paso decide si el tráfico de búsqueda de la web antigua se mantiene. Si además vas a rehacer la estructura completa, nuestro checklist de rediseño web cubre la planificación previa.

Un checklist útil para la salida a producción cubre tres fases. Las comprobaciones previas se hacen en staging y deciden si la web está lista. El día del lanzamiento es el cambio en sí: DNS, cachés y señales de indexación. Las comprobaciones posteriores duran unos 90 días y confirman que lo que funcionaba en staging también funciona con tráfico real, navegadores reales y rastreadores reales. Muchos checklists publicados terminan en el botón de publicar, y por eso la tercera fase tiene aquí su propia parte.

La tabla de abajo es la versión corta y sirve como plantilla que puedes copiar en tu gestor de proyectos. Asigna a cada fila una persona responsable con nombre. Una tarea que es "del equipo" no suele ser de nadie, y es la que sigue abierta la mañana del lanzamiento.

La revisión de contenidos es la parte menos técnica de un checklist web y la que los visitantes notan primero. Lee cada página en staging, no en el editor del CMS, porque las plantillas cambian cómo se cortan los textos y cómo se recortan las imágenes. Contrasta con la fuente los precios, teléfonos, direcciones, horarios y datos legales de la empresa, y sustituye cada texto provisional, cada párrafo de lorem ipsum y cada imagen de prueba. Los enlaces internos rotos y los botones que no llevan a ninguna parte entran en la misma pasada.

Contenido y revisión

• Cada página tiene su propia etiqueta title, su meta description y un único H1
• Las imágenes tienen un texto alternativo que las describe y están comprimidas (WebP o AVIF)
• El año del copyright, los enlaces a redes sociales y el enlace del logo a la página de inicio funcionan
• La imagen y el título de Open Graph se ven bien al compartir un enlace en Slack, LinkedIn o WhatsApp
• Una página 404 propia devuelve a la gente a las secciones principales

Formularios y entrega de correos

Un formulario que se envía solo está probado a medias. La otra mitad es comprobar si el correo de aviso llega a la persona que tiene que responder. Envía cada formulario con datos realistas y revisa la bandeja de entrada, la carpeta de spam y el CRM o la hoja de cálculo donde debe llegar el contacto.

Envía los avisos de formularios desde un dominio autenticado o un servicio de correo transaccional, no con la función de correo por defecto del servidor web. Desde febrero de 2024, las directrices para remitentes de Gmail exigen a todos los remitentes configurar SPF o DKIM, y a quienes envían más de 5.000 mensajes al día, usar los dos y publicar un registro DMARC. Un formulario de contacto nunca llegará a ese volumen, pero el correo sin autenticar de un dominio nuevo acaba en spam con mucha más frecuencia, y nadie se da cuenta hasta que un cliente llama para preguntar por qué nadie le contestó.

La analítica tiene que estar activa y verificada el día del lanzamiento, porque los datos que no recojas la primera semana no se pueden recuperar después. Pegar una etiqueta no basta. Decide qué acciones cuentan como éxito (envíos de formularios, solicitudes de presupuesto, llamadas, compras), márcalas como eventos clave en GA4 y prueba cada una en DebugView o Tag Assistant antes del cambio de DNS, mientras todavía puedes corregir sin prisas.

Si la web recibe visitas de la UE, el banner de cookies y la analítica tienen que funcionar juntos. En España, el artículo 22.2 de la LSSI-CE exige informar al usuario y obtener su consentimiento antes de usar cookies que no sean técnicas. La Guía sobre el uso de las cookies de la AEPD, actualizada en julio de 2023, pide que aceptar y rechazar se ofrezcan al mismo nivel, lo que en la práctica significa un botón de rechazar en la primera capa. Google, por su parte, exige a las webs que miden usuarios del EEE con sus etiquetas que recojan el consentimiento y lo transmitan mediante el modo de consentimiento, que añadió dos parámetros, ad_user_data y ad_personalization, a las señales de almacenamiento originales. Las etiquetas no deberían instalar cookies de analítica ni de publicidad antes de que el visitante acepte. Prueba los dos caminos en una ventana privada y confirma que rechazar detiene de verdad las cookies.

Checklist de medición

• Propiedad de GA4 creada, con el tráfico de tu propia oficina filtrado
• Eventos clave definidos para cada conversión que importa al negocio
• Propiedad de Search Console verificada antes del lanzamiento, idealmente como propiedad de dominio
• Herramientas de mapas de calor o grabación de sesiones incluidas en el banner y en la política de cookies
• Nomenclatura UTM acordada para el anuncio del lanzamiento y para las campañas

La mayoría de los problemas SEO del día del lanzamiento vienen de ajustes de staging que pasan a producción. Un entorno de staging suele estar oculto a los buscadores, y eso hay que deshacerlo en el momento en que la web sale en vivo. Según la documentación de Google sobre cómo bloquear la indexación, si una página está bloqueada en robots.txt, Google no puede leer su regla noindex, así que revisa los dos ajustes juntos y no por separado.

Señales de indexación

• Elimina las metaetiquetas noindex y las cabeceras X-Robots-Tag que se pusieron para staging
• El robots.txt del dominio en vivo no debe contener Disallow: /, y puede apuntar al sitemap con una línea Sitemap:
• Cada página tiene una etiqueta canonical que apunta a sí misma en el dominio en vivo, no a la URL de staging
• Una versión del dominio (HTTPS, con o sin www) es la principal, y las demás redirigen a ella
• Los datos estructurados pasan la prueba de resultados enriquecidos de Google

Sitemap XML

Genera un sitemap que incluya solo URLs publicadas, indexables y canónicas. Las directrices de Google sobre sitemaps limitan cada archivo a 50.000 URLs o 50 MB sin comprimir e indican que Google ignora los valores priority y changefreq, así que no tiene sentido ajustarlos. lastmod solo se usa si es exacto de forma constante.

Redirecciones desde la web antigua

Si la web nueva sustituye a otra, el mapa de redirecciones es el documento más importante del proyecto. Rastrea la web antigua, exporta sus URLs junto con las páginas que tienen enlaces entrantes o tráfico de búsqueda y asigna cada una a su equivalente nuevo más cercano. La guía de Google sobre migraciones con cambios de URL pide redirecciones permanentes del lado del servidor (301 o 308), sin cadenas de redirecciones, sin redirigir todo a la página de inicio y manteniéndolas al menos un año. Nuestra guía de migración web y el artículo sobre cómo proteger el SEO en un rediseño explican el mapeo paso a paso.

Webs multilingües

En una web con más de un idioma, cada página necesita anotaciones hreflang que enumeren todas sus versiones, incluida ella misma, y cada versión tiene que enlazar de vuelta. La documentación de Google sobre versiones localizadas indica que las anotaciones que solo apuntan en un sentido se ignoran. Añade una entrada x-default para el selector de idioma o la página de respaldo. Si publicas también en catalán, euskera o gallego, cada versión entra en esas anotaciones como un idioma más.

La velocidad es más fácil de arreglar antes del lanzamiento, mientras las plantillas siguen abiertas. Las Core Web Vitals de Google dan objetivos claros. Web.dev define una buena experiencia, en el percentil 75 de las cargas de página en móvil y escritorio, como un Largest Contentful Paint de 2,5 segundos o menos, un Interaction to Next Paint de 200 milisegundos o menos y un Cumulative Layout Shift de 0,1 o menos. INP sustituyó a First Input Delay como Core Web Vital en 2024.

Antes del lanzamiento solo tienes datos de laboratorio. Pasa PageSpeed Insights y Lighthouse con el perfil móvil por la página de inicio y por una página de cada tipo de plantilla (página de servicio, artículo, contacto, producto). Arregla primero lo más pesado: imágenes de cabecera sin comprimir, fuentes cargadas desde varios orígenes y scripts de chat o de seguimiento que bloquean el hilo principal. Nuestra guía para crear una web de alto rendimiento entra en más detalle.

Los errores de accesibilidad son frecuentes y casi siempre fáciles de detectar. El informe WebAIM Million 2026 encontró fallos detectables de WCAG 2 en el 95,9% del millón de páginas de inicio más visitadas: texto con poco contraste en el 83,9%, imágenes sin texto alternativo en el 53,1% y campos de formulario sin etiqueta en el 51%. Herramientas automáticas como axe o WAVE señalan la mayoría de estos fallos en staging en pocos minutos por plantilla.

Los análisis automáticos se dejan mucho, así que añade una revisión manual. Recorre cada plantilla con el tabulador, comprueba que el contorno de foco se ve y asegúrate de que el banner de cookies, los menús y las ventanas emergentes se pueden cerrar sin ratón. El objetivo habitual es WCAG 2.2 nivel AA.

En la UE, el Acta Europea de Accesibilidad se aplica desde junio de 2025 a muchos servicios digitales dirigidos a consumidores. En España la incorpora la Ley 11/2023, de 8 de mayo, cuyos requisitos de accesibilidad se aplican desde el 28 de junio de 2025 a los productos y servicios que enumera, entre ellos el comercio electrónico. Las microempresas que prestan servicios están exentas. Nuestra guía de accesibilidad web recoge las comprobaciones por componente.

La seguridad antes del lanzamiento es sobre todo configuración. El certificado SSL tiene que cubrir cada nombre de host que sirves, con y sin www, y renovarse solo, y cada petición HTTP debe redirigir a HTTPS. Las cabeceras de seguridad se configuran en una hora y cierran huecos habituales: Strict-Transport-Security, una Content-Security-Policy (consulta la guía de CSP de MDN), X-Content-Type-Options y una Referrer-Policy. Compruébalas con un escáner externo en lugar de fiarte del panel del hosting.

• Las cuentas de administración usan contraseñas únicas y verificación en dos pasos, y las cuentas por defecto están eliminadas
• El CMS, los plugins y las dependencias están actualizados
• Las copias de seguridad automáticas funcionan, se guardan fuera del servidor y se ha probado al menos una restauración
• Los formularios tienen protección antispam, como un campo trampa (honeypot), un límite de envíos o un CAPTCHA
• La monitorización de disponibilidad avisa a una persona concreta, no a un buzón compartido que nadie lee

Aviso legal, privacidad y cookies

Enlaza desde el pie de cada página el aviso legal, la política de privacidad y la política de cookies. En España, el artículo 10 de la LSSI-CE obliga a ofrecer de forma permanente, fácil, directa y gratuita la información general del prestador: nombre o denominación social, domicilio, correo electrónico, datos de inscripción registral cuando proceda y NIF. La ley no usa el término "aviso legal", pero es el nombre habitual de la página donde se publica esa información.

La política de privacidad responde a los deberes de información de los artículos 13 y 14 del RGPD y a la LOPDGDD (Ley Orgánica 3/2018), y tiene que nombrar las herramientas que de verdad funcionan en la web. Por eso conviene escribirla cuando la analítica, el chat y los contenidos incrustados estén decididos, no antes. Revisa también la política de cookies con la guía de la AEPD, cuyo periodo de adaptación a la versión de 2023 terminó el 11 de enero de 2024, y deja que un profesional revise los textos legales de la web antes de publicarlos.

El día del lanzamiento debería ser aburrido. Elige una mañana entre semana en la que el desarrollador y el responsable de contenidos estén disponibles el resto del día, y evita los viernes por la tarde. Congela los cambios de contenido en la web antigua un día antes, para que no se publique allí nada que la nueva no tenga. Después sigue los pasos en este orden y marca cada uno al terminarlo.

1. Uno o dos días antes, baja el TTL de los registros DNS que vas a cambiar (300 segundos es un valor habitual). Los resolutores guardan un registro durante el TTL que recibieron, así que esto solo sirve si se hace con antelación.
2. Haz una última copia de seguridad de la web antigua y de la nueva.
3. Despliega y después cambia el DNS o la configuración del hosting.
4. Vacía todas las capas de caché (CDN, servidor, CMS) para que nadie reciba una versión antigua o la de staging.
5. Revisa el robots.txt y el estado de noindex en el dominio en vivo.
6. Rastrea la lista de URLs antiguas para confirmar las redirecciones y abre a mano las 20 páginas con más tráfico.
7. Envía el sitemap XML en Search Console y pasa la Inspección de URLs por la página de inicio y las principales páginas de servicio. Si ha cambiado el propio dominio, usa la herramienta de cambio de dirección, que Google reserva para traslados entre dominios o subdominios.
8. Envía un formulario de prueba real y confirma que llegan tanto el correo como el evento clave de GA4.
9. Activa la monitorización de disponibilidad y vuelve a subir el TTL cuando la nueva configuración esté estable.

Cuenta con un retraso hasta que la búsqueda se ponga al día. Google indica que el rastreo puede tardar desde unos días hasta unas semanas, y volver a solicitar la misma URL no lo acelera. Después de una migración, las posiciones pueden oscilar un tiempo mientras Google procesa las redirecciones.

El primer mes sirve para detectar lo que se escapó en la revisión de staging. Los visitantes reales llegan con navegadores, dispositivos y recorridos que nadie probó, y los rastreadores encuentran URLs antiguas que nadie mapeó. Revisa Search Console cada pocos días durante las dos primeras semanas y luego una vez por semana. Lo que arregles en este periodo cuesta poco, mientras que los mismos problemas descubiertos en el cuarto mes ya han costado tráfico y contactos.

Search Console y errores 404

• En el informe de indexación de páginas, vigila si suben "No encontrada (404)", "Excluida por una etiqueta noindex" y "Página con redirección"
• Redirige las URLs 404 que tengan enlaces entrantes o tráfico a las páginas nuevas adecuadas
• Confirma que el sitemap aparece procesado sin errores
• Compara las impresiones de tus búsquedas principales con la línea base de la web antigua

Analítica y conversiones

• Compara las conversiones de GA4 con lo que llegó de verdad al CRM o a la bandeja de entrada, y averigua por qué difieren antes de que alguien use las cifras
• Busca páginas de entrada con tasas de salida especialmente altas en móvil
• Revisa la tasa de consentimiento. Un 0% o un 100% exactos de aceptación indican que algo está mal configurado

Datos de rendimiento de campo

Las puntuaciones de laboratorio previas al lanzamiento son una previsión. Los datos de campo vienen de usuarios reales de Chrome a través del Chrome UX Report, que agrega una ventana móvil de 28 días. Por eso el primer informe de Core Web Vitals con sentido llega alrededor de un mes después del lanzamiento, y una web con poco tráfico puede no tener nunca datos suficientes por página. En ese caso, los datos a nivel de origen o tu propia monitorización de usuarios reales cubren el hueco.

A partir del segundo mes hay datos suficientes para dejar de arreglar y empezar a mejorar. La pregunta pasa de "¿hay algo roto?" a "¿dónde abandonan los visitantes y por qué?". Usa los informes de rutas de conversión y de páginas de destino para elegir las dos o tres páginas que más pesan en los contactos, y observa cómo las usa la gente con mapas de calor o grabaciones de sesiones antes de cambiar nada.

Cambia una sola cosa cada vez y mídela frente a la línea base, porque los cambios hechos en bloque no se pueden atribuir a nada. Si el tráfico lo permite, haz un test A/B como es debido siguiendo el ciclo de la guía de tests A/B de Nielsen Norman Group: una hipótesis, una variable, una métrica definida y tiempo suficiente para llegar a un resultado. En webs B2B con poco tráfico, una comparación limpia de antes y después durante varias semanas suele ser la alternativa honesta. Nuestra guía de optimización de conversión va más allá.

Mejoras típicas en este periodo:

• Formularios más cortos, sin los campos que ventas nunca usa
• Llamadas a la acción más claras en la primera pantalla en móvil
• Secciones de página reordenadas según la profundidad de scroll
• Enlaces internos desde artículos del blog a las páginas de servicio que apoyan
• Páginas con poco contenido ampliadas o fusionadas con otras más sólidas

Dónde ayudan las herramientas de IA

Las herramientas de IA rinden bien en la mitad analítica de este ciclo: resumir grabaciones de sesiones, agrupar búsquedas, señalar anomalías en la analítica y redactar variantes de prueba. La mitad de las decisiones sigue necesitando a alguien que conozca el negocio, sus márgenes y sus clientes. Usa la IA para acortar el camino de los datos a la hipótesis y deja a una persona como responsable de lo que se publica.

La mayoría de los lanzamientos que fallan lo hacen por el proceso y no por la tecnología. Casi todos los problemas vienen de algo que era cierto en staging y dejó de serlo en producción, o de una tarea que todos daban por hecha por otra persona. Cada uno de los errores siguientes se evita con poco esfuerzo si tiene un responsable con nombre y una prueba, y sale caro si lo descubres un mes después por una caída de contactos.

• Una etiqueta noindex o un bloqueo en robots.txt de staging que llega a producción
• Ningún mapa de redirecciones, o redirecciones que llevan todas a la página de inicio
• Analítica instalada pero con los eventos clave sin probar, de modo que falta el primer mes de datos de conversión
• Un banner de cookies que carga rastreadores antes de que el visitante acepte
• Avisos de formularios que caen en spam durante semanas sin que nadie lo note
• Aviso legal o política de privacidad sin terminar el día del lanzamiento
• Lanzar un viernes a última hora sin nadie disponible hasta el lunes
• Tratar el lanzamiento como el final del proyecto, sin revisión prevista para el día 30 ni para el día 90

Una auditoría web unos tres meses después del lanzamiento detecta lo que se haya colado, y nuestra guía de mantenimiento web cubre el trabajo rutinario a partir de ahí.

Un checklist de lanzamiento web funciona cuando está ordenado, cada punto tiene responsable y se completa hasta el final. Las comprobaciones previas deciden si la web está lista. El día del lanzamiento es una secuencia corta de cambios que conviene ensayar antes en staging. Los 90 días siguientes muestran si la web cumple su función con visitantes reales. Apunta la línea base, asigna un responsable a cada línea y pon en el calendario las revisiones del día 30 y del día 90 antes de publicar.

Cuando Vezert crea una web corporativa o una landing page, un checklist como este forma parte de la entrega. Después del lanzamiento, nuestros planes de mantenimiento web cubren la monitorización del rendimiento, las actualizaciones de seguridad y el soporte de contenidos, y los servicios SEO se ocupan de la indexación, las redirecciones, los contenidos y el enlazado interno. Los precios actuales están en la página de precios.