Si has entrado recientemente en la sección de Salud del Sitio (Site Health) de tu panel de administración y te has encontrado con la advertencia crítica que reza: «Tu sitio está configurado para registrar errores en un archivo potencialmente público» (o en inglés, su versión original: «Your site is set to log errors to a potentially public file WordPress»), es natural que te preocupes. En mi experiencia como desarrollador Senior de WordPress, este es uno de los avisos más comunes pero mal entendidos que pueden aparecer tras una sesión de depuración o mantenimiento.
No se trata de un error del núcleo de WordPress que haya roto tu sitio, sino de una advertencia de seguridad vital relacionada con cómo tu servidor maneja los registros de errores (logs). Ignorar esto puede exponer rutas de archivos, nombres de usuario y detalles de tu base de datos a cualquier persona curiosa en internet.
En este artículo exhaustivo, desglosaremos exactamente por qué aparece este mensaje, la lógica técnica detrás de la decisión de los desarrolladores de WordPress, y las estrategias definitivas para solucionarlo y blindar tu instalación.
¿Qué significa exactamente esta advertencia en Salud del Sitio?
Desde la versión 5.2, WordPress introdujo la herramienta de Salud del Sitio para ayudar a los administradores a identificar problemas de configuración y seguridad. El mensaje «Tu sitio está configurado para registrar errores en un archivo potencialmente público» aparece específicamente cuando el sistema detecta que el modo de depuración está activo y configurado para escribir en un archivo estándar.
Para entender la gravedad, debemos mirar bajo el capó. Cuando desarrollamos o solucionamos problemas en PHP y WordPress, necesitamos ver qué está fallando. Para ello, utilizamos una constante en el archivo wp-config.php llamada WP_DEBUG_LOG.
El problema raíz: Al activar esta función sin configuraciones adicionales, WordPress genera un archivo llamado debug.log dentro de la carpeta /wp-content/. Como esta carpeta es pública (es donde están tus imágenes, temas y plugins), el archivo de texto plano generado es accesible desde el navegador.
Esto significa que si alguien visita tusitio.com/wp-content/debug.log, podría descargar el historial completo de errores de tu sitio. Dependiendo de tus plugins y errores, este archivo puede contener información sensible.
Origen de la advertencia por la configuración de WP_DEBUG_LOG
La advertencia no aparece aleatoriamente. Se activa específicamente cuando el valor WP_DEBUG_LOG ha sido añadido y activado (establecido en true) en el archivo de configuración del sitio. Esto indica al sistema que los errores, advertencias y avisos de PHP se están escribiendo activamente en un disco físico accesible.
Según la documentación y discusiones técnicas en el desarrollo del núcleo, esta verificación busca proteger a los usuarios que olvidan desactivar el modo de desarrollo antes de pasar a producción.
- Fuente técnica: Puedes leer más sobre la discusión original de los desarrolladores sobre esta implementación en el Ticket de desarrollo en WordPress Core Trac.
- Discusión de la comunidad: También existe un extenso debate sobre cómo afecta esto a la salud del sitio en StackExchange – Preguntas y respuestas de desarrollo.
La vulnerabilidad de acceso público predeterminado
El concepto clave aquí es que el archivo generado (debug.log) es considerado técnicamente un «archivo regular» (regular file). En términos de servidores web (como Apache o Nginx), a menos que se le diga explícitamente lo contrario, cualquier archivo regular dentro de la raíz pública del documento es servible al usuario final.
En mi experiencia auditando sitios para clientes, he encontrado archivos debug.log indexados por Google, lo que representa un riesgo de seguridad masivo. No se necesita ser un hacker avanzado; basta con conocer la estructura de carpetas predeterminada de WordPress.
La comunidad de usuarios ha debatido largamente sobre si este archivo debería ser accesible por defecto o no. La realidad es que, por diseño, WordPress prioriza la compatibilidad, y bloquear archivos por defecto podría causar problemas en ciertas configuraciones de servidor.
Para profundizar en la perspectiva de la comunidad sobre esta vulnerabilidad, recomiendo leer esta discusión en Reddit sobre la accesibilidad pública de debug.log.
Por qué WordPress no «arregla» esto automáticamente
Es posible que te preguntes: «Si WordPress sabe que esto es inseguro, ¿por qué no guarda el archivo en un lugar seguro automáticamente?». Esta es una excelente pregunta que toca las limitaciones técnicas de la arquitectura web.
Limitaciones técnicas en la verificación de rutas seguras
Aunque un usuario avanzado intente configurar la ruta de WP_DEBUG_LOG fuera de la carpeta pública (por ejemplo, un nivel por encima de public_html), WordPress no puede verificar con un 100% de certeza si esa ubicación es realmente segura mediante programación.
Esto se debe a la variabilidad de los entornos de hosting. Un sitio puede estar ejecutándose en un subdirectorio, o el servidor puede tener configuraciones de «alias» que hacen que carpetas superiores a ABSPATH sigan siendo accesibles públicamente a través de otra URL.
El veredicto de los desarrolladores: Debido a esta imposibilidad de garantizar la privacidad automática, el equipo de Core de WordPress decidió mantener la redacción de la advertencia y cerrar el ticket de mejora como «wontfix» (no se arreglará/cambiará).
La intencionalidad del mensaje «Potencialmente Público» es alertar al usuario de que el archivo podría ser accesible dependiendo de la configuración general del sistema, transfiriendo la responsabilidad de la seguridad al administrador del servidor, ya que no existe una forma concreta de comprobar la accesibilidad externa automáticamente sin realizar peticiones HTTP que podrían fallar o dar falsos positivos.
Para los más técnicos, los detalles de esta decisión de diseño se encuentran documentados en el Ticket #46689 del Trac de WordPress.
Solución paso a paso: Cómo eliminar el error y asegurar tu sitio
Ahora que entendemos el «por qué», pasemos a la acción. Si ves el error «Tu sitio está configurado para registrar errores en un archivo potencialmente público», tienes tres caminos principales para solucionarlo, ordenados de más recomendado a más avanzado.
Método 1: Desactivar la depuración (Recomendado para Sitios en Producción)
Si tu sitio está en vivo y recibiendo visitas reales, no deberías tener el log de depuración activado. El registro de errores consume recursos de disco (el archivo puede crecer hasta ocupar gigabytes) y expone la información mencionada.
La acción correctiva inmediata tras finalizar la depuración, recomendada por expertos, no es solo cambiar permisos, sino desactivar la función y eliminar el rastro.
- Accede a los archivos de tu sitio vía FTP o el Administrador de Archivos de tu hosting.
- Localiza el archivo
wp-config.phpen la raíz. - Busca las líneas relacionadas con el debug y cámbialas a
false.
// Desactiva el modo debug
define( 'WP_DEBUG', false );
// Desactiva el guardado en el archivo log
define( 'WP_DEBUG_LOG', false );
// Evita que los errores se muestren en pantalla
define( 'WP_DEBUG_DISPLAY', false );
Paso Crucial: Una vez hayas cambiado el código a false, debes eliminar físicamente el archivo debug.log de la carpeta /wp-content/. Si solo desactivas el código, el archivo viejo sigue existiendo y sigue siendo descargable. Esta es una recomendación clave extraída de la comunidad de expertos en seguridad.
Método 2: Cambiar la ubicación del archivo de registro
Si eres un desarrollador y necesitas mantener el registro activo en un entorno de producción (algo que desaconsejo, pero a veces es necesario temporalmente), puedes forzar a WordPress a guardar el archivo en una ruta no pública.
Para esto, en lugar de poner true en la constante, puedes definir una ruta específica:
// Define una ruta fuera del directorio público (public_html)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/usuario/logs_privados/mi_sitio_debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
Nota: Incluso haciendo esto, es probable que la advertencia en Salud del Sitio persista. Recuerda lo que mencionamos sobre las «Limitaciones técnicas». WordPress no puede verificar que /home/usuario/logs_privados/ sea seguro, por lo que te seguirá advirtiendo por precaución. Sin embargo, tú sabrás que el archivo está a salvo.
Método 3: Proteger el archivo mediante .htaccess (Para servidores Apache)
Si no puedes mover el archivo o prefieres una capa extra de seguridad, puedes usar el archivo .htaccess para prohibir el acceso a cualquier archivo con extensión .log.
Añade este bloque de código a tu archivo .htaccess:
<FilesMatch "\.log$">
Order Allow,Deny
Deny from all
</FilesMatch>
Esto devolverá un error «403 Forbidden» a cualquiera que intente acceder al archivo desde el navegador, pero permitirá que WordPress siga escribiendo en él.
Buenas Prácticas: Flujo de trabajo ideal de Marcos Arcusin
En mi día a día desarrollando soluciones con Vue.js y WordPress, sigo un protocolo estricto para evitar que la keyword «Your site is set to log errors to a potentially public file WordPress» sea siquiera una preocupación para mis clientes.
Aquí te comparto mi flujo de trabajo para asegurar ingresos y estabilidad:
1. Nunca depurar en producción
Utiliza siempre un entorno de Staging (entorno de pruebas). La mayoría de los hostings modernos ofrecen esta funcionalidad con un clic. Activa WP_DEBUG_LOG solo en el entorno de staging. Si el error es específico de producción y no se replica en staging, usa el método de protección por .htaccess y desactívalo tan pronto obtengas el dato que necesitas.
2. Rotación y limpieza de logs
Los archivos de log pueden crecer indefinidamente. Un archivo debug.log de 2GB puede tumbar tu sitio si te quedas sin espacio en disco. Acostúmbrate a revisar y eliminar el archivo periódicamente.
3. Uso de plugins de monitoreo
En lugar de depender de un archivo de texto plano, considera usar plugins como Query Monitor para depuración en tiempo real, o servicios externos como Sentry o New Relic para monitorear errores de PHP sin exponer archivos públicos.
Conclusión
La advertencia «Tu sitio está configurado para registrar errores en un archivo potencialmente público» es un recordatorio amigable pero firme de WordPress sobre la importancia de la seguridad de los datos. No es un error que debas temer, sino una configuración que debes gestionar.
Recuerda los puntos clave que hemos cubierto gracias a la investigación de fuentes oficiales:
- La advertencia proviene de tener
WP_DEBUG_LOGactivo. - El archivo
debug.loges públicamente accesible por defecto. - WordPress no puede «arreglarlo» solo porque no puede validar rutas de servidor con certeza.
- La solución real es desactivar el debug y borrar el archivo cuando termines de trabajar.
Mantener tu sitio limpio de advertencias en la Salud del Sitio no es solo vanidad; es una práctica fundamental para proteger tu negocio y el de tus clientes. Si sigues los pasos descritos anteriormente, no solo eliminarás el mensaje de error, sino que habrás elevado el nivel de seguridad de tu infraestructura WordPress.
¿Necesitas ayuda con esto?
Detectamos y solucionamos de raíz los problemas de rendimiento, errores y configuración de tu WordPress. Descubre nuestro servicio de auditoría técnica WordPress.
