Un visor PHP te permite consultar avisos y errores puntuales de WordPress sin modificar código, una opción razonable para una web pequeña o con soporte técnico disponible. El problema aparece cuando los fallos se repiten, afectan a compras, formularios o velocidad, y nadie los detecta hasta que un usuario avisa.
Un plugin de informe simple basta para ver errores puntuales de WordPress sin tocar código; el logging avanzado sirve cuando necesitas alertas, búsqueda y contexto para resolver incidencias repetidas. No elijas por funciones: compara el riesgo de tu web, el volumen de errores, el tráfico, quién puede revisarlos y la sensibilidad de los datos antes de activar registros.
Decide por riesgo, no por funciones
La elección depende de lo que perderías si un fallo pasa desapercibido durante varias horas.
Un error PHP es un aviso que genera el lenguaje con el que funciona buena parte de WordPress. Piensa en él como el testigo de avería de un coche: a veces avisa de algo menor y otras indica que el motor se ha parado. Un Fatal error puede dejar una página en blanco; un Notice suele ser un aviso técnico que no impide navegar.
Un visor lee mensajes puntuales
Un visor simple muestra las últimas líneas de un PHP error_log o del archivo debug.log . Sirve para responder preguntas concretas: qué plugin falló, a qué hora ocurrió y en qué archivo aparece el mensaje. Es una linterna útil cuando ya sabes que hay una habitación a oscuras.
Este enfoque encaja si tienes una web corporativa pequeña, un blog o una página de servicios que recibe pocas consultas. Revisar el registro tras una actualización o cuando aparece el aviso de error crítico suele ser suficiente en esos casos.
El logging convierte mensajes en casos
El logging avanzado recoge errores con datos que ayudan a investigarlos: URL afectada, versión del plugin, gravedad, usuario implicado y cambios cercanos. También puede agrupar cientos de mensajes iguales en una sola incidencia y avisar por correo o Slack cuando aparece un fallo grave.
Un archivo error_log es como una libreta donde se anota todo por orden de hora. Un sistema avanzado se parece más a una centralita: identifica avisos repetidos, los separa por gravedad y procura que llegue el aviso correcto a la persona adecuada.
Una web no necesita logging avanzado por tener muchos plugins. Lo necesita cuando el tiempo entre el fallo y su detección puede causar pérdida de ventas, reservas, contactos o confianza.
El error más frecuente es elegir una herramienta por su lista de funciones y no por quién revisará los avisos. Si nadie atiende alertas, un sistema avanzado acaba siendo un buzón lleno de ruido. Con este criterio claro, toca ver el caso más habitual para quien empieza.
✉
¿Quieres más información? Escríbenos y te orientamos
Empieza simple
Para una web pequeña, menos registro suele significar menos problemas de gestión.
Un visor sencillo es una buena primera capa si los errores aparecen de forma ocasional y tienes acceso privado al panel de hosting. Muchos alojamientos usados por negocios de Valencia, como los que ofrecen cPanel o Plesk, permiten consultar el registro PHP sin instalar otro plugin. Esto evita añadir una pieza más a WordPress para una necesidad que puede surgir solo entre una y tres veces al año.
Un informe básico suele bastar si tu web no cobra pagos, no guarda datos delicados y recibe menos de unas 500 visitas al día. También encaja si una persona puede revisar el log en menos de 24 horas después de una actualización o de un aviso recibido por correo.
Un caso habitual es una clínica local con una web informativa y un formulario de contacto. Tras actualizar un constructor visual, una página muestra un Warning ; el gestor consulta el log, identifica el complemento y el soporte corrige el conflicto sin necesitar alertas permanentes.
Configura la depuración sin mostrarla
WP_DEBUG activa el modo de depuración de WordPress. WP_DEBUG_LOG guarda los mensajes en un archivo, normalmente /wp-content/debug.log, mientras que WP_DEBUG_DISPLAY decide si el visitante ve esos mensajes en pantalla.
En una web pública, la pantalla debe seguir limpia. Si necesitas registrar fallos durante una prueba, deja desactivada la visualización con define('WP_DEBUG_DISPLAY', false); y revisa después el archivo desde un lugar privado. WordPress explica estas constantes en su documentación oficial de depuración .
Lo que la práctica demuestra en estos casos es que activar WP_DEBUG de forma continua rara vez aporta valor a una página estable. Puede llenar el archivo con avisos antiguos de compatibilidad y ocultar el mensaje que sí importa. El visor simple funciona, pero deja de ser suficiente cuando el fallo afecta directamente a ingresos.
Para activar un registro de errores WordPress durante una prueba controlada, configura WP_DEBUG y WP_DEBUG_LOG como true, y mantén WP_DEBUG_DISPLAY como false para que el visitante no vea avisos técnicos. Así, el modo depuración WordPress escribirá normalmente en wp-content/debug.log; si ese archivo no contiene nada, revisa el PHP error_log desde el panel del hosting, porque PHP puede registrar los fallos en una ruta distinta.
Un visor de errores PHP ayuda a leer ambos archivos, pero no debe sustituir el acceso privado ni exponer el registro por URL. Al terminar la investigación, desactiva la depuración temporal y conserva solo las líneas necesarias para documentar la incidencia.
Vigila activamente
Una tienda no puede depender de que alguien entre a mirar un archivo.
Cuando WooCommerce procesa pedidos, una academia vende cursos o una web acepta citas, cada error crítico puede cortar un proceso que genera ingresos. Si el pago falla a las 22:00 y nadie lo detecta hasta la mañana siguiente, el coste real no es el mensaje PHP: son las compras abandonadas que quizá no regresen.
Matriz para elegir sin pagar de más
Esta matriz sirve para elegir un nivel de control razonable. Las cifras son orientativas: el dato decisivo es cuánto daño causa una hora de fallo en tu caso.
Tipo de web Tráfico orientativo Impacto de una caída Soporte disponible Nivel aconsejado Blog o página local Hasta 500 visitas/día Bajo Revisión en 24-72 h Visor simple y log privado Web corporativa con formularios 500-5.000 visitas/día Medio Revisión semanal Visor protegido y revisión programada Tienda o reservas Más de 1.000 visitas/día Alto Respuesta en pocas horas Alertas para errores críticos Membresía o varios sitios Variable Alto o muy alto Equipo técnico Centralización y trazabilidad
Alertas que merecen una respuesta
Una alerta útil no dice que existe cualquier aviso. Debe avisar solo ante un Fatal error , un fallo de pago, un aumento anormal de errores o una URL clave que deja de responder. El umbral de severidad es la regla que marca cuándo un evento merece interrumpir a alguien.
La deduplicación evita recibir 200 correos por el mismo fallo. La agrupación reúne errores con la misma causa para investigarlos una sola vez. Ambas opciones ahorran tiempo cuando un complemento defectuoso genera el mismo mensaje en cada visita.
🛒
Producto recomendado
Un libro práctico sobre depuración de WordPress puede ayudarte a interpretar un log antes de enviar una captura completa al soporte. Resulta más útil para aprender a aislar la causa que para sustituir alertas o copias de seguridad.
Ayuda a distinguir un aviso Deprecated de un Fatal error que bloquea una compra
Facilita preparar datos seguros para soporte, como hora, URL y plugin afectado
Reduce cambios a ciegas en wp-config.php durante una incidencia
Ver en Amazon →
Para una tienda , academia o agenda de reservas, conviene combinar alertas de errores críticos con revisión humana de los grupos de incidencias. La excepción es un proyecto nuevo sin usuarios ni operaciones: durante la fase de pruebas, un log temporal y privado puede ser suficiente. El siguiente paso es evitar que esa vigilancia se convierta en cientos de avisos inútiles.
✉
¿Quieres más información? Escríbenos y te orientamos
Evita el ruido que oculta el fallo real
Más registros no garantizan una detección mejor.
El logging avanzado tiene un coste operativo, es decir, tiempo, espacio y atención. Puede almacenar miles de líneas al día si un plugin genera un Deprecated en cada carga. En un hosting compartido español, conservar ese volumen entre 30 y 90 días puede ocupar espacio que necesitas para copias o hacer más lenta la búsqueda manual.
Los errores que un visor no detecta
Un visor simple puede mostrar un mensaje aislado, pero no siempre permite relacionarlo con una página, una versión concreta o el momento exacto de un pago fallido. Tampoco avisa si la persona encargada no revisa el archivo hasta varios días después.
Los fallos silenciosos son especialmente molestos. Por ejemplo, un formulario puede cargar sin error visible pero no enviar el correo por un conflicto con una extensión SMTP; el log avanzado, bien configurado, puede guardar el contexto de la petición y señalar que el problema se repite desde una actualización.
No confundas guardar con resolver
Borrar error_log o debug.log libera espacio, pero no arregla la causa que lo llenó. Antes de limpiarlo, guarda de forma privada las líneas relevantes, apunta la hora, la URL, la acción que causó el fallo y los cambios recientes.
El error más común que cometen los gestores es desactivar varios plugins a la vez sin anotar el resultado. Así se pierde la pista del origen y se puede romper otra función. Haz una copia de seguridad, prueba primero en un entorno de pruebas y cambia un elemento cada vez.
Un registro útil debe responder cuatro preguntas: qué falló, cuándo falló, dónde ocurrió y qué cambió alrededor de ese momento.
La recomendación extendida de activar todo el logging posible es incompleta para sitios pequeños. Sin filtros, un aviso repetido tapa los incidentes importantes y obliga a invertir tiempo en leer mensajes que no requieren acción. La seguridad del contenido registrado es el otro límite que debe guiar tu elección.
Lee cada error empezando por el tipo, el archivo y la hora. Un Fatal error justo después de actualizar suele apuntar al plugin o tema indicado en la ruta; un Warning PHP repetido al subir una imagen puede relacionarse con permisos, límites de memoria o una biblioteca de procesamiento; y mensajes como “Error establishing a database connection” requieren revisar credenciales, disponibilidad del servidor y estado de la base de datos antes de desactivar extensiones.
Si el fallo ocurre en un formulario, reproduce la acción en un entorno de pruebas, anota URL, usuario de prueba y versión del complemento, y cambia un único elemento cada vez. Esta monitorización de incidencias evita confundir una coincidencia temporal con la causa real.
Protege tus logs y escala con orden
Un log puede revelar más de lo que parece.
Las líneas de un registro pueden incluir correos, direcciones IP, rutas internas del servidor, URL con parámetros, tokens y contenido enviado en formularios. Bajo el Reglamento General de Protección de Datos (RGPD) y la LOPDGDD, conviene aplicar el principio de minimización: guardar solo lo necesario y durante el tiempo necesario para investigar una incidencia.
Oculta datos antes de compartir
Antes de enviar una captura a soporte, tapa correos, IP, claves API, cookies, tokens, nombres de usuario y rutas completas del servidor. También elimina parámetros de URL que puedan contener datos de formulario o identificadores de pedido.
No publiques nunca una captura completa en un foro ni dejes debug.log accesible desde una dirección web. Los logs del servidor de Apache HTTP Server o Nginx también requieren acceso restringido. Los WordPress Coding Standards recomiendan evitar que el código registre secretos o información privada sin necesidad.
Escala en cuatro niveles
El camino seguro no exige pasar de cero a una plataforma compleja. Empieza con un visor privado, luego fija una rutina de revisión y añade alertas solo cuando el impacto de un fallo lo justifique.
Nivel 1: consulta el log privado del hosting después de actualizaciones o avisos críticos.Nivel 2: activa un visor protegido y conserva registros entre 7 y 14 días si los errores son ocasionales.Nivel 3: configura alertas solo para errores críticos y pagos fallidos, con una retención de entre 14 y 30 días.Nivel 4: centraliza logs de varios sitios, etiqueta cada proyecto y asigna responsables cuando existe soporte técnico.No es prioritario instalar ningún plugin de errores si la web funciona correctamente, no genera ingresos ni trata datos sensibles y el hosting ya ofrece registros privados fáciles de consultar. El logging avanzado tampoco sustituye copias de seguridad, actualizaciones controladas, contraseñas seguras ni medidas básicas de seguridad de WordPress.
Para la mayoría de principiantes, el plan razonable es empezar con revisión privada y escalar solo tras un fallo repetido, una tienda activa o una necesidad real de respuesta rápida. Esta decisión protege el presupuesto y reduce riesgos sin dejar la web a ciegas.
Preguntas frecuentes
Un informe simple te conviene si los fallos son ocasionales y puedes revisar un log privado en 24 horas. Es suficiente para blogs y webs informativas sin pagos. Escala si los errores se repiten o afectan a formularios, ventas o reservas.
¿Dónde veo los errores PHP de WordPress?
Los errores PHP suelen aparecer en /wp-content/debug.log o en el panel privado de tu hosting. La ubicación depende de si WordPress registra con WP_DEBUG_LOG o si PHP usa el log del servidor. No abras el archivo mediante una URL pública.
¿Cuál es la diferencia entre WP_DEBUG y WP_DEBUG_LOG?
WP_DEBUG activa la depuración y WP_DEBUG_LOG guarda los mensajes en un archivo. Puedes usar el segundo para investigar sin mostrar nada al visitante. Mantén WP_DEBUG_DISPLAY en false en producción.
¿Un error deprecated puede romper mi web?
Un error Deprecated normalmente no rompe la web hoy, pero avisa de código que podría fallar con futuras versiones de PHP. Conviene anotarlo y actualizar el plugin o tema afectado. Un Fatal error requiere atención más rápida porque puede bloquear una página.
Usar solo un informe simple es razonable si una caída tiene poco impacto y alguien revisa el registro cuando surge un problema. El riesgo aumenta si vendes online o recibes reservas fuera de horario. En esos casos, una alerta para errores críticos reduce el tiempo de reacción.
¿Qué plugin de logs elegir para errores PHP?
Elige un plugin de logs que permita acceso restringido, filtros por gravedad y borrado programado de registros. Para una web pequeña, evita herramientas que envíen alertas por cada Warning. Si gestionas varias webs, busca agrupación de incidencias, búsqueda y etiquetas por sitio.
✉
¿Quieres más información? Escríbenos y te orientamos
Empieza pequeño y vigila lo crítico
Lo esencial: un visor simple cubre errores puntuales cuando el impacto de una caída es bajo. Lo esencial: las alertas tienen sentido cuando un pago, una reserva o un formulario puede fallar sin que nadie lo advierta. Lo esencial: filtra, agrupa y limita la retención antes de activar logging avanzado. Lo esencial: protege siempre rutas, IP, correos, tokens y cualquier dato que aparezca en los registros. La herramienta adecuada es la que permite detectar un fallo a tiempo sin crear una carga diaria innecesaria. Empieza con un registro privado, documenta los errores repetidos y sube de nivel cuando el coste de esperar sea mayor que el coste de vigilar.
Fuentes de interés
Otros artículos que pueden complementar lo que acabas de leer:
