Wat betekent een 500 Internal Server Error in WordPress?

HTTP 500 is een algemene serverfout: de server kon het verzoek niet afhandelen, maar de statuscode noemt de precieze oorzaak niet. Je hebt daarom het exacte tijdstip, de getroffen URL en de server- of PHP-log nodig om gericht te zoeken.

Kan een WordPress-plugin een 500-fout veroorzaken?

Ja. Een PHP-fout, incompatibele update of verkeerd ingestelde plugin kan een 500-respons veroorzaken. Schakel plugins gecontroleerd uit, test na iedere wijziging en zet de oorspronkelijke mapnaam terug als de fout niet verandert.

Moet ik .htaccess verwijderen bij een 500-fout?

Nee. Maak op Apache of LiteSpeed eerst een kopie en hernoem het bestand tijdelijk, zodat je het direct kunt terugzetten. Op Nginx wordt .htaccess niet gebruikt en moet je de serverconfiguratie of hostinglogs onderzoeken.

Waarom werkt wp-admin wel terwijl de voorkant een 500-fout geeft?

Dan ligt de oorzaak waarschijnlijk in een laag die vooral bij de voorkant wordt geladen, zoals het actieve thema, een template, cache of routegebonden pluginlogica. Het is geen bewijs, dus bevestig de oorzaak met logs en één test tegelijk.

Mag ik WP_DEBUG aanzetten op een live site?

Alleen kort en gecontroleerd als dat nodig is. Laat fouten naar een beschermd log schrijven, zet WP_DEBUG_DISPLAY op false en verwijder gevoelige loggegevens en tijdelijke instellingen direct na de diagnose.

Helpt het verhogen van de PHP-geheugenlimiet altijd?

Nee. Alleen een logmelding over uitgeput geheugen ondersteunt die hypothese. Verhoog nooit onbeperkt en onderzoek welke plugin, query of verwerking het geheugen verbruikt, anders verberg je de oorzaak.

Wanneer moet de hostingprovider een WordPress 500-fout onderzoeken?

Vraag de provider om hulp als ook statische bestanden of meerdere sites falen, je geen serverlogs hebt, rechten of PHP-instellingen onduidelijk zijn, of de fout na een veilige plugin-, thema- en configuratietest blijft bestaan.

WordPress 500 Internal Server Error oplossen (2026)

Een 500 Internal Server Error betekent dat de server het verzoek niet kon afhandelen, maar de statuscode vertelt niet welke WordPress-, PHP- of serverlaag faalde. Noteer de exacte URL en het tijdstip, controleer eerst de server- en PHP-log en draai daarna één recente wijziging per keer terug.

Bepaal eerst de omvang van de fout

Test zonder iets te wijzigen een kleine set routes:

de startpagina;
één gewone inhoudspagina;
/wp-admin/;
de inlogpagina;
een bestaand statisch bestand, zoals een afbeelding.

Noteer per route de status en het tijdstip. Als alleen één pagina faalt, is routegebonden code of inhoud aannemelijker. Als /wp-admin/ werkt maar de voorkant niet, kijk je eerder naar thema, pagina-cache of code die alleen in templates draait. Als ook statische bestanden mislukken, ligt het probleem mogelijk vóór WordPress bij de webserver, proxy of hostingconfiguratie.

Een 500-status is iets anders dan een databaseverbindingsfout, 403 Forbidden of 404. Controleer de echte HTTP-status in het hostingpaneel of de browsernetwerkinformatie, want een vormgegeven foutpagina kan de tekst “server error” tonen terwijl de status anders is.

Maak herstel mogelijk voordat je ingrijpt

Maak een actuele database-export en download de WordPress-bestanden, inclusief wp-config.php, .htaccess en wp-content. WordPress legt in de officiële back-uphandleiding uit dat bestanden en database samen één herstelset vormen. Controleer of de export kan worden geopend en leg vast welk herstelpunt bij welke bestanden hoort.

Heb je al een 500-fout en lukt een nieuwe back-up niet, controleer dan eerst de beschikbare hostingsnapshot. Overschrijf geen live database met een oude kopie als er sinds die kopie bestellingen, formulieren of andere gegevens zijn toegevoegd. Een rollback moet herstelbaar én passend bij de actuele data zijn.

Maak voor ieder bestand dat je test een kopie met een herkenbare naam. Noteer de oorspronkelijke mapnamen en instellingen. Verander één laag, test dezelfde URL, en zet de laag terug als het resultaat niet verandert.

Stap voor stap een WordPress 500-fout onderzoeken

1. Controleer hostingstatus en recente wijzigingen

Bekijk of de provider een storing, onderhoud of wijziging van PHP, webserver of database meldt. Controleer ook jouw eigen tijdlijn: begon de fout direct na een pluginupdate, themawijziging, PHP-upgrade, migratie of aanpassing in .htaccess?

Rol alleen de laatst bekende wijziging terug als je daarvoor een betrouwbare kopie hebt. Zet niet tegelijk PHP terug, plugins uit en .htaccess opzij. Zelfs wanneer de site dan werkt, weet je niet welke laag de oorzaak was.

2. Lees de server- en PHP-log op het juiste tijdstip

Open in het hostingpaneel de errorlog van de webserver en PHP. Herhaal één verzoek naar de getroffen URL en zoek direct daarna naar dezelfde tijd en route. Een PHP-fatal, syntaxisfout, ontbrekend bestand, geheugentekort, rechtenfout of ongeldige serverrichtlijn vraagt telkens om een andere oplossing.

De WordPress-documentatie voor debugging beschrijft hoe je tijdelijk naar een log kunt schrijven zonder fouten aan bezoekers te tonen:

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

Plaats definities vóór de afsluitende opmerking in wp-config.php en voorkom dubbele constanten. Op productie blijft WP_DEBUG_DISPLAY uit. Een log kan paden, querydetails en persoonsgegevens bevatten, dus maak het niet publiek, deel alleen opgeschoonde regels en verwijder of archiveer het veilig na afloop.

WordPress-logging helpt niet altijd. Als PHP de configuratie niet kan lezen of de webserver het verzoek eerder afwijst, staat de bruikbare fout alleen in de hostinglog.

3. Draai de verdachte wijziging terug

Noemt het log één plugin- of themabestand en begon de fout na een update, zet dan de vorige geteste versie terug vanuit je back-up of gebruik de rollback van je beheerplatform. Download plugin- of themabestanden alleen van de officiële leverancier en behoud eerst de huidige map als bewijs.

Test na de rollback precies dezelfde URL. Blijft de status 500, herstel dan de uitgangssituatie en ga door. Verwijder niet alvast andere onderdelen omdat ze “ook verdacht” lijken.

4. Isoleer normale plugins via het bestandssysteem

Kun je niet inloggen, hernoem dan via SFTP of het hostingbeheer tijdelijk wp-content/plugins naar bijvoorbeeld plugins.test-uit. De officiële WordPress-probleemoplossing beschrijft deze methode wanneer het beheer niet bereikbaar is.

Laad één getroffen route opnieuw. Werkt de site, zet de mapnaam exact terug en activeer of test plugins daarna één voor één vanuit het beheergedeelte. Maak bij een drukke site deze test liever in staging, want pluginfuncties zoals formulieren, betalingen en beveiliging zijn tijdelijk niet actief.

Blijft de fout, zet de oorspronkelijke mapnaam meteen terug. Controleer apart wp-content/mu-plugins en drop-ins zoals object-cache.php alleen als het log of de hostingconfiguratie daarnaar wijst. De gewone pluginsmap uitschakelen raakt die lagen niet.

5. Test het actieve thema zonder data te verwijderen

Noemt het log een bestand in het actieve thema, schakel dan in een stagingomgeving tijdelijk naar een geïnstalleerd standaardthema. Als het beheergedeelte niet opent, laat je dit via een veilige beheerroute of door een ontwikkelaar doen. Alleen een themamap hernoemen is pas verantwoord als je hebt gecontroleerd dat een werkend terugvalthema aanwezig is en je de originele naam direct kunt herstellen.

Werkt de route met het standaardthema, herstel dan eerst de productiepresentatie en onderzoek de genoemde template, hook of recente themawijziging. Pas het WordPress-corebestand niet aan. Lees bij een lege pagina zonder zichtbare status ook de route voor het witte scherm in WordPress.

6. Isoleer .htaccess alleen op de juiste webserver

Op Apache en vaak LiteSpeed kan een foutieve regel in .htaccess een 500-status geven. Download het bestand, noteer de rechten en hernoem het tijdelijk naar .htaccess.voor-500-test. Verwijder het niet. Test daarna dezelfde URL.

Werkt de site, maak dan via Instellingen > Permalinks een nieuwe standaardconfiguratie of laat de host de ongeldige richtlijn aanwijzen. Voeg maatwerkregels daarna één voor één terug. Werkt de site niet, herstel direct de originele bestandsnaam.

Nginx leest geen .htaccess. Daar heeft hernoemen geen diagnostische waarde en moet je de Nginx-configuratie, deployhistorie en errorlog laten controleren. Ontstaan na het vernieuwen van permalinks alleen 404-fouten, gebruik dan de aparte handleiding voor 404 na permalinks.

7. Controleer PHP-versie, extensies en limieten met bewijs

Vergelijk de actieve PHP-versie en extensies met de eisen van WordPress, thema en plugins. Een wijziging in het hostingpaneel geldt soms per domein of per map, dus controleer welke runtime het getroffen verzoek werkelijk gebruikt. Zet een versie niet blind terug op productie als beveiligingsupdates of andere sites daarvan afhankelijk zijn.

Zoek in het log naar de concrete fout:

Allowed memory size exhausted vraagt om onderzoek naar geheugenverbruik, niet automatisch een hoge limiet. Volg de WordPress-geheugenlimiet.
Maximum execution time exceeded vraagt om het isoleren van de trage taak via de max execution time-handleiding.
Undefined function of een ontbrekende extensie vraagt om controle van PHP-modules en compatibiliteit.
Parse error wijst vaak naar een fout in recent gewijzigde PHP-code.

Verhoog limieten nooit onbeperkt. Een ruimere limiet kan een slecht begrensde import of lus langer laten draaien en de server zwaarder belasten zonder de oorzaak weg te nemen.

8. Controleer rechten en eigenaarschap zonder 777

Een verhuizing, herstelactie of handmatige upload kan verkeerde bestandsrechten of een verkeerde eigenaar achterlaten. Vergelijk de getroffen bestanden met werkende bestanden en laat de hostingprovider de verwachte eigenaar en rechten bevestigen. Stel nooit alles recursief op 777 in: dat maakt bestanden onnodig schrijfbaar en lost verkeerd eigenaarschap niet betrouwbaar op.

Geeft het log aan dat één bestand niet leesbaar is, herstel dan alleen dat bestand vanuit een vertrouwde back-up of corrigeer gericht de door de host voorgeschreven rechten. Bewaar vooraf de oorspronkelijke waarden voor rollback.

9. Controleer cache, proxy en beveiligingslaag

Leeg pas na een inhoudelijke wijziging de relevante pagina-, object- en servercache. Een oude foutrespons kan anders blijven verschijnen, maar herhaald cache legen zonder wijziging is geen diagnose. Test waar mogelijk ook rechtstreeks op de origin via het hostingpaneel, zodat je ziet of een CDN of reverse proxy de 500 genereert of alleen doorgeeft.

Een beveiligingsplugin of web application firewall kan een verzoek blokkeren, maar dat geeft vaak een andere status. Schakel beveiliging niet breed en langdurig uit. Gebruik een opgeschoond log, een specifieke regel-ID en één tijdelijke uitzondering in overleg met de host.

10. Controleer herstel en ruim tijdelijke diagnose op

Test na de oplossing de oorspronkelijke URL, de startpagina, /wp-admin/ en de functie die de fout activeerde. Controleer ook de errorlog op nieuwe fouten. Een enkele 200-respons is niet genoeg als een formulier, geplande taak of beheeractie nog 500 geeft.

Zet tijdelijke debugdefinities terug, houd foutweergave uit op productie, bescherm of verwijder debug.log en herstel alle tijdelijk hernoemde bestanden. Noteer de oorzaak, wijziging en rollback. Controleer later nogmaals of de fout niet onder belasting terugkomt. Geen van deze stappen garandeert dat iedere 500-fout lokaal oplosbaar is, omdat de oorzaak ook buiten jouw WordPress-installatie kan liggen.

Veelgemaakte fouten

Alle plugins, het thema en PHP tegelijk wijzigen. Daarmee verdwijnt het bewijs welke laag faalde.
Foutdetails op de live pagina tonen. Logs horen beschermd te zijn en WP_DEBUG_DISPLAY blijft op productie uit.
Een debuglog ongefilterd delen. Logs kunnen serverpaden, persoonsgegevens en andere gevoelige details bevatten.
.htaccess verwijderen zonder kopie. Hernoemen met rollback is veiliger en heeft op Nginx geen nut.
Bestandsrechten overal op 777 zetten. Dit vergroot het beveiligingsrisico en maskeert mogelijk verkeerd eigenaarschap.
De geheugenlimiet onbeperkt verhogen. Doe dat alleen begrensd en bij een passende logmelding, terwijl je de verbruiker onderzoekt.
Een pluginmap uit laten staan na een negatieve test. Zet de oorspronkelijke staat terug voordat je de volgende laag test.
Cache verwarren met oorzaak. Een cache kan een oude respons tonen, maar verklaart niet vanzelf waarom de origin 500 gaf.
Een oude databaseback-up direct terugzetten. Daarmee kun je nieuwe gegevens overschrijven die niets met de serverfout te maken hebben.

Wanneer je hosting of een ontwikkelaar nodig hebt

Stop als je geen herstelbare back-up hebt, geen serverlogs kunt inzien, de fout ook statische bestanden raakt of rechten en eigenaarschap onduidelijk zijn. Laat ook een specialist meekijken bij terugkerende fouten onder belasting, aangepaste serverconfiguratie, multisite of een productieomgeving met actuele transacties.

Lever het exacte tijdstip, de getroffen routes, recente wijzigingen en enkele opgeschoonde logregels aan. Deel geen wachtwoorden, API-sleutels, cookies of volledige configuratiebestanden. Op de WordPress-hub vind je de beslisroutes voor andere meldingen en onderhoudsproblemen.

Wil je dat iemand de serverfout en herstelroute gecontroleerd onderzoekt, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.