Cookies zijn geblokkeerd of worden niet ondersteund in WordPress

Wat de melding eigenlijk betekent

WordPress plaatst bij het tonen van wp-login.php een kort lopende testcookie met de naam wordpress_test_cookie, en controleert bij de POST terug of die cookie er nog is. Ontbreekt hij, dan weigert WordPress wp_set_auth_cookie() te draaien en krijg je de foutmelding. Dat is een bewuste veiligheidsrem: het heeft geen zin om de drie echte auth-cookies (wordpress_[hash], wordpress_sec_[hash], wordpress_logged_in_[hash], beschreven in de WordPress-handleiding) te schrijven als de browser ze bij het volgende verzoek toch niet gaat accepteren.

De melding is dus een symptoom, geen diagnose. In de praktijk wil je browser cookies gewoon accepteren. De vraag is wat het testcookie tegenhoudt op de route heen of terug.

Meest voorkomende oorzaken, op volgorde van waarschijnlijkheid

1. Je laadt wp-admin in een iframe of een cross-site context. SaaS-dashboards, sitebuilders en "preview in een modal"-flows embedden WordPress in een iframe op een ander domein. Browsers gebruiken tegenwoordig standaard SameSite=Lax, en de SameSite-referentie op MDN is er duidelijk over: een Lax-cookie wordt alleen meegestuurd bij top-level veilige navigaties. Een POST vanuit een iframe op een ander domein is noch top-level noch een safe method, en dus dropt de browser het testcookie.
2. Een browserextensie of strikte privacymodus houdt het cookie tegen. Brave met Shields op "strict", uBlock Origin met agressieve filters, Firefox-profielen met "cookies wissen bij afsluiten" en incognito-vensters waar extensies in mogen draaien saboteren de probe vaak zonder dat je het merkt.
3. WP_HOME en WP_SITEURL komen niet overeen met de URL in je adresbalk. De auth-cookies zijn gebonden aan het domein dat WordPress denkt te zijn. Kom je aan op https://www.voorbeeld.nl/wp-login.php terwijl WP_HOME op https://voorbeeld.nl staat, dan krijgt je browser een cookie voor voorbeeld.nl en stuurt hij op www.voorbeeld.nl terug. Vanuit de browser klopt dat niet en is het testcookie "afwezig".
4. Een cache- of security-plugin stript de Set-Cookie-headers op wp-login.php. Full-page-caches cachen soms per ongeluk de loginpagina voor anonieme bezoekers, en sommige security-plugins herschrijven responses. Beide kunnen de Set-Cookie: wordpress_test_cookie=...-header ongemerkt weghalen.
5. Er gaat output de deur uit vóór de headers. Een losse regel witruimte, een UTF-8 BOM of een echo/var_dump in wp-config.php, een must-use plugin of de functions.php van je actieve thema triggert de "headers already sent"-toestand in PHP. WordPress detecteert dat en toont dan expliciet de blocked-cookies fout. Dit is de klassieke "unexpected output"-variant.

Bepalen welke oorzaak speelt

Open de DevTools van je browser (F12), ga naar het Network-tabblad, herlaad wp-login.php en bekijk de response voor dat verzoek. Verstuur daarna het formulier en bekijk de POST.

• Bevat de GET-response Set-Cookie: wordpress_test_cookie=...? Zo niet, dan wordt het cookie aan jouw kant onderdrukt. Ga naar oorzaak 4 of 5.
• Staat wordpress_test_cookie in het Cookie-tabblad van de POST? Zo niet, dan heeft de browser hem wel gekregen maar niet meegestuurd. Ga naar oorzaak 1, 2 of 3.
• Laat document.cookie in de Console het testcookie zien na een gewone paginalaad? Zo ja, en hij wordt tóch niet meegestuurd bij de POST, dan zit je vrijwel zeker in een cross-site iframe of SameSite-situatie (oorzaak 1).

Staat er in de response-body van de mislukte POST letterlijk "Cookies are blocked due to unexpected output", dan zit je in oorzaak 5. WordPress benoemt die variant apart, dus gokken hoeft niet.

Fix per oorzaak

Oorzaak 1: iframe of cross-site context

Open wp-login.php in een nieuw top-level tabblad in plaats van in de embed. Als de hostapplicatie een SaaS is die admin-schermen altijd in een iframe propt, is dit een structurele beperking van Lax-cookies; de enige schone oplossing is één keer inloggen in een top-level tab en daarna terugkeren naar de embed. Je weet dat het werkte als je URL-balk na inloggen wp-admin/ toont in plaats van dat je terugkaatst naar wp-login.php.

Oorzaak 2: browserextensie of strikte modus

Probeer een ander browserprofiel zonder extensies, of een gewoon (niet-privé) venster. Lukt het inloggen daar wel, dan zit het probleem in het huidige profiel. Bij Brave klap je Shields uit op de site en zet je "cookies" op "toestaan". Bij Firefox schakel je "Enhanced Tracking Protection" per site uit via het schild-icoon in de adresbalk. Verifieer door de login opnieuw te proberen in het aangepaste profiel: lukt het dan wel, dan was het de extensiestack.

Oorzaak 3: domein- of HTTPS-mismatch

Kijk in wp-config.php naar WP_HOME en WP_SITEURL. Staan ze er niet, check dan siteurl en home in de database. Beide waarden moeten exact overeenkomen met de URL die je in de adresbalk hebt, inclusief de www (of het ontbreken ervan) en het https://-schema. Toont de browser ook een gebroken hangslot of consolewaarschuwingen over onveilige subresources, dan veroorzaakt dezelfde onvolledige migratie mogelijk ook mixed-content-waarschuwingen.

// wp-config.php, voor een site die draait op https://www.voorbeeld.nl
define( 'WP_HOME',    'https://www.voorbeeld.nl' );
define( 'WP_SITEURL', 'https://www.voorbeeld.nl' );

Wis na het opslaan de oude cookies voor de oude hostnaam in je browser en laad wp-login.php opnieuw. Je weet dat het werkt als het inloggen doorkomt zonder terug te kaatsen en DevTools de auth-cookies op exact het domein uit de adresbalk laat zien.

Draai je multisite met gemapte domeinen, dan moet je waarschijnlijk stoppen met het forceren van COOKIE_DOMAIN. De wp-config-referentie beschrijft die constante als één vaste waarde, en multisite met domain mapping heeft juist het standaardgedrag nodig in plaats van een hardgecodeerd domein.

Oorzaak 4: cache- of security-plugin die de header stript

Hernoem de verdachte plugin onder wp-content/plugins/ via SFTP of de bestandsbeheerder van je host. Begin met full-page-caches (wp-super-cache, w3-total-cache, wp-rocket, litespeed-cache) en WAF-achtige security-plugins (wordfence, wp-cerber, all-in-one-wp-security-and-firewall). Door de map te hernoemen denkt WordPress dat de plugin weg is en wordt hij gedeactiveerd zonder dat je het dashboard in hoeft.

Probeer na elke rename opnieuw in te loggen. Je weet dat je de dader te pakken hebt als het inloggen lukt én DevTools de Set-Cookie: wordpress_test_cookie=... header op de GET weer laat zien. Zet de map daarna terug en meld het probleem bij de pluginmaker: een correct geconfigureerde cache zou wp-login.php nooit moeten cachen, en een correct geconfigureerde WAF zou Set-Cookie-headers daar nooit mogen herschrijven.

Oorzaak 5: onverwachte output (BOM, witruimte, losse echo)

Hernoem de map van je actieve thema zodat WordPress terugvalt op een core-thema (twentytwentyfive of wat er bij jouw versie meekomt). Probeer opnieuw in te loggen. Werkt dat, dan zit het probleem in de functions.php van het oude thema of een bestand dat daaruit geïnclude wordt. Helpt het niet, hernoem dan wp-content/mu-plugins en check daarna wp-config.php op regels vóór <?php of op een ?> aan het einde gevolgd door witruimte of een lege regel.

De snelste manier om een BOM te vinden: open het verdachte bestand in een editor die bytes toont en kijk of op positie nul de bytes EF BB BF staan. Verwijder ze en sla het bestand op als UTF-8 zonder BOM. Je weet dat het gelukt is als wp-login.php een schone response-body teruggeeft zonder de formulering "due to unexpected output" en de auth-cookies gewoon heen en weer rondkomen.

Wanneer je moet escaleren

Heb je alle vijf oorzaken langsgelopen en staat de fout er nog, verzamel dan eerst onderstaande gegevens voordat je hulp inroept. Zo hoeft degene die ernaar kijkt niet bij nul te beginnen:

• WordPress-versie, PHP-versie, actieve thema en een exacte lijst actieve plugins (uit wp plugin list --status=active of het Plugins-scherm)
• De volledige wp-config.php met secrets onleesbaar gemaakt, inclusief WP_HOME, WP_SITEURL en eventuele COOKIE_*-constanten
• Een HAR-export van één loginpoging via DevTools, inclusief zowel de GET van wp-login.php als de POST
• De response-body van de mislukte POST, en specifiek of daarin de tekst "due to unexpected output" voorkomt
• Of de site achter Cloudflare, een load balancer of een andere reverse proxy hangt, en op welke hostinglaag hij draait
• De output van curl -I https://www.voorbeeld.nl/wp-login.php met de response-headers

Kom je er dan nog niet uit, lees dan waarom je niet kunt inloggen in WordPress om te bevestigen dat je in het juiste artikel zit: het zusartikel WordPress login redirect loop dekt het geval waarin het testcookie prima werkt maar je sessie alsnog niet blijft plakken, en geen toegang tot wp-admin zonder foutmelding gaat over situaties waarin je überhaupt geen WordPress-loginscherm te zien krijgt. Kom je ná het inloggen op "Je hebt geen toestemming om deze pagina te bekijken", dan is de login al gelukt en zit je probleem in een capability-check, niet in een cookie.

Hoe voorkom je dat het opnieuw gebeurt

• Pin WP_HOME en WP_SITEURL hard in wp-config.php zodat ze niet uit de pas gaan lopen met het domein dat de browser raakt.
• Sluit wp-login.php en wp-admin/* uit van elke cachelaag die je toevoegt, of dat nou een plugin, een CDN-pagina-regel of een reverse proxy is.
• Voordat je wijzigingen commit in wp-config.php of functions.php: sla op als UTF-8 zonder BOM en zorg dat er geen witruimte of lege regel vóór <?php staat en helemaal geen sluitende ?> aan het einde.
• Bouw wp-admin niet in als iframe op een ander domein. Moet de hostapplicatie dat toch, laat de login dan in een top-level tab plaatsvinden en leun daarna op de bestaande sessie.