Arreglar errores de PHP en WordPress tras cambio de hosting

Contexto de los errores de PHP tras migrar WordPress

Cuando una instalación de WordPress cambia de hosting, el código de la web no siempre llega a un entorno equivalente al anterior. Aunque la migración se complete y el dominio resuelva bien, el nuevo servidor puede usar otra versión de PHP, otra configuración de extensiones, distinto valor de memory_limit, reglas de caché de servidor o un modelo diferente de permisos. Ese cambio de contexto es una causa muy frecuente de errores fatales, avisos deprecados y comportamientos inestables.

En WordPress, estos fallos suelen aparecer en puntos sensibles: carga del tema, plugins con código antiguo, funciones personalizadas en functions.php, tareas programadas, integraciones de WooCommerce, llamadas AJAX y envíos de formularios. En un ámbito general, y también en España, la casuística varía según el proveedor, el panel de control y si la migración la hizo usted, el hosting o una herramienta automática.

• La misma web puede funcionar en un servidor y fallar en otro por diferencias de versión de PHP o módulos cargados.
• Los errores de PHP pueden mostrarse como pantalla blanca, error 500, mensajes visibles o fallos solo en el administrador.
• Un plugin aparentemente estable puede romperse si dependía de una función obsoleta o de una librería no presente en el nuevo entorno.
• La caché del servidor o una CDN pueden ocultar el error real y hacer pensar que el problema es intermitente.
• El riesgo principal no es solo la caída, sino perder trazabilidad al tocar demasiadas cosas sin registrar el orden.

Diagnóstico inicial y señales útiles

El primer paso es identificar qué tipo de error aparece y en qué momento. No es lo mismo un mensaje como “There has been a critical error on this website” que un aviso de función obsoleta, un error 500 en el frontal, una administración inaccesible o picos de CPU detectados por el hosting. También importa si el fallo empezó justo después del cambio de hosting, tras actualizar plugins o al cambiar la versión de PHP desde el panel.

En esta fase conviene hacer comprobaciones prudentes. Evite reinstalar media web, borrar plugins a ciegas o editar archivos de producción sin copia previa. Lo razonable es activar depuración controlada, revisar logs del servidor y del sitio, comprobar versión de PHP y comparar con los requisitos del tema y de los plugins críticos. Si hay tráfico real o tienda online, priorice medidas de contención que reduzcan impacto sin destruir evidencia técnica.

• Revise mensajes concretos como error 500, pantalla blanca, “critical error”, “Parse error”, “Fatal error”, “Allowed memory size exhausted” o avisos de funciones deprecadas.
• Compruebe si hubo cambios recientes: migración manual, restauración de copia, actualización automática, cambio de versión PHP o modificación de .htaccess y wp-config.php.
• Consulte avisos del hosting sobre consumo de CPU, procesos PHP, límites superados, malware detectado o incompatibilidades del entorno.
• Verifique si Search Console, monitorización externa o formularios están mostrando síntomas secundarios como caídas, URLs con 500 o errores de rastreo.
• Antes de desactivar elementos, haga una copia de archivos y base de datos y conserve capturas, horas exactas y URLs afectadas.

Causas habituales y cómo confirmarlas

La causa más repetida es la incompatibilidad entre la versión de PHP del nuevo hosting y el código existente. Un plugin antiguo puede romper al pasar a una versión de PHP más moderna. También ocurre lo contrario: el nuevo hosting puede mantener una versión demasiado antigua para la versión actual de WordPress, del tema o de extensiones recientes. A esto se suman límites de memoria, extensiones PHP no habilitadas, rutas incorrectas y archivos incompletos tras la migración.

Confirmar la causa exige pruebas concretas. Compare la versión de PHP anterior y la actual, revise el log de errores, identifique el archivo que falla y localice el componente responsable. Si el error apunta a un plugin, no basta con suponerlo. Conviene comprobar versión instalada, fecha de última actualización, cambios recientes y compatibilidad declarada. Si el fallo señala funciones del tema hijo o snippets personalizados, el foco pasa a su código y no al core de WordPress.

• Versión de PHP incompatible con plugins, tema o código personalizado, especialmente tras saltos grandes de versión.
• Extensiones de PHP ausentes o configuradas de forma distinta, como mbstring, curl, intl, imagick o zip.
• Límites insuficientes de memoria, tiempo de ejecución o procesos concurrentes, que generan errores fatales o respuestas truncadas.
• Archivos migrados de forma incompleta, permisos incorrectos o rutas antiguas que siguen referenciando el servidor previo.
• Configuraciones heredadas en .htaccess, caché o reglas del servidor que no encajan con el nuevo entorno.

Seguridad, malware y spam cuando aparece un error de PHP

No todo error de PHP es un problema de seguridad, pero tampoco conviene descartarlo sin revisar. Algunas webs muestran errores tras una migración porque ya arrastraban archivos alterados, usuarios no reconocidos, código inyectado en plugins o tema, o reglas maliciosas en archivos de configuración. El cambio de hosting puede hacer visible lo que antes pasaba desapercibido, por ejemplo porque el nuevo proveedor registra mejor los errores o bloquea ejecuciones sospechosas.

Los síntomas más útiles son redirecciones extrañas, creación de archivos PHP no esperados, spam saliente, cambios en el contenido, avisos del proveedor o errores que afectan solo a determinadas rutas. El enfoque correcto es prudente: copia previa, revisión de usuarios, rotación de contraseñas, análisis del origen del archivo afectado y hardening básico. En España, como en cualquier otro ámbito general, el detalle de la respuesta cambia según el hosting y los accesos disponibles.

• Revise si el error de PHP coincide con usuarios administradores desconocidos, tareas programadas anómalas o archivos recientes no identificados.
• Considere vectores habituales como plugins vulnerables, credenciales filtradas, permisos excesivos o inyecciones en archivos del tema.
• Haga copia de estado actual antes de limpiar, para no perder evidencia sobre la causa y el alcance de la incidencia.
• Rote contraseñas de WordPress, base de datos, SFTP, panel de hosting y correo si existen indicios razonables de acceso no autorizado.
• Aplique medidas básicas de hardening, actualización controlada y revisión de integridad antes de reabrir servicios sensibles.

Rendimiento y estabilidad tras el cambio de entorno

Un error de PHP no siempre produce una caída completa. En muchos casos se traduce en lentitud, respuestas parciales o fallos intermitentes bajo carga. Tras un cambio de hosting, el sitio puede pasar a tener otros límites de CPU, RAM, procesos PHP o políticas de caché. Si además el código genera avisos repetidos o bucles, el impacto sobre el rendimiento se multiplica y la incidencia se percibe como una web inestable.

Por eso conviene separar dos preguntas. La primera es qué rompe el código. La segunda es qué hace el servidor cuando ese código falla. Un sitio puede seguir cargando parcialmente mientras consume recursos de forma anormal. Revisar logs, tiempos de respuesta y puntos de carga crítica ayuda a corregir la causa y no solo el síntoma. Esto es especialmente importante si la web tiene formularios, WooCommerce o integraciones con APIs externas.

• Compruebe si los errores coinciden con picos de CPU, procesos PHP saturados o límites de memoria agotados.
• Revise si la caché de servidor, la caché de página o un sistema CDN están sirviendo contenido antiguo o errores enmascarados.
• Valore si las tareas programadas de WordPress, el envío de correo o las llamadas AJAX están generando bloqueos repetitivos.
• Analice el impacto de plugins pesados, constructor visual, búsquedas complejas o consultas lentas a base de datos.
• Tras corregir el error, haga pruebas de estabilidad con navegación real, acceso al administrador y acciones críticas del negocio.

Plugins, temas y actualizaciones en un entorno nuevo

La mayor parte de los errores de PHP en WordPress tras un cambio de hosting termina señalando a un plugin, al tema activo o a código personalizado. Por eso conviene revisar compatibilidades declaradas, historial de actualizaciones y dependencias. No basta con desactivar elementos sin orden. Lo adecuado es trabajar con staging cuando sea posible, reproducir el fallo, aislar el componente y documentar el resultado de cada prueba.

Si el error comenzó después de actualizar, la pregunta clave es si el conflicto procede del código actualizado o de su interacción con el nuevo hosting. Un plugin puede ser compatible con WordPress, pero no con una librería del servidor, con una extensión PHP ausente o con un cambio del tema. El control de cambios ayuda a decidir si conviene actualizar, revertir, reemplazar o corregir código propio.

• Use un entorno de staging para probar cambios de versión de PHP, actualizaciones y desactivación selectiva sin afectar la web pública.
• Compruebe compatibilidades entre WordPress, tema, plugins críticos y versión de PHP antes de aplicar cambios en producción.
• Si sospecha de un conflicto, aísle el componente de forma ordenada y anote qué cambia en cada paso.
• Revise snippets en functions.php, mu-plugins y personalizaciones de terceros que suelen quedar fuera de auditorías básicas.
• Después de corregir, deje documentado el cambio, su motivo y la versión válida para evitar repetir la incidencia.

Hosting, dominio y correo en España

En proveedores habituales de España, las diferencias entre planes y paneles de control influyen mucho en este tipo de incidencias. No todos ofrecen el mismo selector de versión PHP, la misma visibilidad de logs, la misma caché de servidor ni los mismos límites de procesos. También es frecuente que, tras la migración, haya ajustes pendientes en DNS, certificados SSL, redirecciones, rutas del sistema y servicios de correo que no dependen solo de WordPress.

Un error de PHP puede coincidir con otros síntomas derivados del cambio de proveedor: dominios que resuelven a un entorno antiguo, mezcla de contenido con y sin SSL, correo transaccional que deja de salir o cachés que siguen entregando respuestas anteriores. En España, y en ámbito general, esto varía según la infraestructura concreta, el uso de CDN, el registrador del dominio y si el envío de correo depende del propio hosting o de un servicio externo.

• Verifique DNS, propagación, registros relacionados y certificado SSL para asegurarse de que está probando contra el servidor correcto.
• Confirme la versión de PHP activa, módulos disponibles, memory_limit, max_execution_time y límites de procesos del plan contratado.
• Revise cachés de servidor, OPcache, compresión y reglas propias del proveedor que puedan enmascarar errores o servir respuestas antiguas.
• Compruebe permisos de archivos, propietario correcto y rutas del sistema tras la migración, especialmente en instalaciones movidas manualmente.
• Si hay formularios o WooCommerce, valide el correo transaccional y la autenticación saliente, ya que un cambio de hosting puede afectar al envío.

Pruebas, accesos y documentación técnica

La calidad del diagnóstico depende en gran medida de la información disponible. En incidencias de PHP tras migración, disponer de acceso al panel de hosting, a los logs y a una copia verificable ahorra tiempo y evita cambios innecesarios. También ayuda saber quién hizo la migración, cuándo se cambió el DNS, qué versión de PHP había antes y si se usó una herramienta automática o un traslado manual de archivos y base de datos.

La documentación técnica no es burocracia. Es la base para trazar el origen del fallo, justificar una corrección y poder revertir si algo sale mal. Si trabaja con soporte externo, esta información permite acotar responsabilidades y reducir tiempos de parada. Cuanto más precisa sea la evidencia, menos intervenciones destructivas serán necesarias.

• Trazabilidad de cambios recientes: registro de actualizaciones, lista de plugins y temas, versión de PHP anterior y actual, y changelog de acciones realizadas.
• Evidencias técnicas: logs de PHP y del servidor, capturas del error, horas exactas, URLs afectadas y pasos para reproducir el fallo.
• Copia de seguridad completa y verificable de archivos y base de datos, o al menos export de base de datos antes de intervenir.
• Accesos necesarios: WordPress, panel de hosting, SFTP o SSH si existe, gestión DNS y servicio de correo si interviene en la incidencia.
• Informes de seguridad o monitorización, junto con listado de avisos del hosting sobre recursos, malware, bloqueos o procesos anómalos.

Plan de acción ordenado

Ante errores de PHP después de cambiar de hosting, el orden importa tanto como la corrección. La prioridad es contener el impacto, conservar una copia del estado actual y reunir evidencia mínima antes de modificar nada. Después, se identifica el componente afectado, se valida la compatibilidad del entorno y se corrige en el punto más concreto posible. Solo al final tiene sentido optimizar o limpiar elementos accesorios.

Este enfoque reduce el riesgo de agravar la caída, perder datos o encadenar soluciones temporales. También permite explicar qué se hizo, por qué y con qué resultado. En proyectos con captación, reservas o comercio electrónico, esa trazabilidad resulta clave para coordinar soporte técnico, negocio y proveedor de hosting sin bloquear procesos esenciales durante más tiempo del necesario.

• Contención inicial: confirme alcance, active modo mantenimiento si es necesario y evite cambios simultáneos por varias personas.
• Copia previa: guarde archivos, base de datos y estado del entorno antes de tocar plugins, tema, PHP o reglas del servidor.
• Diagnóstico: lea logs, identifique archivo y línea afectada, compare versión de PHP y determine el componente responsable.
• Corrección: aplique el cambio mínimo razonable, ya sea ajustar PHP, corregir código, sustituir un plugin o restaurar un archivo íntegro.
• Verificación y monitorización: pruebe frontal, administración, formularios, correo y funciones críticas, y mantenga seguimiento tras la intervención.

Si ya se ha tocado algo o hay urgencia

Es muy frecuente llegar a una incidencia cuando ya se han probado varias soluciones. Quizá se instaló un plugin de seguridad, se restauró una copia parcial, se cambió de hosting de forma acelerada, se editó functions.php, se borró un plugin crítico o se intentó limpiar malware sin copia. En ese escenario, el objetivo inicial no es hacer más cambios, sino reconstruir la secuencia de acciones y conservar la evidencia que aún quede disponible.

Si la web está caída, actúe con criterio de mínima intervención. No mezcle varias restauraciones, no sobreescriba logs si todavía pueden consultarse y no asuma que el último cambio es el único culpable. A veces el intento de arreglo elimina la pista principal o introduce un segundo problema. Una revisión técnica ordenada puede diferenciar entre daño original, daño colateral y configuración aún pendiente del nuevo entorno.

• Si se instaló un plugin de seguridad, compruebe si cambió reglas, bloqueó archivos o alteró el acceso sin resolver el error base.
• Si se restauró una copia parcial, valide coherencia entre archivos y base de datos, ya que una mezcla de fechas distintas genera nuevos fallos.
• Si se tocó functions.php o código personalizado, compare con la versión previa y revierta solo con copia y registro del cambio.
• Si se borró un plugin crítico, revise dependencias rotas, shortcodes, tablas propias y configuraciones que hayan quedado huérfanas.
• Si se intentó limpiar malware sin copia, detenga nuevas modificaciones y preserve logs, archivos afectados y cronología de acciones.

Preguntas frecuentes

Estas dudas son habituales cuando WordPress empieza a fallar con errores de PHP tras una migración. La respuesta correcta depende siempre del entorno y de la evidencia disponible.

P: ¿Cambiar la versión de PHP suele arreglar el problema?

R: A veces sí, pero no debería hacerse a ciegas. Puede servir para confirmar una incompatibilidad, aunque la solución estable suele pasar por revisar el componente que falla y no solo por ajustar la versión del servidor.

P: ¿Es seguro desactivar todos los plugins para probar?

R: Solo si se hace con copia previa y entendiendo el impacto. En sitios con comercio electrónico, membresía o formularios, desactivar en bloque puede alterar pedidos, sesiones o integraciones activas.

P: ¿Un error 500 siempre significa problema de PHP?

R: No siempre. Puede estar relacionado con PHP, pero también con reglas del servidor, permisos, límites de recursos, .htaccess, caché o configuraciones del proveedor.

P: ¿Debo restaurar una copia de seguridad inmediatamente?

R: Depende del contexto. Si necesita recuperar servicio con urgencia puede ser una opción, pero conviene valorar si la copia es íntegra, reciente y compatible con el nuevo hosting para no introducir otra incidencia.

P: ¿Qué información debería preparar antes de pedir ayuda técnica?

R: Accesos, logs, capturas, URLs afectadas, hora de inicio, cambios recientes, versión de PHP, copia disponible y detalle de la migración. Con esa base, el diagnóstico suele ser más rápido y menos invasivo.