Migración de sitio en Search Console: cambio de dirección, redirecciones y comprobación del tráfico tras el traslado
Para migrar un sitio web a una URL nueva en Search Console, verifica como propiedades tanto el sitio antiguo como el nuevo, redirige cada URL antigua a su equivalente nueva con un 301 permanente, envía un sitemap de las URLs nuevas en la propiedad nueva y, cuando cambie el dominio o el subdominio, presenta el traslado con la herramienta de cambio de dirección en Configuración de la propiedad antigua. Después, el trabajo es vigilar: la indexación y los clics deberían ir saliendo de la propiedad antigua y acumularse en la nueva, algo que según Google tarda unas semanas para la mayoría de las páginas de un sitio pequeño o mediano y más en uno grande. Este playbook cubre qué hacer antes, durante y después del traslado, y qué partes no cubre la herramienta de cambio de dirección.
Traslada un sitio a URLs nuevas y recupera su tráfico de Google, con prueba por URL de que las redirecciones funcionan.
Unos días de preparación, un día de lanzamiento y después revisiones semanales durante tres a seis meses.
Acceso de propietario a ambas propiedades de Search Console, acceso a las reglas de redirección del servidor y un crawler.
¿De qué tipo de traslado se trata?
Google trata un cambio de dominio, un paso a HTTPS y una nueva estructura de URLs como el mismo tipo de trabajo: un traslado de sitio con cambios de URL, en el que cada URL antigua necesita una redirección permanente a su URL nueva. La herramienta de cambio de dirección es solo una parte de ese trabajo, y solo para algunos traslados, así que conviene saber en qué fila de esta tabla estás antes de planificar nada. Todo lo que contiene procede de la guía de traslado de sitios de Google y de su página de ayuda sobre el cambio de dirección.
| Traslado | Redirecciones 301 | Herramienta de cambio de dirección |
|---|---|---|
| Dominio nuevo (example.com a example.net) | Sí, todas las URLs antiguas | Sí, para cada variante verificada del dominio antiguo, incluidas www y sin www |
| Subdominio nuevo (a.example.com a b.example.com) | Sí | Sí |
| Dominio entero a una carpeta de otro dominio (example.com a example3.com/new/location/) | Sí | Sí, Google permite este sentido |
| HTTP a HTTPS | Sí | No: "Google averiguará tus cambios por ti" |
| www a sin www en el mismo dominio | Sí, o etiquetas canónicas | No |
| Rutas nuevas en el mismo dominio (/blog/ a /articles/) | Sí, más sitemaps actualizados | No |
| Una subcarpeta como origen (example.com/petstore/ a cualquier destino) | Sí | No: las propiedades a nivel de ruta no se pueden trasladar |
| Nuevo hosting o CDN, mismas URLs | No, no se traslada nada | No: Google tiene una guía aparte para los traslados sin cambios de URL |
Google también te pide que cambies una sola cosa a la vez. Si planeas un dominio nuevo, un CMS nuevo y un diseño nuevo, su guía recomienda hacerlos uno después de otro, y la página sobre el cambio de dirección advierte de que combinar un traslado con una estructura de URLs nueva "probably" costará algo de tráfico mientras Google vuelve a aprender cada página. Elige para el traslado un periodo tranquilo si tu tráfico es estacional, porque así los problemas de arranque afectan a menos visitantes y queda más capacidad de servidor para Googlebot.
Antes del traslado: qué configurar en Search Console
- Verifica las dos propiedades, todas las variantes. La guía de Google dice que hay que "verificar todas las variantes de los sitios antiguo y nuevo", por ejemplo www y sin www, y HTTP y HTTPS si usas HTTPS. Una propiedad de dominio cubre todos los subdominios y ambos protocolos de una vez, y requiere verificación por DNS. La herramienta de cambio de dirección añade una regla más estricta: debes ser propietario de ambas propiedades y usar la misma cuenta de Google para gestionarlas. Comprueba también que la verificación sobrevive al traslado: un archivo de verificación HTML tiene que copiarse al sitio nuevo, y una etiqueta meta tiene que estar en las plantillas nuevas.
- Traspasa los ajustes y revisa un dominio comprado. Si subiste un archivo de disavow para el sitio antiguo, Google recomienda volver a subirlo en la propiedad nueva. Si el dominio nuevo se compró de segunda mano, busca acciones manuales y eliminaciones de URLs que haya dejado el propietario anterior, "especialmente una eliminación de URLs en todo el sitio".
- Construye el mapa de URLs. Anota a dónde va cada URL antigua. Google sugiere partir de tus sitemaps, los logs del servidor o la analítica, el informe de enlaces de Search Console y tu CMS, y recuerda incluir imágenes, vídeos, archivos JavaScript y CSS, que se trasladan como cualquier otra URL. Añade todas las páginas que tuvieron clics en el informe de rendimiento, pero ten en cuenta que la interfaz de Search Console exporta solo 1000 filas por tabla, así que en un sitio mayor necesitas la API para obtenerlas todas (consulta el límite de 1000 filas).
- Rastrea el sitio antiguo. Un rastreo completo con un crawler de escritorio te da el código de estado de cada URL antigua antes de que cambie nada, los enlaces internos que tendrás que actualizar y la lista contra la que probarás las redirecciones el día del lanzamiento. El propio Google menciona Screaming Frog para comprobar que las redirecciones funcionan como se espera. Guarda la lista de sitios que te enlazan, del informe de enlaces, mientras la propiedad antigua todavía la tenga, para poder pedir más tarde a los más valiosos que actualicen sus enlaces.
- Exporta una referencia. Exporta clics, impresiones y posición por página y por consulta de al menos los últimos 28 días, y de las mismas semanas del año anterior si tu tráfico es estacional. Después del traslado las cifras de la propiedad antigua desaparecen, y Search Console solo conserva 16 meses de datos (consulta la retención de datos), así que esta exportación es la que te dirá en el tercer mes si el sitio nuevo ha vuelto adonde estaba el antiguo.
- Prepara las páginas nuevas. Cada URL nueva necesita una etiqueta canónica autorreferenciada, las anotaciones hreflang necesitan las URLs nuevas, los enlaces internos deben apuntar directamente a las URLs nuevas y un sitemap de las URLs nuevas debe estar listo para enviarse. Si el sitio nuevo estaba oculto con un noindex o un bloqueo en robots.txt durante el desarrollo, haz ya la lista de lo que hay que quitar el día del lanzamiento. Las páginas eliminadas o fusionadas que no tengan sustituto deben responder 404 o 410.
El traslado: redirecciones 301, cambio de dirección y sitemaps
Redirige cada URL antigua, una a una, con un 301
Google recomienda redirecciones permanentes en el servidor, HTTP 301 o 308, desde cada URL antigua a la URL nueva de tu mapa. Su documentación sobre redirecciones explica por qué importa el tipo: con una redirección permanente "el proceso de indexación usa la redirección como señal de que el destino de la redirección debe ser canónico", mientras que con una 302, 303 o 307 temporal no lo hace, y la URL antigua puede seguir en los resultados. Apunta cada URL antigua directamente a su destino final. Googlebot sigue hasta 10 saltos, pero Google aconseja mantener una cadena en "idealmente no más de 3 y menos de 5", y una redirección directa es todavía mejor. No envíes muchas URLs antiguas a una sola página no relacionada, como la home nueva, algo que según Google "podría tratarse como un soft 404", aunque varias páginas antiguas consolidadas en una nueva sí pueden redirigir todas a ella. Google también tranquiliza al decir que las 301 y otras redirecciones permanentes "no provocan una pérdida de PageRank".
Prueba las redirecciones en cuanto estén activas. Google sugiere la herramienta de inspección de URLs para URLs sueltas y herramientas de línea de comandos o scripts para muchas, y cita las redirecciones a URLs inexistentes del sitio nuevo como uno de los errores de migración más habituales. Después activa lo que preparaste: quita el noindex de desarrollo y los bloqueos de robots.txt, y comprueba que las etiquetas canónicas del sitio nuevo usan las URLs nuevas.
Cómo usar la herramienta de cambio de dirección
Úsala solo cuando el sitio ya se haya trasladado y las redirecciones estén activas; la página de ayuda de Google dice "usa esta herramienta después de haber trasladado y redirigido tu sitio". Los requisitos, según esa página:
- Eres propietario de la propiedad antigua y de la nueva, con la misma cuenta de Google.
- La propiedad antigua está a nivel de dominio (example.com, m.example.com o http://example.com), no en una ruta como http://example.com/petstore/.
- Una 301 redirige la home antigua a la home nueva. Google recomienda además 301 para las páginas canónicas del sitio antiguo, y la herramienta comprueba que haya 301 en unas cuantas páginas antes de aceptar la solicitud.
Los pasos son breves. Abre la propiedad antigua, ve a Configuración → Cambio de dirección, elige la propiedad nueva en Seleccionar sitio nuevo y haz clic en Validar y actualizar. La herramienta ejecuta sus comprobaciones previas: un fallo en una comprobación crítica hay que corregirlo para poder continuar, mientras que un fallo en una no crítica muestra una advertencia y deja pasar la solicitud. Cuando se acepta, ambas propiedades muestran un aviso de que el traslado está en curso durante 180 días. Repite la solicitud para cada variante del dominio antiguo que hayas verificado, porque la herramienta traslada todos los protocolos de la propiedad que indiques, pero ninguno de los subdominios que cuelgan de ella, www incluido.
La versión corta de estos mismos pasos está en la pregunta frecuente Cómo usar la herramienta de cambio de dirección.
Qué hace la herramienta de cambio de dirección y qué no cubre
Según Google, un cambio de dirección le indica que rastree e indexe el sitio nuevo con preferencia sobre el antiguo, traslada las señales del sitio antiguo al nuevo y hace que Google prefiera el sitio nuevo al elegir las páginas canónicas, durante 180 días desde la solicitud. No sustituye ninguna parte del trabajo de redirecciones, y tiene límites claros:
| No cubierto | Qué dice Google que hay que hacer en su lugar |
|---|---|
| HTTP a HTTPS, www a sin www, rutas dentro de un mismo sitio | Redirecciones (y etiquetas canónicas para www), con sitemaps actualizados. |
| Una subcarpeta como origen | Solo redirecciones: las propiedades a nivel de ruta no se pueden trasladar. |
| Subdominios por debajo de la propiedad, www incluido | Verifica cada variante y presenta una solicitud para cada una, "aunque no estés usando activamente estas variantes". |
| Un segundo traslado justo después del primero (de A a B y luego de B a C) | No encadenes traslados: la segunda solicitud no puede ir inmediatamente después. |
| Varios sitios fusionados en uno (A, B y C en D) | Traslada un sitio cada vez y espera a que el tráfico se asiente antes del siguiente. |
| Eliminar el sitio antiguo del índice | La herramienta no lo borra. Las redirecciones y las etiquetas canónicas reducen las URLs antiguas que se muestran. |
| Cualquier cosa pasados 180 días | Después de eso Google "trata el sitio antiguo como un sitio no relacionado" si todavía se puede rastrear, así que las redirecciones tienen que seguir haciendo el trabajo. |
Si cambias de opinión, una solicitud se puede cancelar dentro de esos 180 días: quita las redirecciones de lo antiguo a lo nuevo, añade redirecciones del sitio nuevo al antiguo y haz clic en Cancelar traslado en la herramienta de cambio de dirección de la propiedad antigua.
Sitemaps para las URLs antiguas y las nuevas
Envía el sitemap con las URLs nuevas en la propiedad nueva el día del lanzamiento. La guía de Google sugiere además enviar un segundo sitemap con las URLs antiguas, como medidor: al principio el sitemap nuevo no tiene páginas indexadas y el antiguo tiene muchas, y con el tiempo el recuento del antiguo baja a cero mientras el del nuevo sube. Search Console avisará de que las URLs del sitemap antiguo redirigen, y Google dice "esto es normal y puedes ignorar estas advertencias". Es la única excepción a la regla habitual de que un sitemap solo lista URLs finales (consulta Página con redirección), y es temporal: cuando el recuento de indexadas del sitemap antiguo esté cerca de cero, elimínalo y deja solo el nuevo.
Mantén las redirecciones durante mucho tiempo. La guía de traslado de sitios dice "por lo general, al menos 1 año" para que todas las señales puedan transferirse, y sugiere mantenerlas indefinidamente para los usuarios; la página sobre el cambio de dirección fija un mínimo de 180 días, más si las URLs antiguas aún reciben tráfico de la Búsqueda de Google, y recomienda pagar el dominio antiguo al menos un año para que nadie más pueda comprarlo y hacer mal uso de él.
Después del traslado: qué revisar en Search Console, semana a semana
El consejo de Google sobre el seguimiento se resume en un patrón: "Lo ideal es que el tráfico del sitio antiguo baje, mientras que el del sitio nuevo suba". El calendario de abajo es cómo reparto esas comprobaciones durante los primeros meses. Los plazos son mi práctica de trabajo, no los de Google; Google solo dice que un sitio pequeño o mediano "puede tardar unas semanas en trasladar la mayoría de sus páginas" y que los sitios más grandes tardan más, según el número de URLs y la velocidad del servidor.
| Cuándo | Dónde en Search Console | Qué quieres ver |
|---|---|---|
| Día del lanzamiento | Inspección de URLs (prueba en vivo) en la home antigua y en tus principales URLs antiguas; Sitemaps en la propiedad nueva; Cambio de dirección en la antigua | Las URLs antiguas redirigen en un salto a la página asignada, el sitemap nuevo se acepta y la solicitud de traslado supera sus comprobaciones. |
| Semana 1 | Rendimiento en ambas propiedades; Indexación de páginas en la propiedad nueva; Estadísticas de rastreo | Primeras impresiones y clics en URLs nuevas, sin pico de No encontrada (404) ni de Error de redirección, y Googlebot rastreando más de lo habitual sin errores de servidor. |
| Semanas 2 a 4 | Sitemaps (ambos); Indexación de páginas (ambas) | El recuento de indexadas del sitemap nuevo sube y el del antiguo baja; Página con redirección crece en la propiedad antigua. |
| Meses 2 y 3 | Rendimiento frente a tu exportación de referencia | Los clics diarios de la propiedad nueva se acercan a los que tenía la antigua; las URLs antiguas van desapareciendo de los resultados. |
| Mes 6 | Rendimiento en la propiedad antigua | Poco o ningún tráfico en las URLs antiguas a medida que se agotan los 180 días del cambio de dirección. |
| Mes 12 | Ninguna: una decisión | Las redirecciones siguen activas; mantenlas mientras las URLs antiguas reciban visitas o enlaces. |
Indexación de lo antiguo frente a lo nuevo. El informe de indexación de páginas (la guía de Google todavía lo llama Index Coverage) debería mostrar el recuento de indexadas bajando en la propiedad antigua y subiendo en la nueva. En la propiedad antigua, el estado que cabe esperar es Página con redirección, que Google define como "una URL no canónica que redirige a otra página", y añade que esa URL "no se indexará" mientras que su destino "puede indexarse o no". Ese estado es el traslado funcionando, no un fallo. Los que hay que atender son Error de redirección, que Google enumera como una cadena demasiado larga, un bucle de redirecciones, una URL de redirección que superó la longitud máxima o una URL errónea o vacía en la cadena, y un número inusual de URLs No encontrada (404) en el sitio nuevo, lo que suele indicar redirecciones que apuntan a páginas que no existen. Para una URL concreta, la herramienta de inspección de URLs muestra si Google ha visto la redirección y qué canónica ha elegido; el playbook de indexación técnica cubre los demás estados.
El tráfico pasando de una propiedad a otra. Search Console mantiene separadas las dos propiedades, así que el informe de rendimiento nunca muestra el traslado como una sola línea: la propiedad antigua pierde clics mientras la nueva los gana, y eres tú quien suma ambas, por día, para ver si el total se sostiene. Compara por día y no por periodo, porque las ventanas anterior y posterior al lanzamiento rara vez tienen la misma duración, y deja fuera los dos o tres últimos días, que Search Console aún está completando. Si la propiedad antigua sigue acumulando una gran parte de las impresiones un mes después del lanzamiento, faltan redirecciones o Google todavía no ha vuelto a rastrear esas URLs; el aviso de cambio de dirección en la propiedad nueva también dice "otros sitios se están trasladando a este sitio", y Google explica que su tráfico crece a medida que los usuarios son redirigidos desde la antigua.
Carga del servidor. Google advierte de que tras una migración rastreará el sitio nuevo "más intensamente de lo habitual", porque los rastreos del sitio antiguo se redirigen además del rastreo normal. El informe de estadísticas de rastreo en Configuración muestra esa carga, y un aumento de errores de servidor ahí significa que el nuevo hosting necesita más capacidad.
Cómo ayuda GSC Wizard: Migration Compare
Search Console muestra cada propiedad por separado, que es justo lo que hace tan difícil juzgar una migración en él. El informe Migration Compare de GSC Wizard reúne en un solo análisis la configuración antigua (lado A, antes de la fecha de salida en producción) y la nueva (lado B, después de ella). Está en Análisis del sitio en el menú izquierdo de una propiedad y en el menú principal, y gestiona tres tipos de traslado: Propiedad frente a propiedad para un cambio de dominio o un paso a HTTPS entre dos propiedades, Prefijos de URL para el traslado de una carpeta dentro de una misma propiedad y Patrones regex para una estructura de URLs nueva. No se descarga nada hasta que haces clic en Ejecutar análisis.
- Un veredicto frente a una migración encarrilada. Con una fecha de salida en producción, el banner de salud de la migración ofrece la recuperación (los clics diarios del lado nuevo como porcentaje de los del lado antiguo antes de la salida), el ritmo frente a la etapa esperada, el impulso, una puntuación de riesgo de 0 a 100 y el éxito de las URLs, con un estado de Saludable, En recuperación, En riesgo, Crítico o Datos insuficientes. Las etapas esperadas son reglas empíricas que incorporé al informe, como el 60 % de los clics antiguos al día 56 y el 90 % al día 180, no una promesa para un sitio concreto. La página sobre salud, recuperación y riesgo explica cada cifra.
- Tu mapa de URLs, comprobado en el servidor real. Sube el mapa de lo antiguo a lo nuevo como CSV (hasta 10.000 filas por archivo, hasta 50.000 por análisis) y haz clic en Verificar redirecciones. GSC Wizard solicita cada URL antigua, sigue hasta cinco saltos, respeta robots.txt y da a cada asignación un veredicto: Migrada, Cadena de redirecciones, Redirección temporal, Destino incorrecto, Sin redirigir, Destino roto, URL antigua rota, Bucle de redirecciones, Conservada o Desconocida. También señala las redirecciones a la home, los destinos con noindex y las canónicas que aún apuntan al sitio antiguo. Consulta mapas de redirecciones y verificación.
- La vista de Google sobre el traslado. El botón Inspeccionar en Google ejecuta la inspección de URLs sobre los 20 a 200 principales pares de URL antigua y nueva, y sitúa cada par en una etapa del traspaso, desde Redirección aún sin ver hasta Canónica trasladada.
- Adónde fue el tráfico. Páginas, consultas, secciones de URL, países, dispositivos y tipos de búsqueda antes y después, además de una lista de comprobación del lanzamiento y hasta 12 recomendaciones ordenadas por los clics en juego. Cuando el dominio cambió y las URLs antiguas siguen acumulando impresiones, una de esas recomendaciones es presentar el cambio de dirección en Search Console.
- Alertas tras el lanzamiento. Guarda la migración y activa Alertas, y una nueva comprobación diaria vuelve a verificar las redirecciones y publica en Slack, Microsoft Teams o un webhook cuando aparecen nuevos problemas de redirección o cuando la recuperación se estanca o cae. Consulta guardar, compartir y alertas.
Qué necesita y qué no hace
El veredicto de salud, la curva de recuperación, la puntuación de riesgo y las recomendaciones necesitan una fecha de lanzamiento y al menos un día posterior al lanzamiento con datos finales, y la recuperación necesita al menos 10 clics en la ventana anterior. Las comprobaciones de redirección solo solicitan URLs de los hosts de las propiedades a las que tienes acceso, así que añade a GSC Wizard tanto el sitio antiguo como el nuevo, y deja pasar al crawler GSCWizard-Bot por cualquier firewall, o las URLs antiguas aparecerán como rotas. Solo el propietario de una propiedad puede iniciar una ejecución de Inspeccionar en Google, que usa la cuota de inspección de URLs de 2000 llamadas por propiedad y día. Las alertas necesitan una migración guardada (hasta 50) y llegan solo a la cuenta que la guardó, a través de sus suscripciones de Slack, Teams o webhook, no por correo electrónico. En el modo Propiedad frente a propiedad, las mismas ventanas se pueden leer desde Bing Webmaster Tools, que necesita una clave de API de Bing y cubre unos 16 meses en una propiedad consolidada. GSC Wizard no presenta por ti el cambio de dirección, no configura redirecciones en tu servidor, y la comprobación integrada solo sigue redirecciones HTTP, de modo que una redirección por JavaScript o por meta refresh aparece como Sin redirigir. Comprueba las URLs de tu mapa en lugar de rastrear todo el sitio, así que para el rastreo completo previo al lanzamiento es mejor un crawler de escritorio como Screaming Frog, y su exportación se puede importar al informe.
Migration Compare forma parte de todos los planes, y todos los planes empiezan con una prueba gratuita de 7 días (consulta los precios). También ayuda con el problema de la referencia del paso de preparación: una propiedad almacenada en GSC Wizard conserva hasta 10 años de historial en lugar de los 16 meses de Search Console, así que la ventana anterior de un dominio antiguo sigue ahí mucho después de que Google la haya descartado.
Pregunta a un asistente de IA sobre la migración
Con GSC Wizard conectado a Claude, ChatGPT u otro cliente MCP, el mismo análisis está disponible como herramientas, así que un asistente responde a partir de los datos medidos en lugar de adivinar.
| Herramienta | Qué hace |
|---|---|
| list_migrations | Lista las migraciones guardadas en la app, con la última instantánea de salud de la comprobación diaria. |
| get_migration_health | La comprobación de salud de la app para una fecha de salida en producción o una migración guardada: recuperación, ritmo, impulso, hitos proyectados, éxito de las URLs, la puntuación de riesgo y sus factores, recomendaciones, recuentos de estado de las redirecciones a partir de las comprobaciones almacenadas y la lista de comprobación. Analiza hasta 10.000 asignaciones de redirección por llamada. |
| compare_migration | Comparación antes y después en cualquiera de los tres modos, con tendencia diaria, totales por lado y las consultas y páginas ganadoras y perdedoras. |
| add_migration_redirects | Guarda asignaciones de lo antiguo a lo nuevo para un par de propiedades, hasta 10.000 filas por llamada. Las filas se añaden al final, así que enviar dos veces la misma lista la almacena dos veces. list_migration_redirects y delete_migration_redirects gestionan lo almacenado. |
Las herramientas MCP leen las comprobaciones de redirecciones almacenadas por la app; no ejecutan comprobaciones nuevas por sí mismas, así que haz clic primero en Verificar redirecciones en la app. La documentación del MCP lista todas las herramientas.
List my saved migrations, then run a health check on the shop
replatform. Tell me which three fixes matter most, with the clicks
at stake for each, and state the go-live date and both windows.Preguntas frecuentes
¿Cómo migro un sitio web a una URL nueva en Search Console?
Verifica como propiedades en Search Console el sitio antiguo y el nuevo, incluidas todas las variantes que uses, y redirige cada URL antigua a su equivalente nueva con una redirección permanente en el servidor (301 o 308). Envía un sitemap de las URLs nuevas en la propiedad nueva. Si cambia el dominio o el subdominio, abre la herramienta de cambio de dirección en Configuración de la propiedad antigua, selecciona el sitio nuevo y ejecuta Validar y actualizar. Después vigila ambas propiedades: la indexación y el tráfico deberían caer en la antigua y subir en la nueva.
¿Necesito la herramienta de cambio de dirección para pasar de HTTP a HTTPS?
No. La página de ayuda de Google dice que no se use la herramienta para pasar de http a https: sigue la guía de traslado de sitios y Google averiguará el cambio por sí mismo. Tampoco sirve para pasar de www a sin www en el mismo dominio, para mover rutas dentro de un mismo sitio ni para un cambio de hosting o CDN sin cambios de URL.
¿Puedo usar el cambio de dirección para trasladar una subcarpeta?
No como origen. La herramienta solo funciona con propiedades a nivel de dominio, como example.com, m.example.com o http://example.com, y Google dice que no se pueden trasladar propiedades a nivel de ruta, como http://example.com/petstore/. El otro sentido sí está permitido: un dominio entero puede trasladarse a una ruta de otro dominio, como example.com a example3.com/new/location/. El traslado de una carpeta dentro de un mismo sitio solo necesita redirecciones y sitemaps actualizados.
¿Cuánto tarda en verse en Search Console una migración de sitio?
La guía de traslado de sitios de Google dice que un sitio web pequeño o mediano puede tardar unas semanas en trasladar la mayoría de sus páginas, y que los sitios más grandes tardan más, según el número de URLs y la velocidad del servidor. El traslado se produce URL a URL y solo está completo cuando Googlebot ha visitado al menos una vez cada URL antigua y nueva. Una solicitud de cambio de dirección sigue funcionando durante 180 días.
¿Cuánto tiempo debo mantener las redirecciones 301 tras trasladar un sitio?
La guía de traslado de sitios de Google dice que, por lo general, al menos un año, para que todas las señales puedan transferirse, y sugiere mantenerlas indefinidamente para los usuarios. La página de ayuda del cambio de dirección fija un mínimo de 180 días, más si las URLs antiguas aún reciben tráfico de la Búsqueda de Google, y recomienda pagar el dominio antiguo al menos un año para que nadie más pueda comprarlo y hacer mal uso de él.
¿Debo conservar el sitemap antiguo tras la migración de un dominio?
Durante un tiempo, como herramienta de medición. Google sugiere enviar un sitemap de las URLs antiguas junto al nuevo, para que puedas ver cómo el recuento de indexadas del antiguo baja hacia cero mientras el del nuevo sube, y dice que las advertencias de redirección en el sitemap antiguo son normales. Cuando el recuento antiguo esté cerca de cero, elimínalo y deja solo el sitemap con las URLs nuevas.
¿Por qué mi sitio antiguo sigue apareciendo en Google tras el traslado?
Porque el traslado se produce URL a URL y una URL antigua solo desaparece después de que Googlebot la vuelve a rastrear y ve la redirección. Google también dice que la herramienta de cambio de dirección no borra el sitio antiguo del índice, y que las URLs antiguas pueden seguir apareciendo cuando no tienen una página equivalente en el sitio nuevo. Las redirecciones y las etiquetas canónicas autorreferenciadas en las páginas nuevas reducen el número de URLs antiguas mostradas.
¿Puede GSC Wizard presentar el cambio de dirección por mí?
No. El cambio de dirección se presenta a mano en Search Console. GSC Wizard mide la migración: su informe de comparación de migraciones lee la propiedad antigua y la nueva en torno a la fecha de lanzamiento, comprueba en el servidor en vivo cada redirección de tu mapa, puntúa la recuperación y el riesgo, y puede avisarte en Slack, Microsoft Teams o un webhook cuando fallan las redirecciones o la recuperación se estanca.
Siguiente playbook
Cuando la migración se haya asentado, busca las páginas que nunca se recuperaron del todo y las que a Google todavía le cuesta indexar: corrige los problemas técnicos de indexación →
Mide tu migración, no te limites a presentarla
Compara la propiedad antigua y la nueva en torno al lanzamiento, verifica cada redirección de tu mapa y recibe una alerta cuando la recuperación se estanque. Prueba gratuita de 7 días, sin tarjeta de crédito.
Escrito por Jan-Willem Bobbink · Publicado el 4 de noviembre de 2026 · Actualizado el 4 de noviembre de 2026