Kort svar: LiteSpeed Cache skriver sine serverregler i .htaccess mellem
# BEGIN LSCACHEog# END LSCACHE(plus en NON_LSCACHE-blok). Reglerne styrer bl.a. cache-vary på mobil/login, browser cache og WebP-servering. Rediger dem aldrig i hånden – pluginnet overskriver blokken, når indstillinger gemmes. Mangler blokken (efter gendannelse eller manuel oprydning), genskabes den ved at gemme LiteSpeed-indstillingerne igen. Og sletter du hele sektionen ved en fejl, holder cachen simpelthen op med at variere korrekt – typisk med forkert indhold til følge.
Åbner man .htaccess på et LiteSpeed-site, møder man et bundt regler, man ikke selv har skrevet. De ser tekniske ud – og fristelsen til at “rydde op” har væltet mange velfungerende cache-opsætninger. Denne guide forklarer, hvad blokkene gør, hvornår du må røre dem, og hvordan de genskabes.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet viser et typisk (forkortet) uddrag af LiteSpeed-blokken.
På en LiteSpeed-server er .htaccess vejen til at tale direkte med serverens cache-motor – det er derfor, LiteSpeed Cache kan mere end plugins på andre servere. Pluginnet vedligeholder typisk to sektioner: LSCACHE-blokken med cache-reglerne og NON_LSCACHE-blokken med øvrige regler (fx browser cache-headere). Begge er indrammet af BEGIN/END-kommentarer – og alt mellem dem tilhører pluginnet:
Inde i blokkene: nej. Pluginnet genskriver dem ved næste gem af indstillinger, så håndrettelser overlever ikke – og en tastefejl giver øjeblikkelig 500 på hele sitet. Vil du ændre adfærden, så ændr indstillingen i LiteSpeed Cache, og lad pluginnet skrive reglerne. Egne regler (redirects, sikkerhed) placeres uden for BEGIN/END-sektionerne – så lever de fredeligt side om side. Generel .htaccess-førstehjælp – inklusive gendannelse af WordPress-standardblokken – står i .htaccess-guiden.
Efter en gendannelse fra backup, en flytning eller en hårdhændet oprydning kan LSCACHE-blokken mangle. Symptomet er subtilt: pluginnet ser aktivt ud, men cachen opfører sig forkert – ingen hits, eller forkert varieret indhold. Løsningen er enkel: åbn LiteSpeed Cache-indstillingerne, og klik Gem (uden at ændre noget) – så skriver pluginnet sine blokke igen. Tjek bagefter, at .htaccess har rettigheden 644, og at der ikke ligger halve sektioner fra tidligere cache-plugins og forstyrrer; fjern i så fald hele den fremmede sektion.
Opsætningen er sund, når .htaccess indeholder komplette BEGIN/END-par for LSCACHE og NON_LSCACHE, cache-headerne viser hit for anonyme og no-cache for indloggede (test begge!), WebP serveres hvor forventet – og sitet svarer 200 på alle stikprøver. Tag en kopi af den fungerende .htaccess og gem den med dato: det er verdens billigste forsikring, næste gang noget skal fejlsøges eller flyttes.
Nej – det nulstiller ikke cachen, det fjerner reglerne for korrekt variering. Brug purge-funktionerne i pluginnet til at rydde cache, og lad blokken være.
Fordi pluginnet ejer indholdet mellem BEGIN og END og genskriver det ved næste gem. Ændr indstillingen i pluginnet i stedet – eller læg din egen regel uden for sektionen.
LSCACHE-direktiverne virker kun på LiteSpeed-servere – på Apache ignoreres de stille (harmløst), og på nginx læses .htaccess slet ikke. Flytter du til LiteSpeed-hosting, vågner reglerne til live igen af sig selv.
