Checklist técnico de lanzamiento: de staging a producción sin perder SEO

La inmensa mayoría de desastres de SEO en un lanzamiento no vienen de un problema técnico complejo, sino de un paso de checklist que nadie marcó porque no existía checklist. Un entorno de staging con noindex heredado, una redirección que se verifica después del cambio de DNS en vez de antes, un canonical que sigue apuntando al dominio de pruebas: son errores triviales de corregir por separado, pero devastadores si se descubren días después del lanzamiento, cuando Google ya ha empezado a procesar la versión rota. Esta guía es una lista de comprobación concreta, en el orden en que hay que ejecutarla, no una explicación conceptual de por qué importa cada punto (eso ya está cubierto en las guías específicas de cada tema, enlazadas donde corresponde).

Antes del lanzamiento: lo que se comprueba en staging

El error de lanzamiento más común, con diferencia, es dejar activo en producción el bloqueo de rastreo que protegía el entorno de pruebas. La mayoría de entornos de staging llevan, por buena práctica, un Disallow: / en robots.txt o una etiqueta noindex global, precisamente para que Google no indexe una copia de pruebas del sitio real. El problema aparece cuando ese bloqueo se copia sin querer al pasar a producción (porque staging y producción comparten el mismo fichero de configuración, o porque nadie recuerda desactivarlo en el despliegue final) y el sitio entero queda invisible para Google desde el primer día, a veces durante semanas antes de que alguien lo note.

Comprobación obligatoria antes de dar por bueno el lanzamiento:
curl -s https://www.tudominio.com/robots.txt
# No debe contener: Disallow: /
# Debe apuntar al sitemap correcto de producción

curl -sI https://www.tudominio.com/ | grep -i x-robots-tag
# No debe devolver: noindex

# Y revisar el  del HTML servido, no solo la plantilla en el editor:
#  heredado de staging
# es el fallo más habitual y más caro de un lanzamiento

Redirecciones: verificarlas antes del cambio de DNS, no después

Cuando un lanzamiento incluye un cambio de dominio, de estructura de URLs, o ambos, las redirecciones desde las URLs antiguas hacia las nuevas tienen que estar probadas y funcionando antes de apuntar el DNS al nuevo destino, no después. El error habitual es dar por hecho que "ya se configurarán las redirecciones en cuanto el sitio esté en vivo", lo que deja una ventana (a veces de horas, a veces de días) en la que las URLs antiguas devuelven 404 en vez de redirigir, justo el periodo en el que Google, atraído por el cambio de contenido detectado, suele revisar esas URLs con más frecuencia de lo habitual. Verificar las redirecciones contra el entorno de staging antes del cambio de DNS, simulando el dominio final con una entrada temporal en el fichero hosts local, permite confirmar que cada URL antigua relevante redirige correctamente antes de que el cambio sea público.

Sitemap, robots.txt y canonical: apuntando a producción, no a staging

Tres comprobaciones relacionadas que conviene hacer juntas porque comparten la misma causa raíz habitual (un valor de configuración copiado de staging sin actualizar): el sitemap XML enviado debe contener URLs del dominio de producción, no del entorno de pruebas ni de una versión intermedia; el robots.txt de producción debe declarar el sitemap de producción, no dejar la referencia al sitemap de staging que a veces queda olvidada; y la etiqueta <link rel="canonical"> de cada página debe resolver al dominio final, un fallo especialmente frecuente cuando el sitio se ha desarrollado y probado durante semanas bajo un subdominio de staging y esa URL ha quedado escrita de forma fija en algún componente en vez de generarse dinámicamente a partir del dominio real de la petición.

SSL y HSTS: certificado activo y sin bloqueos de acceso accidentales

El certificado SSL del dominio de producción tiene que estar activo, válido y correctamente encadenado (sin errores de cadena de confianza intermedia) antes del lanzamiento, no como una tarea posterior: un aviso de "conexión no segura" en el primer acceso de un usuario real es tan dañino para la confianza como para el SEO. Un matiz que causa problemas serios si se pasa por alto: si el sitio activa HSTS (HTTP Strict Transport Security, que obliga al navegador a recordar que ese dominio solo debe visitarse por HTTPS) con una duración larga (max-age de meses o años) y sobre todo si se activa la variante preload (que lo incluye en una lista precargada en los propios navegadores), cualquier problema posterior con el certificado deja al dominio completamente inaccesible para quien ya lo tenga registrado, sin posibilidad de "volver atrás" a HTTP mientras se soluciona, porque el propio navegador rechaza la conexión insegura sin siquiera intentarla.

# Cabecera HSTS razonable para un lanzamiento reciente:
Strict-Transport-Security: max-age=86400; includeSubDomains
# (24 horas: permite subir la duración progresivamente
# una vez confirmado que el certificado es estable,
# en vez de comprometerse de entrada a max-age de un año o al preload)

El orden correcto de operaciones el día del lanzamiento

La secuencia que minimiza el riesgo no es "cambiar el DNS y luego comprobar", sino comprobar primero contra el entorno final ya desplegado (accediendo por IP directa o mediante una entrada temporal en el fichero hosts local) todo lo anterior: ausencia de bloqueos de robots, redirecciones funcionando, SSL válido, canonical y sitemap correctos. Solo cuando esas comprobaciones pasan sobre el destino real, se realiza el cambio de DNS, y solo después de que la propagación de DNS se haya completado (comprobable con herramientas públicas de propagación) se considera el lanzamiento técnicamente terminado, aunque la vigilancia activa continúe.

Las primeras 48 horas: qué vigilar y con qué frecuencia

El lanzamiento no termina cuando el DNS propaga: las primeras 48 horas son la ventana en la que la mayoría de problemas no detectados en las comprobaciones previas se manifiestan, porque es cuando Google empieza a re-rastrear el dominio con normalidad y a exponer discrepancias. La rutina mínima recomendada durante ese margen: revisar el informe de cobertura de Search Console varias veces al día buscando picos repentinos de exclusiones (URLs marcadas como bloqueadas, con error, o excluidas por canonical hacia otra página); revisar el informe de estadísticas de rastreo para confirmar que Google sigue rastreando con normalidad y no ha detectado errores de servidor; y activar una monitorización de errores 404 en los logs del servidor o mediante una herramienta de análisis de logs, para detectar rápidamente cualquier URL antigua sin redirigir que se haya escapado de la comprobación previa.

Preguntas frecuentes