He visto a empresas perder 40-60% de su tráfico orgánico de la noche a la mañana porque alguien pensó que una migración de CMS era "solo un proyecto técnico". No lo es. Es un proyecto SEO con componentes técnicos, y el orden de esas palabras importa.

Durante los últimos siete años, he liderado personalmente o supervisado migraciones desde WordPress a configuraciones headless, Drupal a Sanity, sitios legacy .NET a Next.js, y todo lo que hay en medio. Algunas fueron impecables. Algunas fueron desastres que heredé y tuve que arreglar. Esta guía es 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 se someten a una migración de CMS experimentan una caída de tráfico de más del 20% que tarda más de seis meses en recuperarse. Pero aquí está la cosa -- no tiene que ser así. Con el proceso correcto, puedes migrar tu CMS y salir al otro lado con tus rankings intactos, a veces incluso mejorados.

Tabla de Contenidos

CMS Migration Without Losing SEO Rankings: A Complete Guide

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

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

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

  • Las estructuras de URL cambian sin redirecciones adecuadas (esto solo representa aproximadamente el 70% de las caídas de tráfico post-migración)
  • El contenido se modifica, trunca u reorganiza de formas 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 datos meta se pierden -- títulos, descripciones, etiquetas canónicas, atributos hreflang
  • Los datos estructurados desaparecen porque el CMS antiguo tenía complementos que los generaban automáticamente

¿Lo peor? Estos problemas se componen. Una única cadena de redirección rota puede cascadear 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 instantánea completa de tu estado SEO actual. Piénsalo como un punto de guardado en un videojuego -- necesitas algo contra lo que comparar.

Qué Rastrear y Exportar

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

# Puntos de datos clave a capturar:
- Todas las URLs (cada una, incluidas las páginas paginadas)
- Códigos de estado HTTP
- Títulos
- Meta descripciones
- 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 Baseline de Rankings

Extrae datos de ranking de Google Search Console para los últimos 16 meses. Exporta. También extrae datos de cualquier herramienta de terceros que uses -- Ahrefs, SEMrush, Moz. Necesitas:

  • Top 500 páginas por tráfico orgánico
  • Top 1000 palabras clave por clics
  • Todas las páginas que se clasifican en la página 1 para cualquier palabra clave
  • Páginas con fragmentos destacados
  • Páginas con resultados enriquecidos

Almacena 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 rápida base de datos PostgreSQL.

Identifica Tus Páginas de Dinero

No todas las páginas son iguales. Una migración que preserva perfectamente el 95% de tus páginas pero rompe las top 20 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. Recuento de backlinks (estos transmiten 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 exactamente la misma estructura de URL, 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. Tal vez estés consolidando subdominios, cambiando de HTTP a HTTPS (aunque eso debería haber sucedido hace años), o tu antiguo CMS generaba 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 URL

Crea un documento de mapeo con estas columnas:

| URL Antigua | URL Nueva | Código de Estado | Prioridad | Notas |
|---------|---------|-------------|----------|-------|
| /old-page | /new-page | 301 | Alto | Top 10 por tráfico |
| /removed-page | /relevant-page | 301 | Medio | Contenido fusionado |
| /still-exists | /still-exists | 200 | Bajo | 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 automático. Hemos construido herramientas de migración personalizadas para exactamente esto cuando trabajamos en proyectos de desarrollo de CMS headless.

CMS Migration Without Losing SEO Rankings: A Complete Guide - architecture

Mapeo de Redirecciones: El Trabajo Tedioso Que Lo Salva Todo

Las redirecciones son tu red de seguridad. Cada URL antigua que cambia debe 301 redirigir a su equivalente nuevo. No a la página de inicio. No a una página de categoría. El 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 redirección. Si A redirige a B y B redirige a C, esa es una cadena. Cada salto pierde algo de equidad (Google dice que no, pero datos empíricos de estudios de 2024 por Cyrus Shepard y otros sugieren lo contrario).
  3. Nunca redirijas todo a la página de inicio. Esto se llama un "404 suave" y Google eventualmente tratará esas URLs como realmente desaparecidas.
  4. Mapea 1:1 donde sea posible. Página antigua → página nueva equivalente.
  5. Maneja el contenido eliminado adecuadamente. Si una página no tiene equivalente, encuentra la página topicamente más relevante o devuelve un estado 410 (Desaparecido) 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 desde 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 mapa para listas grandes
map $request_uri $new_uri {
    include /etc/nginx/redirects.map;
}

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

Para Vercel/hosting basado en edge:

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

Prueba de Redirecciones Antes de ir en Vivo

Esto es innegociable. He visto equipos escribir 3,000 reglas de redirección e implementar 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 "FAIL: $old_url -> $actual_url (expected $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. Me refiero a 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. Acabas de romperla.

Cambiar la jerarquía de encabezados. Si tu página antigua tenía un H1 de "Mejores Frameworks de React en 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 ranking.

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

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

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

Aquí está la lista de verificación que uso el día de la migración. Imprímela. Pégala a 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 URLs 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 bajado 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 top 20 páginas de dinero
- [ ] Verificar que no hay etiquetas noindex accidentales
- [ ] Verificar que robots.txt es accesible
- [ ] Probar 50 redirecciones aleatorias manualmente
- [ ] Verificar datos estructurados en Rich Results Test
- [ ] Verificar Core Web Vitals en páginas principales

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

Datos Meta, Schema y Migración de Datos Estructurados

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

Lo Que Necesitas Preservar

Elemento Dónde Vive (WordPress) Dónde Va (Headless)
Etiqueta de título Complemento Yoast SEO Gestión de cabeza del framework frontend
Meta descripción Complemento Yoast SEO Campo de framework frontend o CMS
Imagen OG Yoast/auto-generada Campo de CMS + renderización frontend
Schema JSON-LD Complemento generado Código personalizado en frontend
Schema de migajas de pan Complemento generado Implementación a nivel de componente
Schema de FAQ Complemento 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 autoridad de página, señalizan relaciones de contenido a Google, y ayudan con la rastreabilidad.

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

  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 diferente

Arreglando 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 contenido."""
    for old_url, new_url in redirect_map.items():
        # Coincide tanto con URLs absolutas como relativas
        content = content.replace(f'href="{old_url}"', f'href="{new_url}"')
        content = content.replace(
            f'href="https://yourdomain.com{old_url}"',
            f'href="https://yourdomain.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 (arguiblemente) diluye la equidad de enlaces. Arregla los enlaces en la fuente.

Rendimiento y Core Web Vitals

Una migración de CMS es tu única oportunidad para hacer una mejora de rendimiento masiva, o para hundir completamente tus Core Web Vitals.

El algoritmo de ranking de Google en 2026 continúa usando Core Web Vitals como una señal de ranking. 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 antiguo de WordPress tenía un LCP de 3.8s y tu nuevo sitio Next.js alcanza 1.2s, eso es un impulso de ranking genuino esperando suceder. Pero si tu nuevo sitio está cargando un paquete JavaScript de 2MB y tu LCP salta a 5s, acabas de crear un nuevo problema además de la migración.

Prueba tu sitio de staging a fondo con Lighthouse, WebPageTest, y el Chrome UX Report antes de ir en vivo.

Protocolo de Monitoreo Post-Migración

Los 30 días después de la migración son críticos. Aquí está el cronograma 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 rankings: Top 50 palabras clave
  • Tráfico orgánico: Comparar día a día con el año anterior

Semanas 2-4: Monitoreo Semanal

  • Comparación completa de rastreo del sitio contra baseline pre-migración
  • Tendencia de recuento de páginas indexadas
  • Adquisición de nuevos backlinks (enlaces rotos de sitios externos)
  • Comparación de tasa de conversión

Meses 2-3: Monitoreo Bisemanal

  • Estabilidad de ranking para palabras clave de cola larga
  • Nuevas apariciones de palabras clave
  • Datos de campo de Core Web Vitals (toma ~28 días para llenar)

Una fluctuación temporal de ranking en las primeras 2-4 semanas es normal. Google está re-rastreando y re-evaluando tu sitio. Si has hecho todo bien, los rankings deben estabilizarse y volver al baseline dentro de 4-6 semanas. Si no se han recuperado después de 8 semanas, algo salió mal.

Migraciones de CMS Headless: Consideraciones Especiales

Migrar a una arquitectura de CMS headless introduce desafíos únicos que las migraciones tradicionales de CMS a CMS no tienen.

Renderización del Lado del Servidor Es No Negociable

Si tu frontend headless renderiza todo del lado del cliente (estilo SPA), Google tendrá más dificultad para indexar tu contenido. Google puede renderizar JavaScript, pero es más lento y menos confiable que rastrear HTML renderizado en el servidor.

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

Diferencias de Modelado de Contenido

Los CMSes tradicionales almacenan contenido como bloques HTML. Los CMSes 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

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

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 la producción. Esto significa:

  • Las mismas reglas de redirección
  • La misma configuración de CDN
  • El mismo comportamiento de renderización
  • Contenido real (no lorem ipsum)

Rastrea el entorno de staging con Screaming Frog y compáralo contra tu baseline pre-migración. Cada discrepancia es una pérdida potencial de ranking.

Plan de Recuperación: Qué Hacer Si Los Rankings Caen

A pesar de los mejores esfuerzos, a veces las cosas se van de lado. Aquí está el proceso de triage:

  1. Verifica si hay bloqueos de rastreo. ¿Está robots.txt bloqueando a Googlebot? ¿Hay etiquetas noindex accidentales? Este es el error #1 post-migración.
  2. Verifica que las redirecciones funcionan. Spot-check 100 URLs antiguas aleatorias. ¿Se están 301ing correctamente?
  3. Busca cadenas de redirección y bucles. Estos son asesinos silenciosos.
  4. Compara contenido. Abre tus top 20 páginas en Wayback Machine y compara con la actual. ¿Falta contenido?
  5. Audita etiquetas canónicas. ¿Están apuntando a las URLs correctas? ¿Canónicas autorreferenciales en cada página?
  6. Revisa datos estructurados. Usa Google Rich Results Test en tus páginas principales.
  7. Revisa Core Web Vitals. ¿El rendimiento retrocedió?
  8. Envía una reconsideración o solicitud de 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 graves, la recuperación puede tomar 2-4 meses.

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

FAQ

¿Cuánto tiempo toma una migración de CMS sin perder rankings SEO?

Para un sitio con menos de 1,000 páginas, planifica de 4 a 8 semanas de preparación, migración y estabilización. Los sitios más grandes (10k+ páginas) pueden tomar 3-6 meses. El cambio real puede 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 los rankings.

¿Perderé rankings 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, e re-indexar las páginas. Si has implementado correctamente redirecciones 301 y mantenido paridad de contenido, deberías ver que los rankings vuelvan al baseline dentro de 4-6 semanas. Caídas mayores que persistan más allá de 8 semanas indican un problema que necesita investigación.

¿Debo 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 rankings. Si tus URLs actuales son funcionales (aunque sean feas), mantenlas. Si debes cambiar URLs por razones técnicas, asegúrate que cada URL antigua tenga una redirección 301 adecuada a su equivalente nueva. Nunca redireccionamiento en lote URLs antiguas a la página de inicio.

¿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 Next.js o Astro bien construido puede superar WordPress en métricas de SEO técnico como Core Web Vitals. Pero WordPress con buen hosting y los complementos correctos sigue siendo perfectamente capaz. El "mejor" CMS es el que tu equipo puede usar correctamente. Revisa nuestra página de precios si estás evaluando una compilación headless.

¿Cuántas redirecciones 301 son demasiadas?

No hay un 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 mapa para listas grandes en lugar de evaluación de reglas secuencial.

¿Puedo migrar mi CMS en fases en lugar de todo de una 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 producto, luego páginas de aterrizaje. Esto te permite monitorear el impacto de cada fase y atrapar problemas antes de que afecten todo el sitio. La parte complicada es gestionar el estado híbrido donde algo de contenido vive en el CMS antiguo y algo en el nuevo. Esto usualmente requiere una cuidadosa configuración de proxy inverso o enrutamiento.

¿Qué herramientas necesito para una auditoría SEO de migración de CMS?

Como mínimo: Screaming Frog (o Sitebulb) para rastrear, Google Search Console para datos de ranking e indexación, y un script de prueba de redirecciones. Adiciones útiles incluyen Ahrefs o SEMrush para seguimiento de backlinks y rankings, Google Analytics para comparación de tráfico, y un analizador de registros del servidor. Para migraciones headless, también querrás Lighthouse CI o WebPageTest para monitoreo de rendimiento.

¿La migración a un CMS headless mejora el SEO?

No automáticamente. Un CMS headless en sí no afecta el SEO -- es el frontend lo que importa. Pero las arquitecturas headless a menudo resultan en sitios más rápidos y ligeros porque tienes control total 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, rankings. La migración en sí es neutral; lo que construyes con la nueva arquitectura es lo que hace la diferencia.