Migración web SEO: cómo cambiar de CMS o URLs sin improvisar

Una migración web SEO es el proceso de trasladar dominio, CMS, diseño, arquitectura o URLs preservando el acceso, el contenido útil y las señales que los buscadores ya conocen. No existe una garantía de cero fluctuación. Sí existe una forma controlada de reducir riesgo.

La migración empieza antes del desarrollo y termina después del lanzamiento. El fichero de redirecciones es una parte. No es el plan entero.

Qué cambios requieren un plan de migración

Requieren plan los cambios que afectan a URLs, dominio, protocolo, contenido indexable, renderizado o señales técnicas. Cambiar solo estilos puede no necesitarlo.

Los escenarios habituales son cambio de dominio, migración de HTTP a HTTPS, sustitución de CMS, nueva arquitectura, fusión de sitios y rediseño con rutas nuevas. Cada uno tiene riesgos distintos.

Qué hay que inventariar antes de tocar la web

El inventario debe reunir todas las URLs conocidas y las señales que ayudan a decidir su destino. Rastreo, sitemap y analítica por separado dejan huecos.

Incluimos URLs del CMS, sitemap, Search Console, analítica, enlaces externos, campañas y archivos. Para cada una registramos estado, canonical, tráfico, consultas, conversiones, enlaces, tipo de contenido y destino propuesto.

El resultado es una tabla de decisiones: conservar, trasladar, fusionar, retirar o corregir.

Cómo crear el mapa de redirecciones

Cada URL antigua debe redirigir al equivalente nuevo más cercano cuando exista una correspondencia real. Mandarlo todo a la portada confunde a usuarios y buscadores.

Usamos redirecciones permanentes directas, evitamos cadenas y comprobamos parámetros, mayúsculas, barra final, idiomas, imágenes y PDF. Una URL retirada sin sustituto debe responder 404 o 410.

Google recomienda redirecciones permanentes del lado del servidor y mantenerlas generalmente durante al menos un año; conservarlas más tiempo ayuda a usuarios y enlaces antiguos.Guía oficial de Google para migraciones

Qué preparar en la nueva web

La nueva web debe estar rastreable, indexable y medible antes de recibir tráfico. El entorno de pruebas puede estar bloqueado. Producción no.

Validamos:

• Canonical autorreferente donde corresponde.
• Robots.txt y etiquetas robots.
• Sitemap con URLs finales y códigos 200.
• Enlaces internos apuntando a destinos finales.
• Hreflang en proyectos internacionales.
• Metadatos y encabezados migrados.
• Datos estructurados coherentes.
• Analítica, consentimiento y conversiones.
• Imágenes, descargas y recursos necesarios.

Cómo probar antes del lanzamiento

Las pruebas se ejecutan contra la tabla de migración y las plantillas, no mediante una navegación manual aleatoria. Cada regla necesita resultado esperado.

Rastreamos staging si es accesible de forma segura, comparamos inventarios y verificamos una muestra representativa. Probamos redirecciones en un entorno equivalente y buscamos bucles, cadenas, destinos 404 y pérdidas de parámetros necesarios.

También comparamos HTML renderizado. Un contenido presente en el CMS pero ausente en la respuesta pública no está migrado.

Qué hacer el día del lanzamiento

El lanzamiento debe seguir una secuencia con responsables y posibilidad de reversión. Congelamos cambios editoriales, generamos copia, desplegamos, activamos redirecciones y ejecutamos comprobaciones críticas.

Las primeras pruebas cubren portada, plantillas, formularios, robots, sitemap, canonical, códigos HTTP, analítica y una muestra de redirecciones. Después rastreamos el sitio completo.

Qué revisar después

El seguimiento compara datos diarios al principio y después amplía el intervalo conforme se estabiliza el rastreo. Revisamos errores, indexación, impresiones, clics, conversiones y logs si están disponibles.

Segmentamos por tipo de página. Una caída en todo el dominio sugiere un problema transversal. Una caída en una plantilla apunta a renderizado, canonical, contenido o enlazado de ese grupo.

Qué errores causan más pérdidas

Los errores más dañinos son bloquear producción, perder contenido, redirigir sin equivalencia y lanzar sin medición. También aparecen canonical hacia staging, sitemap antiguo, noindex heredado y enlaces internos que siguen pasando por redirecciones.

No atribuiría cualquier cambio de tráfico a la migración. Hay estacionalidad, actualizaciones y demanda. Por eso guardamos una línea base y comparamos grupos equivalentes.

Cuándo se considera terminada

La migración termina cuando las rutas antiguas resuelven correctamente, las nuevas se rastrean e indexan y el rendimiento se ha estabilizado dentro de los criterios acordados. Publicar la nueva web solo abre el periodo de observación.

En un proyecto web profesional el mapa SEO forma parte del alcance desde el inicio. Añadirlo la víspera del lanzamiento suele convertir decisiones de arquitectura en una carrera contra el reloj.