500 Internal Server Error in WordPress

Je WordPress-site toont een lege pagina met de tekst "500 Internal Server Error", of Chrome meldt "This page isn't working: HTTP ERROR 500". De response inspector laat statuscode 500 zien. De fout komt terug bij bezoekers en bij jou, in elke browser, op mobiel en op desktop. Soms helpt een refresh een paar seconden, soms ligt de site er volledig uit tot je ingrijpt.

Wat een 500 echt betekent

RFC 9110 §15.6.1 definieert 500 als: "the server encountered an unexpected condition that prevented it from fulfilling the request." Die ene zin doet veel werk. De server leeft, het verzoek bereikte de applicatie, de applicatie startte met verwerken, en daarna trad er een fout op die niet vertaald kon worden naar een normaal antwoord. De webserver gaf vervolgens een 500 aan de bezoeker terug in plaats van HTML.

Het woord dat ertoe doet in die definitie is unexpected. Een 500 is de server die toegeeft dat er ergens in de applicatie iets misging waarvan hij niet weet hoe ermee om te gaan. Het is geen netwerkprobleem en geen browserprobleem. De fix zit altijd ergens op de server.

Een 500 is niet hetzelfde als de andere 5xx-fouten in deze categorie, en het verschil is belangrijk voor je diagnose:

• 500 Internal Server Error: de applicatie zelf maakte een nette fout en gaf een 500 terug aan de proxy. Hierover gaat dit artikel.
• 502 Bad Gateway: de upstream gaf een ongeldig of leeg antwoord, vaak omdat de worker midden in het verzoek crashte.
• 503 Service Unavailable: de upstream geeft expliciet aan het verzoek nu niet aan te kunnen (overbelasting, onderhoudsmodus, rate limit).
• 504 Gateway Timeout: de upstream was bereikbaar maar duurde te lang. PHP leeft nog, alleen traag.

Kortom: een 502 is een lijk, een 504 is stilte, een 503 is een "ga weg" en een 500 is een bekentenis.

Eén belangrijke nuance: sinds WordPress 5.2 verschijnen de meeste PHP fatals binnen WordPress niet meer als kale "500 Internal Server Error"-pagina. WordPress 5.2 introduceerde fatal error recovery mode, die een fatal opvangt, de admin een herstel-mail stuurt en de bezoeker het scherm "Er is een kritieke fout op deze website opgetreden" toont in plaats van een blanco 500. Zie je in 2026 nog een kale 500-pagina, dan is de fout meestal iets wat WordPress vanuit PHP-land níet kon vangen: een parse error, een .htaccess-probleem, een ontbrekend bestand, of een geheugenuitputting die het proces afbrak voordat WordPress' shutdown handler kon draaien.

Veelvoorkomende oorzaken, op volgorde van waarschijnlijkheid

1. Een PHP fatal voordat WordPress hem kon vangen

Dit is de oorzaak achter de meeste kale 500's op een WordPress-site. PHP laadde het bestand, begon met uitvoeren en raakte iets wat hij niet kon afmaken: een geheugenuitputting, een maximale uitvoeringstijd, een parse error, een ontbrekende functie. Elk van deze heeft een eigen artikel en een eigen fix. De 500 is alleen het symptoom aan de oppervlakte:

• Een geheugenuitputting geeft "Allowed memory size exhausted" in het error log en een 500 aan de bezoeker.
• Een lang lopend verzoek raakt de "Maximum execution time exceeded" en wordt afgebroken.
• Een typo in een thema- of pluginbestand geeft een "Parse error: syntax error, unexpected" en het bestand is onbruikbaar.

De 500-pagina zelf zegt je niets. Het error log vertelt je welke van deze het is.

2. Een .htaccess-syntaxfout (alleen Apache)

Draai je op Apache en bevat de root van je site een .htaccess-bestand met een onjuiste directive, dan geeft Apache een 500 terug aan de client en schrijft de specifieke syntaxfout naar het Apache error log. Dit is de op één na meest voorkomende oorzaak die ik in de praktijk zie, omdat .htaccess het bestand is dat plugins, beveiligingstools en migratiescripts het meest agressief aanpassen. Een typische trigger is een security plugin die net een nieuwe ruleset installeerde, een caching plugin die een rotte rewrite-block schreef, of een handmatige edit die Windows line endings in het bestand plakte. nginx leest .htaccess helemaal niet, dus deze oorzaak is Apache-only.

3. Een kapotte plugin of thema die buiten WordPress' vangnet draait

De meeste plugin- en themabugs in 2026 geven het kritieke-foutscherm, niet een kale 500. Maar code die draait voordat WordPress boot (een custom mu-plugin, een snippet in wp-config.php, een drop-in als object-cache.php) draait buiten de recovery handler. Crasht zo'n stuk code, dan ziet de bezoeker wel een kale 500. Hetzelfde geldt voor code die een fout triggert die PHP vanuit user space niet kan vangen, zoals een stack overflow, een segfault in een native extension, of een fatal in PHP's startup-fase.

4. Verkeerde permissies op een sleutelbestand

Kan PHP wp-config.php, index.php of een bestand in wp-includes niet lezen, dan faalt het verzoek voordat WordPress iets kan renderen. Het Apache- of nginx-error-log meldt Permission denied met de bestandsnaam erbij. WordPress' eigen permissie-richtlijn is 644 voor bestanden, 755 voor mappen en 440 of 400 voor wp-config.php. Een migratietool die bestanden met de verkeerde owner kopieerde, of een chmod die alles op 000 zette, geeft 500's bij elk verzoek tot het is rechtgezet.

5. Een serverconfiguratiefout

Komt minder vaak voor, maar wel uitsluiten: de webserver zelf staat verkeerd ingesteld en geeft een 500 voordat het verzoek PHP überhaupt bereikt. Een kapotte php_value-regel in een Apache-vhost, een corrupt opcache-bestand, een PHP-FPM-pool die wel boot maar zijn socket niet kan lezen, of een mod_security-regel die op elk verzoek afgaat: ze geven allemaal een 500. Op managed hosting is dit zelden iets wat jij zelf moet fixen, maar je moet het wel kunnen herkennen zodat je geen uur verspilt aan plugins deactiveren.

Stel vast welke oorzaak het is

Doe deze checks voordat je ook maar één instelling wijzigt. Ze zijn niet-destructief en vertellen je precies welke van de vijf oorzaken jij hebt.

Check 1: lees het server error log. Dit is veruit de belangrijkste stap, en de stap die de meeste lezers overslaan. Het server error log bevat de échte PHP-foutmelding die de 500 veroorzaakte. Open het controlepaneel van je hosting (cPanel, Plesk, DirectAdmin of wat je host ook aanbiedt) en zoek naar "Error logs" of "Foutenlogboek". Voor een 500 zoek je de regel waarvan de timestamp matcht met de bezoekersmelding. Heb je SSH-toegang? Op Apache vind je het log op /var/log/apache2/error.log of /var/log/httpd/error_log, conform de Apache documentatie. Op nginx staat het op /var/log/nginx/error.log, conform de nginx documentatie. Hoe dan ook, de regel die je zoekt ziet er ongeveer zo uit:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 8192 bytes) in /home/jouwsite/public_html/wp-content
/plugins/voorbeeld-plugin/render.php on line 1024

Of voor een .htaccess-probleem:

.htaccess: Invalid command 'RewriteCondX', perhaps misspelled or
defined by a module not included in the server configuration

Die ene regel vertelt je welke van de vijf oorzaken je hebt. Je weet dat het werkt als: je de exacte foutmelding kunt citeren en de timestamp ervan kunt koppelen aan de bezoekersmelding.

Check 2: zet WordPress debug logging aan als het server log leeg is. Toont het server error log niets (sommige shared hosts verbergen het voor je), zet dan WordPress' eigen error log aan. De WordPress debugging documentatie zegt om deze regels toe te voegen aan wp-config.php, vlak boven het commentaar /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

De volgende keer dat de 500 optreedt, wordt de fout weggeschreven naar wp-content/debug.log. De WP_DEBUG_DISPLAY-regel is de belangrijke: hij houdt de fout uit de browser van de bezoeker en vangt hem toch op in het bestand. Zet WP_DEBUG weer op false zodra je de foutmelding hebt.

Je weet dat het werkt als: wp-content/debug.log een Fatal error- of Parse error-regel bevat met een timestamp die matcht met de 500.

Check 3: hernoem .htaccess als je op Apache zit. Kun je via SFTP of een file manager bij de site root, hernoem dan het bestaande .htaccess naar .htaccess.bak en herlaad de mislukte URL. Komt de site terug, dan was het bestand de oorzaak. Zo niet, hernoem hem dan weer terug naar .htaccess (een kapot bestand is meestal niet het enige probleem en een ontbrekend .htaccess breekt permalinks en security plugins). Op nginx sla je deze check helemaal over: nginx negeert .htaccess.

Je weet dat het werkt als: de URL die 500 gaf nu een 200 geeft met het hernoemde bestand op zijn plek, of de 500 blijft optreden zonder .htaccess en je kunt het bestand uitsluiten.

Check 4: bestaan en permissies van de sleutelbestanden. Open de file manager van je hostingpaneel en blader naar de site root. Controleer of wp-config.php, index.php en wp-load.php bestaan. De meeste file managers tonen een permissiekolom naast elk bestand: wp-config.php hoort op 440 of 644 te staan en mappen op 755. Kun je permissies wijzigen in de file manager, zet dan elk bestand dat op 000 staat meteen goed. Heb je SSH-toegang? Draai ls -l wp-config.php in de site root en kijk of er minstens r-- voor de owner staat. Fix het zo nodig met chmod 440 wp-config.php.

Je weet dat het werkt als: elk sleutelbestand aanwezig en leesbaar is, en de 500 of weg is, of je permissies in elk geval kunt uitsluiten.

Oplossingen, per oorzaak

Fix voor oorzaak #1: een PHP fatal

De fix hangt af van wélke fatal het was. De 500 is alleen de verpakking:

• Allowed memory size exhausted: volg het aparte artikel over de WordPress geheugenlimiet verhogen. Daarin vind je WP_MEMORY_LIMIT, de onderliggende PHP memory_limit en hoe je het verzoek vindt dat zoveel vraagt. Ik dupliceer de configuratie hier bewust niet: de canonieke fix staat dáár en blijft daar actueel.
• Maximum execution time exceeded: zie het artikel over de PHP max execution time voor het verhogen ervan en voor het uit de request lifecycle halen van de lange taak.
• Parse error: zie het parse error artikel. De foutmelding noemt het exacte bestand en de regel. De fix is bijna altijd het bestand via SFTP terugzetten naar de vorige versie.
• Iets anders: lees de foutmelding, zoek op de exacte tekst en update of verwijder de plugin die het veroorzaakt.

Verificatie: de URL die 500 gaf geeft nu een 200, en het server error log toont geen nieuwe fatal-regels meer voor hetzelfde bestand.

Fix voor oorzaak #2: een kapotte .htaccess (alleen Apache)

Bevestigde Check 3 dat het bestand de oorzaak was, regenereer dan een schone default. Log in op wp-admin (dat lukt, want WordPress permalinks vallen terug op de standaard rewrite-regels als .htaccess ontbreekt), ga naar Instellingen → Permalinks en klik Wijzigingen opslaan zonder iets aan te passen. WordPress schrijft een schone .htaccess met het standaard WordPress rewrite-blok. Heeft een security- of caching-plugin eigen regels nodig, activeer die plugin daarna opnieuw en laat hem zijn blok in het nieuwe bestand schrijven.

Kun je wp-admin niet bereiken, maak dan zelf een verse .htaccess met de standaard WordPress-inhoud uit de WordPress permalinks documentatie en upload hem naar de site root.

Verificatie: de mislukte URL geeft nu een 200, en het Apache error log bevat geen .htaccess: Invalid command-regels meer.

Fix voor oorzaak #3: een kapotte plugin, thema of drop-in

Noemt het error log een bestand in wp-content/plugins/voorbeeld-plugin/, deactiveer dan die plugin. Werkt wp-admin, doe het via Plugins → Geïnstalleerde plugins. Werkt wp-admin niet, hernoem dan via SFTP de map van de plugin van voorbeeld-plugin naar voorbeeld-plugin.off. WordPress ziet de plugin als verdwenen en de 500 stopt. Werk de plugin daarna bij naar een gefixte versie, vervang hem door een alternatief, of meld de bug bij de ontwikkelaar.

Noemt het error log een bestand in wp-content/mu-plugins/, wp-content/themes/jouwthema/, of een drop-in als wp-content/object-cache.php, doe dan hetzelfde met dat bestand of die map. Een hernoemde mu-plugin is de snelste manier om een custom plugin uit te sluiten waarvan je vergeten was dat hij bestond.

Verificatie: de URL die 500 gaf geeft nu een 200 met het kapotte bestand uit de weg, en het error log verwijst niet meer naar dat bestand.

Fix voor oorzaak #4: bestandspermissies

Open de file manager van je hostingpaneel, selecteer alle bestanden in de WordPress-root en zet de permissies op 644. Selecteer daarna alle mappen en zet die op 755. Zet tot slot wp-config.php op 440. Dit zijn de veilige defaults conform de WordPress permissie-richtlijn. Op sommige shared hosts werkt 640 voor bestanden en 750 voor mappen beter. Werkt 644 niet, probeer dan 640.

Heb je SSH-toegang?

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Verificatie: de mislukte URL geeft een 200, en het server error log bevat geen Permission denied meer voor een WordPress-bestand.

Fix voor oorzaak #5: serverconfiguratie

Dit is de oorzaak waar jij niet aan de knoppen zit. Wijst het server error log naar een Apache-vhost, een nginx-config, een opcache-bestand of een mod_security-regel, dan is de fix om je host precies te vertellen wat het log meldt. Zij zijn de enigen die die bestanden mogen aanpassen. Stuur ze de escalatiechecklist hieronder in het eerste bericht, dan landt het ticket meteen bij de juiste engineer.

Verificatie: support bevestigt de wijziging, de mislukte URL geeft een 200, en de bewuste error-log-regel komt niet meer terug.

Wanneer je het moet escaleren

Lukt het je binnen 30 minuten niet om met de stappen hierboven de oorzaak te pinpointen, dan geef je het door aan je host of developer. Houd onderstaande lijst klaar, want dat is precies het eerste wat ze gaan vragen:

• De exacte URL die de 500 triggert.
• Het tijdstip waarop de fout optreedt, met tijdzone, en of het reproduceerbaar is of alleen sporadisch.
• Je hostingtier en stack (shared, VPS, managed, container; nginx of Apache; PHP-versie).
• De matchende regel uit het server error log (Apache of nginx).
• De matchende regel uit wp-content/debug.log als je WP_DEBUG_LOG aan hebt gezet.
• Een lijst van wat er in de afgelopen 48 uur is gewijzigd (plugin-updates, thema-updates, WordPress core updates, code-deploys, serverwijzigingen, DNS-wijzigingen).
• De lijst met momenteel actieve plugins, vooral alles wat .htaccess, caching, security of object caching aanraakt.
• Of de site achter Cloudflare of een vergelijkbare edge proxy zit, en of de 500 ook optreedt als je die omzeilt.

Stuur dat in het eerste bericht. Het scheelt een hele heen-en-weer-ronde en routeert het ticket meteen naar de juiste engineer.

Hoe je voorkomt dat het terugkomt

Een hardnekkige 500 is bijna altijd een recente wijziging die niet was getest. Drie gewoontes houden de fout zeldzaam op een gezonde site:

• Test updates eerst op staging. Een staging omgeving die je productiestack spiegelt, vangt .htaccess-regressies, plugin-incompatibiliteiten en PHP fatals op voordat je bezoekers ze merken. Heeft je host geen one-click staging, dan vangt zelfs een lokale Docker-kopie van de site de meeste eruit.
• Houd WP_DEBUG_LOG klaar om aan te zetten. Laat de constants in wp-config.php staan met WP_DEBUG op false. De dag dat je ze nodig hebt, verander je één regel en heb je meteen een echte foutmelding in plaats van een blanco 500. De WP_DEBUG_DISPLAY- en display_errors-regels uit Check 2 houden de bezoekerskant netjes.
• Pin je herstelbare configuratie. Een .htaccess die je via Instellingen → Permalinks regenereert is herstelbaar. Een handmatig aangepaste .htaccess die niet in version control staat, niet. Commit dus je custom serverconfig naar een repo, of laat een plugin er eigenaar van zijn zodat een herinstallatie van die plugin alles terugzet.

Antwoordt een single request op je site cold binnen één seconde, zonder extra bewegende delen en zonder recente configuratiewijzigingen, dan zou een 500 onder normale omstandigheden onmogelijk moeten zijn. Alles daarboven is het systeem dat je vertelt dat er iets misging op de server, en de 500 is gewoon de plek waar het symptoom naar boven komt.