Errores de WordPress que tumban tu web: guía para diagnosticarlos y arreglarlos

Respuesta corta: casi todos los errores de WordPress que tumban una web caen en seis tipos: error crítico, fallo de conexión con la base de datos, modo mantenimiento atascado, pantalla blanca, «Fatal error» o «Parse error» de PHP, y errores 500 o 503 del servidor. Para todos funciona el mismo método: mira el código HTTP, lee el log de errores, piensa qué cambió por última vez y desactiva el plugin o tema culpable por FTP, SSH o wp-cli.

Por qué aparecen los errores de WordPress (y por qué casi siempre es lo mismo)

WordPress es un núcleo pequeño al que se le suman plugins, un tema, una versión de PHP y un servidor de base de datos. Cada pieza se actualiza por su cuenta y la mayoría las escribe gente distinta. Cuando algo falla, el origen suele ser uno de estos:

1. Una actualización de plugin, tema o núcleo que no encaja con el resto.
2. Un cambio en el servidor: nueva versión de PHP, migración, límites de memoria, disco lleno.
3. Una edición manual: código pegado en functions.php, un .htaccess tocado, wp-config.php modificado.
4. Carga: picos de tráfico, bots atacando el acceso o tareas pesadas que saturan PHP o MySQL.
5. Algo externo: la base de datos en otro servidor, una caché o CDN, un servicio de terceros.

Por eso la pregunta más útil cuando algo se rompe no es «qué es este error», sino «qué ha cambiado». La respuesta suele estar en las últimas 24 horas.

Qué error tienes: tabla rápida

Hay otros fallos que no tumban la web entera pero hacen daño: Google que deja de indexarla (lo cubrimos en «Disuadir a los motores de búsqueda») o spam inyectado tras un hackeo (limpiar una web hackeada).

Las herramientas que necesitas tener a mano

Cuando la web está caída no puedes entrar al escritorio, así que necesitas llegar a los ficheros y a la base de datos por otro camino. Antes de tener un problema, comprueba que tienes al menos dos de estas vías.

Acceso a los ficheros

• SFTP o FTP (FileZilla, Cyberduck, WinSCP). Los datos los da el hosting. Activa «mostrar archivos ocultos» para ver .htaccess y .maintenance.
• Gestor de archivos del panel (cPanel, Plesk, DirectAdmin). Más lento, pero no necesitas instalar nada.
• SSH. La vía más rápida si tu hosting la ofrece. Con SSH tienes también wp-cli.

wp-cli

La herramienta oficial de línea de comandos de WordPress. Muchos hostings la traen instalada. Te permite actuar aunque el escritorio no cargue:

wp plugin list --status=active
wp plugin deactivate nombre-del-plugin --skip-plugins --skip-themes
wp theme activate twentytwentyfour --skip-plugins --skip-themes
wp maintenance-mode deactivate
wp db check
wp core verify-checksums

Las opciones --skip-plugins --skip-themes son la clave: hacen que wp-cli no cargue el código que está roto.

El registro de errores

WordPress puede guardar sus errores en wp-content/debug.log, como explica la guía oficial de depuración de WordPress. Se activa en wp-config.php, antes de la línea «¡Eso es todo, deja de editar!»:

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

Con WP_DEBUG_DISPLAY en false el error se guarda pero no se enseña a los visitantes. Si el problema es anterior a WordPress (servidor, .htaccess, PHP-FPM), mira el log del servidor: en el panel aparece como «Error log» o «Registros».

El modo de recuperación

Desde WordPress 5.2, cuando un plugin o tema provoca un error fatal, WordPress envía un correo a la dirección de administración con un enlace para entrar en modo de recuperación: el culpable queda pausado solo para ti y puedes desactivarlo desde el escritorio. Comprueba hoy que esa dirección (Ajustes > Generales) es de alguien que la lee y que tu WordPress envía correo.

Copias de seguridad

Una copia reciente, fuera del servidor, de ficheros y base de datos. No es la primera herramienta (antes hay que entender qué pasa), pero es la red que te permite actuar sin miedo.

Un método para diagnosticar cualquier error de WordPress

Este es el orden que seguimos nosotros con los errores de WordPress. Funciona aunque no sepas qué error es.

1. Confirma qué ve el visitante

Abre la web en una ventana privada y mira el código HTTP:

curl -sI https://tuweb.com/ | head -n 1

Prueba también una URL interior, /wp-admin/ y /wp-login.php. Si solo falla una parte, la causa está en el código que carga esa parte.

2. Descarta la caché

Muchos plugins de caché sirven la página sin caché a los administradores. Puedes estar viendo la web bien y tus visitantes, no; o al revés. Prueba con ?nocache=1 al final de la URL y en una ventana privada.

3. Lee el error de verdad

El mensaje en pantalla casi nunca es suficiente. Busca el correo de recuperación, el debug.log o el log del servidor. Una línea como esta:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function() in /var/www/html/wp-content/plugins/plugin-antiguo/widget.php:41

ya te dice el plugin («plugin-antiguo»), el fichero y la línea.

4. Pregunta qué cambió

Actualizaciones automáticas de anoche, un cambio de PHP del hosting, un plugin nuevo, una edición de un compañero. Si el log no es claro, el último cambio es tu principal sospechoso.

5. Aísla: plugins, tema, servidor

Desactiva el plugin sospechoso. Si no sabes cuál, desactívalos todos (wp plugin deactivate --all --skip-plugins --skip-themes o renombrando wp-content/plugins). Si vuelve, reactiva uno a uno. Si no, cambia al tema por defecto. Si tampoco, el problema es del servidor: PHP, base de datos, disco, .htaccess.

6. Arregla la causa y deja todo limpio

Actualiza o sustituye el plugin, corrige el código, ajusta el servidor. Después: WP_DEBUG a false, borra debug.log, quita cualquier fichero temporal que hayas subido y vacía la caché.

7. Apunta qué pasó

Una línea en un documento: fecha, síntoma, causa, solución. La segunda vez que ocurra, la tendrás resuelta en cinco minutos.

Los seis errores, uno a uno

«Ha habido un error crítico en esta web»

Es la forma moderna de un error fatal de PHP. WordPress lo intercepta para no enseñar rutas y te manda un correo de recuperación. Causa típica: un plugin incompatible tras una actualización o tras subir PHP. Lo explicamos en la guía del error crítico.

«Error al establecer una conexión con la base de datos»

WordPress no puede hablar con MySQL o MariaDB. Primero las credenciales de wp-config.php; después, si el servidor de base de datos está vivo, saturado o sin disco; por último, tablas dañadas. Todo en la guía de la conexión con la base de datos.

«No disponible temporalmente por mantenimiento programado»

Lo provoca el fichero .maintenance que WordPress crea al actualizar. WordPress lo ignora pasados diez minutos, así que si persiste hay algo más: la caché, un proceso que lo regenera o un plugin de mantenimiento. Paso a paso en la guía del modo mantenimiento.

Pantalla blanca

Una página vacía sin mensaje: error de PHP antes de que WordPress lo capture, memoria agotada, un drop-in de caché roto o una caché que guardó una página vacía. El código HTTP te orienta. Lo tienes en la guía de la pantalla blanca.

«Fatal error» y «Parse error»

El error de PHP en bruto, visible porque el servidor muestra errores. Te dice exactamente el fichero y la línea, y al mismo tiempo enseña información interna a cualquiera. Cómo leerlos en la guía de Fatal error y Parse error.

Error 500 y error 503

Códigos del servidor. El 500 es un fallo al generar la página (PHP, .htaccess, permisos); el 503, que el servidor no puede atender (mantenimiento, PHP saturado, límites del hosting). La diferencia y la solución, en la guía del error 500 y 503.

Cómo evitar que vuelva

Ninguna web está libre de fallos, pero la mayoría de los errores de WordPress se pueden evitar o acortar:

• Actualiza por tandas y con copia previa. Si actualizas todo a la vez y algo falla, no sabrás qué fue.
• Prueba en un entorno de pruebas los cambios grandes: versión de PHP, constructor de páginas, WooCommerce.
• Elimina plugins que no uses o que nadie mantiene. Son los que fallan al subir PHP.
• No edites en producción desde el editor de temas. Usa un tema hijo y un plugin de fragmentos.
• No muestres errores al público. display_errors en Off y WP_DEBUG_DISPLAY en false.
• Comprueba el correo de administración y que el servidor envía correo: el modo de recuperación depende de ello.
• Documenta los accesos (SFTP, SSH, panel, base de datos) en un gestor de contraseñas. Buscar credenciales con la web caída es tiempo perdido.
• Vigila la web desde fuera. Si el primer aviso es la llamada del cliente, ya llevas horas caído.

Para agencias: cómo te avisa Jeffrey de estos errores

Cuando gestionas decenas de webs, el problema no es arreglar el error: es enterarte a tiempo. Un monitor que solo comprueba que el servidor contesta no ve una pantalla blanca que devuelve 200, ni un error crítico en la ficha de producto mientras la portada funciona.

Jeffrey combina dos vigilancias:

• Disponibilidad cada uno o dos minutos. Comprueba la portada; un error de red o una respuesta 500 o superior cuenta como fallo. Con tres muestras fallidas seguidas abre un aviso urgente («La web da error» con el código, o «La web no responde») y lo cierra con la primera respuesta correcta.
• Pruebas diarias con navegador real, en móvil y en escritorio, sobre hasta cinco páginas: la portada, las que tú marques, las dos que más visitas reciben desde Google, la de contacto y una de producto. Detecta en pantalla «Ha habido un error crítico en esta web», «Error al establecer una conexión con la base de datos», «No disponible temporalmente por mantenimiento», los «Fatal error» y «Parse error» de PHP y las páginas en blanco. También avisa si una página devuelve un error, o si desaparece el formulario de contacto o el botón de comprar que había en la última prueba buena.

Antes de avisar, la prueba se repite a los cinco minutos para no despertarte por un fallo momentáneo. Si se confirma, recibes un aviso urgente con la URL, el dispositivo y lo que ha visto. Con el plugin de Jeffrey instalado, las pruebas se lanzan también un par de minutos después de cada actualización de plugins, tema o núcleo, y el aviso dice qué actualización lo provocó. Las pruebas no envían formularios ni hacen compras. Si el cortafuegos de una web bloquea a nuestro navegador, Jeffrey no da la prueba por buena ni por mala: te lo indica para que lo permitas.

Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Preguntas frecuentes