Checklist SEO para migrar un sitio: qué vigilar antes y después

Una checklist SEO para migrar un sitio web tiene tres partes: lo que registras antes del cambio, lo que verificas el día en que sale el sitio nuevo y lo que sigues vigilando durante el mes siguiente. Muchas migraciones que pierden tráfico tenían un plan razonable. Lo pierden porque un noindex de staging o un bloqueo en robots.txt sobrevivió al cambio y nadie se dio cuenta en dos semanas.

Da igual que el proyecto sea un cambio de dominio, un cambio de plataforma, el paso de HTTP a HTTPS o un rediseño que mantiene las mismas URL. Los ajustes que hacían invisible el staging para Google llegan a producción, y el sitio deja de poder rastrearse mientras en el navegador se ve perfectamente.

Una o dos semanas antes del lanzamiento: crea la referencia

No puedes demostrar qué ha cambiado con una migración si no tienes un registro de lo que había. Hazlo con suficiente antelación para que refleje el sitio normal y no uno ya congelado para el lanzamiento.

1. Exporta todas las URL del sitemap actual y de un rastreo completo, y guarda los dos archivos. Las páginas que reciben tráfico pero no están en el sitemap son las que se olvidan en los mapas de redirecciones, así que crúzalas con las principales páginas de destino de GA4 o del informe Rendimiento de Search Console de los últimos 12 meses.
2. Registra title, meta description, H1, canonical y hreflang de cada URL con tráfico orgánico. Te vale una exportación a CSV de un rastreador.
3. Anota la configuración de seguimiento con sus IDs: el ID de medición de GA4 (prefijo G-), el contenedor de GTM (prefijo GTM-), el ID de Meta Pixel y la plataforma de consentimiento de cookies.
4. Apunta los tiempos de respuesta habituales, para saber después si la nueva infraestructura va más lenta.
5. Prepara el mapa de redirecciones, con una fila por cada URL antigua y su destino nuevo concreto. Todas las URL con tráfico o con backlinks necesitan la suya.

Nuestra guía de buenas prácticas del sitemap XML explica cómo debería ser el sitemap nuevo.

En staging: localiza los ajustes que romperán producción

Los mecanismos que mantienen el staging fuera de Google son justo los que tienes que quitar en el lanzamiento. Localiza dónde está cada uno en staging y vuelve a comprobarlos en producción a los pocos minutos del cambio.

• robots.txt con Disallow: /. Aquí tienes cómo revisar el robots.txt línea por línea.
• Una etiqueta noindex en una plantilla compartida, o una cabecera X-Robots-Tag: noindex configurada en el servidor o en la CDN
• En WordPress, la casilla "Disuade a los motores de búsqueda de indexar este sitio" en Ajustes > Lectura
• Canonicals que apuntan al hostname de staging o al dominio antiguo
• Anotaciones hreflang que hacen referencia a URL antiguas o a las que les faltan las etiquetas de retorno que necesita cada versión de idioma
• La autenticación HTTP básica, que bloquea a Googlebot con la misma eficacia que cualquier regla de robots

El día del lanzamiento

Las primeras horas sirven para confirmar que el cambio ha funcionado, no para rediseñar plantillas.

Prueba las redirecciones contra el mapa. curl -sIL https://old.example.com/pagina/ muestra cada salto con su código de estado, así que puedes confirmar que hay una única 301 al destino correcto y no una cadena o una 302. No redirijas todo a la home para ir más rápido; Google suele tratar esas redirecciones como soft 404, y se pierde el valor de las páginas antiguas.

Confirma que el certificado SSL es válido tanto para www como para el dominio sin www. Después recorre las plantillas principales con el informe Tiempo real de GA4 abierto y comprueba que GA4 y GTM se disparan con los mismos IDs que anotaste en la referencia. El seguimiento se pierde con facilidad al rehacer plantillas, y nadie lo nota hasta el informe mensual.

Si cambias de dominio, verifica las dos propiedades en Search Console y comunica el traslado con la herramienta Cambio de dirección (Ajustes > Cambio de dirección) desde la propiedad antigua. Envía el sitemap nuevo y mantén accesible el antiguo durante un tiempo para que Google vuelva a rastrear las URL antiguas y encuentre las redirecciones.

Los 30 días siguientes

Los problemas que aparecen después de la primera semana son los que nadie está buscando. Pueden desaparecer URL del sitemap nuevo mientras el CMS se asienta, una plantilla puede reescribir titles y meta descriptions en una sección entera, un deploy rutinario puede cambiar canonicals y los tiempos de respuesta pueden ir subiendo a medida que vuelve el tráfico. En Search Console, el informe de indexación de páginas de la propiedad nueva debería mostrar cómo suben las páginas indexadas mientras bajan en la propiedad antigua a medida que se procesan las redirecciones. Si la propiedad nueva se estanca, mira primero su tabla "Por qué no se indexan las páginas".

Deja que un monitor guarde la referencia de tu checklist SEO para migrar

Si añades el sitio del cliente a Deltio una o dos semanas antes del lanzamiento, el estado previo queda registrado sin que tengas que hacerlo tú. Deltio revisa el sitemap y las páginas cada día y compara cada comprobación con la anterior, así que una sección que desaparece del sitemap, un cambio de noindex o de robots.txt, un canonical que apunta a otro sitio o un title, meta description o H1 reescrito generan una alerta por Slack y por email para ese sitio. También vigila el uptime, el SSL y la caducidad del dominio, y si GA4, GTM y Meta Pixel siguen en la página.

Un ciclo diario no sustituye a las comprobaciones manuales de la primera hora después del lanzamiento. Cubre el mes siguiente, cuando la atención suele pasar al próximo proyecto. La referencia no se puede crear a posteriori, así que añade los sitios antes de que esté fechada la próxima migración; la prueba gratuita de 14 días da de sobra para cubrir un lanzamiento.