When WordPress wp-admin is not working, first determine what “not working” means. A login loop, a permission error, a blank page, a dashboard that opens but will not save, and a missing toolbar are different problems with different fixes.
In this guide
This guide focuses on identifying the failure safely. It does not assume that the issue is a plugin, a corrupted database, or a hacked site. Start with the least-invasive checks, record what changes, and avoid editing wp-config.php, .htaccess, DNS, or the database until the evidence points there.
1. Record the exact wp-admin symptom
Open a private browser window and visit https://example.com/wp-admin/, replacing the domain with your site. Note the first result rather than repeatedly refreshing it.
- Login page never appears: suspect a redirect, access rule, DNS, SSL, or server response.
- You can log in but return to the login screen: check cookies, site URLs, caching, SSL configuration, and authentication-related plugins.
- The page is completely blank: a PHP fatal error is possible; use the separate blank wp-admin recovery guide.
- You see 403 Forbidden: a firewall, host rule, file permission, or security plugin may be blocking access. Follow the 403 wp-admin troubleshooting guide.
- The dashboard opens but buttons, menus, or saving fail: JavaScript errors, REST API blocks, plugin conflicts, or server timeouts are more likely.
- Only one user or role is affected: investigate permissions, the user account, or a role-management plugin.
Take a screenshot and copy any error code or message. The exact wording is more useful than a description such as “the backend is broken.”
2. Check whether the problem is local
Before changing WordPress, rule out a browser or network problem. Try the same administrator account in a private window or a different browser. Disable browser extensions temporarily, especially ad blockers, password managers, script blockers, and developer tools that rewrite requests.
Then test from a different network, such as a phone hotspot. If wp-admin works there, the site may be blocking your IP address or your usual network may be filtering a request. Clear only the site’s cookies and cache rather than deleting all browser data. Log in again and test the specific action that failed.
If the problem occurs in every browser and network, it is probably server-side or WordPress-side. If it occurs for one browser only, inspect that browser’s console for a named JavaScript file or blocked request before changing plugins.
3. Test the site and admin URL separately
Open the public homepage in a private window, then test /wp-login.php and /wp-admin/. This comparison narrows the search:
- Public site and login both fail: check hosting status, DNS, SSL, PHP, and server errors first.
- Public site works but login is blocked: investigate security rules, login protection, cookies, redirects, or permissions.
- Login works but dashboard actions fail: inspect JavaScript, REST API requests, plugin conflicts, and server limits.
- Only one admin screen fails: the relevant plugin, widget, editor, or AJAX request may be the cause.
Use your host’s error log or control panel status page if available. Do not guess from the URL alone: a browser may display a generic error while the server log identifies the actual PHP file or rule.
4. Check for a recent change
Ask what changed immediately before wp-admin stopped working: a plugin or theme update, PHP version change, SSL or CDN change, migration, security rule, new code snippet, or hosting move.
If the timing matches an update, do not update everything again. Make a backup first, then use the host’s staging site or backup restore process where possible. A rollback can restore access, but it does not prove that the older version is a safe long-term solution. Check compatibility and update the affected component after identifying the conflict.
If the public site works and you can still use a different administrator account, avoid making several changes at once. A controlled test makes it possible to identify the responsible component.
5. Isolate plugins and themes safely
Plugin conflicts are common, but disabling everything on production can affect forms, checkout, caching, security, and scheduled tasks. The safest option is a staging copy or a host-provided file manager backup.
When the dashboard is partly usable
- Record active plugins and the current theme.
- Clear any page, object, server, and CDN cache you control.
- Temporarily deactivate the most recently changed plugin, then test the exact failed action.
- If the problem remains, test other plugins one at a time rather than bulk-deactivating blindly.
- Switch to a default WordPress theme only on staging, or during a planned maintenance window, because theme-dependent layouts and functions can change.
If wp-admin is inaccessible, ask your host whether they provide a staging environment or a safe plugin-disable method. Renaming a plugin directory through hosting file access can disable it, but this is a production file change: record the original name, make a backup, and do not rename WordPress core directories.
For a structured approach to plugin, theme, and code conflicts, see the WordPress error troubleshooting guide.
6. Inspect JavaScript, REST, and AJAX failures
If the dashboard loads but controls do nothing, right-click the affected page, choose the browser’s developer tools, and inspect the Console and Network panels. Exact labels vary by browser.
Look for a failed request when you click Save, Update, Upload, or another broken control. A 401 or 403 can indicate authentication or firewall blocking. A 404 can indicate an incorrect URL or damaged rewrite configuration. A 500 response points toward a server-side PHP error. A request that waits and then fails may indicate a timeout or resource limit.
Do not permanently disable browser security or a firewall just to make the request succeed. Instead, copy the request path, response code, and timestamp for your host or developer. If WordPress updates or editor saves fail with a JSON response message, use the guide for invalid JSON responses. If remote requests time out, see the cURL Error 28 guide.
7. Check WordPress URLs, SSL, and caching
A mismatch between the WordPress URL and Site URL can create login loops, mixed-content problems, or requests sent to the wrong hostname. If the dashboard is available, check the URL values under the WordPress settings screen; exact labels can vary by version. They should use the intended protocol and domain, including or excluding www consistently.
Do not change these values casually. If you cannot access the dashboard, ask the host to confirm the database values and take a database backup before editing them. Also purge persistent caches after correcting a URL, and check whether a CDN or reverse proxy is forcing a different HTTPS mode.
If the problem began after Cloudflare or another proxy change, test the origin site according to your host’s instructions. Incorrect SSL modes can cause redirects or authentication failures. Do not delete rewrite rules as a first step; save a copy before modifying .htaccess.
8. Check PHP, memory, permissions, and the database
Server-side causes become more likely when multiple admin screens fail, the site returns 500 or 503 responses, or logs show fatal errors. Ask the host to verify:
- the PHP version is supported by the installed WordPress, theme, and plugins;
- the PHP error log identifies a specific file or function;
- PHP memory, execution time, and request limits are sufficient for the failed operation;
- the account has not exceeded disk space, inode, CPU, or database limits;
- file ownership and permissions match the host’s WordPress configuration; and
- the database server is reachable and tables show no reported corruption.
Do not “fix” permissions by making all files writable, and do not run database repair commands without a verified backup. Editing wp-config.php can take the site offline if a quote, semicolon, or constant is wrong. If you need diagnostic logging, have the host or an experienced administrator enable it temporarily and protect the log from public access.
How to confirm the fix
After each change, test more than the dashboard homepage:
- Log out and back in using a private window.
- Open the dashboard, Posts, Media, Plugins, Users, and the screen that originally failed.
- Save a harmless draft rather than immediately changing a live page.
- Test the public site in a separate private window.
- Check the browser Network panel for new failed requests and review the server log for fresh errors.
- Re-enable any disabled plugin or service one at a time if it was part of the test.
If the fix works only after clearing a cache, identify which cache layer caused the stale response. If it works only with a plugin disabled, keep the evidence, contact the plugin author, and look for a compatible update rather than leaving important functionality disabled indefinitely.
Quick decision guide
- One browser fails: cookies, extensions, or browser cache.
- One network fails: IP blocking, DNS, firewall, or network filtering.
- 403: security plugin, WAF, host rule, or permissions.
- Blank page or 500: PHP fatal error, incompatible code, memory, or server failure.
- Dashboard opens but Save fails: JavaScript, REST/AJAX, nonce, firewall, or timeout.
- Login repeatedly redirects: cookies, URL/SSL mismatch, cache, or authentication plugin.
- Every screen is slow or times out: hosting resources, database queries, external requests, or a plugin task.
When to stop troubleshooting yourself
Pause and contact your host or a WordPress professional if the site is losing orders, you suspect malware, you have no current backup, or the next proposed step involves database edits, server configuration, DNS, or core file replacement. Preserve the exact error, timestamp, recent changes, and any log excerpt.
WP Fix It’s WordPress Site Repair service can be appropriate when wp-admin access is blocking normal diagnosis or a production-safe recovery is needed. For official background on WordPress administration and troubleshooting, consult the WordPress Documentation.
Questions readers commonly ask
Why does wp-admin work for one administrator but not another?
The affected user may have damaged capabilities, a role-management restriction, an expired session, or a security rule tied to the account or IP. Test a known-good administrator, then review the affected user’s role and account without changing permissions broadly.
Can a cache plugin make wp-admin stop working?
Yes. Incorrectly cached authenticated pages, blocked REST requests, or an aggressive optimization rule can interfere with administration. Purge the cache and exclude logged-in users and administrative paths according to the plugin and host documentation. Do not cache login responses.
Should I reinstall WordPress immediately?
No. Reinstallation will not correct a firewall rule, plugin conflict, database problem, URL mismatch, or server limit. Preserve a backup and inspect logs first. A core reinstall is a later step when evidence points to damaged or missing core files.
What information should I send to hosting support?
Send the domain, affected URL, exact error or status code, affected user and network, time of the failure with time zone, recent changes, browser console or Network details, and the relevant server-log excerpt. Never send passwords, full database exports, or secret API keys in a support ticket.
