![\"Publicaciones](\"https:\/\/reparamiweb.com\/pe\/wp-content\/uploads\/sites\/2\/2025\/12\/modo-debug-wordpress-1.png\")
<\/p>\nAprende paso a paso c\u00f3mo comprobar si el cach\u00e9 de tu WordPress funciona correctamente revisando headers, navegador, CDN y archivos de cach\u00e9.<\/p>\n
<\/p>\n
Cuando un sitio WordPress falla, casi siempre pasa lo mismo: t\u00fa sabes que algo est\u00e1 mal, pero el sitio no te dice qu\u00e9 es.<\/p>\n
Una p\u00e1gina no carga. El panel queda en blanco. Un plugin deja de responder despu\u00e9s de una actualizaci\u00f3n.<\/p>\n
Y como no hay mensaje, toca \u201cprobar cosas\u201d a ciegas.<\/p>\n
El modo debug existe para eso: para que WordPress te muestre el error real, con su archivo y su l\u00ednea exacta.<\/p>\n
WordPress suele ocultar errores para que los visitantes no vean mensajes t\u00e9cnicos. Eso se ve \u201climpio\u201d por fuera, pero por dentro te deja sin pistas.<\/p>\n
Por eso aparecen escenarios como estos:<\/p>\n
El error s\u00ed existe. Solo que no lo est\u00e1s viendo.<\/p>\n
![\"Modo](\"https:\/\/reparamiweb.com\/pe\/wp-content\/uploads\/sites\/2\/2025\/12\/modo-debug-wordpress.png\")
<\/p>\n
El modo debug es una funci\u00f3n interna de WordPress que muestra y registra errores que normalmente est\u00e1n ocultos.<\/p>\n
Por defecto, WordPress prefiere no mostrar mensajes t\u00e9cnicos para no afectar la experiencia de los visitantes. Eso se ve bien por fuera, pero cuando algo falla, te deja sin pistas.<\/p>\n
El modo debug cambia eso.<\/p>\n
Cuando est\u00e1 activo, WordPress deja de esconder los problemas y te dice:<\/p>\n
Es importante tener esto claro:<\/p>\n
Su \u00fanico objetivo es darte informaci\u00f3n real para dejar de adivinar.<\/p>\n
Pi\u00e9nsalo como una linterna. No soluciona el problema, pero te permite ver exactamente d\u00f3nde est\u00e1.<\/p>\n
Adem\u00e1s, 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.<\/p>\n
Gracias a eso, puedes identificar r\u00e1pido si el problema viene de un plugin, el tema o el propio sistema<\/p>\n
No necesitas saber c\u00f3digo. Con solo ver la ruta del archivo, ya sabes por d\u00f3nde empezar a revisar.<\/p>\n
Cuando el modo debug est\u00e1 activo, WordPress muestra mensajes de error en la parte p\u00fablica del sitio o dentro del panel de administraci\u00f3n.<\/p>\n
No todos los mensajes tienen el mismo peso o importacias. El modo debug suele mostrar tres tipos:<\/p>\n
Avisos (PHP Notice)<\/strong> Advertencias (PHP Warning)<\/strong> Errores graves (PHP Fatal error)<\/strong> Adem\u00e1s del texto del error, el modo debug casi siempre muestra:<\/p>\n Ejemplo:<\/p>\n Para habilitar el modo debug en WordPress sigue los siguientes pasos:<\/p>\n Dentro de ese archivo, busca esta l\u00ednea:<\/p>\n Todo el c\u00f3digo que ver\u00e1s a continuaci\u00f3n debe ir antes de esa l\u00ednea.<\/p>\n Por defecto, WordPress trae el debug desactivado. Para activarlo, usa esta l\u00ednea:<\/p>\n Con esto le dices a WordPress: \u201cEmpieza a registrar errores\u201d.<\/p>\n En lugar de mostrar los errores en pantalla, es mejor guardarlos en un archivo. Para eso, a\u00f1ade esta l\u00ednea:<\/p>\n Esto crea un archivo llamado debug.log dentro de la carpeta wp-content.<\/p>\n Mostrar errores en un sitio p\u00fablico no es buena idea. Para ocultarlos, usa esta l\u00ednea:<\/p>\n Todas las l\u00edneas juntas se ver\u00edan as\u00ed:<\/p>\n Con esto:<\/p>\n Si est\u00e1s revisando problemas visuales o errores raros con scripts, puedes a\u00f1adir:<\/p>\n Esto hace que WordPress use archivos sin comprimir, m\u00e1s f\u00e1ciles de revisar.<\/p>\n No es obligatorio para la mayor\u00eda de casos.<\/p>\n El modo debug no se deja activo todo el tiempo.<\/p>\n Cuando ya revisaste el problema, vuelve a dejarlo as\u00ed:<\/p>\n Esto evita mostrar informaci\u00f3n innecesaria y mantiene el sitio m\u00e1s seguro.<\/p>\n Cuando activas el modo debug y usas WP_DEBUG_LOG, WordPress guarda los errores en un archivo de texto llamado debug.log.<\/p>\n Este archivo es como un historial de lo que sali\u00f3 mal en tu sitio.<\/p>\n No necesitas saber programaci\u00f3n para entenderlo. Solo necesitas saber qu\u00e9 partes mirar.<\/p>\n Por defecto, WordPress guarda el archivo en esta ruta:<\/p>\n \/wp-content\/debug.log<\/p>\n Para abrirlo tienes varias opciones:<\/p>\n Si el archivo no existe todav\u00eda, no es un problema, WordPress lo crea autom\u00e1ticamente cuando ocurre el primer error.<\/p>\n Al abrir el archivo, ver\u00e1s muchas l\u00edneas de texto. Cada l\u00ednea es un error o aviso distinto.<\/p>\n Una l\u00ednea t\u00edpica se ve as\u00ed:<\/p>\n Puede verse largo, pero en realidad tiene partes muy claras.<\/p>\n Vamos por partes.<\/p>\n [15-Sep-2025 10:42:25 UTC]<\/p>\n Esto te dice cu\u00e1ndo ocurri\u00f3 el error.<\/p>\n Este dato es clave. Te ayuda a relacionar el error con lo \u00faltimo que hiciste en el sitio:<\/p>\n Si la hora coincide con el momento en que algo dej\u00f3 de funcionar, vas por buen camino.<\/p>\n Despu\u00e9s de la fecha, aparece el tipo de mensaje:<\/p>\n No todos los mensajes son igual de importantes. Cuando el sitio se cae, casi siempre el problema est\u00e1 en un Fatal error.<\/p>\n Luego aparece una frase que explica qu\u00e9 pas\u00f3.<\/p>\n Ejemplo:<\/p>\n No necesitas entender el c\u00f3digo. Solo saber que WordPress intent\u00f3 hacer algo y no pudo.<\/p>\n Este texto da contexto, pero no es lo m\u00e1s importante para empezar.<\/p>\n Al final del mensaje aparece algo como esto:<\/p>\n Aqu\u00ed est\u00e1 la pista clave.<\/p>\n F\u00edjate primero en la carpeta, no en el nombre del archivo:<\/p>\n Con solo ver esto, ya sabes por d\u00f3nde empezar a revisar.<\/p>\n Esto indica la l\u00ednea exacta donde ocurri\u00f3 el fallo.<\/p>\n No es necesario abrir el archivo ni tocar c\u00f3digo. Este dato es m\u00e1s \u00fatil para soporte t\u00e9cnico o desarrollo, pero confirma que el error es real y repetible.<\/p>\n Una vez entiendes estas partes, puedes usar debug.log de forma pr\u00e1ctica:<\/p>\n El log no est\u00e1 para asustarte. Est\u00e1 para ayudarte a tomar decisiones con informaci\u00f3n real.<\/p>\n Es normal ver muchos \u00abNotice\u00bb y \u00abWarning\u00bb, incluso en sitios que funcionan bien.<\/p>\n Eso no significa que el sitio est\u00e9 da\u00f1ado.<\/p>\n Cuando el sitio deja de cargar o el panel no responde, busca:<\/p>\n Ese suele ser el que explica el problema real.<\/p>\n Cuando ya entendiste qu\u00e9 pas\u00f3:<\/p>\n As\u00ed evitas archivos grandes, errores viejos y confusi\u00f3n la pr\u00f3xima vez.<\/p>\n El modo debug es una herramienta muy \u00fatil, pero debe usarse con cuidado. Antes de activarlo y despu\u00e9s de terminar la revisi\u00f3n, hay algunos puntos clave que conviene tener en cuenta para evitar problemas innecesarios.<\/p>\n Antes de activar el debug, revisa si el sitio est\u00e1 en un entorno p\u00fablico o si tiene mucho tr\u00e1fico.<\/p>\n Mostrar errores en pantalla puede confundir a los visitantes y dar una mala impresi\u00f3n. Por eso, siempre es mejor configurar el debug para guardar los errores en un archivo y no mostrarlos al p\u00fablico.<\/p>\n Tambi\u00e9n es buena idea tener claro qu\u00e9 est\u00e1s revisando. Activar el debug sin un objetivo suele generar muchos mensajes que no ayudan. Si sabes qu\u00e9 acci\u00f3n causa el problema, ser\u00e1 m\u00e1s f\u00e1cil identificar el error correcto.<\/p>\n Si tienes acceso a staging o a una copia del sitio, mejor a\u00fan. Revisar errores en un entorno de pruebas reduce riesgos y te permite trabajar con m\u00e1s calma.<\/p>\n Una vez activo, no te alarmes si ves muchos mensajes. No todos los avisos indican un problema grave. Conc\u00e9ntrate en los errores que coinciden con el momento en que el sitio dej\u00f3 de funcionar o cuando aparece el fallo que est\u00e1s investigando.<\/p>\n Evita tocar archivos al azar o borrar c\u00f3digo sin entender qu\u00e9 est\u00e1 pasando. El debug est\u00e1 para dar contexto, no para hacer cambios impulsivos. Si el mensaje apunta a un plugin o al tema, empieza por ah\u00ed: revisa si hay actualizaciones, prueba desactivarlo o verifica si el error apareci\u00f3 despu\u00e9s de un cambio reciente.<\/p>\n Una vez identificada la causa, desactiva el modo debug. Dejarlo activo sin necesidad puede generar archivos de log muy grandes y mostrar informaci\u00f3n que no deber\u00eda estar visible.<\/p>\n 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\u00e9 decir y d\u00f3nde mirar.<\/p>\n El modo debug de WordPress no arregla errores, pero te muestra exactamente qu\u00e9 est\u00e1 fallando y d\u00f3nde. 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\u00e9 pas\u00f3 antes de intentar arreglar tu sitio.<\/p>\n","protected":false},"excerpt":{"rendered":" Cuando tu WordPress falla y no muestra nada, el modo debug te ayuda a ver qu\u00e9 pas\u00f3 y por d\u00f3nde empezar a revisar.<\/p>\n","protected":false},"author":1,"featured_media":4629,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-4611","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mantenimiento-wordpress"],"yoast_head":"\n
\n<\/strong>Son mensajes leves. Indican que algo no est\u00e1 bien escrito o est\u00e1 mal definido, pero el sitio normalmente sigue funcionando. No suelen da\u00f1ar el sitio, pero son se\u00f1ales de que hay c\u00f3digo que conviene revisar.<\/p>\n
\n<\/strong>Son m\u00e1s serias. Indican conflictos, cargas en el orden incorrecto o problemas con archivos. El sitio puede seguir cargando, pero algo ya no est\u00e1 funcionando como deber\u00eda.<\/p>\n
\n<\/strong>Son los m\u00e1s 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\u00e9s de actualizar un plugin, el tema o cambiar la versi\u00f3n de PHP.<\/p>\nLa informaci\u00f3n m\u00e1s valiosa del mensaje<\/strong><\/h3>\n
\n
\n\/wp-content\/plugins\/mi-plugin\/funciones.php on line 87<\/code><\/pre>\n<\/div>\nC\u00f3mo activar el modo debug paso a paso<\/strong><\/h2>\n
Paso 1: Abre el archivo wp-config.php<\/h3>\n
\n
\n\/* That's all, stop editing! Happy publishing. *\/<\/code><\/pre>\n<\/div>\nPaso 2: Activa el modo debug<\/h3>\n
\ndefine( 'WP_DEBUG', true );<\/code><\/pre>\n<\/div>\nPaso 3: Guarda los errores en un archivo (recomendado)<\/h3>\n
\ndefine( 'WP_DEBUG_LOG', true );<\/code><\/pre>\n<\/div>\nPaso 4: Evita mostrar errores al p\u00fablico<\/h3>\n
\ndefine( 'WP_DEBUG_DISPLAY', false );\r\n@ini_set( 'display_errors', 0 );<\/code><\/pre>\n<\/div>\nConfiguraci\u00f3n recomendada (lista para copiar)<\/strong><\/h3>\n
\ndefine( 'WP_DEBUG', true );\r\ndefine( 'WP_DEBUG_LOG', true );\r\ndefine( 'WP_DEBUG_DISPLAY', false );\r\n@ini_set( 'display_errors', 0 );<\/code><\/pre>\n<\/div>\n\n
Opcional: revisar errores de JavaScript y CSS<\/strong><\/h3>\n
\ndefine( 'SCRIPT_DEBUG', true );<\/code><\/pre>\n<\/div>\nMuy importante: desact\u00edvalo cuando termines<\/h3>\n
\ndefine( 'WP_DEBUG', false );<\/code><\/pre>\n<\/div>\nC\u00f3mo leer el archivo debug.log de WordPress sin ser t\u00e9cnico<\/h2>\n
![\"C\u00f3mo](\"https:\/\/reparamiweb.com\/pe\/wp-content\/uploads\/sites\/2\/2025\/12\/archivo-debug-wordpress.jpg\")
<\/p>\nD\u00f3nde encontrar el archivo debug.log<\/h3>\n
\n
Qu\u00e9 ves cuando abres debug.log<\/h3>\n
\n[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<\/code><\/pre>\n<\/div>\n1. Fecha y hora<\/h3>\n
\n
2. Tipo de error<\/h3>\n
\n
3. Qu\u00e9 dice el mensaje<\/h3>\n
\nCall to undefined function obtener_datos()<\/code><\/pre>\n<\/div>\n4. La parte m\u00e1s importante: la ruta del archivo<\/h3>\n
\n\/wp-content\/plugins\/mi-plugin\/funciones.php on line 87<\/code><\/pre>\n<\/div>\n\n
5. La l\u00ednea del error<\/h3>\n
\non line 87<\/code><\/pre>\n<\/div>\nC\u00f3mo usar el log para tomar decisiones<\/h3>\n
\n
Algo importante: no todos los errores importan igual<\/strong><\/h3>\n
\n
Qu\u00e9 hacer cuando termines de revisar<\/h3>\n
\n
Consideraciones importantes antes y despu\u00e9s de activar el modo debug en WordPress<\/h2>\n
Antes de activar el modo debug<\/h3>\n
Despu\u00e9s de activar el modo debug<\/h3>\n
Cuando ya encontraste el problema<\/h3>\n
TL;DR<\/strong><\/h3>\n