seojuice

Migración de sitio SEO: cómo trasladarse sin perder posiciones

Vadim Kravcenko
Vadim Kravcenko
· Updated · 10 min read

TL;DR: Una migración conserva la visibilidad en buscadores cuando cada URL antigua valiosa tiene un destino relevante, los redireccionamientos permanentes del lado del servidor apuntan directamente a ese destino y Google puede rastrear e indexar el reemplazo. Haz inventario y benchmarks del sitio antiguo antes del lanzamiento. Construye un mapa de redirecciones 1 a 1, actualiza enlaces internos y etiquetas canónicas, envía nuevos sitemaps y, después, supervisa la transición entre la indexación antigua y la nueva. Usa la herramienta de Cambio de dirección para movimientos de dominio; no para cambios HTTP a HTTPS ni para cambios de hosting.

Tipo de migración ¿Cambian las URL? ¿Mapa de redirecciones? ¿Cambio de dirección?
Cambio de dominio Sí, incluyendo variantes relevantes y subdominios
HTTP a HTTPS No
Cambio de CMS o de plataforma A menudo Sí, para URL modificadas Sólo si también cambia el dominio
Rediseño o reestructuración de URL A veces Sí, para rutas o slugs modificados No
Consolidación de dominios Sí, para cada dominio de origen Sí, para cada movimiento de dominio
Cambio de hosting o de CDN No No No
La secuencia de migración SEO del sitio: benchmark, mapa de 301, actualización de enlaces, cambio de dirección, supervisión.

La primera pregunta en SEO de migraciones de sitios no es qué plugin instalar. Es esta: ¿después del cambio usuarios y Google verán URL diferentes?

Google Search Central separa las migraciones en cambios de sitio con cambios en URL y cambios de sitio sin cambios en URL. Esa distinción determina la mayor parte del trabajo. Los cambios de dominio, las migraciones de HTTP a HTTPS, las rutas cambiadas y las consolidaciones de dominio pertenecen al primer grupo. Cambiar de hosting o moverse a una CDN manteniendo visible cada URL tal como estaba entra en el segundo.

Nosotros ejecutamos una migración de dominio por nuestra cuenta cuando nuestro equipo de dos personas, Lida y yo, movimos SEOJuice de seojuice.io a seojuice.com en enero de 2026. Mover la aplicación no era lo que me quitaba el sueño. Lo arriesgado era demostrar que cada URL antigua llegaba al reemplazo correcto, que el nuevo sitio no dependía de enlaces internos con el dominio anterior y que Google estaba reemplazando, no sólo descubriendo, las URL.

Esa distinción importa. “El sitio nuevo ya está en marcha” es un hito de infraestructura. No es una prueba de que la migración haya funcionado.

¿Qué cuenta como una migración de sitio SEO?

Una migración SEO es un cambio lo bastante significativo como para afectar la forma en que los motores de búsqueda acceden, rastrean o indexan un sitio web. Un dominio nuevo es el ejemplo más evidente, pero hay varios proyectos menos dramáticos que requieren las mismas medidas de control.

  • Cambio de dominio: Pasar a otro dominio durante un rebranding, una adquisición o un cambio de dominio de nivel superior.
  • HTTP a HTTPS: El protocolo forma parte de la URL, así que es un movimiento con cambios en URL aunque el hostname se mantenga igual.
  • Cambio de plataforma o CMS: Una plataforma nueva puede alterar rutas, parámetros, paginación, el manejo de mayúsculas/minúsculas o los slashes finales. Trátala como una migración con cambios en URL si cualquier URL resultante difiere.
  • Rediseño o reestructuración: Un rediseño visual no es una migración por defecto. Se convierte en una cuando cambian rutas, slugs, navegación, canónicas, contenido renderizado o la capacidad de indexación.
  • Consolidación de dominios: Unir varios dominios o hostnames en uno requiere un inventario y un plan de redirecciones independientes para cada dominio de origen.
  • Cambio de hosting o de CDN: Si las URL visibles para el usuario se mantienen idénticas, esto es principalmente una operación de DNS e infraestructura más que un proyecto de redirecciones.

Yo evitaría mezclar estos cambios salvo que la restricción del negocio pese más que el riesgo de diagnóstico. La guía de Google es contundente: “Cambia sólo una cosa a la vez.” Un cambio simultáneo de dominio, CMS, diseño y taxonomía te deja con cuatro causas plausibles para cada landing page perdida (y en realidad, más si entran en juego el renderizado y las plantillas).

Antes del lanzamiento: inventario primero, migración después

Construye un inventario sólido de las URL antiguas

Tu mapa de redirecciones sólo puede proteger las URL que incluya. Rastrea el sitio antiguo y luego combina ese rastreo con sitemaps XML, exportaciones de Search Console, páginas de aterrizaje en analítica, datos de enlaces entrantes cuando estén disponibles y logs del servidor. Cada fuente ve un recorte distinto del sitio.

Un crawler encuentra páginas enlazadas, pero puede omitir huérfanas. Un sitemap puede excluir URL antiguas que todavía posicionan. La analítica no mostrará páginas que no hayan tenido visitas recientes. Los logs pueden revelar solicitudes a archivos y rutas legacy ausentes de la navegación actual. “Completo” es una palabra incómoda aquí (yo normalmente me conformo con que estén conciliadas de forma independiente).

Mantén dentro del alcance los activos que no sean HTML cuando tengan valor SEO o enlaces externos. PDFs, guías descargables, imágenes y páginas antiguas de campañas son fáciles de omitir porque no aparecen en un rastreo normal de páginas.

Define una línea base fuera del sistema que vas a reemplazar

Exporta tráfico orgánico de páginas de aterrizaje, rendimiento por consultas y por página, información de páginas indexadas, URL con mejor posicionamiento y resultados de rastreo actuales. Separa los datos por directorio o por tipo de página. Un único número de tráfico global del sitio es demasiado ambiguo para depurar una migración.

Si el tráfico baja un 12 por ciento, ese dato te dice casi nada. Si desaparece un directorio de producto mientras el blog se mantiene estable, tienes una pista útil. Revisa primero las redirecciones de ese directorio, plantillas, etiquetas canónicas y directivas de indexación.

Salté el trabajo de línea base porque el lanzamiento se sintió urgente. Me ahorró quizá una hora y después hizo el diagnóstico más lento y menos seguro. No fue un intercambio inteligente.

Mapa cada URL antigua con su reemplazo más cercano

Google Search Central da la instrucción central:

Un mapa de redirecciones envía cada URL antigua a su equivalente nuevo real, 1 a 1:

# 1:1 redirect map (Nginx) - old URL to its closest new equivalent
location = /old-blog/why-seo/    { return 301 /blog/why-seo/; }
location = /products/old-widget/ { return 301 /shop/blue-widget/; }

# Anti-pattern: never mass-redirect everything to the homepage
# location / { return 301 /; }   # this creates soft 404s

“Cuando ya tengas el listado de URL antiguas, decide a dónde debe redirigir cada una.”

Crea una asignación con una fila por cada URL antigua. Incluye el destino previsto, el código de respuesta esperado, el tipo de página, el estado de la migración y cualquier motivo para retirarla. Prioriza las URL que reciben visitas orgánicas o enlaces externos, pero no interpretes “prioriza” como permiso para ignorar la cola larga.

El destino debe preservar la intención. Una página de producto antigua debe llevar al mismo producto o a su sucesor real. Un artículo migrado debe llevar a ese artículo. La home no es un sustituto universal.

Preserva las rutas existentes siempre que sea práctico. Cada URL que no cambia elimina una regla de redirección, una decisión del mapeo y una posible falla. Los equipos suelen reescribir slugs durante un rediseño porque las versiones nuevas “se ven más limpias”. Yo preguntaría qué problema medible resuelve ese “limpieza” antes de aceptar el riesgo de la migración.

Decide qué no debe redirigirse

Un mapeo 1 a 1 no significa que toda página eliminada deba forzarse a algún lugar. Si una página no tiene equivalente y tampoco un sucesor útil, un 404 o 410 correcto puede ser más claro que una redirección irrelevante.

Esto requiere criterio editorial, no una fórmula de spreadsheet. Redirigir un producto discontinuado a su modelo reemplazo puede tener sentido. Redirigir una página de evento eliminada a un índice de eventos no relacionados puede no tenerlo. Relevancia primero.

Prepara el reemplazo para que pueda rastrearse

Importa el contenido, configura HTTPS, prepara el archivo robots.txt de producción, verifica las propiedades relevantes de Search Console y revisa las directivas de indexación a nivel de página. Valida etiquetas canónicas, hreflang donde se use, URLs de datos estructurados, paginación y sitemaps XML contra el hostname de producción.

Los sitios de staging suelen protegerse con reglas de robots.txt, directivas noindex, autenticación o alguna combinación. Esas protecciones no deben filtrarse a producción. Si las páginas siguen ausentes después del lanzamiento, las comprobaciones en Why isn’t my site on Google? cubren controles de robots, directivas noindex y URL Inspection.

Para un sitio grande, migra primero una sección si la arquitectura lo permite. Google recomienda “mover inicialmente sólo una parte del sitio para probar cualquier efecto en el tráfico y en el rastreo e indexación”. Un movimiento en etapas no siempre es posible, pero vale la pena considerarlo antes de aceptar un cambio total “todo o nada”.

Durante el lanzamiento: haz que todas las señales estén alineadas

Usa redirecciones directas y permanentes del lado del servidor

Google recomienda “redirecciones permanentes del lado del servidor desde las URL antiguas a las nuevas URL tal como indicaste en tu mapeo”. Si no conoces la mecánica de las redirecciones, lee primero What is a redirect?. Nuestra comparación de redirecciones 301 vs 302 trata con más detalle la decisión entre permanente y temporal.

Como lo plantea Patrick Stox, autor principal del capítulo SEO de Web Almanac:

“Asegúrate de que tus redirecciones sean 301 o 308 en lugar de códigos de estado 302 o 307 si estás haciendo un movimiento permanente y quieres que las URL se indexen en el nuevo sitio web en vez del antiguo.”

El código de estado no es ceremonial. La documentación de redirecciones de Google explica qué ocurre con una redirección permanente: “Googlebot sigue la redirección y el pipeline de indexación usa la redirección como señal de que el destino de la redirección debe considerarse canónico”.

Cada URL antigua debería apuntar directamente a su destino final. Evita cadenas old-to-intermediate-to-final. Prueba bucles causados por reglas superpuestas de HTTPS, www, slash final, CDN, servidor y aplicación.

Luego inspecciona la respuesta en vivo en lugar del archivo de configuración. Una regla puede ser correcta por sí sola y aun así entrar en conflicto con otra capa. Aquí es donde dejo de confiar en la hoja de migración (y, siendo justos, en mi memoria) y vuelvo a rastrear producción.

No redirijas masivamente páginas a la home

Google lo advierte de forma explícita:

“No redirijas muchas URL antiguas a un único destino irrelevante, como la página de inicio del nuevo sitio.”

Una redirección masiva a la home oculta el trabajo de mapeo que falta; no lo completa. Tanto los motores de búsqueda como los usuarios esperaban un recurso específico. Enviar cada solicitud a una página genérica rompe esa relación.

Si muchas URL comparten un sucesor legítimo, un mapeo many-to-one puede tener sentido. Varios URLs de producto duplicadas pueden, por ejemplo, resolver a la página canónica del producto. El problema no es la aritmética: es la irrelevancia.

Actualiza enlaces internos, canónicas y referencias generadas

Las redirecciones son infraestructura de respaldo. No deberían convertirse en el sistema de enlazado interno del nuevo sitio.

Actualiza navegación, breadcrumbs, enlaces a artículos, módulos de contenido relacionado, etiquetas canónicas, referencias hreflang, datos estructurados, entradas de sitemap y referencias a assets para que usen directamente las URL finales. La instrucción de Google es: “Cambia los enlaces internos del nuevo sitio desde las URL antiguas a las URL nuevas”.

Por lo que vemos en SEOJuice a través de distintos sitios, los enlaces “antiguos” a nivel de plantilla tienen más impacto que los enlaces editoriales aislados: una sola pieza obsoleta puede replicar la misma dependencia de redirección en cientos de páginas. Revisa primero las plantillas y luego el cuerpo del contenido.

Envía sitemaps y usa Cambio de dirección correctamente

Envia el nuevo sitemap XML en Search Console. Google indica que esto lo ayuda a conocer las nuevas URL. Mantener sitemaps separados para URL antiguas y para URL nuevas te da una forma práctica de supervisar el reemplazo.

Para una migración de dominio a dominio, envía Cambio de dirección desde la propiedad antigua de Search Console. La instrucción precisa de Google es enviar solicitudes para “todos los subdominios y las variantes www y non-www del nombre de dominio antiguo”. La herramienta complementa las redirecciones permanentes; no las sustituye.

No uses Cambio de dirección para migraciones de HTTP a HTTPS. Cambiar a HTTPS modifica la URL, pero Google excluye expresamente este caso de la herramienta. También es innecesario para cambios de hosting “solo hosting” y para cambios de ruta dentro del mismo dominio.

Después del lanzamiento: observa el reemplazo, no sólo el tráfico

Una migración no está completa cuando DNS resuelve y se renderiza la home. Está completa cuando usuarios y crawlers llegan de forma consistente al contenido previsto y las nuevas URL reemplazan a las antiguas dentro del índice de Google.

Supervisa los reportes de indexación de Search Console, errores de rastreo, rankings y tráfico orgánico de landing pages contra la línea base. Google describe el patrón esperado de indexación de forma clara:

“Con el tiempo, la cantidad de páginas indexadas desde el sitemap de URL antiguas debería bajar a cero, con un aumento correspondiente en la indexación de las nuevas URL.”

Ese cruce es más útil que refrescar una sola gráfica de tráfico. Si una sección no sube en el lado nuevo, revisa sus redirecciones, etiquetas canónicas, enlaces internos, inclusión en sitemaps, contenido renderizado y directivas de indexación. Nuestra guía sobre cómo funciona la indexación de Google explica el proceso de rastreo y canonicalización detrás de este reemplazo.

Puede ocurrir una caída temporal mientras Google vuelve a rastrear y reindexa URL modificadas. No hay un porcentaje universal creíble ni una fecha límite de recuperación. El tamaño del sitio, la frecuencia de rastreo, el enlazado interno, la calidad de las redirecciones y el alcance del cambio difieren en cada caso. Una pérdida marcada a nivel de página o de directorio, de todos modos, suele ser más accionable que el “promedio” de la industria.

Mantén las redirecciones activas

Google dice: “Mantén las redirecciones durante el mayor tiempo posible, generalmente al menos 1 año”. Mantener redirecciones útiles indefinidamente también puede proteger a visitantes que usan bookmarks antiguos y enlaces de sitios que no controlas.

No canceles el dominio antiguo ni retires infraestructura de soporte de forma prematura. Una redirección que funciona para el rastreo del lanzamiento pero desaparece meses después no puede ayudar a usuarios o crawlers que encuentren un enlace antiguo más adelante.

Las fallas que yo investigaría primero

Síntoma Causa probable Primera revisión
Las URL antiguas devuelven errores 404 Filas de inventario o reglas de redirección faltantes Conciliia URLs de rastreo, sitemap, Search Console, analítica, enlaces entrantes y logs
El navegador reporta demasiadas redirecciones Reglas de redirección en conflicto Revisa juntos el comportamiento de HTTPS, www, slash, CDN, CMS y servidor
Las URL antiguas pasan por múltiples ubicaciones Cadena de redirecciones Apunta cada URL antigua directamente al destino final
Muchas páginas antiguas llegan a la home Mapeo masivo irrelevante Asigna reemplazos relevantes o devuelve respuestas de eliminación correctas
Google conserva URL antiguas Redirecciones temporales o señales canónicas conflictivas Revisa códigos de estado, canónicas, enlaces internos y URLs de sitemap
Las páginas nuevas permanecen sin indexar Controles de staging sobrevivieron al lanzamiento Inspecciona robots.txt, meta robots, X-Robots-Tag y autenticación
Sólo se pierde visibilidad en una plantilla Problema de renderizado o metadatos específico de plantilla Compara HTML renderizado, canónicas, contenido y enlaces internos por plantilla

Revisa accesibilidad y redirecciones antes de reescribir títulos o culpar a una actualización de algoritmo. Los fallos de migración suelen ser mecánicos: una página está bloqueada, una redirección choca con otra regla o una canónica apunta al host equivocado.

El orden importa. Arreglar metadatos en una URL que Google no puede rastrear es trabajo improductivo.

Una migración sólo de hosting es una operación distinta

Si todas las URL visibles para el usuario se mantienen sin cambios, no fabrices un proyecto de redirecciones. Google define este caso como cambiar de proveedor de hosting o moverse a una CDN sin afectar la URL visible.

Prepara y prueba la nueva infraestructura, reduce el TTL de DNS cuando corresponda, cambia DNS y supervisa las solicitudes servidas por ambos entornos. Google aconseja apagar la infraestructura antigua sólo cuando estés seguro de que todos los usuarios, incluido Googlebot, reciben contenido correctamente desde la nueva configuración.

No hay mapa de redirecciones y no hay solicitud de Cambio de dirección porque las URL no se movieron. Los riesgos principales son disponibilidad, rendimiento, configuración de DNS, respuestas del servidor y diferencias en lo que la nueva infraestructura sirve a los crawlers.

Cómo encaja SEOJuice después de una migración

Después de mover seojuice.io a seojuice.com, lo que necesitábamos era una inspección repetible del resultado en vivo. No otra hoja de cálculo de lanzamiento.

La auditoría SEO gratuita de SEOJuice revisa superficies sensibles a la migración, incluyendo robots.txt, sitemaps, etiquetas canónicas, configuración de HTTPS, redirecciones y enlaces internos. Puede detectar enlaces que todavía apuntan al dominio antiguo, destinos de redirección que devuelven errores, directivas noindex sobrantes y desajustes entre canónicas o HTTPS.

La frontera es importante. La auditoría identifica qué está mal y dónde. No escribe reglas de redirección del servidor ni te envía solicitudes de Cambio de dirección. Esos pasos quedan bajo tu control (que probablemente sea donde deberían permanecer los cambios a nivel de dominio).

Preguntas frecuentes

¿Qué es una migración de sitio SEO?

Una migración de sitio SEO es un cambio que afecta la forma en que los motores de búsqueda acceden, rastrean o indexan un sitio web. Los ejemplos incluyen mover dominios, pasar de HTTP a HTTPS, cambiar plataformas de CMS o estructuras de URL, consolidar dominios y mover hosts. La distinción central es si cambian las URL visibles, porque las URL cambiadas requieren mapeo y redirecciones.

¿Perderé posiciones cuando migre mi sitio?

No necesariamente. Las redirecciones permanentes ayudan a Google a tratar el destino como canónico y a reemplazar la URL antigua. Puede haber fluctuaciones durante el rastreo y la reindexación. Las pérdidas sostenidas suelen justificar revisar redirecciones faltantes, destinos irrelevantes, bucles, redirecciones temporales, contenido cambiado, canónicas y indexación bloqueada.

¿Las URL antiguas necesitan redirecciones 1 a 1?

Cada URL antigua valiosa debe evaluarse de forma individual y redirigirse a su reemplazo relevante más cercano. No envíes páginas no relacionadas a la home. Si no existe un reemplazo relevante, un 404 o 410 correcto puede ser más preciso que una redirección engañosa.

¿Cuándo debería usar la herramienta Cambio de dirección de Google?

Úsala para un movimiento desde un dominio hacia otro. Envía las solicitudes necesarias para subdominios y variantes www o non-www del dominio antiguo. No la uses para cambios de HTTP a HTTPS, cambios de ruta dentro del mismo dominio, ni para movimientos de hosting y de CDN. Cambio de dirección no reemplaza las redirecciones permanentes.

¿Cuánto tiempo deben permanecer activas las redirecciones de migración?

Google recomienda mantener las redirecciones durante el mayor tiempo posible, generalmente al menos un año. Conservar redirecciones útiles de forma indefinida puede proteger bookmarks antiguos y enlaces externos, siempre que los destinos sigan siendo relevantes.

¿Cómo verifico que la migración funcionó?

Compara tráfico posterior al lanzamiento, posiciones, URL indexadas y resultados de rastreo con la línea base. Rastrea las URL antiguas para confirmar redirecciones permanentes directas, rastrea el sitio nuevo para encontrar enlaces internos antiguos y revisa directivas de robots, canónicas, sitemaps y respuestas del servidor. En Search Console, el conteo indexado del sitemap antiguo debería disminuir mientras el conteo del sitemap nuevo aumente.

Return the translated content in
SEOJuice
Stay visible everywhere
Get discovered across Google and AI platforms with research-based optimizations.
Works with any CMS
Automated Internal Links
On-Page SEO Optimizations
Get Started Free

no credit card required

More articles

No related articles found.