When the public website works but WordPress admin does not, avoid resetting everything at once. The error shown by /wp-admin usually narrows the problem quickly.
1. Identify the exact symptom
| Symptom | Likely area | First check |
|---|---|---|
| 403 Forbidden | Firewall or security rule | Test another network and review security controls |
| 404 Not Found | Login URL, routing or installation | Confirm the correct WordPress login URL |
| Extra password prompt | Directory protection | Check wp-admin password protection |
| Timeout | Network, firewall or resources | Test public site and hosting status |
2. Confirm the login URL and domain
WordPress normally responds at /wp-admin or /wp-login.php. Hostinger documents the common login paths in its WordPress login URL guide. If the domain was recently moved, confirm it points to the intended Hostinger site before changing WordPress files.
3. Check security blocks before plugins
A 403 or timeout can be caused by an IP/firewall restriction. Test from another legitimate network or device. If the result changes, investigate the block rather than rebuilding WordPress.
4. Isolate login/security plugins carefully
Plugins that hide the login URL, add CAPTCHA, two-factor authentication or access restrictions can prevent admin access. If you cannot enter wp-admin, use File Manager only to isolate the suspected plugin, not to delete the whole plugins directory.
5. Treat .htaccess and wp-config.php as advanced checks
Back up a file before editing or renaming it. Hostinger includes controlled .htaccess and configuration checks in its wp-admin troubleshooting guide.
Related TechGuru fixes
If the symptom is specifically a 403, use our WordPress 403 checklist. If the whole site is failing after a change, see our critical error guide.
How to confirm the fix
Open the normal admin URL in a private window and confirm that the standard WordPress login screen appears. Then sign in and verify that the public site still works before re-enabling anything you temporarily isolated.
wp-admin diagnosis matrix
Use the symptom as evidence. Change one variable at a time so you can tell which action actually fixes the problem.
| What you see | What it suggests | Best next check |
|---|---|---|
| 403 on one network | IP/WAF/security restriction | Test another network; review security logs before touching plugins |
| 404 on both /wp-admin and /wp-login.php | Routing, domain mapping or custom login URL | Confirm the site/domain mapping and any login-hiding plugin |
| Login page loads but loops after sign-in | Cookies, URL mismatch or redirect rule | Check HTTPS and WordPress/Site Address consistency |
| Admin times out while frontend works | Admin-only workload or resource pressure | Check resource usage and recent admin-heavy plugins |
What not to do
Do not rename the entire plugins folder, reset DNS, or replace WordPress core as a first move. Those actions can create extra symptoms and erase the evidence that identifies the original fault.
How to verify the fix
Retest both /wp-login.php and /wp-admin/ in a private window. Sign in, open two or three dashboard screens, and confirm the public site still works.
When to escalate
If the problem persists after the evidence-based checks, preserve screenshots, timestamps, the exact affected URL and any relevant error/log entry before contacting hosting or plugin support. That gives support a reproducible case instead of a generic “site not working” report.
