Waarom je niet kunt inloggen in WordPress

"Ik kan niet inloggen" is een paraplu voor een stuk of tien verschillende problemen die toevallig hetzelfde voelen. Het wachtwoordveld weigert je, of accepteert je en gooit je meteen weer terug, of je krijgt een wit scherm. Vanuit de browser lijken ze op elkaar, maar onder de motorkap zijn het andere problemen met andere oplossingen. Dit artikel is het routeringspunt voor de hele login-subcategorie: ik leg het inlogmechanisme uit op het niveau dat je nodig hebt om te herkennen wat er misgaat, en verwijs je per symptoom door naar het juiste vervolg.

Wat "niet kunnen inloggen" eigenlijk betekent

Met "niet kunnen inloggen" bedoel ik elke situatie waarin je op wp-login.php je gegevens invult en niet eindigt met een werkende sessie in wp-admin. Dat dekt drie hele verschillende dingen: geweigerde inloggegevens, geaccepteerde inloggegevens die niet blijven plakken, en gevallen waarin de inlogpagina zelf niet eens opent. Die drie op één hoop gooien is de belangrijkste reden dat mensen uren bezig zijn met de verkeerde oplossing.

Hoe WordPress-login eigenlijk werkt

De login van WordPress is een kleine pipeline en bijna elk probleem in deze subcategorie valt toe te wijzen aan één stap die breekt. Het startpunt is wp_signon(), en die doorloopt vier stappen:

1. Controle van de inloggegevens. wp_signon() roept wp_authenticate() aan en die vergelijkt je gebruikersnaam en wachtwoord met de wp_users-tabel. Klopt de hash niet, dan krijg je de melding ERROR: The password you entered is incorrect. Bestaat de gebruiker niet, dan krijg je een onbekende-gebruikersnaamfout. Dit is de stap die de meeste mensen bedoelen als ze zeggen "inloggen".
2. Cookies zetten. Bij een match roept WordPress wp_set_auth_cookie() aan en schrijft drie cookies in je browser: wordpress_[hash] voor /wp-admin/, wordpress_sec_[hash] als de site op HTTPS draait, en wordpress_logged_in_[hash] voor de hele site. De exacte namen en scopes staan in de WordPress-handleiding. Zonder die cookies heeft de browser geen manier om bij de volgende request te bewijzen dat jij net bent ingelogd.
3. Redirect naar het dashboard. WordPress stuurt een HTTP-redirect naar wp-admin/. De browser volgt die en stuurt de net ontvangen cookies mee. Klopt het cookie-domein niet met het domein waar je landt, of kwamen de cookies nooit aan, dan ziet WordPress een anonieme request en stuurt hij je gewoon terug naar wp-login.php.
4. De wp_login-actie vuurt. De wp_login-hook draait bij een succesvolle login en wordt door plugins gebruikt om de gebeurtenis te loggen, notificaties te sturen, of eigen checks te doen.

Elk login-probleem waar ik je naartoe ga sturen zit in exact één van die vier stappen, of in de laag eronder (je browser, de webserver, of het netwerk ertussen).

De drie categorieën waarin elk login-probleem valt

Ik deel login-problemen in drie categorieën: account, sessie en omgeving. Die splitsing is handig omdat elke categorie een ander diagnosepad heeft en naar een andere set vervolgartikelen wijst.

Account

Accountproblemen zitten in stap 1 van de pipeline. De controle van de inloggegevens zelf faalt, of een beveiligingslaag blokkeert de poging vóórdat hij bij die controle aankomt. WordPress toont vrijwel altijd een expliciete foutmelding op het inlogscherm. Krijg je een duidelijke melding terug, dan zit je in deze categorie.

Typische gevallen: je wachtwoord klopt echt niet, je IP is tijdelijk geblokkeerd door een beveiligingsplugin na te veel mislukte pogingen, of je wachtwoord-reset-mail komt niet aan. Voor een wachtwoord dat zou moeten kloppen maar niet werkt, begin bij wachtwoord-reset werkt niet in WordPress. Komt de reset-mail niet aan, dan is het probleem e-mailbezorging en geen login: zie WordPress verstuurt geen e-mail.

Sessie

Sessie-problemen zitten in stap 2 en 3. De authenticatie slaagt (WordPress heeft je wachtwoord goedgekeurd), maar het cookie-rondje mislukt, waardoor je volgende request er anoniem uitziet en WordPress je terugstuurt naar het inlogscherm. Het kenmerk is dat je géén "wachtwoord fout"-melding krijgt. Er gebeurt iets anders: de pagina ververst, je komt zonder melding terug op wp-login.php, of de browser klaagt over te veel redirects.

Typische gevallen: cookies worden geblokkeerd of staan op een domein dat niet klopt met de URL waar je landt, een full-page cache strippt de wordpress_logged_in_[hash]-cookie, of WP_HOME en WP_SITEURL wijzen naar verschillende adressen en sturen de browser door een redirect die de cookie kwijtraakt. De twee artikelen om hier te lezen zijn cookies zijn geblokkeerd of worden niet ondersteund in WordPress en WordPress login redirect loop. Als het dashboard wel begint te laden maar halverwege blijft hangen, lees dan WordPress-admin blijft laden na inloggen.

Omgeving

Omgevingsproblemen zitten onder de pipeline. De login-code van WordPress krijgt niet eens de kans om te draaien, omdat iets ervoor (een webserverregel, een WAF, een hostingrestrictie, een plugin die de login-URL verplaatst) de request onderschept. Het duidelijkste teken is dat je helemaal geen WordPress-scherm ziet. Je krijgt een HTTP 403 Forbidden, een blanco pagina, of een inlogvenster van een ander systeem.

Typische gevallen: de host heeft wp-admin beperkt tot specifieke IP-adressen, een WAF-regel blokkeert de POST naar wp-login.php, of een plugin als WPS Hide Login heeft de login-URL verplaatst en jij probeert nog de oude. Lees 403 Forbidden op wp-admin voor een weigering aan de serverkant, of geen toegang tot wp-admin zonder foutmelding als er geen foutmelding is om mee te werken. Lukt het inloggen wel, maar krijg je daarna "Je hebt geen toestemming om deze pagina te bekijken", dan zit je technisch gezien in een rechten-check binnen WordPress en niet in een login-probleem: daar hoort Sorry, you are not allowed to access this page in WordPress oplossen bij.

Wat "niet kunnen inloggen" níet is

Deze sectie voorkomt het meeste verspilde zoekwerk.

• Het is op zichzelf geen wachtwoord-reset-probleem. Als de knop "Wachtwoord vergeten" geen mail stuurt, is er met de login-pipeline niks mis. Je hebt een bezorgprobleem met e-mail. Lees wachtwoord-reset werkt niet in WordPress en een laag dieper WordPress verstuurt geen e-mail.
• Het is geen database-probleem. Kan WordPress helemaal niet bij de database, dan krijg je een specifiek foutscherm, geen login-fout. Dat is een ander symptoom met een andere oplossing: zie fout bij het maken van verbinding met de database.
• Het is niet per se een security-incident. De meeste mensen die hier terechtkomen denken dat ze gehackt zijn. Meestal is dat niet zo. Een cache-laag, een domein-mismatch na een HTTPS-migratie of een vergeten WPS Hide Login-slug dekken veruit de meeste gevallen. Behandel het symptoom eerst als configuratieprobleem en stap pas over op incident response als je écht aanwijzingen voor een inbreuk vindt. Wil je het inlog-endpoint proactief verharden, dan dekt de WordPress-beveiligingschecklist 2FA, brute-force-bescherming en wachtwoordhygiëne.
• Het is niet hetzelfde als een rechten-melding ná het inloggen. "Sorry, je hebt geen toestemming om deze pagina te bekijken" betekent dat WordPress je wél geauthenticeerd heeft en je daarna een specifiek scherm weigert. De login is dus gelukt. Je loopt tegen een capability-check aan, niet tegen een login-check, en de oplossing is compleet anders.

Waar je nu heen moet

Weet je al in welke van de drie categorieën je probleem valt, volg dan de links hierboven en werk van daar verder. Weet je het nog niet zeker, begin dan bij het symptoom: laat het inlogformulier een specifieke foutmelding zien (account), gooit het formulier je stilletjes terug of raak je in een redirect-loop (sessie), of kom je überhaupt niet bij een WordPress-scherm (omgeving)? Met dat ene vraagstuk zit je binnen één klik in het juiste artikel, en dat artikel loopt je dan de rest van het probleem door.