How to sign in to your WordPress blog

To reach the dashboard of a self-hosted WordPress blog, add /wp-login.php to the end of your domain. That works on most sites. When it doesn’t, the cause is rarely the password, even though the password is what people reset first. Most failed sign-ins come from the wrong account, the wrong address, or a site that accepts your password and then forgets you a moment later.

This guide starts with finding the right login. Then it works through each symptom in the order people usually hit them. If all you need is a fact about the site, such as its WordPress version, you may not need to log in at all: see finding your WordPress version without logging in.

Is your blog on WordPress.com or self-hosted?

Answer this first, because the two use separate accounts. WordPress.com is a hosted service with one account system. It has its own login page, its own password reset and an option to get a login link by email. A self-hosted WordPress site keeps its own user accounts in its own database, and it doesn’t know about your WordPress.com account at all.

Mixing the two up wastes a lot of time. In one WordPress.org support thread, a site owner reset their password, still got “incorrect password”, and kept trying. A forum moderator pointed out that the WordPress.com login and the self-hosted site’s login are different accounts. They also suggested checking whether a password manager was filling in an old password.

Here is how to tell which one you have:

• If the address ends in wordpress.com, it is WordPress.com.
• If you pay a web host (cPanel, Plesk or a managed WordPress host) and the bills come from them, the site is self-hosted.
• A custom domain doesn’t settle it, because WordPress.com sites can use custom domains too. Search your email for hosting or billing receipts.

Where is the login page for a self-hosted blog?

WordPress’s Advanced Administration Handbook gives the login page as wp-login.php. It also says that visiting /wp-admin/ while logged out redirects you there. They are not the same thing: /wp-admin/ is the dashboard, and wp-login.php is the form that lets you into it.

1. Type the full address yourself: https://yourdomain.com/wp-login.php. Don’t click through a search result.
2. If WordPress is installed in a subfolder, include it: https://yourdomain.com/blog/wp-login.php.
3. Enter the username and password for your account on that site, not your hosting or WordPress.com login.
4. Leave “Remember Me” unticked on shared computers.
5. Once you land on the dashboard, bookmark the address you used.

If you get the dashboard, you’re done. If not, the next section tells you which problem you have.

What happens after you click Log In tells you the fix

Write down exactly what you see after you submit the form. Each response points to a different part of the site.

What you see	Most likely cause	Where to look
“Incorrect password” or unknown username	Wrong credentials or wrong account	Reset, check case, check the password manager
Back to the login form, no error	Cookies, site URLs, cache, plugin	Private window, URL settings, cache rules
“Too many redirects”	Conflicting redirect rules	WordPress, host panel, CDN, proxy, SSL mode
404 at wp-login.php	A login-hiding plugin	The plugin’s custom address
A lockout or CAPTCHA error	A security plugin	Wait, unlock email, or disable via file access
403, 500, blank page or database error	The server or PHP	Your host and the error logs

The password is rejected

WordPress.org’s troubleshooting guide says the username and password fields are case-sensitive. Check Caps Lock, and type the password by hand once so you know an old saved password isn’t being filled in. Then use “Lost your password?” under the form, enter your username or account email, and follow the link in the message.

If the email doesn’t arrive, check spam. Make sure you are looking in the inbox actually attached to that WordPress user, which is often the address of whoever set the site up. Don’t request five resets in a row. Each new request makes the earlier links useless, and security plugins may count the attempts against you. WordPress.com’s own help says its reset emails can take a few minutes. It also says that several wrong passwords can block sign-in for a few minutes.

If the account email is one nobody can open anymore, the fix needs hosting access. With WP-CLI on the server, you can list administrators and set a new email address, then run the normal reset:

wp user list --role=administrator --fields=ID,user_login,user_email
wp user update 1 --user_email=you@yourbusiness.com

Without WP-CLI, the same details are in the users table in phpMyAdmin, which your host’s control panel opens. Take a database backup before you change anything there.

You log in and land back on the login screen

If the form reloads with no error, WordPress accepted your password but couldn’t keep you signed in. The handbook lists the usual causes: blocked cookies, a COOKIE_DOMAIN mismatch, mixing http and https, site URLs that disagree, plugin conflicts and server caching. Work through them from cheapest to most invasive:

1. Try a private window. If you get in, clear that site’s cookies in your normal browser and you’re done.
2. Check the address you typed against the site’s own settings. Use the same scheme (https or http) and the same host (www or no www) every time. If wp-config.php defines WP_HOME and WP_SITEURL, those values override the database settings. They should match the address you actually use. The handbook warns against blindly making the home and site URLs identical, because some installs keep WordPress in a different folder on purpose.
3. Exclude the login page from every cache. wp-login.php and logged-in sessions shouldn’t be cached by a plugin, by the host or by a CDN. In one WordPress.org thread, clearing cookies and turning off ad blockers did nothing. Host-level caching can keep running even after you disable the cache plugin.
4. Test plugins by renaming the folder. Over SFTP or in the host’s file manager, rename wp-content/plugins to plugins-off. If you can now log in, a plugin is the cause. Rename the folder back and reactivate plugins one at a time until the loop returns. Renaming is a test, not a fix.
5. Check the theme. The error “Cookies are blocked due to unexpected output” means something printed text before WordPress could set its cookie. In one resolved WordPress.org thread, the cause was two blank lines at the end of the theme’s functions.php.

The browser says “Too many redirects”

This means two or more rules are sending the browser back and forth. The rules can live in WordPress, in .htaccess, in the hosting panel, in a CDN or proxy, or in the SSL mode setting. This loop typically starts after a domain change or an HTTPS switch. Find the conflicting rule and remove it, then purge every cache. Adding another “force HTTPS” rule is the most common way to make this loop worse.

wp-login.php returns a 404

A 404 almost always means someone installed a plugin that moved the login page. WPS Hide Login’s plugin page says the plugin makes wp-login.php and the wp-admin directory inaccessible without renaming core files. If you’ve lost the custom address, the plugin’s documentation says it is stored in the whl_page option in the database, or in sitemeta on a multisite network. Removing the plugin’s folder over SFTP brings back the default address. Reinstall the plugin afterwards if you still want it.

A security plugin locked you out

Security features lock out many site owners. Limits on login attempts, CAPTCHAs, cookie-based brute-force settings and forgotten custom URLs are all common causes. In one WordPress.org thread, enabling the cookie-based brute-force feature in All-In-One Security sent the owner’s login to 127.0.0.1. In another, a CAPTCHA showing “Invalid site key” blocked both login and password reset.

For a temporary lockout, wait it out, use the plugin’s unlock email if it has one, or try another network. If the plugin itself is broken, rename its folder in wp-content/plugins, log in, and fix the setting before you reactivate it. Replies in that CAPTCHA thread warned against turning protection back on until you understand what went wrong. Reactivating too soon locks you out again.

You see a 403, a 500 or a database error

A new password does nothing for these. “Error establishing a database connection” means WordPress can’t reach its database. A 403 is usually a firewall or security rule, and a blank page or 500 is usually a PHP failure. Our guide to fixing a WordPress white screen covers the PHP side. For firewall blocks and database errors, contact your host and ask them to check the error logs.

What if you never had hosting access?

This is the harder situation, and it is common with sites a developer or agency built. Your login may be an editor account rather than an administrator, or you may have no login at all. In one 2026 r/Wordpress thread, the client didn’t know where the site was hosted. A freelancer traced the DNS to a server running Plesk and found the web firm behind it. It turned out three years of hosting invoices had been going to an inbox nobody read.

Start by finding the host. A DNS lookup on your domain shows where it points. Your email and card statements show who you pay. Then ask whoever controls that account to create an administrator account in your name. Don’t ask them to send you their password. Practitioners agree on this order: own the domain, the hosting account, the recovery email and one administrator account yourself. Give developers their own accounts that you can delete when the work ends.

When to stop and get help

Stop at the database or redirect rules if you don’t have a recent backup, or if you’re editing values you can’t explain. Hand server errors to your host early. If you have hosting access but would rather not rename folders or edit wp-config.php yourself, SiteSelf can do that work through chat with SSH access. It checks the result and reports what it changed, and you can read more on getting broken WordPress sites working. Once you’re back in, review who holds which keys as part of your WordPress care plan.