Kort svar: wp-admin skal have tre garantier bag Cloudflare: aldrig cache (Cache Rule med bypass på /wp-admin/ og wp-login.php), ingen challenges for redaktørerne (WAF-undtagelse for jeres faste IP-adresser eller login-stien) og fri passage for admin-ajax og REST, som editoren bruger. Får du de tre på plads, forsvinder de klassiske spøgelser: udløbne login-tokens, captcha midt i arbejdet og en editor, der ikke kan gemme.
Cloudflare beskytter forsiden glimrende – men wp-admin har andre behov end forsiden. Bag proxyen opstår tre typiske gener for redaktionen: login-sider fra cache med udløbne tokens, challenges der afbryder arbejdet, og gemme-fejl fordi sikkerhedslaget fænger editorens baggrundskald. Alle tre kan løses med målrettede regler – uden at åbne noget for offentligheden.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026; Cloudflare-dashboardets stier er beskrevet pr. samme dato. Eksemplet i billedet er genskabt.
Som standard cacher Cloudflare ikke HTML – så på en jomfruelig opsætning er admin allerede sikker. Problemet opstår, når der bygges Cache Rules med “cache everything”: så skal admin-stierne eksplicit undtages, ellers ender login-sider og admin-HTML i cachen. Reglen, der løser det, ligger under Caching → Cache Rules:
Bemærk rækkefølgen: Cloudflare evaluerer Cache Rules oppefra, og bypass-reglen skal stå før cache-reglen. Cookie-betingelsen (wordpress_logged_in) sikrer, at indloggede brugere aldrig får cachede sider – heller ikke på frontend. Hele WooCommerce-varianten af samme øvelse står i Cache Rules-guiden til WooCommerce.
Sikkerhedsregler må gerne være strenge på login-stien – bare ikke for jer selv. Den rene løsning: en WAF custom-regel med handlingen “Skip”, der undtager jeres faste kontor-/hjemme-IP-adresser fra challenges på /wp-login.php og /wp-admin/. Har I skiftende IP-adresser, så brug i stedet Cloudflare Access eller nøjes med Managed Challenge (som oftest løses usynligt) frem for interaktive captchas på login. Baggrunden om challenge-typerne står i challenge-guiden.
Blok-editoren gemmer via REST (/wp-json/), og mange plugins arbejder gennem admin-ajax.php. Rammer en WAF-regel eller rate limiting de stier, får redaktører “Opdatering mislykkedes”-fejl, selvom siden ser normal ud. Tjek Security → Events for blokerede POST-requests til de stier, når editoren driller – og lav præcise undtagelser (sti + jeres IP eller login-cookie) frem for at slukke reglen. Fejlbilledet i WordPress er beskrevet i JSON-fejlsguiden og REST API-guiden.
Opsætningen holder, når wp-login.php aldrig viser cache-HIT i headerne, redaktører kan logge ind og arbejde en hel session uden challenges, editoren gemmer uden fejl (tjek konsollen for blokerede REST-kald), og Security Events ikke viser blokeringer af jeres egne IP-adresser. Test fra både kontornet og mobilnet – og gentag tjekket, når I strammer sikkerheden: hver ny regel skal bevise, at den ikke rammer redaktionen.
Det er valgfrit og primært støjreduktion – botterne stopper ikke af det. Kombinationen af stærke kodeord, totrinslogin og Cloudflares regler beskytter reelt; en flyttet login-URL skal blot huskes i alle undtagelser.
Det klassiske tegn på, at login-sider rammer cachen – eller at en regel fjerner cookies. Tjek cache-status på wp-login.php først; mekanikken er samme som i login-loop-guiden.
Ja – en WAF-regel kan challenge eller blokere login-stien for alle lande undtagen Danmark. Husk bare rejser og udenlandske samarbejdspartnere: Managed Challenge er mere tilgivende end en blokering.
