Modo debug en WordPress: cómo encontrar errores sin adivinar

Cuando tu WordPress falla y no muestra nada, el modo debug te ayuda a ver qué pasó y por dónde empezar a revisar.

Modo debug en WordPress: cómo encontrar errores sin adivinar

Cuando un sitio WordPress falla, casi siempre pasa lo mismo: tú sabes que algo está mal, pero el sitio no te dice qué es.

Una página no carga. El panel queda en blanco. Un plugin deja de responder después de una actualización.

Y como no hay mensaje, toca “probar cosas” a ciegas.

El modo debug existe para eso: para que WordPress te muestre el error real, con su archivo y su línea exacta.

Cuando algo falla y nadie te explica por qué

WordPress suele ocultar errores para que los visitantes no vean mensajes técnicos. Eso se ve “limpio” por fuera, pero por dentro te deja sin pistas.

Por eso aparecen escenarios como estos:

  • Pantalla en blanco sin explicación
  • Funciones que dejan de responder de un momento a otro
  • Errores que solo aparecen “a ratos”
  • Cambios pequeños que terminan causando fallos grandes

El error sí existe. Solo que no lo estás viendo.

Qué es el modo debug en WordPress

Modo debug en WordPress: qué es

El modo debug es una función interna de WordPress que muestra y registra errores que normalmente están ocultos.

Por defecto, WordPress prefiere no mostrar mensajes técnicos para no afectar la experiencia de los visitantes. Eso se ve bien por fuera, pero cuando algo falla, te deja sin pistas.

El modo debug cambia eso.

Cuando está activo, WordPress deja de esconder los problemas y te dice:

  • qué error ocurrió
  • en qué archivo
  • en qué línea

Es importante tener esto claro:

  • el modo debug no arregla errores
  • no mejora el rendimiento
  • no protege el sitio

Su único objetivo es darte información real para dejar de adivinar.

Piénsalo como una linterna. No soluciona el problema, pero te permite ver exactamente dónde está.

Además, el modo debug no tiene que mostrar errores en pantalla. Puede guardarlos en un archivo (debug.log) para que los revises con calma, sin afectar a los visitantes.

Gracias a eso, puedes identificar rápido si el problema viene de un plugin, el tema o el propio sistema

No necesitas saber código. Con solo ver la ruta del archivo, ya sabes por dónde empezar a revisar.

Qué pasa cuando activas el modo debug en WordPress

Cuando el modo debug está activo, WordPress muestra mensajes de error en la parte pública del sitio o dentro del panel de administración.

No todos los mensajes tienen el mismo peso o importacias. El modo debug suele mostrar tres tipos:

Avisos (PHP Notice)
Son mensajes leves. Indican que algo no está bien escrito o está mal definido, pero el sitio normalmente sigue funcionando. No suelen dañar el sitio, pero son señales de que hay código que conviene revisar.

Advertencias (PHP Warning)
Son más serias. Indican conflictos, cargas en el orden incorrecto o problemas con archivos. El sitio puede seguir cargando, pero algo ya no está funcionando como debería.

Errores graves (PHP Fatal error)
Son los más importantes. Cuando aparecen, WordPress no puede continuar. El resultado suele ser una pantalla en blanco o un panel que no responde. Estos errores suelen aparecer después de actualizar un plugin, el tema o cambiar la versión de PHP.

La información más valiosa del mensaje

Además del texto del error, el modo debug casi siempre muestra:

  • la ruta del archivo
  • la línea exacta donde ocurrió el fallo

Ejemplo:

/wp-content/plugins/mi-plugin/funciones.php on line 87

Cómo activar el modo debug paso a paso

Para habilitar el modo debug en WordPress sigue los siguientes pasos:

Paso 1: Abre el archivo wp-config.php

  1. Entra al panel de tu hosting.
  2. Busca el archivo wp-config.php (está en la raíz de tu sitio).
  3. Ábrelo para editar.

Dentro de ese archivo, busca esta línea:

/* That's all, stop editing! Happy publishing. */

Todo el código que verás a continuación debe ir antes de esa línea.

Paso 2: Activa el modo debug

Por defecto, WordPress trae el debug desactivado. Para activarlo, usa esta línea:

define( 'WP_DEBUG', true );

Con esto le dices a WordPress: “Empieza a registrar errores”.

Paso 3: Guarda los errores en un archivo (recomendado)

En lugar de mostrar los errores en pantalla, es mejor guardarlos en un archivo. Para eso, añade esta línea:

define( 'WP_DEBUG_LOG', true );

Esto crea un archivo llamado debug.log dentro de la carpeta wp-content.

Paso 4: Evita mostrar errores al público

Mostrar errores en un sitio público no es buena idea. Para ocultarlos, usa esta línea:

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

Configuración recomendada (lista para copiar)

Todas las líneas juntas se verían así:

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

Con esto:

  • El debug quedaría activo
  • Los errores se guardan en un archivo
  • El sitio se ve normal por fuera sin mostrar mensajes de error

Opcional: revisar errores de JavaScript y CSS

Si estás revisando problemas visuales o errores raros con scripts, puedes añadir:

define( 'SCRIPT_DEBUG', true );

Esto hace que WordPress use archivos sin comprimir, más fáciles de revisar.

No es obligatorio para la mayoría de casos.

Muy importante: desactívalo cuando termines

El modo debug no se deja activo todo el tiempo.

Cuando ya revisaste el problema, vuelve a dejarlo así:

define( 'WP_DEBUG', false );

Esto evita mostrar información innecesaria y mantiene el sitio más seguro.

Cómo leer el archivo debug.log de WordPress sin ser técnico

Cómo leer el archivo debug.log de WordPress sin ser técnico

Cuando activas el modo debug y usas WP_DEBUG_LOG, WordPress guarda los errores en un archivo de texto llamado debug.log.

Este archivo es como un historial de lo que salió mal en tu sitio.

No necesitas saber programación para entenderlo. Solo necesitas saber qué partes mirar.

Dónde encontrar el archivo debug.log

Por defecto, WordPress guarda el archivo en esta ruta:

/wp-content/debug.log

Para abrirlo tienes varias opciones:

  • Desde el panel de tu hosting, usando el administrador de archivos
  • Por FTP, con herramientas como FileZilla
  • Descargando el archivo y abriéndolo con cualquier editor de texto

Si el archivo no existe todavía, no es un problema, WordPress lo crea automáticamente cuando ocurre el primer error.

Qué ves cuando abres debug.log

Al abrir el archivo, verás muchas líneas de texto. Cada línea es un error o aviso distinto.

Una línea típica se ve así:

[15-Sep-2025 10:42:25 UTC] PHP Fatal error: Call to undefined function obtener_datos() in /wp-content/plugins/mi-plugin/funciones.php on line 87

Puede verse largo, pero en realidad tiene partes muy claras.

Vamos por partes.

1. Fecha y hora

[15-Sep-2025 10:42:25 UTC]

Esto te dice cuándo ocurrió el error.

Este dato es clave. Te ayuda a relacionar el error con lo último que hiciste en el sitio:

  • instalaste o actualizaste un plugin
  • cambiaste el tema
  • guardaste ajustes
  • cambiaste la versión de PHP

Si la hora coincide con el momento en que algo dejó de funcionar, vas por buen camino.

2. Tipo de error

Después de la fecha, aparece el tipo de mensaje:

  • PHP Notice Es un aviso leve. El sitio suele seguir funcionando.
  • PHP Warning Es una advertencia. Algo no está bien y conviene revisarlo.
  • PHP Fatal error Es un error grave. WordPress no puede continuar y el sitio puede quedar en blanco.

No todos los mensajes son igual de importantes. Cuando el sitio se cae, casi siempre el problema está en un Fatal error.

3. Qué dice el mensaje

Luego aparece una frase que explica qué pasó.

Ejemplo:

Call to undefined function obtener_datos()

No necesitas entender el código. Solo saber que WordPress intentó hacer algo y no pudo.

Este texto da contexto, pero no es lo más importante para empezar.

4. La parte más importante: la ruta del archivo

Al final del mensaje aparece algo como esto:

/wp-content/plugins/mi-plugin/funciones.php on line 87

Aquí está la pista clave.

Fíjate primero en la carpeta, no en el nombre del archivo:

  • Si ves wp-content/plugins, el problema viene de un plugin
  • Si ves wp-content/themes, viene del tema
  • Si ves wp-includes o wp-admin, puede ser el sistema o un problema de compatibilidad del servidor

Con solo ver esto, ya sabes por dónde empezar a revisar.

5. La línea del error

on line 87

Esto indica la línea exacta donde ocurrió el fallo.

No es necesario abrir el archivo ni tocar código. Este dato es más útil para soporte técnico o desarrollo, pero confirma que el error es real y repetible.

Cómo usar el log para tomar decisiones

Una vez entiendes estas partes, puedes usar debug.log de forma práctica:

  • Si el error apunta a un plugin que se actualizó, prueba desactivarlo
  • Si apunta al tema, revisa si hubo cambios recientes
  • Si hay muchos avisos, pero el sitio funciona, no entres en pánico
  • Concéntrate en los errores que coinciden con el momento del fallo

El log no está para asustarte. Está para ayudarte a tomar decisiones con información real.

Algo importante: no todos los errores importan igual

Es normal ver muchos «Notice» y «Warning», incluso en sitios que funcionan bien.

Eso no significa que el sitio esté dañado.

Cuando el sitio deja de cargar o el panel no responde, busca:

  • el primer «Fatal error»
  • o el error que aparece justo antes de que el sitio falle

Ese suele ser el que explica el problema real.

Qué hacer cuando termines de revisar

Cuando ya entendiste qué pasó:

  • descarga el archivo si lo necesitas como referencia
  • borra o vacía debug.log
  • apaga el modo debug

Así evitas archivos grandes, errores viejos y confusión la próxima vez.

Consideraciones importantes antes y después de activar el modo debug en WordPress

El modo debug es una herramienta muy útil, pero debe usarse con cuidado. Antes de activarlo y después de terminar la revisión, hay algunos puntos clave que conviene tener en cuenta para evitar problemas innecesarios.

Antes de activar el modo debug

Antes de activar el debug, revisa si el sitio está en un entorno público o si tiene mucho tráfico.

Mostrar errores en pantalla puede confundir a los visitantes y dar una mala impresión. Por eso, siempre es mejor configurar el debug para guardar los errores en un archivo y no mostrarlos al público.

También es buena idea tener claro qué estás revisando. Activar el debug sin un objetivo suele generar muchos mensajes que no ayudan. Si sabes qué acción causa el problema, será más fácil identificar el error correcto.

Si tienes acceso a staging o a una copia del sitio, mejor aún. Revisar errores en un entorno de pruebas reduce riesgos y te permite trabajar con más calma.

Después de activar el modo debug

Una vez activo, no te alarmes si ves muchos mensajes. No todos los avisos indican un problema grave. Concéntrate en los errores que coinciden con el momento en que el sitio dejó de funcionar o cuando aparece el fallo que estás investigando.

Evita tocar archivos al azar o borrar código sin entender qué está pasando. El debug está para dar contexto, no para hacer cambios impulsivos. Si el mensaje apunta a un plugin o al tema, empieza por ahí: revisa si hay actualizaciones, prueba desactivarlo o verifica si el error apareció después de un cambio reciente.

Cuando ya encontraste el problema

Una vez identificada la causa, desactiva el modo debug. Dejarlo activo sin necesidad puede generar archivos de log muy grandes y mostrar información que no debería estar visible.

Si el error no es claro, se repite o apunta a partes del sistema que no reconoces, es mejor pedir ayuda antes de seguir probando. El mensaje del debug ya te da una ventaja importante: ahora sabes qué decir y dónde mirar.

TL;DR

El modo debug de WordPress no arregla errores, pero te muestra exactamente qué está fallando y dónde. Sirve para dejar de adivinar cuando el sitio se cae, aparece una pantalla en blanco o un plugin deja de funcionar. Al activarlo, WordPress registra avisos, advertencias y errores graves en un archivo llamado debug.log, donde puedes ver la fecha, el tipo de error y si viene de un plugin o del tema. Usado con cuidado y solo por el tiempo necesario, el modo debug es la mejor forma de entender qué pasó antes de intentar arreglar tu sitio.


Tu WordPress siempre al día con nuestro plan de mantenimiento mensual en Colombia

Un WordPress sin mantenimiento puede fallar sin aviso. Nuestro plan mensual reduce riesgos y mantiene tu sitio funcionando como debe.

Incluye:

  • Actualizaciones de WordPress, plugins y tema en ambiente controlado
  • Monitoreo de seguridad
  • Revisión de backups
  • Monitoreo de disponibilidad
  • Informe mensual con métricas y tareas

Mantén tu sitio funcionando sin problemas con mantenimiento mensual para WordPress.

Hablemos y deja que nuestro equipo de expertos gestione el mantenimiento regular de tu WordPress.