Security & access
WordPress admin 404: find the cause before changing DNS or reinstalling
Investigate the login path, server routing, recent changes, and security settings when WordPress administration returns 404.
A WordPress admin 404 means the requested address was not found or was deliberately presented that way. It does not by itself prove that WordPress is missing, DNS is broken, or the site is hacked. First identify which server and rule produced the response.
Start with the exact URL, the last time it worked, and recent changes. A login-hiding plugin, a moved installation, a web-server rule, and missing files require different fixes.
Compare the failing addresses
| Observation | Next place to look |
|---|---|
| Public site works; default login URL returns 404 | Documented custom login path and access-security configuration. |
| Only one hostname or subdirectory fails | Redirects, installation location, document root, and host mapping. |
| Home page works; many nested pages fail | Rewrite configuration and permalink handling. |
| All paths show an unfamiliar page after a move | Which hosting destination the hostname currently reaches. |
Use the login path recorded by the site administrator. WordPress is commonly accessed through /wp-admin/ or /wp-login.php, but an installation in a subdirectory or a security customization changes the relevant address. Do not repeatedly guess paths or passwords.
Distinguish DNS from application routing
DNS resolves a hostname; it does not normally choose whether /wp-admin/ exists. If public pages and the admin path reach the same intended installation, repeatedly changing nameservers is unlikely to fix a path-specific 404.
After a migration, however, different clients may still reach different destinations. Compare the expected hosting address, the returned page, and server logs. If Cloudflare is involved, use the DNS investigation guide to separate authoritative records, cached answers, and proxy behavior.
Ask the host to confirm the document root for this domain. A working cached home page is not proof that the active server has a complete WordPress installation.
Inspect the recent change
If the problem began after a security-plugin change, review that product’s recovery instructions and saved configuration. If it began after a server move, compare rewrite rules and directory layout with the previous setup. Preserve the current configuration before editing.
The WordPress error handbook discusses permalink-related 404 errors and Apache rewrite support. That advice applies to the relevant routing problem; saving permalinks is not a universal cure for a missing or hidden login endpoint.
Apache .htaccess snippets do not configure Nginx, and a root-installation example may be wrong for a subdirectory or Multisite deployment. Have the host or maintainer apply the configuration that matches your setup instead of overwriting all existing rules.
Recover access without removing every protection
Use the hosting account or an existing authorized file-transfer account to inspect errors when WordPress access is unavailable. If a component needs to be disabled, identify it and use its supported recovery process. Do this on an isolated copy when the live change could affect checkout or other critical features.
Keep error logging private. Displaying debugging output to visitors can expose paths and other sensitive information. Do not delete the database or reinstall over the site merely to see whether the login screen returns.
Know when to treat it as a security incident
Unexpected administrators, unauthorized redirects, modified files, or unrelated spam pages justify a separate compromise investigation. A 404 alone does not. Preserve evidence before cleanup if those signs are present.
Once access returns, confirm public pages, editor actions, media uploads, and intended access restrictions. Record the corrected login address and the change responsible for the outage so the next administrator does not repeat the same recovery work.