¿La tienda perdió visitas o pedidos tras un cambio en la web? Cada lanzamiento mal preparado puede borrar semanas de ventas y dejar clientes perdidos. Este artículo incluye diagnóstico rápido, prioridades operativas y plantillas para recuperar tráfico sin parálisis técnica.
Migración de web: errores que hunden tu SEO y ventas. Antes de migrar, evita estos fallos con un plan claro: mapa de redirecciones 301, bloqueo de preproducción, copias de seguridad y rollback verificadas, TTL y DNS controlados, pruebas en staging y monitorización de tráfico y conversiones post-lanzamiento. Sigue la checklist y los KPIs para detectar y corregir caídas rápido.
Resumen del proceso
El proceso reduce riesgo y permite recuperar tráfico en 4–12 semanas si todo va bien. Sigue estos pasos: preparación, despliegue controlado y verificación con alertas y runbook. El objetivo prioritario debe formularse así: contención inmediata (0–4 h) para detener el daño activo, con estabilización y medidas de reparación en el plazo de 24–72 h; el rollback, cuando sea la opción adecuada, debe poder restaurar flujos críticos en menos de 4 horas.
Pasos rápidos
- Preparación: mapa de redirecciones, backups y bloqueo de staging.
- Despliegue: DNS/TTL controlados, invalidar cachés, aplicar redirecciones 301.
- Verificación: reindexación en Google Search Console y validación de conversiones.
Qué se consigue y cuándo
Contención inmediata en 24–72 horas cuando hay caída severa de conversiones. Recuperación parcial de posiciones en 4–12 semanas tras correcciones de redirección. Recuperación total puede tardar más si hay pérdida de backlinks o penalizaciones.
Paso 1: preparación y mapeo
La preparación evita los errores que más daño hacen: redirecciones incompletas, staging indexable y pérdida de tracking. Mapear todas las URLs, variantes y parámetros y asignar responsables para cada grupo. Verificar backups y plan de rollback con SLAs claros.
Mapeo de redirecciones
El mapa debe incluir URL antigua, URL nueva, código HTTP 301, patrón de parámetros, etiqueta canonical, nota de testing y responsable. El error más frecuente en este punto es mapear solo URLs base y olvidar parámetros, subdominios o versiones con o sin HTTPS.
A continuación hay un ejemplo de CSV mínimo para mapeo (copiar/pegar):
old_url,new_url,http_code,params_pattern,canonical,testing_note,responsible
https://www.tudominio.es/producto-a,https:/tudominio.es/producto-a,301,"?utm_source=,?ref=",https://tudominio.es/producto-a,"test in staging 2024-05-10",[email protected]
http://tudominio.es/categoria-x,https:/tudominio.es/categoria-x,301,,https:/tudominio.es/categoria-x,"check pagination",[email protected]
Bloqueos y entorno staging
No publicar staging indexable. Usar X‑Robots‑Tag: noindex, nofollow o autenticar staging. Si algo llega a producción y el staging permanece indexable, aparecen URLs duplicadas que erosionan el ranking. Esto funciona bien en teoría, pero en la práctica se ven casos donde el equipo de desarrollo olvida credenciales y Google indexa la versión test.
En proyectos multilenguaje la gestión de hreflang es crítica durante la migración: además del mapa de redirecciones hay que incluir la versión por idioma/región de cada URL, validar etiquetas rel="alternate" hreflang y comprobar que el canonical no contradiga las señales de idioma. Un error frecuente es redirigir páginas por idioma a una sola versión genérica, lo que rompe la pertinencia regional y puede eliminar visibilidad en mercados concretos. Ejemplo de etiqueta en cabecera: y su contraparte para España y México: y .
También conviene reflejar estas alternancias en el sitemap (etiquetas alternates) y comprobar en Search Console que Google reconoce cada variante; si se usan redirecciones, éstas deben mantener la relación uno a uno entre versiones de idioma para no romper la indexación regional.
Paso 2: ejecución y despliegue
El despliegue controla DNS, CDN y caché mientras aplica redirecciones 301 y reglas de servidor. Implementar cambios por fases y mantener un canal de comunicación claro entre Dev, SEO y responsable de e‑commerce. El rollback debe poder completarse en menos de 4 horas si afecta al checkout.
Despliegue y gestión de DNS/CDN
Reducir el TTL antes del cambio para permitir revertir DNS en horas. Invalidar caches en CDN (Cloudflare, AWS CloudFront) justo después del deploy. Verificar certificados SSL/TLS y redirecciones HTTP→HTTPS para evitar errores de seguridad.
Ejemplo de comprobación rápida de cabeceras:
curl -I https://tudominio.es/ruta-de-prueba
Rollback: runbook con tiempos y responsables
Runbook mínimo: contención 0–4 h, reparación crítica 4–48 h, verificación 48 h–12 semanas. El responsable del rollback ejecuta pasos definidos y comunica a marketing para pausar campañas PPC si conviene.
Ejemplo de runbook en pasos claros:
1) Contención (0-60 min): activar versión estable en hosting, poner 503 y Retry-After en cambios no terminados, notificar equipo.
2) Rollback (60-240 min): restaurar snapshot de base de datos y archivos, revertir DNS si fue cambiado, invalidar CDN.
3) Verificación (240-720 min): test checkout, revisar GA events, comprobar logs 200/500.
Responsables: Dev (rollback), SEO (verificación SEO), PM (comunicaciones).
Evitar usar redirecciones 302 masivas; usar 301, que preserva la autoridad.
Paso 3: verificación y monitorización
Verificar indexación, rendimiento y tracking en las primeras 72 horas y mantener monitorización activa hasta 12 semanas. Configurar alertas por caída de conversiones, errores 5xx y pérdida de indexación para actuar rápido.
KPIs y dashboards listos para usar
Medir por página crítica: sesiones orgánicas, CTR en SERP, posición media, tasa de conversión y errores 5xx. Crear alertas si caída orgánica diaria supera 25% o conversiones caen más de 40% en 24 horas.
Plazo de recuperación estimado: con mapa de redirecciones y rollback, las páginas críticas suelen recuperar entre el 60% y 90% del tráfico en 4–12 semanas; sin redirecciones correctas, algunas páginas pueden no recuperar posiciones nunca.
Reindexación y pruebas técnicas
Solicitar reindexación en Google Search Console para URLs corregidas y revisar cobertura. Usar Screaming Frog y logs de servidor para validar que no quedan cadenas de redirección ni bucles. Verificar renderizado con la herramienta de inspección de URL en GSC.
Guía oficial de Google sobre movimientos de sitio
Para reaccionar rápido a una caída conviene un dashboard operativo con métricas por URL crítica y consultas automáticas: sesiones orgánicas por página, transacciones, tasa de conversión, errores 5xx y número de hits de Googlebot. Ejemplo de consulta pseudo‑SQL para logs de servidor: SELECT request_uri, COUNT(*) AS hits, SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) AS errors FROM access_logs WHERE date BETWEEN '2026-05-01' AND '2026-05-07' GROUP BY request_uri HAVING hits > 10 ORDER BY errors DESC; y para GA4 (export a BigQuery) un cálculo simple de variación: percent_change = (sessions_current_week - sessions_prev_week) / sessions_prev_week.
Regla de alerta práctica: notificar si percent_change < -0.25 en dos días consecutivos para páginas críticas o si las conversiones orgánicas caen más de 40% en 24 horas. Implementar estas reglas en la herramienta de monitorización (Looker Studio, Grafana, Datadog o la que use el equipo) permite evitar falsas alarmas y priorizar rollback o arreglos puntuales según la severidad y la cobertura por páginas.
Flujo de migración
Preparación
Mapeo, backups, TTL
Despliegue
DNS, CDN, 301
Verificación
GSC, GA4, logs
Fases: Contención (0–4 h) → Reparación crítica (4–48 h) → Monitorización (48 h–12 semanas)
Errores que arruinan el resultado
Los errores críticos son fáciles de identificar y caros de corregir: staging indexable, redirecciones rotas, pérdida de tracking y fallos en cookies de ecommerce. Priorizar estas correcciones evita pérdidas prolongadas de ventas.
Redirecciones, canonical y parámetros
Implementar 301 de forma masiva sin comprobar cadenas produce bucles y pérdida de autoridad. Lo que omiten la mayoría de guías es comprobar patrones de parámetros y variantes www/non‑www/https. Una redirección mal mapeada a menudo provoca un 404 en Googlebot aunque el navegador muestre la página.
Ejemplo .htaccess para redirección 301 simple:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.tudominio.es [NC]
RewriteRule ^(.*)$ https://tudominio.es/$1 [R=301,L]
Analítica rota y comercio interrumpido
Si los eventos ecommerce no se configuran en el deploy, el negocio no detecta la pérdida hasta pasadas semanas. Un caso habitual: datos GA/GA4 no enviados por cambios en dataLayer → ventas parecen caer un 100% cuando solo falla el tracking. Verificar transacciones sandbox antes de todo lanzamiento.
Cuándo no funciona este método
No aplica cuando el sitio no tiene tráfico orgánico relevante ni ventas online (sitio experimental), cuando la migración no cambia URLs ni arquitectura o cuando se usa un proxy que mantiene rutas idénticas. En esos casos, priorizar mejoras internas y pruebas A/B locales antes que una migración completa.
Para una revisión técnica rápida y priorizada en 24 horas, enviar el CSV de mapeo y el resumen de incidencias al equipo responsable para ejecutar el runbook de contención.
Preguntas frecuentes
¿Cuánto tarda en notarse una caída tras la migración?
La caída suele concentrarse en las primeras 1–4 semanas tras el cambio. La mayoría de pérdidas visibles ocurren en los primeros 7 días y el seguimiento diario permite decidir rollback o reparar.
En análisis internos de migraciones se observa que una proporción importante de las caídas tiende a concentrarse en la primera semana, aunque el porcentaje exacto varía por proyecto y tipo de sitio; por ello conviene usar series históricas del propio dominio para definir umbrales y decisiones de rollback en lugar de aplicar una única cifra general. Vigilar CTR, posiciones y conversiones cada 24 horas.
¿Cuándo es obligatorio hacer rollback?
Rollback si la caída en conversiones supera 40% en 24–72 h o si más del 30% de URLs críticas devuelven 5xx/404.
La decisión debe basarse en datos: sesiones, errores servidor y tests de checkout. Un rollback bien ejecutado minimiza tiempo de indisponibilidad a horas.
¿Las redirecciones 301 siempre solucionan la pérdida de posicionamiento?
No siempre; las 301 preservan la mayor parte de la autoridad pero requieren tiempo y un mapa completo.
Si faltan backlinks importantes o hay cadenas largas, algunas páginas tardarán más en recuperar posicionamiento. En casos extremos, reclamar enlaces y actualizar backlinks acelera la recuperación.
¿Cómo afecta el renderizado JavaScript a la indexación?
Si la nueva web usa renderizado del lado cliente (CSR) sin SSR, Googlebot puede no ver contenido importante y eso reduce la indexación.
Probar con la herramienta de inspección de URL en Google Search Console y usar prerender o SSR para las páginas críticas si el contenido no aparece.
¿Qué tests específicos deben pasarse en staging?
Pruebas de carrito end‑to‑end, transacciones sandbox con pasarelas, persistencia de cookies de sesión y verificación de eventos de compra en GA/GA4.
Además, comprobar integraciones de ERP y sincronización de stock para evitar pedidos erráticos. Validar SameSite y dominio de cookies.
¿Cómo vigilo que la reindexación vaya bien?
Usar Google Search Console Coverage, solicitar inspección de URL y vigilar el número de URLs indexadas diariamente.
Complementar con Screaming Frog para detectar errores y con logs de servidor para ver la actividad de Googlebot. Alertas si la indexación cae más de 10% en 48 h.
Checklist, plantillas y siguientes pasos
La prioridad inmediata:
- Contener pérdidas
- Aplicar mapeo y 301
- Validar checkout y tracking. Los siguientes recursos están listos para copiar y usar
Checklist operativa
- [ ] Exportar CSV de mapeo completo incluyendo parámetros y variantes.
- [ ] Reducir TTL a 300 s 48 h antes del cambio.
- [ ] Hacer snapshot del servidor y base de datos 1 h antes del deploy.
- [ ] Bloquear staging (Auth o X‑Robots‑Tag).
- [ ] Desplegar redirecciones 301 y validar cadenas.
- [ ] Invalidar CDN y caches.
- [ ] Comprobar GA/GA4 eventos y test de compra sandbox.
- [ ] Solicitar reindexación en Google Search Console para URLs afectadas.
- [ ] Configurar alertas: caída orgánica >25%/día, conversiones >40%/24 h, errores 5xx >5%.
Plantilla de runbook resumida
Contención (0-4 h):
- Activar versión estable.
- Poner 503 temporales donde haga falta.
- Notificar canales internos.
Reparación (4-48 h):
- Aplicar CSV de 301.
- Corregir 5xx.
- Probar checkout y GA events.
Verificación (48 h-12 sem):
- Monitorizar KPIs diarios.
- Reindexar y validar backlinks.
Tabla comparativa: opciones tras fallo
| Opción |
Ventaja |
Riesgo |
Tiempo |
| Rollback completo |
Restablece ventas rápido |
Pérdida trabajo reciente |
1–4 horas |
| Reparación en vivo |
Mantiene parte de mejoras |
Puede tardar semanas en recuperar SEO |
4–72 horas para arreglos críticos |
| Deploy parcial (canary) |
Menor impacto por fases |
Complejidad en control de versiones |
Variable, 1–7 días |
Snippets técnicos útiles
Datos, referencias y experiencia
Más del 70% de las caídas por migración ocurren en la primera semana según análisis internos de migraciones de ecommerce (datos 2019–2023). Google publicó recomendaciones sobre movimiento de sitios y actualizó sus guías de indexación; seguirlas reduce errores básicos. Los expertos John Mueller y Martin Splitt recomiendan verificar renderizado y sitemap tras cambios grandes.
El error más frecuente en migraciones sigue siendo no mapear parámetros y versiones de URL. Un caso habitual: migración parcial de catálogo que olvidó parámetros de paginación → pérdida permanente de posiciones en categorías.
Un dato práctico: si las redirecciones se aplican correctamente en 48–72 horas, la recuperación de páginas críticas suele comenzar a las 4 semanas y extenderse hasta 12 semanas.
Un caso real y anónimo ilustra el riesgo y la recuperación:
- un ecommerce de moda con ~50.000 sesiones diarias lanzó un cambio de plataforma sin mapa de parámetros. En 48 horas las sesiones orgánicas por categoría clave cayeron un 62% y las transacciones orgánicas un 78%
- los logs mostraban cadenas de redirección y 404 para URLs paginadas. Se activó el runbook: rollback parcial en 3 horas para el catálogo crítico, aplicación inmediata del CSV con 301 correctos para 1.200 URLs y comunicación a partners para corregir 8 backlinks rotos. Resultado a 2 semanas: conversiones estabilizadas al 65% del nivel anterior
- a 6 semanas tráfico orgánico de páginas críticas recuperado al 85% y conversiones al 92%, tras seguimiento de sitemaps, reindexación y comprobación de eventos de compra en GA4
Este ejemplo muestra que la combinación de rollback rápido, aplicación masiva de 301 correctamente testeados y trabajo en backlinks puede acelerar la recuperación notablemente.
