Una pantalla en blanco, un formulario que se queda esperando o una tarea que no termina necesitan un diagnóstico concreto. Los registros de errores en WordPress pueden aportar pistas, siempre que se relacionen con la acción que ha fallado y con su momento exacto.
Esta guía propone un procedimiento de investigación. No presupone que todas las incidencias tengan el mismo origen ni que activar la depuración resuelva el problema.
Describe el fallo antes de cambiar nada
Recomiendo anotar la URL, la acción realizada, el resultado esperado, el resultado observado y la hora con su zona horaria. Añade si afecta a usuarios identificados, visitantes o ambos. Esa ficha permite repetir la prueba y pedir ayuda sin depender de una descripción como «la web no funciona».
Por ejemplo: «Al enviar el formulario de contacto, el indicador permanece girando; no aparece confirmación; ocurre en móvil y escritorio». Es un escenario ilustrativo, no una incidencia verificada de este sitio.
Comprueba también el alcance: una página, todo el frontend o el administrador. Si el problema comenzó después de una actualización, anota qué componentes cambiaron sin concluir todavía cuál lo provocó.
Qué ofrece la depuración de WordPress
La documentación oficial de WordPress distingue tres ajustes: WP_DEBUG activa el modo de depuración; WP_DEBUG_LOG permite registrar mensajes; WP_DEBUG_DISPLAY controla su aparición en el HTML. Los dos últimos dependen de que el primero esté activado.
Con WP_DEBUG_LOG en true, el destino habitual es wp-content/debug.log; también admite una ruta de archivo válida. La documentación recomienda estas herramientas para pruebas locales o staging, no para dejarlas activas en un sitio público.
Un registro de WordPress es una pieza del diagnóstico. Mi recomendación es contrastarlo con los registros que facilite el alojamiento y con la petición que falla en el navegador, sin asumir que todos muestran el mismo tipo de incidencia.
Prepara una prueba reversible en staging
Antes de editar configuración, utiliza una copia de pruebas separada y conserva la configuración anterior. Si no tienes acceso técnico o una vía de recuperación, solicita la intervención del responsable del alojamiento.
Como ejemplo de configuración temporal en esa copia, revisa las definiciones existentes de estas constantes en wp-config.php. Modifica sus valores; no añadas definiciones duplicadas:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WordPress sitúa estas definiciones antes del comentario que indica el fin de la edición. Los valores booleanos se escriben sin comillas. Ocultar mensajes en pantalla no protege por sí solo el archivo de registro: recomiendo restringir su acceso y no compartirlo mediante una URL pública.
Reproduce una sola acción y compara el registro
- Anota la hora de inicio y conserva el registro previo.
- Repite una vez la acción que falla con datos de prueba.
- Busca mensajes nuevos que coincidan con ese intervalo.
- Relaciona el mensaje con su archivo, línea y contexto.
- Repite de forma controlada para comprobar si la relación se mantiene.
Este orden es una recomendación de trabajo. Evita mezclar varias pruebas: actualizar plugins, cambiar el tema y modificar el formulario a la vez hace más difícil saber qué cambio alteró el resultado.
La ruta de un plugin en un mensaje es una pista para investigar; no demuestra por sí sola que ese plugin sea la única causa. Puede intervenir una integración o una configuración externa. Tampoco conviene tratar un aviso antiguo como explicación automática de un fallo actual.
Si no aparece ningún mensaje nuevo
Mi propuesta es comprobar primero que estás leyendo el archivo de la copia correcta, que los ajustes se aplican y que el proceso puede escribir en su destino. Después revisa los registros del servidor disponibles y la petición fallida en las herramientas del navegador.
Si la página solo falla al interactuar, observa la consola y la pestaña de red. Registra el estado HTTP y la respuesta relevante sin copiar cookies, tokens o contenido personal. Que el log de PHP esté vacío no prueba que el formulario haya enviado un correo; para ese caso consulta el diagnóstico de envíos desde WordPress.
Corrige con evidencia y valida la misma prueba
Propongo preparar una hipótesis concreta: «Este cambio debería evitar este mensaje al repetir esta acción». Aplica la corrección en staging y vuelve a ejecutar la prueba inicial. Comprueba la función visible y los nuevos registros, además de funciones relacionadas.
No edites WordPress Core para ocultar un síntoma. Si se confirma una incompatibilidad, prepara una actualización o corrección mantenible y sigue un proceso de actualización con validación y reversión.
Para cerrar la investigación, restaura la configuración de depuración anterior, gestiona los archivos temporales y documenta qué se comprobó. Guarda solo los extractos necesarios, con acceso restringido y eliminando datos sensibles. «No volvió a ocurrir durante la prueba» describe una observación; «solucionado en todos los escenarios» exige más evidencia.
¿Necesitas investigar una incidencia de tu web?
El servicio de mantenimiento WordPress permite plantear una revisión técnica con pruebas y cambios controlados.
Fuente oficial
WordPress Developer Resources: depuración en WordPress.
Fuente consultada el 6 de octubre de 2026. El procedimiento de investigación y los criterios de cierre son recomendaciones técnicas; el ejemplo se destina a una copia de pruebas.
