Dónde está el debug.log de WordPress y cómo moverlo de sitio

WordPress escribe su registro de depuración en wp-content/debug.log por defecto, lo que en disco equivale a una ruta absoluta del tipo /ruta/a/tu/web/wp-content/debug.log. El archivo no existe hasta que se registra algo, y solo llega a escribirse cuando WP_DEBUG está en true y WP_DEBUG_LOG está activado en wp-config.php. Esa ubicación por defecto es además un problema de seguridad real, porque en la mayoría de los alojamientos cualquiera puede descargarla desde el navegador.

Las tres constantes y qué hace cada una

Las tres van en wp-config.php, por encima de la línea que dice /* That's all, stop editing! Happy blogging. */. Todo lo que añadas por debajo de esa línea se ejecuta cuando WordPress ya ha arrancado y se ignora.

Constante	Valor por defecto	Qué hace
WP_DEBUG	false	Interruptor principal. Sube el nivel de informe de errores de PHP para mostrar avisos, advertencias y funciones obsoletas. Nada más de esta lista funciona sin ella.
WP_DEBUG_LOG	false	Envía los errores a un archivo. true significa wp-content/debug.log. Si le pasas una cadena, se interpreta como la ruta del archivo donde escribir.
WP_DEBUG_DISPLAY	true	Imprime los errores dentro del HTML de la página, visibles para todos los visitantes.

La dependencia es lo que la gente entiende mal. WP_DEBUG_LOG se lee dentro de la rama WP_DEBUG del código de arranque de WordPress. Si WP_DEBUG está en false, poner WP_DEBUG_LOG en true no hace absolutamente nada: ni archivo, ni error, ni aviso. Si añadiste WP_DEBUG_LOG y no apareció ningún registro, revisa primero WP_DEBUG.

Una configuración que funciona en una web en producción:

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

Si WP_DEBUG ya está definida más arriba en el archivo, y suele estarlo con el valor false, edita esa línea existente en lugar de añadir un segundo define(). Definir la misma constante dos veces lanza un aviso de PHP que, en una web con la visualización activada, aterriza justo en la parte de arriba de tu página.

Por qué WP_DEBUG_DISPLAY debe estar en false en producción

Con la visualización activada, los errores de PHP se imprimen dentro de la respuesta HTML. Un simple aviso de obsolescencia de un tema muestra la ruta absoluta de tu servidor a cualquier visitante. Un error de base de datos muestra nombres de tablas y fragmentos de consultas. Peor aún: la salida que aparece antes de que se envíen las cabeceras rompe las redirecciones, rompe las respuestas de REST y AJAX que esperan JSON limpio y puede producir la pantalla en blanco que después la gente le achaca a un plugin.

Un matiz que conviene conocer: poner WP_DEBUG_DISPLAY en null no es lo mismo que ponerlo en false. null le dice a WordPress que no toque el ajuste display_errors de PHP y herede lo que tenga configurado el servidor. false lo fuerza activamente a desactivado. En una web en producción usa false y añade además la línea de ini_set de arriba como refuerzo, porque un plugin puede volver a activar display_errors más adelante en la misma petición.

La ubicación por defecto es descargable públicamente

wp-content/debug.log está dentro de la raíz web. Nada en una instalación estándar de WordPress bloquea las peticiones directas a ese archivo. En una configuración típica de Apache o nginx, https://tuweb.com/wp-content/debug.log devuelve el archivo como texto plano. Los registros de depuración contienen rutas absolutas del servidor, tripas de plugins y temas, errores de base de datos con el texto real de las consultas y a veces valores que pasaron por funciones que fallaron. Eso es reconocimiento gratis para cualquiera que adivine la URL, y es una de las primeras URLs que prueban los escáneres automáticos.

Hay dos formas de resolverlo. La mejor es mover el registro.

Mover el registro indicando una ruta

Desde WordPress 5.1, WP_DEBUG_LOG acepta una cadena con la ruta del archivo en lugar de un booleano. Apúntala a algún sitio fuera del directorio público:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Tres reglas para esa ruta. Usa una ruta absoluta: una relativa se resuelve contra el directorio de trabajo de PHP, que cambia según la petición y el servidor, así que acabarás sin saber dónde fue a parar el archivo. El directorio debe existir ya; PHP no lo crea, y si no puede abrir el archivo falla en silencio. Y el directorio debe tener permisos de escritura para el usuario de PHP, que en alojamiento compartido no es la misma cuenta con la que entras por SFTP.

Si tu hosting te confina a la raíz web y no hay ningún sitio por encima donde escribir, deja la ruta por defecto y bloquea el acceso a nivel de servidor. En Apache:

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

Eso va en un archivo .htaccess dentro de wp-content, no en el de la raíz: WordPress reescribe el .htaccess raíz cuando guardas los enlaces permanentes y puede borrar tu añadido. En nginx, .htaccess no hace nada en absoluto; necesitas un bloque location en la configuración del servidor, lo que en alojamiento gestionado suele significar pedírselo al soporte.

Sé sincero sobre lo que consigues bloqueándolo: el archivo sigue en disco, en un directorio que el servidor web sirve. Un fallo de recorrido de rutas en cualquier plugin todavía puede leerlo. Sacarlo de la raíz web es la solución más sólida.

Leer el archivo y seguirlo en directo

Por SSH, míralo en vivo mientras reproduces el fallo:

tail -f wp-content/debug.log

Reproduce el error en otra pestaña y las líneas nuevas irán apareciendo según se escriben. Para ver solo lo que ha pasado hace poco, o para filtrar por un plugin concreto:

tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50

PHP añade al final del archivo, así que léelo de abajo hacia arriba. Cada entrada lleva marca de tiempo en UTC, que no coincidirá con la zona horaria configurada en WordPress; que eso no te haga pensar que estás mirando entradas viejas.

Con WP-CLI puedes cambiar las constantes sin editar el archivo a mano:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

El parámetro --raw importa: sin él, el valor se escribe como la cadena "true" en vez de como booleano. Para la variante con ruta, quita --raw para que se escriba como cadena entrecomillada.

¿Sin SSH? Descarga el archivo por SFTP o ábrelo con el administrador de archivos de tu hosting. Evita los plugins que muestran el registro dentro de wp-admin salvo que confíes plenamente en ellos: le estás dando a un plugin acceso de lectura a un archivo lleno de tripas del servidor.

Si quieres el bloque exacto de wp-config para tu caso, con una ruta segura fuera de la raíz y la regla de servidor correspondiente, el generador de registro de depuración para WordPress te lo construye.

Desactívalo cuando termines

Nada en el núcleo de WordPress rota ni vacía debug.log. En una web que lanza un aviso en cada carga de página, el archivo crece sin límite y puede llenar el disco, lo que tumba la web con más fuerza que el propio fallo que estabas persiguiendo. Activa el registro, reproduce el problema, lee el registro y vuelve a poner WP_DEBUG en false.

Para vaciar el archivo sin borrarlo:

: > wp-content/debug.log

Cuando el registro se queda vacío

Repasa esto en orden. WP_DEBUG está en false: la causa más común con diferencia, y desactiva todo lo demás en silencio. La constante está por debajo de la línea de “stop editing” en wp-config.php. Permisos de archivo: PHP no puede escribir en wp-content, o en el directorio personalizado que indicaste. Un error fatal antes de que wp-config termine de cargarse, como un error de sintaxis en el propio archivo de configuración, ocurre demasiado pronto para que el registro de WordPress lo capture; esos van al registro de errores PHP del propio servidor. Tu hosting lo sobrescribe: algunas plataformas gestionadas fijan el ajuste error_log de PHP o desvían el registro a su propio panel, en cuyo caso tus constantes están bien puestas y la salida simplemente está en otro sitio. Revisa el visor de registros de tu hosting antes de dar por hecho que tu configuración está mal.