Migración web y SEO: guía para no perder tráfico | Ighenatt

El 40% de las migraciones web generan caídas de tráfico orgánico que superan el mes de duración. En los casos más graves, sitios con años de posicionamiento acumulado pierden entre el 50% y el 80% de su visibilidad en cuestión de semanas. Lo peor es que en la mayoría de estos casos la causa no es un cambio de algoritmo de Google ni una penalización manual: es simplemente la falta de planificación SEO antes de pulsar el botón de publicar. Esta guía te explica cómo evitarlo.

Por qué las migraciones web son el riesgo SEO más subestimado

Una migración web es cualquier cambio que altera la forma en que Google rastrea, indexa o percibe las URLs de tu sitio. El problema es que los equipos de desarrollo y diseño a menudo tratan una migración como un proyecto técnico puro — y lo es — pero ignoran que Google ha construido un modelo de confianza sobre las URLs existentes durante meses o años. Cuando esas URLs cambian sin la señalización correcta, ese capital se volatiliza.

Según datos agregados de Ahrefs sobre cientos de migraciones analizadas, los sitios que no implementan un plan SEO antes de migrar pierden entre el 20% y el 80% de su tráfico orgánico. La recuperación, incluso en casos bien ejecutados, lleva entre 3 y 6 meses según reconoce el propio Google Search Central. Para sitios medianos, Google indica que puede tardarse “unas pocas semanas” en que la mayoría de páginas se actualicen en el índice, y en sitios grandes puede llevar aún más.

Los tres tipos de migración más habituales, y sus riesgos específicos:

Cambio de dominio. Es la migración de mayor impacto. Google transfiere la autoridad acumulada al nuevo dominio a través de los redirects 301, pero el proceso no es inmediato. Sin el uso correcto de la herramienta de cambio de dirección en Google Search Console, el proceso se ralentiza.

Cambio de estructura de URLs. Rediseños que alteran la jerarquía de directorios, eliminan slugs descriptivos o cambian el patrón de URLs son el origen más frecuente de errores 404 masivos. Una tienda que pasa de /categoria/producto-nombre/ a /p/12345/ sin mapear redirects destruye todo el link equity de sus páginas de producto.

Migración a HTTPS. Aunque Google recomienda HTTPS, la migración mal ejecutada genera mixed content (recursos HTTP en páginas HTTPS), certificados mal configurados y cadenas de redirects que acumulan latencia. Es el tipo de migración que más subestiman los equipos técnicos porque parece simple.

La diferencia crítica entre una migración “técnica” y una “SEO”: la técnica se da por completada cuando el nuevo sitio funciona. La SEO se considera completada cuando el nuevo sitio mantiene — o supera — el tráfico orgánico del anterior.

Pre-migration checklist: antes de tocar nada

El trabajo más importante de toda la migración ocurre semanas antes del día de lanzamiento. Sin datos de referencia, no puedes saber si la migración fue exitosa ni detectar qué se ha roto.

1. Inventario completo de URLs actuales. Usa Screaming Frog para rastrear el sitio completo y exportar todas las URLs que devuelven código 200. Filtra por tipo de contenido: páginas, posts, categorías, productos, imágenes. Guarda el archivo; es tu referencia absoluta.

2. Identificar las URLs de mayor valor. Abre Google Search Console y exporta el informe de rendimiento filtrado por los últimos 3 meses. Ordena por clics. Las 50-100 URLs con más tráfico son tu prioridad absoluta: deben tener redirect 301 correcto sin excepción.

Complementa con Ahrefs o Semrush para identificar las URLs con mayor número de backlinks externos. Una página con 200 backlinks perdida en la migración supone una pérdida de link equity que puede tardar años en recuperarse.

3. Captura el baseline de posiciones. Exporta un snapshot de las posiciones actuales en GSC: keywords, posición media, impresiones y clics. Este documento es tu medición de éxito post-migración. Sin él, no puedes demostrar si la recuperación es completa.

4. Verifica el sitemap y robots.txt actuales. Descarga y revisa ambos archivos. Asegúrate de que el sitemap incluye todas las URLs importantes y que robots.txt no bloquea secciones que deberían estar indexadas. Documenta la configuración actual: necesitarás replicarla correctamente en el nuevo sitio.

5. Inventario de backlinks externos. Exporta la lista de backlinks desde Ahrefs o Search Console. Identifica los 20-30 dominios que más enlazan a tu sitio. Tras la migración, considera contactar a los más relevantes para pedirles que actualicen sus enlaces a las nuevas URLs — aunque con los redirects correctos no es imprescindible, elimina un salto de redirect para esas páginas.

El artículo sobre auditoría SEO técnica cubre la revisión del estado actual como primer paso antes de cualquier migración.

El mapa de redirects: cómo planificarlo correctamente

El mapa de redirects es un documento que relaciona cada URL antigua con su equivalente nueva. No es opcional. Es el núcleo de toda la migración SEO.

Plantilla de mapeo recomendada

Columna por columna: la URL antigua es la que aparece en el crawl de Screaming Frog y en los informes de GSC. La URL nueva es su equivalente en el nuevo sitio. El código de redirect (301 para permanente, 410 para páginas que desaparecen definitivamente). El estado de implementación y verificación.

La regla del 1:1. Cada URL antigua debe apuntar a exactamente una URL nueva. Nunca hagas un redirect de múltiples URLs antiguas al homepage — Google trata esto como un soft 404 y no transmite el link equity. Si una página antigua no tiene equivalente directo, busca la página del nuevo sitio que más se aproxime temáticamente.

Casos especiales que requieren atención

Paginación. Las URLs de paginación (/blog/page/2/) generalmente no necesitan redirect si la estructura nueva mantiene la misma lógica. Si cambia, mapéalas a la primera página de cada sección.

Parámetros de URL. Muchos sitios tienen URLs con parámetros de seguimiento o filtros: ?utm_source=, ?color=rojo. Define en GSC qué parámetros puede ignorar Google para evitar contenido duplicado. No necesitan redirect individual.

Facetas de ecommerce. Las URLs de filtros en tiendas online (/zapatillas/?talla=42&color=negro) son un caso complejo. Si el nuevo sitio usa la misma estructura de facetas, no necesitan mapeo. Si cambia la arquitectura de filtros, consulta a un especialista SEO antes de proceder.

Páginas que desaparecen. Si una página no tiene equivalente razonable en el nuevo sitio, usa un código 410 (Gone) en lugar de redirigir a una página genérica. El 410 le indica a Google que la página se eliminó intencionalmente y que deje de rastrearla, lo cual es más limpio que un redirect irrelevante.

Implementación técnica de los redirects 301

Una vez tienes el mapa de redirects completo y verificado, la implementación varía según la tecnología del servidor.

Apache (.htaccess). La opción más habitual en hostings compartidos. Las reglas de redirect se escriben directamente en el archivo .htaccess:

Redirect 301 /pagina-antigua/ https://tudominio.es/pagina-nueva/

Para redirects masivos con patrones, usa mod_rewrite:

RewriteRule ^categoria-antigua/(.*)$ /categoria-nueva/$1 [R=301,L]

Nginx (nginx.conf). En servidores VPS o dedicados con Nginx, los redirects van en el bloque server:

return 301 https://tudominio.es/pagina-nueva/;

CMS (WordPress, Shopify, etc.). Plugins como Redirection (WordPress) o la gestión nativa de redirects en Shopify permiten implementar el mapa sin acceso al servidor. Son más lentos que los redirects a nivel de servidor pero válidos para la mayoría de sitios.

Errores de implementación más frecuentes

Cadenas de redirects. Si la URL A redirige a B, y B redirige a C, Googlebot debe hacer dos peticiones extra. Google tolera cadenas de hasta 5 saltos, pero cada salto adicional añade latencia y puede perder algo de autoridad. Antes del lanzamiento, usa Screaming Frog en modo “Follow redirects” para detectar cadenas y cortocircuitarlas.

Redirect loops. A redirige a B, B redirige a A. Screaming Frog los detecta como errores rojos. Suelen ocurrir en implementaciones de .htaccess con reglas que se contradicen.

Redirects que apuntan a 404. El redirect existe, pero la URL de destino devuelve 404. Es más dañino que no tener redirect porque Google llega a la URL nueva y encuentra un error. Verifica todas las URLs de destino antes del lanzamiento.

Los sitios con múltiples versiones de idioma tienen una capa adicional: la implementación de hreflang trata ese caso con detalle.

El día del lanzamiento: protocolo de validación

El lanzamiento no es el momento de improvisar. Ten preparado este checklist de 10 puntos y ejecútalo en orden:

1. Verificar que robots.txt no bloquea indexación. El error más catastrófico y frecuente: el sitio nuevo se lanzó con Disallow: / en robots.txt — una medida habitual en entornos de staging que alguien olvidó revertir. Compruébalo en tudominio.es/robots.txt antes de cualquier otra acción.

2. Confirmar que las etiquetas noindex están eliminadas. Similar al punto anterior: revisa con Screaming Frog que ninguna página importante tiene <meta name="robots" content="noindex">.

3. Verificar una muestra de 20 redirects críticos. Comprueba manualmente las 20 URLs con más tráfico del baseline. Usa una herramienta de comprobación de headers HTTP para confirmar que devuelven 301 y que el destino es correcto.

4. Confirmar que no hay redirect loops. Lanza un rastreo rápido con Screaming Frog sobre las URLs principales.

5. Verificar el certificado SSL. Si es una migración a HTTPS, comprueba que el certificado es válido para el dominio principal y los subdominios que uses.

6. Detectar mixed content. Con la consola del navegador (F12 → Console) abre las páginas principales y verifica que no hay recursos cargando por HTTP en páginas HTTPS.

7. Enviar el sitemap actualizado a GSC. Ve a Search Console → Sitemaps → enviar la nueva URL del sitemap. Si el dominio ha cambiado, hazlo desde la propiedad del nuevo dominio.

8. Usar la herramienta de cambio de dirección (solo si cambias dominio). En GSC → Configuración → Cambio de dirección. Solo válido para cambios de dominio completos, no para cambios de estructura de URLs dentro del mismo dominio.

9. Solicitar indexación de las páginas principales. Usa la herramienta de inspección de URLs en GSC para solicitar la indexación de tu homepage, las páginas de servicios principales y los posts más importantes.

10. Monitorizar errores en tiempo real durante las primeras 4 horas. Ten abierto el informe de cobertura de GSC y los logs del servidor. Los primeros problemas suelen aparecer en las horas siguientes al lanzamiento.

Monitorización post-migración: los 90 días críticos

El trabajo no termina el día del lanzamiento. La mayor parte de los problemas de una migración se detectan en las semanas siguientes, no en el momento del lanzamiento.

Semana 1-2: errores 404 y redirects rotos. Googlebot comienza a rastrear el nuevo sitio inmediatamente. Los errores 404 aparecen en el informe “Páginas no encontradas” de GSC. Revísalo diariamente durante la primera semana. Cualquier URL con tráfico histórico que aparezca como 404 necesita un redirect urgente.

Configura una alerta en Google Search Console para recibir notificaciones de nuevos errores de rastreo. También activa alertas de caída brusca de sesiones en Google Analytics 4 (Informes → Alertas personalizadas).

Semana 3-4: problemas de indexación en Coverage Report. A partir de la tercera semana, el informe de cobertura de GSC empieza a reflejar el estado real del nuevo sitio. Problemas frecuentes en esta fase: páginas marcadas como “Descubierta, actualmente no indexada” (Google las encontró pero no las ha procesado aún), páginas con canonical incorrecto, y duplicados detectados.

Compara el número total de páginas indexadas con el baseline anterior a la migración. Una caída del 15-20% puede ser temporal (Google aún re-procesando); una caída del 50%+ requiere investigación inmediata.

Mes 2: recuperación de posiciones. Compara el informe de rendimiento de GSC con el baseline de posiciones que capturaste antes de migrar. Identifica keywords que han perdido más de 5 posiciones. Para cada una, verifica que la URL correspondiente está correctamente indexada y que el redirect del contenido equivalente antiguo funciona.

Un sitio bien migrado debería recuperar el 80-90% de sus posiciones originales al final del segundo mes. Si la recuperación es menor, revisa si hay problemas de canonical entre las URLs antiguas (aún recibiendo tráfico de backlinks) y las nuevas.

Mes 3: análisis de backlinks recuperados vs perdidos. Con Ahrefs o Semrush, compara el perfil de backlinks actual con el anterior a la migración. Los backlinks que apuntan a las URLs antiguas seguirán pasando autoridad siempre que los redirects 301 estén activos — Google recomienda mantener los redirects al menos un año. Los backlinks “perdidos” (los que apuntaban a páginas que ahora devuelven 404) son los que necesitas recuperar contactando a los dominios enlazantes.

El artículo sobre qué es el SEO técnico explica los fundamentos que hacen posible una migración sin pérdidas de visibilidad.

El caso de la migración fallida: qué aprender

El patrón más común que vemos en migraciones con pérdidas severas de tráfico sigue siempre la misma estructura. Un negocio con 3-5 años de presencia web decide renovar completamente su imagen y tecnología. El proyecto se gestiona como un proyecto de diseño y desarrollo: nuevo CMS, nueva arquitectura visual, nuevo sistema de URLs más “limpio”. El SEO no entra en la conversación hasta que la nueva web está lista para publicarse.

El día del lanzamiento, la web nueva está impecable visualmente. Pero en las 3 semanas siguientes, el tráfico orgánico cae un 60%. La investigación revela tres errores simultáneos: las URLs de blog pasaron de /blog/titulo-del-post/ a /noticias/2024/titulo-del-post/ sin ningún redirect, las páginas de servicios cambiaron de estructura completamente y tampoco tienen redirects, y el robots.txt del nuevo servidor bloqueó la indexación durante 5 días porque nadie lo verificó tras el lanzamiento.

La recuperación tomó 8 meses. Con un plan SEO previo, habría tomado 6-8 semanas.

Los tres errores que se repiten siempre:

Primero, tratar el SEO como una capa que se aplica después, no como una restricción de diseño. Las decisiones de arquitectura de URLs deben consultarse con el SEO antes de que el desarrollo esté avanzado, no el día antes del lanzamiento.

Segundo, no tener datos de referencia. Sin el crawl previo, sin el baseline de posiciones, sin el inventario de backlinks, no puedes medir el impacto ni priorizar la recuperación.

Tercero, no asignar responsabilidad de monitorización post-lanzamiento. La migración “termina” el día de publicación para el equipo de desarrollo, pero para el SEO empieza ese día. Alguien debe revisar GSC diariamente durante las primeras 4 semanas.

Con la preparación correcta, una migración web es una oportunidad: limpiar arquitectura de URLs, eliminar contenido duplicado, mejorar la estructura de enlazado interno. Los sitios que migran con planificación SEO no solo preservan su tráfico — a menudo lo superan en 6-12 meses.

La decisión más cara en cualquier migración es incluir el SEO como reflexión de último momento. Con la preparación correcta, esas 8-10 semanas de trabajo previo pueden evitar 6-8 meses de recuperación posterior. Si estás planificando una migración y quieres un protocolo que cubra auditoría, mapeo de redirects y monitorización post-lanzamiento, consulta nuestro servicio de migración SEO.