Een witte WordPress pagina, een melding over een kritieke fout of een beheerpaneel dat niet meer opent voelt al snel alsof de hele website verloren is. Gelukkig is de oorzaak meestal concreet te vinden. Vaak gaat het om een PHP fout, een conflict tussen plugins, een incompatibele update, een tekort aan geheugen of een probleem met de database.
De belangrijkste regel bij WordPress problemen oplossen is dat je niet willekeurig instellingen verandert. Werk stap voor stap, leg vast wat je doet en controleer na iedere wijziging of het probleem verandert. In deze handleiding leer je hoe je veilig debugt, hoe je een foutlog leest en wanneer je beter professionele hulp inschakelt.
Wat een witte WordPress pagina betekent
De bekende White Screen of Death is geen afzonderlijke WordPress functie. Het is meestal het zichtbare gevolg van een fout waardoor PHP de pagina niet kan afmaken. Soms zie je volledig wit. Soms toont WordPress de melding dat er een kritieke fout is opgetreden. Op andere momenten werkt de voorkant nog, terwijl alleen wp admin of één specifieke pagina uitvalt.
Een fatal error geeft de beste aanwijzing. Daarin staat meestal welk bestand de fout veroorzaakte, op welke regel dit gebeurde en welk type fout PHP aantrof. Zonder logging blijft die informatie verborgen. Daarom begint een goede diagnose met het veilig verzamelen van bewijs.
Werk eerst veilig
Maak voordat je bestanden, plugins of de database aanpast een actuele backup. Gebruik bij voorkeur ook een staging omgeving. Dat is een afgeschermde kopie waarop je controles kunt uitvoeren zonder bezoekers, formulieren of bestellingen te raken.
- Noteer welke pagina niet werkt en op welk tijdstip de fout begon
- Schrijf op welke update of wijziging direct daarvoor is uitgevoerd
- Maak een backup van zowel bestanden als database
- Voer ingrijpende controles eerst op staging uit
- Verander steeds maar één onderdeel tegelijk
Gebruik WordPress Recovery Mode
WordPress kan bij bepaalde fatale PHP fouten automatisch Recovery Mode starten. De beheerder ontvangt dan een e mail met een beveiligde link. Via die link kun je inloggen terwijl het problematische thema of de problematische plugin alleen voor jouw sessie wordt gepauzeerd. Je kunt het onderdeel vervolgens uitschakelen, bijwerken of terugzetten.
Recovery Mode lost de onderliggende fout niet zelf op. Het geeft je toegang om veilig onderzoek te doen. Ontvang je geen bericht, controleer dan het beheerdersadres en de spammap. De officiële uitleg over WordPress Recovery Mode beschrijft ook wat je kunt doen wanneer de herstelmail niet aankomt.
Schakel foutlogging veilig in
Kun je bij de bestanden via SFTP, SSH of het bestandsbeheer van je host, open dan het bestand wp config.php. Plaats de volgende regels boven de regel waarin WordPress aangeeft dat je moet stoppen met bewerken.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Met deze instelling worden fouten opgeslagen in wp-content/debug.log, terwijl bezoekers de technische meldingen niet op het scherm zien. Dat is belangrijk omdat foutmeldingen bestandspaden en andere gevoelige informatie kunnen bevatten. Volgens de officiële WordPress documentatie over debugging werkt WP_DEBUG_LOG alleen wanneer WP_DEBUG actief is.
Lees de belangrijkste foutregel
Open debug.log nadat je de fout opnieuw hebt veroorzaakt. Begin onderaan, want daar staan de nieuwste regels. Zoek eerst naar PHP Fatal error, Uncaught Error, TypeError of een melding over exhausted memory. Het bestandspad wijst vaak rechtstreeks naar een plugin, thema of eigen code. Een waarschuwing die al weken voorkomt is minder belangrijk dan een nieuwe fatale fout op het exacte tijdstip van de storing.
Staat de fout bijvoorbeeld in een map onder wp-content/plugins, controleer dan de genoemde plugin. Staat het pad in het actieve thema, kijk dan naar een recente wijziging in dat thema. Bewaar een kopie van het relevante logdeel voordat je het log wist.
Voeg tijdelijk een eigen logregel toe
Bij een fout die alleen tijdens een specifieke actie ontstaat kun je tijdelijk een controlepunt toevoegen. Zo ontdek je of WordPress een bepaald stuk code bereikt.
if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
error_log( 'Controlepunt bereikt' );
}Gebruik dit alleen tijdelijk en verwijder de regel na de diagnose. Plaats zulke controlepunten bij voorkeur in een kleine ontwikkelplugin of in code die onder versiebeheer staat. Zo voorkom je dat een snelle test later onbedoeld op de live website blijft staan.
Sluit een pluginconflict uit
Veel WordPress fouten beginnen direct na het installeren of bijwerken van een plugin. Schakel eerst alleen het verdachte onderdeel uit. Werkt wp admin niet meer, dan kun je via SFTP de map van die plugin tijdelijk hernoemen. WordPress ziet de map dan niet meer en de plugin wordt gedeactiveerd.
Met WP CLI kun je sneller inventariseren en testen. Gebruik het uitschakelen van alle plugins alleen op staging of tijdens gepland onderhoud. Formulieren, webshops, beveiliging en andere functies kunnen tijdelijk stoppen.
wp plugin list
wp plugin deactivate --all
wp plugin activate plugin-slugActiveer daarna de plugins één voor één en test steeds dezelfde fout. Zodra het probleem terugkomt heb je de waarschijnlijke veroorzaker gevonden. Controleer vervolgens de changelog, systeemvereisten en bekende compatibiliteitsproblemen voordat je een versie vervangt.
Controleer het actieve thema
Ook een thema kan een fatale fout veroorzaken, vooral na een PHP update of een wijziging in functions.php. Test op staging met een standaard WordPress thema. Als de fout verdwijnt, zit de oorzaak waarschijnlijk in het actieve thema of in code die eraan gekoppeld is.
wp theme list
wp theme activate twentytwentyfiveVoer deze wijziging niet zomaar op een live website uit. Een ander thema kan menu’s, widgets en vormgeving veranderen. Gebruik een backup en noteer welk thema actief was, zodat je altijd gecontroleerd kunt terugkeren.
Controleer PHP geheugen en versie
De melding Allowed memory size exhausted betekent dat een proces meer geheugen vraagt dan PHP beschikbaar stelt. Je kunt tijdelijk een hogere WordPress limiet instellen, maar alleen wanneer de hostingomgeving die ruimte daadwerkelijk biedt.
define( 'WP_MEMORY_LIMIT', '256M' );Een hogere limiet is geen echte oplossing wanneer een plugin door een fout steeds meer geheugen verbruikt. Controleer daarom ook het log, zware queries en achtergrondtaken. Kijk daarnaast of de gebruikte PHP versie wordt ondersteund door WordPress, het thema en alle belangrijke plugins. Test een wijziging van PHP altijd eerst op staging.
Controleer database en WordPress bestanden
Bij Error establishing a database connection kan de databaseserver onbereikbaar zijn of kunnen de gegevens in wp config.php niet meer kloppen. Wijzig geen wachtwoorden op goed geluk. Controleer eerst de status van de databaseserver bij je host en vergelijk de configuratie met een werkende backup.
Met WP CLI kun je de databaseverbinding controleren en de WordPress kernbestanden vergelijken met officiële checksums.
wp db check
wp core verify-checksumsDe checksumcontrole herstelt niets en beoordeelt geen plugins, uploads of eigen code. Hij helpt wel om gewijzigde of beschadigde kernbestanden te signaleren. Gebruik voor een Nederlandse installatie zo nodig de juiste versie en locale. Geef bestanden nooit algemene 777 rechten om een fout snel te omzeilen. Verkeerde rechten vergroten het beveiligingsrisico.
Onderzoek fouten na een update gericht
Een update kan nieuwe eisen stellen aan PHP, de database of andere plugins. Kijk daarom niet alleen naar het onderdeel dat zojuist is bijgewerkt. Lees de foutregel, controleer afhankelijkheden en vergelijk de werkende versie met de nieuwe versie. Zet alleen het betrokken onderdeel terug vanuit een betrouwbare backup.
Werk WordPress, plugins en thema’s niet allemaal tegelijk bij wanneer je een bestaand probleem probeert te vinden. Dan verander je te veel variabelen en weet je niet welke actie het verschil maakte. Plan onderhoud, maak vooraf een herstelpunt en test de belangrijkste formulieren, betalingen en pagina’s na afloop.
Wanneer slechts één pagina fout gaat
Werkt de rest van de website normaal, dan ligt de oorzaak vaak in de inhoud of logica van die ene pagina. Denk aan een defect blok, een shortcode, een dynamisch veld, een query die te veel gegevens ophaalt of JavaScript dat vastloopt. Vergelijk de pagina met een eerdere revisie en controleer de console en netwerkverzoeken in de browser.
Bij een onverwachte 404 kun je de permalinks opnieuw opslaan. Met WP CLI kan dat via het volgende commando.
wp rewrite flushWis daarna alleen de relevante cache. Een WordPress website kan meerdere lagen gebruiken, zoals paginacache, objectcache, servercache en een CDN. Alles tegelijk wissen maakt onderzoek minder duidelijk. Met professioneel WordPress hosting en beheer worden logging, backups, updates en monitoring als één proces ingericht.
Gebruik een vaste diagnosevolgorde
Een vaste volgorde voorkomt paniek en onnodige schade. Deze aanpak werkt voor de meeste kritieke WordPress problemen.
- Bevestig de fout in een privévenster en noteer tijdstip en URL
- Controleer hostingstatus en beschikbare schijfruimte
- Maak of bevestig een recente backup
- Gebruik Recovery Mode wanneer WordPress die aanbiedt
- Activeer veilige logging zonder fouten aan bezoekers te tonen
- Lees de nieuwste fatale fout en bepaal het betrokken bestand
- Test het verdachte onderdeel op staging
- Voer de kleinste gerichte oplossing uit en test opnieuw
Schakel debugging na herstel weer uit
Wanneer de oorzaak is opgelost, zet je de debugmodus weer uit. Laat debug.log niet onbeheerd staan. Het bestand kan technische details bevatten en kan bij een drukke website snel groot worden.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );Controleer daarna de voorkant, wp admin, formulieren, geplande taken en belangrijke commerciële stappen. Leg vast wat de oorzaak was en welke oplossing is toegepast. Voeg indien nodig monitoring toe, zodat een volgende fout sneller zichtbaar wordt.
Wanneer professionele hulp verstandig is
Stop met zelf aanpassen wanneer je geen recente backup hebt, de webshop bestellingen verwerkt, de fout na iedere wijziging terugkomt of je niet kunt bepalen welk bestand veilig aangepast mag worden. Ook bij malware, onbekende beheerders, gewijzigde kernbestanden of databaseproblemen is snelle technische hulp verstandiger dan verder experimenteren.
Een degelijk gebouwde website is eenvoudiger te onderhouden en te debuggen. Lees ook waarom een professionele WordPress website meer vraagt dan alleen een automatische websitebouwer. Wil je structurele problemen voorkomen, bekijk dan onze dienst voor een WordPress website laten maken.
Veelgestelde vragen over WordPress problemen
Wat veroorzaakt een witte WordPress pagina
De meest voorkomende oorzaken zijn een fatale PHP fout, een pluginconflict, een defect thema, een incompatibele PHP versie, te weinig geheugen of een databaseprobleem. Het debuglog geeft meestal de snelste aanwijzing.
Waar staat het WordPress debuglog
Wanneer WP_DEBUG en WP_DEBUG_LOG actief zijn staat het bestand normaal in wp-content/debug.log. Sommige hosts schrijven fouten daarnaast naar een eigen PHP log in het hostingpaneel.
Kan ik plugins uitschakelen zonder wp admin
Ja. Hernoem via SFTP tijdelijk de map van de verdachte plugin of gebruik WP CLI. Schakel niet zonder plan alle plugins op een drukke live website uit, omdat belangrijke functies dan kunnen stoppen.
Is WP_DEBUG veilig op een live website
Gebruik debugging op live alleen tijdelijk en toon fouten niet aan bezoekers. Combineer WP_DEBUG met WP_DEBUG_DISPLAY op false en schakel alles na de diagnose weer uit. Verwijder of beveilig het logbestand daarna.
Moet ik direct alle updates installeren
Nee. Maak eerst een backup en bepaal of de update relevant is voor de fout. Test updates op staging en controleer na iedere stap de belangrijkste functies. Bij een actieve storing wil je zo weinig mogelijk tegelijk veranderen.
WordPress problemen oplossen zonder giswerk
Een WordPress fout wordt beheersbaar zodra je bewijs verzamelt en één hypothese tegelijk test. Begin met een backup, gebruik veilige logging, lees de nieuwste fatale fout en isoleer daarna plugin, thema, PHP, database of cache. Zo herstel je niet alleen de website, maar begrijp je ook waarom het probleem ontstond.
Kom je er niet uit of wil je voorkomen dat een storing terugkomt? Neem contact op met Bastux voor technische diagnose, herstel en doorlopend beheer.
