“Er is een kritieke fout opgetreden.” Dat is alles wat WordPress je geeft, terwijl je site plat ligt en er net een klant belde. Op zo’n moment is de verleiding groot om willekeurig dingen uit te zetten tot het werkt.
Doe dat niet. Foutopsporing is geen kwestie van geluk, het is een vaste route. Wie die route kent, vindt de oorzaak vaak binnen een kwartier. De webknecht loopt hem met je door, inclusief hoe je een AI hier zinnig bij inzet in plaats van als gokmachine.
Stap 0: verander nog even niets
De eerste reflex is de gevaarlijkste. Voordat je iets aanpast, wil je twee dingen weten:
- Heb je een werkende backup, en van wanneer? Zonder dat antwoord is elke ingreep een gok met je site als inzet.
- Wat is er als laatste veranderd? Een update, een nieuwe plugin, een tekstwijziging, een DNS-aanpassing. In negen van de tien gevallen zit je oorzaak in het antwoord op deze vraag.
Dat tweede punt klinkt simpel en wordt structureel overgeslagen. “Er is niets veranderd” betekent bijna altijd: er is automatisch iets bijgewerkt.
De vier vragen die de helft van je werk doen
Voordat je in logs duikt, baken je het probleem af:
- Wat precies is stuk? De hele site, één pagina, alleen de beheerkant, of alleen het formulier?
- Voor wie? Voor iedereen, of alleen voor jou? Als het alleen bij jou stuk is, kijk dan naar je browsercache, je inlogsessie of je eigen netwerk.
- Sinds wanneer? Koppel dat aan je updategeschiedenis.
- Is het constant of wisselend? Wisselende fouten wijzen richting geheugen, load of een externe koppeling die soms traag antwoordt.
Die laatste is belangrijk: fouten die komen en gaan zijn zelden code-fouten. Dat is vaak capaciteit. Een site die af en toe een 503 geeft, heeft regelmatig een bot die je server opvreet.
Zet het licht aan
Een witte pagina is geen informatie. Een logregel is informatie. Zet dus eerst de foutrapportage aan met WP_DEBUG, en log naar een bestand in plaats van naar het scherm van je bezoekers. Hoe dat precies werkt staat in WP_DEBUG inschakelen en uitlezen.
Je hebt dan meestal drie logs waar je kunt kijken: het WordPress-debuglog, het PHP-errorlog van je hosting en het accesslog van je webserver. Die eerste vertelt je welk bestand klaagt, de tweede waarom PHP stopte, de derde of er iets vreemds aan verkeer voorbijkwam.
Welk foutbeeld hoort bij welke oorzaak
Foutmeldingen zijn geen willekeur. Elke melding wijst naar een hoek van je installatie:
| Wat je ziet | Waar het bijna altijd zit |
|---|---|
| 500 Internal Server Error | PHP-fout in een plugin of thema, of een kapotte .htaccess |
| 403 Forbidden | Rechten, .htaccess-regels of een securityfilter |
| Error establishing a database connection | Inloggegevens, databaseserver plat, of te veel verbindingen |
| Er is een kritieke fout opgetreden | Eén plugin of thema, meestal net bijgewerkt |
| 503 of time-outs, wisselend | Capaciteit: bots, zware queries, te weinig geheugen |
| Alleen de beheerkant stuk | Plugin die in de admin hookt, of een geheugenlimiet |
De bisect: halveren tot je hem hebt
Wijst alles naar een plugin, dan ga je niet één voor één uitzetten. Je halveert. Zet de helft uit: is het over, dan zit hij in die helft. Zet daar weer de helft van uit. Bij 32 plugins ben je zo in vijf stappen klaar in plaats van 32.
Werkt de site daarna weer, wissel dan tijdelijk naar een standaardthema. Blijft het dan goed, dan zat het in je thema. Dit is stug werk, en precies daarom is het werk om uit te besteden.
Zo laat je Claude het uitzoeken
Hier zit het verschil tussen een AI die je helpt en een AI die gokt: informatie. Een vraag als “mijn site is stuk, fix het” levert een lijst algemene tips op. De context erbij en het wordt een onderzoek.
| Zwakke opdracht | Sterke opdracht |
|---|---|
| “Mijn site werkt niet, los het op” | “Sinds de updates van vannacht geeft /contact een 500. Lees het debuglog en het PHP-errorlog, zoek de oorzaak en leg uit wat je vindt voordat je iets wijzigt.” |
| “Zet plugins uit tot het werkt” | “Maak eerst een momentopname. Zoek via halveren welke plugin de kritieke fout geeft, zet de rest daarna terug aan en meld welke het was.” |
| “Maak mijn site sneller” | “Zoek uit waarom de homepage traag is: meet laadtijd, check cache, PHP-versie, plugins, afbeeldingsformaten en bottraffic. Zet de bevindingen op prioriteit.” |
Let op de zinsnede “leg uit wat je vindt voordat je iets wijzigt”. Dat is de belangrijkste veiligheidsrem die je in een opdracht kunt inbouwen, want een diagnose kun je nalezen, een reeks blinde wijzigingen niet. Zet in DirectAdmin de goedkeuring daarbij op elke wijziging, zoals beschreven bij Invoker Link.
Verifieer, anders heb je de fout niet opgelost
“Het werkt weer” is geen conclusie zolang je niet weet waarom. Sluit daarom altijd af met drie dingen: test de pagina die stuk was, test de homepage en de inlogpagina, en leg vast wat de oorzaak was.
Dat laatste is geen bureaucratie. Dezelfde fout komt terug, en dan wil je niet opnieuw een kwartier zoeken. Een regel in een tekstbestand met datum, symptoom en oorzaak is genoeg.
En vind je een oorzaak die je niet kunt verklaren, bijvoorbeeld een bestand dat je niet herkent? Ga dan niet verder met repareren. Dan is dit geen storing maar mogelijk een inbraak, en dat is een ander draaiboek.