Kort svar: Tilføj en unik, ufølsom testmarkør på staging, og sammenlign indlogget preview, anonym browser, en cache-bypasset request og den normale URL. Gem
X-LiteSpeed-Cache,X-QC-Cache,Age,Cache-Controlog eventuelle proxyheaders. Purge først den konkrete URL eller cachetag. Hvis det ikke virker, ligger den gamle kopi i et andet lag eller purge-eventet mangler. Kortere TTL eller gentagen Purge All skjuler kun årsagen.
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, LiteSpeed Cache 7.9, PHP 8.4.23 og Chrome 151 på isoleret staging. QUIC.cloud-integration og quota er ikke aktiveret eller verificeret; edge- og CDN-trin skal derfor efterprøves i dit eget miljø.
Stale content kan komme fra browserens HTML-cache, LiteSpeed page cache, QUIC.cloud/andet CDN, service worker, object cache eller selve databasen/templatebyggeren. Hvert lag har forskelligt bevis. Find laget, før du tømmer alt.
På denne side
Brug staging eller et ufarligt tekstfelt. Tilføj fx en intern testmarkør med dato/tid, gem, og notér post-ID. Brug ikke et kundenavn, en rabatkode eller andre forretningsdata. Kontrollér først i editor/preview, at databasen faktisk indeholder den nye værdi.
| Symptom/fund | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Hard reload viser nyt, normal reload gammelt | Browsercache/service worker | Cache-Control og DevTools Disable cache | Ret HTML-/service-worker-strategien |
| Bypass viser nyt, normal LiteSpeed hit gammelt | LiteSpeed page cache er stale | Markør og targeted purge-log | Purge URL/tag og find manglende event |
| Origin viser nyt, edge viser gammelt | CDN/proxy er stale | Age og QC-/CDN-header | Purge det konkrete edgeobjekt og ret integrationen |
| Alle anonyme svar gamle, editor nyt | Builder/render/template-cache | HTML source og generated assets | Ret den konkrete builder-/rendercache |
| HTML nyt, komponent gammel | ESI/shortcode/object cache/API | DOM, AJAX og komponentdata | Purge eller versionér komponentens egen cache |
| Purge virker kort, problemet vender tilbage | Forkert cachekey eller re-generering | Vary, crawler og updater-event | Pause ejeren på staging og ret dens input |
Åbn DevTools → Network → Disable cache og genindlæs. Kontroller, om requesten faktisk når serveren. Hvis X-LiteSpeed-Cache slet ikke findes på det gamle svar, kan browseren levere HTML uden ny request. Serverregler må ikke sætte lang browser-Expires på HTML; langtidsbrowsercache er normalt til versionsbestemte statiske filer.
Test også en ny privat browser. En hard reload er en diagnose, ikke en løsning for alle besøgende.
Brug LiteSpeed Toolbox → Purge By URL eller den relevante post/tag-funktion. Genindlæs anonymt. Det første svar skal være miss med den nye markør; det næste hit med samme indhold.
Purge All LSCache kan bruges, når en bred relation faktisk er ændret, men er ikke første trin. “Empty Entire Cache” kan berøre andre webapplikationer og er sidste udvej.
LiteSpeed tagger posts og relaterede arkiver og purger normalt ved WordPress-events som save/edit/delete. Hvis en tredjepartsintegration opdaterer data direkte, kan WordPress-hooket mangle. Reproducer med debuglog og se, om post/tag-purge blev udløst ved gemning.
Udvikleren skal derefter kalde LiteSpeeds purge-/tagintegration på det rigtige event. Tilføj ikke en global Purge All ved hvert besøg eller croninterval; det fjerner cachegevinsten og kan skabe belastning.
Start ved kilden, før cachelagene mistænkes. Åbn den gemte post eller indstilling i WordPress, og kontroller post-ID, revisionsdato og det felt, som templaten faktisk læser. Pagebuildere, oversættelser og WooCommerce kan have flere felter eller sprogversioner, der ligner hinanden. Hvis preview også viser den gamle værdi, er problemet ikke den offentlige page cache.
Kontroller derefter offentlig HTML-kilde, ikke kun det visuelle DOM-resultat. Hvis den nye tekst findes i HTML, men browseren viser noget andet, kan CSS, JavaScript eller en efterfølgende API-request overskrive den. Hvis HTML er gammel på origin, ligger ejeren i WordPress-rendering, template-/fragmentcache eller objektcache. Hvis origin er ny og edge er gammel, er CDN-laget bekræftet. Denne rækkefølge forhindrer, at en database- eller builderfejl “løses” med gentagne cachepurges.
Progressive web-app-plugins og visse temaer kan registrere en service worker, som svarer før netværket. I DevTools → Application kontrolleres, om en service worker styrer siden, og Network viser, om svaret kommer “from ServiceWorker”. Afregistrer den kun i den isolerede testbrowser, genindlæs og sammenlign. Det ændrer ikke andre besøgendes tilstand og er derfor et sikkert diagnosepunkt.
Hvis service workeren er ejeren, skal dens versions- og opdateringsstrategi rettes. En serverpurge kan ikke slette HTML, som allerede ligger i en besøgendes offline-cache. Publicer ikke en løsning, der beder alle brugere rydde hele browseren; det flytter ansvaret til brugeren og løser ikke næste udgivelse.
Sammenlign den normale edge-URL med en godkendt origin-test. X-QC-Pop, X-QC-Cache, Age eller anden CDN-header viser, hvilket lag der svarede. Purge origin opdaterer ikke nødvendigvis edge, og edge purge opdaterer ikke en gammel browserkopi.
Hvis to CDN-/page-cachelag er aktive, dokumenteres purge-rækkefølgen. Fjerne cachelag skal ikke slås fra permanent uden at kontrollere sikkerhed og DNS.
En crawler kan genopbygge cache hurtigt, men den bør hente den nye originversion. Hvis den rammer en gammel intern route, forkert server-IP eller et andet cachelag, kan gammel HTML blive lagt tilbage. Pause crawleren på staging, purge målrettet, og test markøren før den aktiveres igen.
Shortcodes, ESI, pagebuilder-CSS, produktfiltre og eksterne API-widgets kan have egen cache. Se sidekilden: er markøren gammel i HTML, eller bliver den gamle komponent hentet bagefter via AJAX? Hvis kun komponenten er gammel, skal dens ejer purge eller have en passende kort TTL.
Gem en tydelig ejeroversigt for hver komponentcache: hvor data ændres, hvilket event der gør cachen ugyldig, og hvordan en enkelt post kan purges. Test med to forskellige poster, så en rettelse ikke kun virker for én hardcodet ID. En kort TTL kan begrænse varigheden af en fejl, men erstatter ikke et korrekt purge-event, når en pris, lagerstatus eller anden vigtig oplysning skal slå igennem straks.
En redaktør opdaterer titel og billede. Selve artiklen viser den nye version, mens kategoriarkivet stadig har det gamle kort. Det peger ikke på browsercache, hvis den nye artikel kan ses i samme session. Mere sandsynligt er artiklens cachetag purget uden det relaterede arkiv, eller builderens komponentcache har sin egen levetid.
Sæt en ufølsom markør både i artiklen og i den del, arkivkortet afspejler. Gem artikel- og arkivheaders før og efter en normal gemning. Hvis artiklen bliver miss → hit med ny markør, men arkivet forbliver hit med gammel hash, har du et præcist purge-event at give til plugin- eller temaejeren.
Det mønster betyder ofte, at preview eller indlogget bruger går uden om page cache, mens anonyme gæster får en cachet kopi. Purge den konkrete URL og gentag anonymt. Hvis markøren stadig er gammel mod edge, men ny ved en sikker origin-kontrol, ligger kopien i CDN/proxylaget. Hvis begge er gamle, skal du tilbage til servercache eller selve renderingen.
Cache er ikke altid ejeren. Hvis editoren viser den gamle værdi efter reload, eller en read-only forespørgsel mod den rigtige post stadig indeholder den, blev ændringen måske ikke gemt eller en synkronisering skrev den tilbage. Kontroller post-id, revision og builderens datakilde, før du purger igen. Ellers kan du bruge tid på at tømme lag, som korrekt gengiver en gammel databaseværdi.
Ved planlagte indholdsfeeds eller eksterne datakilder skal du også notere opdateringsrytmen. En cache kan være frisk og stadig vise en gammel pris, hvis importen aldrig skrev den nye værdi. Følg rækkefølgen fra kilde til database, rendering og cache; den første gamle værdi ejer sagen.
Fjern testmarkøren, gendan tidligere purge-/TTL-/CDN-regel, og purge de berørte tags. Hvis en integration blev tilføjet, gendan plugin/kode fra backup og bekræft den tidligere dokumenterede adfærd. Sæt ikke HTML-browsercache tilbage til en kendt skadelig lang TTL.
Hosting skal have URL, markør, UTC-tid og headers fra edge/origin. Pluginudvikleren skal have eventet, der opdaterer data uden purge. Se LiteSpeed hosting hos Hostious ved flere cachelag eller originproblemer.
Fordi du er logget ind og bypasser cachen, mens anonyme får den gamle cachede version. Test altid i et privat vindue – det er de besøgendes virkelighed.
Følg headerne: Age og X-QC-Cache/CDN-headers peger på edge-cache, X-LiteSpeed-Cache på serverens cache, og ingen af delene peger på browserens egen cache. Purge kun det lag, der matcher.
Som nødgreb, ja – men som vane, nej. Fuld purge tømmer alt og gør sitet langsomt, til cachen er varm igen. Purge den konkrete URL, og lær hvilken hændelse der burde have purget automatisk.
Brug en ufølsom markør som CACHE-TEST-1420, og skriv for hvert lag, om markøren ses: editor/preview, origin, LiteSpeed, CDN og normal browser. Gem headers og tidspunkt sammen med resultatet. Markøren skal fjernes igen efter testen, så den ikke bliver en permanent del af indholdet.
Når laget er fundet, dokumenteres den smalleste purge og samme request før/efter. En global purge kan få siden til at se rigtig ud uden at afsløre det manglende event. Notér derfor også hvilken post, taxonomy eller komponent der burde have ugyldiggjort cachen, og kontrollér en relateret arkivside som negativ eller sekundær test.
