Errores habituales al migrar WordPress y cómo resolverlos

Los errores tras migrar WordPress no tienen una solución única. Antes de repetir una restauración, identifica si falla la conexión a base de datos, PHP, las URLs, los archivos, DNS o un servicio externo. Conserva una copia del estado actual, sobre todo si ya entraron formularios o pedidos: restaurar una base antigua podría borrarlos.

Primero, confirma dónde ocurre el error

Comprueba si accedes al servidor nuevo o al anterior, si el fallo aparece en todo el sitio o solo en una ruta y desde cuándo ocurre. Anota código HTTP, mensajes de error y hora. Una web antigua visible en el dominio puede ser un problema de DNS o caché, no de WordPress; usa el diagnóstico específico. La lista de verificación posterior ayuda a reproducir el fallo.

Síntomas frecuentes y primera comprobación

Síntoma	Revisa primero	Acción prudente
«Error al establecer conexión con la base de datos»	Host, nombre, usuario, contraseña y permisos en wp-config.php; importación y servidor SQL	Corrige credenciales y verifica que las tablas esperadas están en destino; no publiques contraseñas
Pantalla blanca o error 500	Registro de PHP, versión/extensiones, plugin o tema incompatible, límites	Trabaja sobre copia o ventana controlada; usa diagnóstico seguro antes de desactivar componentes
Portada bien, páginas interiores 404	Enlaces permanentes y reglas web del servidor	Revisa reescrituras y guarda los enlaces permanentes tras hacer copia de reglas propias
Imágenes rotas o redirecciones al origen	Archivos de medios, URL guardadas, CDN y home/siteurl	Tras backup, usa una herramienta que respete datos serializados si cambió el dominio
HTTPS falla o hay contenido mixto	Certificado del dominio exacto, enlaces HTTP y proxy/CDN	Instala certificado válido y corrige referencias sin crear bucles
No llegan formularios o emails	SMTP, MX y autenticación DNS	Prueba envío/recepción; separa incidencia web de correo

La documentación de errores de WordPress relaciona pantalla blanca y errores de base de datos con causas distintas. Para cambios de dominio, WordPress advierte sobre reemplazos de texto que rompen datos serializados; no hagas un «buscar y sustituir» SQL indiscriminado.

Si la web está operativa a medias

Haz una copia del estado nuevo antes de tocar datos. En una tienda, no repitas una importación sobre pedidos recién creados: compara origen y destino por ID, fecha y estado y detén el checkout si existe riesgo de dos fuentes de escritura. Consulta el checklist de WooCommerce. Si solo algunos usuarios ven el sitio antiguo, revisa DNS, IPv6 y cachés antes de mover archivos.

Si consultas el error con una IA, prepara un extracto seguro

Una IA puede ordenar hipótesis después de una migración, pero no tiene acceso al estado real de tus servidores, DNS, correo o pedidos. No le envíes la copia de la web, un log completo ni un archivo de configuración. Conserva los originales en un lugar privado y prepara un resumen separado; la guía para revisar logs en Plesk explica cómo localizar la ventana del fallo.

1. Delimita un fallo reproducible. Anota qué ruta falla, código HTTP, hora con zona horaria, servidor de origen o destino y pasos realizados. Si hay varios síntomas, empieza por uno. Para una tienda, indica si se siguen recibiendo pedidos, sin copiar datos de compradores.
2. Selecciona solo la evidencia necesaria. Extrae las líneas de la misma ventana horaria que describen el error y comprueba que corresponden a la petición. Una línea aislada puede ser efecto de otro problema; si no hay correlación, indica que falta evidencia.
3. Retira identificadores y secretos. Sustituye dominios internos, nombres de usuario, rutas de cuentas, IP, correos y parámetros de URL si no son imprescindibles. Elimina contraseñas, claves API, cookies, cabeceras de autorización, cadenas de conexión y datos de clientes; no basta con tapar unos caracteres de una clave. Si no puedes revisar el extracto entero, no lo pegues.
4. Pide comprobaciones, no una reparación automática. Solicita que la IA separe hechos, hipótesis y datos faltantes, y que proponga pruebas reversibles. Contrasta cada sugerencia con los logs originales y la verificación de la migración antes de cambiar PHP, plugins, DNS o bases de datos.

Ejemplo ficticio: «Tras mover una web WordPress de servidor, /ejemplo/ devuelve HTTP 500 desde las 10:15 UTC; la portada devuelve 200. En un extracto revisado aparece “PHP Fatal error en plugin-ejemplo.php:42” a esa hora. No incluyo dominio real, IP, usuarios, credenciales ni pedidos. ¿Qué dos hipótesis son compatibles con estos datos, qué prueba permitiría distinguirlas y qué información falta? No propongas borrar archivos ni restaurar la base de datos». La referencia al plugin no demuestra por sí sola la causa: hay que confirmar que la traza corresponde a la petición y probar la corrección en un entorno controlado.

Si el error afecta a pagos o hay datos nuevos desde la copia, detén cualquier restauración automática y pide revisión humana. Un extracto saneado todavía puede revelar detalles de infraestructura; revisa las condiciones de tratamiento de datos de la herramienta antes de enviarlo. OWASP documenta el riesgo de divulgación de información sensible en sistemas de IA. Si una clave activa se compartió por error, revócala o rótala desde el servicio correspondiente y revisa accesos. La guía para abrir una incidencia indica qué evidencia mínima conviene comunicar por el canal de soporte adecuado.

Escalada con datos útiles

Envía a soporte URL afectada, código HTTP, hora, origen y destino, cambios realizados y fragmentos de log sin claves. Indica si hay pedidos o formularios posteriores a la copia. Si contemplas cambiar otra vez de plan, mide primero el problema: un error 500 por plugin no se arregla necesariamente con más servidor. Para una ayuda delimitada, consulta la incidencia; el alcance del soporte debe confirmarse.

Para seguir una ruta concreta según el síntoma, consulta el diagnóstico de HTTP 500 o el mensaje de conexión a base de datos antes de repetir la importación.