Una pàgina en blanc pot ser una resposta buida amb estat correcte, un error fatal de PHP ocult, una sortida prematura, memòria exhaurida o HTML amagat pel codi del frontal. El color que mostra el navegador no identifica tot sol la capa que falla.
Inspecciona l’estat, les capçaleres i el cos abans de fer visibles els errors. Els visitants de producció no haurien de veure mai rutes del servidor ni traces d’execució.
Comprova la resposta HTTP real
Obre la pestanya Xarxa de les eines del navegador o utilitza un client HTTP autoritzat. Registra el codi d’estat, tipus de contingut, longitud de resposta, cadena de redireccions i capçaleres de memòria cau.
Patrons d'una resposta en blanc:
500 amb cos buit -> fallada del servidor o PHP
200 amb zero bytes -> sortida prematura o error ocult
200 amb HTML -> problema de CSS, JavaScript o visualització
bucle 3xx -> problema d'URL, HTTPS o galetesProva també un CSS o una imatge i wp-login.php per delimitar l’abast.
Mira la resposta sense interpretar
Utilitza «Mostra el codi font» o inspecciona el cos rebut. Si hi ha marcatge HTML, desactiva extensions del navegador i busca CSS com ara text blanc, contenidors ocults o una capa de pantalla completa.
Si el cos s’acaba bruscament, anota l’última secció de plantilla renderitzada. Pot assenyalar el hook o shortcode que s’executava quan PHP s’ha aturat.
No modifiquis el disseny abans de demostrar que el servidor ha retornat l’HTML complet.
Llegeix els registres de PHP i del servidor
Relaciona l’hora de la petició amb els registres de PHP-FPM, Apache o Nginx i WordPress. Busca errors fatals, memòria exhaurida i excepcions no controlades.
Activa WP_DEBUG_LOG amb WP_DEBUG_DISPLAY desactivat només si no hi ha prou registres:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Desactiva el registre temporal en acabar i evita que el fitxer es pugui descarregar públicament.
Comprova memòria i temps d’execució
La memòria exhaurida pot produir una resposta blanca quan els errors estan ocults. Registra el límit, l’assignació sol·licitada, el fitxer i la línia.
No augmentis el límit sense investigar què consumeix la memòria. Un bucle o una consulta sense límits també exhaurirà el nou màxim.
En els timeouts, compara el temps màxim de PHP amb el del proxy invers i identifica la tasca que s’ha bloquejat.
Aïlla connector i tema de manera precisa
Si l’error fatal esmenta un connector, canvia el nom només del seu directori. Si no hi ha registres, prova en staging o canvia el nom del directori de connectors seguint un ordre documentat de reactivació.
Recorda que els connectors obligatoris es carreguen fora del directori normal i poden continuar provocant la pantalla blanca.
Si el problema és al tema, confirma que hi ha un tema predeterminat compatible. Sense alternativa, WordPress es pot quedar sense res per renderitzar.
No editis el tema pare ni els fitxers del connector com a solució permanent.
Localitza sortides prematures i memòries intermèdies
Busca al codi propi exit, die, neteja de la memòria intermèdia de sortida i lògica de manteniment al voltant de la ruta afectada. Un control de seguretat o staging pot retornar deliberadament un cos buit.
if ( ! defined( 'ABSPATH' ) ) {
exit;
}Aquesta protecció és normal quan s’obre un fitxer directament; el defecte apareix si una condició semblant s’activa durant una petició vàlida de WordPress.
Comprova fitxers incomplets o incorrectes
Una actualització interrompuda, una restauració fallida o el límit de disc o inodes poden deixar fitxers PHP absents o de zero bytes. Compara checksums de paquets fiables i dates de modificació.
Després de fer còpia, reinstal·la exactament el component oficial. Conserva les pujades i la configuració, i verifica el propietari dels fitxers abans de tornar a actualitzar.
Buida OPcache perquè PHP no conservi codi compilat antic.
Verifica totes les rutes afectades
Prova la portada, entrades, accés, administració, editor, mitjans i l’URL original. Revisa si apareixen errors nous i prova com a usuari anònim i connectat.
El manteniment recurrent també hauria d’alertar de respostes HTML buides, no només d’estats diferents de 200. La pantalla blanca està resolta quan la petició subjacent acaba de manera previsible, no quan apareix temporalment una pàgina desada a la memòria cau.