Cómo Crear y Acceder a los Registros de Errores de WordPress (3 Métodos)

Los registros de errores de WordPress son registros de diagnóstico que capturan errores PHP, excepciones fatales, fallos de base de datos, conflictos de plugins e incompatibilidades de temas a medida que ocurren en su servidor. Acceder e interpretar estos registros es la forma más rápida de identificar la causa raíz de una página rota, una pantalla blanca de la muerte o una regresión de rendimiento silenciosa, sin necesidad de adivinar ni desactivar plugins uno por uno.

Esta guía cubre tres métodos probados en producción para habilitar, localizar y leer los registros de errores de WordPress: la pila nativa WP_DEBUG, los registros a nivel de servidor a través del panel de control de su alojamiento, y los visores de registros basados en plugins. Cada método se adapta a un nivel de acceso y caso de uso diferente, y los tres se explican con rutas de archivo exactas, sintaxis de configuración y consideraciones de seguridad.

Por qué son importantes los registros de errores de WordPress

WordPress funciona sobre PHP, que genera varias clases de mensajes en tiempo de ejecución: errores fatales (la ejecución se detiene), advertencias (la ejecución continúa pero algo está mal), avisos (informativos, que a menudo indican código obsoleto) y mensajes deprecated (funciones programadas para su eliminación). De forma predeterminada, ninguno de estos se escribe en un registro persistente en la mayoría de las configuraciones de producción: se suprimen o se muestran en el navegador, lo que supone un riesgo de seguridad.

Sin un registro, una actualización de plugin que introduce un error fatal produce solo una pantalla en blanco. Una biblioteca SMTP mal configurada descarta correos electrónicos silenciosamente. Un límite de memoria excedido interrumpe la carga de una página sin dejar rastro visible. Los registros de errores convierten estos fallos invisibles en entradas con marca de tiempo, referencia de archivo y número de línea sobre las que puede actuar de inmediato.

Método 1: Habilitar el modo de depuración de WordPress mediante wp-config.php

WordPress incluye un subsistema de depuración integrado controlado por un conjunto de constantes PHP definidas en wp-config.php. Este es el método más preciso porque captura errores específicos de WordPress, incluidos los generados por la API de plugins, el cargador de temas y la capa de abstracción de base de datos (wpdb).

Paso 1: Localizar y abrir wp-config.php

Conéctese a su servidor mediante SFTP (preferible sobre FTP simple por seguridad) usando un cliente como FileZilla o Cyberduck, o abra el Administrador de archivos de su proveedor de alojamiento. Navegue hasta el directorio raíz de WordPress, normalmente /public_html/ o /var/www/html/. El archivo wp-config.php se encuentra en la raíz de este directorio.

Si tiene acceso SSH, puede editarlo directamente:

nano /var/www/html/wp-config.php

Paso 2: Configurar las constantes de depuración

Localice la línea existente:

define( 'WP_DEBUG', false );

Reemplace el bloque completo con la siguiente configuración, que habilita el registro sin exponer errores a los visitantes del sitio:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Qué hace cada constante:

• WP_DEBUG — activa el motor de depuración de WordPress y habilita el reporte de errores PHP al nivel E_ALL.
• WP_DEBUG_LOG — escribe todos los errores capturados en un archivo de registro en lugar de (o además de) la pantalla.
• WP_DEBUG_DISPLAY — cuando se establece en false, suprime la salida en pantalla. Esto es fundamental en sitios en producción; sin ello, los avisos PHP filtran rutas de archivos internas y nombres de variables a los visitantes.
• display_errors — la directiva PHP subyacente; establecerla en 0 mediante ini_set proporciona una segunda capa de supresión en caso de que un plugin o tema anule WP_DEBUG_DISPLAY.

Paso 3: Localizar el archivo de registro de depuración

Con WP_DEBUG_LOG establecido en true, WordPress escribe los errores en:

/wp-content/debug.log

Este archivo se crea automáticamente con el primer error registrado. Puede verlo mediante SFTP o SSH:

tail -f /var/www/html/wp-content/debug.log

El indicador tail -f transmite nuevas entradas en tiempo real, lo cual es muy valioso cuando se reproduce un error específico de forma interactiva.

Paso 4: Usar una ruta de registro personalizada (recomendado por seguridad)

La ruta predeterminada debug.log es accesible públicamente si su servidor web no la bloquea explícitamente. Un servidor mal configurado servirá https://yourdomain.com/wp-content/debug.log a cualquier visitante, exponiendo rutas internas, prefijos de tablas de base de datos y nombres de clases.

Opción A — Mover el archivo de registro fuera de la raíz web:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Cree el directorio de destino y establezca los permisos:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Opción B — Bloquear la ruta predeterminada mediante .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Opción C — Equivalente en Nginx en su bloque de servidor:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Paso 5: Deshabilitar el modo de depuración tras la resolución del problema

Nunca deje WP_DEBUG establecido en true en un sitio activo más tiempo del necesario. Una vez resuelto el problema:

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

Dejar el modo de depuración activo en un sitio en producción degrada el rendimiento (PHP procesa cada aviso E_ALL) y puede exponer trazas de pila sensibles si WP_DEBUG_DISPLAY se establece accidentalmente en true.

Método 2: Acceder a los registros de errores a nivel de servidor mediante el panel de control de alojamiento

Los errores de WordPress que ocurren antes de que se complete el arranque de WordPress, como un wp-config.php corrupto, una incompatibilidad de versión PHP o una conexión de base de datos fallida, nunca aparecerán en debug.log porque WordPress en sí nunca llega a cargarse. Para estos casos, necesita el registro de errores PHP del servidor o el registro de errores de Apache/Nginx.

Alojamiento basado en cPanel

Si su entorno de alojamiento utiliza VPS con cPanel, el registro de errores es accesible a través de la interfaz del panel de control:

1. Inicie sesión en cPanel.
2. Navegue a Métricas > Errores.
3. El panel muestra las últimas 300 líneas del registro de errores de Apache para su cuenta.

Para el archivo de registro completo, use el Administrador de archivos de cPanel o conéctese mediante SFTP y navegue a:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Los nombres exactos de los archivos varían según la configuración del servidor, pero el patrón es consistente en la mayoría de las instalaciones de cPanel.

Alojamiento basado en Plesk

En Plesk, navegue a Sitios web y dominios > seleccione su dominio > Registros. Puede filtrar por tipo de registro (acceso, error, PHP) y descargar el archivo de registro completo.

Acceso directo al servidor (VPS o dedicado)

En un entorno de Alojamiento VPS o Servidor Dedicado donde tiene acceso root, las ubicaciones de los registros dependen de su stack:

Para monitorear el registro PHP-FPM en tiempo real:

tail -f /var/log/php8.2-fpm.log

Para buscar errores fatales específicos de WordPress en el registro de Apache:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Configurar el registro de errores PHP a nivel de servidor

Si los errores PHP no se están escribiendo en un registro, verifique su configuración de php.ini:

php --ini | grep "Loaded Configuration"

Abra el archivo php.ini identificado y verifique o establezca:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Reinicie PHP-FPM tras los cambios:

systemctl restart php8.2-fpm

Alternativamente, anule la configuración PHP por sitio usando un archivo .htaccess (solo Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Método 3: Usar un plugin de registro de errores de WordPress

Para entornos donde el acceso directo al servidor está restringido, como el Alojamiento Web Compartido, o para equipos donde administradores no técnicos necesitan revisar errores sin acceso SSH, un plugin de WordPress ofrece una alternativa viable.

Plugins recomendados

• WP Log Viewer — lee el archivo debug.log existente y lo muestra en el administrador de WordPress con filtrado y búsqueda.
• Error Log Monitor — añade un widget al panel de control que muestra los errores recientes y puede enviar alertas por correo electrónico cuando se registran nuevos errores.
• Query Monitor — va más allá del registro de errores para perfilar consultas de base de datos, llamadas a la API HTTP, hooks y etiquetas condicionales. Esencial para la depuración de rendimiento.
• Health Check & Troubleshooting — el plugin oficial de WordPress.org; habilita un modo de resolución de problemas que activa un tema predeterminado y deshabilita todos los plugins solo para su sesión, sin afectar a otros visitantes.

Instalar y configurar Error Log Monitor

1. En el administrador de WordPress, vaya a Plugins > Añadir nuevo.
2. Busque Error Log Monitor y haga clic en Instalar ahora, luego en Activar.
3. Navegue a Ajustes > Error Log Monitor.
4. Establezca la ruta del archivo de registro. Si ha movido debug.log fuera de la raíz web, introduzca aquí la ruta absoluta del servidor.
5. Configure la frecuencia de alertas por correo electrónico si desea notificaciones para nuevos tipos de errores.

El plugin lee el mismo archivo debug.log en el que escribe WP_DEBUG_LOG. No crea un mecanismo de registro separado: es un visor. Esto significa que WP_DEBUG y WP_DEBUG_LOG deben seguir estando habilitados en wp-config.php para que el plugin muestre algo.

Limitación crítica: Los plugins se cargan después de que WordPress arranca. Cualquier error que impida que WordPress se cargue (fallo de conexión a la base de datos, archivo principal corrupto, versión PHP incompatible) no será visible en ningún visor de registros basado en plugins. Para esos escenarios, el Método 2 es la única opción.

Comparación: Tres métodos de registro de errores de WordPress

Lectura e interpretación de las entradas del registro de errores de WordPress

Una entrada sin procesar de debug.log tiene este aspecto:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Cómo leer esto:

• La marca de tiempo está en UTC: conviértala a la zona horaria local de su servidor si es necesario.
• PHP Fatal error significa que la ejecución se detuvo. La página que desencadenó esto devolvió un error 500 o una pantalla en blanco.
• Call to undefined function get_field() significa que el plugin Advanced Custom Fields está desactivado o se carga después de que el functions.php del tema intentó llamarlo.
• La traza de pila muestra el archivo exacto y el número de línea. Comience la depuración en la línea 47 de functions.php.

Patrones de error comunes y sus causas:

• PHP Warning: require(): Failed opening required — una ruta de archivo es incorrecta o falta un archivo. A menudo causado por un plugin que hace referencia a un archivo que fue eliminado.
• PHP Deprecated: Function _register_controls is deprecated — un plugin o tema usa una API obsoleta. No es fatal, pero indica un plugin que no ha sido actualizado para la versión actual de WordPress/Elementor.
• WordPress database error ... for query — una consulta wpdb falló. Compruebe si hay discrepancias en el prefijo de tabla o tablas corruptas.
• Maximum execution time of 30 seconds exceeded — un script tardó demasiado. Común con importaciones grandes, consultas no optimizadas o llamadas a API externas que agotan el tiempo de espera.
• Allowed memory size of X bytes exhausted — PHP alcanzó el límite de memoria. Aumente memory_limit en php.ini o identifique el plugin que consume memoria en exceso.

Mejores prácticas para gestionar los registros de errores de WordPress

Rote los registros para evitar el agotamiento del disco. Un sitio WordPress activo bajo ataque o con un error recurrente puede generar cientos de megabytes de datos de registro por día. En servidores Linux, configure logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Nunca confirme debug.log en el control de versiones. Añádalo a .gitignore:

wp-content/debug.log

Audite su wp-config.php después de cada migración de servidor. Las migraciones de alojamiento frecuentemente restablecen WP_DEBUG a false o introducen una nueva plantilla wp-config.php que sobreescribe sus constantes.

Use SAVEQUERIES para la depuración a nivel de base de datos. Añada esta constante junto a WP_DEBUG para registrar cada consulta SQL que ejecuta WordPress:

define( 'SAVEQUERIES', true );

Luego inspeccione $wpdb->queries en una plantilla personalizada o mediante Query Monitor. Desactívelo inmediatamente después de su uso: almacena cada consulta en memoria y aumenta significativamente el consumo de RAM.

Correlacione las marcas de tiempo del registro con los eventos de despliegue. Si aparece un nuevo tipo de error, compruebe si coincide con una actualización de plugin, una actualización del núcleo de WordPress o un cambio de versión PHP en el servidor. La mayoría de los paneles de control de alojamiento registran los cambios de versión PHP en un registro de auditoría separado.

Matriz de decisión: qué método usar

Lista de verificación técnica de puntos clave

• Establezca WP_DEBUG_DISPLAY en false antes de habilitar WP_DEBUG_LOG en cualquier sitio con tráfico activo.
• Mueva debug.log fuera de la raíz web o bloquéelo mediante reglas del servidor: la ruta predeterminada es accesible públicamente.
• Use tail -f en el archivo de registro cuando reproduzca errores de forma interactiva; elimina la necesidad de actualizar el archivo manualmente.
• Los registros PHP y Apache/Nginx a nivel de servidor son la única fuente de verdad para los errores que ocurren antes de que WordPress se cargue.
• Los visores de registros basados en plugins requieren que WP_DEBUG_LOG esté activo: son lectores, no escritores.
• Implemente la rotación de registros en cualquier servidor donde WP_DEBUG_LOG esté habilitado durante más de unas pocas horas.
• Nunca deje SAVEQUERIES habilitado en producción; es una carga para la memoria y el rendimiento.
• Tras resolver un problema, establezca todas las constantes de depuración de nuevo en false y verifique con una solicitud del navegador que no aparecen avisos PHP en el código fuente de la página.

—

Preguntas frecuentes

¿Dónde se encuentra el archivo de registro de depuración de WordPress de forma predeterminada?

WordPress escribe el registro de depuración en /wp-content/debug.log relativo al directorio raíz de WordPress. Esta ruta solo se crea después de que se registra el primer error y únicamente cuando tanto WP_DEBUG como WP_DEBUG_LOG están establecidos en true en wp-config.php. Puede anular la ruta pasando una cadena de ruta de archivo absoluta como valor de WP_DEBUG_LOG en lugar de true.

¿Es seguro habilitar WP_DEBUG en un sitio en producción activo?

Es seguro solo si WP_DEBUG_DISPLAY está explícitamente establecido en false y display_errors está establecido en 0. Sin estas dos configuraciones, los errores PHP, incluidas las rutas de archivos internas y los nombres de tablas de base de datos, se renderizan directamente en el código fuente HTML de cada página. Siempre combine WP_DEBUG true con WP_DEBUG_DISPLAY false en cualquier sitio con tráfico público.

¿Por qué mi archivo debug.log está vacío aunque WP_DEBUG está habilitado?

Las causas más comunes son: el proceso del servidor web no tiene permiso de escritura en el directorio /wp-content/; WP_DEBUG_LOG está establecido en false o no está presente en wp-config.php; o el error está ocurriendo a nivel de servidor antes de que WordPress se cargue, lo que significa que aparecerá en el registro de Apache o PHP-FPM en lugar de en debug.log. Compruebe los permisos del directorio con ls -la wp-content/ y verifique que las constantes estén definidas en el orden correcto en wp-config.php.

¿Cuál es la diferencia entre WP_DEBUG_LOG y el registro de errores PHP del servidor?

WP_DEBUG_LOG es una constante a nivel de WordPress que enruta los errores capturados por el manejador de errores personalizado de WordPress hacia debug.log. El registro de errores PHP del servidor (configurado mediante error_log en php.ini) captura todos los errores PHP a nivel del intérprete, incluidos los que ocurren antes de que WordPress se inicialice. En un servidor correctamente configurado, ambos registros están activos simultáneamente y se complementan entre sí.

¿Puedo habilitar el registro de errores en alojamiento compartido sin acceso SSH?

Sí. Puede editar wp-config.php a través del Administrador de archivos de su proveedor de alojamiento en cPanel o Plesk, habilitar WP_DEBUG y WP_DEBUG_LOG, y luego leer debug.log a través de la misma interfaz del Administrador de archivos. Para los registros a nivel de servidor en Alojamiento Web Compartido, use la sección Errores en Métricas de cPanel. Si necesita un control más detallado sobre la configuración PHP y las rutas de registro, actualizar a un plan de Alojamiento VPS le proporciona acceso directo a php.ini y acceso SSH completo a todos los archivos de registro.