Migración web SEO / GEO: cómo lanzar una nueva web sin perder visibilidad

En los casi 20 años de experiencia que tenemos en dobleO con desarrollos web, uno de los momentos mas importantes son los lanzamientos de nuevas webs.

Estrenar una nueva página web debería ser una mejora para el negocio. Nuevo diseño, mejor tecnología, una arquitectura más clara, mejor experiencia de usuario y, en muchos casos, nuevas funcionalidades. Sin embargo, también es uno de los momentos en los que una web puede perder gran parte de la visibilidad que ha construido durante años, por eso, es uno de los momentos mas temidos en el mundo del marketing digital.

Una URL que desaparece, una redirección mal configurada, un noindex que llega accidentalmente a producción o un cambio de arquitectura aparentemente inocente pueden provocar pérdidas de tráfico, rankings e incluso conversiones.

Además, hoy la migración no debería plantearse únicamente desde el SEO tradicional, también debemos pensar en GEO (Generative Engine Optimization) y comprobar que el nuevo sitio continúa siendo accesible, comprensible y rastreable para buscadores y sistemas que utilizan contenido web para ofrecer respuestas generativas.

Por eso, lanzar una nueva web no debería consistir simplemente en sustituir la antigua.

Toquemos este tema.

¿Qué es una migración web?

Una migración web es el proceso de trasladar o modificar una página web de manera significativa intentando conservar su funcionamiento, tráfico, posicionamiento, autoridad y capacidad de ser rastreada e interpretada.

Existen muchos tipos de migraciones:

• Cambio de dominio.
• Cambio de HTTP a HTTPS.
• Cambio de CMS.
• Cambio de servidor.
• Rediseño completo.
• Cambio de arquitectura.
• Modificación de URLs.
• Internacionalización de una web.
• Unión de varios dominios.
• Separación de diferentes áreas de una web.
• Cambio de tecnología o framework.

Pero una migración no necesita implicar necesariamente un cambio de dominio. Podemos mantener exactamente el mismo dominio y estar realizando una migración importante.

Por ejemplo:

URL antigua

empresa.com/servicios/posicionamiento-seo

URL nueva

empresa.com/servicios/seo-geo

Para el usuario puede parecer simplemente una nueva web. Para Google, otros buscadores y diferentes sistemas de rastreo, son dos URLs distintas.

Si la URL antigua tenía posicionamiento, backlinks, tráfico o autoridad y simplemente desaparece, podemos perder parte de las señales que había acumulado.

Ahí empieza el trabajo de migración, de hecho, podríamos decir que empieza mucho antes.

Como hacer un briefing para una nueva web.

¿Por qué una migración puede afectar al SEO / GEO?

Una web que lleva años publicada acumula muchas más señales de las que vemos a simple vista.

Por ejemplo:

• URLs indexadas.
• Rankings.
• Backlinks.
• Enlazado interno.
• Contenidos posicionados.
• Historial de rastreo.
• Autoridad temática.
• Datos estructurados.
• Relaciones entre páginas.
• Información sobre entidades, productos, servicios o ubicaciones.
• URLs que son utilizadas o citadas desde otros sitios.

Cuando sustituimos una web por otra, debemos intentar conservar aquellas señales que siguen siendo relevantes.

Google recomienda preparar y probar exhaustivamente el nuevo sitio, establecer una correspondencia entre URLs antiguas y nuevas e implementar redirecciones permanentes cuando las URLs cambian.

Desde una perspectiva GEO, además, interesa mantener una estructura clara, contenidos accesibles y unas reglas de rastreo que no bloqueen accidentalmente a los sistemas que queremos que puedan descubrir nuestras páginas.

Por ejemplo, OpenAI diferencia actualmente entre OAI-SearchBot, utilizado para que las páginas puedan aparecer en las funciones de búsqueda de ChatGPT, y GPTBot, relacionado con el rastreo de contenido para entrenamiento. Son controles independientes mediante robots.txt.

Esto introduce una nueva capa que también debería revisarse durante una migración.

El error más frecuente: pensar en SEO / GEO cuando la web ya está terminada

Uno de los mayores problemas aparece cuando el proceso funciona así:

1. Se diseña la nueva web.
2. Se desarrolla.
3. Se aprueba.
4. Se publica.
5. Alguien pregunta: “¿Y el SEO?”

En ese momento, parte de las decisiones más importantes ya están tomadas.

Por ejemplo:

• Se han eliminado páginas.
• Se han cambiado URLs.
• Se ha simplificado la navegación.
• Se ha modificado el contenido.
• Se han eliminado categorías.
• Se ha cambiado el enlazado interno.
• Se han creado nuevas plantillas.
• Se han perdido encabezados o datos estructurados.

Algunas decisiones pueden ser correctas desde diseño o desarrollo y, al mismo tiempo, tener consecuencias importantes para la visibilidad orgánica.

Por eso, SEO / GEO debería participar antes de empezar a construir la nueva web, no únicamente antes de pulsar “Publicar”.

Entorno de Desarrollo vs Entorno de Producción

Otro concepto fundamental cuando se trabaja en una nueva web es diferenciar entre entorno de desarrollo y entorno de producción.

¿Qué es el entorno de producción?

Producción es la web real, la que visitan los usuarios, rastrea Google y utilizan las campañas publicitarias.

Por ejemplo:

www.empresa.com

Cualquier error introducido en producción puede afectar inmediatamente a:

• Usuarios.
• Posicionamiento.
• Formularios.
• Ventas.
• Analytics.
• Google Ads.
• Meta Ads.
• Integraciones.
• Motores de búsqueda.
• Sistemas generativos.

¿Qué es un entorno de desarrollo?

Es un entorno separado donde se construye y prueba la nueva versión antes de hacerla pública. Dependiendo del proyecto también podemos hablar de desarrollo, staging o preproducción.

Por ejemplo:

staging.empresa.com

Aquí se pueden probar cambios sin afectar a los usuarios de la web actual.

Esto permite revisar:

• Diseño.
• Responsive.
• Navegación.
• Formularios.
• URLs.
• Redirecciones.
• SEO técnico.
• Datos estructurados.
• Analítica.
• Conversiones.
• Rendimiento.
• Integraciones.

Entonces, ¿por qué no desarrollar directamente en producción?

Porque elimina nuestra red de seguridad. Imaginemos que durante un desarrollo alguien cambia la plantilla de producto y accidentalmente elimina el canonical de miles de páginas.

• O que una nueva configuración deja de enviar conversiones a Google Ads.
• O que se cambia la estructura de URLs antes de tener preparadas las redirecciones.

En producción, el problema ya está afectando al negocio.

En desarrollo podemos detectarlo antes.

Además, el entorno de desarrollo normalmente debe mantenerse fuera del índice de los buscadores para evitar que aparezcan dos versiones de la misma web.

Y aquí aparece otro de los clásicos de las migraciones.

Se bloquea correctamente el entorno de pruebas y, cuando se publica la web, el bloqueo también llega a producción.

El resultado puede ser una web perfectamente visible para las personas pero que contiene:

noindex

o reglas de robots.txt que impiden el rastreo.

Google identifica precisamente los bloqueos accidentales mediante noindex o robots.txt como uno de los errores habituales en migraciones.

Antes de migrar o lanzar la nueva web, debemos analizar lo siguiente:

Una migración correctamente planificada empieza con una pregunta sencilla:

¿Qué tenemos actualmente que no podemos permitirnos perder?

Antes de realizar cambios deberíamos crear una fotografía de la web existente.

1. Rastreo completo

Necesitamos conocer todas las URLs accesibles. No únicamente las páginas que aparecen en el menú.

También pueden existir:

• Landings.
• Categorías.
• Productos.
• Artículos.
• PDFs.
• Imágenes.
• URLs antiguas.
• Páginas huérfanas.
• Parámetros.
• Versiones internacionales.

Herramientas como Screaming Frog permiten obtener esta fotografía inicial.

2. Tráfico orgánico

GA4 nos permite conocer qué páginas reciben tráfico orgánico. Una página que no aparece en el menú principal puede estar generando cientos o miles de visitas cada mes.

Eliminarla sin analizarla previamente sería un error.

3. Google Search Console

Search Console nos permite conocer:

• Clics.
• Impresiones.
• Consultas.
• Posiciones.
• Páginas con visibilidad.
• Estado de indexación.

No debemos valorar una URL únicamente por su tráfico actual.

Puede existir una página con poco tráfico pero miles de impresiones que está empezando a ganar posicionamiento.

4. Rankings

También es recomendable conservar una fotografía de las palabras clave posicionadas antes de realizar la migración.

Después nos permitirá comparar.

5. Backlinks

Una URL puede tener poco tráfico pero contar con enlaces externos de gran valor.

Si desaparece sin redirección, podemos desperdiciar parte de esa autoridad.

El mapa de URLs: la pieza central de una migración

Una vez conocemos la web anterior y la nueva arquitectura podemos crear un mapa de migración.

El principio es sencillo:

URL actual	Nueva URL	Acción
/servicios/seo	/servicios/seo-geo/	Redirección 301
/google-ads	/sem/google-ads/	Redirección 301
/blog/seo-2024	/blog/guia-seo-geo/	Redirección 301
/servicio-obsoleto	—	404/410

Cuando existe una página equivalente, normalmente utilizaremos una redirección permanente 301 o 308.

Google recomienda precisamente utilizar redirecciones permanentes del lado del servidor siempre que sea técnicamente posible.

Redirigir todo a la home no es una solución

Otro error habitual consiste en decidir:

“Todas las páginas antiguas que no existen las mandamos a la home.”

Es fácil de implementar, pero generalmente incorrecto.

Una redirección debería llevar al usuario hacia el contenido nuevo más equivalente al antiguo.

Google desaconseja redirigir grandes cantidades de URLs hacia destinos irrelevantes, como la página principal, ya que estas redirecciones pueden incluso interpretarse como soft 404.

Si no existe realmente un contenido equivalente, en determinados casos puede ser más correcto devolver un 404 o 410.

¿Qué debemos revisar antes de lanzar una nueva web?

Antes del lanzamiento deberíamos rastrear completamente el entorno de pruebas y compararlo con la web actual.

URLs y códigos de respuesta

Comprobar:

• URLs con código 200.
• 3XX.
• 4xx
• 5XX.
• Cadenas de redirecciones.
• Bucles.

Los enlaces internos deberían apuntar directamente a las URLs definitivas y no depender innecesariamente de redirecciones.

Titles y meta descriptions

Hay que comprobar que los metadatos actuales no desaparecen simplemente porque se haya desarrollado una nueva plantilla.

Un rediseño no debería significar empezar el SEO / GEO desde cero.

H1, H2 y estructura semántica

El diseño también puede alterar la estructura del contenido.

Debemos comprobar:

• H1.
• H2.
• H3.
• Textos descriptivos.
• FAQs.
• Listados.
• Tablas.
• Información contextual.

Una estructura clara ayuda tanto al usuario como a los sistemas que necesitan interpretar la información de la página.

Canonicals

Los canonicals deben utilizar las URLs definitivas.

Un error especialmente problemático es publicar una web cuyos canonicals continúan apuntando a:

staging.empresa.com

Robots.txt

Debe revisarse antes y después del lanzamiento.

Actualmente, además de Googlebot y otros buscadores tradicionales, una estrategia SEO / GEO puede requerir revisar qué rastreadores relacionados con sistemas generativos queremos permitir.

Por ejemplo, OpenAI indica que una web que quiera facilitar su aparición en los resultados de búsqueda de ChatGPT no debería bloquear OAI-SearchBot.

Esto no significa permitir indiscriminadamente todos los bots.

Significa que las decisiones de rastreo deberían ser intencionadas y no accidentales.

Noindex

Buscar cualquier:

noindex

que no deba llegar a producción.

Sitemap XML

El sitemap debería contener únicamente las URLs relevantes de la nueva web.

Debemos evitar:

• URLs antiguas.
• URLs redireccionadas.
• 404
• URLs no indexables.
• URLs de staging.

Hreflang

En webs internacionales debemos comprobar:

• País.
• Idioma.
• URLs.
• Reciprocidad.
• Canonicals.

Una migración es uno de los momentos en los que más fácilmente se rompe una implementación internacional.

Datos estructurados

El Schema puede desaparecer durante un rediseño aunque visualmente no veamos ninguna diferencia.

Deberíamos revisar especialmente aquellos tipos de datos estructurados que fueran relevantes para el sitio:

• Organization.
• LocalBusiness.
• Product.
• Article.
• BreadcrumbList.
• Event.
• Otros específicos del proyecto.

Además del potencial impacto en buscadores, una estructura semántica clara contribuye a que máquinas y sistemas puedan interpretar mejor el contenido y las entidades de una web.

Revisar el Contenido es sumamente importante

Una nueva web puede ser técnicamente perfecta y perder visibilidad igualmente.

¿Por qué?

Porque durante el rediseño se ha decidido “simplificar”.

Una página que anteriormente explicaba un servicio con 800 palabras puede convertirse en:

“Hacemos SEO. Contacta con nosotros.”

Visualmente puede quedar más limpia.

Desde el punto de vista de búsqueda y comprensión temática, probablemente hemos perdido información.

En una migración deberíamos comparar también:

Contenido anterior → contenido nuevo

y comprobar si hemos eliminado:

• Información relevante.
• Preguntas frecuentes.
• Definiciones.
• Casos de uso.
• Características.
• Datos.
• Entidades.
• Contexto.
• Enlaces relacionados.

Este análisis cobra todavía más importancia cuando hablamos de SEO / GEO.

Para aparecer en respuestas generativas necesitamos que nuestros contenidos puedan ser entendidos, relacionados con una temática y utilizados como fuente cuando sean relevantes.

El tracking también se migra

Hay otro error especialmente peligroso:

Publicamos una web nueva y el tráfico parece desplomarse.

Después descubrimos que GA4 había dejado de medir.

Por eso una migración debe incluir también analítica.

Antes del lanzamiento deberían comprobarse, según cada proyecto:

• Google Analytics 4.
• Google Tag Manager.
• Google Ads.
• Meta Pixel.
• Consent Mode.
• CMP.
• Eventos.
• Formularios.
• Ecommerce.
• Conversiones.
• Cross-domain tracking.
• Scripts de terceros.

No deberíamos descubrir varios días después del lanzamiento que las ventas sí existían pero no se estaban midiendo.

¿Cómo debe hacerse el Testeo de una nueva web?

La migración debería incluir una fase formal de QA (Quality Assurance). No debería depender únicamente de desarrollo.

Lo ideal es que cada área valide lo que le corresponde.

Área	Qué debería comprobar
Desarrollo	Funcionalidad, servidor, errores, integraciones
SEO / GEO	URLs, rastreo, indexación, arquitectura, contenido, robots, canonicals, Schema
Analítica	GA4, GTM, eventos, conversiones, consentimiento
UX / Diseño	Navegación, responsive, accesibilidad, experiencia
Negocio	Formularios, compras, solicitudes, reservas y procesos críticos

El objetivo no es simplemente comprobar que “la web funciona”, debemos comprobar que funciona para usuarios, buscadores, sistemas de medición y motores generativos.

¿Cómo organizar una migración web?

Podemos resumir el proceso en tres grandes fases.

Antes del lanzamiento	Día del lanzamiento	Después del lanzamiento
Rastreo de la web actual	Publicar nueva versión	Rastreo completo de producción
Análisis GA4 y Search Console	Activar redirecciones	Revisar redirecciones
Rankings y backlinks	Revisar robots.txt	Controlar 404 y 5XX
Arquitectura nueva	Retirar noindex cuando corresponda	Revisar indexación
Mapa de URLs	Verificar canonicals	Enviar sitemap
Redirecciones	Activar sitemap definitivo	Monitorizar GSC
QA SEO / GEO	Comprobar tracking	Monitorizar rankings
QA Analytics	Probar conversiones	Comparar tráfico
QA UX	Revisar páginas críticas	Comparar conversiones
Revisión de crawlers	Validar producción	Analizar logs y rastreo

Problemas típicos después de lanzar una web nueva

Estos son algunos de los problemas que encontramos con mayor frecuencia:

1. Páginas antiguas que devuelven 404

Había URLs posicionadas pero nadie preparó las redirecciones.

2. Todo redirige hacia la home

Se ha intentado solucionar la migración con una única regla global.

3. Canonicals incorrectos

Continúan apuntando al staging o a URLs antiguas.

4. Producción sigue teniendo noindex

La configuración utilizada para proteger desarrollo se publicó junto con la nueva web.

5. Robots.txt bloquea más de lo necesario

Google u otros rastreadores no pueden acceder correctamente.

6. Sitemap desactualizado

Continúa mostrando URLs antiguas o inexistentes.

7. Pérdida de contenidos

La nueva web tiene menos información que la anterior.

8. Pérdida de enlazado interno

Páginas importantes quedan mucho más profundas o prácticamente huérfanas.

9. Hreflang roto

Las relaciones entre idiomas dejan de funcionar.

10. Schema eliminado

El nuevo desarrollo no incorpora los datos estructurados existentes.

11. Tracking roto

GA4, Google Ads u otras plataformas dejan de recibir determinados eventos.

12. Formularios que funcionan visualmente pero no envían datos

El usuario ve un mensaje de confirmación pero el lead nunca llega.

13. Páginas inaccesibles para determinados crawlers

Las reglas de robots o sistemas de seguridad pueden estar bloqueando involuntariamente rastreadores que forman parte de la estrategia GEO.

Errores más comunes en una migración web

Aunque cada proyecto es diferente, hay una serie de errores que se repiten con frecuencia cuando se lanza una nueva web. Muchos de ellos pueden afectar directamente al SEO / GEO, al tráfico orgánico, a la medición y a las conversiones.

1. No preparar un mapa de redirecciones

Uno de los errores más habituales es cambiar la estructura de URLs sin definir previamente qué debe ocurrir con las páginas antiguas.

Si una URL desaparece y no existe una redirección hacia su nueva versión, puede terminar devolviendo un error 404 y perder parte de la autoridad, tráfico y posicionamiento que había acumulado.

Lo recomendable es preparar antes del lanzamiento una relación entre:

• URL antigua.
• URL nueva.
• Tipo de redirección.
• Estado final de la página.

2. Redirigir todas las URLs antiguas hacia la home

Enviar todas las URLs eliminadas hacia la página principal puede parecer una solución sencilla, pero normalmente no es la mejor opción.

Las redirecciones deberían apuntar hacia la página nueva más equivalente posible.

Si una URL antigua hablaba sobre un servicio concreto, debería redirigir hacia ese mismo servicio o hacia la alternativa más relevante, no directamente a la home.

3. Publicar la nueva web con noindex

Durante el desarrollo es habitual bloquear el entorno de pruebas para evitar que aparezca en buscadores.

El problema aparece cuando esa configuración se mantiene al pasar la web a producción.

Una directiva noindex olvidada puede provocar que Google deje de indexar páginas importantes de la nueva web.

4. Mantener bloqueos incorrectos en robots.txt

Algo similar ocurre con robots.txt.

Una configuración pensada para el entorno de desarrollo puede terminar bloqueando rastreadores importantes cuando la nueva web ya está publicada.

En una estrategia SEO / GEO conviene revisar no solo Googlebot, sino también aquellos crawlers que formen parte de la estrategia de visibilidad en motores generativos.

5. Dejar canonicals apuntando al entorno de desarrollo

Este es otro error técnico frecuente.

La nueva web se publica correctamente, pero las etiquetas canonical siguen apuntando hacia URLs del staging o de la versión anterior.

Esto puede enviar señales contradictorias a los buscadores y dificultar la correcta indexación de las nuevas URLs.

6. Perder contenidos que ya estaban posicionando

Un rediseño suele buscar una web más limpia y visual, pero a veces esa simplificación elimina contenidos que estaban ayudando a posicionar.

Es frecuente perder:

• Textos de servicio.
• FAQs.
• Información técnica.
• Contenido de categorías.
• Enlaces internos.
• Datos relevantes.
• Entidades y contexto semántico.

Desde un punto de vista SEO / GEO, reducir contenido sin analizar su rendimiento previo puede provocar una pérdida de visibilidad.

7. Cambiar la arquitectura sin analizar el impacto

Modificar menús, categorías o niveles de navegación puede hacer que páginas importantes queden más profundas o incluso huérfanas.

Antes de cambiar la arquitectura deberíamos analizar qué páginas reciben más enlaces internos y qué secciones concentran mayor tráfico o posicionamiento.

8. No revisar el enlazado interno

Aunque las redirecciones estén correctamente implementadas, los enlaces internos deberían actualizarse para apuntar directamente a las nuevas URLs.

Mantener enlaces internos hacia URLs antiguas genera redirecciones innecesarias y hace menos eficiente el rastreo.

9. Publicar un sitemap XML desactualizado

El sitemap debería reflejar únicamente las URLs relevantes de la nueva web.

Un sitemap incorrecto puede incluir:

• URLs antiguas.
• Páginas redireccionadas.
• Errores 404.
• URLs con noindex.
• URLs del entorno de desarrollo.

Esto dificulta que los buscadores entiendan correctamente cuál es la estructura final del sitio.

10. Romper hreflang en webs internacionales

En webs multiidioma o multipaís, una migración puede romper fácilmente las relaciones entre versiones.

Los errores más comunes son:

• URLs incorrectas.
• Falta de reciprocidad.
• Idiomas mal definidos.
• Canonicals incompatibles.
• Referencias hacia URLs antiguas.

Esto puede afectar directamente a la visibilidad internacional.

11. Eliminar datos estructurados

Un rediseño puede mantener visualmente el mismo contenido y, sin embargo, eliminar el marcado Schema que existía anteriormente.

Conviene comprobar si siguen presentes los datos estructurados relevantes, como:

• Organization.
• LocalBusiness.
• Product.
• Article.
• BreadcrumbList.
• Event.

12. No comprobar GA4, GTM y conversiones

Una web puede migrarse correctamente desde el punto de vista SEO y, al mismo tiempo, perder toda la medición.

Es habitual encontrar:

• Etiquetas de GA4 que dejan de dispararse.
• Eventos que desaparecen.
• Formularios que ya no generan conversiones.
• Google Ads sin recibir datos.
• Meta Pixel mal implementado.
• Consent Mode incorrecto.

Por eso el tracking debe formar parte del checklist de migración.

13. No probar formularios, ecommerce o procesos críticos

No basta con comprobar que las páginas cargan.

También hay que validar que funcionan correctamente:

• Formularios.
• Compras.
• Reservas.
• Descargas.
• Inicios de sesión.
• Solicitudes de información.
• Pasarelas de pago.

Una migración puede parecer correcta técnicamente y estar perdiendo conversiones por un problema funcional.

14. No revisar la versión móvil

Muchos errores aparecen únicamente en determinados dispositivos.

Es importante comprobar:

• Menús.
• Botones.
• Formularios.
• Pop-ups.
• Contenido oculto.
• Velocidad.
• Diseño responsive.

15. No comparar la nueva web con la anterior

Uno de los mayores errores es revisar únicamente si la nueva web “funciona”.

La pregunta correcta debería ser:

¿La nueva web conserva o mejora lo que ya funcionaba en la anterior?

Por eso conviene comparar antes y después:

• URLs.
• Contenidos.
• Metadatos.
• Rankings.
• Tráfico.
• Backlinks.
• Enlazado interno.
• Datos estructurados.
• Conversiones.

16. No monitorizar después del lanzamiento

Una migración no termina el día en que la nueva web se publica.

Durante las semanas posteriores deberíamos revisar:

• Clics.
• Impresiones.
• Rankings.
• Indexación.
• Errores 404.
• Errores 5XX.
• Redirecciones.
• Sesiones orgánicas.
• Conversiones.
• Rastreo de bots.

Cuanto antes detectemos una anomalía, más sencillo será corregirla antes de que se convierta en una pérdida importante de visibilidad.

El lanzamiento no termina cuando la web está publicada

Después de poner la nueva web en producción empieza otra fase crítica: monitorizar.

Google necesita volver a rastrear URLs, procesar redirecciones, actualizar su índice y reasignar diferentes señales.

Por eso pueden existir fluctuaciones.

Lo importante es comprobar que la evolución es la esperada.

Durante las semanas posteriores deberíamos monitorizar:

• Clics.
• Impresiones.
• Rankings.
• Sesiones orgánicas.
• Conversiones.
• Páginas indexadas.
• URLs excluidas.
• Errores 404.
• Errores 5XX.
• Redirecciones.
• Rastreo de bots.
• Páginas más afectadas.
• Principales consultas.
• Backlinks hacia URLs antiguas.

Google recomienda mantener las redirecciones durante al menos un año y señala que, desde la perspectiva del usuario, pueden conservarse durante más tiempo.

Checklist SEO / GEO para lanzar una nueva web

Antes de publicar

• Rastrear la web actual.
• Exportar las URLs existentes.
• Analizar GA4.
• Analizar Google Search Console.
• Guardar rankings.
• Analizar backlinks.
• Definir la nueva arquitectura.
• Mapear URLs antiguas y nuevas.
• Preparar redirecciones.
• Comparar contenidos.
• Revisar enlazado interno.
• Revisar titles y meta descriptions.
• Revisar H1, H2 y estructura semántica.
• Revisar canonicals.
• Revisar robots.txt.
• Revisar directivas noindex.
• Revisar reglas para crawlers relevantes.
• Revisar sitemap.
• Revisar hreflang.
• Validar datos estructurados.
• Validar GA4 y GTM.
• Validar conversiones.
• Probar formularios.
• Probar ecommerce.
• Revisar versión móvil.
• Revisar rendimiento.

Después de publicar

• Rastrear inmediatamente producción.
• Revisar códigos de respuesta.
• Probar redirecciones.
• Revisar canonicals.
• Confirmar que no existen bloqueos accidentales.
• Actualizar y enviar el sitemap.
• Revisar Search Console.
• Verificar GA4.
• Verificar conversiones.
• Monitorizar rankings.
• Monitorizar tráfico.
• Monitorizar indexación.
• Revisar 404.
• Revisar logs y comportamiento de crawlers.
• Comparar datos con la situación previa a la migración.

Migrar una web no es cambiar una web por otra

Una migración bien ejecutada empieza mucho antes del día del lanzamiento.

Empieza cuando analizamos qué visibilidad tiene actualmente el sitio, qué URLs funcionan, qué contenidos generan tráfico, qué páginas reciben enlaces y qué señales queremos conservar.

Después debemos asegurarnos de que la nueva arquitectura, las URLs, los contenidos, la analítica y las reglas de rastreo están correctamente preparadas.

Y finalmente debemos comprobar qué ocurre cuando la nueva web entra en producción.

Porque el objetivo de un rediseño no debería ser únicamente conseguir una web más moderna.

Debería ser conseguir una web mejor sin perder todo el trabajo de SEO / GEO, autoridad, tráfico y visibilidad que la empresa ya había construido.

¿Has tenido problemas con tu migración web?

Por: Alexis Petit