La mayoría de los desastres de tráfico no vienen de una actualización de Google: los equipos se los provocan solos al cambiar de plataforma. Una migración a ciegas puede costar entre el 30 y el 70 % del tráfico orgánico, y la recuperación lleva meses. Hecha según el manual, supone una caída pequeña y breve, a la que a menudo sigue un crecimiento (Next.js suele ganar en renderizado y velocidad).
Regla cero: cambie una variable cada vez
Las migraciones más arriesgadas cambian a la vez la plataforma, la estructura de URL, el diseño y el contenido: cuando el tráfico cae, nadie sabe señalar qué cambio lo tumbó. Escalone en el tiempo: migre la plataforma con URL y contenido congelados, confirme la estabilidad durante unas semanas y después evolucione el diseño y el contenido ya en el nuevo stack.
Antes: construya un inventario
No conservará lo que no ha medido. Reúna por URL:
- Un rastreo completo del sitio antiguo (Screaming Frog o un script sobre el sitemap antiguo).
- Las páginas top de Search Console (12 meses de clics) y las páginas top de conversión de la analítica: esas reciben atención manual.
- Las páginas más enlazadas (GSC → Enlaces o Ahrefs): perder una redirección en una página con 200 dominios de enlace quema años de autoridad.
- Title, description, canonicals, hreflang y datos estructurados actuales: la base de la paridad.
El mapa de redirecciones es la migración
Si las URL cambian en absoluto, cada URL antigua recibe un 308/301 de un solo salto hacia su equivalente nuevo exacto, no hacia la página principal (Google trata las redirecciones masivas a la principal como soft 404):
// next.config.mjs — primero reglas de patrón, mapa explícito para las excepciones
async redirects() {
return [
{ source: "/shop/:category/:slug", destination: "/products/:slug", permanent: true },
...explicitMap.map(({ from, to }) => ({ source: from, destination: to, permanent: true })),
];
}
Las cadenas están prohibidas: si el sitio antiguo ya tenía redirecciones, dirija también sus orígenes directamente a las URL finales. Todo lo del tema sobre redirecciones aquí cuenta por partida doble.
Staging: control de paridad, no "a ojo"
- Mantenga el staging fuera del índice: la autenticación HTTP evita depender de un ajuste
noindexque podría llegar por accidente a producción. - Compare con un script lo antiguo y lo nuevo en las páginas top: title, description, canonical, hreflang, H1, JSON-LD, código de respuesta. También la paridad de renderizado: haga
curlal HTML del staging y confirme que el contenido se renderiza en el servidor. - Pruebe el mapa de redirecciones sobre el inventario completo de URL antiguas antes del lanzamiento, no sobre una muestra.
El día del lanzamiento y las semanas siguientes
- Envíe el nuevo sitemap en Search Console; sirva las redirecciones desde las URL antiguas de forma indefinida (años, no semanas).
- Vigile los logs del servidor en busca de 404 de Googlebot: cada uno es un agujero en el mapa de redirecciones; durante la primera semana corríjalos a diario.
- Espere un pico de rastreo y oscilaciones de posición durante 2–6 semanas: Google vuelve a evaluar el sitio; no dé marcha atrás presa del pánico.
- Umbrales de alarma: una caída sostenida de >20 % en páginas de ingresos pasada la tercera semana merece una investigación (configuración del monitoreo), no esperanza.
Checklist:
- Inventario de URL con las páginas top de GSC y las más enlazadas marcadas
- Mapa de redirecciones de un solo salto que cubre el 100 % de las URL antiguas, probado antes del lanzamiento
- Staging tras autenticación; paridad de meta/schema/renderizado comparada por cada página top
- Plataforma migrada con URL y contenido congelados; diseño después
- Tras el lanzamiento: revisión diaria de los 404 de Googlebot, redirecciones vivas durante años