Migrar un WordPress sin perder posicionamiento es posible: con pre-auditoría completa, mapa de redirects 301, pruebas en staging de 7 a 21 días y monitoreo post-migración, los sitios mantienen el 95-100% del tráfico orgánico durante la transición y suelen ganar 5-15% en los siguientes 60 días por mejoras de hosting y performance.
Por qué la mayoría de migraciones WordPress destruyen el SEO
Una migración WordPress mal hecha puede borrar entre 30% y 70% del tráfico orgánico que tomó años construir. No es exageración: hemos auditado sitios que perdieron meses de inversión SEO porque alguien decidió migrar el viernes a las 5pm “y ya está”. Los problemas más comunes que destruyen posicionamiento durante una migración son evitables con metodología.
Las causas habituales de pérdida de SEO en migraciones: URLs cambiadas sin redirects 301, contenido perdido o reescrito accidentalmente, schema.org y meta tags no preservados, sitemap roto, robots.txt mal configurado bloqueando indexación, hosting nuevo con TTFB peor, certificado SSL mal configurado, y configuraciones de cache que sirven páginas erróneas a Googlebot.
La buena noticia: una migración bien planificada NO debe causar pérdida de tráfico. Sitios que migramos con metodología completa mantienen el 95-100% del tráfico durante la transición y suelen ganar 5-15% en los siguientes 60 días por mejoras de hosting, performance y schema.
Tipos de migración: hosting, dominio, estructura, completa
No todas las migraciones tienen el mismo riesgo. Conocer el tipo determina la estrategia.
Migración de hosting (mismo dominio, misma estructura)
Riesgo bajo. Cambia solo el servidor donde corre WordPress. URLs, contenido, schema permanecen idénticos. Solo hay que asegurar uptime durante el cambio de DNS.
Migración de dominio (cambio de URL completa)
Riesgo alto. Pasar de empresa-vieja.com a empresa-nueva.com requiere redirects 301 masivos, comunicación a Search Console, recuperación lenta de autoridad. Requiere 60-90 días para estabilizar.
Migración de estructura (cambio de URLs, mismo dominio)
Riesgo medio-alto. Reorganizar /blog/articulo-123 a /recursos/articulo requiere mapa de redirects 301 completo. Si se hace mal, se pierden backlinks y posicionamiento.
Migración completa (todo cambia)
Riesgo máximo. Cambio de hosting + dominio + estructura + tema/builder simultáneo, el escenario habitual cuando la migración acompaña un nuevo diseño web. Requiere planificación de 2-4 semanas mínimo. Es donde más pérdidas vemos cuando se hace sin metodología.
Pre-migración: la auditoría que evita el desastre
El 70% del éxito de una migración está antes de tocar nada. La pre-auditoría documenta el “estado de verdad” actual.
Inventario de URLs indexadas
Exportar de Search Console todas las URLs con impresiones en últimos 6 meses. Cruzar con sitemap.xml actual. Identificar URLs con tráfico orgánico que DEBEN preservarse o redirigirse.
Inventario de backlinks
Exportar de Ahrefs, Semrush o Moz los backlinks externos que apuntan a páginas específicas. Esas URLs son críticas: si las cambia sin redirect, pierde link juice.
Inventario de keywords con ranking
Exportar de Search Console todas las keywords donde el sitio aparece en posiciones 1-30. Documentar qué URLs están rankeando para no romperlas en la migración.
Auditoría técnica de baseline
Capturar PageSpeed, Core Web Vitals, schema validador, robots.txt, sitemap, .htaccess actual. Esto sirve de referencia post-migración para validar que todo se preservó.
Backup completo: archivos + base de datos + meta-datos
Antes de tocar el sitio, backup ABSOLUTO. Si algo sale mal en la migración, restaurar desde backup es el plan B.
Qué incluir en el backup
- Archivos completos de public_html/: tema, plugins, uploads, wp-config.php.
- Base de datos completa con todas las tablas (posts, postmeta, options, terms, users).
- Configuraciones de servidor: .htaccess, configuración de cron jobs, certificados SSL.
- Reglas de DNS actuales (zone file completo).
- Configuraciones de plugins críticos exportadas (SEOPress settings, BerqWP config, WooCommerce settings).
Plugins recomendados para backup completo
UpdraftPlus Premium (más fiable para sitios grandes), All-in-One WP Migration Pro (excelente para mover sitios completos), BackupBuddy (alternativa robusta), Duplicator Pro (con migración asistida). Los gratis funcionan para sitios pequeños; para sitios serios, las versiones pro evitan errores en sitios con WooCommerce o membresías.
Backup offsite obligatorio
El backup debe estar fuera del hosting actual y del nuevo. Subirlo a Backblaze B2, AWS S3, Google Drive, o NAS Synology propio. Si el hosting cae durante la migración, el backup en el mismo hosting no sirve.
Mapa de redirecciones 301: la pieza más crítica
Cuando una URL cambia, un redirect 301 (permanente) le dice a Google y al usuario “esta URL se mudó a esta nueva ubicación”. Sin redirects, los backlinks externos apuntan a páginas 404 y se pierde ranking.
Plantilla básica de mapa de redirects
| URL antigua | URL nueva | Tipo |
|---|---|---|
| /blog/post-viejo-1/ | /blog/categoría/post-nuevo-1/ | 301 |
| /servicios/ | /que-hacemos/ | 301 |
| /categoría/diseno/page/2/ | /blog/diseno/page/2/ | 301 |
Reglas para mapear bien
1 a 1 cuando posible (URL vieja A apunta a URL nueva A equivalente). Evitar redirects masivos a la home (Google lo trata como 404 soft). Cuando no hay equivalente directo, redirigir a la categoría o al post más relevante. Documentar TODAS las URLs con tráfico, no solo las top.
Wildcards y patrones
Para sitios grandes, usar reglas con regex. Ej: RewriteRule ^old-blog/(.*)$ /blog/$1 [R=301,L] mueve todo lo que estaba bajo /old-blog/ a /blog/ preservando los slugs.
.htaccess vs WordPress redirect plugins: cuándo cada uno
Los redirects pueden vivir en dos lugares: el archivo .htaccess del servidor (Apache/LiteSpeed) o un plugin de WordPress.
.htaccess (servidor)
Más rápido (procesado antes que WordPress). No depende de PHP ni de plugins. Sobrevive si WordPress cae. Recomendado para redirects masivos (100+) y reglas con regex. Requiere conocimiento de Apache rewrite syntax.
Plugin de WordPress (Redirection, Rank Math, SEOPress)
Interfaz amigable. Estadísticas de hits. Detección automática de 404 y sugerencias. Más lento (procesado por PHP). Recomendado para sitios con cambios frecuentes y para no-developers.
Combinación recomendada
Para migraciones grandes: redirects masivos en .htaccess + plugin para casos puntuales y monitoreo de 404. SEOPress Pro tiene módulo de redirects con monitorización 404 automática que es excelente para post-migración.
Migración en staging antes que producción
NUNCA migrar directo a producción. El staging es una copia idéntica del sitio en un entorno separado donde se prueba todo antes del cambio definitivo.
Cómo crear staging
Hostings administrados (Kinsta, WP Engine, Rocket.net, SiteGround) tienen staging con un click. Hostings genéricos: subdominio (staging.empresa.com), instalación WordPress nueva, importar backup completo. Bloquear staging con .htpasswd para que Google no lo indexe.
Qué validar en staging
Funcionalidad crítica completa: formularios envían, checkout WooCommerce funciona, login de usuarios opera, áreas privadas accesibles. Visualmente: todas las páginas pixel-perfect. SEO: schema válido, meta tags correctos, sitemap genera bien. Performance: Core Web Vitals dentro de targets.
Tiempo en staging
Mínimo 7 días para sitios medianos. 14-21 días para sitios complejos con WooCommerce, membresías, integraciones third-party. Tiempo para detectar bugs sutiles que solo aparecen con uso real.
Día D: pasos exactos en orden cronológico
Este es el orden que aplicamos en migraciones reales. Hora 0 = momento del cambio.
T-24h: Preparación
Bajar TTL del DNS a 300 segundos para que el cambio se propague rápido. Comunicar al equipo y stakeholders el horario del cambio. Modo mantenimiento programado en sitio actual con mensaje claro.
T-2h: Backup final
Backup definitivo del sitio actual ya con todos los cambios “frescos” hasta el momento. Importar al staging para sincronizar.
T-1h: Sincronización final
Pasar el contenido más reciente (posts, productos, comentarios) del actual al staging si hubo cambios. Última validación visual.
T-0: Cambio de DNS
Cambiar el DNS A record (o CNAME) al hosting nuevo. Confirmar propagación con whatsmydns.net y dig en terminal.
T+30min: Validación inicial
Verificar que el sitio responde en el hosting nuevo. SSL activo. Sin errores 500. Páginas críticas cargan bien.
T+1h: Validación SEO
Search Console: enviar nuevo sitemap. URL Inspection en 3-5 URLs críticas. Validar que robots.txt no bloquea indexación. Confirmar redirects 301 funcionando con curl.
T+2h: Comunicación
Confirmar al equipo que la migración está completa. Equipos de soporte alertados para detectar problemas reportados por usuarios.
Post-migración: 24 horas críticas
El primer día post-migración es donde aparecen los problemas sutiles que en staging no salieron.
Monitoreo en tiempo real
Search Console: revisar Coverage, Sitemaps, Crawl Stats cada 2-4 horas. Google Analytics: comparar tráfico hora a hora vs misma hora día anterior. Alertas de hosting: respuesta del servidor, errores 500, picos de CPU.
Errores 404 emergentes
SEOPress Pro 404 monitor o Redirection plugin detectan URLs que generan 404. Cada hora revisar el log y agregar redirects faltantes.
Validación de funcionalidad por equipo
Equipo de ventas testea formularios de contacto. Equipo de e-commerce testea flujo de compra completo. Equipo de soporte testea áreas privadas. Si algo falla, rollback al hosting viejo es opción válida.
Validaciones técnicas (Search Console, Ahrefs, Screaming Frog)
Auditoría completa los días 1, 3, 7, 14, 30 post-migración.
Search Console
Cobertura de indexación: pages indexed debe estar igual o mayor. Errores 4xx/5xx: tendencia debe ser cero crecimiento. Sitemaps: URLs procesadas vs descubiertas. Mobile usability: sin nuevos errores.
Crawl con Screaming Frog
Ejecutar Screaming Frog SEO Spider en el sitio nuevo. Detectar: redirects rotos (chains), 404 internos, meta tags duplicados, schema inválido, canonical mal apuntando. Comparar con baseline pre-migración.
Ahrefs/Semrush Site Audit
Site audit completo cada semana primer mes. Comparar errores nuevos vs baseline. Detectar pérdidas de backlinks (links que apuntaban a páginas eliminadas sin redirect).
Core Web Vitals comparativos
CrUX dashboard antes y después de migración. LCP, INP, CLS deben ser iguales o mejores. Si empeoraron, es señal de hosting peor o configuración nueva incorrecta.
Recuperación de tráfico perdido: las primeras 4 semanas
Es normal que tráfico orgánico baje 5-15% en la primera semana de una migración bien hecha. Si baja más de 25%, hay problema serio.
Semana 1
Caída esperada 10-15%. Google está reprocesando URLs nuevas. Foco: corregir 404 emergentes, agregar redirects faltantes, validar schema.
Semana 2
Caída debe estar bajando a 5-8%. Si sigue alta, revisar Search Console para errores nuevos.
Semana 3-4
Tráfico recupera al 95-100% del baseline. Si la migración mejoró hosting/performance, suele superar baseline en 5-15% por mejora de Core Web Vitals.
Si NO recupera
Auditoría profunda: ¿se preservaron meta tags? ¿schema sigue válido? ¿internal linking equivalente? ¿hay penalización manual? El 80% de migraciones que no recuperan tienen problema en redirects 301 incompletos.
Caso real: migración de e-commerce de 10K productos sin caída de tráfico
Cliente: tienda WooCommerce en Bogotá, 10.200 productos, 850 categorías y subcategorías. Migración completa: hosting (compartido económico → VPS LiteSpeed NVMe), tema (Divi 4 → Divi 5), estructura URL (de /?product=slug a /producto/slug/).
Plan ejecutado
- Pre-auditoría: 18 días. Inventario de 10.200 URLs producto, 850 categorías, 32 páginas estáticas. Mapa de 11.082 redirects 301 documentados.
- Staging completo: 21 días. WooCommerce + 24 plugins probados pieza por pieza. Tests de checkout end-to-end con 12 escenarios.
- Backup: 4 backups en lugares distintos (UpdraftPlus a Google Drive, All-in-One Migration archivo .wpress, snapshot de hosting nuevo, dump SQL al NAS).
- Día D: domingo 4am hora Colombia (tráfico mínimo). Ventana de migración 2 horas.
- Post-migración: monitoreo 24/7 primeros 5 días.
Resultados
Día 1 post-migración: tráfico orgánico -8% (caída esperada). Día 7: tráfico orgánico -2%. Día 30: tráfico orgánico +12% vs baseline. Day 60: +21% vs baseline. La mejora se debe a Core Web Vitals (LCP de 4.2s a 1.8s) que mejoraron ranking en queries competitivas.
404 emergentes detectados durante mes 1: 47 URLs antiguas no contempladas en mapa inicial. Todas resueltas con redirects en menos de 24 horas tras detectar.
