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ó.
Un arbre de decisió abans de canviar la web
- La resposta no té cos: registra estat HTTP i hora i correlaciona’ls amb evidència del servidor i PHP. L’HTML buit no identifica tot sol el component que falla.
- Hi ha HTML, però la pàgina sembla blanca: inspecciona marcat rebut, errors del navegador, estils i capes superposades. Conserva la resposta abans de canviar presentació.
- Funciona la web pública, però l’administració queda en blanc: segueix el diagnòstic d’administració en blanc. Una pàgina pública a la memòria cau no verifica la petició de l’administració.
- La petició redirigeix o es denega: identifica aquesta resposta i l’origen abans de tractar-la com un error de presentació.
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.
Prova HTTP pròpia: l’estat és una pista més
El 24 d’octubre de 2026 vam servir quatre respostes sintètiques originals en un servidor HTTP temporal de bucle local i en vam llegir les respostes. No vam intervenir en WordPress ni en una configuració de producció. Aquestes van ser les observacions controlades:
empty-success HTTP 200 0 bytes no HTML
empty-error HTTP 500 0 bytes no HTML
hidden-markup HTTP 200 90 bytes HTML present
maintenance HTTP 503 69 bytes HTML presentL’exemple de marcat ocult contenia un element main amb display:none. Les respostes buides 200 i 500 tenien la mateixa longitud; canviava l’estat. L’exercici mostra diferències de resposta, no una causa de WordPress ni una reparació de client. Per reproduir-lo, prepara aquestes combinacions d’estat i cos en un entorn aïllat i inspecciona la resposta original.
En una incidència real, conserva URL, hora, estat, observació del cos i evidència corresponent del registre. La documentació de depuració de WordPress —en anglès— orienta l’obtenció de registres addicionals mantenint els errors fora de la pantalla pública.
Evidència per tancar la reparació de pantalla blanca
Repeteix la URL afectada en la condició original del visitant després de la correcció acordada. Comprova contingut i resposta previstos, formulari o tasca administrativa afectats i absència del mateix error nou als registres disponibles. Anota canvi i rutes sense verificar. Per reparar una pantalla blanca de WordPress, aporta aquest límit de l’error i els canvis recents per concretar la intervenció.