Contact
← Terug naar kennisbank HOSTING

500 Internal Server Error — wat het betekent en hoe je 'm oplost

Je site geeft alleen nog: "500 Internal Server Error". Geen plugin-naam, geen regel code, geen aanwijzing. De server zegt: "er is iets mis, maar ik vertel je niet wat." Frustrerend — maar in 9 van de 10 gevallen vind je de échte oorzaak binnen 10 minuten als je weet waar te kijken. Deze gids loopt alle veelvoorkomende oorzaken door, met diagnose-stappenplan, concrete fixes per scenario en een checklist die je kunt afvinken.

17 min lezen · Laatst gecheckt:

De varianten die je in beeld kunt krijgen, allemaal hetzelfde onderliggende statusbericht:

  • 500 Internal Server Error
  • HTTP Error 500
  • HTTP Status 500 — Internal Server Error
  • The server encountered an internal error or misconfiguration and was unable to complete your request
  • The website cannot display the page — HTTP 500
  • Sommige hosters tonen een gestylde foutpagina met dezelfde boodschap in eigen huisstijl

De HTTP-statuscode is altijd 500 — een server-side fout-categorie waarmee de server in feite zegt: "er ging iets fout terwijl ik je request afhandelde, maar ik kan of mag niet vertellen wat exact." In tegenstelling tot een 404 (pagina niet gevonden) of 403 (toegang geweigerd) is een 500 een vergaarbak voor alles wat onverwacht fout ging.

Waarom toont de server geen detail?

Bewuste keuze. Apache, Nginx en PHP verbergen technische details voor het publiek omdat:

  • Stack traces lekken interne paden, versies en code-structuur
  • Foutmeldingen kunnen credentials of database-namen bevatten
  • Aanvallers gebruiken die info actief om zwakheden te vinden

Voor jou betekent het: de echte foutmelding staat in het error_log — niet in je browser. Daar ga je dus eerst kijken.

Stap 1: lees het server error_log

Dit is veruit de belangrijkste stap. In 80% van de gevallen vind je hier exact wat er fout is.

Plek per control panel

  • cPanel: Metrics → Errors. Toont de laatste 300 entries uit het error_log
  • Plesk: Logs → klik op je domein → Error Log. Of: Files → logs/error_log
  • DirectAdmin: Domain Setup → klik domein → "Domain logs" → Error log
  • Hosting zonder paneel: vraag je hoster waar het log staat (vaak ~/logs/error_log of /var/log/apache2/error_log)

Via SSH

# Laatste 100 regels
tail -100 ~/logs/error_log

# Live meekijken — refresh de site in een andere tab
tail -f ~/logs/error_log

De tail -f-truc is goud waard: laat 'm openstaan, refresh de pagina die de 500 geeft, en je ziet exact welke nieuwe entry binnenkomt — die is gegarandeerd jouw oorzaak.

Wat zoek je?

Recent (binnen het laatste uur) geschreven entries die overeenkomen met de URL die de 500 geeft. Typische foutmeldingen die je daar ziet:

  • PHP Fatal error: Uncaught Error: ... → PHP-code crasht
  • Allowed memory size of X bytes exhausted → memory-fout
  • Maximum execution time of N seconds exceeded → script te traag
  • .htaccess: Invalid command 'X', perhaps misspelled → htaccess-fout
  • Premature end of script headers → PHP crasht of file permissions
  • Permission denied → file permissions verkeerd
  • ModSecurity: Access denied → web application firewall blokkeert

Elke regel in het error_log heeft een tijdstempel, een type (Notice/Warning/Error/Fatal) en het pad/bestand. De fatal errors zijn meestal je boosdoener — de notices en warnings vaak ruis.

De acht veelvoorkomende oorzaken — met fixes per scenario

1. .htaccess syntax-fout of niet-ondersteunde directive

Veruit de meest voorkomende oorzaak na een edit aan .htaccess. Eén verkeerd geplaatst karakter, één directive die jouw hoster niet toestaat, en de hele site valt om. Foutmelding in error_log: Invalid command 'X', perhaps misspelled or defined by a module not included in the server configuration.

Snelle test: hernoem .htaccess tijdelijk naar .htaccess.bak. Werkt de site weer? Dan zat 't in htaccess. Voeg regels één voor één terug om te vinden welke crasht.

Schone WordPress-default:

# 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

Zie ook .htaccess uitgelegd voor algemene context, en ERR_TOO_MANY_REDIRECTS oplossen als je htaccess-fout een redirect-loop maakt.

2. PHP fatal error in code, plugin of theme

Een plugin- of theme-update die niet compatibel is met je PHP-versie, een PHP-versie die net is geüpgraded, of corrupt code. Foutmelding in error_log begint met PHP Fatal error.

Voorbeelden van wat je kunt zien:

PHP Fatal error: Uncaught Error: Call to undefined function ...
PHP Fatal error: Cannot redeclare class ...
PHP Fatal error: syntax error, unexpected '?'
PHP Fatal error: Required parameter follows optional parameter

Bij WordPress: zie WordPress critical error oplossen voor het complete stappenplan om plugins en theme te isoleren. Snelle aanpak: hernoem wp-content/plugins naar plugins-uit en kijk of de site terugkomt. Zo ja, één voor één plugins terug activeren.

Bij andere CMS-en: deactiveer de meest recent geïnstalleerde of geüpdate component. De boosdoener is bijna altijd het laatst-gewijzigde stuk.

Bij PHP-versie-upgrade als oorzaak: zie PHP-versie veilig upgraden.

3. Memory_limit overschreden

Foutmelding: Allowed memory size of X bytes exhausted. PHP probeerde meer geheugen te claimen dan toegestaan. Soms eenmalige piek, soms structureel probleem met een plugin die te veel laadt.

Quick fix: verhoog limiet via wp-config.php (WordPress) of .user.ini:

// WordPress wp-config.php
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// .user.ini in webroot
memory_limit = 256M

Volledige aanpak inclusief wanneer verhogen géén oplossing is: Allowed memory size exhausted oplossen.

4. Maximum execution time overschreden

Foutmelding: Maximum execution time of 30 seconds exceeded. Een PHP-script duurde langer dan toegestaan. Veelvoorkomende oorzaken: trage database-queries, externe API-calls die hangen, een import-functie die teveel doet in één request.

Verhogen via .htaccess (als je hoster php_value-directives toestaat):

php_value max_execution_time 300

Of via .user.ini:

max_execution_time = 300

Maar zoals bij memory: vaak is "het script duurt te lang" een symptoom van slecht-presterende code, niet van een te lage limiet. Bij regelmatig terugkomen is performance-onderzoek nodig — zie trage WordPress site versnellen voor diagnose-aanpak.

5. Onjuiste file permissions

Op Linux-hosting moeten bestanden en mappen specifieke permissies hebben:

  • Mappen: 755 (drwxr-xr-x) — eigenaar lezen/schrijven/uitvoeren, anderen lezen/uitvoeren
  • PHP-bestanden: 644 (rw-r--r--) — eigenaar lezen/schrijven, anderen alleen lezen
  • Speciale bestanden (zoals wp-config.php): 600 of 640
  • Configuratie-bestanden als sommige hosters: 444 (read-only)

Wat NIET mag: 777 op bestanden of mappen — sommige Apache-configuraties weigeren bestanden te serveren met te ruime rechten en geven 500. Plus: 777 is een grote security-risk.

Permissies herstellen via SSH:

cd /home/jouwsite/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php  # voor WordPress

Of via FTP/file manager: rechtsklik bestand/map → "Change Permissions" → vul de juiste waarde in.

6. PHP-versie-incompatibiliteit

Hoster heeft PHP 7.4 uitgeschakeld, jouw site staat nu op 8.2 — en oude code crasht. Foutmelding: vaak een PHP fatal met termen als undefined function, cannot redeclare of een syntax-error.

Tijdelijke fix: PHP-versie terugzetten naar de oude in je control panel. Werkt soms nog 1-2 weken voordat hoster definitief uitschakelt.

Echte fix: code/plugins/theme moderniseren of vervangen. Zie PHP-versie veilig upgraden voor het volledige stappenplan en compatibility-tools.

7. ModSecurity / web application firewall blokkeert

Sommige hosters draaien ModSecurity (een WAF — web application firewall) die requests blokkeert die op een aanval lijken. Foutmelding in error_log: ModSecurity: Access denied with code 500 gevolgd door welke regel triggerde.

Triggers zijn vaak: form-submits met SQL-achtige tekens, bestand-uploads met verdachte content, file managers van plugins. False positives zijn zelden zeldzaam.

Fix: hosting support vragen om de specifieke ModSecurity-rule uit te schakelen voor jouw site of voor de URL die crasht. Niet zelf in code proberen te fixen — 't zit op server-niveau.

8. Database-issues die een 500 maskeren

Soms presenteert een database-fout zich als een 500. Bij WordPress zie je vaker "Error establishing a database connection", maar oudere of custom code crasht stiller en leidt tot 500. Foutmelding in error_log: mysqli_connect()-warnings of mysqli_query()-fouten.

Volledige aanpak: Warning: mysqli foutmeldingen oplossen.

Speciale gevallen

500 alleen op één pagina (rest werkt)

Andere oorzaak dan een site-brede 500. Mogelijkheden:

  • Plugin- of theme-functie die alleen op die pagina draait crasht
  • Custom code in de page-template heeft een bug
  • WAF-rule blokkeert specifieke URL-patroon (bijvoorbeeld /wp-admin/admin-ajax.php)
  • Bestand op die URL ontbreekt of heeft verkeerde permissies

Aanpak: error_log filteren op exacte timestamp van de mislukte request, en de URL erbij zoeken.

500 alleen op /wp-admin/

Frontend werkt, admin niet. Veelvoorkomende oorzaken:

  • Plugin breekt admin-only code (deactiveer via FTP-rename)
  • memory_limit te krap voor admin-acties (admin gebruikt meer geheugen dan frontend)
  • ModSecurity blokkeert admin-requests
  • Beschadigde core-files in /wp-admin/ (re-install via WP-CLI: wp core download --force)

500 intermittent — komt en gaat willekeurig

Niet permanent, maar regelmatig. Vrijwel altijd een resource-issue:

  • Hosting heeft per-minuut of per-uur rate limits die je raakt op piek-momenten
  • Memory-pieken bij specifieke zware queries
  • "Entry processes"-limiet bij CloudLinux-hosting bereikt
  • Bot- of crawler-aanval die resources opeet

Aanpak: error_log analyseren over meerdere uren, kijken naar patroon (welk tijdstip? welke URLs? welke User-Agents?). Vaak is er een specifieke trigger.

500 na een hosting-migratie

Net verhuisd, alles moet werken, maar 500. Volgorde van checken:

  1. .htaccess: regels die op oude hosting werkten kunnen op nieuwe niet werken (mod_php vs PHP-FPM, andere Apache-versie)
  2. File permissions: zip-tools of FTP-clients zetten soms verkeerde permissies bij overdracht
  3. PHP-versie verschillend: oude hoster draaide 7.4, nieuwe staat default op 8.2
  4. Database-credentials: andere hostnaam, andere user, andere wachtwoord
  5. PHP-extensies ontbreken: nieuwe hoster heeft niet alle modules die je gebruikte

Volledige migratie-aanpak die deze valkuilen voorkomt: website migreren zonder downtime.

Diagnose-stappenplan in volgorde

  1. Open error_log via control panel of SSH. Lees de laatste 50 regels
  2. Identificeer type fout: PHP fatal? htaccess? memory? permissions? Zie de scenario's hierboven
  3. Klopt timing met laatste wijziging? Recent een plugin geüpdatet, .htaccess bewerkt, hosting iets veranderd? Daar zit je oorzaak in 70% van de gevallen
  4. Snelle htaccess-test: hernoem .htaccess naar .htaccess.bak. Werkt site weer? Probleem geïsoleerd
  5. WordPress: plugins-test: hernoem wp-content/plugins. Werkt site weer? Plugin is boosdoener
  6. File permissions check: te ruim (777) of te krap (600 op pagina-bestanden)? Herstellen via SSH of file manager
  7. Memory & execution time: error_log-melding wijst hierheen? Verhogen of optimaliseren
  8. PHP-versie check: recent gewijzigd? Tijdelijk terug naar oude
  9. Lukt 't nog niet: hosting support contacten met exact citaat uit error_log. Zij zien meer dan jij (firewall logs, server-resource-graphs, andere klanten met zelfde issue)

Foutmelding zelf zichtbaar maken — alleen op staging of tijdelijk

Tijdens diagnose kun je PHP forceren om de fout op het scherm te tonen — handig als error_log onbereikbaar is:

// In wp-config.php (WordPress) of bovenin index.php (custom)
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

// Voor WordPress specifiek:
define('WP_DEBUG', true);
define('WP_DEBUG_DISPLAY', true);

Belangrijk: dit doet 't lekken-naar-bezoekers ding waarvoor de 500 zelf bestaat om te voorkomen. Alleen tijdelijk (5 minuten) en alleen als de site al down is. Direct daarna terugzetten op:

ini_set('display_errors', 0);
define('WP_DEBUG_DISPLAY', false);

Preventie

  • Test wijzigingen op staging eerst. Een 500 op staging is een leerervaring; op productie is 't downtime. Zie WordPress staging site opzetten
  • Backup voor elke significante wijziging: htaccess-edit, PHP-upgrade, plugin-installatie, theme-switch. Met backup ben je in 5 minuten terug; zonder kost 't uren
  • Update incrementeel: één plugin tegelijk, niet 10 in één klap. Bij 500: weet je direct welke
  • Monitor je error_log periodiek: 500's komen vaak met waarschuwingsteken eraan. Een wekelijkse blik in error_log laat zien welke plugins/code regelmatig PHP-warnings geven, vóór ze fatal worden
  • Uptime monitoring aan: UptimeRobot, Better Stack of vergelijkbaar. Krijg binnen minuten alert in plaats van uren later "klant belde"
  • PHP-versie up-to-date: oude PHP genereert vaker 500's bij kleinste compatibility-issue. Zie PHP-versie veilig upgraden
  • Hosting met fatsoenlijk error-log-toegang: budgethosters die je geen toegang tot error_log geven zijn een rode vlag. Zonder dat log debug je blind
Belangrijkste lesje: de 500-melding zelf is bijna nooit informatief. Kijk niet langer dan 30 seconden naar je browser — open meteen het error_log. De échte fout staat daar in 80% van de gevallen letterlijk uitgeschreven, met bestandspad en regelnummer.

Wanneer schakel je hulp in?

  • Error_log is leeg of onbereikbaar en je weet niet waar je anders moet kijken
  • Foutmelding vermeldt een bestand of regel maar je begrijpt niet wat er mis is
  • 500 keert terug zodra je 'm "fixt" — symptoom dat dieper zit (resource-limiet, memory leak, hosting-issue)
  • 500 komt willekeurig op, hosting-resource-graph laat geen duidelijke trigger zien
  • Net een migratie afgerond en de site geeft direct 500 — vraagt om systematische diagnose
  • WooCommerce-shop, betaalpagina geeft 500 → orders gaan verloren, dit moet binnen het uur weg
  • Hosting support zegt "geen issue aan onze kant" maar de site is offline — derde partij voor onafhankelijke diagnose
  • Custom code waarvan oorspronkelijke ontwikkelaar niet beschikbaar is en de fout zit dáár

Een 500 lijkt mysterieus omdat de browser je niets vertelt — maar de server vertelt het wel, in het error_log. 80% van mijn 500-debugcalls worden binnen het halfuur opgelost door simpelweg de juiste regels in dat log te lezen en de bijbehorende fix toe te passen. De resterende 20% is waar ervaring en stapsgewijs uitsluiten waarde toevoegt — meerdere oorzaken tegelijk, hosting-quirks, niet-standaard configuraties. Deze gids haalt je in de meeste gevallen ruim binnen die 80%.