Una página por error, para cuando tu sitio no funciona. Cada guía empieza con el mensaje original de WordPress y explica las causas en el orden más útil para revisarlas.
Busca el texto exacto, no solo el síntoma. Una página en blanco y un error 500 pueden verse igual en el navegador, pero tienen causas distintas.
WordPress cargado, leer wp-config.php, y no pudo obtener una respuesta de MySQL. Cada página en el sitio está en blanco hasta que pueda.
Una página completamente en blanco sin error y sin HTML. PHP paró la mitad de la investigación y el mensaje fue a un registro que no ha leído todavía.
El servidor web intentó producir la página, algo salió mal dentro, y devolvió un código de estado en lugar de una razón.
El servidor web alcanzó PHP y PHP no respondió. Nginx o Apache está informando de una conversación que terminó antes de que empezara.
PHP estaba trabajando cuando el servidor web dejó de esperar. Nada se estrelló - simplemente tomó más tiempo de lo que el tiempo permite.
PHP alcanzó el techo que se dio y paró. El número en el mensaje es el límite, no la cantidad que su sitio necesita.
PHP detuvo un script que había estado funcionando más tiempo de lo que se permite. El límite hizo su trabajo; la pregunta es si el trabajo perteneció a una solicitud web.
El navegador siguió la redireccion después de redireccionar y detener. Dos cosas no están de acuerdo sobre dónde debe vivir esta URL, y cada una es segura.
El propio controlador de error fatal de WordPress. Se cobró, sustituyó la página con esta frase, y no dijo a nadie excepto el correo electrónico de administración.
WordPress escribe un archivo .maintenance antes de una actualización y lo elimina después. La actualización no terminó, por lo que el archivo sigue allí.
PHP rechazó el archivo antes de que WordPress vio un byte de él. El número en el mensaje es el techo de PHP, no WordPress.
El archivo transferido, entonces algo falló mientras WordPress estaba generando las miniaturas. El mensaje es el mismo lo que algo era.
La página llegó sobre HTTPS y luego pidió algo sobre HTTP. Los navegadores bloquean las partes activas y dejan el candado para el resto.
El tiempo de publicación pasó y no pasó nada. WP-Cron no es un reloj — funciona cuando llega una solicitud, y no llegó ninguna petición.
WordPress tenía una conexión de base de datos de trabajo y lo perdió la mitad de la investigación. La consulta es raramente culpa; la conexión es.
WordPress hizo una solicitud HTTP a su propia dirección y no obtuvo una respuesta. Varias características dependen de que funcione.
Algo respondió la solicitud que no era WordPress, o contestó con HTML. El editor deja de funcionar primero, porque depende de la API para todo.
La carga fue rechazada antes de que se haya escrito algo. O la extensión no está en la lista permitida, o el contenido del archivo no coincide con la extensión.
La solicitud fue entendida y rechazada. La negativa vino del servidor web, un firewall o una regla de permisos — WordPress rara vez está involucrado.
Un patrón muy específico con una lista muy corta de causas. Sus publicaciones todavía existen; el router delante de ellos no está enrutándose.
La mayoría de estos errores tienen que ver con la configuración. El alojamiento gestionado, con copias diarias, entornos de pruebas con un clic y límites por sitio, elimina causas comunes.