Su questa pagina: [nascondere]
WordPress prints two different “cookies are blocked” errors on the login screen. One means your browser refused a cookie. The other means your server printed something before WordPress could set one. They sit eleven lines apart in the same core file. They need opposite repairs, and almost every guide treats them as one error. So the first move is not clearing your cache. It’s reading the sentence on your screen, parola per parola.
Risposta rapida: Match the exact error text to the fix. “Cookies are blocked or not supported by your browser” is your browser, so retry in a private window. “Cookies are blocked due to unexpected output” is your server, so rename the plugins folder over FTP. A blank page, o “There has been a critical error on this website”, is neither. Check the admin inbox for a WordPress recovery mode email before you touch a file. Landing back on the login form with no error at all usually means your site URL changed.
Ultima revisione: settembre 2026. Error strings, cookie constants and password-hashing behavior were read from the WordPress core source on 8 settembre 2026. Versioni dei plugin, install counts and release dates came from the WordPress.org plugin API and SVN tags on the same day.
The Files These Answers Came From
Login guides copy each other, and the copies drift. This one was built by reading the code that produces the errors. Four core files were pulled from the WordPress master branch on 8 settembre 2026:
- wp-login.php for the exact error strings and the conditions that trigger them
- pluggable.php for how passwords are checked and how login cookies get set
- default-constants.php for the cookie names and the memory defaults
- user.php for reset-key expiry and the rehash that runs after a successful login
Every behavior described below traces back to one of those four. Plugin figures came from the WordPress.org plugin information API. Release dates came from SVN tag headers rather than vendor blog posts. A blog post announces a version; a tag header records when it shipped.
Two rules decided what got in. Any fix that only exists inside one host’s control panel was left out, since it doesn’t help a reader on a different host. Any trick that couldn’t be traced to a line of core or plugin source was left out too, however often it appears elsewhere.
What this guide didn’t do: run these failures on a live crashed site. Nothing here is a hands-on repair log. The bigger gap is server configuration. Hosts run their own firewall rules in front of WordPress. From outside, you can’t verify which requests a host blocks before PHP even loads. That section names the symptom and tells you what to ask your host, which is as far as the evidence goes.
Start With What the Screen Says
Eight things commonly break WordPress logins. The screen usually tells you which one, if you read it before reaching for a fix.
- An error mentioning cookies, and you’re still on the login form: the wording splits this into two different problems. Cookie errors.
- No error at all, the page just reloads or bounces you between wp-login.php and wp-admin: the login loop.
- A blank white page, o “There has been a critical error on this website”: fatal error.
- A lockout or 2FA prompt you can’t get past: plugin lockout.
- UN 404 on /wp-admin or on /wp-login.php: the login page moved.
- No reset email, o “the username is not registered”: reset it yourself.
- UN 403, 503 or timeout before the form even loads: il server, non WordPress.
- Your admin account is missing, or there’s a user you didn’t create: non un bug.
The Two Cookie Errors That Mean Opposite Things
Here’s the part that decides your next hour. After you submit the form, core checks whether the logged-in cookie came back. If it didn’t, WordPress picks one of two messages based on a single test: headers_sent().
Had PHP already sent output when WordPress tried to set the cookie? Then you get “Cookies are blocked due to unexpected output“. This is a server-side fault, and your browser is innocent. Something in your own code printed characters before the HTTP headers finished. In practice it’s one of three things. A blank line after the closing ?> in a theme’s functions.php. A stray space at the top of a plugin file. Or a UTF-8 byte order mark, saved by an editor that never asked.
Clearing cookies does nothing here. You need to find the file that’s talking too early. Rinominare /contenuto wp/plugin per plugins-off over FTP and reload the login page. If the error clears, rename the folder back and disable plugins one at a time until it returns.
If headers hadn’t been sent and the test cookie simply never came back, hai capito “Cookies are blocked or not supported by your browser“. That one really is your browser, or something sitting between you and the site. Try a private window first. A private window starts with no cookies at all and takes ten seconds. Se funziona, clear cookies for that domain in your normal profile and you’re done. In caso contrario, look at browser extensions, una VPN, or network filtering at your office.
The distinction matters more than it sounds. The browser-side error is fixed in under a minute with no file access at all. The server-side error needs FTP or SSH and a hunt through plugin files, and cache clearing will never move it. Reading eight words saves you from doing the second job when you needed the first.
Use this section when the word “cookies” appears anywhere on screen. If there’s no error text at all, you want the login loop anziché.
The Login Loop: Your Cookie Name Is a Hash of Your Site URL
You type the right password, the page reloads, and you’re back on the login form with nothing to read. Nessun errore, no lockout, no clue. The mechanism behind this is one line in core, and once you’ve seen it the fix is obvious.
WordPress doesn’t give your login cookie a fixed name. It builds the name from a constant called COOKIEHASH, and COOKIEHASH is md5 of your siteurl option. The auth cookie becomes wordpress_ plus that hash. The logged-in cookie becomes wordpress_logged_in_ plus the same hash. So the moment your siteurl changes, WordPress starts looking for a cookie with a different name than the one already in your browser. It finds nothing, decides you aren’t logged in, and sends you back to the form. Per sempre.
Four changes trigger this, and all four look harmless at the time:
- Switching from http to https
- Adding or dropping the www
- Moving the site to a new domain
- Adding a trailing slash to one of the two URL fields
WordPress stores siteurl e casa in the wp_options table. They need to match each other exactly, character for character. You can’t fix that in the dashboard, because you can’t get into the dashboard. Force the values in wp-config.php instead, just above the “interrompere la modifica” comment:
- definire( ‘WP_HOME’, 'Https://example.com’ );
- definire( 'WP_SITEURL', 'Https://example.com’ );
Pick the exact scheme and host you actually serve. These constants override the database rows without changing them, so they’re safe to try and trivial to undo. They also reach further than most guides admit. Core filters them into the siteurl option before it builds COOKIEHASH, so the constant fixes the cookie name too, not just the redirects. A trailing slash on the constant is harmless, because core strips it. A trailing slash in the database row is not.
Expect one side effect. Changing that value changes the cookie name for everybody, so every logged-in user gets signed out. That’s the fix working, not a second problem. I nostri guide to editing wp-config.php safely covers where the file sits and what else belongs in it. Once you’re back in, set Settings > General to match, then delete the two lines.
Two more loop causes are worth checking if the URLs already matched. A corrupted .htaccess can rewrite wp-admin requests into a circle. Rename it to .htaccess-old and try again; if the login works, WordPress writes a clean one when you re-save your permalinks. Sites behind a reverse proxy or CDN have a second trap. FORCE_SSL_ADMIN bounces you between http and https when the proxy doesn’t pass the protocol header through.
One symptom looks like the loop but isn’t: logging in fine, then getting kicked out again an hour later. WordPress sets the auth cookie to 2 giorni, o 14 days when you tick “Remember Me”. Sessions shorter than that point at a security plugin or an object cache, not at a URL mismatch. Worth knowing which one you’re in, because the price gap is real. This fix is two lines in wp-config.php. The unexpected-output error costs you an FTP session and a plugin-by-plugin hunt.
This is your section if the loop began after a domain, SSL or URL change. Been on the same URL for a year, and the loop started after a plugin update? Un plugin is the likelier culprit.
Blank Page or “There Has Been a Critical Error”
Start with the good news, because a lot of people don’t know this exists. Da WordPress 5.2, a fatal error doesn’t just white-screen you. Core catches it, emails the site’s admin address, and that email carries a secret link into recovery mode. Click it and WordPress pauses the plugin or theme that crashed, for your browser only, and lets you into the dashboard to remove it. Visitors keep seeing the error page while you work. It’s the fastest fix on this list, and it needs no FTP at all.
So check that inbox before anything else, spam folder included. Two things break this for a lot of sites. The admin address is a mailbox nobody reads. Or the site can’t send mail in the first place. You can point future alerts somewhere better with definire( ‘RECOVERY_MODE_EMAIL’, ‘[email protected]’ ); in wp-config.php, though that only helps for the next crash. If no email ever arrives from your site, the real problem is deliverability. La nostra ripartizione di why WordPress stops sending email covers the nine causes behind it.
Nessuna e-mail, no recovery link? Then find out what actually crashed. Inserisci definire( ‘WP_DEBUG’, vero ); e definire( ‘WP_DEBUG_LOG’, vero ); to wp-config.php, reload the login page, and read /wp-content/debug.log. The last few lines will name a file, and that file’s folder is your culprit. Rename that plugin’s folder over FTP and WordPress deactivates it on the next load.
If the log points at memory rather than a plugin, the numbers are lower than people assume. WordPress sets WP_MEMORY_LIMIT to 40M by default, or 64M on multisite, and raises the admin side to 256M. A heavy plugin stack can exhaust 40M on the login request alone. Aggiunta definire( ‘WP_MEMORY_LIMIT’, ‘256M’ ); is a legitimate test. Treat the result as a diagnosis rather than a cure, because something is using far more than it should.
One popular piece of advice to ignore. Guides still recommend the Health Check plugin for isolating a conflict without breaking your live site, and on paper it’s the right tool. Its last release was version 1.7.1 sopra 25 luglio 2024. It declares compatibility only up to WordPress 6.6.7, and it still carries 200,000 installazioni attive. That’s three major WordPress versions behind, on a plugin whose whole job is manipulating which plugins load. Renaming a folder over FTP is cruder and safer.
Work here when you see a WordPress error page or nothing at all. A login form that renders correctly rules this out, because PHP got through the request.
Your Security Plugin Locked You Out
The tools that protect wp-login.php are also the ones most likely to lock out the person who installed them. Know the scale before you assume a core bug. Wordfence sits on 5 milioni di siti. Limit Login Attempts Security and Loginizer run on 1 million each, and Kadence Security on 700,000. On a typical install, one of these is between you and your dashboard.
Which raises a naming problem that has confused people all year. Hunting for Solid Security in your plugins list and can’t find it? Solid Security became Kadence Security in version 10.0.0, tagged on 12 Maggio 2026, after Liquid Web retired the StellarWP brand. The plugin folder is still called better-wp-security, the name it carried as iThemes Security before that. Three brands, one folder.
The same version series carries a bug worth naming, because it causes exactly the failure this article is about. Kadence Security 10.0.1, tagged on 12 Maggio 2026, fixed a race condition in the plugin’s file writer that could empty wp-config.php or .htaccess. An empty wp-config.php doesn’t just lock you out of the login page. It takes down the whole site, database credentials and all. And it looks nothing like a plugin problem while you’re staring at it.
Recovery is the same for all of them, and it doesn’t require guessing a lockout table name. Connect over FTP or SSH, Aperto /contenuto wp/plugins/, and rename the offending folder, così wordfence diventa wordfence-off. WordPress can no longer find the plugin file, deactivates it silently, and the lockout goes with it. Accesso, rename the folder back, then reconfigure before you reactivate.
Two-factor lockouts follow the same path with one step in front. Look for the recovery codes you were given at setup. Check your password manager first, because that’s a thirty-second fix against a five-minute one. No codes? Rename the 2FA plugin’s folder. Is your 2FA bundled inside a security suite rather than a standalone plugin? Renaming the suite’s folder drops the lockout and the second factor at once.
Start here when you see a countdown, a lockout message or a 2FA prompt. A password that’s accepted before the page reloads clean is the loop, not a lockout.
The Login Page That Moved
UN 404 on /wp-admin is a different animal from a login that fails. Nothing crashed. The door was moved and nobody wrote down where.
WPS Hide Login runs on 2 million sites and does one job. It changes your login URL, so bots hitting /wp-login.php find nothing. That works well right up to the day you need the URL and can’t remember it. (That day always seems to land on a Sunday.) Recovering it takes one lookup, because the plugin stores the slug in plain text. Open phpMyAdmin, vai al wp_opzioni tavolo, and search option_name for whl_page. The value in that row is your login slug. Your login URL is your site URL, a slash, and that value.
Rather not touch the database? Renaming /wp-content/plugins/wps-hide-login/ over FTP restores /wp-login.php immediately, same as any other plugin. The database lookup is the better option when you want the URL back rather than the plugin gone. Compare that with the security lockouts above, where renaming the folder is the entire fix. Here it’s the blunter of two choices.
Also check that nobody renamed wp-login.php itself, or added an .htaccess rule restricting wp-admin to a fixed IP address. IP allowlists on wp-admin are common on agency-built sites. They break the day the client’s home connection gets a new address.
Go here for a 404 or your host’s error page instead of a WordPress screen. If the form loads at all, the file is exactly where WordPress expects it, so look elsewhere.
Resetting the Password When the Email Never Comes
The reset link has a shelf life most people don’t expect. WordPress expires a password reset key after 24 ore per impostazione predefinita. So a link sitting in your mailbox from last week is dead. Il “your password reset link has expired” message that follows sends people hunting a fault that isn’t there. Request a fresh one first.
Before touching the database for any of what follows, take a backup. Not a plugin backup you assume exists, but an actual copy of the wp_users table you can restore in one paste. I nostri WordPress backup guide covers doing that properly, and a database export takes about two minutes in phpMyAdmin.
With SSH access, WP-CLI is the fastest route and the one to prefer. It goes through WordPress’s own hashing rather than around it. Correre wp user update admin –user_pass=”your-new-password” from the site root, substituting your username. It works no matter how broken the dashboard is, and it can’t write a malformed hash.
Senza SSH, the phpMyAdmin route still works, and there’s a 2026 wrinkle other guides get wrong in both directions. Su 15 aprile 2025, WordPress 6.8 switched password hashing from phpass to bcrypt. Passwords written after that date carry a $wp$2y$ prefix instead of the old $P$. Some guides now claim the classic phpMyAdmin trick is dead because of it. Non lo è. Core’s password check still has a branch for any hash of 32 characters or fewer, which compares it as a plain MD5. So the old routine still works on WordPress 7.1. Edit the user_pass row in wp_users, pick MD5 from the function dropdown, and type your new password.
What’s changed is what happens next. On your first successful login, core notices the hash is outdated and quietly rewrites it as bcrypt. Your MD5 row exists for exactly one login, then upgrades itself. That’s the detail to take away. The weak hash is a doorway, not a state you’re leaving your site in. Just don’t stop at the doorway: set a real password from Users > Profile once you’re inside.
Your section when the reset email never arrives, or the account itself looks healthy. Cookie errors and lockouts don’t care what your password is, so a reset fixes neither.
When the Block Is Your Server, Not WordPress
Some login failures never reach PHP. If the form doesn’t load at all, WordPress isn’t involved. Same goes if submitting it returns a bare 403 from your host rather than a WordPress screen. No amount of plugin renaming will help either one.
The usual cause is a firewall rule in front of the application. Most shared hosts run ModSecurity or an equivalent, and a POST to wp-login.php containing an unusual character can trip a generic rule. You’ll see a plain 403, sometimes with a reference ID. That ID is the whole conversation with support: give it to them and ask which rule fired.
Caching is the second suspect. Server-level page caches are meant to exclude wp-login.php automatically. When that exclusion breaks, the login page gets served from cache with a stale nonce. It submits, and it fails silently.
One error belongs to neither list. “errore nello stabilire una connessione col database” isn’t a login fault at all, because it shows on every page of the site. Check the credentials in wp-config.php, then ask your host whether the database server is up.
Then there’s the certificate, quietly becoming the more common one. Let’s Encrypt stopped sending expiry emails sopra 4 giugno 2025, so a renewal that fails now fails in silence. Chrome is closing the gap from the other side. Cromo 147 acceso “Utilizza sempre connessioni sicure” per gli utenti di Navigazione sicura avanzata nel mese di aprile 2026. Cromo 154 makes it the default for everyone in October 2026. A site with a dead certificate stops being a warning you can click past and becomes a wall. Does your login page throw a browser security screen rather than a WordPress one? Our walkthrough of il “la tua connessione non è privata” errore separates a bad certificate from a bad device clock.
One test tells you which side to work on. Load the login page in a private window on mobile data, off your home network entirely. If it loads there, the block is local to you: an IP ban, your ISP, or your own security software. If it fails there too, it’s the server, and that’s a support ticket rather than a file edit.
Come here when you never see a WordPress screen at all. A WordPress-worded error means the request reached PHP, so work the sections above instead.
When It Isn’t a Bug
Sometimes nothing is broken and the login works exactly as designed. It’s just no longer designed for you.
Three signs point this way rather than at any fix above:
- Your admin account no longer exists
- There’s an administrator in the users table you didn’t create
- Your password stopped working on every device at the same moment
A compromised site behaves like this because the attacker changed the credentials. The login page will keep rejecting you politely all day.
The login screen itself has been a target this year. WordPress 7.0.3 patched CVE-2026-64638 sopra 6 agosto 2026, a pre-authentication cross-site scripting flaw in wp-login.php rated 8.9, with fixes backported through the 4.7 branch. It let an attacker craft a login URL that runs JavaScript in an administrator’s browser. Opening the link was the only interaction needed, and researchers demonstrated chaining it to PHP execution. Running an older build, with access that vanished for no reason? Check your patch level first, not last.
You can read the version without a dashboard. Aperto wp-include/versione.php over FTP and look at the $wp_version line on the same trip you’re already making. WordPress 7.1 is current as of September 2026. Note that the August fix was backported as far as 4.7.34, so an old major branch isn’t automatically unpatched. What matters is whether the site took its last minor update.
Regaining access is the easy half here, and it’s the half people stop at. Resetting the password gets you in; the attacker’s backdoor puts them back tomorrow. Una volta dentro, work through four steps in order:
- Update core and every plugin and theme
- Remove any administrator account you don’t recognize
- Change the salts in wp-config.php, which force-logs-out every session
- Then start the actual malware cleanup
If the site has been visibly defaced or is serving spam, restoring a known-clean backup beats cleaning by hand.
Read this when access vanished with no update, no config change and no error. Anything you can trace to your own actions is one of the seven cheaper problems above.
Which Fix to Try First
The right order depends on what access you have and what you were doing when it broke. Four situations cover most of them.
Aggiornare, white screen, niente SSH. You clicked Update Plugins, the site went white, and cPanel is all you have. Check the admin inbox for the recovery mode email first, because a click beats a file hunt. Nothing there? In File Manager, rename /contenuto wp/plugin per plugins-off, login, rename it back, then reactivate one plugin at a time until it breaks again. Don’t install Health Check to do this more elegantly. Its last update was July 2024, and it hasn’t been tested past WordPress 6.6.7.
Right password, silent bounce. No error message, straight back to the login form, and the site moved to HTTPS recently. Go directly to the login loop and set WP_HOME and WP_SITEURL in wp-config.php. Skip the cookie-clearing advice entirely. Your browser holds a cookie whose name no longer matches the md5 of your site URL. Clearing it just removes a cookie WordPress had already stopped looking for.
2FA lockout, SSH available. You wiped your phone and the authenticator went with it. Two commands and you’re done: wp plugin deactivate with the 2FA plugin’s slug, poi wp user update for a fresh password if you need one. This is where WP-CLI earns its place. Through phpMyAdmin, the same job means finding the right user_meta rows. Through FTP, it means renaming folders and hoping you picked the right one.
The page won’t load at all. UN 403 from your host, or a timeout, and no WordPress screen anywhere. Nothing in wp-content will help. Test on mobile data first, to rule out an IP block on your own connection. Then send your host the timestamp and any reference ID from the 403. Editing files while a server rule blocks the request wastes the afternoon.
One habit prevents most repeat visits: know your route in before you need it. If you have SSH, confirm WP-CLI actually runs on the site today. Se non lo fai, confirm you can reach the file manager and phpMyAdmin, and that the admin email is a mailbox you read. Finding out that the recovery mail goes to a former developer’s address, while the site is down, is the worst possible timing.
Domande frequenti
Why does my WordPress login page keep refreshing without an error?
A silent refresh with no error text almost always means a cookie mismatch, not a wrong password. WordPress names its login cookie using an md5 of the siteurl option. Change the site URL (http to https, adding www, a new domain) and it looks for a cookie name your browser doesn’t have. Set WP_HOME and WP_SITEURL in wp-config.php to the exact URL you serve, with no trailing slash. A corrupted .htaccess produces the same symptom, so rename it to .htaccess-old if the constants don’t fix it.
How do I reset my WordPress admin password in phpMyAdmin?
Open phpMyAdmin, select your site’s database, and edit your username’s row in the wp_users tavolo. Replace the value in user_pass, choose MD5 from the function dropdown beside the field, e salva. Export the table first so you can undo it. With SSH access, correre wp user update admin –user_pass=”new-password” anziché. WP-CLI writes a proper hash and can’t produce a malformed one.
Does the MD5 password trick still work now that WordPress uses bcrypt?
sì, on WordPress 7.1 as of September 2026. WordPress 6.8 switched new password hashes to bcrypt on 15 aprile 2025. The password check in core still treats any hash of 32 characters or fewer as a plain MD5. Your MD5 value gets you in once, and core then rewrites it as a bcrypt hash on that first successful login. Set a proper password from your profile afterwards anyway.
How do I disable a plugin when I can’t log in to WordPress?
Connect over FTP, SFTP or your host’s file manager, then rename the plugin’s folder inside /contenuto wp/plugins/. Turn wordfence in wordfence-off, per esempio. WordPress can’t find the plugin file, deactivates it, and lets you in. To disable everything at once, rename the whole plugins folder instead. With SSH, wp plugin deactivate –tutti does the same job without touching a file name.
Why does WordPress log me out after a couple of days?
That’s the default, not a fault. WordPress sets the authentication cookie to expire after 2 days on a normal login, e 14 days when you tick “Remember Me”. Logged out far sooner than that? Check three things: a security plugin shortening the session, a www and non-www mismatch, or an object cache dropping session tokens.
What do I do if the WordPress password reset email never arrives?
Assume the site can’t send mail at all, rather than that the reset is broken. The two failures look identical from the login screen. Reset the password directly with WP-CLI or phpMyAdmin to get back in, then fix deliverability by routing mail through an authenticated SMTP service. Reset links also expire after 24 hours by default, so an older email in your inbox will fail even if it did arrive.
Is the Health Check plugin still safe for troubleshooting a login problem?
It isn’t the tool to reach for in 2026. Health Check & Troubleshooting last shipped version 1.7.1 sopra 25 luglio 2024 and declares compatibility only up to WordPress 6.6.7, three major releases behind current. It still has 200,000 active installs and is still recommended widely, which is why it keeps coming up. For isolating a plugin conflict while you’re locked out, renaming folders over FTP or running WP-CLI is simpler and current.
Getting Back In: The Short Version
Read the error text before you touch anything, because the exact wording narrows eight possible failures to one. Cookie errors split into a browser fix and a server fix that share nothing but the word “cookies”. A silent loop is a site URL problem, solved in wp-config.php in two lines. A blank page means checking the admin inbox for a recovery mode link before you open an FTP client. A lockout means renaming a plugin folder. Everything else is either your server or an intrusion. A server block is a support ticket. An intrusion makes regaining access the start of the job, not the end.
Do one thing while the site is still working. Verify today that you can reach phpMyAdmin or WP-CLI, and that the admin email lands somewhere you actually read. Every fix above assumes one of those two doors is open.
If your crash traces back to something broader than the login screen, we have guides for the neighboring problems. A stalled update leaves behind il “briefly unavailable for scheduled maintenance” Messaggio, which looks alarming and clears in seconds. And if the same site keeps breaking after routine updates, the host is often the common factor. Moving to managed WordPress hosting with staging and automatic rollbacks changes the math. A broken update becomes a two-minute restore instead of an afternoon in an FTP client.