Kort svar: Vises gammelt indhold, selvom du har opdateret siden, så tjek først hvilket lag der holder på det: CF-Cache-Status-headeren afslører, om Cloudflare serverer et HIT. Purge derefter målrettet – “Purge by URL” for de ændrede sider frem for “Purge Everything” – og sæt automatisk purge op via et Cloudflare-integreret plugin, så opdateringer fremover rydder sig selv. Husk: purge hjælper ikke, hvis det i virkeligheden er dit cache-plugin eller browserens cache, der viser det gamle.
“Jeg har rettet siden, men den gamle version vises stadig” er en lagkage-fejl: indholdet kan sidde fast i cache-pluginnet, i Cloudflare eller i browseren – og at purge det forkerte lag føles som at purge forgæves. Denne guide gør rydningen målrettet: find laget, purge præcist, og automatisér det, så problemet ikke vender tilbage.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt – det er ikke data fra hostious.io.
Hent siden med friske øjne (inkognito), og læs response-headerne i browserens Netværk-fane eller med curl:
Læsningen: cf-cache-status: HIT med høj age = Cloudflare holder på en gammel udgave – purge dér. DYNAMIC/BYPASS/MISS = Cloudflare cacher ikke HTML’en; så er det cache-pluginnet på serveren eller browseren, der viser det gamle. Alle statusværdierne er forklaret i CF-Cache-Status-guiden. Og bemærk: som standard cacher Cloudflare slet ikke HTML – kun statiske filer som CSS, JS og billeder. Ser du gamle stylesheets eller billeder, er det netop dem, der skal purges.
Håndpurge er en overgangsløsning. Det holdbare setup lader WordPress selv purge Cloudflare, når indhold ændres: Cloudflares officielle plugin gør det med en API-token, og flere cache-plugins har indbygget Cloudflare-integration, så server-cache og CDN ryddes i samme greb ved opdatering af indlæg og sider. Opret en API-token med rettigheden “Zone → Cache Purge” (frem for den globale API-nøgle), indsæt den i pluginnet – og test med en synlig rettelse på en testside.
Skal du arbejde koncentreret på design eller CSS, så slå Development Mode til (Caching → Configuration): Cloudflare sender så alle requests udenom sin cache i tre timer og slår automatisk fra igen. Det fjerner behovet for at purge efter hver lille rettelse – uden at du kan glemme tilstanden tændt. Server-cachen gælder stadig, så kombiner med cache-pluginnets udviklingsindstilling, hvis ændringerne heller ikke slår igennem dér.
Flowet virker, når en testrettelse på en side er synlig i inkognito inden for få sekunder efter udgivelse – uden manuel purge; når cf-cache-status på den ændrede URL viser MISS/EXPIRED ved første besøg efter ændringen og HIT derefter; og når statiske filer får ny cache efter deploys (versionerede filnavne klarer det af sig selv). Ser kunder stadig gammelt indhold efter alt dette, er det typisk deres browsercache – og den forsvinder af sig selv, når filens cache-levetid udløber.
Så kom det gamle indhold fra et andet lag: server-cachen (ryd cache-pluginnet først) eller din browser (test i inkognito). Purge Everything rydder kun Cloudflares kopi.
Nej – det påvirker kun cache, ikke indeksering. Konsekvensen er alene, at de første besøg efter purgen er langsommere, indtil cachen er varm igen. Hyppige totalpurges på travle sites er derfor et hastighedsspørgsmål, ikke et SEO-spørgsmål.
Helst aldrig – automatisk purge ved indholdsændringer bør dække hverdagen. Manuel purge er til undtagelser: deploys, designændringer og fejlsituationer.
