
Je opent je website of wp-admin en ziet een melding die je niet begrijpt, of helemaal niets. De meest voorkomende WordPress-fouten zijn de kritieke fout, het witte scherm, de databaseverbindingsfout, serverfouten 500 tot 504, te veel redirects, mixed content en de geheugenlimiet. Bijna allemaal komen ze door een plugin, thema, update of serverinstelling.
Dat maakt het minder erg dan het lijkt, want de meeste WordPress-problemen los je op zonder gegevensverlies, zolang je in de goede volgorde werkt. WordPress-fouten oplossen begint met vier vaste stappen, en daarna lees je per melding wat de oorzaak is en waar de oplossing staat.
Eerst dit: vier stappen die bij elke WordPress-fout helpen
Bij elke WordPress-fout werk je in dezelfde volgorde, ongeacht welke melding je ziet. Ik vergelijk een foutmelding met een waarschuwingslampje op je dashboard. Het lampje zegt dat er iets mis is, maar pas de uitleesapparatuur van de garage vertelt je wat. In WordPress is het foutlog die uitleesapparatuur, en daarom staat het lezen van de echte melding hieronder vóór het repareren.
- Verwijder niets. Wis geen plugins of bestanden en herinstalleer niets voordat je weet wat er mis is. Uitschakelen kun je terugdraaien, verwijderen niet.
- Maak een back-up of controleer of er een recente is. Doe dat ook als je site al kapot is. Bij Surver zet je back-ups terug met JetBackup 5 in cPanel, maar de huidige staat wordt daarbij niet automatisch bewaard. Hoe dat werkt, lees je bij back-up terugzetten.
- Maak de echte foutmelding zichtbaar. Bij een kritieke fout mailt WordPress het beheerdersadres een link naar de herstelmodus (recovery mode), waarmee je inlogt met de schuldige plugin gepauzeerd. Geen mail ontvangen? Zet dan
WP_DEBUGaan zoals beschreven in debug-modus inschakelen en leeswp-content/debug.log, of open het foutlog van de server. Bij Surver is dat het bestanderror_login de map waar de fout optreedt, te openen via File Manager in cPanel. - Draai de laatste wijziging terug. Denk aan een update, een nieuwe plugin, een codefragment of een instelling. Kom je niet in
wp-admin, hernoem dan via (S)FTP of File Manager de pluginmap inwp-content/plugins, of de hele map plugins om alles tegelijk uit te zetten. Ligt het aan het thema, hernoem dan de themamap inwp-content/themes, zodat WordPress terugvalt op een standaardthema. Meer daarover in site kapot na een update.
In de praktijk is het merendeel van de fouten na stap 4 al verholpen. Lukt dat niet, dan weet je dankzij stap 3 in elk geval waar je verder moet zoeken.
Welke WordPress-fout zie je? Overzicht van foutmeldingen
Deze tabel koppelt de bekendste WordPress-foutmeldingen, letterlijk zoals je ze op je scherm ziet, aan hun betekenis, de meest waarschijnlijke oorzaak en het artikel met de oplossing. De kolom “Zelf of hosting” laat zien wie de fout meestal oplost.
| Wat je ziet | Wat het betekent | Meest waarschijnlijke oorzaak | Zelf of hosting | Oplossing |
|---|---|---|---|---|
| “Er heeft zich een kritieke fout voorgedaan op deze site” | WordPress vangt een fatale PHP-fout af. | Plugin- of thema-update, oude PHP-versie | Meestal zelf | ‘Er heeft zich een kritieke fout voorgedaan’ oplossen |
| “Er is een fout bij het maken van een databaseverbinding” (“Error establishing a database connection”) | WordPress bereikt de database niet. | Gegevens in wp-config.php, overbelaste databaseserver | Samen | de databaseverbindingsfout oplossen |
| Een volledig wit scherm | Er gaat iets mis zonder melding. | Plugin, thema of PHP-fout | Meestal zelf | white screen of death oplossen |
| “Kort niet beschikbaar wegens gepland onderhoud” | WordPress staat nog in onderhoudsmodus. | Onderbroken update | Zelf | vast in onderhoudsmodus |
| Statuscode 500 of “Internal Server Error” | De server kan het verzoek niet afhandelen. | .htaccess, plugin of PHP-fout | Meestal zelf | statuscode 500 |
| Statuscode 502, 503 of 504 | De server antwoordt traag of niet. | Overbelasting, zware processen, onderhoud | Meestal hosting | statuscode 502, 503, 504 |
| Statuscode 403 of “Forbidden” | De server weigert toegang. | Firewall blokkeert je IP, .htaccess, bestandsrechten | Samen | statuscode 403 |
“Deze pagina werkt niet, te vaak omgeleid” (ERR_TOO_MANY_REDIRECTS) | Adressen sturen eindeloos naar elkaar door. | Site-URL, dubbele HTTPS-redirects, CDN | Meestal zelf | te veel redirects oplossen |
| Geen slotje of “niet volledig beveiligd” na de overstap naar HTTPS | Onderdelen laden nog via http://. | Oude verwijzingen in de database | Zelf | mixed content oplossen |
| “Allowed memory size exhausted” | Een script vraagt te veel PHP-geheugen. | Zware plugin of lage limiet | Samen | de geheugenlimiet verhogen |
| “Het geüploade bestand overschrijdt de upload_max_filesize-instructie” | Het bestand is te groot voor de server. | Uploadlimiet in PHP | Zelf | de maximale uploadgrootte verhogen |
| “cURL error 28” in Sitediagnose | Een uitgaande verbinding loopt in een time-out. | Trage externe dienst of firewall | Samen | cURL error 28 |
Je site laadt niet of toont een leeg scherm
Dit zijn de fouten waarbij je hele site of wp-admin plat ligt, en dus de fouten die de meeste schrik veroorzaken.
De kritieke fout
De kritieke fout betekent dat WordPress een fatale PHP-fout heeft afgevangen en in plaats daarvan een algemene melding toont. De echte oorzaak staat in de herstelmodus-mail of het foutlog, en daar zie je meestal precies welke plugin of welk thema de fout gooit. In de meeste gevallen die ik tegenkom, gaat het om een plugin- of thema-update, of om een plugin die niet samenwerkt met je PHP-versie. Heb je net een stukje code geplakt, dan zie je vaak een parse error met bestandsnaam en regelnummer. Dat fragment haal je weg via File Manager. Zijn kernbestanden van WordPress beschadigd, dan upload je verse mappen wp-admin en wp-includes, maar overschrijf nooit wp-content, want daar staan je eigen thema, plugins en uploads. Het complete stappenplan staat in ‘Er heeft zich een kritieke fout voorgedaan’ oplossen.
Het witte scherm
Het witte scherm (white screen of death) is een fout zonder melding, waarbij de pagina leeg blijft omdat de foutweergave uitstaat of WordPress verouderd is. Eigenlijk is het familie van de kritieke fout, met dezelfde oorzaken, alleen laat WordPress je nu niets zien. Begin dus ook hier met de debug-modus of het foutlog. De aanpak lees je in white screen of death oplossen.
De databaseverbindingsfout
De databaseverbindingsfout betekent dat WordPress de MySQL-database niet kan bereiken, in het Engels “Error establishing a database connection”. Er zijn drie gebruikelijke oorzaken. De gegevens in wp-config.php kloppen niet meer, vaak na een verhuizing of een gewijzigd wachtwoord. De databaseserver is overbelast of plat. Of er zijn tabellen beschadigd. Hier wil ik eerlijk zijn, want niet elke fout kun je zelf oplossen. Ligt de databaseserver plat, dan is dat het werk van je hostingpartij. Hoe je uitzoekt welke van de drie het is, lees je in de databaseverbindingsfout oplossen.
Vast in onderhoudsmodus
Vast in onderhoudsmodus betekent dat een onderbroken update het bestand .maintenance in de hoofdmap heeft laten staan. Verwijder dat bestand en controleer daarna of de update echt is afgerond. Meer in vast in onderhoudsmodus.
Zie je “Deze site is niet bereikbaar” of DNS_PROBE_FINISHED_NXDOMAIN, dan is er iets anders aan de hand. Dat is geen WordPress-fout, maar een domein dat nog niet goed naar de server wijst, vaak vlak na een verhuizing. Bij Surver is de standaard-TTL, de tijd dat een DNS-antwoord wordt onthouden, 600 seconden. Lees ook wat is DNS.
Serverfouten, statuscodes en redirects
Een statuscode is de antwoordcode die de server bij elk verzoek terugstuurt, en een WordPress error met een code die met een 4 of 5 begint, wijst op een probleem.
- 5xx, het probleem zit aan de serverkant. Statuscode 500 komt vaak door een fout in het .htaccess-bestand, een plugin of verkeerde bestandsrechten. 502 en 504 betekenen dat de server te traag of niet antwoordt, 503 dat hij tijdelijk niet beschikbaar is.
- 4xx, het verzoek wordt geweigerd of de pagina bestaat niet. Statuscode 403 betekent geen toegang, 404 niet gevonden en 429 te veel verzoeken.
- cURL error 28 is geen statuscode, maar een time-out bij verbindingen die WordPress zelf maakt, zoals bij updates. Je ziet hem onder Extra > Sitediagnose. Lees meer over cURL error 28.
Een 403 zie ik vaak na te veel mislukte inlogpogingen of na het aanpassen van bestandsrechten. Normaal staan mappen op 755, bestanden op 644 en wp-config.php strenger, op 440 of 400. Alle shared pakketten van Surver hebben een ModSecurity-firewall met automatische IP-blokkades, dus bij een 403 kan support controleren of jouw IP-adres geblokkeerd is. Geven ineens alle pagina’s een 404, sla dan je permalinks opnieuw op. Als vuistregel ligt 4xx meestal aan jouw kant of je instellingen, en 5xx vaker aan de server of een plugin die de server laat struikelen. Het bredere stappenplan staat in WordPress-website offline.
Te veel redirects en mixed content
Een redirect is een automatische doorverwijzing naar een ander adres, met statuscode 301 voor permanent en 302 of 307 voor tijdelijk. Hoe dat werkt, lees je in wat zijn redirects. Te veel redirects betekent dat adressen eindeloos naar elkaar doorsturen, een redirect-loop. De drie gangbare oorzaken zijn een verkeerde site-URL, dubbele HTTPS-redirects in .htaccess en in een plugin, of een CDN met een afwijkende SSL-instelling. Ook een inlogpagina die steeds terugkomt, is meestal zo’n loop. De oplossing staat in te veel redirects oplossen.
Mixed content betekent dat je pagina via HTTPS laadt, terwijl afbeeldingen of scripts nog via http:// binnenkomen. Je ziet dan geen slotje of een melding dat de verbinding niet volledig beveiligd is. Zet de site-URL en de verwijzingen in de database om naar https://, zoals beschreven in mixed content oplossen.
Limieten van je server: geheugen en uploads
Sommige fouten ontstaan doordat een PHP-limiet op de server wordt bereikt, en dat is een serverinstelling, geen WordPress-instelling. “Allowed memory size exhausted” betekent dat een script meer PHP-geheugen vraagt dan is toegestaan. Bij Surver verhoog je memory_limit zelf via cPanel > Select PHP Version > Options, en ook php_value in .htaccess of WP_MEMORY_LIMIT in wp-config.php werken. Mijn advies is wel om kritisch te blijven. Komt de fout na het verhogen terug, dan zit het probleem in een plugin die te veel vraagt, en verhoog je alleen het plafond. Zie de geheugenlimiet verhogen. Bij “Maximum execution time of 30 seconds exceeded” pas je op dezelfde plek max_execution_time aan.
Voor uploads gelden twee andere waarden, upload_max_filesize en post_max_size, die je ook via Select PHP Version aanpast. Een “HTTP-fout” bij het uploaden van afbeeldingen of statuscode 413 komt vaak door deze limiet, maar soms ook door de rechten van de map uploads of door een plugin die het bestand bewerkt. Lees de maximale uploadgrootte verhogen.
Fout of hack?
Een hack lijkt soms op een gewone fout, maar vraagt een heel andere aanpak. Let op onbekende beheerdersaccounts in WordPress, bezoekers die naar spamsites worden doorgestuurd, vreemde bestanden in de hoofdmap of een waarschuwing van Google of je browser. Zie je een van die signalen, zet dan niet alleen een paar plugins uit en wacht af. Daarmee verberg je hooguit het symptoom, terwijl de indringer gewoon toegang houdt. Volg in dat geval de stappen in WordPress website gehackt, wat nu? en laat het herstel desnoods aan ons over via WordPress gehackt.
Zo voorkom je de meeste WordPress-fouten
De meeste fouten die we zien, zijn het gevolg van een update die direct op de live-site is uitgevoerd. Test updates daarom eerst op een staging-omgeving, een kopie van je site waar een fout geen bezoekers raakt. Bij Surver maak je die door je installatie te klonen in Installatron.
Zorg daarnaast dat er altijd een recente back-up is. Op shared hosting maakt Surver automatisch dagelijkse, wekelijkse en maandelijkse back-ups, maar vóór een grote wijziging maak ik er zelf ook nog een. Houd je PHP-versie actueel met PHP-versie updaten en verwijder plugins die je niet gebruikt, want elke plugin is een extra kans op conflicten. Plak codefragmenten nooit direct in functions.php van je live-site. Eén vergeten puntkomma is genoeg voor een kritieke fout. Wil je updates liever laten testen en uitvoeren, dan valt dat onder WordPress onderhoud.
Hulp vragen: dit stuur je mee
Hoe completer je hulpvraag, hoe sneller de oplossing, omdat support dan niet eerst hoeft terug te vragen wat er aan de hand is. Stuur in elk geval dit mee.
- De exacte melding, het liefst als screenshot.
- De URL waar de fout optreedt.
- Het tijdstip waarop het begon.
- Wat je als laatste hebt gewijzigd.
- De regel uit
debug.logof het foutlog.
Wat we bij Surver standaard doen, is de servers in de gaten houden. Ligt een fout aan de server, bijvoorbeeld een overbelaste databaseserver, dan is dat ons werk, en storingen zie je op status.surver.nl. Op onze managed WordPress hosting heb je zelf ook het gereedschap in handen. In cPanel zet je met JetBackup 5 losse bestanden, databases of mailaccounts terug, wissel je de PHP-versie via Select PHP Version en vind je PHP-fouten in het bestand error_log. Toegangslogs staan onder Raw Access. Kom je er niet uit, dan kijkt support mee, per e-mail op werkdagen en zaterdag, via chat op werkdagen en telefonisch bij spoed op werkdagen. Bij ons beantwoordt altijd een mens je vraag. Zit de fout in een maatwerkthema of eigen code, dan kan onze webmasterservice het oppakken.
Veelgestelde vragen
Hoe vind ik welke plugin een fout veroorzaakt?
Kijk naar het bestandspad in de herstelmodus-mail of het foutlog, want daarin staat de naam van de pluginmap. Staat er geen pad bij, hernoem dan de map plugins zodat alles uitstaat, en zet de plugins daarna één voor één weer aan. Zodra de fout terugkomt, heb je de boosdoener.
Kan ik een WordPress-fout oplossen door een back-up terug te zetten?
Ja, als je weet dat de fout na een bepaald moment is ontstaan. Wijzigingen van daarna gaan wel verloren, en bij een WooCommerce-webshop zijn dat ook orders. Draai daarom eerst de laatste wijziging terug en zie de back-up als laatste redmiddel.
Kan een WordPress-fout mijn vindbaarheid in Google schaden?
Een fout die kort duurt niet. Geven pagina’s langdurig een 5xx- of 404-statuscode, dan kan Google ze lager tonen of uit de index halen. Los de fout dus snel op en controleer daarna in Search Console of alles weer goed wordt opgehaald.
Lost Surver WordPress-fouten voor mij op?
Serverfouten bij managed WordPress hosting pakt Surver op. Fouten in plugins, thema’s of maatwerk vallen onder WordPress onderhoud en beheer of de webmasterservice. Support kijkt altijd mee om te bepalen waar de fout zit.