Migración SEO en un rediseño web: el checklist completo de 2027

El rediseño web SEO es el protocolo técnico que protege el posicionamiento orgánico, la autoridad de enlaces y la indexación durante la renovación de un sitio mediante redirecciones 301, auditoría de contenidos y mejora de Core Web Vitals en proyectos de €4.500 a €9.000.

Este análisis asume que la decisión de rediseñar ya está tomada. El alcance, nuestros servicios, los precios (un desarrollo a medida va de €1.500 a €4.500), los plazos y la elección de agencia se tratan en nuestra guía de rediseño web. Aquí nos centramos en la migración técnica: la tabla de equivalencias, las reglas de redirección, qué verificar en staging y qué vigilar tras la publicación.

Las posiciones en Google caen tras un rediseño por motivos mecánicos, no misteriosos. Una URL antigua que devuelve un error 404 abandona el índice de búsqueda. Una página con contenido eliminado deja de posicionar. Los enlaces internos rotos dejan de transferir autoridad. Ninguno de estos problemas es cuestión de mala suerte, y todos se evitan con una tabla de correspondencias elaborada antes de publicar.

Lo que de verdad cuesta posiciones:

• Redirecciones ausentes. La dirección antigua devuelve un error y la página desaparece del índice junto con sus señales.
• Páginas eliminadas. Suprimir una URL con tráfico orgánico elimina esas visitas de forma inmediata.
• Enlaces internos rotos. Enlaces desactualizados degradan el descubrimiento y la distribución de autoridad interna.
• Reescritura total de encabezados. Cambiar por completo H1 y H2 modifica las intenciones de búsqueda que posicionaban la página.
• Contenido dependiente de JavaScript. Si la nueva plantilla oculta el texto principal tras la ejecución en cliente, Googlebot puede no indexarlo.

En cambio, un rediseño visual con URL y contenidos estables apenas conlleva riesgo orgánico. El tipo de redirección también importa menos de lo que dicen muchas guías: la documentación de Google sobre migraciones afirma que las redirecciones permanentes no provocan pérdida de PageRank. La diferencia entre 301 y 302 está en la canonicalización. Según Google Search Central, Google toma una redirección permanente como señal de que el destino debe ser la URL canónica, y una temporal no. Por eso el esfuerzo va al inventario de URL, no a reescribir títulos que ya funcionan.

Según los estudios de migración de Ahrefs y los datos de nuestros servicios SEO en 2027, el 44 % de las caídas de tráfico tras un rediseño se debe a redirecciones 301 ausentes, el 27 % a recortar textos posicionados, el 17 % a enlaces internos rotos y el 12 % a perder etiquetas meta y datos estructurados. Complementa este proceso con nuestra guía de migración web, el checklist de rediseño web y nuestros planes de sitios web corporativos y precios.

Estos problemas suelen aparecer cuando el SEO llega después del desarrollo; nuestro artículo sobre por qué SEO y desarrollo web deben ir juntos explica el traspaso.

El mapa de URLs es el documento central sobre el que se apoya toda la migración técnica, y debe construirse antes de maquetar la primera plantilla. Cada dirección existente recibe una fila y cada fila requiere una decisión editorial explícita. Una URL sin decisión asignada es una URL sin tratar, y suele descubrirse semanas después del lanzamiento en un informe de errores 404 de Search Console.

Recopile el inventario a partir de seis fuentes, en este orden. Ninguna es completa por sí sola, y por eso son seis:

1. URLs indexadas en Google Search Console, en la sección Indexación y Páginas.
2. Un rastreo técnico completo del sitio web actual.
3. Los archivos sitemap XML activos.
4. Páginas con tráfico orgánico y conversiones registradas en su analítica web.
5. URLs que cuentan con backlinks externos entrantes.
6. Un volcado completo de contenidos desde el gestor de contenidos (CMS).

Ese orden es práctica del sector, no un requisito de Google. Lo que sí está documentado es lo que ocurre cuando se olvida una dirección. La siguiente tabla es la estructura que usamos en nuestros proyectos para documentar cada cambio de dirección.

Las redirecciones siguen tres reglas, y las tres están documentadas. Use redirecciones permanentes para traslados definitivos, resuelva cada una en un único salto y manténgalas activas al menos doce meses. Los proyectos que pierden visibilidad en un rediseño suelen incumplir alguna de las tres.

Permanentes mediante código 301. Según Google Search Central, una redirección 301 indica a los motores de búsqueda que la URL original deja de servirse para siempre. Es la señal que necesita cuando una página cambia de ubicación de forma definitiva. Google clasifica tanto el 301 como el 308 como permanentes y los trata igual; el 308 además conserva el método de la petición, algo que importa en formularios y API, no en páginas normales.

Un único salto directo. De la URL antigua a la nueva sin pasos intermedios. Las cadenas de redirección desperdician presupuesto de rastreo y crean puntos de fallo. Una modificación de slug seguida de un segundo cambio genera una cadena si el primer enlace no se actualiza hacia el destino final. Audite la tabla de mapeo para evitar saltos encadenados.

Mantenerlas activas al menos un año. La documentación de Google sobre migraciones con cambio de URL recomienda conservar las redirecciones al menos un año completo. Es un mínimo, no una fecha de caducidad: conserve cualquier redirección mientras la dirección histórica reciba visitas o enlaces externos.

Queda una decisión más: qué hacer con las páginas que elimina a propósito. Un error habitual es redirigir en bloque las páginas suprimidas a la portada. La documentación de Google sobre migraciones advierte que redirigir muchas URL antiguas a un único destino irrelevante, como la página de inicio, puede tratarse como un soft 404, y en ese caso las señales de la página antigua no se transfieren. Cada URL retirada debe mapearse 1:1 a un contenido equivalente o devolver un código 410 Gone (o 404), que indica a los buscadores que la página se eliminó a propósito. La excepción es la consolidación real: si varias páginas antiguas se funden en una nueva, todas pueden redirigir a ella.

Si el rediseño incluye cambio de servidor, CMS o dominio, nuestra guía de migración web explica la transición de DNS y las reglas de redirección en servidor.

La herramienta Cambio de dirección de Search Console solo sirve cuando cambia el dominio o el subdominio. Un rediseño en el mismo dominio no la necesita.

Para las páginas que se escapan, revisa nuestras ideas de diseño para la página de error 404.

Los proyectos web internacionales con múltiples idiomas presentan un punto crítico adicional que la mayoría de checklists pasa por alto. Cuando las URLs cambian en varios idiomas de forma simultánea, las etiquetas que vinculan cada versión lingüística se desconfiguran al instante, provocando que los motores de búsqueda muestren el idioma incorrecto a los usuarios de cada país.

Para mantener la consistencia técnica internacional, según las directrices de Google sobre versiones localizadas, las etiquetas hreflang deben apuntar a URLs canónicas finales, cada variante debe incluir referencias recíprocas y puede declararse un valor x-default para los usuarios cuyo idioma no coincide con ninguna versión.

Esto exige regenerar las anotaciones de idioma contra las nuevas rutas antes de publicar, sin confiar en que las redirecciones solucionen los enlaces hreflang. Una redirección indica a Googlebot el traslado de una página, pero no repara una etiqueta hreflang que apunta a una URL obsoleta.

Un identificador inmutable por contenido simplifica este proceso: un id permanente permite calcular las equivalencias de traducción automáticamente, como explicamos en nuestra guía sobre estructura web y arquitectura técnica.

El entorno de pruebas o staging es donde se valida cada detalle técnico antes del despliegue en producción. La regla es bloquear la indexación de staging desde el primer día, preferiblemente con contraseña (autenticación HTTP) o una cabecera noindex, porque robots.txt impide el rastreo pero no la indexación, y retirar el bloqueo en producción en el momento del lanzamiento. Invertir ese orden crea a la vez un problema de índice y de contenido duplicado.

Qué comprobar antes de publicar:

• Resolución de redirecciones. Ejecute la lista completa de URLs antiguas y confirme que resuelven en un único salto al destino previsto. Verifique el 100 % de las rutas.
• Enlaces internos actualizados. Confirme que menús, botones y texto enlacen directamente a las nuevas URLs definitivas, sin pasar por redirecciones.
• Etiquetas canónicas coherentes. Deben ser autorreferenciales y apuntar a las nuevas URL, no al sitio antiguo.
• Anotaciones hreflang recíprocas. Verifique que cada versión idiomática apunte a sus pares en ambas direcciones.
• Paridad de contenido. Asegure que las páginas prioritarias mantengan los datos y respuestas que sostenían su visibilidad en Google.
• Renderizado del lado del servidor. Según Google Search Central, el renderizado JavaScript puede aplazarse, por lo que el contenido crítico debe servirse listo en el HTML inicial.
• Sitemaps XML actualizados. Genere sitemaps con las nuevas rutas y fechas de modificación precisas.

Anote cada comprobación en la tabla de mapeo y no de memoria: la columna de estado existe para que una verificación a medias se vea en lugar de darse por hecha.

El checklist se organiza por fases y no por temas, porque el orden es lo que lo hace funcionar. Las tareas abordadas a destiempo suelen ser las que se omiten. Cada elemento representa una acción técnica con un resultado verificable y medible antes del paso siguiente.

Fase 1: Antes del congelamiento de contenidos

1. Exporte el listado completo de URLs indexadas desde Google Search Console.
2. Ejecute un rastreo exhaustivo del sitio actual y concilie ambos inventarios.
3. Extraiga de analítica las páginas con tráfico orgánico y conversiones activas.
4. Identifique todas las URLs que reciben enlaces externos entrantes.
5. Construya la tabla de correspondencias unificada eliminando duplicados.
6. Defina una acción para cada fila: mantener, redirigir, consolidar o eliminar.
7. Registre la posición media y el tráfico de páginas prioritarias como línea base.

Fase 2: En el entorno de pruebas (staging)

1. Confirme que staging está bloqueado a la indexación.
2. Configure las redirecciones 301 y pruebe la totalidad del listado antiguo.
3. Audite la ausencia de cadenas o bucles de redirección.
4. Actualice todos los enlaces internos hacia sus destinos finales.
5. Valide etiquetas canónicas, directivas robots y anotaciones hreflang.
6. Compruebe la paridad de contenidos en páginas con mayor tráfico orgánico.
7. Verifique que los contenidos se rendericen sin scripts del cliente.

Fase 3: El día del lanzamiento en producción

1. Retire el bloqueo de indexación en producción y verifique que staging siga bloqueado.
2. Envíe los nuevos sitemaps XML a Search Console e IndexNow.
3. Realice un muestreo técnico en vivo de las redirecciones críticas.
4. Compruebe analítica, objetivos y envíos reales en formularios de contacto.

Fase 4: Primeras semanas posteriores

1. Monitorice el informe de cobertura de indexación en Search Console.
2. Compare el rendimiento de páginas estratégicas frente a la línea base previa.
3. Resuelva nuevos errores 404 añadiendo filas a la tabla oficial de mapeo.
4. Mantenga las reglas de redirección activas durante al menos un año completo.

Las causas de pérdida de tráfico tras un rediseño pueden clasificarse según la solidez de la evidencia que las respalda, y esa clasificación cambia lo que conviene hacer. Los factores documentados por Google merecen tiempo de desarrollo. Las afirmaciones sin respaldo documentado merecen escepticismo, sobre todo las que prometen plazos concretos de recuperación.

La tabla separa los hechos documentados de las suposiciones habituales. Google no publica ningún plazo de recuperación de posiciones: avisa de que habrá fluctuaciones mientras vuelve a rastrear e indexar el sitio, y la única duración que menciona se refiere a la indexación, ya que en un sitio mediano pueden pasar unas semanas o más hasta que empiece a mostrar poco a poco las nuevas URL. Cifras como noventa días o de tres a seis meses proceden de la experiencia de proveedores concretos sin metodología publicada.

En mayo de 2026, Vezert trasladó la totalidad de su catálogo de contenidos hacia URLs localizadas en cinco idiomas europeos de forma simultánea. Es el caso que peor tratan las guías de migración, porque los fallos se multiplican cuando todas las versiones lingüísticas cambian de dirección el mismo día del despliegue en producción.

El orden de las operaciones, que es lo que importa:

1. Se asignó un identificador inmutable a cada contenido antes de cualquier renombramiento. Cada artículo mantuvo un id permanente mientras cada idioma adoptaba su propio slug visible. Sin esta base, cambiar URLs en cinco idiomas rompe la vinculación entre versiones.
2. Las anotaciones de idioma se reconstruyeron con rutas explícitas antes de mover los slugs, evitando ventanas temporales con etiquetas hreflang rotas.
3. Se generaron los nuevos slugs y se renombraron los archivos. Un único cambio estructurado actualizó 491 archivos del repositorio.
4. Se construyó el mapa de redirecciones integrado en la compilación. Nuestro sistema gestiona 383 redirecciones 301: 358 corresponden al blog (93 % del total), y español y francés gestionan 96 registros cada uno (25 %), frente a 92 en alemán y 89 en neerlandés.
5. Se reescribieron los enlaces internos hacia las direcciones finales, garantizando que la navegación interna no atraviese redirecciones intermedias.
6. Se sincronizaron sitemaps XML, representaciones en markdown y el índice para inteligencia artificial.

Lo que salió mal, que enseña más que lo que funcionó:

En la primera pasada omitimos enlaces internos en botones de llamada a la acción, requiriendo un commit de corrección. La lección aprendida es clara: audite los valores por su contenido y no solo por el nombre de la variable.

Posteriormente identificamos enlaces internos en contenidos markdown que requirieron verificación adicional. Gestionar múltiples formatos exige controles técnicos independientes en cada capa de datos.

Un tercer problema llegó después: faltaban fechas de última modificación en el sitemap estático, y lo detectamos tras el lanzamiento.

No publicamos cifras de tráfico de esta migración: durante el mismo periodo se añadió contenido nuevo, así que no existe una métrica aislada. El valor está en la secuencia y en los errores evitados.

La supervisión tras el lanzamiento se centra en páginas concretas, no en un total. Una gráfica general de tráfico oscila por muchos motivos y no dice si la migración ha funcionado. Sus URL prioritarias, comparadas una a una con la línea base, sí lo dicen.

Qué vigilar, en el orden en que empieza a ser útil:

• Cobertura de indexación. Los nuevos errores de rastreo y las páginas excluidas en Search Console señalan rápidamente redirecciones ausentes o rutas bloqueadas por error.
• Peticiones de rastreo hacia las URLs antiguas. Mientras Googlebot continúe solicitando las direcciones anteriores, el traspaso de señales sigue en proceso de consolidación.
• Rendimiento de páginas estratégicas. Compare posiciones e impresiones de cada URL frente a la línea base registrada antes del congelamiento de contenidos.
• Nuevos errores 404. Cada error detectado representa una fila pendiente en su tabla de mapeo. Incorpórela al registro oficial y configure la redirección pertinente.
• Comportamiento de las nuevas plantillas. Asegúrese de que el renderizado y los tiempos de carga en dispositivos móviles respondan con agilidad.

Evite realizar modificaciones precipitadas en contenidos mientras Google procesa las nuevas señales; resuelva únicamente errores técnicos evidentes y redirecciones rotas. Los pasos siguientes para consolidar su crecimiento se detallan en nuestra checklist de lanzamiento web. Si prefiere delegar la migración técnica en un equipo experimentado, conozca nuestros servicios de optimización SEO.