Your WordPress homepage opens, but a page or post says “404 Not Found.” The page may be missing, the link may be old, or the server may no longer route readable URLs to WordPress. Those are different repairs. Before changing permalink settings, test the exact address and find out whether one page or every inner page fails.
This guide is for a business owner whose public homepage still works. If the browser instead says ERR_TOO_MANY_REDIRECTS, use our redirect-loop guide. A 404 response is not a redirect loop, and changing HTTPS or domain settings can make a working homepage fail too.
Check one broken URL before changing the whole site
- Copy the failing public URL, including its path. Do not share private preview, password-reset, account or checkout links.
- Open it in a fresh browser session, then click the same page from your site’s own menu or sitemap. Compare the two addresses character by character.
- Check the homepage, one other published page and one blog post. Record which ones fail and when you first noticed it.
- In WordPress, find the affected item under Pages or Posts. Confirm it is published and use its View link. Do not rename its slug as a test.
If the menu link is old but WordPress’s View link works, the first repair is the link, not a site-wide permalink reset. If the item is a draft, private or deleted, the URL may correctly return a 404 for public visitors. If every published inner page fails while the homepage opens, routing deserves attention. WordPress’s Permalinks screen documentation explains the site’s URL structure; it is a setting for the whole site, not one broken page.
Which 404 pattern do you have?
| What you can verify | Likely owner of the next check | Safe next action |
|---|---|---|
| Only an old bookmarked or menu URL fails; the page’s View link works. | Changed path or outdated internal link. | Record both URLs. Ask the site owner to update the link and assess whether the old public path needs a relevant redirect. |
| One current View link fails, but other posts and pages work. | That item’s status, slug, custom route or a page-specific rule. | Confirm published status and exact permalink; note any recent edit. Do not alter the global URL structure. |
| All inner pages fail while the homepage works. | WordPress rewrite rules or the web server’s routing configuration. | Capture the current permalink setting and the first failing URL; ask the host or developer which server receives the request. |
| A clean visitor sees 404 while an editor sees the page. | Publishing permissions, an access rule or a cached public response. | Compare a public session and a logged-in session on the same clean URL. Do not assume the editor view proves public delivery. |
| The page loads but displays a “not found” message, or an old URL lands on unrelated content. | The visible message and the HTTP response may disagree. | Have a developer check the actual response status and final URL before adding redirects or requesting indexing. |
A 404 tells a browser that the requested resource was not found; it does not identify the broken layer. Google also distinguishes a real 404 from a soft 404, where the page looks like an error but does not return the appropriate status. Do not promise that an indexing request will repair a page that still fails for visitors.
Why the homepage can work while everything else fails
The homepage can load through the site’s root address while readable inner URLs depend on routing rules. WordPress’s common-errors handbook lists pretty-permalink 404s and notes that Apache’s rewrite module or rules may be involved. After a migration or hosting change, the public server may not pass those inner paths through as expected.
That does not mean you should paste a generic .htaccess recipe into production. Apache can use that file; Nginx does not read it. A proxy may also sit in front of the server you think you use. Ask the host to identify the actual request path and preserve the current configuration before changing it. WordPress’s rewrite-rule reference also calls a flush an expensive operation: it is a targeted repair, not a scheduled fix for an unexplained recurring 404.
On a site with a recent permalink, migration or server change, a qualified administrator may save the existing structure once and retest a small URL set. But even a save can rewrite routing rules. First record the setting and take a recoverable backup of the relevant configuration. Do not switch to Plain and back on a live site just to see whether something changes: that can temporarily alter public URLs and make diagnosis harder.
What to record for the host or developer
| Evidence | Why it matters | Keep out of the handoff |
|---|---|---|
| One exact public failing URL, its time and timezone, and a working homepage URL. | Lets the investigator reproduce and locate the request in logs. | Private preview, reset, customer account or checkout-session URLs. |
| Whether one item or all published inner pages fail; whether the item’s View link works. | Separates a broken link or unpublished item from site-wide routing. | An unreviewed export of every page, customer or order. |
| What changed just before the failure: permalink, migration, host, proxy, plugin or redirect rule. | Defines a focused comparison; timing alone does not prove cause. | Passwords, API keys and raw server access details. |
| The actual response status and which layer produced the error, if support can determine them. | Distinguishes a WordPress 404, a server/edge 404 and a page that only looks broken. | Full request headers containing cookies or authorization values. |
If you do not know how to read response headers, simply send the public URL and scope comparison to your host. The host can check whether the request reached WordPress at all. When several layers are involved, a WordPress developer can trace the route from the menu link through server rules, WordPress and any edge cache.
Make one reversible repair, then test real pages
Choose the repair that matches the evidence. Update an obsolete menu link if its target is alive. Restore a legitimately unpublished page only after confirming it should be public. Correct a server rule only with a backup and rollback owner. If a cached 404 is suspected, fix the source first, then purge the relevant cache and compare the clean public URL in a fresh session.
Do not redirect every broken URL to the homepage. A page that intentionally no longer exists may be better left as a proper 404, while a moved page should point to its genuinely relevant replacement. Google’s crawl-error guidance distinguishes removed content from a broken page that should return. Bulk homepage redirects can conceal the latter without restoring it.
Stop making changes if the next step requires editing unknown web-server rules, changing the public permalink structure, or touching a live store’s product and checkout routes without a tested rollback. Webless can investigate the route and agree a scoped WordPress repair; a site owner should not have to learn server configuration during an outage.
After repair, verify the original URL, the current View link, a representative post, the menu route and any affected business path from a fresh public session. Check desktop and mobile navigation. Confirm the final response and canonical destination with a developer if search visibility is involved. The incident is not closed merely because the homepage still works.