Cookies are blocked or not supported in WordPress

Inloggen in WordPress lukt niet door een cookie-foutmelding? Je bent niet de enige. Veel WordPress-beheerders lopen er wel eens tegenaan dat ze niet kunnen inloggen op wp-admin omdat er een melding verschijnt over geblokkeerde cookies. Vaak zie je de waarschuwing “Cookies zijn geblokkeerd of worden niet ondersteund door je browser. Je moet cookies inschakelen om WordPress te kunnen gebruiken.” Dit betekent dat WordPress de noodzakelijke login-cookie niet kan plaatsen of lezen. Daardoor blijf je bijvoorbeeld hangen op het inlogscherm of beland je in een inlog-redirectlus zonder in het dashboard te komen.

In dit kennisbankartikel leg ik helder uit wat cookies en sessies doen bij het WordPress‑inlogsysteem, waarom dit probleem optreedt en hoe je het in grote lijnen kunt oplossen. Dit artikel is specifiek gericht op sitebeheerders die niet meer kunnen inloggen op de WordPress‑admin (niet op websitebezoekers). Wees gerust: je website zelf blijft doorgaans normaal bereikbaar voor bezoekers — dit issue treft meestal alleen de beheerderskant.

Wat doen cookies en sessies bij het inloggen in WordPress?

Wanneer je inlogt op WordPress, gebruikt het systeem cookies om je sessie te beheren en je ingelogd te houden. Denk aan een cookie als het kortetermijngeheugen van je site: zodra je inlogt, plaatst WordPress een klein tekstbestandje (cookie) in je browser dat in feite zegt: “Deze gebruiker is succesvol ingelogd en geautoriseerd”. Bij elke volgende klik of paginaverzoek controleert WordPress die cookie om te onthouden wie je bent, zonder dat je je opnieuw hoeft voor te stellen. Met andere woorden: de cookie fungeert als jouw sessie‑identificatie. Zonder deze cookie “vergeet” WordPress bij iedere paginalaad wie je bent, en kun je dus niet ingelogd blijven. WordPress vertrouwt op deze cookies voor authenticatie en sessiebeheer; ze zijn essentieel om jouw loginstatus te behouden en toegang te geven tot het dashboard.

Enkele voorbeelden van WordPress‑authenticatiecookies zijn: wordpress_sec_[hash] en wordpress_logged_in_[hash] (die jouw login en identiteit aangeven), en wp-settings-[uid] (voor dashboardvoorkeuren). Ook plaatst WordPress op de inlogpagina een tijdelijke testcookie (zoals wordpress_test_cookie) om te controleren of jouw browser cookies accepteert. Als WordPress merkt dat deze testcookie niet gezet of uitgelezen kan worden, zal het de login blokkeren en de foutmelding over geblokkeerde cookies geven — een beveiligingsmaatregel om te voorkomen dat je op een manier inlogt die toch niet zal werken.

Symptomen van cookie- of sessieproblemen bij het inloggen

Hoe herken je nu dat jouw inlogprobleem daadwerkelijk door cookies of sessies wordt veroorzaakt? Enkele veelvoorkomende symptomen op een rij:

• Foutmelding op het inlogscherm: Je krijgt expliciet de melding “Cookies zijn geblokkeerd of worden niet ondersteund door je browser. Je moet cookies inschakelen om WordPress te kunnen gebruiken.” iedere keer dat je probeert in te loggen.
• Inlogscherm ververst steeds: Je voert je gebruikersnaam en wachtwoord in, maar na het verzenden kom je weer terug op het inlogscherm zonder foutmelding. WordPress laat je niet in het dashboard, omdat de login‑cookie niet gezet of gelezen kon worden (waardoor de site denkt dat je niet bent ingelogd).
• Redirect loop na inloggen: Je ziet een oneindige omleiding tussen wp-admin en wp-login.php. Bijvoorbeeld: je logt in, WordPress probeert je naar het dashboard te sturen, maar stuurt je direct weer terug naar het login‑formulier omdat de sessie niet behouden blijft. Dit patroon kan duiden op een cookie die niet werkt — de site blijft je als niet‑ingelogd beschouwen en vraagt continu opnieuw om in te loggen.
• Blijvend uitgelogd worden: In sommige gevallen lijkt de inlog even te slagen, maar zodra je een volgende actie doet in het dashboard, word je prompt uitgelogd of gevraagd opnieuw in te loggen. Ook dit wijst erop dat WordPress je sessie niet kan onthouden, meestal door een cookieprobleem.

Kortom, als “WordPress inloggen lukt niet” en je merkt bovengenoemde verschijnselen, is de kans groot dat er iets mis is met de cookies of sessie van het inlogsysteem.

Mogelijke oorzaken dat cookies worden geblokkeerd (bij WordPress login)

De foutmelding over geblokkeerde cookies wijst erop dat de login‑cookie niet goed werkt. Maar wat ligt hieraan ten grondslag? Ironisch genoeg betekent de melding niet altijd dat jouw browser daadwerkelijk cookies uitzet — vaak ligt de oorzaak elders in de keten. Hieronder bespreek ik de meest voorkomende oorzaken van dit probleem.

Browserinstellingen en privacy‑extensies

Een voor de hand liggende oorzaak is dat de browser zelf cookies blokkeert. Moderne browsers hebben steeds strengere privacy‑instellingen. Soms staat een browser zo ingesteld dat cookies (volledig of gedeeltelijk) worden geweigerd. Bijvoorbeeld als je alle cookies hebt uitgezet, strenge trackingbescherming aan hebt staan, of in private/incognito‑mode werkt, kunnen cookies geblokkeerd worden — vaak geldt dat privénavigatiemodi standaard cookies weigeren na de sessie. Ook browserextensies gericht op privacy of ad‑blocking kunnen ongemerkt het plaatsen van cookies verstoren. Denk bijvoorbeeld aan extensies die trackers blokkeren; in sommige gevallen kunnen ze agressief alle cookies tegenhouden of specifieke cookies (zoals die van WordPress) markeren als “verdacht”. Het gevolg is dat WordPress’ testcookie of login‑cookie niet doorkomt, en de site dus aanneemt dat jouw browser geen cookies ondersteunt.

Voorbeeld: stel je gebruikt een browser als Brave, of je hebt in Firefox strenge cookie‑instellingen. Je probeert in te loggen, maar na indienen van je gegevens blijf je op het login‑scherm. In zo’n geval is het goed mogelijk dat je browser het plaatsen van de WordPress‑cookie verhindert. Hetzelfde kan gebeuren als je een privacy‑plugin in je browser hebt die net iets té beschermend is. Om dit uit te sluiten, kun je proberen in te loggen met een andere browser, in een normale (niet‑private) sessie, of alle extensies tijdelijk uitschakelen. Als het inloggen dan wél lukt, weet je dat de oorzaak bij de browserinstellingen of ‑extensies lag.

Beveiligings- en cache‑plugins op je site

Een minder bekende maar veelvoorkomende oorzaak ligt bij WordPress‑plugins, met name beveiligingsplugins en cachingplugins. Deze handige plugins fungeren als een soort bewakers voor je site, maar soms zijn ze overijverig en blokkeren ze per ongeluk de normale werking van cookies.

Populaire security‑plugins (zoals Wordfence, Sucuri, iThemes Security e.d.) kunnen uit veiligheid bepaalde cookie‑activiteiten inperken of sessies ongeldig maken. Hun intentie is goed — je site beschermen — maar het kan ertoe leiden dat zelfs jij als legitieme beheerder niet kunt inloggen omdat de login‑cookie wordt tegengehouden.

Ook caching‑plugins (bijv. WP Super Cache, W3 Total Cache) kunnen roet in het eten gooien. Als een cache‑plugin te agressief omgaat met het cachen van de inlogpagina of headers, kan het gebeuren dat de browser verouderde informatie ziet en de verse cookie niet ontvangt. Soms wordt de loginpagina uit cache geserveerd zonder de cookie‑header (Set-Cookie), of de redirect na inloggen wordt verkeerd afgehandeld, wat resulteert in een mislukte sessie.

Daarnaast zijn er plugins die met cookies spelen, zoals bepaalde cookie‑consent‑plugins. Hoewel deze meestal alleen op de front‑end werken, kan een misconfiguratie ertoe leiden dat ze ook de WordPress‑inlogcookie blokkeren totdat er “toestemming” is gegeven — wat natuurlijk problematisch is voor de beheerder‑login. Dit komt niet heel vaak voor, maar is het overwegen waard als je recent zo’n plugin hebt geïnstalleerd.

Voorbeeld: je hebt recent een beveiligingsplugin geüpdatet, en vanaf dat moment kun je niet meer inloggen. Of je verhuist je site naar een nieuwe hosting en zet een cache‑plugin aan, en ineens krijg je de cookie‑fout. In deze gevallen is het waarschijnlijk dat zo’n plugin het loginproces dwarszit. Een plugin kan bijvoorbeeld de cookie‑generatie verstoren of een extra beveiligingscookie verwachten. Het resultaat: WordPress kan de standaard login‑cookie niet (correct) zetten, waardoor de bekende foutmelding verschijnt.

Fouten in het thema of onverwachte output (code‑problemen)

Soms ligt de oorzaak in je actieve thema of een andere codebron die onbedoeld roet in het eten gooit. Met name kan het voorkomen dat er ergens in een themabestand, plugin of zelfs in wp-config.php uitvoer wordt gegenereerd voordat WordPress de cookies stuurt. Dit is een technisch detail: cookies worden via HTTP‑headers verzonden, en HTTP‑headers kunnen alleen vóór alle HTML‑output worden gestuurd. Als een thema of plugin per ongeluk al iets van tekst of whitespace naar de browser stuurt (bijvoorbeeld een extra regel witruimte, een BOM‑karakter, of een debugbericht) vóórdat de login‑cookie header eruit is, dan blokkeert dat de cookie‑transmissie. WordPress merkt dit meteen, omdat de testcookie ontbreekt of de authenticatiecookie niet aankomt, en geeft de foutmelding dat cookies geblokkeerd zijn “vanwege onverwachte uitvoer” (in het Engels: “Cookies are blocked due to unexpected output”). Dit scenario kan optreden na het bewerken van belangrijke bestanden als functions.php of wp-config.php, of na het installeren of updaten van een plugin die direct output genereert.

Ook andere codefouten kunnen sessieproblemen veroorzaken. Bijvoorbeeld, een verkeerd ingestelde header, een conflict tussen twee plugins, of zelfs een PHP‑fout die de loginroutine onderbreekt. Dit zijn wat lastigere oorzaken om te traceren, maar ze komen zeker voor.

Voorbeeld: je hebt handmatig een regel code toegevoegd in wp-config.php of een themafunctie, en vanaf dat moment treedt de cookie‑fout op bij inloggen. Waarschijnlijk veroorzaakt die aanpassing onbedoeld vroege output of een conflict dat het zetten van cookies dwarsboomt. In zo’n geval is de “gebroken” code de boosdoener, niet je browser. Het tijdelijk terugzetten van de wijziging of het activeren van een standaardthema kan bevestigen of het daaraan lag.

Domein-, SSL‑ of serverconfiguratie (website verhuizing e.d.)

Tenslotte kunnen server‑ of configuratieproblemen rondom je domein en URL leiden tot geblokkeerde cookies. WordPress login‑cookies zijn domeingebonden. Als de site‑URL of domein recent is gewijzigd, of je hebt de site verhuisd naar een andere server terwijl de domeinnaam gelijk bleef, kunnen er conflicten ontstaan tussen bestaande cookies en de nieuwe omgeving. Bijvoorbeeld, je oude cookies in de browser verwijzen naar een bepaalde pad of domeinnaam die nét anders is dan wat de nieuwe WordPress‑install verwacht, waardoor de nieuwe cookie niet juist wordt gezet of gelezen.

Veelvoorkomende issues na een site‑migratie zijn: onjuiste cookie‑paden, verkeerde domein‑instellingen, of veranderingen in SSL (HTTP → HTTPS) die het cookiegedrag beïnvloeden. Als je bijvoorbeeld je site van http naar https hebt gezet, markeert WordPress de login‑cookie voortaan als “secure” (alleen te accepteren via HTTPS). Probeer je echter nog via http in te loggen, dan accepteert de browser die secure cookie niet — resultaat: login faalt. Andersom kan ook: als de site op https draait maar ergens in de config nog http verwacht wordt, kan het misgaan. In WordPress Multisite‑installaties met domeinmapping komt deze fout ook boven water: wanneer een subsite een eigen domein krijgt, moet de cookie‑instelling daarop aangepast worden. Zo niet, dan “ziet” WordPress de cookie niet op het nieuwe domein en blijf je de foutmelding krijgen.

Ook kan een reverse proxy, load balancer of speciale servercache de cookie‑header strippen of niet doorlaten, zij het minder vaak. En het gebruik van sommige VPN‑ of proxy‑verbindingen bij het inloggen zou roet in het eten kunnen gooien (bijvoorbeeld als je bedrijf een proxy heeft die cookies filtert, of als je IP per verzoek wisselt via een VPN, wat sommige beveiligingsinstellingen van WordPress verwarrend vinden).

Voorbeeld: je hebt je site verhuisd naar een nieuwe hostingpartij maar houdt dezelfde domeinnaam. Na de migratie kun je niet meer inloggen — elke poging resulteert in de cookie‑fout, ondanks dat cookies in de browser gewoon aan staan. Waarschijnlijk zoekt de WordPress‑cookie nog naar iets van de oude omgeving. Het wissen van oude browsercookies kan in zo’n geval helpen, zodat een “schone” login mogelijk wordt. Een ander voorbeeld: je schakelt SSL in en vanaf dat moment krijg je de melding bij login. In dat geval moet je zorgen dat je daadwerkelijk via https inlogt en dat de WordPress‑instellingen (WP_SITEURL/WP_HOME) overeenkomen met de URL die je gebruikt. Als er een mismatch is, blokkeert dat de cookie.

Oplossingen: hoe krijg je het inloggen weer werkend?

Nu ik de mogelijke oorzaken heb besproken, is de vraag: wat kun je als beheerder doen om dit op te lossen? Omdat het probleem per situatie anders kan zijn, gaat het hier vooral om systematisch uitzoeken waar de knel zit. Hieronder enkele aanwijzingen en oplossingsrichtingen op hoofdlijnen (niet elke stap zal altijd nodig zijn):

• Controleer je browserinstellingen: Zorg dat jouw browser cookies toestaat voor jouw WordPress‑site. Probeer een harde refresh (Ctrl+F5 / Cmd+Shift+R) op de inlogpagina en wis eventueel de browsercache en cookies voor je site. Log daarna opnieuw in. Als je een privacy‑extensie of adblocker gebruikt, schakel deze dan tijdelijk uit en probeer het nogmaals. Ook kun je testen in een andere browser of in incognito‑modus (let op: incognito wist cookies na afloop, maar zou het inloggen op zich niet moeten blokkeren). Werkt het in de ene browser wel en de andere niet, dan zit het euvel hoogstwaarschijnlijk in de browserinstellingen of ‑extensies van die ene browser. Pas de instellingen aan om cookies toe te staan (voor eerste‑partij‑sites), en probeer opnieuw in te loggen.
• Schakel beveiligings- en cache‑plugins (tijdelijk) uit: Denk terug of het probleem optrad na het activeren of updaten van een plugin (vooral security of caching). Zo ja, deactiveer die plugin tijdelijk en test het inloggen opnieuw. Omdat je niet in het dashboard kunt, kun je dit doen via FTP of het hosting‑controlepaneel door de pluginmapnaam te hernoemen (bijv. wordfence → wordfence_old om Wordfence uit te schakelen). Lukt inloggen daarna wel, dan weet je dat de plugin de boosdoener was. Meld het probleem eventueel bij de plugin‑ontwikkelaar zodat zij een oplossing kunnen bieden. Voor caching‑plugins geldt: wis de cache en kijk of dat verschil maakt, of zet de plugin tijdelijk uit. Ook kun je overwegen of je een cookie‑consent‑plugin hebt die ingrijpt; sta cookies toe via die plugin (voor jezelf) of test met die uit. Let op: vergeet niet uitgeschakelde beveiligingsplugins weer te activeren of te vervangen zodra je klaar bent, want je wilt je site niet onnodig lang onbeveiligd laten draaien.
• Test met een standaardthema en controleer custom code: Om uit te sluiten dat je actieve thema of aangepaste code het probleem veroorzaakt, kun je tijdelijk overstappen op een WordPress‑standaardthema (bijv. Twenty Twenty‑xx) of je huidige thema uitschakelen (bijvoorbeeld door de themamap te hernoemen via FTP). Probeer opnieuw in te loggen. Als dit lukt, zit er een fout in je vorige thema (mogelijk een stukje code dat cookies verstoort). Je zult dan dat thema moeten debuggen — denk aan recente wijzigingen, extra spaties of regels buiten <?php ?>‑tags, etc. Datzelfde geldt voor eventuele code‑snippets in wp-config.php of mu‑plugins: verwijder of comment die tijdelijk en kijk of inloggen weer mogelijk is. Het idee is om alle custom code die vroeg in het laadproces draait, te inspecteren. Eén rogue spatie of BOM‑karakter kan al het verschil maken tussen wel of niet kunnen inloggen.
• Controleer site‑adres, cookies en serverinstellingen: Ga na of je recente wijzigingen aan de site‑URL, domeinnaam of SSL‑configuratie correct hebt doorgevoerd. Kijk in de database of in wp-config.php of WP_HOME en WP_SITEURL kloppen met de URL die je gebruikt om in te loggen. Inconsistente URL’s (bijv. WordPress ingesteld op https://jouwdomein.nl maar je probeert via http:// in te loggen) leiden tot cookieproblemen. Zorg dat je de juiste URL gebruikt (liefst altijd via HTTPS indien ingesteld). Bij multisite/domain‑mapping: check of de domain mapping goed staat; zo niet, pas dit aan — in sommige gevallen is het nodig om de cookie‑domain‑instelling uit te schakelen zodat WordPress cookies accepteert op het nieuwe domein. Verder, als je de site verhuisd hebt: verwijder de oude cookies in je browser voor dat domein en probeer opnieuw. Dit voorkomt dat een oud cookie in de weg zit. Tot slot, controleer of er geen bijzondere server‑headers of proxies zijn die cookieverkeer beïnvloeden (dit is zeldzaam, maar bijvoorbeeld een verkeerde HTTP‑response header of strikte beveiligingsmodule op de server kan theoretisch de Set-Cookie‑header blokkeren). In normale gevallen hoef je hier niks aan te passen, maar het is goed om te weten als alles anders faalt.

Door deze stappen systematisch te doorlopen, vergroot je de kans om de oorzaak te vinden zonder meteen diep in de code te hoeven duiken. Meestal kom je met rustig elimineren van factoren — eerst de browser, dan plugins, dan thema/code, dan serverconfig — achter het probleem en kun je het verhelpen.

Conclusie

Een loginprobleem met de melding dat cookies geblokkeerd zijn, kan in eerste instantie erg frustrerend zijn, maar met inzicht in hoe WordPress met cookies omgaat is het gelukkig vaak oplosbaar. Ik heb laten zien dat cookies cruciaal zijn voor de “sessie” van een ingelogde gebruiker, en dat allerlei factoren — van browserinstellingen tot plugin‑gedrag en serverconfig — kunnen zorgen dat die cookies niet goed werken. Door stap voor stap te controleren waar het misgaat (beginnend bij je browser en eindigend bij de serverinstellingen) kun je meestal het euvel vinden en verhelpen. Het belangrijkste is om rustig te blijven en de logica te volgen: WordPress wil een cookie zetten; waar wordt dat tegengehouden? Zodra je dat weet, kun je gericht actie ondernemen.