Kort svar: Når login-siden sender dig i ring eller klager over blokerede cookies, er det næsten altid én af tre ting: login-cookien bliver ikke sat (browser eller cookie-regler), login-siden bliver leveret fra cache, eller WordPress’ site-URL passer ikke til den adresse, du logger ind på. Test i inkognito først, ryd derefter cache af login-sider, og tjek til sidst WP_HOME og WP_SITEURL for http/https- og www-mismatch.
Du taster korrekt brugernavn og adgangskode, rammer Enter – og står på login-siden igen. Ingen fejlbesked, eller måske beskeden “Cookies are blocked or not supported by your browser”. De to symptomer hører til samme familie: login lykkes teknisk set, men sessionen overlever ikke turen tilbage til wp-admin.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Diagrammet er en diagnoseillustration – ikke en måling af hostious.io.
Åbn et inkognitovindue, og prøv at logge ind. Virker det dér, ligger problemet i din normale browserprofil: gamle cookies fra sitet, en udvidelse der blokerer cookies, eller strænge tracking-indstillinger. Slet alle cookies for dit domæne (ikke nødvendigvis alle cookies i browseren), og prøv igen. Virker det heller ikke i inkognito, er problemet på serversiden – gå videre til trin 2.
En page cache må aldrig cache wp-login.php eller noget under /wp-admin/. Sker det alligevel, får du serveret en gammel udgave af login-siden med et udløbet sikkerhedstoken – og login fejler i ring. Det opstår typisk efter skift af cache-plugin, ved for aggressive cache-regler på CDN-niveau eller ved “cache alt”-regler i Cloudflare.
Login-cookien sættes for det domæne, WordPress mener, sitet bor på. Logger du ind på https://www.ditdomæne.dk, mens site-URL’en står som http://ditdomæne.dk, passer cookien aldrig – og du ryger i loop. Det klassiske tidspunkt er lige efter et SSL-skift eller en flytning.
Tjek de to værdier under Indstillinger → Generelt (eller wp option get siteurl og wp option get home). De skal begge bruge https og præcis den variant – med eller uden www – som sitet reelt kører på. Er de forkerte, så ret dem ét sted og kontrollér, at redirects følger med; guiderne www eller uden www og ERR_TOO_MANY_REDIRECTS dækker fælderne.
Plugins, der flytter login-URL’en, begrænser login-forsøg eller binder sessioner til IP-adresser, kan skabe loops – især som efterladte rester: pluginnet er slettet, men dets regler står stadig i .htaccess eller i databasen. Ser du henvisninger til et gammelt sikkerhedsplugin i .htaccess, så fjern hele dets sektion – fremgangsmåden står i guiden om at gendanne .htaccess.
Skal du ind nu, uanset årsag, så brug de manuelle veje: deaktiver mistænkte plugins ved at omdøbe deres mapper via SFTP, eller nulstil adgangen direkte. Begge fremgangsmåder er beskrevet trin for trin i låst ude af wp-admin og nulstil WordPress-adgangskode.
Problemet er løst, når login virker i både normal browser og inkognito, når wp-login.php svarer uden cache-hit i headerne, og når du kan logge ind og ud tre gange i træk uden loop. Ramær flere brugere samtidig – og hjælper cache-rydning kun midlertidigt – så er det cache-reglerne og ikke browserne, der skal rettes. Kommer du ikke i mål, kan Hostious’ support slå requests op i serverloggen og se, præcis hvor sessionen knækker.
Så ligger årsagen næsten sikkert i din browser: gamle cookies, en udvidelse eller en cachet udgave af login-siden hos dig. Inkognitotesten afgør det på 30 sekunder.
Ja – hvis site-URL’en stadig står på http, mens sitet kører https, passer login-cookien ikke længere. Ret WP_HOME og WP_SITEURL til https-varianten, og ryd cachen bagefter.
Kun hvis problemet er lokalt hos dig. Slet cookies for dit eget domæne først – det rammer ikke dine logins andre steder. Fejler login stadig i inkognito, er cookies ikke problemet.
