"I cannot log in" covers a dozen different failure modes that happen to produce the same feeling. The username/password box rejects you, or accepts you and then throws you right back, or the whole dashboard goes white. These look similar from the browser, but underneath they are different problems with different fixes. This article is the routing hub for the whole login subcategory: it explains the login mechanism at the level you need to recognize what is going wrong, and it points you to the specific article for your symptom.
What "cannot log in" actually means
When I say "cannot log in to WordPress", I mean any state where you enter credentials at wp-login.php and do not end up with a working session inside wp-admin. That covers rejected credentials, accepted credentials that do not stick, and situations where the login page itself never loads or never responds. These are three very different failure modes, and treating them as one problem is the single biggest reason people spend hours on the wrong fix.
How WordPress login actually works
WordPress login is a small pipeline, and almost every problem in this subcategory maps to one step breaking down. The canonical entry point is wp_signon(), which runs in four stages:
- Credential validation.
wp_signon()callswp_authenticate(), which checks the username and password against thewp_userstable. If the password hash does not match, you getERROR: The password you entered is incorrect. If the user does not exist, you get an unknown-username error. This is the step most people think of as "login". - Cookie issuance. On a successful match, WordPress calls
wp_set_auth_cookie(), which writes three cookies into your browser:wordpress_[hash]scoped to/wp-admin/,wordpress_sec_[hash]when the site runs on HTTPS, andwordpress_logged_in_[hash]scoped to the whole site. The exact names and scopes are documented in the WordPress handbook. Without these cookies, the browser has no way to prove on the next request that you are the person who just authenticated. - Redirect to the dashboard. WordPress issues an HTTP redirect to
wp-admin/. The browser follows it and sends back the cookies it just received. If the cookie domain does not match the domain you land on, or if the cookies never arrived, WordPress sees an anonymous request and sends you back towp-login.php. wp_loginaction fires. Thewp_loginhook runs on a successful login and is what plugins use to record the event, send notifications, or run their own checks.
Every login problem I will route you to sits in exactly one of those four steps, or in the layer underneath them (the browser, the server, or the network between them).
The three categories every login problem falls into
I group login problems into account, session, and environment. That split is useful because each category has a different diagnostic path, and each category has a different set of siblings to read.
Account
These problems sit at step 1 of the pipeline. The credential check itself is failing, or a security layer is blocking the attempt before it reaches the check. WordPress almost always shows an explicit error on the login screen. If you see the form reject you with a message, you are in this category.
Common cases: the password is genuinely wrong, your IP has been temporarily blocked by a security plugin after too many failed attempts (see brute force attack protection in WordPress for tuning or temporarily relaxing those limits), or your password reset email never arrives. For a wrong password that should be right, start with password reset not working in WordPress. If the reset email never arrives, the problem is usually mail delivery, not login: see WordPress not sending email.
Session
Session problems sit at steps 2 and 3. Authentication succeeds (WordPress validated your password) but the cookie round-trip fails, so your next request looks anonymous and WordPress bounces you back to the login screen. The giveaway is that you do not see a "wrong password" error. Something else happens: the page refreshes, you end up back at wp-login.php with no message, or the browser complains about too many redirects.
Common cases: cookies are blocked or scoped to a domain that does not match the URL you landed on, the wordpress_logged_in_[hash] cookie is being stripped by a full-page cache, or WP_HOME and WP_SITEURL disagree and send the browser through a redirect that loses the cookie. The two sibling articles to read here are cookies are blocked or not supported in WordPress and WordPress login redirect loop. If the dashboard loads partially and then stalls, read WordPress admin stuck loading after login.
Environment
Environment problems sit underneath the pipeline. The WordPress login code never even gets a chance to run, because something in front of it (a web server rule, a WAF, a hosting restriction, a plugin that rewrites the login URL) is intercepting the request. The telltale sign is that you do not see a WordPress screen at all. You see an HTTP 403 Forbidden, a blank page, or a login form from a different tool.
Common cases: the host has locked wp-admin to specific IP addresses, a WAF rule is blocking the POST to wp-login.php, or a plugin like WPS Hide Login has moved the login URL and you are hitting the old one. Read 403 Forbidden on wp-admin for the server-side refusal, or no access to wp-admin without an error when there is no error to work with. If you successfully log in but then hit "Sorry, you are not allowed to access this page", that is technically a permissions message inside WordPress, and it has its own article: Sorry, you are not allowed to access this page in WordPress.
What "cannot log in" is NOT
This is the section that prevents most wasted debugging time.
- It is not a password reset problem on its own. If clicking "Forgot password" does not send you an email, the login pipeline is fine. You have an email delivery problem. Read password reset not working in WordPress and, one layer down, WordPress not sending email.
- It is not a database connection problem. If WordPress cannot reach the database at all, you get a specific error screen, not a login failure. That is a different symptom with a different fix: see error establishing a database connection.
- It is not necessarily a security breach. Most people arriving here assume they have been hacked. Usually they have not. A cache layer, a domain mismatch after an HTTPS migration, or a forgotten WPS Hide Login slug accounts for the overwhelming majority of cases. Treat the symptom as a configuration problem first, and only move to incident response if you find actual evidence of a breach. If you do want to harden the login endpoint proactively, the WordPress security hardening checklist covers 2FA, brute-force protection, and credential hygiene.
- It is not the same as a permissions error after login. "Sorry, you are not allowed to access this page" means WordPress authenticated you successfully and then refused to show a specific screen. The login worked. You are hitting a capability check, not a login check, and the fix is completely different.
Where to go next
If you already know which of the three categories fits your symptom, follow the links above into the sibling article and work from there. If you are still not sure, start from the symptom: does the login form show you a specific error message (account), does the form silently bounce you back or throw a redirect loop (session), or do you never reach a WordPress screen at all (environment)? That single question will put you in the right article within one jump, and the right article will walk you the rest of the way.