Checklist SEO de migración de sitio

Qué cuenta como migración

Google trata cualquier cambio a URLs existentes como un site move —

• HTTP a HTTPS
• Cambio de dominio o hostname (example.com a example.net, o fusionar hosts)
• Cambios de path (/page.php?id=1 a /widget)
• Cambia una cosa a la vez. Dominio nuevo + CMS nuevo + rediseño el mismo fin de semana es la forma de perder un mes debuggeando la capa equivocada.
• Los rankings se mueven mientras Google recrawlea. Sitios medianos suelen tardar unas semanas. Los más grandes, más. Es esperado — no es motivo para rollback el día tres.

Un cambio de hosting con las mismas URLs es otro trabajo. No corras un playbook de move de URLs sobre eso.

Dos reglas de Google que evitan discusiones después —

Google también dice que las redirecciones permanentes (301, 308) no causan pérdida de PageRank. El daño viene de cadenas, bucles y tirar todo a la homepage.

1. Verifica ambas propiedades en Search Console

Sitio viejo y sitio nuevo. www y non-www. HTTP y HTTPS si ambos todavía resuelven. Si la verificación de Search Console es un archivo HTML o una meta tag, ese token tiene que existir en el sitio nuevo antes de voltear el tráfico. La gente se olvida de esto todo el tiempo.

Deja el crawl-rate en “Let Googlebot determine.” Si alguna vez subiste un archivo disavow en la propiedad vieja, súbelo otra vez en la nueva. Google no lo traslada.

En un dominio comprado, revisa remociones de URL viejas y manual actions antiguas. Una remoción site-wide de un dueño anterior hará que el sitio nuevo se vea maldito.

2. Arma la lista de URLs viejas desde más de un lugar

Una sola exportación nunca es el sitio completo. Saca de —

• El sitemap XML (y cualquier sitemap hijo)
• Search Console (páginas que de verdad tienen impresiones)
• Analytics (URLs con sesiones en los últimos 12 meses, no la última semana)
• El CMS
• PDFs, imágenes y otros archivos que rankean o reciben links

Si solo mapeas lo que el CMS cree que existe, te pierdes la paginación vieja del blog, el whitepaper PDF antiguo y la URL con parámetros que un partner todavía enlaza.

Pega esa lista en el Comprobador de URL masivo y guarda el CSV. Quieres un baseline pre-launch — qué es 200, qué ya es 301, qué ya está muerto. Después del cutover corres la misma lista y haces diff.

Tope de 1000 URLs por corrida. En sitios más grandes, primero las money pages, luego el resto en batches. Está bien. El proceso de Google es por URL de todos modos.

3. Mapea cada URL vieja a una URL nueva

Este es el trabajo de verdad. Todo lo demás es QA.

• La página equivalente más cercana, no “ya lo vemos después”
• Contenido retirado debería 404 o 410 a propósito. No inventes un destino
• Nunca hagas 301 de un montón de URLs no relacionadas a /. Google puede tratarlo como soft 404, y los usuarios rebotan
• Si fusionaste tres artículos viejos en uno, las tres URLs viejas pueden apuntar a la nueva. Eso es consolidación, no un dump

Mantén el mapa en una hoja con tres columnas — URL vieja, URL nueva, notas. Lo reutilizarás para enlaces internos, canonicals y el crawl post-launch.

4. Deja staging honesto antes de que sea producción

Staging es donde las migraciones mueren, en silencio.

• robots.txt en staging puede bloquear todo. Está bien. Ten el robots.txt de producción escrito y listo en una pestaña para deploy. Pruébalo en el Robots.txt Tester contra las URLs que te importan
• Si usaste noindex para sacar staging de Google, haz una lista de cada URL que debe perderlo. Luego verifica la lista. El Bulk Meta Robots Checker lee tanto la meta robots como X-Robots-Tag, que es la que la gente se pierde porque no aparece en View Source
• Canonicals autoreferenciados en las URLs nuevas. No las viejas, no staging, no una variante con parámetros. Spot-check con el Canonical Checker
• Los enlaces internos del sitio nuevo ya deberían apuntar a URLs nuevas. Las redirecciones atraparán rezagados. Usuarios y crawlers no deberían tener que rebotar por ellas
• Hreflang, si lo tienes, necesita las URLs nuevas en cada anotación de idioma. Un cluster de locale viejo mantendrá vivo el host antiguo en el índice
• Analytics / tag manager en las plantillas nuevas. Confirma que llega un hit antes de celebrar

Recomendación de Google si puedes — mueve en un periodo tranquilo. Menos usuarios chocan con la hora sucia, y queda más servidor para Googlebot, que va a crawlear más duro de lo usual después del flip.

5. Enciende redirecciones permanentes server-side

301 o 308. No meta refresh. No JavaScript. No un 302 que “prometes cambiar después.”

Googlebot seguirá hasta 10 hops. No uses eso como presupuesto. Su consejo — aterriza en la URL final de forma directa; si no puedes, mantén la cadena bajo 3, nunca más de 5. Hops de más son lentos para la gente y una buena forma de filtrar un pedazo de equity.

Revisa los feos con el Redirect Chain Checker — HTTP www viejo, apex HTTP viejo, un /index.php olvidado, cualquier cosa que marketing lleva tres años pegando en ads. Si A luego B luego C, escribe A luego C y borra B.

Mantén las redirecciones al menos un año. Google lo dice en lenguaje claro. Más tiempo es mejor para humanos que hacen clic en links viejos. Actualiza los backlinks de alto tráfico que sí puedas alcanzar para que dejen de usar el redirect.

6. Change of Address no es una varita mágica

Usa Change of Address de Search Console solo cuando cambia el hostname. example.com a example.net. a.example.com a b.example.com.

• HTTP a HTTPS
• www a non-www en el mismo dominio
• Reordenamientos solo de path

No lo uses para —

No reemplaza las redirecciones. Envíalo después de que los 301 estén live, y hazlo para cada variante verificada del host viejo.

7. Sitemaps

Envía un sitemap de las URLs nuevas. Puedes dejar el sitemap viejo en Search Console un rato — Google mostrará warnings de “estas URLs redirigen”. Ese es el punto. No trates esos warnings como errores.

Luego audita el sitemap nuevo para no publicar una lista de 301s y thank-you pages con noindex. El Sitemap Auditor marca 404s, redirecciones y URLs bloqueadas dentro del sitemap. El XML Sitemap Validator es el pase de sintaxis si un plugin escribió el archivo.

8. Vuelve a correr la misma lista de URLs

El mismo CSV del paso 2. Buscas —

• URLs viejas que no son 301/308
• URLs nuevas que no son 200
• Cualquier 404 que debería tener destino
• Cualquier 200 en el host viejo (DNS o caché mintiendo)
• Homepage como destino sorpresa

Si titles, descriptions o H1s fueron parte del rebuild, pasa esas URLs por el SEO Content QA Checker contra el spec que firmaste. A las migraciones les encanta shippear la URL correcta con el title de staging todavía en el template.

9. Confirma que Google puede indexar las URLs nuevas

Elige 10 a 20 money pages y pásalas por el Google Index Checker. No estás preguntando “¿ya terminamos?” el día uno. Preguntas “¿dejamos un noindex, un bloqueo de robots, un canonical apuntando hacia atrás o un bucle de redirección en las páginas que pagan las cuentas?”

URL Inspection en Search Console es la otra mitad. Usa ambos. A veces discrepan, y esa discrepancia es útil.

10. Mira los dos sitios a la vez

El tráfico del host viejo debería caer. El del nuevo, subir. Si ambos se quedan planos, no están pegando las redirecciones. Si el viejo sigue ocupado, algo todavía resuelve ahí — una variante de CDN, un subdominio olvidado, ads.

• Cobertura de índice / páginas en ambas propiedades
• El conteo indexado del sitemap nuevo subiendo
• Un spike de 404s o “crawled, currently not indexed” en el host nuevo
• Queries empezando a mostrar URLs nuevas

Mira en Search Console —

Los logs de servidor importan más que un screenshot del dashboard. Googlebot te va a pegar más duro después de un move. Si el servidor se cae, el crawl se frena y la migración solo se estira.

Dale tiempo. Google tiene que ver cada URL vieja y cada URL nueva al menos una vez. No hay SLA.

Los errores que siguen apareciendo

• Protecciones de staging dejadas encendidas. noindex en el header. Disallow: / en robots.txt. Un muro de basic-auth detrás del cual solo viven algunas URLs. Sigue siendo la forma número uno de que un launch “exitoso” se quede invisible.
• Redirecciones equivocadas. El mapa decía /pricing. El servidor mandó a /pricing-2 que 404. Crawl un sample. No confíes en el config que escribiste a la 1 a.m.
• Soft 404 vía homepage. Es tentador. También es cómo le enseñas a Google que las URLs viejas nunca tuvieron casa de verdad.
• Sitemap todavía listando el mundo viejo. O listando URLs nuevas que redirigen. Arregla el archivo, reenvía.
• Servidor insuficiente. Te mudaste. Googlebot trajo amigos. Avisa a hosting antes, no después de los 502.
• Move a HTTPS con restos mezclados. Un canonical todavía en http://, un hueco de HSTS, un enlace interno al scheme viejo. Trata HTTP a HTTPS como un move de URL de verdad, porque lo es.

Lo que este checklist no reemplaza

Un toolkit de navegador no va a renderizar cada ruta JavaScript en un sitio de 400k URLs ni a replayear un año de logs. Si ese es tu sitio, usa un crawler de escritorio para el grafo completo y los checks de arriba para lo que se rompe la noche del launch — códigos de estado, hops de redirección, robots, canonicals, higiene de sitemap, indexabilidad.

La guía de migración de Screaming Frog está bien. El checklist de Aleyda Solís también. Google incluso apunta a ambos. La diferencia aquí es que puedes correr el QA sin licencia y sin esperar a que termine un crawl.

Herramientas usadas en este workflow

• Comprobador de URL masivo — baseline y códigos de estado post-cutover
• Comprobador de cadenas de redirección — hops, bucles
• Robots.txt Tester — reglas de producción antes del go-live
• Bulk Meta Robots Checker — noindex olvidado, incluido X-Robots-Tag
• Canonical Checker — URLs nuevas autoreferenciadas
• Sitemap Auditor / XML Sitemap Validator
• Google Index Checker — sanity check de money pages
• SEO Content QA Checker — titles, descriptions, H1s después del rebuild