Una web nueva sale un viernes y el lunes el teléfono suena menos. Casi nunca es el diseño: es que Google ha perdido el rastro de las páginas que antes le traían clientes.
Este artículo es el método que sigo para que eso no pase. Y no lo escribo desde la teoría: mientras lo actualizo estoy preparando una migración en mi propia web, la de mis páginas de Colombia, y te enseño el mapa real con sus trampas.
Qué es una migración SEO
Una migración SEO es el trabajo de cambiar URLs, dominio, plataforma o estructura de una web de forma que Google traslade a las direcciones nuevas lo que ya tenían ganado las antiguas.
No todas las migraciones pesan lo mismo. Lo que decide el riesgo es cuántas URLs cambian y cuánto cambia lo que hay dentro de ellas.
| Tipo de migración | Qué cambia | Riesgo |
|---|---|---|
| De HTTP a HTTPS | Solo el protocolo; las rutas se quedan igual | Bajo |
| Rediseño o nueva arquitectura de URLs | Rutas, menús y enlaces internos | Medio |
| Cambio de CMS o plataforma | Rutas, plantillas, código y a menudo el contenido | Medio-alto |
| Cambio de dominio | Todo lo anterior y además la dirección de la marca | Alto |
← Desliza lateralmente para ver más →
Si tu caso combina dos filas, por ejemplo un rediseño que además cambia de plataforma, trátalo con el riesgo de la más alta.
Por qué se pierde tráfico en una migración
Se pierde tráfico cuando Google encuentra direcciones que ya no existen, enlaces que no llevan a ninguna parte o páginas nuevas que ya no responden a lo que la gente buscaba.
Las tres causas habituales:
- URLs antiguas sin redirección. Google llega, encuentra un error y deja de mostrar la página.
- Redirecciones mal apuntadas. Todo a la home, o a una página que no tiene nada que ver. Para Google es casi lo mismo que un error.
- Contenido que cambia demasiado. La URL redirige bien, pero la página nueva ya no responde a la búsqueda por la que rankeaba la antigua.
La tercera es la más traicionera, porque las herramientas te dicen que todo está correcto.
Antes de tocar nada, la línea base
La línea base es la foto de cómo está tu web antes de migrar: qué páginas existen, cuáles traen visitas y cuáles reciben enlaces de fuera.
Sin ella no puedes saber después si algo ha ido mal, ni qué página fue. Yo la hago en tres pasos:
- Rastrea la web entera con un crawler como Screaming Frog, para tener el inventario completo de URLs, incluidas las que ya redirigen.
- Exporta de la consola de Google para propietarios de webs el rendimiento por página y por consulta del periodo más largo que te deje. Guárdalo en tu propia hoja: Google no conserva ese histórico para siempre, y después de migrar vas a necesitar comparar cada URL antigua con su nueva.
- Marca las páginas que no te puedes permitir perder: las que traen clientes, las que reciben enlaces externos y las que convierten.
Si tienes un ecommerce, añade las categorías con filtros: son las que más URLs generan sin que nadie se dé cuenta. Si tienes una web de servicios pequeña, el inventario puede caber en una hoja, y no por eso es menos necesario.
El mapa de redirecciones va una a una y al destino final
El mapa de redirecciones es la tabla que dice, para cada URL antigua, a qué URL nueva equivalente debe llevar con una redirección permanente 301.
Tres reglas que no negocio:
- Una a una. Cada URL antigua va a su equivalente más parecida. Mandarlo todo a la home es la forma más rápida de perder lo que tenías.
- Permanentes. Si el cambio no se va a deshacer, la redirección es 301 (o 308). Una 302 le dice a Google que es temporal y que siga mostrando la dirección antigua.
- Al destino final. Sin saltos intermedios.
La tercera es la que más se incumple. La documentación de Google sobre traslados de sitio (actualizada en septiembre de 2026) pide evitar las secuencias de redirecciones, apuntar siempre al destino final y, si no queda más remedio, que haya menos de tres saltos y nunca más de cinco. También recomienda conservar las redirecciones al menos un año.
La trampa que casi nadie revisa son las redirecciones que ya tenías
Cuando una web ha tenido vida, ya arrastra redirecciones de cambios anteriores. Si migras las páginas de destino y no tocas esas redirecciones viejas, cada una se convierte en una cadena: URL de hace dos años → URL actual → URL nueva.
Por eso mi mapa no empieza por las páginas que voy a mover, sino por la lista de redirecciones que ya existen. Las que apuntan a una página que se mueve se editan para que apunten directamente a la nueva. No se crea una redirección nueva encima.
Así estoy migrando mis páginas de Colombia
El caso es el cambio de la sección /cali/ de mi web a /colombia/, manteniendo Cali como ciudad principal dentro de las direcciones de los servicios.
Lo hago porque la sección tiene que representar a todo el país y no solo a una ciudad, y porque hoy dos páginas mías compiten por la misma intención. Este es el mapa, tal como está en octubre de 2026:
| URL actual | URL nueva | Qué se hace |
|---|---|---|
| /cali/ | /colombia/ | Se renombra y se reescribe como página de Colombia |
| /consultor-seo-colombia/ | /colombia/ | Se fusiona su contenido útil en la nueva y se redirige |
| /cali/consultor-seo/ | /colombia/consultor-seo-cali/ | Cambio de página padre y de slug, con 301 |
| /cali/diseno-de-paginas-web/ | /colombia/diseno-paginas-web-cali/ | Cambio de página padre y de slug, con 301 |
| /consultor-seo-en-cali/ (antigua) | /colombia/consultor-seo-cali/ | Se edita la redirección que ya existía |
| /diseno-de-paginas-web-en-cali/ (antigua) | /colombia/diseno-paginas-web-cali/ | Se edita la redirección que ya existía |
← Desliza lateralmente para ver más →
Las dos últimas filas son la trampa del apartado anterior. Esas direcciones antiguas ya redirigen hoy a las páginas de /cali/. Si no las edito, el día de la migración harían dos saltos.
[PENDIENTE: resultado de la migración a /colombia/ tras seis semanas de vigilancia]
En WordPress las páginas no se redirigen solas
Mucha gente cree que WordPress redirige automáticamente cuando cambias un slug. Lo hace con las entradas, pero no con las páginas.
La función que guarda los slugs antiguos ignora expresamente los tipos de contenido jerárquicos, y las páginas lo son. Si cambias la página padre o el slug de una página de servicio, la redirección la tienes que crear tú en tu plugin de redirecciones.
Y si ese plugin crea redirecciones automáticas al cambiar slugs, desactívalo durante la migración. Si no, él crea las suyas, tú creas las tuyas y acabas con cadenas que no has escrito.
En Elementor los enlaces internos están escondidos
Elementor guarda el contenido de cada página como datos JSON, y ahí las barras de las URLs se escriben escapadas: lo que tú ves como /cali/ está guardado como \/cali\/.
Si haces un buscar y reemplazar solo con la forma normal, la mitad de tus enlaces internos seguirá apuntando a las direcciones viejas. Busca las dos formas y prueba siempre primero en modo simulación.
Lo que vive fuera de tu web
Las redirecciones arreglan lo que Google rastrea, pero hay direcciones tuyas que no dependen de tu servidor: tu Perfil de Empresa de Google, LinkedIn, la firma del correo, tus herramientas de seguimiento de posiciones y cualquier presupuesto en PDF que hayas enviado. Haz la lista antes del lanzamiento, no después.
La checklist del staging y del día del lanzamiento
El día del lanzamiento no se diseña nada: se ejecuta una lista que ya estaba escrita y probada en una copia de la web.
Antes de lanzar, en el entorno de pruebas:
- La copia de pruebas está bloqueada a los buscadores, con contraseña o noindex, para que no compita con la web real.
- Las etiquetas canonical apuntan a las URLs nuevas, no a las del entorno de pruebas.
- Las redirecciones del mapa están cargadas y probadas una a una.
El día del lanzamiento, en este orden:
- Primero las redirecciones, después los cambios de URL. Si cambias los slugs antes, hay un rato en que las URLs antiguas dan error.
- Quita el bloqueo a los buscadores si la web nueva lo heredó del entorno de pruebas. Es un error caro y muy fácil de pasar por alto.
- Revisa que el menú y los enlaces internos llevan a las URLs nuevas.
- Vacía la caché del servidor y del plugin.
- Comprueba que el sitemap solo lista URLs nuevas y vuelve a enviarlo desde la consola de Google.
- Pide desde esa misma consola la inspección de las páginas más importantes del inventario.
Cuánto vigilar después del lanzamiento y qué mirar
La vigilancia posterior compara página a página la web nueva con la línea base durante varias semanas, porque Google tarda en procesar los cambios.
La propia documentación de Google avisa de que puede tardar varias semanas o más en mostrar las URLs nuevas y de que las posiciones pueden fluctuar mientras tanto. Que algo baje la primera semana no significa que haya ido mal; que siga bajando a la sexta, sí.
Yo vigilo seis semanas, y miro tres cosas:
- Errores 404 nuevos, cada día la primera semana y cada semana después. Cada uno es una URL que se escapó del mapa.
- Las páginas marcadas en la línea base, una a una. El total del sitio puede esconder que una página importante se ha caído.
- Enlaces internos que aún pasan por una redirección. Funcionan, pero cada salto es trabajo de más para Google y para quien navega. Lo explico con más detalle en la guía sobre cómo optimizar el presupuesto de rastreo.
Y aquí va un error propio, porque es la mejor prueba de que este último punto importa. La versión anterior de este mismo artículo enlazaba a una de mis guías por su dirección antigua, la que tenía antes de que yo mismo reorganizara las URLs del blog. El enlace funcionaba, así que nadie lo vio: cada clic pasaba por una redirección. Lo encontré al revisar esta pieza.
Si al migrar descubres que dos páginas tuyas responden a lo mismo, no las muevas por separado: fusiónalas en una y redirige la otra. Es el mismo criterio que explico en el artículo sobre canibalización de contenido duplicado.
Preguntas frecuentes
¿Cuánto tarda Google en procesar una migración?
Según la documentación de Google, puede tardar varias semanas o más en mostrar las URLs nuevas, y las posiciones pueden fluctuar mientras tanto. Por eso conviene vigilar al menos seis semanas antes de sacar conclusiones.
¿Cuánto tiempo hay que mantener las redirecciones 301?
Google recomienda conservarlas al menos un año y, pensando en los usuarios, indefinidamente. Quitarlas pronto rompe los enlaces externos y los marcadores que todavía apuntan a las direcciones antiguas.
¿Puedo redirigir todas las URLs antiguas a la página de inicio?
No es recomendable. Cada URL antigua debe ir a su equivalente más parecida. Si todo apunta a la home, Google lo trata casi como un error y lo que había ganado esa página se pierde.
¿Qué pasa si una URL antigua ya tenía una redirección?
Si la página de destino cambia, la redirección vieja se convierte en una cadena de dos saltos. Hay que editarla para que apunte directamente a la URL nueva, en lugar de añadir otra redirección encima.
¿Una migración de HTTP a HTTPS necesita mapa de redirecciones?
Sí, aunque sea sencillo: una regla general en el servidor que lleve cada URL a su versión segura. Las rutas no cambian, así que el riesgo es bajo, pero hay que comprobar canonical, sitemap y enlaces internos.
Antes de fijar la fecha del lanzamiento
La decisión que tienes en la mano no es si migrar, sino si lanzas con el mapa completo o con el que te dio tiempo a hacer. Las cadenas y las páginas que se escapan del mapa no se notan el día del lanzamiento: se notan seis semanas después, cuando ya cuesta recuperarlas.
Si tu migración tiene muchas URLs, redirecciones heredadas o un cambio de plataforma, el paso sensato es una auditoría SEO antes de la migración: revisar el inventario, el mapa y las redirecciones que ya existen, y darte por escrito lo que se rompería si lanzaras hoy.
Si solo pasas de HTTP a HTTPS en una web pequeña, no me necesitas: con la checklist de este artículo y una tarde de revisión lo tienes resuelto.
