Cloudflare Cache Rules til WooCommerce uden cached kurv og checkout

Kort svar: Cloudflare må kun cache WooCommerce-HTML, når alle besøgende kan få det samme svar. Hvis du gør HTML cache-egnet, skal kurv, checkout, Min konto, login, wc-ajax, relevante API-kald og requests med WooCommerce- eller login-sessioncookies gå uden om edge-cachen. Placér bypass som den sidste matchende cachebeslutning, fordi sidste konfliktende Cache Rule vinder. Eftertest to separate browsersessioner; kurv, checkout og konto må aldrig vise CF-Cache-Status: HIT.

Risiko: Høj — forkert cache kan vise en anden sessions indhold Forventet tid: 45-90 minutter plus checkouttest Hav klar: Staging/testshop, aktuelle WooCommerce-sideslugs, testprodukt og mulighed for at inspicere headers/cookies

Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Regellogikken er fagligt kontrolleret, men Hostious er ikke bag Cloudflare, og der er ingen Cloudflare-testzone knyttet til artiklen. En syntetisk stagingtester kan validere path-udtrykket, men er ikke bevis for Cloudflares evaluering eller en produktionsshop.

Cloudflare cacher ikke automatisk al HTML, blot fordi DNS-skyen er orange. Problemet opstår, når en bred Cache Rule, “Cache Everything”, APO eller et andet edge-lag gør offentlige WordPress-sider cache-egnede uden at skelne WooCommerce-sessioner. En hurtig produktside er ikke en gevinst, hvis kurven bliver tom, gammel eller deles mellem besøgende.

Kortlæg de dynamiske routes først

Læs de faktisk tildelte WooCommerce-sider i WordPress. Danske shops kan bruge /kurv/, /kasse/ og /min-konto/ i stedet for engelske slugs. En bypassregel, der kun matcher /cart/, beskytter ikke en side med et andet navn.

Kortlæg mindst:

• kurvsiden;
• checkout-siden og ordre-/betalingsendpoints under den;
• Min konto og login;
• wc-ajax-requests;
• Store API/REST-routes, hvis de indgår i frontendflowet;
• webhooks og callbacks;
• preview og WordPress administration.

Cloudflare cacher kun GET og HEAD, men en dynamisk route bør stadig have en tydelig bypass. Det forhindrer, at en efterfølgende GET-statusside eller en fejlkonfiguration bliver gjort cache-egnet.

De cookies, der fortæller at en WooCommerce-session findes

WooCommerce bruger blandt andet:

Cookieværdier må aldrig stå i screenshots. Det er nok at vise cookienavnet og at værdien er maskeret.

Bekræft om der overhovedet er et cacheproblem

Test som anonym besøgende uden varer:

1. åbn en produktside i et privat vindue;
2. gem CF-Cache-Status, Cache-Control, Set-Cookie og eventuelt Age;
3. tilføj et testprodukt til kurven;
4. genindlæs produktsiden og kurven;
5. gentag i en helt separat browserprofil.

Regel 1: bypass de faktiske WooCommerce-paths

Opret en Cache Rule med en afgrænset betingelse for de paths, din shop bruger, og handlingen Bypass cache. Et konceptuelt eksempel er:

(http.request.uri.path eq "/kurv") or
starts_with(http.request.uri.path, "/kurv/") or
(http.request.uri.path eq "/kasse") or
starts_with(http.request.uri.path, "/kasse/") or
(http.request.uri.path eq "/min-konto") or
starts_with(http.request.uri.path, "/min-konto/")

Udtrykket bruger eq til basepathen uden afsluttende skråstreg og starts_with() til både versionen med skråstreg og alle underliggende endpoints. /kurv, /kasse og /min-konto er kun eksempler: slå de faktisk tildelte WooCommerce-sider og deres reelle slugs op i den konkrete shop, og erstat hvert path-par før reglen gemmes. Kopiér ikke danske eller engelske standardslugs blindt. Kontrollér med både base-URL'en og eksempelvis et ordre-/betalingsendpoint under checkout.

Regel 2: bypass sessions og login med Cookie-feltet

Tilføj en separat eller samlet bypassbetingelse, der matcher cookienavne i hele http.cookie-strengen:

(http.cookie contains "woocommerce_items_in_cart=") or
(http.cookie contains "woocommerce_cart_hash=") or
(http.cookie contains "wp_woocommerce_session_") or
(http.cookie contains "wordpress_logged_in_")

Brug cookienavne, ikke værdier. Test udtrykket i Cloudflares Expression Builder eller Trace. Hvis din shop bruger valuta-, sprog-, medlems- eller priscookies, skal de vurderes særskilt. En side kan være offentlig og stadig variere i pris eller sprog.

Regel 3: bypass wc-ajax, API, preview og administration

Afhængigt af shopopsætningen skal du beskytte:

• requests med wc-ajax i query string;
• /wp-admin/ og WordPress-login;
• preview-requests;
• /wp-json/ eller specifikke Store API-routes, der leverer sessionsafhængige data;
• webhook- og callbackpaths.

Gør ikke alle query strings cache-identiske. Parametre kan ændre valuta, sortering, produktvariant eller session. Ignorér kun en parameter, når du har bevist, at response body er den samme.

Regelrækkefølgen er afgørende

Cache Rules er stackable. Hvis flere regler sætter samme cache-egenskab, vinder den sidste matchende regel. En bred “hele websitet er cache-egnet”-regel efter din WooCommerce-bypass kan derfor ophæve beskyttelsen.

En sikker rækkefølge er:

1. bred cache-egnet regel for de offentlige områder, hvis du bevidst bruger HTML-cache;
2. mere specifikke WooCommerce- og login-bypassregler bagefter;
3. kontrol med Trace for produkt, kurv, checkout og en request med sessioncookie.

Læs den faktiske evalueringsrækkefølge i din konto. Ældre Page Rules kan også eksistere, men Cache Rules har forrang, når de matcher cacheindstillinger på samme request.

Respektér originens cacheheaders

WooCommerce og WordPress-cachelag kan sende Cache-Control, Set-Cookie og andre signaler. En Edge TTL, der tvinger caching og ignorerer originens direktiver, kan fjerne den sikkerhedsmargin. Brug ikke en global TTL-overstyring på dynamiske routes.

Hvis din servercache allerede ekskluderer WooCommerce-sider, skal Cloudflare-reglerne afspejle samme grænse. To cachelag bør være enige om, hvad der er offentligt. Ellers kan origin levere korrekt uncached indhold, mens edge stadig returnerer en gammel kopi.

Testflow med to helt adskilte sessioner

Brug staging eller en testshop uden rigtige kunder.

Session A

1. Åbn produktsiden anonymt.
2. Tilføj produkt A.
3. Kontrollér mini-cart, kurv og checkout.
4. Gem kun headers og masker cookie-værdier.

Session B

1. Åbn en ny browserprofil, ikke blot en ekstra fane.
2. Åbn samme produktside.
3. Bekræft at kurven er tom.
4. Tilføj produkt B og kontrollér total og checkout.

Efter cache-purge

1. Purge kun test-URL'erne, hvis muligt.
2. Bekræft forventet MISS på offentlig cache-egnet side.
3. Bekræft derefter HIT for en anonym side, hvis HTML-cache er ønsket.
4. Bekræft fortsat DYNAMIC/BYPASS på kurv, checkout og begge sessions.

Test også mobil, login og en checkout i gatewayens testtilstand. Ingen rigtig ordre eller kortdata skal bruges som dokumentation.

Når lager, priser eller valuta varierer

En anonym produktside kan stadig være dynamisk. Geolocation, valuta, B2B-priser, medlemskab, lager pr. lokation og sprog kan ændre HTML. I sådanne shops er det ofte sikrere at lade produktsider være DYNAMIC og nøjes med statiske filer eller et cachelag, der forstår variationerne.

Lav ikke en custom cache key med alle cookies. Det skaber høj kardinalitet og mange MISS uden nødvendigvis at være sikkert. Definér de få dokumenterede variationer eller bypass hele den variable side.

Sådan eftertester du

• Kurv, checkout, Min konto og login viser aldrig HIT.
• Set-Cookie bevares, når WooCommerce starter en session.
• To adskilte profiler ser kun deres egen kurv og total.
• wc-ajax og relevante API-kald returnerer friske sessionsdata.
• Offentlige, bevidst cachede sider kan gå MISS → HIT uden at ændre pris, valuta eller lager forkert.
• Trace viser, at bypass er den sidste konfliktende cachebeslutning.
• Checkout kan gennemføres i testtilstand, og callback/webhook når frem.

Rul tilbage

Hvis personlig data cachelagres, deaktivér straks den brede HTML-cache-regel, purge de berørte HTML-URL'er og test nye sessioner. Gendan den tidligere regelfil eller screenshots som facit. Cookie- eller path-bypass kan derefter genbygges på staging, før HTML-cache aktiveres igen.

Hvornår skal hosting eller udvikler hjælpe?

Hosting skal afstemme edge- og servercache samt originheaders. En WooCommerce-udvikler skal vurdere custom sessions, valuta, medlemspriser og checkout-API'er. Se WooCommerce-hosting hos Hostious, hvis du vil have cache og checkout testet samlet.

Ofte stillede spørgsmål om Cache Rules og WooCommerce

Må Cloudflare cache HTML på en WooCommerce-shop?

Ja, men kun på sider hvor alle besøgende kan få samme svar: forside, kategorier og produktsider. Kurv, checkout, Min konto og alt med session skal altid bypasses.

Hvilke cookies skal udløse bypass?

WooCommerce-sessionscookies (woocommerce_*, wp_woocommerce_session_*) og login-cookies (wordpress_logged_in_*). Har requesten én af dem, skal svaret komme fra origin – ellers kan kunder se hinandens indhold.

Hvordan tester jeg, at reglerne er sikre?

To sessioner: læg en vare i kurven i én browser, og åbn shoppen anonymt i en anden. Ser den anonyme session aldrig den førstes kurv eller navn – og får kurvsiderne BYPASS – er opsætningen korrekt.

Læs også

• Læs headers i CF-Cache-Status: DYNAMIC, BYPASS og MISS.
• Start med Cloudflare-indstillinger til WordPress.
• Hvis checkout stadig fejler uden HIT, brug WooCommerce checkout virker ikke.
• Ved redirect-problemer på checkout: for mange redirects mellem Cloudflare og WordPress.
• Se alle Cloudflare-emner i Cloudflare-guides til WordPress.

Sådan dokumenterer du din egen WooCommerce-cachetest

Start med at skrive de faktiske slugs og sessionstyper ned. Gem derefter reglen som tekst, ikke kun som et dashboardbillede; teksten afslører manglende basepaths, parenteser og betingelser. Tilføj et screenshot af Expression Builder eller Trace med konto-, zone- og Ray-identitet beskåret. En syntetisk path-tester kan kontrollere udtrykkets logik, men den beviser ikke, at Cloudflare har evalueret reglen på en virkelig request.

Brug to adskilte browserprofiler og to ufølsomme testprodukter. For hver profil registreres cookienavne, CF-Cache-Status på produkt, kurv og checkout samt den synlige kurvtotal. Cookieværdier, kundeoplysninger, ordredata og betalingsfelter må ikke indgå. Resultatet er bestået, når profilerne er isolerede og de dynamiske routes aldrig viser HIT.

Gem til sidst en offentlig cachetest uden session: samme produktside to gange kan, hvis din opsætning bevidst cacher HTML, gå fra MISS til HIT. Sammenlign pris, valuta og lager med origin. Dokumentationen skal således rumme både en positiv cachetest og flere negative bypass-tests. Den balance er langt vigtigere end en høj samlet hitrate.