Kort svar: Nogle sider må aldrig caches: alt med persondata, formularer med engangstokens og sider med indhold, der skifter pr. besøgende. I LiteSpeed Cache undtager du præcist – pr. URI, cookie, query-string eller brugerrolle – under Cache → Excludes. Kunsten er at undtage smalt: en undtagelse for meget koster fart på hele sitet, en for lidt viser forkert indhold. Verificér altid med cache-headerne bagefter.
Cache-undtagelser er der, hvor hastighedsopsætning bliver håndværk: WooCommerce-siderne klarer LiteSpeed selv, men kampagnesider med nedtælling, medlemsområder, formularer og landingssider med personaliseret indhold er dit ansvar. Denne guide viser de fire undtagelsestyper – og hvornår hver især er den rigtige.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026; menupunkternes navne kan variere mellem LiteSpeed Cache-versioner. Terminaleksemplet er genskabt.
Skal undtages: sider med persondata eller sessionsindhold (ud over WooCommerce-automatikken – fx egne “min side”-løsninger), formularer med engangstokens (nonce), der udløber i cachet HTML, sider med tidsafhængigt indhold (nedtællinger, “kun i dag”-priser) og medlemsindhold bag login uden privat cache. Skal ikke undtages: almindelige sider “for en sikkerheds skyld”. En kontaktformular med standardopsætning virker fint på cachede sider, og roterende indhold, der gerne må være ens i cache-levetiden, er ingen grund til undtagelse – sæt hellere kortere TTL på den ene side.
| Type | Felt i LiteSpeed Cache | Brug den til |
|---|---|---|
| URI | Do Not Cache URIs | Konkrete sider/stier – fx /medlem/ eller /kampagne-live/ |
| Query string | Do Not Cache Query Strings | Parametre der ændrer indholdet – fx ?preview eller egne parametre |
| Cookie | Do Not Cache Cookies | Besøgende i en særlig tilstand – fx et medlemsplugins cookie |
| Rolle | Do Not Cache Roles | Hele brugerroller – fx shop_manager under test |
To præcisionstips: URI-felterne matcher som udgangspunkt begynder med – så /kampagne rammer også /kampagne-2026/; brug $ for præcis match, hvor det understøttes. Og husk forskellen på “undtag fra cache” og “undtag fra optimering”: går CSS/JS i stykker på én side, er det optimerings-undtagelser (Page Optimization → Tuning), du skal bruge – ikke cache-undtagelser.
Headeren x-litespeed-cache-control viser sidens cache-beslutning, og x-litespeed-cache viser hit/miss. Hele læsningen af headerne står i header-guiden – den er også værktøjet, når problemet er det omvendte: en side, der burde caches, men ikke bliver det, fordi en undtagelse rammer for bredt.
Før du undtager en hel side, så spørg: er det hele siden, der er dynamisk – eller kun en stump? En nedtæller, et navn eller en kurv-status kan serveres dynamisk i en ellers cachet side med ESI (på LiteSpeed-server) eller et lille AJAX-kald. Så beholder du cache-gevinsten på 99 % af siden; fremgangsmåden er beskrevet i WooCommerce-guiden. Undtagelser er til sider, hvor alt er personligt – stumper klares smartere.
Undtagelserne er korrekte, når de følsomme sider viser no-cache i headerne ved hvert besøg, resten af sitet stadig får cache-hit, og listen over undtagelser er kort nok til at kunne forklares på ét minut. Gennemgå listen halvårligt: undtagelser fra nedlagte kampagner og slettede plugins har det med at blive stående – og hver unødvendig linje koster cache-hit-rate. Dokumentér hvorfor for hver linje, så oprydningen er ufarlig.
Nej – med WooCommerce aktivt håndterer LiteSpeed Cache det automatisk. Manuelle undtagelser er til dine egne dynamiske sider, som ingen automatik kender.
Klassisk nonce-problem: formularens engangstoken udløber, mens siden ligger i cache, og indsendelser afvises. Løsning: undtag siden, sæt kortere TTL end token-levetiden – eller brug en formularløsning, der henter token via AJAX.
Kun på de undtagne sider – de leveres af u-cachet PHP ved hvert besøg. Derfor undtager man smalt: hver side på listen er en side, hvor serveren arbejder forfra hver gang.
