WordPress.com account: why login to a self-hosted site fails

Understand why a valid account can be rejected elsewhere

You can log in to WordPress.com, but the same credentials are rejected by your site’s administration area. This result may be normal. A self-hosted WordPress installation has its own accounts. Having a WordPress.com identity does not automatically create an authorized user in every independent installation.

Confusion often follows installation with a host, migration or the arrival of a new collaborator. The site has the same title, your avatar may be recognized and your email address remains the same. None of these proves the two logins are connected. Identify the service verifying your identity and the account it associates with you.

Two routes are useful: use the local account intended for the site, or check a WordPress.com connection already organized by its administrator. We favor these checks without adding a plugin. The goal is to restore authorized access; randomly resetting passwords, creating several accounts or moving the site does not answer this question.

Preserve useful access and record the exact rejection

Keep any usable session open and save unsaved work. Do not log out every device before identifying the affected account. Record the starting address, form domain, final destination and message received. Hide parameters containing codes or tokens when sharing this sequence.

Distinguish an unknown username, incorrect password, code request and access-denied page. The first may indicate that the account does not exist in this context. The second does not prove you used the correct identity. An additional authentication step and insufficient permissions require further checks.

Consult installation details or information supplied by the provider. Find the administrative domain and account name created for you without copying secrets into a public document. A password manager may contain several similar entries: compare the associated domain of each before filling the form. Do not publish password screenshots or recovery codes.

Confirm the target installation and its hosting

Ask who actually hosts the site. A domain purchased from one provider may point to another service, so its purchase location does not automatically identify the host. Launch emails, the contract and technical administrator establish the context. A custom domain may also correspond to a WordPress.com site.

Check whether you are opening the public site, a test copy or an old installation. These sites may display the same pages while using different users. Return to a trusted address supplied by the administrator. If the address bar changes to an old domain, record that before requesting new access.

The hosting panel account is also separate. It may manage backups or files without being your WordPress user. Any access button offered by the host follows its own authorized procedure. Do not reuse its password in the site form or give hosting credentials to a collaborator who only needs to write pages.

Read the form to identify who verifies the login

On an independent installation, the usual form is often under /wp-login.php, and /wp-admin/ may lead there. A site installed in a subdirectory or using a custom address may have another path. Use the confirmed administrative address instead of trying dozens of variations or search results.

Look at the page domain and available options. A WordPress.com login button indicates a specific route, not proof that every WordPress.com account can access the site. A redirect to an enterprise service may reveal another identity provider. Ask which is intended for you before entering information.

Your publicly displayed name may differ from your login username. A recognized avatar or comment signed with your name also does not prove a local administrative account exists. Record the form type and message without including your password. If the screen or domain looks unusual, have the address confirmed through an already known channel.

Choose between the local account and an existing connection

The first route applies if the administrator created a site-specific user for you and local login is the authorized method. Find that username or recover its password on the relevant site. Changing your WordPress.com password does not affect this independent identity.

The second route applies if the site actually supports login through WordPress.com, for example through an already configured Jetpack. The administrator must then verify the associated local account, external account and connection. The plugin’s presence alone does not prove this login was enabled or prepared for your user.

If you do not know which route to follow, simply ask the administrator how your access was created. This answer comes before any intervention in files or the database. Do not install Jetpack to justify an existing WordPress.com account. Centralized login may be a future choice, but it is an authentication project requiring preparation, protections and recovery access.

Approach 1: use the site-specific identity

Use the local username or email address supplied when the account was created. In the confirmed site form, use that account’s password. If your password manager offers the WordPress.com entry, select the correct domain’s entry. Avoid trying several old passwords in succession: a protection may limit attempts.

If you have forgotten the local password, follow the steps below from the affected site’s form. The received message contains a link to set a new password, not a secret to give an administrator. Recovery does not create an absent user: have the account located if its existence remains uncertain.

The expected result is your local profile with the intended permissions. A new password does not remove a second step or login restriction. If the link has expired, request a new one without reusing a series of old messages. After a change, returning to the old password is not the intended rollback: keep the new one in the correct entry or request another reset.

1. On the confirmed local form, open Lost your password?.
2. Enter the local account’s username or email address and submit one request. Check that mailbox, including spam.
3. Check the reset link’s domain before opening it. Do not forward this message or its link.
4. Set a strong, unique password, save it in the correct domain’s entry, then confirm with the reset button.
5. Return to the local form and log in with this account. If a second step is required, use its usual method; if the email does not arrive, continue to the next check.

Reset the account for the service actually involved

A request sent from WordPress.com targets your WordPress.com account. A request sent from the local form targets the user in that installation. Therefore check the form address before concluding a reset was ignored. Two similar messages may concern different identities and create the impression of a persistent failure.

If the problem actually concerns WordPress.com, use its official login and appropriate route: forgotten password, inaccessible mailbox, lost second step or account recovery. That service’s support does not replace the local account administrator of independent hosting. Provide ownership evidence only through its designated channel without exposing it in a forum.

If the local message does not arrive, check the account’s associated mailbox, spam and delivery with the site administrator. Repeated requests make links harder to track. Use the latest according to the instructions received. For detailed recovery methods when email remains unusable, continue with the dedicated password guide and authorized access.

If the local account is missing, have the correct access created

On an independent installation, an authorized administrator opens Users, then All Users. They first search for the person’s username and email to avoid duplication. An author already associated with content must not be replaced with a new account merely because their login name was forgotten.

The procedure below concerns a single site and a confirmed assignment. Full administration is unnecessary just to write your own posts. Manual creation does not require opening public registration to every visitor. The recipient sets their own password; they do not receive the password of the administrator adding them.

In multisite, first check whether the person exists in the network. When authorized, the site administrator uses Users > Add New, then Add Existing User, with the registered email and intended role. The invitation may require email confirmation. If the option is missing, the account must be created in the network or its global profile corrected, contact the super administrator instead of creating a duplicate.

If an incorrect email or role was entered, correct only that account after verification. Do not automatically delete it if it already owns content; have its assignment decided. Also check other affected sites before changing a multisite user’s global profile.

1. On the single site, the administrator opens Users > Add New User only after confirming the account is absent.
2. They enter the chosen local name under Username, the verified address under Email and necessary permissions under Role.
3. They retain the new-user notification option, then confirm Add New User. The recipient opens the received link and sets their password.
4. The person logs in and checks an action intended for their role. If they only need to edit a draft, no publication is necessary for this check.

Approach 2: check the WordPress.com login already arranged

If Jetpack already handles login, an administrator opens Jetpack, Settings, then Security. They record the state of Allow users to log in to this site using WordPress.com accounts and check that this route matches intended policy. Do not enable it after the fact to explain an external account that was never authorized.

The Match accounts using email address setting can match local and WordPress.com accounts with the same address. Verify both identities and the user actually intended. A message saying the account was not found calls for checking this association; do not change another person’s address to obtain a match.

On a single site, the administrator can also open Users > All Users and read the SSO Status column when displayed by Jetpack. The official screenshot illustrates Send invite for proposing a connection to a user. This invitation button is unavailable in this multisite route. Read the status first; do not send an invitation to another account to test the feature.

Record the already installed Jetpack version from the plugin list if contacting its support. Its official listing supplies the current version’s WordPress and PHP requirements; these are not an invitation to install or update the component during recovery. A version change requires its own compatibility checks.

Preserve the settings state and approved backup access. Do not disable two-factor authentication or a protected form for a test. If an authorized setting was changed and login fails, the administrator restores only that setting from a retained session while checking other affected users.

Connect only your own accounts when the procedure calls for it

This route concerns an existing local user whose connection is authorized. A free WordPress.com account is sufficient for this association; it does not require buying a hosting plan for the independent site. Start from your own local session and follow the steps below only if Jetpack offers this connection.

These steps associate an additional user. They do not require changing the site connection’s primary account or transferring a subscription. If the screen proposes another operation or displays the wrong account, do not approve it: use the correct account or have the route confirmed before continuing.

Keep the useful local session open and then try login in a separate session. In your profile, check Username and email address instead of only the display name. Your role is not necessarily shown in your own profile: have an administrator confirm it in the user list, then check an authorized action. Merely seeing the site in an external list does not confirm permissions.

If you no longer have a local session, first have your intended access restored. An external approval must not invent an administrator. If the individual connection is wrong, have only that association corrected with the maintainer and available recovery access, without globally disconnecting the site or other services.

1. From your own WP Admin session, open Jetpack > My Jetpack.
2. If offered, choose Connect your WordPress.com account, then Connect your user account.
3. Log in to your WordPress.com identity if prompted. Verify the account and site shown on the authorization screen.
4. Use Approve only if this is the intended association. Then verify login and the resulting user in a separate session.

Handle a second step or block without changing identity

A code request after the password indicates an additional authentication step. Use the method or backup codes intended for the displayed service. WordPress.com codes do not replace those of an independent local protection. If you have lost the phone or verification method, begin recovery specific to that provider.

A rate-limit or blocking message also requires precise reading. Stop repeated attempts, record the time and send the information to the administrator. Resetting a password again does not necessarily remove an attempt limit. Do not change networks to bypass a protection without understanding the rejection.

If the form keeps returning despite a confirmed identity, record domain or protocol changes and compare with a separate browser profile. Cookies and redirects then belong to another diagnosis. Do not allow every third-party browser cookie or disable site protections to achieve one isolated success. The repair must remain compatible with the intended security arrangement.

Check the administration path and multisite context

WordPress core may remain in a subdirectory while the public home page displays at the root. In that case, administration may be under that subdirectory. Using a login address guessed from the home page may lead to the wrong place. Have the actual path confirmed and retain it in your password manager.

A multisite network adds another distinction: a user can exist in the network without the intended role on the selected site. Have their assignment checked by the authorized site administrator or super administrator if local permissions are insufficient. Successful login to another network site does not prove authorization for the one you want to manage.

A network user’s password is not site-specific. Resetting it affects that shared identity; it does not correct roles assigned separately to sites. Therefore avoid repeated resets when only an assignment is missing.

Do not change the site’s two General Settings addresses to try to find an account. A wrong URL can block navigation but is not fixed by creating users. If failure follows a move or migration, send this sequence to the administrator. Have routing to the correct installation and accounts actually present in its context checked separately.

Use an existing administrator session with limited scope

If an authorized administrator still has access, ask them to inspect the user list and your assignment. They can confirm the username, address and role without a database intervention. If they find an incorrect value, they record the old one and correct only the targeted account using their version’s procedure.

Do not ask them to share their password or reset every account to save time. Named individual logins maintain clear responsibility. If assisted recovery is necessary, use a mechanism that lets you set your own password, with secure transmission and proportionate permissions.

An account mistake does not justify deleting the previous user or moving their posts. If unknown access, unrequested changes or a suspicious address appear, also have site and email security examined. Restored login alone does not establish that every earlier change was legitimate.

Confirm the result with the normally intended account

In an independent session, open the confirmed administrative address and use the chosen route. Check the account name in your profile, then its associated email address. Perform an action appropriate to your role, such as opening your draft or viewing an authorized setting. Publishing content is unnecessary to demonstrate that login works.

Also confirm that permissions remain limited to the intended assignment. Success with a shared administrator account does not repair your personal identity. If a temporary role was granted, have it returned to the agreed role after necessary operations. Document the change and its administrator.

If the connection was changed, check backup access and other affected users with the maintainer. If it fails, revert only the changed setting after confirming approved access remains available. Do not disconnect the entire site from WordPress.com to undo an individual association: that can affect other functions without resolving the account being recovered.

Document the correct login and direct support to the right service

In your password manager, separate site, WordPress.com and hosting entries. Record the exact domain and expected identity for each. If the site uses external login, indicate that route and its administrator without copying backup codes into an openly shared document.

For support, prepare the site domain, login type, message, time and checks already performed. The site administrator or host handles the local user; WordPress.com handles its service identity; the connection administrator examines the association. This division prevents recovery from targeting an account that already worked.

Keep a record of the cause: wrong form, absent user, different identity, multisite assignment or incomplete connection. Add the check that confirmed restored access. If the problem persists, send only necessary details through the designated secure channel. Passwords, cookies, verification codes and full account exports do not belong in public messages.

Confirm the account exists in the WordPress installation rejecting access

First have the address of the form you use compared with the site address confirmed by its administrator. From an authorized session in that WordPress installation, the administrator opens Users and searches for the expected account. With two similar addresses, verify the user record before sending recovery or an invitation.

On a self-hosted copy with WP-CLI, the administrator can perform the same lookup by address. Run the command from the copy’s directory and replace the fictional address with the test account’s address. Output is limited to the username and role.

Without an external connection, a WordPress.com address should be considered a local account only if the search actually finds that user in the target installation. Record the command’s actual result, then separately verify authorized login and role. No password change or email sending is needed just to check account presence. This read-only check tests neither Jetpack nor a remote identity association.

1. If a local account appears, try its usual login in a separate profile or initiate one recovery from the local form. The displayed role provides a reference to check with the administrator if the expected action remains inaccessible.
2. If no local account appears, confirm the site and invitation address with the administrator. They can search another known address and create the account only if access is authorized and no duplicate exists.
3. If WordPress.com login is already offered, check with the administrator which local account should be associated with your identity and what recovery route is available. Existence of a local record and correct operation of the connection are two separate checks.

wp eval '$u = get_user_by("email", "compte-local@exemple.test"); echo $u ? $u->user_login . " : " . implode(", ", $u->roles) . PHP_EOL : "Aucun compte local" . PHP_EOL;'