The WordPress admin on Hostinger is reachable at four default addresses on the same domain: /admin, /wp-admin, /login and /wp-login. All four open the same sign-in form, so appending any of them to your domain is enough to reach it. What you need is the WordPress username and password created during installation, not the hPanel account password, and the two are not interchangeable. Below is where each address leads, how subdomains change it, and what to do when none of the four works.
The four default login URLs
| URL | What it does |
|---|---|
| domain.tld/admin | Opens the WordPress sign-in form, then the dashboard |
| domain.tld/wp-admin | The standard WordPress admin path; redirects to the sign-in form when signed out |
| domain.tld/login | Short form of the same sign-in page |
| domain.tld/wp-login | The core login file, without the .php extension |
Use whichever your fingers remember, but bookmark one and keep it. Typing the domain alone is a bad habit for a different reason: the front page of a live site looks the same whether or not your account still has admin rights, so it tells you nothing about access.
Setting up the site behind that login? check the current Hostinger hosting plans — Premium is $1.99/mo on a 48-month term ($95.52 up front, renews at $10.99/mo), and every hosting plan carries a 30-day money-back guarantee.
Subdomains: two paths to the same dashboard
A WordPress install on a subdomain answers on two patterns. If WordPress lives at subdomain.domain.tld, the admin is subdomain.domain.tld/wp-admin. The same install is often also reachable as domain.tld/subdomain/wp-admin, which is how it appears when the subdomain was created as a folder on the main hosting plan rather than as a separate site.
That second path is the one people miss. If the subdomain address returns a not-found page but the folder path loads the site, the install is fine and only the subdomain’s mapping is wrong, which is a DNS question rather than a WordPress one. Test both before concluding the site is broken, and note which one the site actually serves: rewriting the WordPress address and site address settings to the wrong pattern is a reliable way to lock yourself out of the dashboard while the front end keeps working.
Opening wp-admin from the dashboard
You do not need to remember a URL if you can sign in to hPanel. In the dashboard, open Websites, then the site’s Manage screen. The dashboard button there opens wp-admin for that site. It is a convenience link, not shared authentication: you still land on the WordPress sign-in form and still need the WordPress credentials.
That distinction is the most common source of confusion in support threads. A browser that is signed in to hPanel and not to WordPress will show a login form, and users read it as the button failing. It is not failing; it is handing you to the other system, which has its own users table. If you do not know the WordPress password, the button will not help, and the reset routes below will.
When the login URL fails or redirects elsewhere
The first suspect is a security plugin that changes the admin URL. Plugins built for exactly that purpose, WPS Hide Login among them, replace the default path with a custom slug and send the four standard addresses to a not-found page or to the home page. If the site was set up by someone else, or by an installer that bundled a security plugin, the default URLs may never have worked.
Confirm the site is actually WordPress before chasing the URL. A CMS detector will identify the platform from the front end, and if it reports something else, you are looking for a different admin path entirely. If it reports WordPress and all four addresses fail, ask whoever built the site for the custom login path, or look through the active plugins list from the hosting file manager.
Two smaller causes are worth ruling out first, because they cost nothing to check. A trailing slash matters less than the domain prefix: www and the bare domain can be configured differently, and a login that works on one may fail on the other. And a redirect plugin or a forced HTTPS rule can send the login POST to a different host than the one that set the cookie, which looks like a wrong password rather than a redirect problem.
The cookies error, and the one line that fixes it
WordPress refuses to sign you in when it cannot set or read its authentication cookie, and it says so with an error about cookies being blocked or unsupported. The first fix is the obvious one: allow cookies for the domain, and turn off any extension that blocks them for that site.
If the error survives that, the cause is usually a domain mismatch between the cookie and the site address. Add this line to wp-config.php, on the line just above the closing comment that begins That's all, stop editing! near the bottom of the file:
define('COOKIE_DOMAIN', false);
The effect is to stop WordPress from forcing a specific cookie domain, so the browser accepts the cookie on whichever host it landed on. This is the right fix when the site answers on both www and the bare domain, or when it was migrated from another domain and the old value is still pinned somewhere. Save the file, then load the login page in a fresh window, because the browser will otherwise keep presenting the rejected cookie.
Resetting the password over SSH
On Web Premium and above, where SSH access is available, WP-CLI is the fastest way back in and it does not depend on email delivery. Connect over SSH, change into the directory where WordPress is installed, and list the users.
- Run
wp user listto see the accounts on the install, with their usernames and roles. Identify the administrator account rather than guessing at an address. - Run
wp user update username --user_pass=NewPassword, replacing the username with the one from the list and the value after the equals sign with the new password. - Sign in at any of the four URLs with that username and the new password.
- Change the password again from the WordPress profile screen once you are inside, so the value in your shell history is no longer the live one.
If wp is not recognised, you are either outside the WordPress directory or on a plan without SSH, in which case the hosting file manager and the database are the remaining route, or the password reset email is. Note that the command needs the username, not the display name and not the email address, which is why the list step comes first.
Protecting the admin URL once you are back in
A default login path is a known login path, and that is the trade-off of the four URLs above: they are convenient because everyone knows them. After access is restored, the sensible next step is to stop advertising the form to automated attempts, either by moving the login path with a security plugin or by adding a layer in front of it. Hostinger publishes its own guide on protecting the WordPress admin URL inside the Hostinger help centre, and that is the reference to follow rather than improvising rules.
Our own walkthrough of that process is in protecting your Hostinger WordPress login, which covers the admin URL change and what to do when the new path is forgotten. Do that work after you have confirmed you can sign in and out reliably, not before: changing the login path while access is already fragile turns a small problem into a lockout.
Keep the hosting account and the WordPress account separate in your notes, with the WordPress username written down next to the site rather than the domain. When the dashboard opens but the site does not, the difference between the two logins is the first thing to check, and the hPanel login guide covers the hosting side of that pair.
Starting a new WordPress site? check the current Hostinger hosting plans — Premium is $1.99/mo on a 48-month term ($95.52 up front, renews at $10.99/mo), and every hosting plan carries a 30-day money-back guarantee.
Frequently asked questions
What is the default WordPress login URL on Hostinger?
There are four, and all of them work: domain.tld/admin, domain.tld/wp-admin, domain.tld/login and domain.tld/wp-login. They reach the same sign-in form. If one returns a not-found page while another works, a plugin or a redirect rule is rewriting paths rather than the install being broken.
Why does my hPanel password not work on wp-admin?
Because they are two different accounts. hPanel authenticates you to the hosting platform; WordPress authenticates you to the site’s own user table, which was populated when WordPress was installed. Nothing you change in hPanel updates a WordPress user, and nothing you change in WordPress affects the dashboard login.
Can I log in with my email address instead of the username?
WordPress accepts either the username or the email address on the account in the login field. The WP-CLI command is stricter: wp user update needs the username, which is why wp user list comes first. If the login form rejects an email address that you are sure is on the account, try the username before resetting anything.
What if I no longer have access to the admin email?
The password reset goes to the address on the administrator account, so a dead mailbox blocks the self-service route. SSH and WP-CLI solve it on Web Premium and above. Without SSH, the remaining options are the hosting file manager and a database edit, or a support request, and both are slower than setting a working mailbox address before you need it.
Does changing the site URL break the login?
It can. The admin URL follows the WordPress address setting, so a site moved from a temporary domain to a live one will answer at the new address only after both the WordPress address and site address values are updated. If the front end works but every admin path fails, check those two values before looking for a security plugin.
Where do I find the login button in the dashboard?
Under Websites, on the site’s Manage screen. That button opens wp-admin in a new context but does not sign you in, so keep the WordPress credentials to hand. It is the quickest way to confirm the site is reachable when you cannot remember which of the four URLs you normally use.
Pick one URL, confirm it loads, and write the WordPress username beside it in whatever you use for site notes. Almost every lockout described on this page is survivable, but the recovery is much shorter when the username is already written down and the admin email still works.
