iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If a new WordPress installation will not let you into wp-admin, start with the direct login URL, then check credentials, browser cookies, site URL settings, and extensions before changing the database. Open https://example.com/wp-login.php on the same domain and HTTPS scheme as the site. A logged-out visit to /wp-admin/ should redirect there automatically. The workflow below isolates browser, WordPress, plugin/theme, password, and hosting-stack causes without requiring dashboard access.
Start with the correct login address and account details
Use wp-login.php on the site’s canonical URL
Replace example.com with your domain and open https://example.com/wp-login.php directly. WordPress normally redirects a logged-out request for /wp-admin/ to the login page automatically, so a redirect by itself is not an error. Use the exact scheme and hostname visitors use: do not begin on http:// if the site is configured for HTTPS, and do not switch between a www and non-www hostname during the test.
Verify the WordPress account, not the hosting account
Enter the WordPress username or the email address attached to the account. The Username and Password fields are case-sensitive. A control-panel, FTP, database, or hosting password is not automatically the WordPress password unless you deliberately set them to the same value. If the form rejects the credentials immediately, use the password-recovery section below rather than repeatedly guessing.
Check whether the request reaches the expected site
After submitting the form, note the address in the browser. It should remain on the same domain and HTTPS scheme. A jump to another hostname, a repeated return to the login form, or a browser warning about an insecure connection points to URL, cookie, or proxy configuration rather than a simple mistyped password.
#1 Best Overall
Fix browser and cookie problems first
Why cookies matter
WordPress must set cookies to remember a successful login. It first writes wordpress_test_cookie to test whether the browser accepts cookies, then uses authentication cookies including wordpress_[hash] and wordpress_logged_in_[hash]. WordPress describes the “cookies are blocked” message as occurring when it cannot set the test cookie or authentication cookies.
Run a clean browser test
- Delete cookies and cached data for the affected domain only, then close and reopen the browser.
- Confirm that cookies are enabled for the domain. If the browser blocks third-party or all cookies, add an exception for the site while testing.
- Open a private or incognito window and visit the direct
/wp-login.phpaddress. - Try a second browser or another device on the same network. If the second browser works, the original browser profile, extension, or stored cookie is the likely fault.
- Temporarily disable extensions that alter privacy, scripts, redirects, or page caching. Re-enable them one at a time after login works.
When the form simply reloads
A form that returns to itself without a useful error commonly means the test or authentication cookie was rejected. Check the browser’s cookie-blocking notice and inspect whether a cache is serving an old copy of wp-login.php. A security or redirect plugin can also intercept the request; the filesystem isolation procedure below lets you test that without dashboard access.
Resolve login loops and “too many redirects”
Keep the WordPress URLs consistent
WordPress stores its site address in two places: the WP_HOME and WP_SITEURL constants in wp-config.php, and the home and siteurl rows in the database options table. The domain and HTTP/HTTPS scheme must agree across the values that are actually in use. A mismatch such as an HTTPS front end with an HTTP home value can make the browser bounce between addresses and discard the login cookie on every trip.
Inspect wp-config.php safely
Use SFTP, FTP, or the host’s file manager to download a backup of wp-config.php before editing it. Look for definitions similar to the following example:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Replace the example domain with the canonical address of your site. If WordPress core is intentionally installed in a subdirectory, WP_SITEURL may be different from WP_HOME; preserve that deliberate arrangement and change only an incorrect domain or scheme. Do not add competing definitions elsewhere in the file. Save the file, clear the site’s cookies, and test /wp-login.php again.
Check the database options
If the constants are absent, overridden, or correct but the loop continues, inspect the options table through the host’s database tool. The table may have a custom prefix, so its name is not always literally wp_options. Find the rows named home and siteurl. Compare their complete values with the address visitors should use, including the HTTPS scheme and hostname. Back up the database first, edit only a value that is demonstrably wrong, and remove accidental spaces or a second hostname. Clear cookies after saving.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsRank #3
Account for proxy, CDN, and host redirects
Mixed redirects can be introduced outside WordPress. An HTTPS certificate may terminate at a reverse proxy while the origin server receives HTTP; a CDN or host-level redirect may also force a different hostname. If the browser alternates between HTTP and HTTPS, or between www and non-www, WordPress values alone may not fix it. Ask the host to verify SSL termination, forwarded protocol handling, DNS target, redirect rules, and any cache rule covering wp-login.php. Purge the relevant cache only after confirming that the canonical URL is correct.
Disable plugins and the active theme without dashboard access
Rename the plugins directory
- Connect with SFTP, FTP, or the hosting file manager and open the WordPress installation directory containing
wp-admin,wp-includes, andwp-content. - Inside
wp-content, renamepluginsto a temporary name such asplugins.disabled. Renaming prevents WordPress from loading the installed plugins; it does not delete their files or settings. - Open a private browser window and retry
/wp-login.php. - If login works, restore the directory name to
plugins, sign in, and reactivate plugins individually. Test after each activation to identify the conflict.
A successful login with plugins disabled identifies a plugin conflict, but not which plugin caused it. Leave the directory name restored once you have isolated the offender; otherwise updates and normal plugin management will not work.
Test the active theme
If disabling plugins changes nothing, identify the active theme directory under wp-content/themes and rename that directory temporarily. WordPress should fall back to an available default theme. Retry the login, then restore the original directory name. If the theme was responsible, switch to a maintained default or repair the theme before reactivating it.
Rank #4
Recognize when renaming is not the right fix
Do not rename WordPress core directories or delete plugin files while diagnosing authentication. If the filesystem account cannot rename a directory, or the site immediately restores the name through a deployment system, ask the host to perform the isolation and preserve a backup. A failure that persists with both plugins and the active theme disabled points toward credentials, URL settings, cookies, or the hosting stack.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteRecover access when the password is the problem
Use the email reset link when mail delivery works
- Open
/wp-login.phpand select Lost your password?. - Enter the account username or its email address and submit the form.
- Open the message’s reset link promptly and choose a new, unique password.
- Check spam, quarantine, and mail-filter logs if no message arrives. Confirm that the address belongs to the WordPress account rather than only to the hosting account.
If WordPress reports that the account is not recognized, check the spelling and capitalization of the username and try the account email. Repeatedly requesting resets can create several valid-looking messages; use the newest link.
Use WP-CLI when email is unavailable
WP-CLI requires shell access to the WordPress installation and an account with permission to run commands. First identify the administrator login, then choose one of these documented approaches:
Best Value
wp user update ADMIN_LOGIN --prompt=user_passThis command prompts for a new password without placing it in the shell history. Replace ADMIN_LOGIN with the actual login name. You can also use the password-reset command:
wp user reset-password ADMIN_LOGINAny generated password printed by a command is plaintext sensitive data. Copy it only through a protected terminal, change it immediately after signing in, and remove it from shell transcripts, support tickets, and shared logs.
Database recovery is a last resort
A documented database recovery method can restore administrator access when neither email nor WP-CLI is available, but it carries more risk than the preceding options. Back up the database, confirm the correct options-table prefix, identify the intended user record, and follow the host or WordPress support documentation for the exact password-hash procedure for your version. Never paste a plaintext password into an arbitrary database field, and do not edit rows while another migration or deployment is running.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the recovery path that matches your access
| Situation | Best first path | Configuration risk | What success tells you |
|---|---|---|---|
| You can receive the account email | Use Lost your password?, then test in a clean browser session. | Low; only the account password changes. | The account and mail route are valid; remaining failures are likely browser, URL, extension, or host related. |
| No email, but shell access is available | Run wp user update ... --prompt=user_pass or wp user reset-password. |
Moderate; protect the terminal and generated password. | The WordPress user record can be changed without relying on mail delivery. |
| No dashboard, but SFTP or file-manager access exists | Inspect URL constants and temporarily rename plugins or the active theme. | Moderate; back up files and restore directory names. | A change in behavior identifies a configuration or extension conflict. |
| Database access only | Back up first, then use a documented user or options-table recovery method. | High; an incorrect row or hash can lock users out or break the site. | Database values, rather than the browser, are controlling the failure. |
| DNS, SSL, proxy, or server redirects are inconsistent | Escalate to the host with timestamps, URLs, and environment details. | High if changed blindly in production. | The fault is outside the WordPress dashboard and may require infrastructure changes. |
Use the symptom to select the next check
| Observed symptom | Most useful next check | Expected result |
|---|---|---|
/wp-admin/ sends you to /wp-login.php once |
Enter the WordPress credentials on the redirected page. | This is normal logged-out behavior. |
| “Cookies are blocked” appears | Enable site cookies, clear the domain’s cookies, and test privately. | The browser accepts wordpress_test_cookie and authentication cookies. |
| The form reloads after every submission | Check cookie blocking, cached wp-login.php, and plugin/theme conflicts. |
The form either logs in or displays a specific credential error. |
| The browser alternates between HTTP and HTTPS or two hostnames | Compare WP_HOME, WP_SITEURL, home, and siteurl; then ask the host to inspect proxy redirects. |
Every login request stays on one canonical scheme and hostname. |
| Password reset mail never arrives | Check spam and mail logs, then use WP-CLI if shell access exists. | You obtain a controlled password-reset path without guessing. |
| Login works only after renaming plugins | Restore the directory and reactivate plugins one at a time. | The conflicting plugin is identified and can remain disabled or be repaired. |
What to give your host or the WordPress support forum
Escalate after completing the browser, URL, extension, password, and filesystem checks. State exactly which steps you tried; WordPress troubleshooting guidance asks you to indicate that you attempted the possible solutions. Include:
- The WordPress version and whether the installation is fresh, migrated, or recently updated.
- The PHP version and MySQL or MariaDB version.
- The browser name and version, operating-system version, and whether another browser or private window behaves differently.
- The server type, hosting control panel, and whether a CDN, reverse proxy, or SSL terminator sits in front of the origin.
- The exact login URL, the final URL after submission, and the time of the failure with its time zone.
- The precise message, such as a cookie warning, invalid-credentials notice, or redirect-loop error.
- Whether renaming the plugins directory or active theme changed the result, and whether the original directory names have been restored.
Do not post passwords, reset links, session cookies, database credentials, or a generated plaintext password. A host can inspect DNS, certificate, redirect, cache, and server logs without receiving those secrets.
Final verification after access returns
- Restore any temporarily renamed plugin or theme directories.
- Change a temporary or generated password to a unique long password and store it in a password manager.
- Open the dashboard and confirm the site URL settings, active theme, and plugin status.
- Test a fresh private-window login and a logged-out visit to
/wp-admin/. - Clear or purge only the caches that were serving the login request, then repeat the private-window test.
If the clean test succeeds and the browser remains on one canonical HTTPS address, the authentication path is working. Persistent failures after all of these checks require host or WordPress support because the remaining cause is likely server-side or specific to the installation’s database.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
