U heeft net de openingstijden aangepast op de contactpagina. Opslaan, pagina bekijken, en daar staan nog de oude tijden. U probeert het opnieuw. In het beheer klopt alles, op de site niet. Een collega ziet het wel goed, uw telefoon niet. Een klant belt de volgende dag dat u dicht was terwijl de site zei dat u open was.

Dit is een cacheprobleem, en het is een van de meest gestelde vragen die wij krijgen. De oplossing is bijna altijd de WordPress cache legen, maar “de cache” bestaat niet: er zijn minstens vijf plekken waar een oude versie van uw pagina bewaard kan worden. In dit artikel leggen we uit welke dat zijn, in welke volgorde u ze leegt en hoe u voorkomt dat u elke wijziging drie keer moet controleren.

Waarom een cache oude versies toont

Zonder cache moet WordPress bij elk bezoek de pagina opnieuw opbouwen: database raadplegen, thema uitvoeren, plugins laten meedoen. Dat kost tijd. Een cache bewaart daarom een kant-en-klare kopie en serveert die aan de volgende bezoeker. Dat maakt de site snel, maar het betekent ook dat een wijziging pas zichtbaar wordt als die kopie wordt vernieuwd. Goede cacheplugins doen dat automatisch bij het opslaan van een pagina. Maar niet elke laag krijgt dat seintje, en niet elke wijziging telt als “pagina opslaan”.

De vijf lagen waar u de WordPress cache legen moet

1. Uw eigen browser

De browser bewaart afbeeldingen, stijlbestanden en soms hele pagina’s. Dit is de laag die het vaakst voor verwarring zorgt, en de makkelijkste om uit te sluiten: open de pagina in een privévenster. Ziet u daar de nieuwe versie wel, dan zat het in uw browser en is er op de site niets mis. Een geforceerde herlaadactie (Ctrl+F5 op Windows, Cmd+Shift+R op Mac) helpt ook.

2. De cacheplugin in WordPress

WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache, WP Fastest Cache: ze hebben allemaal een knop “cache legen” of “cache wissen” in de bovenste balk van het beheer of in hun eigen instellingenpagina. Bij het opslaan van een bericht legen ze meestal alleen de cache van dat bericht en de homepage. Een wijziging in een widget, het menu, de footer of een thema-instelling wordt vaak niet opgemerkt. Leeg dan handmatig de volledige cache.

3. De servercache van uw hostingpartij

Veel hostingpartijen draaien hun eigen cache op de server, buiten WordPress om: Varnish, Nginx FastCGI-cache, LiteSpeed op serverniveau of een eigen oplossing. Die is vaak onzichtbaar, maar wel aanwezig. U leegt hem in het controlepaneel van de host, en sommige hosts leveren een plugin die er een knop voor in WordPress zet. Ziet u wijzigingen niet terwijl de cacheplugin leeg is, dan is dit de volgende plek.

4. Objectcache en gecompileerde bestanden

Redis of Memcached bewaren databaseresultaten. Meestal merkt u daar niets van, maar bij gewijzigde instellingen of menu’s kan een oude waarde blijven hangen. De knop hiervoor zit in de plugin die de objectcache beheert. Daarnaast bewaren paginabouwers als Elementor en Divi hun eigen gegenereerde CSS-bestanden; Elementor heeft daarvoor de optie “CSS en gegevens regenereren” onder Gereedschap, Divi heeft een vergelijkbare knop onder Prestaties.

5. CDN of Cloudflare

Als uw site via Cloudflare of een ander CDN loopt, bewaart dat netwerk kopieën van bestanden op servers over de hele wereld. Standaard cachet Cloudflare alleen afbeeldingen, scripts en stijlbestanden, maar met de functie “Cache Everything” of APO ook hele pagina’s. Legen doet u in het Cloudflare-dashboard onder Caching, Purge Everything, of gerichter per URL.

De volgorde die het minste tijd kost

  1. Privévenster. Nieuwe versie zichtbaar? Klaar, het was uw browser.
  2. Cacheplugin volledig legen. Controleer opnieuw in een privévenster.
  3. Servercache legen in het hostingpaneel.
  4. CDN legen als u er een gebruikt.
  5. Paginabouwer-CSS regenereren als het om een opmaakwijziging gaat die niet doorkomt.
  6. Objectcache legen als het om instellingen, menu’s of widgets gaat.

Controleer na elke stap in een privévenster, niet in het tabblad waar u de wijziging maakte. Ingelogde gebruikers krijgen namelijk meestal een ongecachete versie te zien, wat verklaart waarom u het zelf wel goed ziet en een klant niet.

Wanneer het geen cache is

Soms is het toch iets anders. De meest voorkomende verwarringen:

  • U bewerkte de verkeerde pagina. Een gekopieerde pagina, een conceptversie, of een pagina in de andere taal bij meertalige sites.
  • Het thema toont iets anders dan de pagina-inhoud. Openingstijden in de footer komen vaak uit een thema-instelling of widget, niet uit de pagina.
  • Een paginabouwer heeft een eigen opslag. Bij Elementor moet u in de bouwer zelf op “Bijwerken” klikken; opslaan in de gewone editor overschrijft die versie niet.
  • DNS wijst nog naar een oude server, bijvoorbeeld kort na een verhuizing. Dan bewerkt u de nieuwe site en kijkt u naar de oude.
  • Een revisie is niet gepubliceerd. Sommige plugins voor werkstromen bewaren wijzigingen als concept tot iemand ze goedkeurt.

Praktijkvoorbeeld: een bakkerij in Leiden

Een bakkerij in Leiden veranderde de openingstijden voor de zomervakantie. De eigenaar paste de contactpagina aan, leegde de cacheplugin en zag het goed. Toch belden klanten een week lang dat de site nog de oude tijden toonde. Bij onderzoek bleek de site achter Cloudflare te staan met “Cache Everything” ingeschakeld door een vorige beheerder, met een bewaartermijn van een maand. De cacheplugin wist daar niets van en gaf geen seintje door.

Na het legen van de Cloudflare-cache was het direct opgelost. Om het niet elke keer handmatig te hoeven doen, hebben wij de koppeling tussen de cacheplugin en Cloudflare ingesteld, zodat het opslaan van een pagina beide caches leegt. De bakker ziet zijn wijzigingen nu binnen een minuut, ook op de telefoon van zijn klanten. Dit soort verborgen lagen zijn een van de redenen waarom een site na een optimalisatie soms “raar” gaat doen; meer daarover in het artikel over gestapelde optimalisatieplugins.

Voorkomen dat u dit elke keer moet doen

Zorg dat de lagen met elkaar praten. De meeste cacheplugins hebben een koppeling met Cloudflare en met de servercache van bekende hosts; zet die aan. Kies één cacheplugin en zet geen tweede erbij. Laat wijzigingen aan menu’s, widgets en thema-instellingen altijd volgen door een volledige leging. En documenteer welke lagen uw site heeft, zodat een collega niet hoeft te raden. Wie dit liever niet zelf uitzoekt, kan een cacheprobleem dat blijft terugkomen laten onderzoeken en oplossen; het is een kleine ingreep die veel herhaald werk scheelt.

Blijft een wijziging na alle vijf de lagen onzichtbaar, dan is het geen cache. Kijk dan naar de lijst met verwarringen hierboven, en controleer vooral of u de goede pagina en de goede server bewerkt.