Cómo migrar una web sin perder SEO: plan y checklist paso a paso

Primero define qué cambia realmente

No todas las migraciones tienen el mismo riesgo. Cambiar de servidor conservando dominio, rutas y HTML es principalmente una migración de infraestructura. Pasar de un CMS a otro puede alterar rutas, etiquetas, contenido renderizado y enlaces. Cambiar de dominio obliga a trasladar señales entre hostnames. Una reestructuración combina varias de estas operaciones y necesita más control.

Escribe una lista explícita de elementos que cambian y de los que deben permanecer. Si el objetivo es mover el hosting, no aproveches el mismo día para reescribir todas las páginas y renombrar categorías. Google recomienda separar cambios importantes cuando sea posible porque facilita el rastreo y, sobre todo, el diagnóstico. Una mejora posterior se puede medir; cinco cambios simultáneos convierten cualquier caída en una investigación incierta.

Define también el criterio de éxito: respuestas correctas, formularios operativos, equivalencia visual, conservación de conversiones, ausencia de URLs huérfanas y evolución de clics orgánicos. El posicionamiento puede fluctuar temporalmente mientras los buscadores vuelven a rastrear, por lo que no debe evaluarse solo con una captura del día siguiente.

Inventario previo: lo que no registras se pierde

Extrae todas las URLs conocidas desde el sitemap, el CMS, la analítica, Search Console si está disponible, backlinks relevantes y registros del servidor. Une las listas, normaliza protocolos y elimina duplicados sin descartar todavía páginas antiguas. Una URL que no aparece en el menú puede seguir recibiendo enlaces o visitas.

Para cada URL conserva código de estado, canonical, title, description, H1, directivas robots, idioma, tráfico, conversiones, enlaces internos y archivos principales. Guarda también sitemaps, robots, reglas de redirección, datos estructurados y capturas de plantillas clave. Este inventario permite comparar antes y después de forma automática.

Haz copia de la web, base de datos y configuración antes de tocar producción. Si la plataforma genera contenido desde una base, una copia solo de archivos no basta. Anota versiones, variables y tareas programadas necesarias para reconstruir el servicio. El rollback debe indicar quién decide activarlo y cuánto tiempo se esperará antes de considerar fallido el lanzamiento.

Construye un mapa uno a uno de URLs

Cada URL antigua debe tener un destino razonado. Si el contenido continúa, conserva la misma ruta cuando puedas. Si cambia, apunta a su equivalente más cercano mediante una redirección permanente 301 o 308. Si desaparece y no existe sustituto, devuelve un 404 o 410 correcto y ofrece navegación útil en la página de error.

No redirijas todo a la portada. Google advierte que agrupar muchas URLs sin relación en un destino genérico puede interpretarse como un soft 404. Tampoco encadenes redirecciones antiguas y nuevas: actualiza cada origen para llegar directamente al destino final. Las cadenas añaden latencia, dificultan el rastreo y complican futuras migraciones.

El mapa debe incluir imágenes o documentos con enlaces relevantes, variantes con y sin barra, HTTP y HTTPS, y subdominios que realmente reciban tráfico. Actualiza enlaces internos para que apunten directamente a las rutas nuevas; una redirección es una red de seguridad, no el mecanismo normal de navegación.

Qué probar en preproducción

Protege el entorno de pruebas con autenticación o restricción de red. No confíes únicamente en robots.txt: una URL de pruebas accesible puede descubrirse por otros enlaces. Asegúrate de retirar cualquier noindex antes del lanzamiento mediante una comprobación automatizada.

Rastrea la nueva web como lo haría un navegador sin sesión. Comprueba códigos 200, H1, títulos, canonical, hreflang, schema, imágenes, navegación, paginación, formularios y contenido generado con JavaScript. Compara las páginas de mayor tráfico una a una. Revisa que una URL inexistente devuelva 404 real en vez de la portada con 200.

Prueba las redirecciones con una tabla de origen y destino. Detecta bucles, cadenas, destinos 404 y diferencias de mayúsculas. Verifica el comportamiento en móvil, cookies, checkout, correos y analítica. Una migración SEO técnicamente correcta sigue siendo fallida si impide enviar un contacto o completar una compra.

Prepara el nuevo sitemap con URLs canónicas y un lastmod honesto. No incluyas páginas bloqueadas, redirigidas o duplicadas. Comprueba que robots permite rastrear recursos necesarios y que las canonicals usan el dominio definitivo, no localhost ni el hostname temporal.

Plan para el día del lanzamiento

1. Reduce cambios editoriales y congela datos cuando el sistema lo necesite.
2. Genera una última copia y registra hora, versión e imagen desplegada.
3. Publica la nueva plataforma y activa redirecciones del lado del servidor.
4. Ejecuta un smoke test de portada, plantillas, contacto, login y compra.
5. Rastrea el conjunto prioritario y después todas las URLs del mapa.
6. Comprueba canonical, robots, sitemap, analítica y códigos de error.
7. Envía el sitemap nuevo y, si cambia el dominio, utiliza la herramienta de cambio de dirección cuando corresponda.

Elige una ventana de menor actividad, pero no lances cuando nadie pueda responder. La persona técnica, quien valida negocio y quien controla DNS deben estar disponibles. Si el cambio depende de propagación, reduce previamente el TTL cuando sea apropiado y documenta la configuración anterior para revertir.

Seguimiento durante las primeras semanas

Observa respuestas 404 y 500, tráfico por plantilla, clics orgánicos, páginas indexadas, conversiones y carga del servidor. Tras una migración Google puede rastrear con más intensidad tanto rutas antiguas como nuevas; la infraestructura debe soportarlo. Compara grupos de URLs equivalentes, no solo el total del dominio.

Revisa los registros para descubrir bots y usuarios que siguen llegando a rutas sin mapear. Añade una redirección solo si existe un destino útil. Si una sección pierde visibilidad, compara contenido, enlaces internos, metadatos y renderizado con la versión anterior antes de concluir que el problema es la autoridad del dominio.

Mantén un diario de correcciones. Las métricas de un mismo día pueden estar afectadas por estacionalidad, campañas o retraso de datos. Una revisión diaria al principio y semanal después permite actuar sin convertir cada variación normal en un cambio de emergencia.

Errores que más visibilidad destruyen

• Publicar con noindex o bloqueo de robots heredado de preproducción.
• Cambiar todas las rutas y no crear un mapa de equivalencias.
• Usar JavaScript para redirigir cuando el servidor puede devolver 301.
• Canonicalizar páginas nuevas hacia el dominio antiguo o temporal.
• Eliminar contenido que respondía a la búsqueda sin revisar su tráfico.
• Devolver 200 para URLs inexistentes o redirigirlas todas a inicio.
• Olvidar imágenes, PDFs, hreflang o enlaces internos.
• Cancelar el hosting antiguo antes de validar redirecciones y DNS.

Checklist final de migración SEO

Antes: inventario completo, copia, mapa, baseline, entorno protegido y rollback. Durante: redirecciones permanentes, canonicals definitivas, sitemap limpio, analítica operativa y pruebas de negocio. Después: rastreo, monitorización de errores, revisión de indexación, comparación por grupos y conservación de redirecciones.

Una migración no tiene riesgo cero, pero sí puede tener un riesgo controlado y un procedimiento de recuperación. Luvalia integra este trabajo en proyectos de desarrollo y migración web, con pruebas antes del cambio y comprobaciones automáticas después del despliegue.