Als een website oude content toont, hoor ik vaak dezelfde oplossing: “Leeg de cache even.” Soms is dat inderdaad genoeg. Maar als ik meteen alle caches tegelijk leegmaak, weet ik daarna nog steeds niet waar het probleem zat.
Een moderne WordPress-website heeft meestal niet één cache, maar meerdere lagen. De browser kan oude bestanden vasthouden, een optimalisatieplugin kan een opgeslagen versie van een pagina tonen en de server kan HTML via FastCGI bewaren. Bij websites met een pagebuilder kunnen daarnaast gegenereerde CSS-bestanden achterlopen. Wat aan de voorkant één simpel probleem lijkt, kan dus op verschillende plekken ontstaan.
Oude content is niet automatisch een cacheprobleem
Mijn eerste stap is daarom niet wissen, maar vergelijken. Staat de wijziging werkelijk goed in WordPress? Zie ik hetzelfde probleem in een privévenster? Wordt de juiste pagina geopend? En gaat het om oude tekst, een ontbrekende afbeelding of alleen om verouderde vormgeving?
Dat onderscheid is belangrijk. Oude tekst wijst eerder op opgeslagen HTML. Een pagina die inhoudelijk klopt maar er verkeerd uitziet, heeft vaker een probleem met CSS of andere bestanden. Een afbeelding die niet verandert, kan nog uit de browsercache of via een optimalisatielaag komen. Door eerst vast te stellen wat er precies oud is, verklein ik het zoekgebied.
De publieke pagina is mijn uitgangspunt
Ik controleer de website altijd zoals een gewone bezoeker hem ziet: zonder ingelogde WordPress-sessie. Beheerders krijgen soms een andere, ongecachete versie van een pagina. Daardoor kan alles in het dashboard en zelfs aan de voorkant correct lijken, terwijl bezoekers nog een oude versie ontvangen.
Een publieke controle geeft mij een zuiverder beeld. Ik let op de HTTP-status, de zichtbare inhoud, de geladen assets en de exacte URL. Bij een wijziging controleer ik bovendien niet alleen de homepage, maar juist het pad waar de aanpassing is gedaan.
Elke cachelaag heeft een ander doel
De browser bewaart bestanden om vervolgbezoeken sneller te maken. WordPress-cacheplugins slaan pagina’s of onderdelen daarvan op. FastCGI-cache voorkomt dat PHP en WordPress voor ieder bezoek opnieuw de hele pagina hoeven op te bouwen. Een pagebuilder kan zijn eigen gegenereerde CSS bewaren. Al deze lagen verbeteren de snelheid, maar ze reageren niet altijd tegelijk op een wijziging.
Daarom behandel ik ze ook niet als één grote knop. Ik begin zo dicht mogelijk bij het symptoom. Gaat het alleen om styling, dan controleer of regenereer ik eerst de gegenereerde CSS. Gaat het om de volledige pagina-inhoud, dan kijk ik naar de WordPress-cache. Pas als de server nog aantoonbaar oude HTML levert, komt de FastCGI-laag in beeld.
Waarom alles tegelijk leegmaken weinig leert
Wanneer je browsercache, WordPress-cache en servercache in één keer leegt, is de kans groot dat de pagina daarna klopt. Maar de oorzaak is verdwenen zonder dat je hem hebt gevonden. Bij een volgend incident begin je opnieuw.
Dat is vooral lastig bij terugkerende problemen. Misschien ververst een plugin zijn cache niet na een bepaalde publicatieactie. Misschien wordt CSS niet opnieuw opgebouwd. Misschien valt één URL buiten de verwachte regels. Als je altijd alles wist, blijven zulke patronen onzichtbaar.
Breed caches legen heeft ook een praktisch nadeel: de eerste bezoekers moeten de pagina’s opnieuw laten opbouwen. Op een drukke of zware website kan dat tijdelijk extra belasting en tragere reacties veroorzaken. Meestal is gericht ingrijpen veiliger en informatiever.
Mijn vaste volgorde
Ik werk daarom van klein naar groot:
- Controleren of de wijziging correct in WordPress staat.
- De exacte publieke URL zonder ingelogde sessie bekijken.
- Bepalen of het probleem in inhoud, styling of een los bestand zit.
- Alleen de meest waarschijnlijke laag verversen.
- De publieke pagina opnieuw controleren.
- Pas daarna doorgaan naar een bredere cachelaag.
Na iedere stap verifieer ik opnieuw. Niet alleen of de pagina opent, maar ook of precies de bedoelde wijziging zichtbaar is. Zo wordt cachebeheer onderdeel van diagnose in plaats van een reflex.
Caching is zelden het echte probleem
Een cache doet meestal wat hij moet doen: een eerder resultaat snel opnieuw leveren. Het probleem ontstaat wanneer de applicatie niet duidelijk doorgeeft dat dat resultaat verouderd is, of wanneer verschillende lagen niet goed op elkaar aansluiten.
Daarom zie ik “de cache” liever niet als oorzaak, maar als aanwijzing. Welke laag had moeten verversen? Welke gebeurtenis had dat moeten activeren? En hoe kunnen we voorkomen dat dezelfde situatie terugkomt?
Die manier van werken kost bij het eerste onderzoek soms een paar minuten extra. Op de langere termijn levert het juist tijd op. Je bouwt kennis op over de website, voorkomt onnodige acties en kunt terugkerende fouten structureel oplossen.
Dus ja: soms moet de cache gewoon leeg. Maar ik wil eerst weten welke cache, waarom die oude informatie toont en hoe ik daarna objectief vaststel dat het probleem echt is opgelost.