¿Tu web en WordPress no carga? Aquí está la solución

Qué significa que WordPress no cargue y por qué ocurre

Cuando una web “no carga” puede referirse a situaciones distintas: el navegador no resuelve el dominio, el servidor responde con error (por ejemplo 500, 502, 503), aparece una pantalla en blanco, se muestra un mensaje de “Ha habido un error crítico”, o la página se queda cargando indefinidamente. En WordPress, estas señales suelen apuntar a un fallo en la cadena de ejecución: petición HTTP, capa de caché, PHP, consultas a base de datos, carga de plugins y tema, y finalmente renderizado.

La clave es no asumir una única causa. Un cambio aparentemente menor, como actualizar un plugin, activar una caché o modificar un registro DNS, puede destapar un límite de recursos, un conflicto de versiones o un error de configuración que ya estaba latente. Por eso conviene trabajar con trazabilidad: identificar qué cambió, cuándo empezó el fallo y qué evidencia técnica lo respalda.

• Distinga si el problema es de resolución (DNS), de conexión (TLS/SSL) o de aplicación (WordPress y PHP).
• Compruebe si afecta a todo el sitio o solo a rutas concretas (inicio, /wp-admin/, checkout, API).
• Determine si el fallo es intermitente o constante, y si coincide con picos de tráfico o tareas programadas.
• Separe síntoma de causa: un 503 puede ser mantenimiento real, saturación o un WAF bloqueando.
• Priorice minimizar el tiempo de caída: contención, copia y diagnóstico antes de “probar cosas”.

Diagnóstico inicial y señales útiles sin empeorar la caída

Antes de tocar archivos o desactivar componentes, conviene recopilar señales verificables. Esto reduce el riesgo de empeorar el problema y acelera la resolución. Empiece por observar qué devuelve el servidor y si el fallo se reproduce desde distintas redes o dispositivos. Si tiene acceso al panel del hosting, revise alertas de recursos y registros de errores.

En WordPress, un mensaje de “error crítico” suele implicar un fallo fatal de PHP, a menudo provocado por un plugin o el tema. Un 500 puede ser un error de aplicación o de configuración del servidor. Un 502 o 504 suele apuntar a problemas entre el proxy y PHP-FPM o a tiempos de respuesta excesivos. Un 403 puede ser un bloqueo por reglas de seguridad, permisos o un WAF. No haga cambios a ciegas: primero capture evidencia.

• Anote el código HTTP y el texto exacto del error (captura y hora), incluyendo si aparece en /wp-admin/.
• Revise si hay cambios recientes: actualizaciones, nuevo plugin, cambio de tema, ajuste de caché, migración o cambios DNS.
• Compruebe avisos del hosting: picos de CPU, memoria, procesos PHP, límites de I/O o incidencias de red.
• Busque alertas en Google Search Console si el sitio lleva horas caído (cobertura, errores de servidor, problemas de seguridad).
• Haga comprobaciones prudentes: probar en incógnito, vaciar caché del navegador, verificar desde otra red y evitar reinstalar o borrar sin copia.

Causas habituales y cómo confirmarlas con pruebas

Las causas más frecuentes se agrupan en cuatro bloques: errores de PHP (fatal errors), problemas de base de datos, configuración de servidor y red (DNS, SSL), y conflictos de plugins o tema. Confirmarlas exige pruebas simples: revisar logs, reproducir el fallo en un entorno controlado y aislar componentes de forma reversible.

WordPress ofrece mecanismos de depuración que, bien usados, ayudan a identificar el archivo o función que falla. La recomendación es activar depuración de forma temporal y controlada, evitando exponer información sensible en producción. Si no tiene acceso a logs, el panel del hosting suele permitir ver el error_log o registros de PHP.

• Error crítico o pantalla blanca: confirme si hay fatal error en logs de PHP y qué plugin o tema aparece en la traza.
• Error “Error establishing a database connection”: valide credenciales, estado del servicio de base de datos y saturación de conexiones.
• Errores 502/504: revise tiempos de respuesta, límites de PHP-FPM y si hay consultas lentas o tareas programadas bloqueando.
• Errores 403/406: compruebe reglas de seguridad, permisos de archivos y posibles falsos positivos de WAF.
• Problemas intermitentes: correlacione con cron, copias automáticas, picos de tráfico o tareas de WooCommerce.

Seguridad: malware, spam y bloqueos que impiden cargar

Aunque no siempre es la causa, una infección o compromiso de credenciales puede provocar que la web no cargue o cargue de forma errática. También puede ocurrir que el proveedor bloquee temporalmente el sitio por actividad maliciosa, envío de spam o consumo anómalo de recursos. En estos casos, actuar sin método puede destruir evidencia útil y dificultar una limpieza correcta.

Los vectores habituales incluyen plugins o temas vulnerables, credenciales filtradas reutilizadas, permisos de archivos demasiado permisivos y inyecciones en la base de datos o en archivos del tema. Los síntomas típicos son redirecciones extrañas, contenido inyectado, usuarios administradores desconocidos, picos de CPU por procesos sospechosos o avisos de seguridad. La respuesta debe ser proporcional: contención, copia, revisión y endurecimiento básico.

• Busque señales: redirecciones, anuncios no autorizados, cambios en archivos recientes y usuarios admin que usted no creó.
• Haga una copia forense razonable antes de limpiar: archivos y base de datos, para poder comparar y restaurar si algo falla.
• Rote credenciales: WordPress, FTP/SFTP, panel del hosting, base de datos y cuentas de correo asociadas.
• Revise permisos y hardening básico: limitar edición de archivos desde el panel y proteger accesos a /wp-admin/ según su caso.
• Actualice núcleo, plugins y tema desde fuentes legítimas, y elimine extensiones abandonadas o sin mantenimiento.

Rendimiento y estabilidad: cuando “no carga” es saturación

En ocasiones la web no está “rota”, sino saturada. Si el servidor llega a límites de CPU, memoria o procesos PHP, las peticiones empiezan a acumularse y el usuario percibe que no carga. Esto es frecuente en picos de tráfico, campañas, bots, búsquedas internas mal optimizadas o procesos pesados como importaciones, copias de seguridad o regeneración de miniaturas.

La estabilidad depende de una combinación de caché bien configurada, base de datos saludable y un hosting dimensionado. También influye el número de plugins, el peso del tema, el uso de constructores y la calidad del código. La mejora no consiste solo en “instalar caché”, sino en medir, aislar cuellos de botella y evitar que tareas pesadas se ejecuten en momentos críticos.

• Compruebe si el fallo coincide con picos de recursos en el panel del hosting o con límites de procesos PHP.
• Revise si hay endpoints problemáticos: búsqueda, filtros, carrito, checkout o llamadas a APIs externas que bloquean.
• Valide la caché: página, objeto y navegador, y evite cachear zonas dinámicas como carrito o cuenta.
• Inspeccione tareas programadas: cron de WordPress, copias automáticas y plugins que ejecutan procesos intensivos.
• Reduzca carga: desactive temporalmente funciones no críticas en momentos de caída, siempre de forma reversible y documentada.

Plugins, temas y actualizaciones: conflictos típicos

Los conflictos entre plugins, tema y versiones de PHP son una causa muy común de webs que dejan de cargar tras una actualización. WordPress evoluciona, y no todas las extensiones mantienen el mismo ritmo. También puede ocurrir que un plugin de caché, seguridad o optimización modifique reglas, cabeceras o archivos y provoque errores difíciles de interpretar.

La buena práctica es trabajar con un entorno de staging, aplicar control de cambios y validar compatibilidades antes de actualizar en producción. Si el sitio ya está caído, el objetivo es aislar el componente conflictivo con el mínimo impacto: desactivar plugins de forma segura, cambiar temporalmente a un tema por defecto y revisar el error exacto en logs. Evite “actualizar todo” como primer impulso, porque puede introducir más variables.

• Use staging cuando sea posible: pruebe actualizaciones y compatibilidades antes de tocar producción.
• Controle cambios: registre qué se actualizó, versión anterior y nueva, y el momento exacto del cambio.
• Aísle conflictos: desactive plugins de uno en uno (o por grupos) y observe si el error desaparece.
• Valide compatibilidad con PHP: una actualización puede requerir una versión mínima distinta a la de su servidor.
• Revise el tema y functions.php: un error de sintaxis o una función incompatible puede provocar pantalla blanca.

Hosting, dominio y correo en España: DNS, SSL y límites

En el ámbito general de España, los problemas de carga a menudo se relacionan con la capa de proveedor: cambios de DNS, certificados SSL, cachés de servidor, versiones de PHP y límites de recursos. También influyen configuraciones de seguridad del propio hosting, como firewalls de aplicaciones, reglas anti bots o bloqueos por intentos de acceso. Cada proveedor implementa estas capas de forma distinta, por lo que los pasos exactos pueden variar.

Si el dominio no resuelve o resuelve a un destino incorrecto, WordPress puede estar funcionando, pero el usuario nunca llega. Si el SSL está mal configurado, el navegador puede bloquear la carga o mostrar advertencias. Si PHP está desactualizado o demasiado nuevo para su stack, pueden aparecer errores. Y si el correo transaccional depende del servidor, un bloqueo por spam puede venir acompañado de restricciones que afecten a la web.

• DNS: verifique que el dominio apunta al servidor correcto y que no hay cambios recientes sin documentar.
• SSL/TLS: confirme que el certificado está vigente y que la redirección a HTTPS no entra en bucle.
• PHP: revise versión activa, límites de memoria y tiempo de ejecución, y si hay cambios automáticos del proveedor.
• Cachés de servidor y CDN: purgue con criterio y compruebe que no se sirve una versión rota o un error cacheado.
• Correo: si hay formularios o WooCommerce, valide que el envío transaccional no está bloqueado por políticas del proveedor.

Pruebas, accesos y documentación para trazabilidad

Para resolver una caída con rapidez, la diferencia suele estar en la calidad de la información disponible. Documentar accesos, cambios y evidencias técnicas permite reproducir el problema, aislar la causa y justificar cada acción. Además, si necesita escalar al hosting o a un proveedor externo, aportar datos concretos reduce tiempos de ida y vuelta.

No se trata de acumular capturas sin orden, sino de construir una línea temporal: cuándo empezó, qué se cambió, qué error exacto aparece y qué pruebas lo confirman. En WordPress, los logs y el registro de actualizaciones son especialmente útiles. Si hay sospecha de seguridad, preserve evidencia antes de limpiar.

• Trazabilidad de cambios recientes: registro de actualizaciones (núcleo, plugins, tema), lista de plugins activos y versiones, y changelog si aplica.
• Evidencias técnicas: logs de PHP y del servidor, capturas del error con hora, y URLs exactas afectadas (inicio, /wp-admin/, checkout).
• Copias de seguridad: fecha de la última copia válida, ubicación, y prueba de restauración en staging si es posible.
• Export de base de datos: copia antes de cambios, y nota de tamaño y tablas relevantes si hay errores de conexión o corrupción.
• Accesos necesarios: panel del hosting, SFTP/SSH si aplica, acceso a WordPress, y datos de DNS/registrador cuando haya cambios de dominio.

Plan de acción ordenado para recuperar la web

Un plan ordenado reduce el tiempo de caída y evita introducir nuevas variables. La prioridad es contener el impacto, asegurar una copia y diagnosticar con evidencias. Después se corrige la causa, se verifica la recuperación y se monitoriza para confirmar que el problema no reaparece. Este enfoque es válido en la mayoría de entornos, aunque los detalles pueden variar según hosting, CDN o configuraciones específicas.

Si el sitio es crítico (ventas, captación), es preferible una recuperación estable aunque sea temporal, antes que una “optimización” apresurada. Por ejemplo, restaurar una versión funcional y luego investigar el conflicto en staging suele ser más seguro que encadenar cambios en producción. Documente cada paso para poder revertir.

• Contención: active una página de mantenimiento si procede y reduzca cambios en producción mientras se investiga.
• Copia: haga backup de archivos y base de datos antes de desactivar, borrar o restaurar componentes.
• Diagnóstico: identifique el tipo de error (HTTP, PHP, base de datos, DNS, SSL) y recopile logs y señales.
• Corrección: aísle el componente conflictivo (plugin, tema, configuración) y aplique el cambio mínimo necesario.
• Verificación y monitorización: pruebe rutas clave (inicio, login, formularios, checkout) y vigile recursos y logs tras el arreglo.

Si ya se ha tocado algo o hay urgencia: cómo no empeorar

En situaciones reales, a menudo se actúa con prisa: se instala un plugin de seguridad, se restaura una copia parcial, se cambia de hosting o se edita functions.php para “arreglarlo rápido”. Si la web sigue sin cargar, el siguiente paso debe ser frenar, reconstruir la línea temporal y recuperar control. No es un reproche, es una medida para evitar pérdida de datos y para poder diagnosticar con fiabilidad.

La cautela principal es no destruir evidencia técnica ni mezclar restauraciones. Una restauración parcial puede dejar desalineados archivos y base de datos, generando errores difíciles. Cambiar de hosting sin revisar DNS puede crear intermitencias. Y limpiar malware sin copia puede eliminar pistas sobre el vector de entrada. Si hay urgencia, priorice estabilizar y documentar, y deje la optimización para después.

• Si instaló un plugin de seguridad: revise si bloquea /wp-admin/ o peticiones legítimas y documente reglas aplicadas.
• Si restauró una copia parcial: confirme coherencia entre archivos y base de datos, y evite encadenar restauraciones sin plan.
• Si cambió de hosting: verifique DNS real, TTL y que el certificado SSL y las rutas de PHP coinciden con el nuevo entorno.
• Si tocó functions.php o el tema: revierta el cambio si no está seguro y busque el error exacto en logs.
• Si borró un plugin crítico o intentó limpiar sin copia: detenga cambios, haga una copia del estado actual y reconstruya pasos con evidencia.

Preguntas frecuentes

Estas dudas son habituales cuando una web en WordPress deja de cargar. Las respuestas son generales y deben adaptarse a su hosting, configuración y cambios recientes.

P: ¿Qué significa el mensaje “Ha habido un error crítico en este sitio web”?

R: Normalmente indica un error fatal de PHP provocado por un plugin, el tema o una incompatibilidad de versión. La forma más fiable de confirmarlo es revisar el log de errores y activar depuración de forma controlada.

P: ¿Por qué mi WordPress no carga solo a veces?

R: Suele deberse a saturación de recursos, cachés inconsistentes, DNS resolviendo a destinos distintos tras cambios, o tareas programadas que bloquean. Correlacionar horas, tráfico y recursos ayuda a confirmarlo.

P: ¿Es buena idea desactivar todos los plugins para recuperar la web?

R: Puede ser útil como prueba de aislamiento, pero conviene hacerlo con copia previa y registrando el estado inicial. En sitios con WooCommerce o funciones críticas, desactivar sin plan puede afectar pedidos, sesiones o integraciones.

P: ¿Restaurar una copia de seguridad siempre soluciona que no cargue?

R: No necesariamente. Si la causa es externa (DNS, SSL, límites del servidor) o si la copia es parcial o antigua, puede no resolverlo o incluso introducir incoherencias. Lo recomendable es validar la copia y, si es posible, probar la restauración en staging.

P: ¿Qué datos debo aportar si pido soporte técnico?

R: Código y mensaje de error, hora de inicio, cambios recientes, URLs afectadas, lista de plugins y versiones, y logs disponibles del hosting o de WordPress. Con esa información se reduce mucho el tiempo de diagnóstico.