Acabas de actualizar un plugin, vuelves a abrir la web y aparece «Ha habido un error crítico en esta web». O quizá no has tocado nada y te avisa alguien que está intentando comprar. En ambos casos, el mensaje tiene la delicadeza de decirte que algo va mal sin contarte qué.
La tentación es probar arreglos hasta que uno funcione. Cambiar PHP, desactivar cosas, restaurar una copia. El problema es que, si haces todo a la vez, puedes recuperar la web y seguir sin saber qué ocurrió. O sumar una segunda avería a la primera.
Empieza por comprobar qué falla y buscar el correo de recuperación de WordPress. Si no llega, los registros del hosting y los cambios recientes ayudan a decidir el siguiente paso. Hay varias vías para recuperar el acceso; conviene elegir la que corresponda a tu caso.
Qué significa «Ha habido un error crítico en esta web»
El aviso indica que WordPress ha encontrado un fallo que le impide ejecutar correctamente una parte de la web. Suele estar relacionado con un error fatal de PHP, el lenguaje en el que funciona WordPress. Un plugin incompatible, el tema, un fragmento de código o un problema de recursos pueden estar detrás.
El mensaje no identifica por sí solo la causa ni demuestra que hayas perdido los contenidos. Tampoco significa necesariamente que todo esté caído. Puede fallar la parte pública, el administrador, una página concreta o una acción como finalizar un pedido.
Una pantalla blanca en WordPress puede ser otra forma de ver un fallo, pero no conviene dar por hecho que siempre es el mismo. El manual de errores de WordPress también contempla problemas de base de datos entre las posibles causas de una pantalla vacía.
Si lo que aparece es «404» o «página no encontrada», sigue otro recorrido. Ese síntoma tiene su propia guía de error 404 en WordPress. Aquí vamos a centrarnos en el error crítico y la pantalla blanca, sin mezclar sus arreglos.
Qué comprobar antes de intentar arreglar WordPress
Mira si puedes abrir la portada, otra página interior y /wp-admin/. Si el fallo aparece al realizar una acción, anota cuál. Una captura del mensaje, la hora aproximada y la dirección afectada son datos útiles cuando consultes el registro o pidas ayuda.
Después reconstruye lo que cambió. Cuando atendemos una incidencia, no nos quedamos solo con «yo no he tocado nada». Puede ser completamente cierto y haber habido una actualización automática, un cambio de PHP en el alojamiento o un ajuste realizado por otra persona. La pregunta útil es qué ha cambiado en la instalación.
Antes de modificar archivos, conserva una copia del estado actual y comprueba qué backups anteriores tienes. Aunque ahora la web falle, puede contener pedidos, formularios o cambios que no están en la copia de ayer. Guarda también la configuración original del archivo que vayas a editar.
A partir de aquí, haz un cambio cada vez y comprueba el resultado. Si no ayuda, vuelve al estado anterior antes de probar otra cosa. Así mantienes una pista de lo que funciona y una forma de deshacerlo. El diagnóstico ya tiene bastante trabajo sin añadirle una gincana.
Cómo entrar en WordPress con el modo de recuperación
Busca en el correo de administración de la web un mensaje de WordPress sobre un problema técnico. Revisa también spam. Puede incluir el componente afectado, detalles del error y un enlace especial para entrar en modo de recuperación.
La documentación oficial del modo de recuperación explica su alcance: puede pausar un plugin o tema problemático para tu sesión de administración, de modo que puedas entrar y trabajar. Recuperar esa sesión no significa que la web pública ya esté arreglada.
Si has recibido el correo, el recorrido es este:
- Abre su enlace de recuperación e inicia sesión con tu usuario administrador.
- Revisa el aviso que identifica el componente y los detalles del fallo.
- Desactiva el plugin señalado o corrige el cambio identificado. Si apunta al tema, prepara una alternativa compatible antes de cambiarlo.
- Sal del modo de recuperación y comprueba la web sin esa sesión, incluyendo la acción que fallaba.
Desactivar un componente puede recuperar el acceso sin resolver la causa de fondo. Si era el plugin de pagos, por ejemplo, la portada podría volver mientras la tienda sigue sin poder cobrar. Después habrá que corregir la incompatibilidad, aplicar una versión válida o buscar otra forma de mantener esa función.
Si no llega el mensaje, no intentes fabricar el enlace añadiendo parámetros a la URL de acceso. La recuperación utiliza un enlace validado. Continúa con los registros y el acceso al hosting.
Cómo solucionar el error crítico si no llega el correo
No recibir el correo no demuestra que el problema sea más grave. Puede fallar la entrega o producirse el error antes de que WordPress llegue a cargar el sistema que envía los mensajes.
Esto importa si utilizas un plugin SMTP. No puede ayudar a enviar ese aviso si el fallo ocurre antes de cargarlo. La entrega de correo merece una revisión propia, que explicamos en qué hacer cuando WordPress no envía correos. Mientras tanto, el hosting puede darte otra vía para investigar.
Revisar los registros de errores del hosting
Busca el registro de errores de PHP en el panel del alojamiento o pídeselo a soporte. La ubicación cambia según el proveedor. Compara sus entradas con la hora y la acción que has anotado; un aviso antiguo de otro día puede llevarte a perseguir al sospechoso equivocado.
Una ruta como wp-content/plugins/plugin-ejemplo/archivo.php orienta hacia ese componente. El nombre del archivo es una pista, no siempre el origen del problema: puede estar recibiendo datos o llamadas de otro componente incompatible.
Busca también el tipo de mensaje. Allowed memory size ... exhausted apunta a memoria agotada; un error de sintaxis tras editar código pide revisar ese cambio. No hace falta interpretar toda la traza para pedir ayuda. La hora, la acción y el mensaje completo suelen ser un buen comienzo.
Desactivar un plugin por SFTP sin borrarlo
Si el registro o el cambio reciente apunta a un plugin y no puedes entrar al administrador, puedes aislarlo desde el gestor de archivos del hosting o mediante SFTP, siempre que te manejes con esos accesos.
Dentro de wp-content/plugins, renombra únicamente la carpeta del plugin identificado, por ejemplo de plugin-ejemplo a plugin-ejemplo-inactivo. No la borres. Guarda su nombre original y vuelve a probar la acción que fallaba.
Si recuperas el acceso, entra en Plugins instalados y comprueba su estado antes de devolver el nombre a la carpeta. Reponerlo puede volver a cargar el componente si WordPress no había actualizado su lista de plugins activos. No lo reactives sin resolver o revisar lo que provocó el fallo.
Si no sabes qué plugin aislar, una prueba sin plugins puede ayudar, pero también desactiva formularios, pagos y otras funciones. Es preferible prepararla en una copia de pruebas o con asistencia técnica. Ir renombrando carpetas al azar hasta que vuelva la portada deja demasiadas preguntas abiertas.
Activar la depuración cuando los registros no bastan
WordPress dispone de herramientas de depuración, pero su documentación las orienta a entornos de prueba. Prioriza los registros existentes. Si necesitas generar más información, hazlo en una copia de pruebas o pide a un técnico una activación temporal y controlada.
Este es un ejemplo de configuración, no un bloque listo para pegar en cualquier hosting:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/RUTA_PRIVADA/wordpress-errores.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );/RUTA_PRIVADA/wordpress-errores.log es un marcador que hay que sustituir por una ruta válida, escribible y fuera del directorio público de la web. El hosting puede indicarte cuál. Ocultar los errores en pantalla no protege un archivo de registro que sea accesible por su URL.
Si ya existen esas constantes en wp-config.php, modifica sus valores en lugar de duplicarlas. Van antes de que se cargue WordPress, normalmente antes del comentario que indica que dejes de editar. true y false son booleanos, sin comillas. Guarda antes una copia del archivo: un error de sintaxis aquí puede añadir otro problema.
Tras reproducir el fallo, revisa la entrada nueva y desactiva la depuración cuando termines. Si no aparece un log, puede haber un problema de ruta, permisos o un fallo anterior a la carga de WordPress. La ausencia de registro no demuestra que todo esté bien.
Qué hacer si el fallo viene del tema, PHP o la memoria
Si los indicios apuntan al tema, prueba una alternativa compatible que esté instalada y disponible. Desde el administrador puedes activarla temporalmente, teniendo presente que cambiará la presentación y puede afectar a funciones de la web.
Sin acceso al panel, no borres el tema ni toda la carpeta themes. La vuelta a un tema por defecto no debe darse por garantizada sin comprobar qué hay instalado. Si no sabes cómo conservar las personalizaciones y recuperar el tema activo, pide ayuda para hacer esa prueba.
Con PHP, relaciona el error con los cambios recientes. Si la avería empezó tras cambiar su versión, revisa la compatibilidad del tema y los plugins. No elijas una versión antigua por tanteo ni saltes a otra sin comprobar requisitos. Recuperar temporalmente una configuración conocida puede formar parte del diagnóstico; la corrección debe quedar en una versión compatible y mantenida.
Con la memoria, actúa cuando el registro apunte a agotamiento. Un límite demasiado bajo puede necesitar un ajuste, pero también puede haber una operación desmesurada o código que consume memoria sin control. Poner un número mayor en WP_MEMORY_LIMIT no garantiza que el hosting permita ese límite ni arregla necesariamente la causa.
Si el error señala archivos que faltan o están dañados, revisa su integridad antes de reinstalar. Sobrescribir archivos del núcleo sin comprobar versión, copias y contenido no debería ser el siguiente experimento. Y si aparecen archivos desconocidos u otros indicios de intrusión, conserva las evidencias y escala el caso.
Cuándo restaurar una copia de seguridad o pedir ayuda
Restaurar una copia anterior al fallo puede ser la vía adecuada, sobre todo si necesitas recuperar el servicio y hay un punto conocido que funcionaba. Antes de hacerlo, comprueba de qué fecha es, qué incluye y qué datos han cambiado desde entonces.
En una tienda, restaurar toda la base de datos de ayer puede dejar fuera los pedidos de hoy. Lo mismo ocurre con nuevos usuarios, reservas o formularios guardados. Puede convenir recuperar solo archivos, restaurar primero en una copia de pruebas o planificar cómo conservar esos datos. La elección depende del fallo y del sistema; no hay un botón universal de «volver sin perder nada».
Pide ayuda si no puedes acceder al hosting, no entiendes el registro, faltan copias fiables o el fallo afecta a cobros y datos que no puedes arriesgar. No necesitas agotar todos los tutoriales antes de hacerlo. Reúne la URL afectada, la hora, el último cambio conocido y las pruebas que has realizado.
Que una copia haga desaparecer el error tampoco cierra por sí solo el diagnóstico. Si se repite la actualización o vuelve la operación que lo desencadenó, puede regresar. Recuperar el servicio y corregir el origen son dos tareas relacionadas.
Cómo comprobar que WordPress vuelve a funcionar
Cuando la web cargue, sal del modo de recuperación y prueba sin tu sesión de administrador. Repite la acción que fallaba y revisa si el registro añade errores nuevos. Si se mantiene una versión antigua en pantalla después de reparar, puede tocar borrar la caché de WordPress; eso no sustituye la corrección del fallo de PHP.
En nuestras revisiones comprobamos las funciones que sostienen el negocio, además de la portada. Formularios, acceso de usuarios y proceso de compra, según la web. Una página de inicio que carga bien no dice mucho sobre un pedido que se rompe al confirmar el pago. La compra de prueba debe hacerse de forma controlada, evitando cargos o notificaciones reales no previstos.
Anota qué cambió, qué componente falló y cómo quedó resuelto. Conserva una copia comprobada y revisa cómo se aplican las actualizaciones para reducir la posibilidad de repetir el incidente. Una web recuperada merece algo más que cerrar la pestaña con alivio.
Si necesitas que alguien revise el fallo, proteja los datos y compruebe la web después, es parte de nuestro trabajo de mantenimiento web. Cuéntanos qué ha pasado y qué has probado: partiremos de esas pistas para diagnosticar la causa y acordar la intervención necesaria.
Escrito en Nereida Studio, estudio de diseño web y posicionamiento en Valencia. Así trabajamos.
