Cloudflare-cachen ryddes ikke – purge rigtigt

Kort svar: Vises gammelt indhold, selvom du har opdateret siden, så find først hvilket lag der holder på det: headeren cf-cache-status afslører, om Cloudflare serverer et HIT. Ryd derefter server-cachen før Cloudflare, og purge målrettet med Purge by URL i stedet for Purge Everything. Sæt til sidst automatisk purge op via et plugin med Cloudflare-integration, så opdateringer rydder sig selv. Purge hjælper ikke, hvis det i virkeligheden er cache-pluginnet eller browseren, der viser det gamle.

Fagligt gennemgået: 2. oktober 2026

„Jeg har rettet siden, men den gamle version vises stadig“ er en lagkage-fejl. Indholdet kan sidde fast i cache-pluginnet på serveren, i Cloudflares kantservere eller i browseren – og purger du det forkerte lag, føles det, som om purgen ikke virker.

Denne guide gør rydningen målrettet: find laget, purge præcist, automatisér det, og verificér bagefter, så problemet ikke vender tilbage.

Før du ændrer noget: Notér den præcise URL, der viser gammelt indhold (med eller uden www, med eller uden skråstreg til sidst), og hvornår du ændrede siden. Brug et inkognitovindue til alle test, så din egen browsercache og dit login ikke snyder dig. Purge Everything er ufarlig for data, men gør sitet langsommere, indtil cachen er bygget op igen.

1. Find laget, der holder på det gamle

Hent siden i et inkognitovindue, og læs response-headerne i browserens Netværk-fane (vælg selve dokument-requesten) eller med curl:

curl -sI https://ditdomæne.dk/den-aendrede-side/ | grep -iE "cf-cache-status|age|cache-control|x-litespeed-cache"

Sådan læser du svaret:

• cf-cache-status: HIT med en høj age: Cloudflare holder på en gammel udgave. Purge i Cloudflare.
• DYNAMIC, BYPASS eller MISS: Cloudflare leverede ikke HTML’en fra sin cache. Det gamle indhold kommer så fra server-cachen eller browseren. Alle statusværdierne er forklaret i guiden til CF-Cache-Status.
• x-litespeed-cache: hit (eller tilsvarende header fra dit cache-plugin): serverens page cache leverede siden. Ryd den først.
• Kun gamle stylesheets eller billeder: som standard cacher Cloudflare statiske filer som CSS, JavaScript og billeder, men ikke HTML. Ser siden rigtig ud i HTML’en, men forkert i layoutet, er det typisk de statiske filer, der skal purges.

Headerne gør det til en diagnose i stedet for et gæt. Det tager et minut og sparer dig for at purge tre lag i blinde.

2. Purge målrettet – i den rigtige rækkefølge

Cloudflare tilbyder flere purge-metoder. Siden april 2025 er alle metoderne – enkelt-URL, hostname, cache-tag og præfiks – tilgængelige på alle planer, også den gratis. Du finder dem under Caching-sektionen i dashboardet (Purge Cache / Custom Purge); menunavnene flytter sig af og til, så søg efter „Purge“, hvis du ikke kan finde dem.

• Purge by URL: indsæt de konkrete URL’er – siden, der er ændret, og eventuelt den ændrede CSS- eller JS-fil. Cachen for alt andet bevares, så sitet forbliver hurtigt.
• Purge by prefix eller hostname: praktisk, når en hel sektion (fx /blog/) eller et subdomæne skal ryddes, uden at resten af zonen rammes.
• Purge Everything: nødknappen ved store ændringer som nyt design eller nyt tema. Regn med et kortvarigt fald i hastighed, mens cachen genopbygges – på travle sites helst uden for spidsbelastning.

Rækkefølgen er afgørende: ryd først cache-pluginnet på serveren og derefter Cloudflare. Purger du Cloudflare først, kan kantserveren nå at hente den gamle udgave fra server-cachen igen – og så ligner purgen en fuser, selvom den faktisk virkede.

URL-varianter og cache-nøgler

Cloudflare gemmer hver kopi under en cache-nøgle, der bl.a. består af skema, hostname, sti og query string. https://ditdomæne.dk/side/ og https://www.ditdomæne.dk/side/ er derfor to forskellige objekter, og det samme gælder /side/?utm_source=nyhedsbrev. Purger du kun den ene variant, kan den anden stadig vise gammelt indhold.

Ser du gammelt indhold på trods af en purge by URL, så kopiér URL’en direkte fra browserens adresselinje i den test, der fejler, og purge præcis den. Har du både www og uden www i brug, er det samtidig et tegn på, at sitet mangler en fast www-redirect.

3. Automatisér purge ved opdateringer

Håndpurge er en overgangsløsning. Det holdbare setup lader WordPress selv purge Cloudflare, når indhold ændres. Cloudflares officielle WordPress-plugin kan det, og flere cache-plugins har indbygget Cloudflare-integration, så server-cache og CDN ryddes i samme greb, når du opdaterer et indlæg eller en side.

1. Opret en API-token i Cloudflare med rettigheden „Zone → Cache Purge → Purge“, afgrænset til den ene zone. Brug ikke den globale API-nøgle – den giver adgang til hele kontoen.
2. Indsæt tokenet i pluginnet, og slå automatisk purge ved indholdsændringer til.
3. Lav en synlig rettelse på en testside, og tjek i inkognito, at den slår igennem uden manuel purge.
4. Notér i jeres driftsdokumentation, hvilket plugin der purger Cloudflare – to plugins, der begge forsøger, giver dobbeltarbejde og svær fejlfinding.

Purge fra kommandolinjen eller et deploy-script

Udrulles der tema- eller kodeændringer via et script, kan purgen lægges ind som sidste trin. Cloudflares API tager en liste over URL’er:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://ditdomæne.dk/","https://ditdomæne.dk/wp-content/themes/ditema/style.css"]}'

Gem tokenet som miljøvariabel eller i et hemmelighedslager, aldrig i selve scriptet eller i et Git-repository. Svaret indeholder "success": true, når purgen er modtaget.

4. Development Mode til arbejdssessioner

Skal du arbejde koncentreret med design eller CSS, så slå Development Mode til i Caching-indstillingerne. Cloudflare sender så alle requests uden om sin cache i tre timer og slår automatisk fra igen. Det fjerner behovet for at purge efter hver lille rettelse – uden at du risikerer at glemme tilstanden tændt.

Server-cachen gælder stadig, så kombinér med cache-pluginnets egen udviklings- eller debugindstilling, hvis ændringerne heller ikke slår igennem dér. Husk også, at Development Mode ikke rydder noget: når de tre timer er gået, serverer Cloudflare igen de kopier, der lå i cachen, medmindre du purger.

Når HTML også caches i Cloudflare

Har du sat en Cache Rule op, der cacher HTML („Cache Everything“-princippet), eller bruger du Cloudflare APO, gælder purge også for selve siderne – ikke kun for statiske filer. Så bliver automatisk purge ved opdateringer obligatorisk, og du skal sikre, at kurv, checkout, Min konto og wp-admin altid er undtaget. Fremgangsmåden står i guiden til Cache Rules for WooCommerce og i artiklen om Cloudflare APO.

Uden HTML-cache i Cloudflare er det næsten altid server-cachen, der viser gammelt sideindhold, mens Cloudflare kun kan stå bag gamle CSS-, JS- og billedfiler. Den skelnen alene halverer fejlsøgningen.

Browsercachen – det sidste lag

Selv efter en korrekt purge kan en besøgende se den gamle udgave, fordi browseren har gemt filen lokalt. Hvor længe afhænger af Cache-Control-headeren og Cloudflares indstilling for Browser Cache TTL. Du kan ikke purge en besøgendes browser – men du kan undgå problemet:

• Brug versionerede filnavne eller versionsparametre på CSS og JavaScript (fx style.css?ver=2.4.1). WordPress og de fleste temaer gør det automatisk, når versionsnummeret ændres.
• Sæt lange cache-levetider på statiske filer, men ikke på HTML.
• Erstattes et billede med en ny fil under samme navn, så upload det hellere under et nyt filnavn.

Verifikation

Flowet virker, når alle punkterne her holder:

• En testrettelse er synlig i inkognito inden for få sekunder efter udgivelse – uden manuel purge.
• cf-cache-status på den ændrede URL viser MISS eller EXPIRED ved første besøg efter ændringen og HIT derefter (for filer og eventuel HTML, som Cloudflare cacher).
• Statiske filer får ny version efter deploys, fordi filnavnet eller versionsparameteren ændres.
• Både www- og ikke-www-varianten (eller redirecten mellem dem) giver den nye udgave.

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.

Læs også

• Hub: Cloudflare-guides til WordPress
• Hvorfor viser CF-Cache-Status DYNAMIC, BYPASS eller MISS?
• LiteSpeed viser gammelt indhold efter en opdatering
• Page cache, object cache og browser cache: hvem gør hvad?
• Cloudflare-indstillinger til WordPress: sikker basisopsætning
• WordPress hosting hos Hostious – LiteSpeed og NVMe, så server-cachen er hurtig at bygge op igen

Ofte stillede spørgsmål om Cloudflare-purge

Hvorfor viser siden stadig gammelt indhold efter Purge Everything?

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.

Skader Purge Everything mit SEO?

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.

Hvor ofte bør jeg purge manuelt?

Helst aldrig – automatisk purge ved indholdsændringer bør dække hverdagen. Manuel purge er til undtagelser: deploys, designændringer og fejlsituationer.

Hvorfor virker Purge by URL ikke på min side?

Typisk fordi du har purget en anden variant end den, der vises – fx uden www, uden afsluttende skråstreg eller uden query string. Cloudflare gemmer hver variant for sig, så kopiér den præcise URL fra den test, der fejler, og purge den.

Hvad er forskellen på purge og Development Mode?

En purge sletter de cachede kopier én gang, hvorefter cachen bygges op igen. Development Mode lader requests gå uden om Cloudflares cache i tre timer uden at slette noget, så det er beregnet til arbejdssessioner med mange små rettelser.