Logs de errores PHP en WordPress: guía de configuración

Cuando un WordPress se rompe —pantalla blanca, un error 500, un plugin que deja de responder o un tema medio roto— los logs de errores PHP son, con diferencia, lo más útil que puedes tener a mano. Sin registro activo, depurar es tirar dardos a ciegas. En esta guía verás cómo activar y configurar esos logs correctamente, tanto desde wp-config.php como a nivel de servidor, y qué hacer después con lo que encuentres en ellos.

Por qué necesitas los logs de errores PHP en WordPress

WordPress funciona sobre PHP, y casi todos los problemas graves —el temido error 500, la pantalla blanca de la muerte, los bucles de redirección— nacen de un error PHP que se queda en silencio. Muchos hostings, por seguridad, tienen la visualización de errores desactivada. Resultado: los fallos ocurren y no dejan rastro visible. Nada.

Con los logs bien configurados puedes:

• Saber exactamente qué archivo y qué línea provocan el fallo.
• Detectar incompatibilidades entre plugins y temas antes de que afecten a los usuarios.
• Registrar errores intermitentes que solo aparecen en momentos concretos (crons, WooCommerce, formularios).
• Recortar el tiempo de resolución de incidencias de forma considerable.

Hay algo más. Desde PHP 5.4, y sobre todo desde WordPress 5.2 con la protección Site Health y su recovery mode, el propio WordPress se apoya en estos registros para identificar extensiones problemáticas. La diferencia, al final, es reparar un sitio en minutos o pasarse horas a ciegas.

Cómo activar WP_DEBUG y WP_DEBUG_LOG en wp-config.php

El método nativo de WordPress se apoya en tres constantes que editas en el archivo wp-config.php, en la raíz de la instalación. Busca esta línea:

define( ‘WP_DEBUG’, false );

y cámbiala por este bloque:

Cada constante hace una cosa distinta:

• WP_DEBUG: activa el modo depuración de WordPress.
• WP_DEBUG_LOG: guarda todos los errores en el archivo /wp-content/debug.log.
• WP_DEBUG_DISPLAY: evita que los errores se muestren en pantalla. Imprescindible en producción, no lo olvides.

Guarda los cambios, visita la página que falla para forzar el registro, y después descarga el log vía FTP o con el gestor de archivos del hosting. Un aviso importante: cuando acabes, desactiva WP_DEBUG. El archivo debug.log es accesible públicamente si el servidor no lo bloquea, y no quieres eso. Puedes protegerlo con esta regla en el .htaccess de /wp-content/:

<Files debug.log>
Require all denied
</Files>

Con esto tendrás un registro completo —y seguro— de todos los avisos y errores que genere WordPress.

Configurar el log de errores PHP desde php.ini o .htaccess

A veces el problema está antes de que WordPress llegue a cargarse, o es un error fatal de PHP puro. Para esos casos hay que bajar un nivel y configurar los logs en el servidor. Si tu hosting permite un php.ini personalizado (algo habitual en VPS y hostings con cPanel), añade:

Si solo tienes acceso a .htaccess (Apache con mod_php), puedes usar:

• php_flag log_errors on
• php_value error_log /home/usuario/php-error.log
• php_value error_reporting E_ALL

Ojo con los servidores PHP-FPM (los más comunes hoy): ahí las directivas van en el archivo .user.ini del directorio o en el pool de FPM, porque .htaccess no aplica. Verifica siempre con un archivo que contenga <?php phpinfo(); que los valores se han aplicado, y comprueba que el log tiene permisos de escritura (644 o 664 suele bastar).

Si tu hosting no permite ninguna de estas opciones, o simplemente prefieres que lo revise alguien con experiencia, en RedServicio (redservicio.net) podemos configurar y revisar tus logs de errores PHP para que localices el problema de tu web sin perder tiempo.

Dónde encontrar y cómo leer los logs de errores PHP

¿Dónde está el log? Depende de lo que hayas configurado. Si definiste la directiva error_log en wp-config.php o en php.ini, el archivo estará justo en la ruta que indicaste (por ejemplo /home/usuario/logs/php-error.log). Si no definiste ninguna, lo habitual es que se escriba en la raíz del proyecto o en el directorio que el hosting designa por defecto.

Estas son las ubicaciones habituales donde buscar:

• Ruta personalizada: la que hayas indicado en error_log dentro de wp-config.php, php.ini o .user.ini.
• error_log en la raíz: muchos hostings compartidos generan un archivo llamado error_log en public_html, y a veces uno en cada carpeta con código PHP.
• logs del servidor: en VPS o servidores dedicados revisa /var/log/apache2/error.log o /var/log/nginx/error.log, y /var/log/php-fpm/ si trabajas con PHP-FPM.
• cPanel: busca la sección «Métricas» > «Errores», o localiza el log a mano desde el administrador de archivos.
• WP_DEBUG_LOG: si activaste esta constante, el archivo será /wp-content/debug.log.

¿Y para leerlo? Si tienes acceso por SSH, tail -f /ruta/del/log te muestra las entradas en tiempo real mientras reproduces el error. tail -n 100, en cambio, te devuelve las últimas cien líneas. En hosting compartido sin SSH no te complicues: descarga el archivo por FTP o SFTP y ábrelo con cualquier editor de texto.

Cada entrada sigue un patrón parecido a este:

Conviene desglosarlo. La fecha y hora te dice cuándo ocurrió; el nivel (Fatal error, Warning, Notice) marca la gravedad; el mensaje describe el problema; y la ruta final, con número de línea, señala el archivo exacto responsable. Ese último dato es oro. Te dice qué plugin o tema debes revisar, sin rodeos.

Errores más comunes en los logs de WordPress y cómo interpretarlos

Al revisar logs de errores PHP en WordPress te encontrarás con patrones que se repiten una y otra vez. Los más frecuentes, y lo que significan:

• PHP Fatal error: Allowed memory size exhausted: un script consumió toda la memoria disponible. Solución: sube el límite con define(‘WP_MEMORY_LIMIT’, ‘256M’); en wp-config.php o ajusta memory_limit en php.ini.
• Call to undefined function: alguien invoca una función que no existe. Casi siempre se debe a un archivo del plugin o tema que falta, o a versiones incompatibles tras una actualización.
• Failed opening required … (include_path): falta un archivo que otro intenta cargar. Suele apuntar a una instalación incompleta o dañada; reinstala el plugin o tema afectado.
• Maximum execution time exceeded: el script tardó demasiado. Ajusta max_execution_time a 120 o más, o identifica procesos pesados como importaciones o backups.
• Headers already sent by: se envió salida antes de las cabeceras, normalmente por espacios o caracteres sueltos antes de la etiqueta de apertura de PHP en algún archivo.
• Warning: Undefined variable / index: aviso menor que delata código descuidado. No rompe la web, pero conviene corregirlo antes de que traiga sorpresas.

Una regla práctica: prioriza siempre los Fatal error, porque detienen la ejecución y suelen estar detrás de la pantalla blanca o del error 500. Los Warning y Notice van en segundo plano. Eso sí, si se repiten en el mismo archivo, pueden estar anticipando un fallo más serio. No los ignores por siempre.

Conclusión: depura WordPress con logs bien configurados

De todas las herramientas de diagnóstico que tienes en WordPress, los logs de errores PHP son la más rentable: gratis, precisas y disponibles en cualquier hosting. Con WP_DEBUG activado en desarrollo, un log personalizado en producción y la costumbre de leer bien cada entrada, dejas de adivinar qué falla y pasas a saberlo en minutos. Qué archivo, qué línea, qué tipo de problema.

No olvides lo básico: desactiva la visualización de errores en producción, revisa el log tras cada actualización de plugins o temas, y jamás dejes un debug.log accesible públicamente sin protegerlo. Tampoco está de más un mantenimiento periódico del registro, porque los logs acumulados durante meses acaban dificultando el análisis.

Si tu web presenta errores que no logras interpretar o tu hosting complica la configuración, en RedServicio (redservicio.net) contamos con especialistas que revisan tus logs de errores PHP, identifican la causa raíz y aplican la corrección de forma segura. Escríbenos y recuperamos tu web cuanto antes.