site-migration-seo-checklist-2026.html
< BACK Sala de control analógica vintage con diales iluminados en ámbar e indicadores parpadeantes, estética de grano de película de 35 mm

Mi Checklist de SEO para Migraciones de Sitios con 20,000 Páginas

Hace tres años me entregaron una migración que ya estaba en vivo. Sin ambiente de prueba. Sin mapa de redirecciones. Un catálogo de comercio electrónico de 22,000 páginas que alguien acababa de apuntar a un nuevo dominio y llamó "listo". El tráfico orgánico cayó 74% en seis semanas. El cliente me llamó en pánico moderado, y pasé la mejor parte de cuatro meses desenredándolo.

Punto clave: Las migraciones de sitios pierden posicionamiento por auditorías de redirecciones omitidas, no por cambios de plataforma; la lista de verificación incluye mapeo de redirecciones, transporte de metadatos, continuidad de esquema, y verificación posterior al lanzamiento.Site migrations lose rankings through skipped redirect audits, not platform changes; the checklist is redirect map, metadata transport, schema continuity, and post-launch verification.

Esa experiencia -- por dolorosa que fue -- es básicamente la razón por la que existe esta lista de verificación. Desde entonces he migrado sitios que van desde folletos de 800 páginas hasta un editor con 31,000 páginas y subdominios regionales, y los fundamentos son iguales cada vez. Cambia el orden, sáltate un paso, y Google te lo dirá en Search Console de la forma más desagradable posible.

Así que aquí está. El checklist actual que uso en Seahawk Media, no un marco teórico.Seahawk Media, not a theoretical framework.

---

1. Comienza con un Rastreo Completo Antes de Tocar Nada

¿Obvio? Sí. ¿Omitido? Constantemente.

Antes de que se mueva un solo archivo, rastro todo el sitio en vivo con Screaming Frog SEO Spider. En un sitio de 20,000 páginas esto toma un par de horas -- normalmente lo inicio por la noche con el rastreo guardado en modo base de datos para que la memoria no se convierta en un problema. Lo que estoy capturando:Screaming Frog SEO Spider. On a 20,000-page site this takes a couple of hours -- I usually kick it off overnight with the crawl stored to database mode so memory doesn't become an issue. What I'm capturing:

  • Cada URL indexable (la versión canónica, no ruido de paginación)
  • Códigos de respuesta en general -- 200s, 301s, 302s, 404s, todo
  • Estructura de enlaces internos existente
  • Etiquetas canónicas, atributos hreflang si aplica
  • Títulos de página y meta descripciones (para verificar que sobrevivan la migración)

Exporto el rastreo completo a CSV y lo conservo. Este es mi punto de referencia. Es el documento que compararé tres semanas después de que el nuevo sitio esté en vivo.

Muchas personas se saltan este paso porque "ya conocemos el sitio." No lo hacen. Pensé que conocía el sitio de un cliente de viajes en 2021 -- resultó que tenían 4,000 URLs que se estaban sirviendo desde un subdirectorio de CMS heredado que nadie había mencionado en el brief. Lo encontré en el rastreo. Habría sido un desastre.

No olvides los propios datos de Google

Extrae todo de Google Search Console -- datos de rendimiento de los últimos 16 meses como mínimo, el informe de cobertura de índice, cualquier acción manual, todos los sitemaps. Y extrae de Google Analytics (GA4 ahora, obviamente) para que tengas tus puntos de referencia de tráfico orgánico bloqueados antes de que nada cambie. Las capturas de pantalla funcionan bien aquí; también exporto los CSVs sin procesar.Google Search Console -- performance data for the last 16 months minimum, the index coverage report, any manual actions, all sitemaps. And pull from Google Analytics (GA4 now, obviously) so you have your organic traffic benchmarks locked down before anything changes. Screenshots work fine here; I also export the raw CSVs.

---

2. Construye el Mapa de Redirecciones. Luego Verifica de Nuevo.

Aquí es donde las migraciones triunfan o fracasan. En sitios grandes, el mapa de redirecciones es una hoja de cálculo real -- normalmente compartida en Google Sheets con el cliente, su equipo de desarrollo, y cualquier otra persona que podría sobrescribir una fórmula accidentalmente a las 11pm.

La estructura es simple:

  1. Columna A: URL Anterior (exacta, incluyendo barra diagonal final o su ausencia)
  2. Columna B: URL Nueva (exacta)
  3. Columna C: Tipo de redirección (301 en casi todos los casos)
  4. Columna D: Estado (mapeado, verificado, en vivo)
  5. Columna E: Notas (redirecciones generales, consolidaciones de categorías, descartes intencionales)

En un sitio de 20,000 páginas obviamente no puedes mapear cada URL individualmente. Aquí está el orden en que trabajo:

  1. Mapea primero todas las URLs con mejor rendimiento (por tráfico orgánico de GSC -- los 500 principales generalmente impulsan más del 80% del tráfico)
  2. Mapea páginas de categoría y taxonomía
  3. Mapea cualquier URL que tenga backlinks significativos (usa Ahrefs para esto -- filtra por dominios de referencia, no solo enlaces sin procesar)Ahrefs for this -- filter by referring domains, not just raw links)
  4. Maneja redirecciones basadas en patrones para todo lo demás (por ejemplo, /product/old-slug/ → /shop/old-slug/)/product/old-slug//shop/old-slug/)
  5. Documenta 410s intencionales para páginas que estás retirando

Las redirecciones basadas en patrones son lo que la mayoría de desarrolladores junior hacen mal. Escribirán una regla con comodín demasiado amplia y accidentalmente redirigirán URLs que no tenían intención de redirigir. Prueba cada regla de patrón en staging antes de que vaya cerca de producción.

---

3. Staging No Es Opcional

Voy a mantener esto breve porque no debería necesitar mucha explicación. Cada migración obtiene un entorno de staging. Punto.

Seahawk tuvo un cliente fintech en 2022 que se resistió a esto -- quería "simplemente hacerlo en vivo porque el sitio es pequeño." El sitio tenía 6,000 páginas. Lo hicimos en staging. Encontramos un conflicto de plugin que estaba eliminando etiquetas canónicas de todas las páginas de productos. Habría sido invisible hasta que Google volviera a rastrear todo, lo que en un dominio de baja autoridad puede tomar semanas.

En staging estás verificando:

  • Todos los redirects se ejecutan correctamente (uso Screaming Frog de nuevo, apuntado a staging, para verificar el mapa de redirects en lote)
  • Robots.txt está bloqueando el entorno de staging de la indexación (importante -- usar Disallow: / pero también agregar un header noindex para doble protección)Disallow: /but also add a noindex header for double protection)
  • El nuevo sitemap es preciso y no contiene URLs de staging
  • Las etiquetas canónicas apuntan a las URLs de producción correctas
  • Baselines de velocidad de página con PageSpeed Insights -- las migraciones se usan frecuentemente como oportunidades de rediseño, y los rediseños destruyen regularmente Core Web VitalsPageSpeed Insights -- migrations are often used as redesign opportunities, and redesigns frequently destroy Core Web Vitals

---

4. La Secuencia de Go-Live (El Orden Importa Más de Lo Que Crees)

Esta es la parte donde la gente improvisa y se causa problemas a sí misma. Hay un orden específico. No me desvío de él.

Paso 1: Previa al lanzamiento (48 horas antes)

  • Reduce el TTL en todos los registros DNS a 300 segundos (5 minutos). Acelera significativamente la propagación.
  • Briefea al cliente: sin cambios de contenido, sin nuevas páginas, sin actualizaciones de plugins durante la ventana de migración.
  • Notifica a cualquier integración de terceros (CDNs, plataformas publicitarias, herramientas de monitoreo) sobre el cambio próximo.

Paso 2: Ventana de lanzamiento

  • Actualiza el DNS
  • Desplegar redirects antes de que el contenido nuevo esté completamente propagado -- los redirects deben estar activos a nivel de servidor, no solo en WordPressWordPress
  • Habilita el nuevo sitemap, desactiva el antiguo
  • Verifica que robots.txt sea correcto (archivo de producción, no el de staging)

Paso 3: Inmediatamente después del lanzamiento

  • Rastrear el nuevo sitio dentro de dos horas. Screaming Frog, apuntando a producción, respetando redirecciones. Busco 404s inesperados, cadenas de redirecciones más largas de dos saltos, y cualquier página que debería ser indexable mostrando una etiqueta noindex.
  • Enviar el nuevo sitemap en Search Console
  • Obtener la página de inicio a través de la herramienta URL Inspection de GSC para solicitar a Googlebot que la visite

Una cosa que siempre señalo a los clientes: Google no reflejará inmediatamente las nuevas URLs en los resultados de búsqueda. Hay un lag de rastreo y reprocesamiento. En un sitio grande, presupuesta dos a seis semanas antes de tener una imagen clara. Entrar en pánico el día cuatro porque los rankings cambiaron es normal -- no significa que algo esté roto.

---

5. Auditoría de Cadenas de Redirecciones (El Paso que la Mayoría de Agencias Facturan por Separado)

Las cadenas de redirecciones son un sangrado lento. Una URL que va A → B → C → D está haciendo que Googlebot haga trabajo extra, y también está diluyendo el equity de enlaces a través de múltiples saltos. En un sitio que ha tenido múltiples migraciones previas o cambios de plataforma, las cadenas pueden ser sorprendentemente profundas.

Post-lanzamiento, exporto el rastreo completo de Screaming Frog y filtro por cadenas de redirecciones. Cualquier cosa más allá de dos saltos se colapsa. Si la URL original estaba en el mapa de redirecciones, la actualizo para que apunte directamente al destino final. Si era una cadena heredada de una migración que nadie documentó, la agrego.

Este paso solo -- en un cliente que migramos de Magento a WooCommerce a principios de 2023 -- tomó dos días. Habían tenido tres migraciones en ocho años. Algunas URLs pasaban por cinco redirects antes de llegar a la página correcta. Las colapsamos todas, y las métricas de crawl budget en Search Console mejoraron notablemente en un mes.

---

6. Verificación de Contenido a Escala

No puedes revisar manualmente 20,000 páginas. Pero puedes verificar sistemáticamente lo que importa.

Esto es lo que verifico en las primeras dos semanas después del lanzamiento:

  • Etiquetas de título y meta descripciones: Compara una muestra aleatoria de 200 páginas contra la exportación de Screaming Frog previa a la migración. Los desajustes se marcan inmediatamente.: Compare a random 200-page sample against the pre-migration Screaming Frog export. Mismatches get flagged immediately.
  • Datos estructurados: Ejecuta una muestra de páginas de productos, páginas de artículos y la página de inicio a través de Google's Rich Results Test. Las migraciones rompen el markup de esquema más frecuentemente de lo que piensas, especialmente si el tema nuevo usa un plugin diferente.: Run a sample of product pages, article pages, and the homepage through Google's Rich Results Test. Migrations break schema markup more often than you'd think, especially if the new theme uses a different plugin.
  • Enlaces internos: Rastreo de Screaming Frog, filtra por inlinks. Las páginas de alto valor deben mantener recuentos sólidos de enlaces internos. Si una página de categoría que previamente tenía 400 enlaces internos ahora tiene 12, algo salió mal en la plantilla.: Screaming Frog crawl, filter for inlinks. High-value pages should still have strong internal link counts. If a category page that previously had 400 internal links now has 12, something went wrong in the template.
  • Imágenes y texto alternativo: No es estrictamente crítico para SEO, pero las imágenes rotas afectan las señales de experiencia del usuario y son fáciles de pasar por alto en sitios basados en plantillas.: Not strictly SEO-critical, but broken images hurt user experience signals and they're easy to miss on templated sites.

---

7. Monitoreo para los 90 Días Posteriores

La migración no termina el día del lanzamiento. Se extiende por un mínimo de 90 días.

Establecí cadencias de reporte semanales con el cliente durante el primer mes, luego quincenales después. Esto es lo que estoy monitoreando:

  • GSC Index Coverage: ¿Se está recuperando el número de páginas indexadas hacia el conteo anterior a la migración? Una caída significativa que persiste más allá de tres semanas necesita investigación.: Is the number of indexed pages recovering toward the pre-migration count? A significant drop that persists beyond three weeks needs investigation.
  • Tráfico orgánico vs. baseline: Segmentado por tipo de página de aterrizaje (producto, categoría, blog). Las caídas de tráfico suelen ser desiguales -- a veces las páginas de categoría se desploman mientras las páginas de producto se mantienen.: Segmented by landing page type (product, category, blog). Traffic drops are often uneven -- sometimes category pages tank while product pages hold.
  • Crawl budget: El reporte de estadísticas de crawl de GSC muestra el promedio de páginas rastreadas por día y los tiempos de respuesta del servidor. Si Googlebot está recibiendo muchos 404s, se ve aquí.: GSC's crawl stats report shows average pages crawled per day and server response times. If Googlebot is hitting a lot of 404s, it shows here.
  • Seguimiento de posición de ranking: Uso una combinación del rank tracking de Ahrefs y el reporte de desempeño de Google Search Console. La volatilidad de rankings en las primeras dos a tres semanas es común y no es necesariamente un problema. Las caídas sostenidas más allá de la semana cuatro justifican una acción.: I use a combination of Ahrefs rank tracking and Google Search Console's performance report. Ranking volatility in the first two to three weeks is common and not necessarily a problem. Sustained drops beyond week four warrant action.
  • Perfil de backlinks: Usando Ahrefs, verifica que los backlinks de alto valor que apunten a URLs antiguas estén ya redirigidos correctamente o marcados para contacto y actualización.: Using Ahrefs, verify that high-value backlinks pointing to old URLs are either already redirected correctly or flagged for outreach to update.

¿La verdad honesta? La mayoría de los problemas SEO en migraciones son detectables dentro de 30 días si estás monitoreando las métricas correctas. Los que sorprenden a la gente son aquellos donde nadie configuró el monitoreo y el cliente se da cuenta ocho meses después.

---

8. Las Cosas en las que He Fallado (Para que Tú No Tengas Que Hacerlo)

Allá por 2019, me perdí una implementación de hreflang en una migración para un cliente con subcarpetas de Reino Unido, Australia y Canadá. Las etiquetas canónicas eran correctas. Los redirects estaban bien. Pero las anotaciones hreflang en el sitio nuevo tenían los códigos de región incorrectos -- en-au en lugar de en-AU (las mayúsculas importan, aparentemente, en algunas implementaciones). Google empezó a servir páginas del Reino Unido a buscadores australianos. Nos tomó seis semanas averiguar por qué el tráfico orgánico australiano se había reducido a la mitad. Hemos tenido un paso de validación de hreflang en cada migración internacional desde entonces.en-au instead of en-AU(case matters, apparently, in some implementations). Google started serving the UK pages to Australian searchers. Took us six weeks to figure out why Australian organic traffic had halved. We've had a hreflang validation step in every international migration since.

Otro más: sitemaps XML que contienen URLs con noindex. Suena como una inconsistencia menor pero envía señales conflictivas y definitivamente vale la pena limpiar. Screaming Frog puede auditar tu sitemap e identificar cualquier URL que devuelva una etiqueta noindex.

Y probablemente la lección más cara: no tener un plan de reversión. En una migración que está saliendo mal, la capacidad de cambiar el DNS de vuelta al servidor antiguo en una hora vale su peso en oro. Siempre insisto en que el entorno antiguo siga activo e intacto durante al menos 30 días después de la migración. Los clientes a veces se quejan del costo del hosting. Les explico cuánto cuesta en ingresos una caída del 70% en tráfico y dejan de quejarse.

---

FAQ

¿Cuánto tiempo toma realmente planificar una migración de sitio de 20,000 páginas?

¿Realísticamente? Seis a diez semanas de preparación antes de la fecha de lanzamiento. Solo el mapa de redirecciones en un sitio de ese tamaño puede tomar dos a tres semanas construirlo correctamente, especialmente si estás auditando backlinks para cada URL. Apresurarse en la preparación es cómo terminas gastando meses en recuperación.

¿Necesito enviar un archivo disavow después de una migración?

Usualmente no, a menos que el dominio antiguo tuviera enlaces tóxicos y estés migrando específicamente para escapar de ellos. Si estás migrando a un nuevo dominio y quieres un perfil de enlaces limpio, maneja el disavow en la propiedad nueva en GSC. Pero para la mayoría de migraciones de plataforma o rediseño en el mismo dominio, disavow es irrelevante.

¿Cuál es el error más grande que ves que cometen las agencias en migraciones grandes?

Tratar el mapa de redirect como una tarea de desarrollo. Los redirects son una tarea de SEO que un desarrollador implementa. El equipo de SEO -- o quien sea dueño de la estrategia de búsqueda -- debe ser dueño del mapa, revisarlo y aprobarlo. He visto desarrolladores construir reglas de redirect técnicamente correctas que eran SEO-incorrectas porque nadie les dijo cuál era la variante de URL canónica.

¿La velocidad del sitio afecta el SEO en migraciones?

Sí, más de lo que la mayoría de las personas consideran. Core Web Vitals son un factor de ranking, y los rediseños -- que frecuentemente acompañan las migraciones -- a menudo introducen JavaScript más pesado o imágenes no optimizadas. Siempre ejecuta una comparación de PageSpeed Insights entre el sitio antiguo y nuevo antes del lanzamiento. Si el sitio nuevo es significativamente más lento en mobile, corrígelo antes de cambiar el switch.

¿Cómo manejas las migraciones para sitios con mucho contenido generado por usuarios?

Con cuidado. Las páginas de UGC son frecuentemente de baja calidad individualmente pero en conjunto generan tráfico de cola larga. Generalmente recomiendo un paso de rastreo y análisis: identifica qué URLs de UGC tienen algo de tráfico orgánico, redirige esas específicamente, y usa 410 para el resto en lugar de dejarlas como 404s. Un 410 le dice a Google que la página se ha eliminado intencionalmente; un 404 es ambiguo.

---

Las migraciones son una de esas cosas donde la diferencia entre bien y catastrófico está casi enteramente en la preparación. La implementación técnica es normalmente la parte fácil. Hacer bien el trabajo previo al lanzamiento -- el rastreo, el mapa de redirects, la verificación de staging -- es donde ocurre el trabajo real. Y si alguna vez te entregan una migración que ya está en vivo y ya está rota, la checklist sigue siendo válida. Solo la estás haciendo al revés.

< BACK