Los errores al migrar WordPress van más allá de la pantalla en blanco. Descubre cuáles son los más graves, por qué ocurren y cómo evitarlos.
Tabla de contenidos
- Por qué fallan las migraciones WordPress con más frecuencia de lo que parece
- Error 1 — URLs y rutas absolutas sin actualizar
- Error 2 — Pantalla en blanco (White Screen of Death)
- Error 3 — Conflictos de versión de PHP
- Error 4 — Pérdida de SEO por falta de redirecciones
- Error 5 — Base de datos incompleta o corrupta
- Error 6 — No hacer backup verificado antes del corte
- Error 7 — Caché sin limpiar en el servidor destino
- Lo que diferencia una migración que sale bien de una que no
Los errores al migrar WordPress tienen una característica frustrante: muchos no aparecen durante el proceso, sino días o semanas después, cuando el cliente ya está en producción y el daño ya está hecho. Pantallas en blanco, URLs rotas, imágenes que desaparecen, pérdidas de SEO que tardan meses en recuperarse. Este artículo repasa los fallos más graves que ocurren en una migración WordPress real — no los teóricos — y explica por qué suceden para que puedas anticiparlos.
Por qué fallan las migraciones WordPress con más frecuencia de lo que parece
WordPress almacena rutas absolutas en la base de datos. Esto significa que cuando mueves un sitio de un servidor a otro, o de un dominio a otro, cientos de referencias internas siguen apuntando a la ubicación antigua. No es un bug: es la arquitectura del sistema. El problema es que muchas guías de migración simplifican este paso hasta hacerlo irreconocible, y quien ejecuta el proceso sin entenderlo bien acaba con un sitio que «parece que funciona» pero tiene problemas ocultos.
A eso hay que sumar diferencias de entorno: versión de PHP, configuración de MySQL, límites de memoria, módulos de Apache o Nginx activos. Un plugin que funcionaba perfectamente en el servidor origen puede romperse en el destino por una diferencia de configuración de dos líneas en el php.ini. Y al revés: a veces el entorno destino es más permisivo y oculta errores que deberían haberse detectado antes.
Error 1 — URLs y rutas absolutas sin actualizar
Este es el error más frecuente y el que más confunde a quienes no tienen experiencia técnica. WordPress guarda en la tabla wp_options los valores siteurl y home, pero además hay rutas absolutas serializadas en otras tablas: metadatos de posts, opciones de plugins, configuraciones de constructores visuales como Elementor o Divi.
Un simple UPDATE en la base de datos no es suficiente. Los datos serializados de PHP tienen una longitud calculada que se rompe si haces un reemplazo directo de texto sin tener en cuenta la serialización. La herramienta estándar para esto es Search & Replace DB, que maneja la re-serialización automáticamente. Usarla mal — o no usarla — genera errores que pueden aparecer en cualquier parte del sitio, meses después.
Síntoma habitual: imágenes que no cargan, widgets configurados que muestran contenido vacío, shortcodes de plugins que devuelven error.
Error 2 — Pantalla en blanco (White Screen of Death)
La pantalla blanca es probablemente el error más conocido al migrar WordPress. Técnicamente es un error PHP fatal que el servidor no muestra por defecto para no exponer información sensible. Puede venir de varias fuentes: un plugin incompatible con la versión de PHP del servidor destino, un tema que usa funciones deprecadas, un límite de memoria insuficiente, o un archivo .htaccess con reglas que no son compatibles con la configuración del nuevo servidor.
El primer paso siempre es activar el modo debug de WordPress añadiendo en wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Esto escribe los errores en /wp-content/debug.log sin mostrarlos en pantalla. Leer ese archivo es el primer diagnóstico real. Sin él, estás adivinando.
Error 3 — Conflictos de versión de PHP
Migrar de un servidor con PHP 7.4 a uno con PHP 8.1 no es transparente. Muchos plugins escritos hace tres o cuatro años usan funciones que han sido eliminadas en PHP 8.x — strftime(), money_format(), o el uso de create_function(), entre otros. El resultado puede ser desde avisos de deprecación inofensivos hasta errores fatales que rompen la carga del sitio.
La comprobación correcta antes de migrar es revisar la compatibilidad de cada plugin activo con la versión de PHP del servidor destino. El plugin PHP Compatibility Checker automatiza este análisis. Si detecta incompatibilidades, hay que decidir antes de migrar si se actualizan los plugins, se buscan alternativas o se mantiene la versión de PHP del servidor origen.
Este paso se salta con frecuencia porque parece burocrático. No lo es: es la diferencia entre una migración que tarda cuatro horas y una que tarda dos días de depuración.
Error 4 — Pérdida de SEO por falta de redirecciones
Cambiar la estructura de URLs durante una migración sin implementar redirecciones 301 correctas es uno de los errores con consecuencias más duraderas. Google indexa las URLs antiguas, y si al crawlear encuentra un 404 donde antes había contenido, ese posicionamiento se pierde. No de golpe — gradualmente, durante semanas, hasta que Google actualiza su índice.
La situación se complica cuando la migración incluye cambio de dominio, cambio de protocolo (HTTP a HTTPS) o reestructuración de permalinks. Cada uno de esos cambios genera una capa nueva de redirecciones que hay que mapear y testear antes de hacer el corte.
Lo mínimo necesario: exportar todas las URLs indexadas desde Google Search Console antes de la migración, cruzarlas con la nueva estructura y crear las redirecciones correspondientes. Si hay cientos de URLs, esto requiere un mapa de redirecciones documentado, no hacerlo «de memoria» el día del corte.
Error 5 — Base de datos incompleta o corrupta
Los errores al migrar la base de datos son especialmente traicioneros porque pueden no ser evidentes de inmediato. Un export de MySQL interrumpido por timeout, una importación con charset incorrecto (utf8 vs utf8mb4), o tablas de prefijo diferente que no se mapean correctamente — todos estos problemas generan sitios que parecen funcionar pero tienen datos corruptos o incompletos.
La verificación básica después de importar: comprobar que el número de filas en las tablas principales del destino coincide con el origen, y revisar que el cotejamiento (collation) de las tablas es coherente. Una discrepancia entre utf8_general_ci y utf8mb4_unicode_ci puede provocar caracteres corruptos en títulos, descripciones y contenido — especialmente en textos con acentos o símbolos.
Error 6 — No hacer backup verificado antes del corte
Técnicamente no es un error durante la migración, sino antes de ella. Pero aparece en el top de problemas reales porque el backup existe pero no se ha verificado. Un backup corrupto o incompleto es funcionalmente igual a no tener backup.
Un backup verificado implica: exportación completa de archivos y base de datos, almacenamiento en ubicación externa al servidor (no en el mismo hosting), y una prueba de restauración en entorno de staging antes de proceder. Este último paso se omite casi siempre porque «lleva tiempo». El tiempo que cuesta restaurar un sitio roto sin backup verificado es entre diez y cien veces mayor.
Error 7 — Caché sin limpiar en el servidor destino
Después de una migración exitosa en todos los parámetros técnicos, el sitio puede seguir mostrando contenido antiguo, páginas en blanco o errores intermitentes por caché no invalidada. Esto afecta a múltiples capas: caché del plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache), caché a nivel de servidor (Varnish, Redis, OPcache), y caché del CDN si lo hay.
El orden correcto al finalizar una migración: desactivar temporalmente los plugins de caché, limpiar la caché de OPcache desde la administración del servidor, purgar el CDN si existe, y solo entonces reactivar y regenerar. Hacer esto en orden inverso — o no hacerlo — puede llevar horas de diagnóstico innecesario.
Lo que diferencia una migración que sale bien de una que no
Revisando estos errores en conjunto, el patrón es claro: los fallos en migraciones WordPress no suelen ser técnicamente complejos de resolver una vez identificados. El problema real es no haberlos anticipado. Una migración bien ejecutada tiene una fase de análisis previa — inventario de plugins, verificación de compatibilidad de PHP, mapa de URLs, verificación de backup — que puede durar tanto como la migración en sí misma.
La diferencia entre un proceso de migración estructurado y uno improvisado no está en las herramientas — está en el checklist que se sigue antes de tocar nada. Según la propia arquitectura de WordPress, el sistema está diseñado para ser portable, pero esa portabilidad requiere entender cómo almacena los datos, no solo copiar archivos de un sitio a otro.
Si estás evaluando si delegar una migración compleja o si necesitas una segunda opinión sobre el proceso que tienes planificado, en la página de servicios puedes ver cómo trabajo este tipo de proyectos.
Mi opinión como desarrollador WordPress
Lo que más me sorprende después de haber gestionado decenas de migraciones WordPress es cuántos problemas siguen siendo los mismos de siempre — URLs sin actualizar, backups sin verificar, caché sin purgar. No son errores exóticos ni difíciles de prevenir. Son errores de proceso: pasos que se saltan porque «probablemente no hará falta» y que luego cuestan horas de diagnóstico. Cuando reviso una migración fallida, casi siempre encuentro que el problema no estuvo en la técnica sino en la ausencia de un protocolo claro antes del corte. La migración en sí dura horas; el análisis previo es lo que determina si esas horas terminan bien o no.
¿Necesitas ayuda con tu proyecto? Trabajo con negocios y agencias en WordPress, WooCommerce, IA e integraciones. Escríbeme y lo vemos juntos.
