Arreglar errores de PHP en WordPress tras cambio de hosting

Los errores php wordpress después de un cambio de hosting suelen aparecer cuando el nuevo servidor no replica exactamente el entorno anterior: puede variar la versión de PHP, las extensiones activas, los límites de memoria, las rutas internas, la caché del servidor, los permisos o el comportamiento de algún plugin o theme.

La forma más segura de resolverlo es seguir un orden lógico: identificar el error real, revisar compatibilidades del entorno, aislar si el fallo viene del código o de un plugin/theme y, solo después, aplicar cambios concretos. Ese enfoque evita tocar archivos a ciegas, restaurar copias sin diagnóstico o “ocultar” el problema sin corregir su causa.

Tras una migración WordPress o un cambio de servidor, una web puede cargar en blanco, devolver un error 500, mostrar avisos de PHP o fallar solo en ciertas funciones como formularios, cron o correo transaccional. No siempre es un problema grave, pero sí conviene revisar el entorno con método para estabilizar la web cuanto antes.

Qué suele causar errores de PHP en WordPress tras cambiar de hosting

Cuando una web funcionaba en un proveedor y falla tras moverla a otro, no significa necesariamente que la migración se haya hecho mal. Con frecuencia, el problema aparece porque el entorno de hosting es distinto en aspectos que WordPress, los plugins o el theme sí notan.

• La versión de PHP del nuevo servidor puede ser más alta o más baja que la anterior.
• Pueden faltar extensiones de PHP que antes estaban activas, como módulos usados por imágenes, ZIP, multibyte o conexiones externas.
• El memory_limit, tiempos de ejecución u otras directivas pueden ser más restrictivos.
• Las rutas internas del servidor cambian y afectan a código personalizado, includes o configuraciones antiguas.
• Puede haber plugins incompatibles con esa versión de PHP o con la configuración del nuevo hosting.
• El theme activo o un child theme pueden contener funciones obsoletas, warnings convertidos en errores o dependencias no presentes.
• La caché del servidor, OPcache, caché de plugins o CDN puede estar sirviendo archivos desactualizados.
• Los permisos de archivos y carpetas pueden impedir lecturas, escrituras o generación de caché y logs.
• Servicios como WP-Cron o el correo saliente pueden comportarse de forma distinta según el servidor.

Por eso conviene evitar conclusiones rápidas del tipo “es culpa del hosting” o “hay que actualizar todo”. En muchos casos, el fallo está en una incompatibilidad concreta entre el sitio y el nuevo entorno.

Cómo identificar el error real antes de tocar plugins o archivos

Antes de desactivar cosas por intuición, el primer objetivo es saber qué error aparece exactamente y dónde. No es lo mismo un fatal error visible, una pantalla blanca, un error 500 en todo el sitio o un fallo que solo afecta al admin, al checkout o a un formulario.

1. Comprueba si el error es visible. Si ves un mensaje con archivo, línea o función, anótalo tal cual antes de hacer cambios.
2. Distingue entre frontal y administración. Puede fallar solo /wp-admin/, solo una plantilla o solo una acción concreta.
3. Valora si es un error 500 WordPress. Si el navegador solo devuelve “500 Internal Server Error”, necesitarás logs para ir más allá.
4. Repite la acción que rompe la web. Por ejemplo, guardar una página, abrir el personalizador, enviar un formulario o lanzar una tarea programada.
5. Anota el momento exacto. Ese dato ayuda a localizar la entrada correspondiente en los logs PHP del hosting.

Si no puedes entrar al panel, no hace falta empezar borrando plugins. Primero intenta acceder a los registros de errores del servidor desde el panel del hosting, SSH o el gestor de archivos, según lo que ofrezca el proveedor.

Revisar versión de PHP, límites del servidor y compatibilidades

En un cambio de hosting WordPress, este bloque suele ser decisivo. Si la web venía de un entorno antiguo y el nuevo usa una versión de PHP más moderna, pueden aparecer funciones obsoletas, código no compatible o plugins que no se han adaptado.

1. Confirmar la versión de PHP activa

Revisa en el panel del hosting qué versión de PHP está asignada al dominio. Si tienes acceso al escritorio de WordPress, también puedes verlo en Salud del sitio. Lo importante es verificar la versión real del nuevo entorno, no asumir que coincide con la anterior.

Si el error empezó tras pasar, por ejemplo, de PHP 7.4 a 8.1 o 8.2, conviene comprobar la compatibilidad del theme, plugins y código personalizado. A veces la solución temporal razonable es probar una versión de PHP intermedia compatible, siempre que el hosting lo permita y sin perder de vista la actualización posterior del sitio.

2. Revisar extensiones de PHP

No basta con que la versión sea válida. Algunos errores aparecen porque faltan extensiones que antes estaban activas. Según la web y los plugins instalados, conviene revisar si el servidor tiene disponibles los módulos necesarios para imágenes, compresión, cadenas multibyte, XML, base de datos o conexiones seguras.

3. Validar límites del servidor

Si la web importa datos, usa constructores visuales, WooCommerce, copias de seguridad o plugins pesados, el problema puede deberse a límites insuficientes. Revisa especialmente estos puntos:

• memory_limit: si es bajo, pueden aparecer errores fatales o peticiones interrumpidas.
• max_execution_time: puede afectar a importaciones, regeneraciones o procesos largos.
• upload_max_filesize y post_max_size: relevantes si fallan subidas de imágenes en WordPress o actualizaciones manuales.

Estos valores pueden depender del plan de hosting, del gestor de PHP o de reglas específicas del proveedor. Si no puedes modificarlos desde tu panel, conviene consultarlo con soporte técnico.

4. Revisar permisos y rutas si el error lo sugiere

Si el log menciona “failed to open stream”, “permission denied” o rutas inexistentes, revisa permisos, propietario de archivos y referencias a carpetas absolutas heredadas del servidor anterior. Esto es especialmente frecuente en código personalizado, scripts de caché, integraciones externas y algunos sistemas de backup.

Qué hacer si el fallo viene de un plugin, theme o código personalizado

Una vez localizado el componente implicado, el objetivo no es “desactivar por desactivar”, sino aislar el conflicto con el menor impacto posible.

Si puedes entrar al administrador

1. Desactiva primero el plugin señalado por el log o el último plugin afectado por la migración.
2. Si no está claro, desactiva los plugins por bloques pequeños para detectar cuál reproduce el error y solucionar conflictos entre plugins en WordPress.
3. Comprueba si el problema desaparece al cambiar temporalmente a un tema por defecto de WordPress.
4. Revisa snippets, funciones en functions.php o mu-plugins si existen personalizaciones fuera del panel.

Si no tienes acceso al administrador

Puedes actuar desde el gestor de archivos o por FTP/SFTP. La forma más prudente suele ser renombrar temporalmente la carpeta de un plugin sospechoso para forzar su desactivación. Si no sabes cuál es, renombrar la carpeta global de plugins puede servir como prueba, aunque conviene hacerlo sabiendo que afectará a varias funciones del sitio.

Para el theme, puedes cambiar temporalmente al tema por defecto si el entorno lo permite, o renombrar la carpeta del tema activo para que WordPress intente cargar otro disponible. Esto solo es recomendable si sabes qué tema alternativo existe y si el sitio no depende críticamente de maquetación o funciones específicas del tema anterior.

Errores frecuentes en código personalizado tras migrar

• Uso de funciones incompatibles con la versión PHP WordPress del nuevo servidor.
• Rutas absolutas antiguas que apuntan al servidor previo.
• Llamadas a librerías no disponibles o dependencias del sistema no instaladas.
• Warnings o notices que en ciertos entornos terminan afectando a cabeceras, sesiones o respuestas AJAX.
• Integraciones con correo o APIs que dependen de IP, DNS, autenticación o certificados del nuevo host.

Si el problema está en un plugin comercial o un desarrollo a medida, conviene valorar si compensa aplicar un parche puntual o si es mejor actualizar, sustituir o refactorizar esa parte para que la web quede estable a medio plazo.

Cómo usar logs y debug de WordPress sin empeorar la incidencia

El debug WordPress ayuda mucho, pero conviene usarlo con prudencia, sobre todo en producción. La idea no es mostrar errores a los visitantes, sino registrar información útil para diagnosticar.

En el archivo wp-config.php, pueden utilizarse estas constantes:

• WP_DEBUG: activa el modo de depuración de WordPress.
• WP_DEBUG_LOG: guarda los errores en un archivo de log, normalmente wp-content/debug.log.
• WP_DEBUG_DISPLAY: controla si los errores se muestran en pantalla.

En una web en producción, suele ser más prudente activar el registro y evitar la visualización pública de los mensajes. Así puedes revisar el error sin exponer rutas, archivos o detalles técnicos a usuarios y buscadores.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Después de activarlo, reproduce la acción que falla y revisa debug.log. Si no aparece nada, el error puede estar ocurriendo antes de que WordPress llegue a registrarlo, o puede estar yendo a los logs PHP del servidor en lugar del log interno.

Según el hosting, también puede ser útil revisar:

• error_log del dominio o de la cuenta
• logs de PHP-FPM o FastCGI
• logs de Apache o Nginx
• registros del panel de control del proveedor

Cuando termines el diagnóstico, conviene desactivar o ajustar el debug para no dejar registros innecesarios creciendo en producción.

Si necesitas una referencia oficial, la documentación de depuración de WordPress explica el uso de estas constantes y su finalidad: Debugging in WordPress.

Checklist final para estabilizar la web tras la migración

Cuando el error principal ya está resuelto, todavía queda una parte importante: validar que la web funciona de forma estable en el nuevo servidor. Esta comprobación evita que reaparezcan incidencias a las pocas horas o días.

1. Confirma que la web carga bien en frontal y en administración.
2. Limpia todas las cachés: plugin de caché, caché del servidor, CDN y navegador.
3. Verifica que el theme activo y los plugins críticos siguen funcionando con la PHP actual.
4. Prueba formularios, checkout, buscador, login, registro y cualquier proceso clave del negocio.
5. Comprueba el correo transaccional: formularios, avisos de pedido, restablecimiento de contraseña o notificaciones internas.
6. Revisa si WP-Cron ejecuta tareas programadas con normalidad, sobre todo si hay suscripciones, reservas o automatizaciones.
7. Observa los logs durante unas horas o días para detectar errores residuales, warnings repetidos o consumos anómalos.
8. Si has bajado o cambiado la versión de PHP como medida temporal, deja planificada la corrección definitiva del componente incompatible.

Cuándo conviene pedir soporte WordPress o mantenimiento profesional

Hay incidencias que un administrador con nivel técnico medio puede resolver bien siguiendo un proceso ordenado. Pero en otros casos, pedir soporte WordPress ahorra tiempo, reduce riesgo y evita tocar producción más de la cuenta.

• Si no puedes acceder ni al admin ni a una pista clara en los logs.
• Si el fallo afecta a ventas, captación o procesos críticos del negocio.
• Si el error viene de código personalizado o de varias incompatibilidades a la vez.
• Si hay que coordinar ajustes entre WordPress, hosting, DNS, correo y caché.
• Si la web “vuelve a caer” después de una corrección aparente.

Un enfoque profesional no consiste solo en reparar WordPress para que cargue otra vez, sino en dejar identificado qué causó la incidencia, qué cambio se ha hecho y qué medidas conviene tomar para que no se repita en la siguiente actualización, migración o cambio de servidor.

Si tu web sigue mostrando errores, devuelve un error 500 WordPress o ha quedado inestable tras la migración, el siguiente paso razonable es revisar el entorno con diagnóstico real y corregir la incompatibilidad concreta. Y si prefieres no hacerlo en producción sin apoyo, contar con un servicio de reparación urgente de WordPress caído o mantenimiento WordPress puede ser la forma más segura de recuperar estabilidad sin improvisar.

Preguntas frecuentes