Identificar problemas en plugins o themes con Health Check para WordPress

Si usaras WordPress sin una herramienta de diagnóstico, sería como conducir un coche sin salpicadero: parece que todo va bien… hasta que te quedas tirado. En mi día a día, Health Check & Troubleshooting es ese salpicadero. Me da una lectura clara de lo que importa: compatibilidad de PHP, plugins desactualizados, integridad de archivos y pruebas de correo, entre otros.

¿Qué resuelve de verdad?

Conflictos entre plugins o entre un plugin y tu theme.
Incompatibilidades con la versión de PHP o de WordPress.
Problemas de entorno (módulos del servidor, extensiones, límites de memoria).
Comprobaciones rápidas (correo saliente, integridad de archivos, REST API).

Cuándo usarlo (y cuándo no)

✅ Úsalo cuando tengas errores intermitentes, pantallas en blanco, bloqueos del editor o comportamientos raros tras una actualización.
✅ Úsalo antes de abrir un ticket al desarrollador: llegarás con datos.
❌ No lo uses como sustituto de un staging para cambios masivos.
❌ No esperes que arregle por sí mismo la web: te guía, tú decides.

Algo que valoro muchísimo es que sus recomendaciones no requieren ser técnico para entenderlas. Y cuando toca la parte delicada —probar sin romper nada—, su modo de solución de problemas es, literalmente, oro puro.

Requisitos previos y copias de seguridad mínimas

Antes de tocar nada, dejo esto listo en 5 minutos:

Copia de seguridad express

Archivos: al menos wp-content (plugins, themes, uploads).
Base de datos: exportación rápida desde tu hosting o plugin de backup.

Entorno y acceso

Usuario administrador a WordPress.
Acceso a hosting (para ver logs y, si hace falta, activar WP_DEBUG).
Navegador sin extensiones agresivas (adblockers pueden “falsear” pruebas).

Orden y registro

Un documento de notas: cada cambio que haces, lo apuntas (hora, qué activaste, qué pasó).
Si gestionas varias webs o clientes, este registro evita repeticiones y acelera tickets.

En mi experiencia, este calentamiento previo ahorra tiempo después. Cuando trabajas con clientes, llegar con “paso a paso + resultados” transmite control y evita culpar al plugin equivocado.

Activar el modo de solución de problemas sin afectar a los visitantes

La joya de Health Check es que te permite desactivar plugins y cambiar de theme solo para tu sesión, sin que el público lo note. Así diagnosticas “en vivo”, con tráfico real, pero sin riesgos.

¿Dónde se activa?

Ve a Herramientas → Salud del sitio.
Abre la pestaña Solución de problemas (Troubleshooting).
Actívala: para ti la web quedará con el theme por defecto y sin plugins. Para los visitantes, todo sigue igual.

¿Qué pasa exactamente?

Para tu usuario admin, WordPress arranca como un entorno limpio.
Puedes activar plugins uno a uno (o en grupos) y probar.
Puedes cambiar de theme (o simular el por defecto) sin afectar a nadie.

Trabajando con varias webs, este modo me permite hacer pruebas en horario comercial sin sudar: “no afecta a los visitantes mientras pruebas”. Es perfecto para aislar el culpable con calma.

Paso a paso: localizar el conflicto (plugins y theme)

Este es el flujo de diagnóstico que aplico siempre:

A. Establece el punto de partida

Con el modo activo, sin plugins y con theme por defecto, verifica si el síntoma persiste (error 500, pantalla blanca, bloqueos del editor, checkout roto, etc.).
- Si el problema desaparece, ya sabes que es software (plugin o theme).
- Si persiste, sospecha de hosting, caché del servidor, reglas .htaccess o código personalizado.

B. Reactiva por bloques

Activa primero plugins críticos (seguridad, caché, e-commerce) y prueba.
Sigue por familias: SEO, maquetadores, formularios, analytics, etc.
Cuando el error reaparezca, ya acotaste el bloque.

C. Aisla el culpable

Dentro del bloque, activa uno a uno y prueba cada vez.
Al encontrar el culpable, confirma con doble verificación: desactívalo → desaparece el error; actívalo → vuelve el error.

D. Valida con el theme

Con el plugin sospechoso activo, vuelve al theme original: si el fallo solo ocurre con tu theme, puede ser conflicto plugin+theme.
Si falla incluso con el theme por defecto, el plugin es la causa.

Truco práctico: si usas cache (servidor o plugin), púrgala tras cada activación. Muchas falsas alarmas vienen de ver una versión cacheada.

Interpretar “Salud del sitio”: compatibilidad PHP, correo y archivos

Site Health no es solo para conflictos. Sus tarjetas y pruebas te dan contexto clave para resolver rápido:

Compatibilidad de PHP y WordPress

Revisa la versión de PHP recomendada y la que tienes.
Mira recomendaciones sobre extensiones (intl, mbstring, curl…).
Si un plugin declara soporte mínimo, no lo fuerces en versiones antiguas.

Integridad de archivos

Comprueba si hay archivos modificados del core. Si los hay, restáuralos.
Evita editar el core: personaliza con snippets o un plugin dedicado.

Correo saliente

Ejecuta la prueba de correo. Si falla, revisa:
- Configuración SMTP o plugin de entrega.
- Registros del servidor (bloqueos, límites).
- Autenticaciones SPF/DKIM si usas dominio propio.

Consejo de campo: cuando ves muchas “recomendaciones” amarillas, no entres en pánico. Prioriza las que afectan a seguridad, compatibilidad y rendimiento directo. Lo urgente arriba, lo “mejorable” después.

Cuando Health Check no basta: diagnóstico manual con `WP_DEBUG` y logs

Hay errores que solo se ven en el log (consultas a APIs, crons, hooks específicos). Ahí entra el modo manual:

Activar `WP_DEBUG` (temporalmente)

En wp-config.php, añade o ajusta:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Reproduce el error; revisa /wp-content/debug.log.
Al terminar, desactívalo para no llenar el disco ni exponer información.

Qué buscar en el log

Fatal errors: llamadas a funciones/métodos no existentes.
Deprecated notices: compatibilidad (no siempre rompen, pero avisan).
Errores de memoria: aumenta WP_MEMORY_LIMIT si procede y revisa plugins pesados.
Conflictos de hooks: dos plugins intentando filtrar/accionar lo mismo.

En mi caso, cuando el modo diagnóstico “no canta”, el debug.log me da la línea exacta y el stack donde ocurre. Con esos datos, abrir un ticket deja de ser “me pasa algo raro” y pasa a “este aviso se dispara en class-x.php al llamar a method_y”.

Buenas prácticas si gestionas varias webs o trabajas con clientes

Guía de bolsillo por cliente: dónde está el hosting, cómo acceder a logs, quién es el contacto y qué plugins son intocables en horario de ventas.
Sandbox o staging siempre que el cambio sea mayor (updates masivas, rediseños). Health Check para aislar; staging para ensayar.
Ventana de mantenimiento pactada: si crees que tendrás que purgar cachés agresivas o reiniciar servicios, avisa.
Notas post-incidente: causa, impacto, solución y prevención (próxima revisión, actualización pendiente).
Plantilla de ticket para desarrolladores: síntoma, pasos reproducibles, estado con Health Check, versión de PHP/WordPress, extracto del log.

En mi trabajo con clientes, esta disciplina convierte un “misterio” en un procedimiento repetible, reduce tiempos de respuesta y, sobre todo, genera confianza.

Errores comunes y cómo evitarlos

Dejar el modo diagnóstico activo y pensar que “ya está solucionado” → ciérralo al terminar.
Confundir staging con producción: no pruebes cambios masivos en vivo.
Olvidar la caché: servidor/CDN/plugin; purga tras cada cambio.
Actualizar a ciegas: revisa changelogs de plugins críticos (e-commerce, membresías, constructores).
No documentar: sin notas, repites pruebas y olvidas qué plugin reactivaste cuando volvió el error.
Ignorar avisos de compatibilidad: forzar un plugin en PHP demasiado nuevo/antiguo es receta de problemas.

Alternativas y complementos útiles (y cuándo usarlos)

Staging del hosting: para cambios grandes o actualizaciones en serie.
Plugins SMTP: si el test de correo falla, configura uno y prueba de nuevo.
Monitores externos (uptime/apdex): para detectar caídas intermitentes que el usuario no ve.
Gestores de actualizaciones: programan updates fuera de horario pico y registran qué cambió.
Reglas de seguridad (WAF/CDN): si un conflicto aparece “solo a veces”, mira si una regla bloquea endpoints.

Checklist rápido para salir del apuro

Backup express (archivos + BD).
Abre Health Check → Solución de problemas.
Comprueba si el síntoma desaparece con todo desactivado y theme por defecto.
Activa por bloques (críticos → familias) y prueba.
Aísla el culpable, confirma (apaga/enciende).
Revisa Site Health: PHP, extensiones, archivos, correo.
Si persiste, activa WP_DEBUG_LOG y reproduce.
Documenta hallazgos; decide update, rollback, parche o ticket.
Cierra el modo, purga cachés y valida en incógnito.
Escribe notas y prevención para la próxima.

Tabla “síntoma → prueba → acción”

Síntoma	Prueba rápida	Acción recomendada
Editor bloqueado / pantallas blancas	Modo de solución de problemas con todo off	Reactiva por bloques; si vuelve, aísla plugin; revisa `debug.log`
Checkout roto / errores JS	Consola del navegador + reactivación escalonada	Identifica scripts en conflicto; desactiva minificación avanzada temporalmente
Emails no salen	Prueba de correo en Site Health	Configura SMTP, revisa SPF/DKIM, comprueba límites del servidor
Caídas aleatorias	Logs del servidor + uptime externo	Revisa cron, plugins pesados, límites de memoria; programa actualizaciones fuera de pico
Lentitud repentina	Desactiva caché en tu sesión y compara	Purga cachés, evalúa plugin de caché, revisa consultas lentas en logs

Health Check

Health Check no “arregla” por ti, te muestra el camino. A mí me ha ahorrado incontables horas y más de un susto con clientes porque me permite probar sin romper. Con el flujo adecuado —backup, modo de solución de problemas, activación por bloques, lectura de Site Health y, si toca, debug.log— puedes pasar del “no sé qué pasa” al diagnóstico claro en muy poco tiempo. Y con notas y disciplina, esa solución se vuelve repetible en todas tus webs.

FAQs

¿El modo de solución de problemas afecta a mis visitantes?
No. Solo altera tu sesión de administrador. Ellos siguen viendo la web normal.

¿Cuánto tiempo lo dejo activo?
El mínimo necesario para aislar el conflicto. Al terminar, ciérralo y purga cachés.

¿Qué hago si dos plugins “necesarios” chocan?
Prioriza el de negocio (p. ej., cobros). Busca versión alternativa, parche temporal o contacta al desarrollador con logs y pasos reproducibles.

¿Necesito staging si tengo Health Check?
Sí, para cambios grandes. Health Check es para aislar; staging, para ensayar.

Opinión Personal

Si gestionas WordPress sin Health Check, estás conduciendo sin salpicadero. Puedes ir “bien”… hasta que algo revienta. Para mí, este plugin es imprescindible porque me da una foto clara de compatibilidades, estado del servidor y puntos flacos antes de que se conviertan en incendios. Y su modo de solución de problemas es oro puro: me permite desactivar plugins y probar con seguridad sin que los visitantes lo noten. Eso, para quien trabaja con clientes o varias webs, es la diferencia entre improvisar y operar con método.

También valoro que las recomendaciones se entienden sin ser técnico. No necesitas perderte en jerga para saber qué corregir primero. ¿Es perfecto? No. Cuando un conflicto es muy específico, toca tirar de WP_DEBUG y logs, pero incluso ahí Health Check me acorta el camino: aísla al sospechoso y llego al log con una hipótesis sólida.

En resumen: si buscas estabilidad y diagnósticos rápidos, Health Check debería estar en tu caja de herramientas desde ayer. Te ahorra tiempo, reduce estrés y te ayuda a comunicar soluciones claras a tus clientes o equipo.

¿Tú qué opinas? ¿Te ha salvado ya de algún conflicto raro entre plugins o themes? ¡Cuéntamelo abajo! Deja tus comentarios, preguntas o tu caso concreto y lo vemos juntos.