Een 500 Internal Server Error betekent dat de server iets fout zag gaan bij het opbouwen van je pagina, maar bewust niet vertelt wát — de details staan in de error_log op je hosting. Bij WordPress-sites is de oorzaak in de praktijk bijna altijd één van deze vijf: een corrupte of te strenge .htaccess, een PHP-fout in een plugin of thema, een te lage PHP memory limit, verkeerde bestandspermissies of een PHP-versieconflict. In dit artikel laat ik je stap voor stap zien hoe je de echte oorzaak vindt en oplost, zonder te gokken.
In mijn praktijk als serverbeheerder — sinds 2006, voor honderden mkb-sites — kom ik deze fout dagelijks tegen. Het goede nieuws: in negen van de tien gevallen is een 500-fout binnen een kwartier te vinden én te verhelpen — als je op de juiste plek kijkt.
Wat betekent een 500 Internal Server Error eigenlijk?
HTTP-statuscodes die met een 5 beginnen, zeggen: het probleem ligt bij de server, niet bij de bezoeker. Code 500 is daarvan de meest algemene variant. De server probeerde je pagina te maken — PHP uitvoeren, WordPress laden, configuratieregels verwerken — en ergens in dat proces ging het mis.
Waarom vertelt de foutpagina dan niet wat er misging? Bewust. Foutdetails kunnen gevoelige informatie bevatten (bestandspaden, databasegegevens, code), en die wil je niet aan de hele wereld tonen. De server houdt de details daarom voor zichzelf en schrijft ze weg naar een logbestand. Dat is meteen de belangrijkste les van dit hele artikel: een 500-fout los je niet op door te gokken, maar door de error_log te lezen.
Belangrijk om te weten: een 500-fout betekent zelden dat "de server kapot is". De server draait meestal prima — hij weigert alleen jouw site uit te voeren omdat er iets in de configuratie of de code van die specifieke site niet klopt. Andere sites op dezelfde server doen het vaak gewoon.
Waar vind je de error_log en wat staat erin?
De error_log is je startpunt, altijd. Waar je hem vindt, hangt af van je hosting:
- Via je hostingpaneel (DirectAdmin, cPanel, Plesk, CloudPanel): zoek naar "Logs", "Error Log" of "Site logs". Bij DirectAdmin staat het onder Site Summary / Statistics / Logs.
- Via FTP of bestandsbeheer: veel servers schrijven een bestand
error_login de map waar de fout optrad — vaak de hoofdmap van je site (public_html) of de map van je actieve thema of plugin. - Bij WordPress zelf: als debug-logging aanstaat, vind je fouten in
wp-content/debug.log.
Open de log en kijk naar de onderste (nieuwste) regels, rond het tijdstip waarop de fout optrad. Je zoekt naar regels als:
[02-Aug-2026 09:14:22 UTC] PHP Fatal error: Uncaught Error: Call to undefined function
wp_super_functie() in /home/klant/public_html/wp-content/plugins/voorbeeldplugin/init.php:87
Deze ene regel vertelt je alles: het is een PHP-fout (fatal), hij ontstaat in de plugin voorbeeldplugin, in regel 87 van init.php. Je weet nu precies welke plugin je moet uitschakelen. Zo'n concreet pad naar een plugin- of thememap is in de praktijk de snelste route naar de oplossing.
Zie je géén PHP-fouten rond het tijdstip van de storing? Dan komt PHP waarschijnlijk niet eens aan de beurt — en dan wijst alles naar de .htaccess. Daarover hieronder meer.
Is je .htaccess de boosdoener?
In mijn eigen praktijk is dit veruit de vaakste dader: een .htaccess-bestand dat door een caching- of securityplugin is volgeschreven met regels die de server niet accepteert of die elkaar in de weg zitten. De plugin bedoelt het goed — browsercaching, firewallregels, redirects — maar één regel die jouw server niet kent, en Apache of LiteSpeed weigert de hele site met een 500.
Typische signalen dat het aan de .htaccess ligt:
- De fout ontstond direct na het installeren, updaten of juist verwijderen van een caching-, security- of SEO-plugin.
- De error_log toont geen PHP-fouten, maar de site geeft wel overal 500.
- In de server-log (als je die kunt inzien) staat iets als
Invalid commandof.htaccess: ... not allowed here.
De test is simpel en veilig. Hernoem het bestand tijdelijk via FTP of SSH:
mv .htaccess .htaccess-kapot
Laad je site opnieuw. Werkt de homepage nu (ook al geven onderliggende pagina's misschien een 404 door ontbrekende rewrite-regels)? Dan heb je de dader. Zet voor WordPress vervolgens een schone standaard-.htaccess terug:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Werkt de site daarmee volledig, dan weet je dat de extra regels van een plugin het probleem waren. Configureer die plugin opnieuw (of laat hem zijn regels opnieuw schrijven) en test na elke wijziging. Gooi het oude bestand pas weg als alles een paar dagen goed draait — het is je bewijsmateriaal.
Hoe spoor je een PHP-fout in een plugin of thema op?
Staat er wél een PHP Fatal error in de log, dan wijst het bestandspad je de weg. Staat er /wp-content/plugins/naam-van-plugin/ in het pad? Dan is die plugin de schuldige. Staat er /wp-content/themes/ in? Dan is het je thema.
Plugin uitschakelen zonder werkende beheeromgeving — want bij een 500-fout kun je meestal niet meer inloggen op wp-admin. Via FTP of bestandsbeheer hernoem je de map van de verdachte plugin:
mv wp-content/plugins/voorbeeldplugin wp-content/plugins/voorbeeldplugin-uit
WordPress schakelt een plugin automatisch uit als de map niet meer bestaat. Site weer online? Dan zoek je een update van die plugin, of een alternatief.
Weet je niet wélke plugin het is, dan hernoem je de hele pluginmap (plugins naar plugins-uit), controleert of de site het dan doet, zet de map terug en hernoemt de plugins daarna één voor één tot de fout terugkeert. Bewerkelijk, maar waterdicht.
Thema's en PHP-versies. De tweede klassieker uit mijn dagelijkse praktijk: na een PHP-upgrade (bijvoorbeeld van 7.4 naar 8.2) valt een ouder thema om. Functies die in oude PHP-versies nog werkten, bestaan in nieuwe versies niet meer, en het thema is nooit bijgewerkt. De log toont dan een fatal error met een pad in de thememap. De nette oplossing is het thema (laten) updaten of vervangen; de tijdelijke pleister is via je hostingpaneel terugschakelen naar de vorige PHP-versie, zodat de site draait terwijl je het thema aanpakt. Blijf niet permanent op een oude PHP-versie hangen — die versies krijgen op den duur geen beveiligingsupdates meer en zijn bovendien trager.
Memory limit. Meldt de log Allowed memory size of 134217728 bytes exhausted, dan vraagt je site meer geheugen dan PHP mag gebruiken. Verhogen kan in wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
Of serverbreed via je hostingpaneel of een .user.ini/php.ini:
memory_limit = 256M
Let wel: als een site ineens véél meer geheugen nodig heeft dan voorheen, is dat vaak een symptoom — een plugin die in een loop hangt of een import die te groot is. Verhoog het limiet, maar vraag je ook af waaróm het nodig werd.
Bestandspermissies. Minder vaak, maar het komt voor: verkeerde permissies na een handmatige upload of migratie. De vuistregel op vrijwel elke hosting is 755 voor mappen en 644 voor bestanden. Bestanden op 777 of met de verkeerde eigenaar kunnen op servers met suPHP/PHP-FPM juist een 500 veroorzaken — de server weigert dan uit veiligheid. Herstellen kan via SSH:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
Geen SSH? Je hoster doet dit in een paar seconden voor je.
Welke stappen doorloop je bij een 500-fout?
Alles samengevat in de volgorde die ik zelf aanhoud:
- Wat is er net veranderd? Een update, nieuwe plugin, PHP-wissel, migratie? De fout ontstaat vrijwel nooit spontaan. Het antwoord op deze vraag halveert je zoektijd.
- Lees de error_log. Nieuwste regels eerst. PHP Fatal error met pad → ga naar stap 3. Geen PHP-fouten → ga naar stap 4.
- Schakel de aangewezen plugin of het thema uit door de map via FTP te hernoemen. Site werkt weer? Oorzaak gevonden; nu updaten of vervangen.
- Test de .htaccess door hem te hernoemen en (bij WordPress) de schone standaardversie terug te zetten.
- Check geheugen en permissies als de log daarop wijst (
memory exhausted, permission-meldingen). - Denk aan de PHP-versie. Recent geüpgraded? Schakel tijdelijk terug en kijk of de fout verdwijnt.
- Nog steeds 500 zonder aanwijzing? Dan zit het dieper — op serverniveau. Tijd voor stap 8.
- Schakel je hoster in.
Werk in deze volgorde en verander één ding per keer. Wie drie dingen tegelijk aanpast en de site ziet terugkomen, weet nog steeds niet wat de oorzaak was — en dan komt de fout terug op het slechtst denkbare moment.
Wanneer schakel je je hoster in?
Er is een grens aan wat je als site-eigenaar zelf kunt zien. Neem contact op met je hoster als:
- Je niet bij de error_log kunt of de log leeg blijft terwijl de fout aanhoudt. De echte melding staat dan waarschijnlijk in de serverlogs, waar alleen de beheerder bij kan.
- De fout komt en gaat. Een 500 die af en toe opduikt bij drukte wijst vaak op een PHP-FPM-pool die tegen zijn limieten aanloopt of een server onder te hoge load — dat is serverbeheer, geen sitebeheer.
- Meerdere sites op je pakket tegelijk plat liggen. Dan is het vrijwel zeker een serverprobleem en hoef jij niets te doen behalve melden.
- Je de stappen hierboven hebt doorlopen zonder resultaat. Op dat punt kost verder zelf zoeken je meer dan een belletje of appje.
Wees daarbij concreet: meld sinds wanneer de fout optreedt, wat je als laatste hebt gewijzigd en wat je al hebt geprobeerd. Met die drie gegevens vindt een beheerder de oorzaak in de serverlogs meestal binnen enkele minuten — zonder die gegevens begint hij bij nul.
Hoe voorkom je een volgende 500-fout?
Helemaal uitsluiten kun je het nooit, maar deze gewoontes schelen enorm:
- Maak een back-up vóór elke update van plugins, thema's of PHP-versie. Gaat het mis, dan zet je terug en zoek je rustig uit wat er gebeurde — zonder dat je site uren plat ligt. Controleer ook af en toe of je back-ups echt teruggezet kúnnen worden. Zie ook WordPress veilig up-to-date houden met updates, staging en back-ups.
- Update regelmatig en in kleine stappen. Wie maandelijks bijwerkt, weet bij een fout meteen welke van de drie updates de dader is. Wie na twee jaar veertig updates tegelijk draait, zoekt een speld in een hooiberg.
- Test een PHP-upgrade eerst. Veel hostingpanelen laten je per site van PHP-versie wisselen. Zet een testkopie (staging) op de nieuwe versie en klik de site door voordat je de live site omzet.
- Wees zuinig met plugins die aan je .htaccess komen. Elke caching- of securityplugin die eigen serverregels schrijft, is een extra kandidaat voor deze fout. Eén goede oplossing per taak is genoeg; twee cachingplugins naast elkaar is vragen om problemen.
- Kijk af en toe zelf in de error_log, ook als de site het gewoon doet. Warnings en notices van vandaag zijn vaak de fatal errors van morgen. Vijf minuten per maand geeft je een flinke voorsprong.
Met deze gewoontes verklein je zowel de kans op een 500-fout als de tijd die je kwijt bent als het toch een keer misgaat.