Respuesta corta: cuando aparece un fatal error en WordPress o un «Parse error» de PHP, el mensaje te dice el tipo de fallo, el fichero y la línea. La ruta indica el culpable: si contiene
wp-content/plugins/nombre, es ese plugin; si contienewp-content/themes/nombre, es el tema. Desactívalo por FTP o wp-cli, corrige o deshaz el cambio y, sobre todo, deja de mostrar errores a los visitantes.
Qué significan estos errores
PHP es el lenguaje en el que está escrito WordPress. Cuando PHP encuentra un problema que no puede saltarse, detiene la ejecución: eso es lo que ves como fatal error en WordPress. Si el servidor tiene activado display_errors (o tienes WP_DEBUG y WP_DEBUG_DISPLAY en true), el error se imprime en pantalla. Si no, WordPress suele enseñar «Ha habido un error crítico en esta web» y el detalle queda en los logs.
Hay dos familias:
- Parse error (error de sintaxis): el código está mal escrito y PHP ni siquiera puede leerlo. Una llave sin cerrar, un punto y coma que falta, unas comillas mal puestas. Casi siempre es una edición manual reciente.
- Fatal error: el código se puede leer, pero al ejecutarse hace algo imposible: llamar a una función que no existe, quedarse sin memoria, pasar un tipo de dato incorrecto. Suele venir de actualizaciones o de cambios de versión de PHP.
Cómo leer el mensaje
Un ejemplo típico:
Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /home/cuenta/public_html/wp-content/plugins/galeria-vieja/includes/db.php:27
Stack trace:
#0 /home/cuenta/public_html/wp-content/plugins/galeria-vieja/galeria.php(15): require_once()
#1 /home/cuenta/public_html/wp-settings.php(526): include_once('/home/cuenta/...')Léelo por partes:
- Tipo:
Fatal error. - Qué pasó:
Call to undefined function mysql_connect(). Esa función se eliminó en PHP 7; el plugin es antiguo. - Dónde:
wp-content/plugins/galeria-vieja/includes/db.php, línea 27. El culpable es el plugin «galeria-vieja». - Stack trace: el camino que siguió PHP hasta el error. Útil cuando el fallo ocurre dentro del núcleo, pero lo ha provocado un plugin: busca la primera línea con
wp-content/pluginsowp-content/themes.
Si el error aparece en un fichero del núcleo (wp-includes o wp-admin) y en el stack trace no hay ningún plugin ni tema, sospecha de una actualización del núcleo incompleta o de ficheros modificados.
Los errores más comunes y qué hacer con cada uno
| Mensaje | Qué significa | Qué hacer |
|---|---|---|
Parse error: syntax error, unexpected ... | Código mal escrito | Deshacer la última edición en ese fichero |
Call to undefined function | Función que no existe en tu versión de PHP o de un plugin desactivado | Actualizar el plugin o reactivar el que la define |
Allowed memory size of N bytes exhausted | Memoria de PHP agotada | Subir WP_MEMORY_LIMIT y buscar qué consume |
Maximum execution time of 30 seconds exceeded | El script tarda demasiado | Revisar el proceso (importación, copia) o subir max_execution_time |
Cannot redeclare función() | Dos plugins o el tema definen la misma función | Desactivar uno; suele pasar con plugins duplicados o un tema hijo copiado mal |
Class "X" not found | Falta una clase: plugin incompleto o dependencia desactivada | Reinstalar el plugin o activar la dependencia (p. ej. WooCommerce) |
Uncaught TypeError: ... must be of type array, null given | Error de tipos, frecuente tras subir a PHP 8 | Actualizar el plugin o el tema |
Ojo: los Warning, Notice y Deprecated no paran la web. Si los ves en pantalla, el problema es que se están mostrando errores, no que la web esté rota. Pero un Deprecated de hoy puede ser el Fatal error de la próxima versión de PHP.
Cómo arreglar un fatal error en WordPress paso a paso
Paso 1: deja de mostrar los errores al público
Mostrar errores en producción enseña rutas del servidor y nombres de ficheros a cualquiera, y Google puede indexarlos. En wp-config.php (lo detalla la documentación oficial de depuración de WordPress):
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Así sigues registrando el error en wp-content/debug.log, pero el visitante no lo ve. Puedes mandar el log fuera de la carpeta pública indicando una ruta en lugar de true:
define( 'WP_DEBUG_LOG', '/home/cuenta/logs/wp-debug.log' );Paso 2: desactiva el culpable
Con la ruta del error ya sabes qué es. Con wp-cli:
wp plugin deactivate galeria-vieja --skip-plugins --skip-themesPor FTP o gestor de archivos, renombra la carpeta wp-content/plugins/galeria-vieja a galeria-vieja.off. Si es el tema, actívate uno por defecto:
wp theme activate twentytwentyfour --skip-plugins --skip-themesPaso 3: si es un Parse error, deshaz la edición
El caso típico: alguien pegó un fragmento en functions.php desde el editor de temas o por FTP. Descarga el fichero, ve a la línea que indica el error (o a la anterior: muchas veces el fallo está justo antes) y corrige o elimina el fragmento. Antes de subirlo, compruébalo:
php -l functions.phpSi no tienes PHP en tu ordenador, súbelo y ejecuta lo mismo por SSH. Para fragmentos de código, usa mejor un plugin de fragmentos o un plugin propio: un error ahí no tumba el tema.
Paso 4: si es un Fatal error, ataca la causa
- Tras subir PHP: actualiza el plugin. Si no tiene versión compatible, vuelve a la versión de PHP anterior desde el panel mientras lo sustituyes. Comprueba tu versión con
php -vpor SSH o en Herramientas > Salud del sitio > Información > Servidor. - Memoria agotada: añade
define( 'WP_MEMORY_LIMIT', '256M' );. Si el límite real de PHP del hosting es más bajo, no lo supera. Si un plugin agota 256 MB en una página normal, el problema es el plugin. - Plugin incompleto: reinstala la misma versión con
wp plugin install nombre --force. - Dependencia: si un complemento de WooCommerce dice que falta una clase, WooCommerce está desactivado o desactualizado.
- Ficheros del núcleo:
wp core verify-checksumste dice si alguno no coincide con el oficial.
Paso 5: limpia
Vuelve a dejar WP_DEBUG en false y borra wp-content/debug.log cuando termines. Ese fichero queda accesible por URL en muchos servidores.
Cómo evitar que vuelva
- No edites ficheros en producción desde el editor de temas. Desde WordPress 4.9 el editor intenta revertir cambios que rompen la web, pero no por FTP.
- Prueba los cambios de PHP en un entorno de pruebas antes de aplicarlos.
- Revisa Salud del sitio de vez en cuando: avisa de versiones de PHP antiguas y de plugins inactivos.
- Elimina plugins abandonados: son la principal fuente de errores al subir PHP.
- Configura display_errors en Off en el PHP del hosting para producción, no solo en WordPress.
Para agencias: que el error no lo vea Google antes que tú
Un «Fatal error» en pantalla tiene dos problemas: la página no funciona y además expone rutas internas del servidor a cualquiera.
Jeffrey hace cada día una prueba con un navegador real, en móvil y en escritorio, sobre hasta cinco páginas de cada web (portada, las que elijas, las dos más visitadas desde Google, contacto y producto). Si en el texto de la página aparece un «Fatal error» o un «Parse error» seguido de la línea del fallo, lo marca como «Error fatal de PHP en pantalla». Repite la prueba a los cinco minutos y, si se confirma, te avisa como error urgente con la URL y el dispositivo. Con el plugin de Jeffrey instalado, la prueba se lanza también un par de minutos después de cada actualización, y el aviso dice cuál fue. Aparte, una vez al día comprueba si el debug.log de WordPress se puede descargar desde fuera, y te avisa si es así.
Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.
Más en la guía de errores de WordPress que tumban tu web y en la del error crítico de WordPress.
Preguntas frecuentes
¿Qué diferencia hay entre «Fatal error» y «Ha habido un error crítico en esta web»?
Es el mismo problema mostrado de dos formas. Si el servidor enseña errores, ves el «Fatal error» con la ruta. Si no, WordPress lo intercepta y enseña el mensaje genérico del error crítico.
La línea que indica el error está bien, ¿dónde está el fallo?
En los «Parse error», PHP señala dónde se dio cuenta, que suele ser después del fallo real. Revisa las líneas anteriores: una llave o un paréntesis sin cerrar unas líneas antes es lo más habitual.
¿Puedo ignorar los «Deprecated» y los «Warning»?
No rompen la web hoy, así que no son urgentes, pero no los ignores del todo. Indican código que dejará de funcionar en una versión futura de PHP. Y nunca deberían verse en pantalla en producción.
¿Es seguro subir el límite de memoria?
Sí, dentro de lo razonable. 256 MB es suficiente para la mayoría de webs, incluidas tiendas WooCommerce. Si necesitas mucho más en páginas normales, hay un plugin que consume de más.