HTTP 500 indica que el servidor no ha pogut completar la petició i ha decidit no mostrar l’error subjacent. Després d’actualitzar, les causes habituals són un error fatal de PHP, una extracció incompleta, permisos incorrectes, una regla de reescriptura malmesa o codi incompatible.
La coincidència amb l’actualització és una pista, no una prova que el paquet nou sigui defectuós. Conserva els registres abans de desfer diversos canvis alhora.
Determina quines peticions retornen 500
Prova la portada, un recurs estàtic, wp-login.php, l’administració i la pàgina que ha fallat originalment. Anota l’hora, el host, l’estat i si la resposta prové d’un servidor intermediari o de l’origen.
Compara:
estat de les peticions HTML/PHP
estat de CSS i imatges
administració davant del web públic
usuari connectat davant d'anònim
resposta de l'origen davant de la CDNNo repeteixis actualitzacions ni accions sobre la base de dades durant el diagnòstic.
Consulta els registres del servidor i PHP
Relaciona l’hora de la petició amb els registres d’Apache o Nginx, PHP-FPM i WordPress. Un 500 generat pel proxy pot deixar proves diferents d’una fallada de l’aplicació PHP.
Conserva el primer error fatal i la seva pila de crides. Els avisos posteriors poden ser-ne només conseqüències.
Protegeix els registres: poden revelar rutes internes, dades de consultes o credencials mostrades accidentalment per una extensió.
Busca una actualització incompleta
Comprova si WordPress ha deixat el fitxer .maintenance, si el directori del connector o tema conté fitxers parcials i si s’ha arribat al límit de disc o d’inodes durant l’extracció.
Compara la versió instal·lada amb el paquet i els checksums oficials quan n’hi hagi. Reinstal·la exactament la versió fiable, sense copiar fitxers solts des d’un altre web.
Quan reinstal·lis el nucli, conserva wp-content, la configuració i les pujades.
Revisa permisos i propietari
Una actualització executada amb un altre usuari del sistema pot impedir que PHP llegeixi fitxers o escrigui als directoris necessaris. Compara el propietari i el grup amb fitxers propers que funcionin.
Els permisos adients depenen de l’allotjament i del controlador PHP. Segueix la documentació de cPanel, Plesk o el proveïdor. No apliquis 777 recursivament per silenciar un accés denegat: crearies un problema de seguretat.
Abans de canviar permisos de manera àmplia, localitza la línia concreta de «permission denied».
Prova la configuració de reescriptura
Una actualització o un connector de seguretat pot modificar .htaccess o les directives del servidor. Fes-ne una còpia, canvia el nom només del fitxer sospitós i prova després un punt d’entrada PHP directe.
En Apache, quan recuperis l’accés, regenera les regles estàndard des d’Ajustos > Enllaços permanents. En Nginx, la configuració és fora de WordPress i s’ha de corregir al servidor o mitjançant el proveïdor.
No enganxis directives d’Apache a Nginx ni a l’inrevés.
Aïlla el component actualitzat
Si el registre assenyala un connector, canvia el nom del seu directori. Si assenyala el tema, canvia’l només després de confirmar que hi ha un tema predeterminat instal·lat.
Reprodueix el cas en proves amb la versió anterior i la nova. Llegeix els canvis publicats i els requisits de PHP i WordPress.
Evita desactivar tots els connectors d’un web comercial tret que el 500 no proporcioni cap prova útil i disposis d’un ordre documentat per reactivar-los.
Reverteix sense perdre dades
Reverteix els fitxers del component responsable a partir d’un paquet fiable o una còpia. No restauris tota la base de dades només per revertir codi: podries perdre entrades, ajustos o comandes noves.
Si l’actualització ha migrat l’esquema de dades, consulta les instruccions del fabricant abans de baixar de versió. Alguns esquemes no són compatibles cap enrere.
Documenta el risc de seguretat de mantenir una versió anterior i prepara una solució actualitzada que ja hagis provat.
Verifica i vigila
Prova la part pública i administrativa, el desament de l’editor, les tasques programades i la funció original. Buida OPcache i la memòria cau de pàgina només quan correspongui i torna a provar amb la memòria cau ja escalfada.
Comprova les capçaleres de la CDN i del navegador per descartar que se segueixi servint un 500 emmagatzemat encara que l’origen ja funcioni. Prova tant amb memòria cau com sense.
Vigila la taxa d’errors 500 i els errors fatals de PHP quan reobris el web. El manteniment recurrent hauria de provar les actualitzacions de risc, comprovar disc i inodes i conservar paquets de reversió perquè la propera actualització no es converteixi en una nova urgència.