Cómo realizar una verificación de salud de WordPress para solución de problemas (Guía 2025)

Una verificación de salud de WordPress es un proceso de diagnóstico sistemático que evalúa la versión de PHP de su sitio, la integridad de la base de datos, los plugins activos, la compatibilidad del tema, el entorno del servidor y la postura de seguridad, todo desde el panel de administración de WordPress o mediante herramientas dedicadas. Ejecutar esta verificación regularmente previene fallos en cascada, identifica cuellos de botella de rendimiento antes de que afecten al posicionamiento y detecta vulnerabilidades de seguridad antes de que se conviertan en brechas.

La herramienta integrada Site Health (introducida en WordPress 5.2) proporciona un informe de estado automatizado y un panel de información de depuración sin procesar que los desarrolladores experimentados utilizan como primer paso en cualquier flujo de trabajo de resolución de problemas. Combinada con el plugin Health Check & Troubleshooting, puede replicar problemas de producción en una sesión aislada sin tocar el sitio en vivo, una capacidad que elimina el mayor riesgo en la depuración de WordPress: romper cosas para los visitantes reales mientras investiga.

Por qué las verificaciones de salud de WordPress importan más de lo que la mayoría de las guías admiten

La mayoría de los tutoriales tratan Site Health como una lista de verificación que se marca una sola vez. En la práctica, es una señal operativa continua. Los Core Web Vitals de Google penalizan directamente los sitios lentos o inestables. Un único plugin desactualizado con un CVE conocido puede resultar en un compromiso total del sitio en cuestión de horas tras la divulgación pública. Las incompatibilidades de versiones de PHP entre su servidor y el requisito mínimo de un plugin degradan silenciosamente el rendimiento mucho antes de que generen un error fatal.

Ejecutar en un entorno de VPS Hosting bien configurado le da control directo sobre las versiones de PHP, el caché a nivel de servidor y el endurecimiento de seguridad, un control que los entornos compartidos simplemente no pueden proporcionar. El flujo de trabajo de verificación de salud descrito a continuación asume que tiene acceso SSH o un panel de control capaz de modificar configuraciones a nivel de servidor, que es la base correcta para cualquier despliegue de WordPress en producción.

Paso 1: Acceder a la herramienta integrada de Site Health de WordPress

Navegue a Herramientas > Site Health dentro de su panel de administración de WordPress. WordPress comenzará inmediatamente a ejecutar verificaciones automatizadas y poblará la pestaña Estado con resultados categorizados por gravedad.

No se requiere ningún plugin para este paso. Site Health es funcionalidad del núcleo, y sus resultados se generan del lado del servidor, lo que significa que reflejan el entorno de ejecución real, no uno simulado.

Lo que Site Health realmente verifica internamente:

• Versión de PHP, límite de memoria y tiempo máximo de ejecución
• Versión activa de WordPress frente a la última versión estable
• Si la REST API es accesible y devuelve respuestas válidas
• Estado de ejecución de tareas cron programadas (wp-cron)
• Aplicación de HTTPS y validez del certificado SSL
• Presencia del archivo debug.log en una ubicación de acceso público
• Capacidad de solicitud de bucle invertido (requerida para actualizaciones en segundo plano e instalaciones de plugins)
• Versión del servidor de base de datos y si cumple los mínimos de WordPress
• Permisos de archivos y directorios para rutas sensibles

Paso 2: Interpretar correctamente el informe de estado de Site Health

La página de estado categoriza los hallazgos en tres niveles. Comprender lo que cada nivel realmente significa, y lo que no significa, previene tanto la complacencia como el pánico innecesario.

Problemas críticos que requieren atención inmediata:

• Versión de PHP desactualizada — PHP 7.4 llegó al fin de su vida útil en noviembre de 2022. Ejecutarlo significa que no hay parches de seguridad. WordPress 6.x recomienda oficialmente PHP 8.1 o 8.2.
• Plugins inactivos aún instalados — Los plugins inactivos siguen siendo legibles por el sistema de archivos y pueden contener código explotable. Elimínelos, no simplemente los desactive.
• REST API bloqueada — Muchos plugins modernos, el editor de bloques (Gutenberg) y WooCommerce dependen de la disponibilidad de la REST API. Una REST API bloqueada produce fallos silenciosos que son notoriamente difíciles de rastrear.
• Fallo en la solicitud de bucle invertido — Si WordPress no puede hacer una solicitud HTTP de bucle invertido a sí mismo, las actualizaciones automáticas en segundo plano y las tareas programadas fallarán silenciosamente.
• WP_DEBUG habilitado en un sitio en vivo — El modo de depuración escribe datos de configuración sensibles y trazas de pila en debug.log. Si ese archivo está en wp-content/ sin restricciones de acceso a nivel de servidor, es de lectura pública.

Un caso límite frecuentemente ignorado: Site Health reporta un estado “Bueno” para el caché de objetos si se detecta *cualquier* caché de objetos, incluido uno basado en archivos. El caché de objetos basado en archivos en sitios de alto tráfico puede en realidad aumentar la carga de I/O en lugar de reducirla. La solución correcta es un backend Redis o Memcached, que requiere configuración a nivel de servidor más allá de lo que Site Health puede aprovisionar.

Paso 3: Extraer y usar el panel de información de depuración

Haga clic en la pestaña Información en la página de Site Health. Este panel es posiblemente más valioso para la resolución de problemas que la pestaña de Estado porque expone datos de entorno sin procesar.

Secciones clave y qué buscar:

• WordPress — Confirma el tema activo, si el multisitio está habilitado y si WP_DEBUG está activo.
• Directorios y tamaños — Revela si wp-content/uploads/ ha crecido a un tamaño que está sobrecargando el I/O de disco o los procesos de copia de seguridad.
• Plugins activos — Lista todos los plugins activos con su versión. Compárelos con la Base de Datos de Vulnerabilidades de WordPress (wpscan.com) para CVEs conocidos.
• Servidor — Muestra la versión de PHP, el límite de memoria de PHP, el tamaño máximo de carga, el tiempo máximo de ejecución y si mod_rewrite o la reescritura de URL equivalente está activa.
• Base de datos — Confirma la versión de MySQL o MariaDB y el conjunto de caracteres de la base de datos. utf8mb4 es necesario para soporte completo de emojis y multilingüe; utf8 (3 bytes) truncará silenciosamente ciertos caracteres.
• Plugins de uso obligatorio — A menudo ignorados. Los plugins MU se cargan antes que todos los demás plugins y no pueden desactivarse desde la interfaz de administración. Si un proveedor de alojamiento ha inyectado un plugin MU (común en el alojamiento administrado), aparece aquí.

Uso práctico del botón “Copiar información del sitio al portapapeles”:

Al abrir un ticket de soporte o publicar en un foro de desarrolladores, pegue este resultado directamente. Elimina el intercambio de preguntas básicas sobre el entorno y permite a los ingenieros experimentados detectar anomalías de configuración de inmediato, por ejemplo, un memory_limit de 40M cuando WooCommerce requiere un mínimo de 128M, o un max_execution_time de 30 segundos cuando un proceso de importación grande requiere 300.

Paso 4: Usar el plugin Health Check & Troubleshooting para depuración en modo seguro

El plugin Health Check & Troubleshooting (disponible gratuitamente en el repositorio de plugins de WordPress) habilita un modo seguro aislado por sesión. Este es el método correcto para diagnosticar conflictos de plugins y temas en un sitio de producción en vivo.

Cómo funciona técnicamente el aislamiento de sesión:

El plugin establece una cookie de navegador que WordPress lee en cada solicitud. Cuando la cookie está presente, WordPress carga solo el tema predeterminado y desactiva todos los plugins no esenciales, pero *solo para la sesión del navegador que lleva esa cookie*. Todos los demás visitantes experimentan el sitio exactamente como estaba antes. Esto no es un entorno de staging; es un filtro de tiempo de ejecución aplicado en el nivel de arranque de WordPress.

Instalación y activación:

# If you have WP-CLI available on your server (recommended)
wp plugin install health-check --activate

O navegue a Plugins > Añadir nuevo, busque “Health Check & Troubleshooting” y haga clic en Instalar ahora, luego en Activar.

Ejecutar una sesión de resolución de problemas:

1. Vaya a Herramientas > Site Health y haga clic en la pestaña Resolución de problemas.
2. Haga clic en Habilitar modo de resolución de problemas. Su sesión ahora se ejecuta con todos los plugins desactivados y el tema predeterminado activo (Twenty Twenty-Four a partir de WordPress 6.5+).
3. Reproduzca el problema. Si ha desaparecido, un plugin o tema es el responsable.
4. Vuelva a habilitar los plugins uno a uno usando la lista de plugins de la pestaña de Resolución de problemas. Después de habilitar cada uno, recargue la página afectada y pruebe.
5. Una vez que el problema reaparezca, el último plugin que habilitó es la fuente del conflicto.
6. Haga clic en Deshabilitar modo de resolución de problemas para restaurar el entorno de producción completo.

Casos límite y errores comunes:

• Si el problema persiste incluso en modo seguro (sin plugins, tema predeterminado), el problema está a nivel del servidor o del núcleo de WordPress, no es un conflicto de plugins. Compruebe php_error.log y el registro de depuración de WordPress a continuación.
• Los plugins MU no se desactivan en modo seguro. Si sospecha de un plugin MU, debe renombrarlo manualmente en wp-content/mu-plugins/ mediante SFTP o SSH.
• La cookie de resolución de problemas es específica del navegador. Si está probando en móvil, necesita habilitar el modo de resolución de problemas en esa sesión del navegador por separado.

Paso 5: Diagnosticar y resolver conflictos de plugins y temas

Los conflictos de plugins se dividen en dos categorías que requieren diferentes estrategias de resolución:

Tipo 1: Conflictos directos de PHP — Dos plugins intentan definir la misma función o clase. Esto produce un error fatal de inmediato. El registro de errores contendrá Cannot redeclare function o Cannot redeclare class.

Tipo 2: Conflictos de comportamiento silenciosos — Dos plugins se enganchan en la misma acción o filtro de WordPress y producen salida inesperada o corrupción de datos sin generar un error. Estos son significativamente más difíciles de diagnosticar y requieren un aislamiento metódico uno por uno.

Flujo de trabajo de resolución:

# Check the WordPress debug log for fatal errors
tail -n 100 /path/to/wp-content/debug.log

# Enable WP_DEBUG temporarily via wp-config.php if debug.log is empty
# Add these lines to wp-config.php before the "stop editing" comment:
# define('WP_DEBUG', true);
# define('WP_DEBUG_LOG', true);
# define('WP_DEBUG_DISPLAY', false);

Cuando un plugin es la fuente confirmada del conflicto:

1. Compruebe el registro de cambios del plugin para ver si hay una actualización reciente que aborde el conflicto.
2. Busque en el foro de soporte del plugin en wordpress.org informes del mismo conflicto.
3. Si no hay ninguna corrección disponible, identifique un plugin alternativo con funcionalidad equivalente.
4. Si el plugin es crítico para el negocio, contacte al autor del plugin con el error específico de su registro de depuración, incluyendo su versión de PHP, versión de WordPress y el nombre y versión del plugin en conflicto.

Paso 6: Actualizar las versiones de PHP y del servidor de base de datos

Esta es la acción de mantenimiento de mayor impacto tanto para el rendimiento como para la seguridad. PHP 8.1 y 8.2 ofrecen mejoras de rendimiento medibles sobre PHP 7.4; los benchmarks muestran consistentemente una ejecución un 20–30% más rápida para cargas de trabajo típicas de WordPress debido a la compilación JIT y el comportamiento mejorado de OPcache.

Matriz de compatibilidad de versiones de PHP para WordPress:

Actualización de PHP mediante cPanel (para entornos de VPS con cPanel):

1. Inicie sesión en WHM (acceso root) o cPanel (nivel de usuario, si MultiPHP Manager está habilitado).
2. Navegue a MultiPHP Manager en la sección de Software.
3. Seleccione su dominio y elija la versión de PHP de destino en el menú desplegable.
4. Haga clic en Aplicar.

Actualización de PHP mediante la línea de comandos (Ubuntu/Debian):

# Add the Ondrej PHP PPA (Ubuntu)
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Install PHP 8.2 with common WordPress extensions
sudo apt install php8.2 php8.2-mysql php8.2-curl php8.2-gd php8.2-mbstring 
  php8.2-xml php8.2-zip php8.2-intl php8.2-bcmath php8.2-imagick

# Switch the CLI default (if using WP-CLI)
sudo update-alternatives --set php /usr/bin/php8.2

Paso crítico previo a la actualización: Antes de cambiar la versión de PHP en producción, pruebe su tema y cada plugin activo con la nueva versión. Use WP-CLI en un entorno de staging:

wp core check-update
wp plugin list --update=available --format=table
wp theme list --update=available --format=table

Consideraciones sobre la versión de la base de datos:

WordPress requiere MySQL 5.7+ o MariaDB 10.3+. MariaDB 10.6 y 10.11 (LTS) son las versiones recomendadas actualmente. Ejecutar una versión más antigua del servidor de base de datos introduce tanto exposición de seguridad como mejoras del optimizador de consultas que afectan a sitios con tablas de publicaciones grandes o volúmenes de pedidos de WooCommerce.

-- Check current database version from within WordPress or phpMyAdmin
SELECT VERSION();

-- Check table storage engines (InnoDB is required for full-text search and transactions)
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_wordpress_database';

Si alguna tabla muestra MyISAM como motor, conviértalas a InnoDB para una mejor recuperación ante fallos y rendimiento de escritura concurrente:

ALTER TABLE wp_options ENGINE=InnoDB;

Paso 7: Medir y optimizar el rendimiento del sitio

Site Health no mide el rendimiento del front-end; eso requiere herramientas externas. Use Google PageSpeed Insights (mide los Core Web Vitals en condiciones del mundo real), GTmetrix (análisis de cascada) y WebPageTest (múltiples ubicaciones, configuración avanzada) como herramientas complementarias.

Optimización del rendimiento por capa:

Capa del servidor:

• Habilite OPcache para el caché de bytecode de PHP. En un VPS correctamente configurado, esto por sí solo reduce el tiempo de ejecución de PHP en un 40–60%.

; Add to php.ini or a custom .ini file
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit_buffer_size=100M
opcache.jit=1255

• Use Redis para el caché de objetos persistente. Instale el paquete redis-server y el plugin de WordPress Redis Object Cache, luego añada a wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

Capa de aplicación:

• Optimización de imágenes — Use el formato WebP con alternativas JPEG/PNG. Los plugins Imagify o ShortPixel gestionan la conversión masiva y la entrega automática de WebP mediante reglas de reescritura de .htaccess.
• Carga diferida — WordPress 5.5+ añade loading="lazy" a las imágenes automáticamente, pero verifique que su tema no lo esté anulando.
• Optimización de la base de datos — Ejecute OPTIMIZE TABLE en tablas de alta rotación (wp_options, wp_postmeta) mensualmente. El plugin WP-Optimize automatiza esto.

# Optimize all WordPress tables via WP-CLI
wp db optimize

• Plugins de caché — W3 Total Cache con backend Redis o WP Rocket (premium) son las dos opciones más capaces. Evite ejecutar dos plugins de caché simultáneamente; entrarán en conflicto.

Integración de CDN:

Un CDN descarga la entrega de activos estáticos y reduce el TTFB para visitantes distribuidos geográficamente. El nivel gratuito de Cloudflare proporciona funcionalidad CDN adecuada para la mayoría de los sitios. Para sitios con muchos medios, BunnyCDN ofrece mejor rendimiento por precio. Configure su CDN para almacenar en caché los activos estáticos de forma agresiva, pero excluya el panel de administración de WordPress (/wp-admin/) y cualquier endpoint dinámico.

Paso 8: Reforzar la seguridad y establecer una rutina de monitoreo de vulnerabilidades

La seguridad no es una configuración única; es una práctica operativa continua. La herramienta Site Health detecta algunos problemas de seguridad, pero no realiza análisis de vulnerabilidades.

Enfoque de seguridad por capas:

A nivel del servidor (requiere acceso a VPS o servidor dedicado):

# Disable XML-RPC if not required (common attack vector for brute force amplification)
# Add to .htaccess
# <Files xmlrpc.php>
#   Order Deny,Allow
#   Deny from all
# </Files>

# Restrict wp-config.php access
chmod 600 /path/to/wp-config.php

# Verify file permissions across the WordPress installation
find /path/to/wordpress/ -type f -name "*.php" -perm /022
# Any PHP file writable by group or world is a security risk

A nivel de aplicación:

• Wordfence Security — Proporciona un Firewall de Aplicaciones Web (WAF), escáner de malware y fuente de inteligencia de amenazas en tiempo real. El nivel gratuito es suficiente para la mayoría de los sitios; el nivel premium añade actualizaciones de reglas de firewall en tiempo real.
• Limitar intentos de inicio de sesión — El plugin Limit Login Attempts Reloaded o la protección integrada contra fuerza bruta de Wordfence. Configure el bloqueo después de 3–5 intentos fallidos.
• Autenticación de dos factores — Aplique 2FA para todas las cuentas de administrador usando los plugins WP 2FA o Google Authenticator.
• Aplicación de SSL/HTTPS — Cada sitio de WordPress debe ejecutarse sobre HTTPS. Obtenga e instale un certificado SSL; si necesita uno, los Certificados SSL de su proveedor de alojamiento son la opción más sencilla. Añada lo siguiente a wp-config.php para forzar HTTPS a nivel de aplicación:

define('FORCE_SSL_ADMIN', true);

Y en .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Monitoreo automatizado de vulnerabilidades:

Suscríbase a las alertas por correo electrónico de la Base de Datos de Vulnerabilidades de WPScan para los plugins que utiliza. La herramienta CLI de WPScan puede integrarse en un cron job para alertarle cuando se publique un nuevo CVE para cualquier plugin instalado:

# Install WPScan (requires Ruby)
gem install wpscan

# Run a vulnerability scan against your site
wpscan --url https://yourdomain.com --api-token YOUR_API_TOKEN 
  --enumerate vp,vt,u --plugins-detection aggressive

Copias de seguridad de la base de datos como control de seguridad:

Una copia de seguridad limpia y reciente es su mecanismo de recuperación más confiable después de un compromiso. Automatice las copias de seguridad diarias en una ubicación fuera del servidor (almacenamiento de objetos compatible con S3, SFTP remoto). El plugin UpdraftPlus gestiona esto de manera confiable. Verifique los procedimientos de restauración trimestralmente; una copia de seguridad que nunca ha probado no es una copia de seguridad.

Verificación de salud de WordPress: Matriz de decisiones y conclusiones clave

Use esta matriz para determinar la acción correcta según lo que reporta Site Health:

Lista de verificación operativa para la salud continua de WordPress:

• Ejecute la revisión del estado de Site Health mensualmente; trate los hallazgos Críticos como incidentes.
• Mantenga PHP en una versión compatible (mínimo 8.1; preferiblemente 8.2 o 8.3).
• Elimine los plugins y temas inactivos; no los desactive simplemente.
• Habilite el caché de objetos Redis en cualquier sitio con más de 500 visitantes diarios.
• Automatice las copias de seguridad diarias de la base de datos fuera del servidor con pruebas de restauración verificadas.
• Suscríbase a alertas de vulnerabilidades para cada plugin y tema en su stack.
• Aplique HTTPS en todo el sitio y establezca FORCE_SSL_ADMIN en wp-config.php.
• Use WP-CLI para actualizaciones masivas y operaciones de base de datos; es más rápido y scriptable.
• En un Servidor Dedicado o VPS, configure un cron job del lado del servidor en lugar de depender de wp-cron; wp-cron solo se activa cuando un visitante accede al sitio, lo que lo hace poco confiable en sitios de bajo tráfico.

# Replace wp-cron with a real cron job (add to crontab)
# First, disable wp-cron in wp-config.php:
# define('DISABLE_WP_CRON', true);

# Then add to crontab (crontab -e):
*/15 * * * * php /path/to/wordpress/wp-cron.php > /dev/null 2>&1
# Or with WP-CLI (preferred):
*/15 * * * * wp --path=/path/to/wordpress cron event run --due-now > /dev/null 2>&1

Si está evaluando entornos de alojamiento para un despliegue de WordPress, los Paneles de Control VPS proporcionan el acceso a nivel de servidor necesario para implementar cada optimización y medida de seguridad descrita en esta guía; la gestión de versiones de PHP, la configuración de Redis, el cron del lado del servidor y las reglas del firewall requieren acceso root o sudo que los entornos compartidos no proporcionan.

Preguntas frecuentes

¿Cuál es la diferencia entre la pestaña Estado y la pestaña Información de Site Health?

La pestaña Estado ejecuta verificaciones automatizadas y categoriza los hallazgos por gravedad (Bueno, Recomendado, Crítico). La pestaña Información muestra datos de entorno sin procesar, como la configuración de PHP, los plugins activos con versiones, los detalles de la base de datos y los tamaños de los directorios, sin ningún juicio de aprobado/reprobado. La pestaña Información se utiliza principalmente para el diagnóstico manual y para compartir con ingenieros de soporte.

¿Habilitar el modo de resolución de problemas afecta a los visitantes en vivo?

No. El modo de resolución de problemas usa una cookie de navegador para aplicar el entorno de modo seguro exclusivamente a su sesión. Los visitantes sin la cookie experimentan el sitio con normalidad. La única excepción es si un error fatal en un plugin está bloqueando el proceso del servidor en sí; en ese caso, todos los visitantes se ven afectados independientemente del estado de activación del plugin en su sesión.

¿Qué versión de PHP debo usar para WordPress en 2025?

PHP 8.2 es la versión recomendada para sitios de WordPress en producción en 2025. Se mantiene activamente con parches de seguridad, ofrece mejoras de rendimiento medibles sobre 8.0 y 8.1, y es compatible con todos los principales plugins de WordPress. PHP 8.3 es estable y adecuado para nuevos despliegues, pero verifique la compatibilidad de los plugins antes de actualizar un sitio existente.

¿Por qué Site Health reporta “Bueno” cuando mi sitio es claramente lento?

Site Health verifica la configuración y la postura de seguridad; no mide métricas de rendimiento del front-end como el Largest Contentful Paint (LCP) o el Time to First Byte (TTFB). Un sitio puede pasar todas las verificaciones de Site Health y aun así obtener una puntuación baja en los Core Web Vitals debido a imágenes no optimizadas, ninguna capa de caché, una base de datos lenta o un servidor geográficamente distante. Use Google PageSpeed Insights o WebPageTest para medir el rendimiento.

¿Cómo soluciono un fallo en la solicitud de bucle invertido en WordPress Site Health?

Un fallo de bucle invertido significa que WordPress no puede hacer una solicitud HTTP a su propia URL desde el servidor. Las causas comunes incluyen: un firewall que bloquea las conexiones salientes del proceso del servidor web, una entrada en el archivo hosts que enruta incorrectamente el dominio, un error de certificado SSL en la solicitud de bucle invertido o un plugin de seguridad que bloquea la solicitud. Comience deshabilitando temporalmente su plugin de seguridad y vuelva a ejecutar Site Health. Si eso lo resuelve, incluya en la lista blanca la IP del propio servidor en la configuración del firewall del plugin de seguridad.