TL;DR: Migramos seojuice.io a seojuice.com en enero de 2026. El tráfico cayó 40% en la primera semana. En 2 meses pasamos de 694 impresiones/día a 7,853. En este artículo te cuento cada error que cometimos, cada ajuste que aplicamos y la línea de tiempo exacta de la recuperación para que no repitas nuestros peores momentos.
En enero de 2026, movimos SEOJuice del dominio .io al .com. Las razones eran bastante simples: .com transmite más confianza, se recuerda mejor como marca y ya estábamos cansados de explicar qué significa ".io" a clientes potenciales no técnicos.
Yo sabía que iba a doler. He ayudado a decenas de clientes con migraciones de dominio. Me había leído toda la documentación de Google sobre el tema. Pensé que estábamos preparados.
No lo estábamos.
Día uno: las impresiones cayeron 40%. Para el día tres, algunas de nuestras páginas con mejor rendimiento habían desaparecido por completo del índice. Nuestra palabra clave principal — la que generaba 30% del tráfico orgánico — pasó de la posición 4 a dejar de posicionar por completo.
Esta es la línea de tiempo de lo que realmente pasó:
| Periodo | Impresiones/Día | Clics/Día | Qué estaba pasando |
|---|---|---|---|
| Antes de la migración | 694 | 31 | Línea base en el dominio .io |
| Semana 1 | ~420 | 14 | Caída inicial. Google todavía indexaba las URL antiguas |
| Semana 2-3 | ~580 | 22 | Google estaba procesando las redirecciones. Mezcla de URL viejas y nuevas en el índice |
| Semana 4-6 | 1,200 | 48 | Empieza la recuperación. El nuevo dominio empieza a ganar tracción |
| Mes 2 | 4,100 | 165 | Superando la línea base anterior. Las mejoras de contenido empiezan a notarse |
| Mes 3 (ahora) | 7,853 | 312 | 11x las impresiones originales. Recuperación total + crecimiento |
La recuperación no fue solo cuestión de esperar a que la migración se asentara. Aprovechamos la migración para corregir años de deuda técnica acumulada, mejorar la calidad del contenido y reorganizar nuestro enlazado interno. Pero la migración en sí fue la parte difícil — y en eso se centra este artículo.
Esta es la checklist que me habría gustado seguir con más cuidado. Hicimos la mayor parte, pero los puntos que se nos escaparon nos costaron semanas de recuperación.
| Antes de la migración | Durante la migración | Después de la migración |
|---|---|---|
| Haz un rastreo completo del sitio antiguo y exporta todas las URL | Implementa redirecciones 301 para cada URL | Verifica las redirecciones con un rastreo completo |
| Crea un mapa completo de redirecciones (URL antigua → URL nueva) | Actualiza las etiquetas canonical al nuevo dominio | Envía el nuevo sitemap en GSC |
| Exporta los datos de Google Search Console | Actualiza los enlaces internos al nuevo dominio | Usa la herramienta de cambio de dirección en GSC |
| Documenta todos los backlinks (origen + URL de destino) | Actualiza sitemap.xml con las nuevas URL | Monitorea la cobertura del índice a diario durante 2 semanas |
| Configura el nuevo dominio en GSC y en tu herramienta de analítica | Actualiza robots.txt en el nuevo dominio | Revisa errores de rastreo en GSC |
| Avisa a tus socios clave de backlinks sobre el cambio | Verifica el certificado SSL en el nuevo dominio | Pide a los principales dominios que te enlazan que actualicen los backlinks |
| Prueba las redirecciones en un entorno de staging | Actualiza perfiles sociales y listados en directorios | Mantén el dominio antiguo redirigiendo durante 12+ meses |
Conclusión clave
El punto más importante de todos: mantén el dominio antiguo redirigiendo al menos durante 12 meses. Google recomienda mantener las redirecciones por lo menos 180 días, pero más tiempo es mejor. Nosotros vamos a mantener seojuice.io redirigiendo de forma indefinida — no hay ninguna razón para no hacerlo.
Este es el principal motivo por el que una migración sale mal. Cada URL del dominio antiguo necesita una redirección 301 hacia su equivalente en el nuevo dominio. No a la home. No a una redirección genérica. A la página equivalente exacta.
Haz un rastreo del dominio antiguo. Para cada URL, revisa si hace una redirección 301 correcta hacia la nueva URL correspondiente. Usa nuestro comprobador de enlaces rotos o Screaming Frog cargando una lista de URL.
Para Apache (.htaccess):
# Redirect entire old domain to new domain (preserving paths)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?olddomain\.io [NC]
RewriteRule ^(.*)$ https://newdomain.com/$1 [R=301,L]
# Individual page redirects (when URL structure changed)
Redirect 301 /old-blog/post-slug https://newdomain.com/blog/post-slug/
Redirect 301 /services/old-page https://newdomain.com/solutions/new-page/Para Cloudflare (Redirect Rules):
# Cloudflare Redirect Rule (Single Redirect)
# Match: hostname equals "olddomain.io"
# Then: Dynamic redirect to https://newdomain.com + URI Path
# Status: 301 (Permanent)
# For Cloudflare Bulk Redirects (CSV format):
olddomain.io/blog/old-post,https://newdomain.com/blog/new-post,301
olddomain.io/about,https://newdomain.com/about/,301Para Nginx:
server {
server_name olddomain.io www.olddomain.io;
return 301 https://newdomain.com$request_uri;
}"Definitivamente necesitas configurar redirects, al menos para las páginas importantes. Sin ellos, tendrás una mezcla de URL antiguas y nuevas en los resultados de búsqueda, y las URL viejas enviarán tráfico a tu página 404. Idealmente, elige redirects permanentes del lado del servidor — 308 o 301. Evita los redirects con JavaScript."
Después de implementar las redirecciones, revisa cada URL de tu sitemap antiguo. La respuesta debe ser un único 301 hacia la nueva URL correcta. Ojo con las cadenas de redirecciones (301 → 301 → 200) — diluyen la autoridad de enlaces y añaden latencia.
Este fue el que nos pegó a nosotros. Configuramos redirecciones externas perfectas, pero olvidamos actualizar los enlaces internos dentro del contenido del blog. Cientos de enlaces internos seguían apuntando a seojuice.io, creando saltos de redirección innecesarios en cada carga de página.
Haz un rastreo del sitio nuevo y filtra cualquier enlace interno que contenga el dominio antiguo. También busca la cadena del dominio viejo en tu base de datos o CMS.
Haz un search-and-replace en toda tu base de datos. En WordPress:
# Using WP-CLI (recommended approach)
wp search-replace 'https://olddomain.io' 'https://newdomain.com' --all-tables --dry-run
# Review output, then run without --dry-run:
wp search-replace 'https://olddomain.io' 'https://newdomain.com' --all-tables
# Also catch http:// variants
wp search-replace 'http://olddomain.io' 'https://newdomain.com' --all-tablesVuelve a hacer un rastreo del sitio. Cero enlaces internos deberían referenciar el dominio antiguo.
Si tu sitemap.xml todavía lista URL del dominio antiguo, le estás diciendo a Google “estas son mis páginas”, mientras que tus redirecciones dicen “en realidad, ve para allá”. Esas señales mezcladas ralentizan la reindexación.
Abre https://newdomain.com/sitemap.xml y revisa cada URL. Si alguna empieza con el dominio antiguo, el sitemap está desactualizado.
Revisa GSC → Sitemaps. El estado debería mostrar “Success” con el conteo correcto de URL.
Las etiquetas canonical son fáciles de pasar por alto porque el usuario no las ve. Pero si tus etiquetas canonical siguen apuntando al dominio antiguo, le estás diciendo a Google que el dominio viejo es la versión “real” — contradiciendo directamente tus redirecciones.
Abre el código fuente de varias páginas del sitio nuevo. Busca <link rel="canonical" y verifica que el href use el nuevo dominio.
Haz una revisión rápida de 10-20 páginas en distintas plantillas (home, post del blog, categoría, producto). Cada etiqueta canonical debe apuntar al nuevo dominio.
Incluso con redirecciones y etiquetas canonical perfectas, Google tarda en procesar un cambio de dominio. Es normal. Nuestra reindexación tomó unas 3 semanas para la mayoría de las páginas y 6 semanas para el long tail.
En GSC, ve a Index → Pages. Observa el conteo de “Indexed” en la nueva propiedad. Debería subir de forma constante. Si se estanca o cae, algo está bloqueando el rastreo.
"Actualiza la dirección URL en Google Search Console durante la migración, no antes — Google necesita contenido en el nuevo sitio para poder procesarlo. Debes esperar algunos cambios visibles en cómo se muestra tu contenido en búsqueda, definitivamente a corto plazo. Incluso si haces los cambios de URL perfectos, vas a ver cambios."
Haz seguimiento diario de: cantidad de páginas indexadas en GSC, estadísticas de rastreo y la proporción de URL del dominio viejo vs. el nuevo que aparecen en resultados de búsqueda (busca site:newdomain.com y site:olddomain.io).
Tus backlinks apuntan al dominio antiguo. Con redirecciones 301, Google transfiere la mayor parte (pero no toda) de esa autoridad a la nueva URL. La pérdida es pequeña por enlace, pero se acumula cuando tienes cientos de backlinks.
Exporta tu perfil de backlinks desde Ahrefs, Semrush o GSC. Revisa cuántos siguen apuntando al dominio antiguo frente al nuevo. Tres meses después de la migración, esa proporción ya debería estar moviéndose hacia el nuevo dominio.
Monitorea tu perfil de backlinks cada mes. El porcentaje de backlinks que apuntan directamente al nuevo dominio debería aumentar con el tiempo. Usa nuestro domain authority checker para seguir la transferencia de autoridad.
La investigación muestra que las migraciones de dominio pueden tardar entre 30 días y 523 días en recuperarse por completo. La variación es enorme porque todo depende de qué tan bien ejecutes el proceso. Esto es lo que suele verse en una migración bien hecha, semana por semana:
| Periodo | Qué es normal | Qué es una señal de alerta |
|---|---|---|
| Semana 1 | Caída de tráfico de 20-40%. Fluctuaciones de rankings en términos clave. Las URL antiguas todavía aparecen en las SERP | Caída de tráfico de 70%+. Desindexación completa. Errores 404 en GSC |
| Semana 2-3 | El tráfico se estabiliza. Las URL del nuevo dominio reemplazan a las antiguas en el índice. Los rankings regresan | El tráfico sigue cayendo. La cobertura del índice no aumenta. Errores de redirección en GSC |
| Semana 4-6 | El tráfico se acerca a los niveles previos a la migración. La mayoría de páginas ya se reindexaron. Rankings estabilizándose | Sigues por debajo de 50% de la línea base. Muchas páginas no están indexadas. Los errores de rastreo aumentan |
| Mes 2-3 | Recuperación completa o por encima de la línea base. Todas las páginas importantes indexadas en el nuevo dominio | Páginas importantes siguen sin indexarse. Los rankings no se recuperan para términos clave |
| Mes 6+ | El dominio antiguo casi no aparece en las SERP. Los backlinks se actualizan gradualmente. El long tail ya se recuperó por completo | El dominio antiguo sigue apareciendo para muchas consultas. Las métricas de autoridad caen |
Si tu migración salió mal y estás viendo señales de alerta, corrige esto en este orden:
La parte más difícil de una migración es saber cuándo la caída es normal y cuándo algo realmente está roto.
Espera si:
Entra en pánico (y corrige de inmediato) si:
Conclusión clave
Una caída de tráfico de 20-40% en la semana 1 es normal y esperable. Una caída de 70%+, o cualquier caída que no empiece a recuperarse para la semana 3, significa que hay un problema técnico. Revisa redirecciones, robots.txt y etiquetas canonical, en ese orden.
Mirando nuestra propia migración en retrospectiva, esto es lo que cambiaría:
Google recomienda al menos 180 días. Yo recomiendo para siempre, o al menos mientras el costo de registrar el dominio siga siendo insignificante. No hay ninguna desventaja en mantener las redirecciones activas, y los backlinks antiguos seguirán transfiriendo autoridad a través de la redirección.
301 (permanente). Siempre. Un 302 le dice a Google que el cambio es temporal, lo que significa que Google mantiene las URL antiguas en el índice y no transfiere por completo la autoridad de enlaces. Para un cambio permanente de dominio, 301 es la única opción correcta. John Mueller también menciona 308 como equivalente a 301.
Temporalmente, sí. La mayoría de los sitios ven una caída de tráfico de 20-40% en la primera semana. Si la ejecución es correcta, la recuperación empieza entre 2-4 semanas. Los estudios muestran que 83% de las migraciones de dominio bien ejecutadas se recuperan por completo dentro de 6 meses. El 17% que no lo logra normalmente arrastra problemas técnicos persistentes (redirecciones rotas, problemas de etiquetas canonical).
Google recomienda claramente que no. Cambia una cosa a la vez. Mueve primero el dominio, deja que se estabilice durante 2-3 meses y luego reestructura las URL. Hacer ambas cosas al mismo tiempo vuelve casi imposible diagnosticar problemas cuando algo sale mal.
No reconstruir, pero sí actualizar. Las redirecciones 301 transfieren la mayor parte de la autoridad, así que tus backlinks existentes siguen contando. Pero contactar a los principales dominios que te enlazan para que actualicen los enlaces directamente (eliminando el salto de la redirección) preserva más autoridad y mejora la eficiencia de rastreo.
La herramienta de cambio de dirección en Google Search Console le dice explícitamente a Google que tu sitio se movió de un dominio a otro. No es estrictamente obligatoria — Google puede detectar el cambio solo con redirecciones 301 — pero acelera el proceso de forma importante. Transfiere señales del dominio antiguo al nuevo, refuerza el rastreo del nuevo dominio y sigue funcionando durante 180 días. Úsala.
Toda migración de dominio duele. Incluso las perfectamente ejecutadas. Google tiene que volver a rastrear, reprocesar y reasignar confianza a un dominio nuevo. Eso toma tiempo.
La diferencia entre una migración que se recupera en 3 semanas y otra que tarda un año está en la calidad de la ejecución: mapas de redirecciones completos, enlaces internos actualizados, etiquetas canonical correctas y la herramienta de cambio de dirección de GSC. No hay atajo ni truco mágico.
Nosotros salimos más fuertes porque tratamos la migración como una oportunidad para arreglar todo lo que ya estaba mal. Si estás por migrar, haz lo mismo. Limpia tu deuda técnica, mejora tu contenido y corrige tu enlazado interno de una vez. Ya estás pasando por el dolor — al menos sal del otro lado con un sitio mejor.
no credit card required
No related articles found.