Tu deploy termina a las 9 AM. Al mediodía, el bot de Google rastrea tu página principal e intenta acceder a /blog/product-launch-2023 y encuentra un 404. Esa URL estaba en posición #3 para "SaaS launch checklist" y generaba 340 visitas al mes. Ahora ha desaparecido — sin redirección, sin aviso, sin tráfico. Esto sucede porque los equipos tratan las migraciones de CMS como actualizaciones de infraestructura cuando en realidad son proyectos de preservación de SEO. La diferencia es importante: una mentalidad lanza rápido y observa cómo caen las posiciones; la otra mapea cada URL, verifica la paridad de contenido y monitorea errores de rastreo durante 72 horas después del lanzamiento. Hemos migrado más de 40 sitios sin perder más del 3% del tráfico orgánico. El proceso no es complicado, pero la secuencia es implacable. Si te saltas la auditoría de redirecciones, pasarás meses recuperando posiciones que podrías haber mantenido.

Durante los últimos siete años, he dirigido o supervisado personalmente migraciones desde WordPress a configuraciones headless, de Drupal a Sanity, de sitios legacy en .NET a Next.js, y todo lo intermedio. Algunas fueron impecables. Un par fueron desastres que heredé y tuve que corregir. Esta guía contiene todo lo que he aprendido de ambos lados de esa moneda.

Las apuestas son reales. Según un estudio de Ahrefs de 2024, el 34% de los sitios que experimentan una migración de CMS sufren una caída de tráfico mayor al 20% que tarda más de seis meses en recuperarse. Pero aquí está el detalle -- no tiene por qué ser así. Con el proceso correcto, puedes migrar tu CMS y salir del otro lado con tus posiciones intactas, a veces incluso mejoradas.

Tabla de Contenidos

Migración de CMS Sin Perder Posiciones en SEO: Una Guía Completa

Por Qué las Migraciones de CMS Matan el SEO (Cuando Salen Mal)

Google no se preocupa por qué CMS uses. Le importan las URLs, el contenido, la velocidad de página, los enlaces internos y miles de señales que ha acumulado sobre tu sitio durante años. Cuando arrancas todo eso y lo reemplazas con algo nuevo, esencialmente le estás pidiendo a Google que reevalúe tu sitio completo desde cero.

Aquí está lo que típicamente sale mal:

  • Las estructuras de URL cambian sin redirecciones adecuadas (esto por sí solo representa aproximadamente el 70% de las caídas de tráfico post-migración)
  • El contenido se modifica, se trunca o se reorganiza de maneras que cambian las señales de relevancia temática
  • Los enlaces internos se rompen porque el nuevo CMS genera patrones de URL diferentes
  • La velocidad de página se degrada porque nadie probó el rendimiento de la nueva plantilla
  • Los metadatos se pierden -- títulos, descripciones, etiquetas canónicas, atributos hreflang
  • Los datos estructurados desaparecen porque el CMS antiguo tenía plugins que los generaban automáticamente

¿Lo peor? Estos problemas se componen. Una sola cadena de redirección rota puede propagarse a través de cientos de páginas.

La Auditoría Pre-Migración: Tu Red de Seguridad

Antes de tocar una sola línea de código en el nuevo CMS, necesitas una captura completa de tu estado actual de SEO. Piénsalo como un punto de guardado en un videojuego -- necesitas algo contra qué comparar.

Qué Rastrear y Exportar

Usa Screaming Frog, Sitebulb o Ahrefs Site Audit para rastrear tu sitio existente completo. Exporta todo:

# Puntos de datos clave a capturar:
- Todas las URLs (cada una, incluyendo páginas paginadas)
- Códigos de estado HTTP
- Títulos de página
- Metadescripciones
- Etiquetas H1
- Etiquetas canónicas
- Etiquetas hreflang (si es multilingüe)
- Enlaces internos (origen y destino)
- Recuento de palabras por página
- Tipos de schema por página
- URLs de imágenes y texto alternativo
- Tiempos de respuesta
- Puntuaciones de Core Web Vitals

Establece tu Línea Base de Posiciones

Obtén datos de posiciones de Google Search Console de los últimos 16 meses. Expórtalos. También obtén datos de cualquier herramienta de terceros que uses -- Ahrefs, SEMrush, Moz. Quieres:

  • Primeras 500 páginas por tráfico orgánico
  • Primeras 1000 palabras clave por clics
  • Todas las páginas que ocupen posición 1 para cualquier palabra clave
  • Páginas con fragmentos destacados
  • Páginas con resultados enriquecidos

Guarda todo esto en una hoja de cálculo o base de datos que puedas consultar post-migración. Típicamente uso una hoja de Google con pestañas para cada conjunto de datos, pero para sitios más grandes (10k+ páginas), configuraré una base de datos PostgreSQL rápida.

Identifica Tus Páginas Clave

No todas las páginas son iguales. Una migración que preserva perfectamente el 95% de tus páginas pero rompe las 20 principales que generan ingresos sigue siendo un desastre. Identifica páginas por:

  1. Volumen de tráfico orgánico
  2. Tasa de conversión
  3. Atribución de ingresos
  4. Conteo de enlaces de retroceso (estos transfieren autoridad)
  5. Posición de clasificación para palabras clave de alto valor

Estas páginas reciben tratamiento de lujo durante la migración.

Estructura de URLs: El Factor Más Importante

Voy a decir algo que podría sonar extremo: si puedes mantener la misma estructura de URL exacta, deberías hacerlo. Incluso si las URLs antiguas son feas. Incluso si tienen fechas. Incluso si usan parámetros de consulta.

Cada cambio de URL es un riesgo. Punto.

Cuándo los Cambios de URL Son Inevitables

A veces tienes que cambiar URLs. Quizás estés consolidando subdominios, cambiando de HTTP a HTTPS (aunque eso debería haber sucedido hace años), o tu CMS antiguo generó URLs como /index.php?id=4523&cat=7.

Si debes cambiar URLs, aquí está la jerarquía de riesgo:

Tipo de Cambio Nivel de Riesgo Ejemplo
Cambio de dominio Muy Alto oldsite.com → newsite.com
Cambio de protocolo Medio http → https
Cambio de subdominio Alto blog.site.com → site.com/blog
Reestructuración de ruta Medio-Alto /2024/01/post-name → /blog/post-name
Cambio de slug Medio /old-slug → /new-slug
Parámetro a ruta Medio /?p=123 → /actual-slug
Cambio de barra diagonal final Bajo /page → /page/

Hoja de Cálculo de Mapeo de URLs

Crea un documento de mapeo con estas columnas:

| URL Antigua | URL Nueva | Código de Estado | Prioridad | Notas |
|---------|---------|-------------|----------|-------|
| /old-page | /new-page | 301 | Alta | Top 10 por tráfico |
| /removed-page | /relevant-page | 301 | Media | Contenido fusionado |
| /still-exists | /still-exists | 200 | Baja | Sin cambios necesarios |

Para un sitio de 500 páginas, esto toma aproximadamente 2-3 días de trabajo enfocado. Para un sitio de 10,000 páginas, necesitarás patrones regex y scripts de mapeo automatizados. Hemos construido herramientas de migración personalizadas exactamente para esto cuando trabajamos en proyectos de desarrollo de CMS headless.

Migración de CMS Sin Perder Posiciones en SEO: Una Guía Completa - arquitectura

Mapeo de Redirecciones: El Trabajo Tedioso Que Lo Salva Todo

Las redirecciones son tu red de seguridad. Cada URL antigua que cambia debe redirigir con 301 a su equivalente nuevo. No a la página principal. No a una página de categoría. Al contenido equivalente real.

Reglas para Redirecciones

  1. Siempre usa redirecciones 301 (permanentes), no 302 (temporales). Google las trata diferente para la transferencia de equidad de enlaces.
  2. Evita cadenas de redirecciones. Si A redirige a B y B redirige a C, eso es una cadena. Cada salto pierde equidad (Google dice que no, pero datos empíricos de estudios 2024 de Cyrus Shepard y otros sugieren lo contrario).
  3. Nunca redirijas todo a la página principal. Esto se llama "soft 404" y Google eventualmente tratará esas URLs como realmente desaparecidas.
  4. Mapea 1:1 cuando sea posible. URL antigua → página nueva equivalente.
  5. Maneja el contenido eliminado adecuadamente. Si una página no tiene equivalente, encuentra la página temáticamente relevante más cercana o devuelve un estado 410 (Gone) adecuado.

Implementación en Diferentes Entornos

Para Next.js (que usamos extensamente en nuestro trabajo de desarrollo Next.js):

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
      {
        source: '/category/:cat/post/:id',
        destination: '/blog/:id',
        permanent: true,
      },
      // Para listas de redirección grandes, importa de un archivo JSON
      ...require('./redirects.json'),
    ]
  },
}

Para Nginx:

# Redirecciones individuales
rewrite ^/old-page$ /new-page permanent;

# Redirecciones basadas en patrones
rewrite ^/blog/(\d{4})/(\d{2})/(.*)$ /blog/$3 permanent;

# Redirecciones basadas en mapas para listas grandes
map $request_uri $new_uri {
    include /etc/nginx/redirects.map;
}

server {
    if ($new_uri) {
        return 301 $new_uri;
    }
}

Para hosting basado en Vercel/edge:

// vercel.json
{
  "redirects": [
    {
      "source": "/old-path/:match*",
      "destination": "/new-path/:match*",
      "permanent": true
    }
  ]
}

Prueba de Redirecciones Antes del Lanzamiento

Esto es innegociable. He visto equipos escribir 3,000 reglas de redirección e implementarlas sin probar. No seas ese equipo.

# Script bash simple para probar redirecciones
while IFS=, read -r old_url expected_url; do
    actual_url=$(curl -Ls -o /dev/null -w %{url_effective} "$old_url")
    if [ "$actual_url" != "$expected_url" ]; then
        echo "FALLO: $old_url -> $actual_url (se esperaba $expected_url)"
    fi
done < redirect_test_urls.csv

Paridad de Contenido: Más Que Solo Copiar y Pegar

Cuando digo "paridad de contenido," no solo me refiero a que el texto del cuerpo coincida. Quiero decir que toda la experiencia de contenido debe ser equivalente o mejor.

Qué Cuenta Como Contenido Para Google

  • Texto del cuerpo principal
  • Encabezados (jerarquía H1-H6)
  • Imágenes con texto alternativo
  • Videos e incrustaciones
  • Tablas
  • Listas
  • Información del autor (señales E-E-A-T)
  • Fechas de publicación y actualización
  • Comentarios (sí, Google los indexa)
  • Enlaces de contenido relacionado

Errores Comunes de Paridad de Contenido

Soltar el contenido de la barra lateral. Tu sitio antiguo tenía una barra lateral con artículos relacionados, publicaciones populares o enlaces contextuales. Tu nuevo diseño es de ancho completo y limpio. Esos enlaces eran parte de tu arquitectura de enlaces internos. Acaban de romperla.

Cambiar la jerarquía de encabezados. Si tu página antigua tenía un H1 de "Best React Frameworks in 2026" y tu nueva plantilla de CMS lo cambia a "React Frameworks" porque alguien quería títulos más limpios, has cambiado una señal de clasificación.

Perder texto alternativo de imagen. La mayoría de herramientas de migración de CMS importan imágenes pero eliminan el texto alternativo. Verifica esto manualmente para al menos tus 100 páginas principales.

Fusionar o dividir contenido. Si combinas dos páginas en una, debes redirigir la URL secundaria a la página combinada. Si divides una página en varias, la URL original debe redirigir a la nueva página más relevante, y probablemente verás fluctuación temporal en la clasificación.

Lista de Verificación de SEO Técnico para el Día de Migración

Aquí está la lista de verificación que uso el día de migración. Imprímela. Pégala en tu monitor.

## Pre-Lanzamiento (Día de)
- [ ] Todas las redirecciones probadas y confirmadas funcionando
- [ ] Mapa del sitio XML actualizado con nuevas URLs
- [ ] Mapa del sitio antiguo eliminado o redirigido
- [ ] robots.txt verificado (NO bloqueando el sitio nuevo)
- [ ] Etiquetas canónicas apuntando a las URL nuevas correctas
- [ ] Etiquetas hreflang actualizadas (si es multilingüe)
- [ ] Certificado SSL válido en todos los dominios/subdominios
- [ ] Caché de CDN purgado
- [ ] TTL de DNS reducido 48 horas antes

## Post-Lanzamiento (Dentro de 1 Hora)
- [ ] Rastrear el sitio nuevo con Screaming Frog
- [ ] Enviar nuevo mapa del sitio en Google Search Console
- [ ] Solicitar indexación para las 20 principales páginas clave
- [ ] Verificar que no haya etiquetas noindex accidentales
- [ ] Verificar que robots.txt sea accesible
- [ ] Probar 50 redirecciones aleatorias manualmente
- [ ] Verificar datos estructurados en Prueba de Resultados Enriquecidos
- [ ] Comprobar Core Web Vitals en páginas principales

## Post-Lanzamiento (Dentro de 24 Horas)
- [ ] Monitorear Google Search Console para errores de rastreo
- [ ] Comprobar picos de 404 en registros del servidor
- [ ] Verificar que Google Analytics/seguimiento de etiquetas se activa en todas las páginas
- [ ] Comparar recuento de páginas indexadas (site:tudominio.com)
- [ ] Probar todos los formularios y rutas de conversión

Migración de Metadatos, Schema y Datos Estructurados

Aquí es donde muchas migraciones de WordPress a headless se desmoronan. Los sitios WordPress a menudo dependen de Yoast SEO o Rank Math para generar automáticamente etiquetas meta, datos Open Graph y marcado schema. Cuando te cambias a un CMS headless como Sanity, Contentful o Storyblok, esa automatización desaparece.

Qué Necesitas Preservar

Elemento Dónde Vive (WordPress) Dónde Va (Headless)
Etiqueta de título Plugin Yoast SEO Gestión de encabezado del framework frontend
Metadescripción Plugin Yoast SEO Campo de frontend framework o CMS
Imagen OG Yoast/auto-generada Campo CMS + renderizado frontend
Schema JSON-LD Plugin-generado Código personalizado en frontend
Schema de migajas Plugin-generado Implementación a nivel de componente
Schema de FAQ Plugin o manual Contenido estructurado de CMS + frontend
URL canónica Auto-generada Implementación explícita requerida

Para compilaciones basadas en Astro, típicamente manejamos esto con un componente SEO dedicado:

---
// src/components/SEOHead.astro
const { title, description, canonical, ogImage, schema } = Astro.props;
---
<title>{title}</title>
<meta name="description" content={description} />
<link rel="canonical" href={canonical} />
<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:image" content={ogImage} />
{schema && (
  <script type="application/ld+json" set:html={JSON.stringify(schema)} />
)}

Preservación de Enlaces Internos

Los enlaces internos son el sistema circulatorio de tu SEO. Distribuyen la autoridad de la página, señalan relaciones de contenido a Google, y ayudan con la rastreabilidad.

Durante una migración, los enlaces internos se rompen de dos maneras:

  1. Enlaces codificados en contenido que apuntan a URLs antiguas
  2. Enlaces programáticos (navegación, pies de página, barras laterales, publicaciones relacionadas) que el nuevo CMS genera de manera diferente

Reparación de Enlaces de Contenido

Antes de la migración, ejecuta un script para encontrar y reemplazar todos los enlaces internos en tu contenido:

import re

def update_internal_links(content, redirect_map):
    """Reemplaza URLs internas antiguas con nuevas en el contenido."""
    for old_url, new_url in redirect_map.items():
        # Coincide con URLs absolutas y relativas
        content = content.replace(f'href="{old_url}"', f'href="{new_url}"')
        content = content.replace(
            f'href="https://tudominio.com{old_url}"',
            f'href="https://tudominio.com{new_url}"'
        )
    return content

No solo confíes en redirecciones para enlaces internos. Sí, las redirecciones funcionarán, pero cada salto de redirección añade latencia y (argumentablemente) diluye la equidad de enlaces. Corrige los enlaces en la fuente.

Rendimiento y Core Web Vitals

Una migración de CMS es tu oportunidad para hacer una mejora masiva de rendimiento, o para absolutamente destruir tus Core Web Vitals.

El algoritmo de clasificación de Google de 2026 continúa usando Core Web Vitals como una señal de clasificación. Los umbrales no han cambiado:

Métrica Bueno Necesita Mejora Pobre
LCP (Largest Contentful Paint) ≤ 2.5s 2.5s - 4.0s > 4.0s
INP (Interaction to Next Paint) ≤ 200ms 200ms - 500ms > 500ms
CLS (Cumulative Layout Shift) ≤ 0.1 0.1 - 0.25 > 0.25

Si tu sitio WordPress antiguo tenía un LCP de 3.8s y tu nuevo sitio Next.js llega a 1.2s, ese es un impulso de clasificación genuino esperando suceder. Pero si tu nuevo sitio está cargando un paquete JavaScript de 2MB y tu LCP salta a 5s, acabs de crear un nuevo problema además de la migración.

Prueba tu sitio de staging a fondo con Lighthouse, WebPageTest y Chrome UX Report antes de lanzarte.

Protocolo de Monitoreo Post-Migración

Los 30 días después de la migración son críticos. Aquí está el calendario de monitoreo que sigo:

Semana 1: Monitoreo Diario

  • Google Search Console: Estadísticas de rastreo, informe de cobertura, rendimiento
  • Registros del servidor: Errores 404, errores 500, bucles de redirección
  • Rastreador de posiciones: Top 50 palabras clave
  • Tráfico orgánico: Comparación día a día con el año anterior

Semanas 2-4: Monitoreo Semanal

  • Comparación de rastreo completo del sitio contra línea base pre-migración
  • Conteo de páginas indexadas tendencia
  • Adquisición de nuevos enlaces de retroceso (enlaces rotos desde sitios externos)
  • Comparación de tasa de conversión

Meses 2-3: Monitoreo Quincenal

  • Estabilidad de clasificación para palabras clave de cola larga
  • Nuevas apariciones de palabras clave
  • Datos de Core Web Vitals del campo (toma ~28 días para poblarse)

Una fluctuación temporal en la clasificación en las primeras 2-4 semanas es normal. Google está re-rastreando y re-evaluando tu sitio. Si has hecho todo bien, las clasificaciones deben estabilizarse y volver a la línea base dentro de 4-6 semanas. Si no se han recuperado después de 8 semanas, algo salió mal.

Migraciones a CMS Headless: Consideraciones Especiales

La migración a una arquitectura de CMS headless introduce desafíos únicos que las migraciones tradicionales de CMS a CMS no tienen.

La Renderización en el Servidor Es Innegociable

Si tu frontend headless renderiza todo del lado del cliente (estilo SPA), Google tendrá más dificultades para indexar tu contenido. Google puede renderizar JavaScript, pero es más lento e improbable que rastrear HTML renderizado por servidor.

Usa SSR o SSG. Punto. Frameworks como Next.js (App Router con componentes del servidor) y Astro (server-first por defecto) hacen esto sencillo.

Diferencias en Modelado de Contenido

Los CMS tradicionales almacenan contenido como blobs HTML. Los CMS headless como Sanity usan contenido estructurado (Portable Text, bloques). Durante la migración, necesitas:

  1. Analizar contenido HTML antiguo en bloques estructurados
  2. Preservar significado semántico (encabezados, listas, énfasis)
  3. Manejar medios incrustados (imágenes, videos, iframes)
  4. Convertir enlaces internos
  5. Preservar cualquier schema en línea o formato especial

Este es genuinamente trabajo duro, y es donde gastamos una cantidad significativa de tiempo en nuestros proyectos de desarrollo de CMS headless. Las herramientas automatizadas te llevan al 80% del camino. El último 20% es revisión manual y limpieza.

Flujos de Trabajo de Vista Previa y Staging

Antes de cambiar el interruptor, tu nueva configuración headless necesita un entorno de staging que refleje producción. Esto significa:

  • Mismas reglas de redirección
  • Misma configuración de CDN
  • Mismo comportamiento de renderización
  • Contenido real (no lorem ipsum)

Rastra el entorno de staging con Screaming Frog y compáralo contra tu línea base pre-migración. Cada discrepancia es una posible pérdida de clasificación.

Plan de Recuperación: Qué Hacer Si las Posiciones Caen

A pesar de los mejores esfuerzos, a veces las cosas se salen de control. Aquí está el proceso de triaje:

  1. Verifica bloques de rastreo. ¿Está robots.txt bloqueando a Googlebot? ¿Hay etiquetas noindex accidentales? Este es el #1 error post-migración.
  2. Verifica que las redirecciones funcionen. Comprueba aleatoriamente 100 URLs antiguas. ¿Se están redirigiendo correctamente con 301?
  3. Busca cadenas de redirección y bucles. Estos son asesinos silenciosos.
  4. Compara contenido. Abre tus 20 páginas principales en Wayback Machine y compara con las actuales. ¿Falta contenido?
  5. Revisa etiquetas canónicas. ¿Apuntan a las URLs correctas? ¿Canónicas auto-referenciadas en cada página?
  6. Audita datos estructurados. Usa la Prueba de Resultados Enriquecidos de Google en tus páginas principales.
  7. Revisa Core Web Vitals. ¿Se degradó el rendimiento?
  8. Envía una solicitud de reconsideración o re-indexación para páginas críticas en Search Console.

Si has identificado el problema y lo has arreglado, Google típicamente re-evalúa dentro de 1-3 semanas. Para caídas severas, la recuperación puede tomar 2-4 meses.

¿Necesitas ayuda con una migración que ha salido mal, o quieres hacerlo bien la primera vez? Hemos manejado docenas de estas -- ponte en contacto para discutir tu situación específica.

Preguntas Frecuentes

¿Cuánto tiempo toma una migración de CMS sin perder posiciones de SEO? Para un sitio con menos de 1,000 páginas, planifica 4-8 semanas de preparación, migración y estabilización. Sitios más grandes (10k+ páginas) pueden tomar 3-6 meses. El cambio real podría suceder en un día, pero la planificación y el monitoreo post-migración toman la mayor parte del tiempo. Apresurarse en la fase de preparación es cómo se pierden las posiciones.

¿Perderé posiciones temporalmente durante una migración de CMS? Alguna fluctuación en las primeras 2-4 semanas es normal y esperada. Google necesita re-rastrear tu sitio, procesar las redirecciones y re-indexar páginas. Si has implementado correctamente redirecciones 301 y mantenido la paridad de contenido, deberías ver que las posiciones vuelven a la línea base dentro de 4-6 semanas. Caídas importantes que persisten más allá de 8 semanas indican un problema que necesita investigación.

¿Debería cambiar mi estructura de URL durante una migración de CMS? Solo si absolutamente tienes que hacerlo. Cada cambio de URL es un riesgo para tus posiciones. Si tus URLs actuales son funcionales (incluso si son feas), mantenlas. Si debes cambiar URLs por razones técnicas, asegúrate de que cada URL antigua tenga una redirección 301 adecuada a su equivalente nuevo. Nunca redirijas URLs antiguas en lotes a la página principal.

¿Cuál es el mejor CMS para SEO en 2026? Honestamente, casi cualquier CMS moderno puede configurarse para buen SEO. Lo que importa más es la implementación frontend. Un CMS headless (Sanity, Contentful, Storyblok) emparejado con un frontend bien construido en Next.js o Astro puede superar WordPress en métricas de SEO técnico como Core Web Vitals. Pero WordPress con buen hosting y los plugins correctos sigue siendo perfectamente capaz. El "mejor" CMS es el que tu equipo puede usar correctamente. Consulta nuestra página de precios si estás evaluando una compilación headless.

¿Cuántas redirecciones 301 son demasiadas? No hay límite duro. Google ha confirmado que procesa redirecciones 301 sin problema, incluso a escala. Sitios con 100,000+ redirecciones funcionan bien. Lo que importa es que cada redirección sea precisa (apuntando al destino correcto) y que evites cadenas (redirección → redirección → redirección). En el lado del rendimiento del servidor, mantén las reglas de redirección eficientes -- usa búsquedas basadas en mapas para listas grandes en lugar de evaluación secuencial de reglas.

¿Puedo migrar mi CMS en fases en lugar de todo a la vez? Sí, y para sitios grandes, las migraciones por fases a menudo son más seguras. Podrías migrar el blog primero, luego páginas de productos, luego páginas de destino. Esto te permite monitorear el impacto de cada fase y detectar problemas antes de que afecten al sitio completo. La parte complicada es manejar el estado híbrido donde algo de contenido vive en el CMS antiguo y algo en el nuevo. Esto usualmente requiere configuración cuidadosa de proxy inverso o enrutamiento.

¿Qué herramientas necesito para una auditoría de migración de CMS SEO? Como mínimo: Screaming Frog (o Sitebulb) para rastreo, Google Search Console para datos de clasificación e indexación, y un script de prueba de redirecciones. Adiciones útiles incluyen Ahrefs o SEMrush para rastreo de enlaces de retroceso y clasificación, Google Analytics para comparación de tráfico, y un analizador de registros del servidor. Para migraciones headless, también necesitarás Lighthouse CI o WebPageTest para monitoreo de rendimiento.

¿Migrar a un CMS headless mejora el SEO? No automáticamente. Un CMS headless en sí no afecta el SEO -- el frontend es lo que importa. Pero las arquitecturas headless a menudo resultan en sitios más rápidos y livianos porque tienes control completo sobre el código frontend. Si construyes con SSR/SSG, optimizas imágenes, minimizas JavaScript e implementas SEO técnico adecuado, puedes ver mejoras significativas en Core Web Vitals y, consecuentemente, en las posiciones. La migración en sí es neutral; lo que construyas con la nueva arquitectura es lo que hace la diferencia.