De kern: de meeste WordPress-fouten — wit scherm, 500-fout, geheugen vol, 404's na een migratie — zijn terug te voeren op een van vier hoofdoorzaken: een plugin-/themaconflict, een PHP-geheugen- of uitvoeringslimiet, een corrupt .htaccess-bestand, of een databaseverbindingsprobleem. Diagnosticeren welke van deze zich voordoet, in plaats van willekeurige fixes te proberen, brengt een site het snelst weer online.
Waarom dezelfde handvol fouten steeds terugkomt
WordPress draait bovenop PHP, een webserver en een database, en de meeste fouten waar site-eigenaren tegenaan lopen zijn eigenlijk storingen in een van die drie lagen die via WordPress naar boven komen, niet bugs in de WordPress-kern zelf. Dat is nuttig om te weten, want het betekent dat de oplossing meestal niet "WordPress opnieuw installeren" is — maar het identificeren van welke laag faalde en dat specifiek aanpakken.
De vier hoofdoorzaken hieronder vormen de grote meerderheid van de WordPress-fouten die worden gemeld in supportforums en hostingtickets, en elk heeft een specifieke, herhaalbare oplossing in plaats van een vaag "probeer je cache te legen".
De White Screen of Death (WSOD)
Een volledig leeg wit scherm, zonder zichtbare foutmelding, betekent bijna altijd dat er een fatale PHP-fout is opgetreden, maar dat WordPress' standaardconfiguratie fouten voor bezoekers verbergt in plaats van ze te tonen. De twee meest voorkomende triggers zijn een plugin of thema dat niet compatibel is met de huidige PHP-versie van de site, en de site die zijn toegewezen PHP-geheugenlimiet halverwege een verzoek opgebruikt.
Om het te diagnosticeren: schakel debugmodus in door twee regels toe te voegen aan wp-config.php — define('WP_DEBUG', true); en define('WP_DEBUG_LOG', true); — dit schrijft de daadwerkelijke PHP-fout naar een debug.log-bestand binnen wp-content in plaats van deze te verbergen. Dit staat gedocumenteerd in WordPress' eigen officiële debugging-gids. Zodra de specifieke fout en het bestand zichtbaar zijn, is de oplossing meestal het deactiveren van de ene plugin of het thema dat in het logboek wordt genoemd.
Als FTP of een bestandsbeheerder de enige beschikbare toegang is (omdat de WSOD ook het admin-dashboard blokkeert), dwingt het hernoemen van de plugins-map binnen wp-content alle plugins om tegelijk te deactiveren — de site zou opnieuw moeten laden, en plugins kunnen één voor één opnieuw worden geactiveerd om de boosdoener te vinden.
500 Internal Server Error
In tegenstelling tot het witte scherm is een 500-fout een generieke foutmelding op serverniveau, niet specifiek voor WordPress — deze kan komen van een corrupt .htaccess-bestand, een pluginconflict, een PHP-uitvoeringstimeout, of een serverconfiguratiefout die volledig losstaat van WordPress' eigen code. Daarom is het controleren van het daadwerkelijke server-foutlogboek (beschikbaar in de meeste hosting-controlepanelen) een betrouwbaardere eerste stap dan gokken.
Veelvoorkomende oplossingen, op volgorde van hoe vaak ze het probleem verhelpen:
- Hernoem .htaccess tijdelijk (WordPress genereert er een standaard opnieuw wanneer je de Permalinks-instellingen opnieuw opslaat) — verhelpt corruptiegerelateerde 500-fouten onmiddellijk.
- Deactiveer alle plugins via phpMyAdmin door de active_plugins-rij van de wp_options-tabel te hernoemen, als adminentoegang kapot is.
- Verhoog de PHP-uitvoeringstijdslimiet als de fout alleen optreedt bij zware bewerkingen zoals grote imports.
"Allowed Memory Size Exhausted"-fout
Deze specifieke, uitgebreide PHP-fout ("Allowed memory size of X bytes exhausted") betekent dat een script probeerde meer geheugen te gebruiken dan PHP toestaat, en is een van de meer voor zich sprekende WordPress-fouten, omdat het exacte probleem al in de melding zelf wordt genoemd.
De oplossing heeft twee niveaus. Verhoog eerst WordPress' eigen geheugenlimiet door define('WP_MEMORY_LIMIT', '256M'); toe te voegen aan wp-config.php. Als dat het niet verhelpt, moet mogelijk ook de onderliggende PHP-memory_limit die door de hostingomgeving zelf is ingesteld, worden verhoogd — WordPress' constante kan niet meer zijn dan wat de server toestaat, dus een supportticket bij de host of een php.ini-bewerking is soms onvermijdelijk.
Snelle referentietabel
| Fout | Meest voorkomende oorzaak | Eerste oplossing om te proberen |
|---|---|---|
| Wit scherm (WSOD) | Fatale PHP-fout van plugin/thema | WP_DEBUG inschakelen, debug.log controleren |
| 500 Internal Server Error | Corrupt .htaccess of pluginconflict | .htaccess regenereren via Permalinks |
| Geheugen vol | PHP-geheugenlimiet te laag | WP_MEMORY_LIMIT verhogen in wp-config.php |
| 404 op alle pagina's behalve homepage | Rewrite-regels niet synchroon | Permalinks-instellingen opnieuw opslaan |
| Databaseverbindingsfout | Verkeerde inloggegevens of corrupte tabel | Database-inloggegevens in wp-config.php controleren |
404-fouten na een migratie of update
Als de homepage laadt maar elke andere pagina een 404 teruggeeft, is de permalinkstructuur die is opgeslagen in de WordPress-database niet meer synchroon met de rewrite-regels die zijn opgeslagen in .htaccess — een veelvoorkomend bijeffect van het verhuizen van hosts, het herstellen van een back-up, of het wisselen van server. Het opnieuw opslaan van de Permalinks-instellingenpagina in het WordPress-admin (Instellingen → Permalinks → Wijzigingen opslaan, zonder dat er daadwerkelijk iets hoeft te veranderen) regenereert .htaccess en verhelpt dit meestal onmiddellijk.
Databaseverbindingsfouten
"Error establishing a database connection" betekent dat WordPress de MySQL/MariaDB-database helemaal niet kan bereiken, wat anders is dan de fouten hierboven omdat dit gebeurt voordat WordPress zelfs maar genoeg kan laden om zijn eigen foutopmaak te tonen. De twee meest voorkomende oorzaken zijn onjuiste databasegegevens in wp-config.php (vaak na een migratie) en een corrupte databasetabel, meestal wp_options. Het controleren van de constanten DB_NAME, DB_USER, DB_PASSWORD en DB_HOST in wp-config.php tegen het daadwerkelijke hostingpaneel lost het geval van verkeerde inloggegevens op; een door de host geleverde databasereparatietool lost meestal tabelcorruptie op.
Een systematische manier om elke WordPress-fout te diagnosticeren
- Controleer de daadwerkelijke fout, niet alleen het symptoom — schakel WP_DEBUG in of controleer het server-foutlogboek in plaats van te gokken op basis van een leeg scherm of een generieke melding.
- Test op een kopie, niet op de live site, wanneer de oplossing het deactiveren van plugins of het bewerken van kernbestanden inhoudt — een staging site bestaat precies hiervoor.
- Verander één ding tegelijk — alle plugins tegelijk deactiveren vertelt je dat een plugin de oorzaak is, niet welke.
- Sluit oorzaken op hostingniveau uit — PHP-versieconflicten en lage geheugenlimieten zijn vaak een hostingconfiguratieprobleem, geen WordPress-probleem; zie onze bredere gids voor WordPress-snelheid en -configuratie voor de factoren op hostingniveau die ook foutpercentages beïnvloeden.
Deze fouten van tevoren voorkomen
Slecht gecodeerde plugins — vooral zware afbeeldingsgalerijen of media-verwerkingstools die bij elk verzoek grote bibliotheken in het geheugen laden — zijn een onevenredig veelvoorkomende bron van crashes door geheugenuitputting. Een lichter alternatief dat de eigen native afbeeldingsbibliotheken van de server gebruikt in plaats van een externe verwerkingsstack te laden, zoals Erdo Image Optimizer, voegt merkbaar minder geheugenoverhead toe dan zwaardere alles-in-één media-plugins.
Naast pluginkeuze zorgen dezelfde gewoontes die fouten voorkomen er ook voor dat ze sneller te verhelpen zijn wanneer ze toch optreden: regelmatige back-ups bijhouden, updates testen op een staging-kopie voordat ze naar productie gaan, en PHP en de WordPress-kern redelijk up-to-date houden zodat compatibiliteitsfouten zich niet jaar na jaar opstapelen door verwaarlozing.
Veelgemaakte fouten bij het oplossen van WordPress-fouten
- De WordPress-kern opnieuw installeren als eerste reactie, terwijl de daadwerkelijke fout bijna altijd een specifieke plugin, thema of instelling op hostingniveau is.
- Plugins één voor één deactiveren en opnieuw activeren op de live site tijdens kantooruren, terwijl een staging-kopie de boosdoener zou vinden zonder downtime voor bezoekers.
- Het foutlogboek volledig negeren en willekeurige fixes proberen op basis van het zichtbare symptoom (een lege pagina) in plaats van de daadwerkelijke PHP-fout erachter.
- wp-config.php bewerken zonder eerst een back-upkopie te maken, waardoor een herstelbare fout verandert in een site die helemaal niet meer laadt als er een typefout wordt geïntroduceerd.
- Aannemen dat een 500-fout altijd de schuld van WordPress is, terwijl foutieve serverconfiguratie en generieke PHP-storingen dezelfde melding produceren.
Tot slot
Kortom, het witte scherm, 500-fouten, geheugenuitputting en kapotte permalinks die het grootste deel van WordPress-probleemoplossingsverzoeken vormen, zijn allemaal terug te voeren op een kleine set hoofdoorzaken — plugin-/themaconflicten, PHP-limieten, .htaccess-corruptie of databaseproblemen — elk met een specifieke, herhaalbare oplossing. Debugmodus inschakelen en de daadwerkelijke fout lezen, in plaats van te gokken op basis van het zichtbare symptoom, is de ene gewoonte die een stressvolle storing verandert in een fix van vijf minuten.