Er is een vast ritueel als je site een 500 internal server error geeft. Je hernoemt je .htaccess. Je zet je plugins uit. Je zet ze weer aan. Ergens in dat proces gaat de site het weer doen en weet je nog steeds niet waarom. Dat ritueel komt uit de handleidingen zelf: we lazen de vier Nederlandstalige gidsen die op 20 augustus 2026 in de Nederlandse top 10 stonden, en alle vier noemen .htaccess, plugins, thema’s en bestandsrechten van 644 en 755. Geen van de vier noemt één concreet getal over de limieten van je hostingpakket, terwijl daar in de praktijk een groot deel van de fouten vandaan komt.
Vijf van die tien resultaten komen trouwens van hostingbedrijven zelf. Dat verklaart een hoop: een host schrijft zelden een gids waarin staat dat de limieten van zijn eigen pakket het probleem zijn.
Wat een 500 internal server error eigenlijk zegt
Een 500 internal server error betekent dat de server een onverwachte situatie tegenkwam en je verzoek niet kon afronden. MDN omschrijft het als een generieke catch-all: de server valt terug op 500 wanneer hij geen passender 5xx-code kan vinden. Het is dus geen foutmelding maar de afwezigheid van een foutmelding. Alles kan erachter zitten: een verkeerde serverconfiguratie, een script dat door zijn geheugen heen ging, een onafgevangen exception, verkeerde bestandsrechten.
Een 500 error betekent overigens niet dat je site offline is. Je server staat gewoon aan en antwoordt, alleen met een foutmelding in plaats van met je pagina. Bij een echte storing krijg je helemaal geen antwoord en loopt je browser vast op een time-out. Dat onderscheid is handig, want een 500 kun je zelf oplossen en een storing niet.
Precies daarom is gokken zo inefficiënt. Je hebt tien mogelijke oorzaken en één symptoom. De informatie die dat terugbrengt tot één oorzaak ligt op je server, in het foutlog.
Begin bij je foutlog, dat scheelt een uur gokken
Wanneer PHP crasht, schrijft de server een regel weg met het tijdstip, het domein, het type fout, het bestandspad en het regelnummer. Die regel is je diagnose. Je hoeft niets uit te schakelen om erachter te komen welke plugin het doet, want de plugin staat er met naam en al in.
Het probleem is dat vrijwel niemand weet waar dat log staat, en dat de plek per host verschilt. Niet een beetje, maar echt: dezelfde handeling heet bij de een “Foutenlogboek” en bij de ander “full error log”, en soms zit hij helemaal niet in het logmenu maar in de bestandsbeheerder.
Waar het foutlog staat bij de Nederlandse hosts
Waar het foutlog van je website staat, hangt af van het controlepaneel dat je host gebruikt. Grofweg draait Nederland op drie smaken: DirectAdmin, Plesk en een eigen paneel. Dit is waar je moet zijn.
| Host | Paneel | Route naar het foutlog |
|---|---|---|
| Antagonist | DirectAdmin | Systeeminfo en bestanden → Statistieken en logs → Foutenlogboek |
| Vimexx | DirectAdmin | Hostingoverzicht → summary → full error log (of 10 / 100 lines) |
| Versio, mijn.host, bHosted | DirectAdmin | Statistieken en logs, of Site Summary → Error Log |
| Yourhosting, Cloud86 | Plesk | Websites en domeinen → domein → Dashboard → Logbestanden |
| Argeweb | Plesk (DirectAdmin loopt af) | Zelfde route als Plesk; oude accounts nog in DirectAdmin |
| TransIP | Eigen controlepaneel | Webhosting → domein → File Manager → map Logs → error.log |
| Hostnet | Mijn Hostnet | Diensten → hostingpakket → File Manager → Logs |
Twee dingen om te weten. Oudere logs worden ingepakt, bij TransIP bijvoorbeeld als error.log.1.gz, dus als je fout van vorige week is moet je eerst uitpakken. En bij grote sites is dat bestand enorm; open in DirectAdmin dan de laatste 100 regels in plaats van het volledige log, anders laadt je browser zich suf.
De vier logregels die je bijna altijd tegenkomt
Een foutlog leest makkelijker dan het eruitziet, want er zijn maar een handvol patronen. Deze vier dekken het overgrote deel van de 500-fouten op WordPress en vergelijkbare CMS’en.
Allowed memory size of 100663296 bytes exhausted. Je script wilde meer geheugen dan het mocht gebruiken. Dat getal is geen toeval: 100663296 bytes is precies 96 MB, de standaardwaarde die bijvoorbeeld Antagonist hanteert. Ziet je log dit, dan weet je meteen tegen welke muur je liep.
Call to undefined function. De code roept een functie aan die niet bestaat. Bijna altijd een plugin die niet compleet is bijgewerkt, of een PHP-versie die te nieuw of te oud is voor wat de plugin verwacht.
No such file or directory. Er ontbreken bestanden, meestal na een upload die halverwege afbrak. Het pad in de logregel vertelt je precies welke map je opnieuw moet uploaden.
Nothing to read from backend. Het PHP-proces werd afgebroken voordat het klaar was. Dit is de klassieke timeout of resource-limiet, en dit is de melding waarbij je naar je pakket moet kijken in plaats van naar je code.
De limieten van je pakket verschillen met een factor tien
Hier zit het inzicht dat de standaardgidsen overslaan. Elke gedeelde host zet grenzen aan wat één klant mag verbruiken, want anders legt één slecht script de hele server plat. Redelijk. Alleen: die grenzen verschillen dramatisch per aanbieder, en ze staan nergens in de vergelijkingstabel waarop je je pakket koos.
| Instelling | Antagonist | TransIP | Wat het doet |
|---|---|---|---|
| max_execution_time | 30 seconden | 300 seconden | Hoe lang een script mag draaien |
| upload_max_filesize | 32 MB | 256 MB | Grootste bestand dat je kunt uploaden |
| post_max_size | Niet gedocumenteerd | 256 MB | Grootste hoeveelheid formulierdata |
| memory_limit | 96 MB | Niet instelbaar in het paneel | Geheugen per PHP-script |
| max_input_vars | 1000 | Niet gedocumenteerd | Aantal invoervelden per verzoek |
Lees die eerste rij nog een keer. Een importscript dat bij TransIP rustig vijf minuten mag doorwerken, wordt bij Antagonist na dertig seconden afgekapt. Dat is een factor tien, bij exact dezelfde website en dezelfde code. Bij uploads is het verschil een factor acht. Wie ooit een webshop verhuisde en zich afvroeg waarom de import bij de nieuwe host halverwege stopte, heeft hier zijn antwoord.
Opvallend genoeg biedt TransIP in zijn paneel wel een tiental instellingen aan, maar geen memory_limit. Bij DirectAdmin-hosts zoals Antagonist, Vimexx en mijn.host zet je hem zelf om via de PHP-selector onder Options. Bij Hostnet loopt het weer anders: daar maak je een bestand met de naam .user.ini aan in je eigen map en zet je de waarden daarin. Drie hosts, drie werkwijzen, één probleem.
”De vraag is nooit of je website te zwaar is. De vraag is of je website te zwaar is voor de limieten die jouw host toevallig heeft ingesteld. Dezelfde WordPress-installatie draait bij de ene provider zonder klagen en valt bij de andere om na dertig seconden.”
WordPress zet zijn eigen plafond op 40 MB
Dan een valkuil waar vooral WordPress-gebruikers uren aan kwijt zijn. Je hebt netjes je memory_limit verhoogd naar 256 MB, je ververst de pagina en de foutmelding blijft. Dat komt doordat WordPress niet zomaar overneemt wat je host toestaat: het zet zijn eigen limiet.
WordPress probeert standaard 40 MB te gebruiken voor een gewone site en 64 MB voor multisite. Voor het beheergedeelte ligt het plafond hoger, op 256 MB. Wil je dat WordPress de ruimte gebruikt die je host je geeft, dan zet je in wp-config.php de regel define('WP_MEMORY_LIMIT', '256M'); boven de regel waar staat dat je moet stoppen met bewerken. Zonder die regel kun je bij je host verhogen wat je wilt, WordPress blijft op zijn eigen waarde zitten.
Overdrijf het niet. Een hoge limiet zorgt er alleen voor dat een lekkend script langer doorloopt voordat het stukgaat, en dat het intussen het geheugen van je hele pakket opsnoept. Vimexx adviseert niet boven de 2048 MB te gaan, en eerlijk gezegd is alles boven 512 MB voor een gewone website al een teken dat er iets anders mis is.
Waarom je bij dezelfde oorzaak soms een 503 krijgt
Dezelfde overbelasting levert bij verschillende hosts een andere foutcode op, en dat is een van de verwarrendste dingen aan 5xx-meldingen.
Bij hosts die op Plesk draaien, zoals Cloud86, ziet de server dat je pakket zijn CPU- of RAM-limiet raakt en vertraagt hij je site of toont een HTTP 503, met in het paneel de melding dat de physical memory limit is bereikt. Je site komt vanzelf weer terug zodra je onder de limiet zakt. Bij DirectAdmin-hosts landt zoiets vaker als een 500 of een wit scherm, omdat het PHP-proces zelf sneuvelt in plaats van dat het platform ingrijpt.
De praktische les: een 503 is een aanwijzing dat je pakket te krap zit, terwijl een 500 alle kanten op kan wijzen. Krijg je afwisselend beide, dan zit je vrijwel zeker tegen je limieten aan en niet in een codefout.
Zo pak je het aan, in volgorde
Een 500 internal server error pak je het snelst aan in onderstaande volgorde, omdat elke stap de volgende overbodig kan maken.
- Open je foutlog via de route van je host uit de tabel hierboven en zoek de laatste regel met een tijdstip dat past bij het moment dat de fout optrad.
- Lees welk bestand en welk regelnummer erin staan. Staat er een pluginmap in het pad, dan heb je je dader te pakken. Hernoem die map via de bestandsbeheerder door er
.oldachter te zetten en test opnieuw. - Zie je een melding over geheugen of een afgebroken proces, dan is het geen plugin maar een limiet. Verhoog memory_limit of max_execution_time via je paneel, of via .user.ini als je host dat zo doet.
- Draai je WordPress, controleer dan of WP_MEMORY_LIMIT in wp-config.php staat. Zonder die regel blijft je site op 40 MB hangen.
- Nu pas is je .htaccess aan de beurt. Hernoem hem naar .htaccess-oud en ververs. Werkt het weer, dan zat de fout in een regel daarin. Regenereer daarna je permalinks in WordPress.
- Komt het terug, kijk dan naar het resourceverbruik in je paneel. Zowel DirectAdmin als Plesk laten grafieken zien, en Antagonist bewaart die historie dertig dagen. Piekt het op vaste momenten, dan heb je een cronjob of een importtaak die te zwaar is.
- Contact met support heeft pas zin als je de logregel erbij kunt plakken. Dat scheelt je een dag heen en weer mailen.
Eén ding vooraf: maak een back-up voordat je in wp-config.php of .htaccess gaat zitten. Bij de meeste Nederlandse hosts staat er een dagelijkse back-up klaar in het paneel, maar controleer dat liever nu dan straks.
Wanneer het niet je website is maar je hosting
Op een gegeven moment moet je durven concluderen dat het niet aan je site ligt. Dat moment is bereikt als je log herhaaldelijk naar limieten wijst en niet naar code: geheugenmeldingen, afgebroken processen, opstapelende verzoeken. Je kunt dan blijven sleutelen aan je site, maar je duwt tegen een muur die iemand anders heeft neergezet.
Twee routes. Binnen dezelfde host een zwaarder pakket nemen is de simpele: meer geheugen, ruimere limieten, en je hoeft niets te verhuizen. Cloud86 zegt daar zelf iets nuttigs over, namelijk dat een WooCommerce-webshop op hun instappakket eigenlijk niet thuishoort en dat je daarvoor minstens een middenpakket nodig hebt. Dat geldt breder: een webshop op het instappakket van € 2,09 dat een doorsnee Nederlandse host rekent, is een tijdbom met een korte lont.
De tweede route is naar een VPS, waar de limieten van jou zijn in plaats van van je buren. Dat kost meer beheer, en of het bij jou past hangt af van je situatie; we zetten de afweging naast elkaar in shared hosting of VPS. Speelt snelheid ook een rol, kijk dan eerst wat er echt traag is met onze uitleg over website snelheid testen.
Wil je gewoon weten welke Nederlandse hosts ruime limieten en een fatsoenlijk paneel bieden, begin dan bij de ranglijst van beste webhosting of vergelijk direct in onze vergelijker. En als je overweegt te vertrekken bij je huidige provider: in hosting overstappen staat hoe je dat doet zonder downtime.
