Veelvoorkomende WordPress-fouten oplossen: complete handleiding

22 aug. 2026 • 33 min leestijd • 15 weergaven

Veelvoorkomende WordPress-fouten oplossen: complete handleiding

Een WordPress-website werkt meestal jarenlang zonder grote problemen. Tot je op een ochtend je website opent en plotseling alleen nog een wit scherm, foutmelding of 500 Internal Server Error ziet.

Of misschien werkt de website zelf nog wel, maar kun je niet meer inloggen. Afbeeldingen willen niet uploaden. Pagina's geven ineens een 404-fout. Een update blijft hangen. Of WordPress meldt dat er geen verbinding met de database kan worden gemaakt.

Dat klinkt ernstig, maar veel WordPress-fouten hebben een vrij herkenbare oorzaak.

Het belangrijkste is dat je niet willekeurig instellingen gaat aanpassen.

Een goede troubleshootingmethode is:

vaststellen welke fout optreedt;
bepalen wanneer het probleem begon;
recente wijzigingen controleren;
logs bekijken;
één mogelijke oorzaak tegelijk testen;
na iedere wijziging opnieuw controleren.

In deze handleiding behandelen we de meest voorkomende WordPress-fouten, leggen we uit waardoor ze ontstaan en laten we stap voor stap zien hoe je ze veilig kunt oplossen.

Maak eerst een backup voordat je gaat troubleshooten

Voordat je bestanden, plugins, databasegegevens of WordPress-instellingen aanpast:

maak een backup.

Idealiter heb je een recente backup van:

de WordPress-database;
wp-content;
themes;
plugins;
uploads;
wp-config.php;
eventuele aanvullende configuratiebestanden.

Zelfs wanneer de website momenteel niet goed werkt, kan een backup van de huidige situatie nuttig zijn.

Waarom?

Omdat je tijdens troubleshooting per ongeluk aanvullende schade kunt veroorzaken. Bovendien kunnen bestanden en logs uit de huidige situatie belangrijk zijn wanneer later moet worden onderzocht wat er precies misging.

Bij een live bedrijfswebsite is een stagingomgeving nog beter.

Daar kun je mogelijke oplossingen testen zonder dat iedere wijziging direct invloed heeft op bezoekers.

Begin altijd met deze vijf controles

Voordat we specifieke WordPress-fouten behandelen, zijn er vijf vragen die verrassend vaak direct richting de oorzaak wijzen.

1. Wat is er vlak vóór het probleem veranderd?

Denk aan:

WordPress-update;
pluginupdate;
nieuwe plugin;
theme-update;
wijziging in PHP-versie;
DNS-aanpassing;
SSL-certificaat;
migratie;
cachinginstelling;
maatwerkcode;
serverwijziging.

Een fout die vijf minuten na een pluginupdate begon, is waarschijnlijk niet toevallig ontstaan.

2. Werkt alleen één pagina niet of de hele website?

Als slechts één pagina een probleem heeft, ligt de oorzaak waarschijnlijk ergens anders dan wanneer:

de homepage;
/wp-admin/;
alle berichten;
en alle afbeeldingen

tegelijkertijd niet meer bereikbaar zijn.

3. Kun je nog inloggen in WordPress?

Controleer:

https://jouwdomein.nl/wp-admin/

Wanneer het dashboard nog werkt, wordt troubleshooting aanzienlijk eenvoudiger.

4. Werkt het probleem ook in een andere browser?

Test eventueel:

incognitomodus;
andere browser;
andere internetverbinding.

Hiermee kun je lokale caching-, DNS- of cookieproblemen uitsluiten.

5. Controleer de serverlogs

Bij technische fouten is de foutmelding op het scherm soms slechts het symptoom.

De echte oorzaak staat vaak in:

PHP error log;
webserver error log;
WordPress debug log;
hostinglogboek.

Logs zijn daarom vaak waardevoller dan willekeurig plugins uitschakelen.

1. "There has been a critical error on this website"

Een van de bekendste moderne WordPress-fouten is:

There has been a critical error on this website.

In Nederlandse installaties kan een vergelijkbare melding worden weergegeven.

Deze fout betekent meestal dat PHP tijdens het uitvoeren van WordPress tegen een fatale fout is aangelopen.

Veelvoorkomende oorzaken

Denk bijvoorbeeld aan:

defecte plugin;
incompatibele pluginupdate;
theme-fout;
incompatibele PHP-versie;
fout in maatwerkcode;
ontbrekende PHP-extension;
onvoldoende PHP-geheugen;
beschadigde bestanden.

Controleer eerst je e-mail

WordPress beschikt over een ingebouwde Recovery Mode.

Wanneer WordPress tijdens een normale paginalaad een fatale PHP-fout detecteert, kan het een e-mail sturen naar het administratoradres van de website.

Die e-mail bevat meestal informatie over:

welke plugin of theme mogelijk de fout veroorzaakte;
welk bestand betrokken was;
een speciale link naar Recovery Mode.

Via Recovery Mode kun je soms nog inloggen terwijl de defecte plugin voor jouw sessie tijdelijk wordt onderdrukt.

Ga vervolgens naar:

Plugins → Geïnstalleerde plugins

en deactiveer de problematische plugin.

Of wissel tijdelijk van theme wanneer het thema de oorzaak is.

Geen Recovery Mode-e-mail ontvangen?

Controleer:

spamfolder;
administrator-e-mailadres;
servermail;
eventuele SMTP-problemen.

Kun je niet meer inloggen? Dan kun je een plugin ook via SFTP of File Manager uitschakelen.

Ga naar:

/wp-content/plugins/

en wijzig bijvoorbeeld:

voorbeeld-plugin

naar:

voorbeeld-plugin-disabled

WordPress kan de plugin dan niet meer op de normale locatie vinden en zal hem deactiveren.

Test daarna opnieuw.

2. White Screen of Death: volledig wit WordPress-scherm

De zogenaamde White Screen of Death of WSOD is een klassiek WordPress-probleem.

Je opent de website en ziet:

helemaal niets;
een leeg wit scherm;
of vrijwel geen bruikbare foutmelding.

Moderne WordPress-versies vangen veel fatale fouten beter af met de Critical Error- en Recovery Mode-functionaliteit, maar een volledig wit scherm kan nog steeds voorkomen.

Mogelijke oorzaken

Meestal gaat het om:

fatale PHP-fout;
pluginconflict;
themeprobleem;
PHP memory limit;
beschadigde WordPress-bestanden;
foutieve maatwerkcode.

Stap 1: controleer of `/wp-admin/` werkt

Probeer:

https://jouwdomein.nl/wp-admin/

Wanneer het dashboard werkt maar de voorkant niet, is het theme een belangrijke verdachte.

Wanneer zowel frontend als backend wit blijven, kan het probleem breder zijn.

Stap 2: schakel plugins tijdelijk uit

Kun je nog inloggen?

Deactiveer dan plugins één voor één.

Kun je niet inloggen?

Ga via SFTP of File Manager naar:

wp-content/

en wijzig:

plugins

tijdelijk naar bijvoorbeeld:

plugins-disabled

Hiermee voorkom je dat WordPress de plugins normaal laadt.

Werkt de website daarna weer?

Dan zit het probleem waarschijnlijk in een plugin.

Herstel de mapnaam en activeer plugins vervolgens systematisch één voor één totdat je de oorzaak hebt gevonden.

Stap 3: controleer het actieve theme

Wanneer plugins niet de oorzaak zijn, test dan een standaard WordPress-theme.

Doe dit bij voorkeur via het dashboard of een stagingomgeving.

3. 500 Internal Server Error

Een 500 Internal Server Error is frustrerend omdat de melding weinig vertelt.

De server zegt feitelijk:

Er ging iets mis tijdens het verwerken van dit verzoek.

Maar niet noodzakelijk wat.

Veelvoorkomende oorzaken

PHP fatal error;
pluginfout;
themefout;
foutieve .htaccess;
verkeerd ingestelde serverregels;
onvoldoende geheugen;
foutieve bestandsrechten;
incompatibele PHP-versie;
serverconfiguratieprobleem.

Stap 1: controleer de error logs

Dit is bij een 500-fout de belangrijkste stap.

Zoek naar een fout die exact rond hetzelfde tijdstip als je request werd geregistreerd.

Bijvoorbeeld:

PHP Fatal error

of:

Allowed memory size exhausted

of:

Call to undefined function

De foutmelding vertelt vaak direct welk bestand betrokken is.

Stap 2: controleer `.htaccess`

Op Apache-omgevingen kan een fout in .htaccess een 500-error veroorzaken.

Maak eerst een backup van het bestaande bestand.

Wijzig daarna tijdelijk:

.htaccess

naar:

.htaccess-old

Test de website opnieuw.

Werkt de website?

Dan was waarschijnlijk een regel in .htaccess verantwoordelijk.

Wanneer je weer in WordPress kunt:

Instellingen → Permalinks

en klik op:

Wijzigingen opslaan

WordPress kan daarmee de permalinkregels opnieuw genereren.

Doe dit alleen wanneer je server daadwerkelijk .htaccess gebruikt. Nginx werkt bijvoorbeeld anders.

Stap 3: test plugins

Wanneer .htaccess niet de oorzaak is, deactiveer plugins systematisch.

Stap 4: controleer PHP

Controleer:

PHP-versie;
memory limit;
benodigde PHP-extensions;
recente wijzigingen in PHP-configuratie.

4. Error establishing a database connection

De melding:

Error establishing a database connection

betekent dat WordPress geen bruikbare verbinding met zijn database kan maken.

Zonder database kan WordPress vrijwel niets doen.

Berichten, pagina's, instellingen, gebruikers en veel plugininformatie staan namelijk in MySQL of MariaDB.

Mogelijke oorzaken

De meest voorkomende zijn:

verkeerde databasenaam;
verkeerde databasegebruiker;
verkeerd databasewachtwoord;
verkeerde databasehost;
databaseserver offline;
databaseverbindingen uitgeput;
serverresources uitgeput;
beschadigde database;
wijziging na een migratie;
databaseaccount heeft onvoldoende rechten.

Stap 1: controleer `wp-config.php`

Open:

wp-config.php

Controleer deze waarden:

define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'database_password' );
define( 'DB_HOST', 'localhost' );

De werkelijke waarden zijn uiteraard per hostingomgeving verschillend.

Let vooral op DB_HOST.

Dat is niet bij iedere host automatisch localhost.

Sommige hostingplatformen gebruiken bijvoorbeeld:

andere hostnaam;
intern serveradres;
specifieke poort.

Gebruik daarom de gegevens van je hostingomgeving.

Stap 2: controleer of de databaseserver bereikbaar is

Wanneer de credentials correct zijn, kan MySQL/MariaDB zelf een probleem hebben.

Bijvoorbeeld:

databaseproces is gestopt;
maximum aantal connecties bereikt;
disk is vol;
accountlimiet bereikt;
server is overbelast.

Dit is een goed moment om de hostingstatus en serverlogs te controleren.

De fout komt maar af en toe voor

Een tijdelijke databasefout is extra interessant.

Wanneer dezelfde configuratie soms wel en soms niet werkt, zijn foutieve credentials minder waarschijnlijk.

Onderzoek dan bijvoorbeeld:

max_connections;
max_user_connections;
CPU-belasting;
RAM;
databasebelasting;
zware queries;
bots;
plugins met extreem veel databaseverzoeken.

Een databasefout is dus niet altijd een configuratiefout.

5. "Briefly unavailable for scheduled maintenance"

Na een WordPress- of pluginupdate kun je soms deze melding blijven zien:

Briefly unavailable for scheduled maintenance. Check back in a minute.

Tijdens updates maakt WordPress tijdelijk een bestand:

.maintenance

aan.

Normaal wordt dat bestand na de update automatisch verwijderd.

Wordt de update onderbroken, dan kan het bestand blijven staan.

Oplossing

Open via SFTP of File Manager de hoofdmap van WordPress.

Dat is de map waarin je bijvoorbeeld ziet:

wp-admin;
wp-content;
wp-includes.

Zoek:

.maintenance

en verwijder het bestand.

Refresh daarna de website.

Controleer vervolgens of de oorspronkelijke update volledig is afgerond.

Start de update eventueel opnieuw.

Verwijder dus niet alleen .maintenance en ga vervolgens verder alsof er niets is gebeurd.

Een onderbroken update kan incomplete plugin- of WordPress-bestanden hebben achtergelaten.

6. WordPress geeft 404-fouten op berichten en pagina's

Je homepage werkt, maar een bericht zoals:

example.nl/blog/mijn-artikel/

geeft:

404 Not Found

Dit wijst vaak op een probleem met permalinks of rewrite rules.

Eenvoudigste oplossing

Ga naar:

Instellingen → Permalinks

Verander niets.

Klik simpelweg op:

Wijzigingen opslaan

WordPress probeert daarmee de rewrite rules opnieuw te genereren.

Test daarna de pagina.

Werkt dat niet?

Controleer afhankelijk van je server:

Apache

Controleer:

.htaccess;
mod_rewrite;
AllowOverride;
serverconfiguratie.

Nginx

Nginx gebruikt geen .htaccess.

De WordPress rewriteconfiguratie moet dan op serverniveau correct staan.

Alleen één custom post type geeft 404

Als bijvoorbeeld alleen:

/vacatures/...

of:

/projecten/...

404 geeft, kan de oorzaak in een plugin, custom post type of rewrite-configuratie zitten.

Sla eerst opnieuw de permalinks op.

Helpt dit slechts tijdelijk? Onderzoek dan de code waarmee het custom post type wordt geregistreerd.

7. WordPress admin geeft 404

Wanneer de website werkt maar bijvoorbeeld een bepaalde adminpagina een 404 geeft, controleer:

pluginroutes;
securityregels;
serverconfiguratie;
.htaccess;
reverse proxy/CDN;
custom loginplugins.

Gebruik niet meteen een databasezoek-en-vervangactie.

Een 404 betekent meestal eerst dat je routing moet onderzoeken.

8. 403 Forbidden

Een 403 Forbidden betekent doorgaans dat de server het verzoek begrijpt maar toegang weigert.

Mogelijke oorzaken

verkeerde bestandsrechten;
firewallregel;
securityplugin;
WAF;
.htaccess;
IP-blokkade;
CDN-firewall;
serverconfiguratie.

Controleer eerst of het probleem overal voorkomt

Krijg je een 403 op:

hele website;
alleen /wp-admin/;
alleen één bestand;
alleen uploads;
alleen vanaf jouw IP?

Dat verschil helpt enorm.

Bestandsrechten

Veel WordPress-omgevingen gebruiken grofweg:

directories: 755;
bestanden: 644.

Maar pas dit niet blind toe.

De correcte permissions hangen af van:

eigenaar;
groep;
PHP-handler;
serverarchitectuur.

Gebruik vooral nooit automatisch 777 om een permissionsprobleem "op te lossen".

Daarmee maak je bestanden of directories potentieel veel te ruim schrijfbaar.

9. 502 Bad Gateway

Een 502 Bad Gateway ontstaat meestal buiten WordPress zelf.

Een proxy of webserver verwacht een geldig antwoord van een backendservice, maar krijgt dat niet.

Bijvoorbeeld:

Nginx → PHP-FPM

of:

CDN → origin server

Mogelijke oorzaken

PHP-FPM gecrasht;
backendserver offline;
timeout;
resource exhaustion;
proxyprobleem;
foutieve upstreamconfiguratie;
deployment tijdens request.

Wat moet je controleren?

Bekijk:

webserverlogs;
PHP-FPM-status;
CPU;
RAM;
PHP workers;
serverload;
proxylogs;
CDN-status.

Wanneer 502-errors vooral tijdens piekverkeer optreden, kijk dan extra naar beschikbare serverresources en PHP-processen.

10. 503 Service Unavailable

Een 503 Service Unavailable betekent meestal dat de server tijdelijk geen request kan verwerken.

Mogelijke oorzaken

server overbelast;
PHP worker-limit;
maintenance;
plugin die extreem zware processen veroorzaakt;
databaseproblemen;
rate limiting;
DDoS- of botverkeer.

Een 503 die slechts af en toe voorkomt is vaak een capaciteits- of stabiliteitsprobleem.

Controleer daarom niet alleen WordPress.

Controleer ook:

CPU;
RAM;
processlimieten;
PHP workers;
databaseconnections;
bezoekerspieken;
bots.

11. 504 Gateway Timeout

Een 504 Gateway Timeout betekent dat een upstreamservice niet op tijd reageerde.

Bij WordPress kan dit bijvoorbeeld voorkomen wanneer:

PHP te lang bezig is;
een databasequery extreem traag is;
WordPress wacht op een externe API;
een import lang duurt;
een plugin vastloopt;
serverresources volledig worden gebruikt.

Zoek de langzame stap

Een timeout los je niet structureel op door alleen de timeoutlimiet steeds hoger te zetten.

Dat kan het probleem maskeren.

Onderzoek:

PHP slow logs;
database slow queries;
externe HTTP-requests;
cronjobs;
imports;
pluginprocessen.

Een request dat twee minuten nodig heeft, verdient onderzoek — ook wanneer je de timeout op vijf minuten kunt zetten.

12. ERR_TOO_MANY_REDIRECTS

De browser toont:

Too many redirects

of:

ERR_TOO_MANY_REDIRECTS

Dit betekent dat de browser in een redirectloop terechtkomt.

Bijvoorbeeld:

A → B → A → B → A

Veelvoorkomende oorzaken bij WordPress

verkeerde Site URL;
verkeerde WordPress URL;
HTTP/HTTPS-conflict;
CDN SSL-configuratie;
reverse proxy;
redirectplugin;
caching;
serverredirect.

Controleer WordPress URL-instellingen

Onder:

Instellingen → Algemeen

staan normaal:

WordPress-adres (URL)
Siteadres (URL)

Controleer of deze waarden correct zijn.

Bijvoorbeeld:

https://example.nl

en niet een combinatie van:

http://example.nl

en:

https://www.example.nl

wanneer de server vervolgens zelf weer redirects uitvoert.

Achter Cloudflare of een andere proxy?

Dan kan een verkeerde SSL/TLS-configuratie eveneens een redirectloop veroorzaken.

Onderzoek dan de volledige route:

browser → CDN/proxy → webserver → WordPress

13. "Your connection is not private" of SSL-certificaatfout

Deze fout komt uit de browser, niet rechtstreeks uit WordPress.

Mogelijke oorzaken:

verlopen certificaat;
certificaat nog niet actief;
verkeerde domeinnaam in certificaat;
incomplete certificate chain;
DNS wijst naar verkeerde server;
systeemdatum van bezoeker klopt niet.

Controleer eerst het certificaat op serverniveau.

Een WordPress-plugin kan een ongeldig TLS-certificaat niet repareren.

14. Mixed Content na overstappen naar HTTPS

Je website opent via HTTPS, maar de browser meldt nog onveilige content.

Dat heet mixed content.

De HTML-pagina wordt via HTTPS geladen, maar één of meerdere resources nog via HTTP.

Bijvoorbeeld:

http://example.nl/wp-content/uploads/logo.jpg

Mogelijke bronnen

oude afbeelding-URL's;
hardcoded themebestanden;
custom CSS;
externe scripts;
databasecontent;
pagebuilderinstellingen.

Oplossing

Identificeer eerst via de browserconsole welke HTTP-resources worden geladen.

Pas daarna de bron aan.

Wanneer honderden oude URLs in de database staan, kan een gecontroleerde search-and-replace nodig zijn.

Maak vooraf altijd een databasebackup.

Gebruik bovendien een tool die geserialiseerde WordPress-data correct kan verwerken.

Een simpele SQL REPLACE() kan in bepaalde situaties serialized data beschadigen.

15. Je kunt niet meer inloggen in WordPress

Loginproblemen hebben verschillende oorzaken.

Bijvoorbeeld:

wachtwoord vergeten;
verkeerde gebruikersnaam;
cookies;
redirectloop;
securityplugin;
geblokkeerd IP;
defecte plugin;
verkeerde Site URL.

Wachtwoord vergeten

Gebruik:

Wachtwoord vergeten?

op de WordPress-loginpagina.

Ontvang je geen resetmail? Dan kan er ook een e-mailprobleem spelen.

Loginpagina refreshes zonder in te loggen

Controleer:

cookies;
WordPress URL;
Site URL;
HTTPS;
caching;
reverse proxy.

Probeer ook een incognitovenster.

Securityplugin heeft je geblokkeerd

Controleer firewall- of securitylogs.

Schakel een securityplugin niet automatisch uit zonder eerst vast te stellen waarom de blokkade plaatsvond.

16. WordPress blijft uitloggen

Wanneer je voortdurend opnieuw moet inloggen, is vaak sprake van een probleem rond cookies of URLs.

Controleer vooral of je website consequent één variant gebruikt.

Dus bijvoorbeeld overal:

https://www.example.nl

of overal:

https://example.nl

Niet voortdurend wisselen tussen:

HTTP;
HTTPS;
www;
non-www.

Authenticatiecookies zijn gekoppeld aan de WordPress-configuratie en domeincontext.

Inconsistente URL's kunnen daarom vreemde loginproblemen veroorzaken.

17. Uploaden van afbeeldingen mislukt

Je probeert een afbeelding te uploaden en krijgt bijvoorbeeld:

upload failed;
HTTP error;
server cannot process image;
bestand kan niet worden geschreven.

Mogelijke oorzaken

bestand te groot;
PHP uploadlimiet;
onvoldoende geheugen;
verkeerde permissions;
disk vol;
image processing faalt;
unsupported format;
securityregel.

Controleer onder andere:

upload_max_filesize;
post_max_size;
PHP memory limit;
vrije schijfruimte;
wp-content/uploads permissions.

Grote afbeeldingen

Zeer grote bronafbeeldingen kunnen tijdens resizing veel geheugen nodig hebben.

Een foto van een moderne camera kan bijvoorbeeld tientallen megapixels bevatten.

Verklein extreem grote afbeeldingen voordat je ze uploadt wanneer volledige resolutie niet nodig is.

18. "The uploaded file exceeds the upload_max_filesize directive"

Deze melding is behoorlijk duidelijk.

PHP accepteert het bestand niet omdat het groter is dan:

upload_max_filesize

Maar er zijn meerdere relevante limieten.

Onder andere:

upload_max_filesize;
post_max_size;
memory_limit;
webserverlimieten.

Wanneer je bijvoorbeeld:

upload_max_filesize = 128M

instelt maar:

post_max_size = 32M

blijft gebruiken, kunnen uploads boven 32 MB nog steeds mislukken.

Pas serverlimieten bij voorkeur via de hostingconfiguratie aan.

Ga niet willekeurig regels aan .htaccess toevoegen wanneer je niet weet welke PHP-handler de server gebruikt.

19. "Allowed memory size exhausted"

Een typische PHP-fout ziet er ongeveer zo uit:

Allowed memory size of ... bytes exhausted

Een PHP-proces heeft dan zijn geheugenlimiet bereikt.

Mogelijke oorzaken

zware plugin;
grote import;
image processing;
inefficiënte query;
pagebuilder;
WooCommerce-proces;
te lage memory limit;
programmeerfout.

Alleen geheugen verhogen?

Dat kan soms gerechtvaardigd zijn.

Maar stel jezelf eerst de vraag:

Waarom gebruikt deze request zoveel geheugen?

Als een plugin door een bug honderden megabytes gebruikt, maakt verhoging van 256 MB naar 1 GB het onderliggende probleem niet weg.

Controleer daarom logs en profiling.

20. "Maximum execution time exceeded"

PHP-processen mogen doorgaans niet onbeperkt blijven draaien.

Wanneer de ingestelde execution time wordt overschreden, kan PHP het proces stoppen.

Dit gebeurt bijvoorbeeld bij:

grote imports;
backups;
image processing;
zware databaseoperaties;
defecte plugins;
externe API die niet reageert.

Ook hier geldt:

de timeout verhogen is niet automatisch de beste oplossing.

Onderzoek eerst waarom de operatie zo lang duurt.

Voor grote achtergrondtaken is het vaak beter om een proces in kleinere batches of via een queue/cronmechanisme uit te voeren.

21. WordPress-e-mails worden niet ontvangen

Een formulier zegt:

Bericht verzonden

maar er komt geen e-mail aan.

Of WordPress verstuurt geen:

password reset;
nieuwe gebruiker;
WooCommerce-order;
formuliermelding.

Dit betekent niet noodzakelijk dat WordPress helemaal geen mail probeert te versturen.

Het probleem van PHP mail

WordPress gebruikt standaard de beschikbare mailfunctionaliteit van de server.

E-maildelivery is echter complex.

Een bericht kan:

niet worden verzonden;
in spam belanden;
door ontvangende mailservers worden geweigerd;
SPF/DKIM-problemen hebben.

Betere oplossing

Voor belangrijke websites is het verstandig een betrouwbare SMTP- of transactionele mailoplossing te gebruiken.

Controleer daarnaast:

SPF;
DKIM;
DMARC waar passend;
From-adres;
mail logs.

Bij WooCommerce moet e-maildelivery zeker gemonitord worden.

Een bestelling die technisch is gelukt maar waarvan niemand een e-mail ontvangt is een bedrijfsprobleem.

22. WordPress-update mislukt

Een WordPress-, theme- of pluginupdate kan om verschillende redenen stoppen.

Bijvoorbeeld:

timeout;
onvoldoende schijfruimte;
permissions;
netwerkfout;
serverprobleem;
incompatibiliteit.

Wat doe je?

Controleer eerst:

of de website nog werkt;
of .maintenance is achtergebleven;
error logs;
beschikbare schijfruimte;
PHP-errors.

Start niet direct vijf keer dezelfde update opnieuw.

Wanneer een update gedeeltelijk bestanden heeft vervangen, kan de installatie in een inconsistente toestand zitten.

Herstel eventueel eerst vanuit een backup of vervang beschadigde bestanden met een bekende correcte versie.

23. Pluginupdate heeft de website kapotgemaakt

Dit is één van de eenvoudigste situaties om te diagnosticeren wanneer je exact weet welke update net is uitgevoerd.

Kun je inloggen?

Deactiveer de betreffende plugin.

Kun je niet inloggen?

Ga naar:

wp-content/plugins/

en hernoem de directory van de plugin.

Bijvoorbeeld:

plugin-name

naar:

plugin-name-disabled

Test opnieuw.

Werkt de website weer?

Dan heb je de oorzaak waarschijnlijk gevonden.

Wat daarna?

Ga niet meteen permanent terug naar een willekeurig oude pluginversie.

Controleer:

changelog;
PHP-compatibiliteit;
WordPress-compatibiliteit;
themecompatibiliteit;
bekende problemen;
vendor support.

Gebruik een rollback alleen bewust en tijdelijk wanneer dat veilig kan.

Een oude versie kan immers een beveiligingslek bevatten.

24. Theme-update veroorzaakt een fout

Hetzelfde principe geldt voor themes.

Mogelijke oorzaken zijn:

incompatibele template override;
oude child theme-code;
WooCommerce template incompatibility;
PHP-fout;
verwijderd theme-functionality.

Test indien mogelijk tijdelijk met een standaard WordPress-theme.

Wanneer het probleem dan verdwijnt, weet je dat de oorzaak waarschijnlijk theme-gerelateerd is.

Controleer vooral maatwerk in:

functions.php

en eventuele child theme overrides.

25. CSS-wijzigingen worden niet zichtbaar

Je past iets aan, maar de website blijft de oude versie tonen.

Dit is vaak geen WordPress-fout maar een cachingprobleem.

Er kunnen verschillende caches bestaan:

browsercache;
WordPress cacheplugin;
server-side page cache;
object cache;
CDN-cache;
reverse proxy.

Troubleshooting

Controleer eerst in incognitomodus.

Leeg daarna alleen de relevante caches.

Verwijder niet onmiddellijk alle caches, object caches en CDN-data tegelijk als je juist wilt ontdekken welke laag het probleem veroorzaakt.

26. Wijzigingen aan pagina's worden niet zichtbaar

Dezelfde situatie kan optreden met HTML/content.

Controleer:

pagina daadwerkelijk gepubliceerd?
juiste pagina aangepast?
preview of productie?
cache?
pagebuilder cache?
CDN?
static page generation?

Bij multisite- of meertalige websites is het bovendien makkelijk per ongeluk een andere taal- of sitevariant aan te passen.

27. WordPress-site is plotseling extreem langzaam

Een trage site is niet altijd een "error", maar vaak wel het eerste symptoom van een probleem.

Mogelijke oorzaken:

pluginupdate;
databaseprobleem;
botverkeer;
externe API;
cache werkt niet;
PHP worker saturation;
serverload;
cronjob;
backup;
malware;
disk bijna vol.

Kijk eerst naar TTFB

Wanneer de eerste byte extreem lang duurt, onderzoek de server/backend.

Wanneer HTML snel komt maar de browser daarna lang bezig is, kijk eerder naar:

JavaScript;
CSS;
afbeeldingen;
third-party scripts.

Zo voorkom je dat je een frontendprobleem met een hostingupgrade probeert op te lossen of andersom.

28. WordPress-dashboard is langzaam terwijl de website snel is

Dit zie je regelmatig bij goed gecachete websites.

De voorkant wordt uit page cache geserveerd en is razendsnel.

wp-admin is echter dynamisch.

Daar kunnen zware:

databasequeries;
dashboardwidgets;
WooCommerce-processen;
API-calls;
plugins;
scheduled actions

zichtbaar worden.

Controleer met profilingtools welke queries en hooks veel tijd gebruiken.

Een page-cacheplugin lost een langzaam dashboard meestal niet op.

29. WordPress cronjobs lopen niet

WordPress gebruikt WP-Cron voor geplande taken.

Bijvoorbeeld:

scheduled posts;
e-mails;
backups;
cleanup;
WooCommerce-taken;
synchronisaties.

Standaard wordt WP-Cron grotendeels door websiteverkeer getriggerd.

Op sites met weinig verkeer kunnen taken daardoor later worden uitgevoerd dan verwacht.

Op zeer drukke of complexe sites kan juist een echte servercron geschikter zijn.

Controleer bovendien:

of DISABLE_WP_CRON is ingesteld;
of een echte cron bestaat;
of scheduled actions vastlopen;
of er fatale PHP-errors zijn.

30. Geplande berichten worden niet gepubliceerd

Een bericht staat gepland voor 10:00 maar blijft op:

Gemiste planning

staan.

Dit kan wijzen op WP-Cron-problemen.

Controleer:

cronconfiguratie;
servercron;
loopback requests;
caching;
pluginconflicten.

Een veelbezochte productiewebsite kan baat hebben bij een echte servercron in plaats van uitsluitend traffic-driven WP-Cron.

31. WooCommerce checkout werkt niet

Een checkoutprobleem moet voorzichtig worden onderzocht omdat veel systemen tegelijk betrokken kunnen zijn:

WordPress;
WooCommerce;
theme;
payment provider;
JavaScript;
cookies;
caching;
sessions;
externe API;
securityregels.

Controleer eerst

Test:

incognito;
verschillende betaalmethode;
browserconsole;
WooCommerce logs;
PHP logs;
REST/AJAX requests.

Cache de checkout niet als normale statische pagina

Dynamische pagina's zoals:

winkelwagen;
checkout;
My Account

moeten normaal gesproken correct worden uitgesloten van full-page caching.

Een foutieve cacheconfiguratie kan zeer vreemde checkoutproblemen veroorzaken.

32. AJAX- of REST API-fouten

Moderne WordPress-sites gebruiken regelmatig:

REST API;
admin-ajax.php;
WooCommerce Store API;
maatwerkendpoints.

Wanneer functionaliteit plots stopt, open dan de Network-tab in browser developer tools.

Zoek requests met bijvoorbeeld:

400;
401;
403;
404;

De HTTP-status vertelt veel.

401 wijst vaak op authenticatie.

403 op permissions/firewall.

404 op endpoint/routing.

500 op een server-side fout.

Schakel de REST API niet simpelweg uit om een REST-probleem "op te lossen". Veel moderne WordPress-functionaliteit gebruikt deze API.

33. "Headers already sent"

Een typische fout:

Cannot modify header information - headers already sent

betekent dat PHP al output naar de browser heeft gestuurd voordat WordPress nog HTTP-headers probeerde aan te passen.

Dit kan komen door:

ongewenste whitespace;
echo;
debugoutput;
BOM;
foutieve plugin/theme-code.

De melding bevat meestal informatie over het bestand waar de output begon.

Controleer dat bestand.

Verwijder niet willekeurig code uit WordPress Core om de waarschuwing te verbergen.

Los de eerste output op.

34. Syntax error na het aanpassen van PHP

Bijvoorbeeld:

Parse error: syntax error, unexpected ...

Dit betekent meestal dat PHP-code syntactisch ongeldig is.

Veelvoorkomende oorzaken:

ontbrekende ;;
verkeerde quote;
ontbrekende };
verkeerd geplakte snippet.

Wanneer de fout ontstond nadat je functions.php hebt aangepast, is de meest waarschijnlijke oorzaak duidelijk.

Gebruik SFTP/File Manager om de wijziging terug te draaien.

Plak liever geen willekeurige PHP-snippets van internet rechtstreeks in productie zonder:

te begrijpen wat ze doen;
backup;
stagingtest.

35. WordPress kan geen bestanden schrijven

Soms verschijnt bijvoorbeeld:

Could not create directory

of WordPress kan geen:

plugin installeren;
update uitvoeren;
afbeelding uploaden.

Dit wijst vaak op:

permissions;
ownership;
diskruimte;
filesystemconfiguratie.

Controleer diskruimte

Een volledig bestandssysteem veroorzaakt verrassend veel verschillende WordPress-problemen.

Denk aan:

uploads mislukken;
database stopt;
logs kunnen niet schrijven;
caches breken;
updates mislukken.

Controleer dus altijd vrije opslagruimte wanneer meerdere ongerelateerde functies tegelijkertijd fouten geven.

36. WordPress vraagt plots om FTP-gegevens

Tijdens plugininstallaties of updates kan WordPress soms FTP-credentials vragen.

Dat gebeurt vaak wanneer WordPress niet rechtstreeks naar het filesystem kan schrijven onder de huidige serverconfiguratie.

De beste oplossing is niet automatisch credentials hardcoden in wp-config.php.

Onderzoek eerst:

ownership;
permissions;
PHP-user;
hostingconfiguratie.

Op goed ingerichte managed hosting hoort dit normaal gesproken door de hostingomgeving correct geregeld te zijn.

37. Database lijkt beschadigd

Soms melden WordPress of database-tools dat een tabel beschadigd is.

Maak eerst een databasebackup.

WordPress ondersteunt een ingebouwde reparatiemogelijkheid via:

define( 'WP_ALLOW_REPAIR', true );

Wanneer dit tijdelijk in wp-config.php staat, kan de database repair-interface beschikbaar worden gemaakt.

Maar let op:

de repairpagina kan in deze modus zonder normale WordPress-login bereikbaar zijn.

Verwijder daarom:

define( 'WP_ALLOW_REPAIR', true );

weer onmiddellijk nadat de reparatie is afgerond.

Gebruik database repair bovendien niet als dagelijkse "optimalisatie".

Als tabellen regelmatig beschadigd raken, onderzoek dan de onderliggende database- of serverproblemen.

38. WordPress-site toont een oude URL na migratie

Na een migratie zie je bijvoorbeeld nog links naar:

old-domain.nl

Mogelijke locaties zijn:

WordPress Site URL;
databasecontent;
widgets;
pagebuilderdata;
serialized pluginsettings;
custom themecode.

Gebruik voor een grootschalige database search-and-replace een WordPress-compatibele tool die serialized data begrijpt.

Een simpele tekstuele zoek-en-vervangactie kan complex opgeslagen data beschadigen.

Maak altijd eerst een backup.

39. Afbeeldingen zijn verdwenen na een migratie

Controleer:

bestaat wp-content/uploads?
zijn alle bestanden daadwerkelijk gemigreerd?
klopt de URL?
permissions?
CDN-configuratie?
HTTP vs HTTPS?
filesystem case sensitivity?

Open één kapotte afbeelding rechtstreeks via de URL.

De statuscode helpt:

404 → bestand/pad niet gevonden;
403 → toegang geblokkeerd;
500 → serverfout;
verkeerde afbeelding → caching/CDN mogelijk.

40. WordPress blijft terugsturen naar de oude domeinnaam

Dit gebeurt regelmatig na migraties.

Controleer:

WordPress Address;
Site Address;
wp-config.php;
database;
serverredirects;
.htaccess;
CDN;
browsercache.

Zoek de eerste redirect in plaats van voortdurend refreshen.

Browser developer tools of een HTTP-headercontrole maakt zichtbaar welke server de redirect daadwerkelijk verstuurt.

41. DNS lijkt niet te werken na een migratie

Wanneer je nameservers of DNS-records hebt gewijzigd, kan een probleem buiten WordPress liggen.

Controleer:

A-record;
AAAA-record;
CNAME;
nameservers;
DNSSEC;
TTL;
welk IP-adres daadwerkelijk wordt geresolved.

Als DNS naar de verkeerde server wijst, kan geen enkele WordPress-instelling dat oplossen.

42. Website werkt bij jou maar niet bij anderen

Dit kan wijzen op:

DNS-cache;
CDN edge;
firewall;
geo-blocking;
ISP-cache;
lokale hosts file;
browsercache.

Test daarom vanuit:

mobiel netwerk;
andere locatie;
externe uptimecheck.

Controleer ook welke IP-adressen verschillende DNS-resolvers teruggeven.

43. Alleen mobiele bezoekers hebben problemen

Dan is de oorzaak waarschijnlijk niet simpelweg "WordPress is offline".

Controleer:

responsive CSS;
mobile caching;
device-specific redirects;
mobiele menu-JavaScript;
cookie banners;
CDN rules;
user-agent rules.

Test op een echt mobiel apparaat én via browserdeveloper tools.

44. WordPress laat wijzigingen na een pluginupdate niet zien

Sommige plugins genereren:

CSS-cache;
JavaScriptbundles;
templates;
object-cachedata.

Na een update kunnen oude gegenereerde bestanden blijven bestaan.

Leeg eerst alleen de relevante plugin/cachelaag.

Controleer ook CDN-cache.

Doe geen database cleanup als eerste stap wanneer het probleem duidelijk front-end caching betreft.

45. Plugin kan niet worden geactiveerd vanwege een fatal error

WordPress voorkomt soms dat een plugin wordt geactiveerd wanneer de activatie direct een fatale fout veroorzaakt.

Controleer:

PHP-versie;
WordPress-versie;
ontbrekende dependency;
vereiste PHP-extension;
pluginconflict;
error log.

Een fout zoals:

Call to undefined function

kan bijvoorbeeld betekenen dat:

een dependency ontbreekt;
een extension ontbreekt;
de plugin code verwacht die niet beschikbaar is.

Lees daarom de volledige error, niet alleen de eerste regel.

46. "Call to undefined function"

Deze PHP-fout betekent letterlijk dat code een functie probeert aan te roepen die op dat moment niet bestaat.

Mogelijke oorzaken:

plugin dependency niet actief;
incompatibele pluginversies;
ontbrekende PHP-extension;
foutieve laadvolgorde;
gedeeltelijke update;
custom code.

De foutmelding geeft meestal:

functie;
bestand;
regelnummer.

Dat is waardevolle informatie.

Begin daar.

47. "Class not found"

Een vergelijkbaar probleem:

Class ... not found

Kan wijzen op:

ontbrekende plugin;
dependency;
autoloaderprobleem;
incomplete deployment;
verkeerde pluginversies;
PHP-code die te vroeg wordt uitgevoerd.

Controleer bij Composer-gebaseerde projecten ook of dependencies correct zijn geïnstalleerd.

48. "Maximum number of database connections" of tijdelijke databaseproblemen

Wanneer de databaseverbinding bij piekverkeer faalt maar een paar minuten later vanzelf herstelt, controleer databaseconnection-limieten.

Mogelijke oorzaken:

te veel gelijktijdige requests;
trage queries houden connecties lang open;
bots;
zware plugins;
onvoldoende databasecapaciteit.

Dit is een ander probleem dan verkeerde credentials.

Het aanpassen van wp-config.php heeft dan weinig zin.

Onderzoek servermetrics en databaseprocessen.

49. WordPress Site Health geeft waarschuwingen

Ga naar:

Gereedschap → Sitediagnose

Site Health kan problemen signaleren rond onder andere:

PHP;
HTTPS;
REST API;
loopback requests;
updates;
caching;
scheduled events.

Niet iedere waarschuwing is een noodsituatie.

Lees daarom wat WordPress precies zegt en onderzoek de oorzaak.

Installeer niet automatisch een plugin voor iedere Site Health-waarschuwing.

50. "Loopback request failed"

WordPress kan requests naar zichzelf uitvoeren.

Dit wordt onder andere gebruikt door bepaalde achtergrondprocessen.

Wanneer loopback requests mislukken, kijk dan naar:

DNS;
firewall;
HTTP-authentication;
SSL;
serverconfiguratie;
securityplugins.

Bij stagingomgevingen met Basic Authentication is het bijvoorbeeld logisch dat interne requests aanvullende authenticatie nodig kunnen hebben.

51. REST API geeft een fout in Site Health

De WordPress REST API wordt gebruikt door moderne WordPress-functionaliteit.

Een mislukte REST-test kan worden veroorzaakt door:

firewall;
securityplugin;
verkeerde URL;
SSL;
serverredirect;
authentication;
pluginfout.

Schakel de REST API niet automatisch uit.

Onderzoek welk request precies faalt en welke statuscode wordt teruggestuurd.

52. WordPress kan geen verbinding maken met externe services

Plugins communiceren regelmatig met externe API's.

Bijvoorbeeld:

payment provider;
licensing server;
update server;
CRM;
shipping;
Google;
e-maildienst.

Wanneer een API-call faalt, kan de oorzaak liggen bij:

DNS;
TLS;
firewall;
timeout;
rate limit;
verkeerde API key;
externe storing.

Controleer dus niet alleen WordPress.

Een externe dienst kan simpelweg tijdelijk offline zijn.

53. CAPTCHA, Maps of externe widgets werken niet meer

Bij externe diensten kunnen API keys:

verlopen;
beperkt zijn;
quota bereiken;
verkeerde domeinrestricties hebben.

Open de browserconsole en Network-tab.

Een duidelijke 401, 403 of externe API-error geeft vaak sneller antwoord dan WordPress-debugging.

54. WordPress-formulier werkt maar bezoekers krijgen een fout

Formulieren combineren vaak:

JavaScript;
AJAX;
REST;
spamfilter;
mailserver;
database;
third-party API.

Test daarom het volledige proces:

kan het formulier worden ingevuld?
wordt de request verstuurd?
antwoordt de server correct?
wordt de inzending opgeslagen?
wordt de e-mail verstuurd?
wordt de e-mail afgeleverd?

"Het formulier werkt niet" zijn eigenlijk zes verschillende mogelijke problemen.

55. Je ziet PHP warnings of notices bovenaan de website

Bijvoorbeeld:

Warning: Undefined array key ...

of:

Deprecated: ...

Dit betekent meestal dat debugging/output verkeerd staat voor productie of dat plugin/theme-code waarschuwingen veroorzaakt.

Op een productieomgeving horen gedetailleerde PHP-errors normaal gesproken niet openbaar zichtbaar te zijn.

Ze kunnen:

bezoekers verwarren;
paden en technische informatie onthullen;
HTML of headers breken.

Los de onderliggende code op en configureer logging correct.

WordPress debugging veilig inschakelen

Wanneer een fout niet duidelijk is, kan WordPress debugging helpen.

In wp-config.php kun je bijvoorbeeld gebruiken:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Hiermee kan WordPress debuginformatie loggen zonder dat alle foutmeldingen direct aan bezoekers worden getoond.

Het logbestand staat standaard vaak in:

wp-content/debug.log

Belangrijk

Laat debugging niet permanent zonder reden actief op productie.

Een debuglog kan:

enorm groot worden;
gevoelige technische informatie bevatten;
diskruimte gebruiken.

Controleer hem, los het probleem op en zet debugging daarna weer passend terug.

Hoe je een WordPress-fout systematisch onderzoekt

Wanneer je niet weet welke van bovenstaande fouten van toepassing is, gebruik dan dit stappenplan.

Stap 1: noteer de exacte foutmelding

Niet:

"WordPress werkt niet."

Maar:

"500 Internal Server Error bij /wp-admin/plugins.php sinds pluginupdate."

Dat maakt troubleshooting veel gerichter.

Stap 2: noteer het tijdstip

Logs zijn vaak enorm.

Wanneer je weet dat de fout om:

14:32

optrad, kun je veel eenvoudiger de juiste logregel vinden.

Stap 3: controleer recente wijzigingen

Vraag:

wat is geüpdatet?
wat is geïnstalleerd?
wat is gewijzigd?
is PHP aangepast?
is DNS gewijzigd?

Stap 4: controleer logs

Zoek naar de eerste relevante fout rond hetzelfde tijdstip.

Stap 5: maak een backup

Voordat je wijzigingen uitvoert.

Stap 6: test één hypothese

Niet tien tegelijkertijd.

Stap 7: controleer opnieuw

Is de fout weg?

Stap 8: zoek de onderliggende oorzaak

Een workaround is niet altijd een oplossing.

Wat je juist niet moet doen bij WordPress-fouten

Tien plugins tegelijk uitschakelen en instellingen veranderen

Dan weet je achteraf niet welke wijziging verschil maakte.

Willekeurige PHP-code uit blogs kopiëren

Een snippet die voor iemand anders werkte kan in jouw omgeving onnodig of zelfs gevaarlijk zijn.

Permissions op 777 zetten

Daarmee behandel je een configuratieprobleem door de beveiliging te verzwakken.

PHP memory limit eindeloos verhogen

Onderzoek eerst waarom zoveel geheugen nodig is.

Timeouts steeds hoger zetten

Een request dat extreem lang duurt kan een onderliggend performanceprobleem hebben.

WordPress Core-bestanden handmatig aanpassen

Corewijzigingen worden bovendien bij updates overschreven.

Debugerrors publiek tonen op productie

Log ze liever veilig.

Databasewijzigingen uitvoeren zonder backup

Een verkeerde query is in seconden uitgevoerd en soms zeer lastig terug te draaien.

Plugins downloaden van willekeurige websites

Gebruik officiële of betrouwbare bronnen.

Wanneer ligt het probleem waarschijnlijk bij WordPress?

Denk vooral aan WordPress wanneer:

de fout direct na een pluginupdate begon;
één pluginfunctionaliteit niet werkt;
het theme fouten geeft;
WordPress een Critical Error toont;
logs naar wp-content/plugins/... verwijzen;
logs naar themebestanden verwijzen.

Wanneer ligt het probleem waarschijnlijk bij hosting of serverconfiguratie?

Denk eerder aan infrastructuur wanneer:

meerdere websites tegelijk offline zijn;
MySQL niet bereikbaar is;
diskruimte volledig vol zit;
PHP-FPM down is;
502/503-errors massaal optreden;
SSL-certificaat niet correct is;
DNS verkeerd staat;
serverresources constant tegen limieten lopen.

WordPress en hosting zijn nauw met elkaar verbonden, maar niet iedere WordPress-fout ontstaat in WordPress-code.

Wanneer moet je de hostingprovider contacteren?

Neem contact op met je hostingprovider wanneer je bijvoorbeeld hebt vastgesteld dat:

databaseserver niet bereikbaar is;
serverlogs niet toegankelijk zijn;
PHP-FPM faalt;
diskruimte of inode-limieten zijn bereikt;
permissions/ownership op serverniveau fout zijn;
SSL niet correct wordt vernieuwd;
502/503/504-errors infrastructuurgerelateerd zijn;
serverresources structureel tegen limieten lopen.

Geef support zoveel mogelijk concrete informatie.

Dus liever:

Sinds 14:32 geeft /wp-admin/ een 503. De frontendcache blijft werken. Er is geen recente WordPress-update geweest en de fout treedt op zodra PHP wordt aangesproken.

dan:

Mijn WordPress werkt niet. Kunnen jullie kijken?

Hoe specifieker de informatie, hoe sneller de oorzaak meestal te vinden is.

Wanneer moet je een WordPress-developer inschakelen?

Een developer is vooral nuttig wanneer:

maatwerkcode fouten veroorzaakt;
pluginconflicten complex zijn;
custom REST API's niet werken;
databasequeries extreem langzaam zijn;
een deployment fout ging;
een theme fundamenteel kapot is;
malware of onverwachte code is gevonden.

Hosting kan de server onderzoeken, maar een hostingprovider is niet automatisch verantwoordelijk voor alle applicatiecode binnen WordPress.

Andersom kan een developer een offline databaseserver niet vanuit WordPress repareren.

Een goede diagnose bepaalt dus eerst in welke laag het probleem zit.

WordPress-fouten voorkomen

Veel problemen zijn nooit volledig te voorkomen.

Maar je kunt de kans én impact sterk verkleinen.

Houd WordPress bijgewerkt

Gebruik actuele versies van:

WordPress Core;
plugins;
themes;
PHP.

Gebruik staging

Test grotere updates voordat je ze op productie uitvoert.

Maak automatische backups

En test of ze daadwerkelijk kunnen worden teruggezet.

Monitor uptime

Ontdek problemen voordat klanten ze melden.

Monitor errors

Een stijgende hoeveelheid PHP-errors kan een probleem aangeven voordat de website volledig uitvalt.

Verwijder ongebruikte plugins

Minder onderdelen betekent minder potentiële conflicten.

Gebruik betrouwbare hosting

Een stabiele PHP-, database- en filesystemomgeving vormt de basis waarop WordPress draait.

Documenteer wijzigingen

Bij zakelijke websites is het handig te weten:

wie;
wanneer;
welke wijziging

heeft uitgevoerd.

Dat maakt troubleshooting aanzienlijk eenvoudiger.

Snelle WordPress troubleshooting-checklist

Wanneer je WordPress-website vandaag een fout geeft, kun je deze volgorde gebruiken:

Veelgestelde vragen over WordPress-fouten

Waarom krijg ik een Critical Error in WordPress?

Een Critical Error betekent meestal dat een fatale PHP-fout is opgetreden. De oorzaak kan bijvoorbeeld een plugin, theme, maatwerkcode, PHP-incompatibiliteit of geheugenprobleem zijn.

Controleer eerst de Recovery Mode-e-mail en server/PHP-logs.

Hoe schakel ik alle WordPress-plugins uit als ik niet meer kan inloggen?

Via SFTP of File Manager kun je:

wp-content/plugins

tijdelijk hernoemen.

Bijvoorbeeld naar:

plugins-disabled

WordPress kan de plugins vervolgens niet meer normaal laden.

Wanneer de website daarna weer werkt, herstel je de directorynaam en onderzoek je plugins één voor één.

Hoe los ik Error establishing a database connection op?

Controleer eerst de databasegegevens in wp-config.php:

database name;
username;
password;
host.

Zijn deze correct? Controleer dan of de databaseserver daadwerkelijk bereikbaar is en of limits zoals maximale databaseconnections niet worden bereikt.

Hoe los ik een 500 Internal Server Error op?

Begin met de server- en PHP-error logs.

Een 500-melding vertelt op zichzelf weinig.

Veel voorkomende oorzaken zijn:

PHP fatal errors;
plugins;
.htaccess;
memory issues;
permissions;
serverconfiguratie.

Waarom krijg ik 404-errors terwijl de homepage werkt?

Dat is vaak een permalink/rewriteprobleem.

Ga eerst naar:

Instellingen → Permalinks

en sla de instellingen opnieuw op.

Blijft het probleem bestaan, controleer dan .htaccess, Apache/Nginx rewrite rules of custom post type-configuratie.

Hoe kom ik uit WordPress maintenance mode?

Wanneer WordPress na een onderbroken update blijft melden:

Briefly unavailable for scheduled maintenance

controleer dan in de WordPress-root of .maintenance is achtergebleven.

Verwijder dit bestand en controleer daarna of de mislukte update correct moet worden opnieuw uitgevoerd.

Waarom ontvang ik geen WordPress-e-mails?

Mogelijk verstuurt de server de e-mail niet correct of wordt deze door de ontvangende mailserver geweigerd.

Gebruik voor belangrijke websites bij voorkeur een betrouwbare SMTP- of transactionele mailoplossing en controleer SPF/DKIM-configuratie en mail logs.

Waarom blijft mijn WordPress-website langzaam ondanks dat ik geen foutmelding zie?

Performanceproblemen kunnen veroorzaakt worden door onder andere:

zware plugins;
trage databasequeries;
externe API's;
onvoldoende PHP workers;
ontbrekende caching;
serverbelasting.

Een website hoeft geen foutmelding te tonen om technisch een probleem te hebben.

Is opnieuw installeren van WordPress een goede eerste oplossing?

Nee.

Een volledige reinstall is zelden de beste eerste stap.

Identificeer eerst de oorzaak.

Een pluginfout los je bijvoorbeeld niet structureel op door WordPress Core opnieuw te installeren.

Bij beschadigde Core-bestanden kan het opnieuw plaatsen van schone WordPress Core-bestanden wel onderdeel zijn van de oplossing, maar doe dit gecontroleerd.

De belangrijkste regel: los de oorzaak op, niet alleen de foutmelding

Bij WordPress-troubleshooting is het verleidelijk om te zoeken naar:

"Hoe krijg ik deze foutmelding weg?"

Maar de betere vraag is:

"Waarom verschijnt deze foutmelding?"

Stel dat een site een 504 Gateway Timeout geeft.

Je kunt de timeout verhogen van 60 naar 300 seconden.

De foutmelding verdwijnt misschien.

Maar wanneer één databasequery nog steeds 90 seconden nodig heeft, heb je het probleem niet werkelijk opgelost.

Hetzelfde geldt voor:

memory limits;
databaseconnections;
PHP errors;
maintenance mode;
cachingproblemen.

Een goede WordPress-reparatie verwijdert niet alleen het zichtbare symptoom, maar identificeert de onderliggende oorzaak.

Een betrouwbare WordPress-omgeving maakt troubleshooting eenvoudiger

WordPress-fouten kunnen ontstaan in verschillende lagen:

Browser → DNS → CDN/proxy → webserver → PHP → WordPress → plugin/theme → database → externe API

Daarom is het belangrijk systematisch te onderzoeken waar de keten breekt.

Een goede hostingomgeving helpt daarbij met bijvoorbeeld:

duidelijke serverlogs;
actuele PHP-versies;
betrouwbare backups;
resource monitoring;
databasebeheer;
SSL/TLS;
SFTP-toegang;
stagingmogelijkheden.

Blijft een WordPress-website fouten geven en blijkt het probleem op serverniveau te zitten? Dan kan Actiefhost helpen onderzoeken wat er in de hostingomgeving gebeurt.

Ligt de oorzaak in een plugin, theme of maatwerkcode, dan weet je na een goede serverdiagnose in ieder geval precies waar je verder moet zoeken.

Het belangrijkste is om niet te gokken.

Meten, logs lezen, één oorzaak tegelijk testen en pas daarna aanpassen.

Dat is vrijwel altijd de snelste manier om een WordPress-fout goed op te lossen.

Controleer Domeinbeschikbaarheid

Handige Tools

Populaire Domeinextensies

Webhosting voor uw website

Webhosting voor uw CMS

Website Migratie

Veelvoorkomende WordPress-fouten oplossen: complete handleiding

Veelvoorkomende WordPress-fouten oplossen: complete handleiding

Maak eerst een backup voordat je gaat troubleshooten

Begin altijd met deze vijf controles

1. Wat is er vlak vóór het probleem veranderd?

2. Werkt alleen één pagina niet of de hele website?

3. Kun je nog inloggen in WordPress?

4. Werkt het probleem ook in een andere browser?

5. Controleer de serverlogs

1. "There has been a critical error on this website"

Veelvoorkomende oorzaken

Controleer eerst je e-mail

Geen Recovery Mode-e-mail ontvangen?

2. White Screen of Death: volledig wit WordPress-scherm

Mogelijke oorzaken

Stap 1: controleer of /wp-admin/ werkt

Stap 2: schakel plugins tijdelijk uit

Stap 3: controleer het actieve theme

3. 500 Internal Server Error

Veelvoorkomende oorzaken

Stap 1: controleer de error logs

Stap 2: controleer .htaccess

Stap 3: test plugins

Stap 4: controleer PHP

4. Error establishing a database connection

Mogelijke oorzaken

Stap 1: controleer wp-config.php

Stap 2: controleer of de databaseserver bereikbaar is

De fout komt maar af en toe voor

5. "Briefly unavailable for scheduled maintenance"

Oplossing

6. WordPress geeft 404-fouten op berichten en pagina's

Eenvoudigste oplossing

Werkt dat niet?

Apache

Nginx

Alleen één custom post type geeft 404

7. WordPress admin geeft 404

8. 403 Forbidden

Mogelijke oorzaken

Controleer eerst of het probleem overal voorkomt

Bestandsrechten

9. 502 Bad Gateway

Mogelijke oorzaken

Wat moet je controleren?

10. 503 Service Unavailable

Mogelijke oorzaken

11. 504 Gateway Timeout

Zoek de langzame stap

12. ERR_TOO_MANY_REDIRECTS

Veelvoorkomende oorzaken bij WordPress

Controleer WordPress URL-instellingen

Achter Cloudflare of een andere proxy?

13. "Your connection is not private" of SSL-certificaatfout

14. Mixed Content na overstappen naar HTTPS

Mogelijke bronnen

Oplossing

15. Je kunt niet meer inloggen in WordPress

Wachtwoord vergeten

Loginpagina refreshes zonder in te loggen

Securityplugin heeft je geblokkeerd

16. WordPress blijft uitloggen

17. Uploaden van afbeeldingen mislukt

Mogelijke oorzaken

Grote afbeeldingen

18. "The uploaded file exceeds the upload_max_filesize directive"

19. "Allowed memory size exhausted"

Mogelijke oorzaken

Alleen geheugen verhogen?

20. "Maximum execution time exceeded"

21. WordPress-e-mails worden niet ontvangen

Het probleem van PHP mail

Betere oplossing

22. WordPress-update mislukt

Stap 1: controleer of `/wp-admin/` werkt

Stap 2: controleer `.htaccess`

Stap 1: controleer `wp-config.php`