404s on Every Page Except the Homepage: How to Fix It

If your homepage loads but every other page returns a 404, the problem is usually not your content — it’s WordPress routing or your web server rewrite rules. In most cases, fixing permalinks, rebuilding rewrite rules, or correcting .htaccess/nginx config will bring the site back without touching posts or pages.

The key is to start with the safest checks first: confirm the pages really exist, then flush permalinks, then inspect rewrite configuration. If the site is on a managed host, the issue may sit in server config rather than WordPress itself.

What this problem usually looks like

This error pattern has a very specific shape: the front page loads, but clicking any inner page, category, product, or post sends you to a 404 page. Sometimes the URLs look normal in the browser bar, but WordPress cannot map them to the right content.

You may also see one of these variations:

• Only the homepage works; all other pages 404.
• Only posts 404, but pages work, or the reverse.
• Pretty permalinks stop working after a migration or update.
• Category archives and product pages fail, but the site root is fine.
• The site works in the admin area, but front-end URLs break.

If the homepage loads from cache while other URLs fail uncached, the problem can look intermittent. That’s why it helps to test in an incognito window and, if possible, with caching temporarily bypassed.

The most likely causes

When only the homepage works, the usual cause is that WordPress rewrite rules are missing, stale, or being overridden. The homepage can still load because it does not rely on the same routing rules as inner permalinks.

One clue: if your homepage URL is something like / and the broken URLs are clean permalinks like /about/ or /blog/post-name/, this is almost always a rewrite problem, not a content problem.

Safe fixes to try first

1) Confirm the pages actually exist

Open the page in the WordPress admin and make sure it is published, not trashed, and not set to a private or password-protected status. If you recently changed the page slug, make sure your menus and links still point to the correct URL.

If you can reach the editor, open the page and click “View” or “Permalink” to compare the stored URL with the one returning 404.

2) Flush permalinks

This is the simplest and safest fix, and it solves a large share of “homepage only works” cases.

1. Back up the site first.
2. Go to Settings > Permalinks.
3. Without changing anything, click Save Changes.
4. Test a few broken URLs again.

This forces WordPress to regenerate its rewrite rules. If the problem was just stale routing data, the site will start working immediately.

3) Check the web server rewrite file

If saving permalinks does not help, inspect the server-level rewrite setup. On Apache, WordPress typically relies on a valid .htaccess file in the site root. On nginx, the rewrite rules live in the server config, not in a file WordPress can edit.

For Apache, the default WordPress rules should usually resemble this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

If your .htaccess file is missing, corrupted, or has custom rules above the WordPress block, that can break inner pages while leaving the homepage intact.

For nginx, the issue is often a missing or incorrect try_files rule. That is host-level configuration, so if you do not control nginx directly, ask your host to verify the WordPress block.

4) Temporarily disable plugins that touch URLs

Some plugins add custom post types, change permalink structure, or rewrite URLs in ways that break routing. Common examples include SEO plugins, membership plugins, e-commerce plugins, multilingual plugins, and redirect tools.

If you can still reach wp-admin, disable plugins that affect URLs one by one and test after each change. If you cannot get reliable access to the dashboard, rename the /wp-content/plugins/ folder over FTP or file manager to disable all plugins at once, then test again.

If the site comes back after that, reactivate plugins in batches until the faulty one is identified. If you need a structured way to undo a bad plugin change, see How to Roll Back a Bad WordPress Plugin or Theme Update.

5) Switch briefly to a default theme

Theme code can also add rewrite rules, especially for custom templates or custom post types. If you suspect the theme, switch temporarily to a default WordPress theme such as Twenty Twenty-Four and test the broken URLs again.

Do this carefully if the live site is busy. Back up first, and if possible test on staging. A theme switch will not normally delete content, but it can change how the front end renders.

6) Check for a bad migration or domain change

If the problem started after moving hosts, changing domains, or switching from a subdirectory to the root, recheck these basics:

• Site URL and WordPress URL in Settings > General.
• Whether the domain points to the right document root.
• Whether the rewrite rules match the new install path.
• Whether old links are hardcoded in menus or content.

A site can look fine on the homepage after a move while inner URLs still point to the old structure or hit the wrong filesystem path.

7) Look for caching layers masking the real issue

Sometimes the homepage is cached and appears healthy while every uncached inner page returns 404. Clear any page cache, server cache, CDN cache, and browser cache, then test again from an incognito window.

If you use a CDN, make sure the 404 is coming from the origin and not from an edge rule or page rule that only affects certain paths. Caching is not usually the root cause here, but it can hide it.

How to tell whether it is WordPress or the server

This distinction matters because it tells you where to fix the problem.

• If saving permalinks fixes it: the issue was stale WordPress rewrite data.
• If Apache works after restoring .htaccess: the file was the problem.
• If only nginx sites fail: the server config likely needs adjustment.
• If disabling one plugin fixes it: that plugin altered routing.
• If switching themes fixes it: the theme or custom code added bad rewrite rules.

If you want a systematic way to isolate the cause instead of guessing, the same approach we use for 500s applies here too: make one change at a time, test the result, and keep notes. Our guide on how to read WordPress debug logs and find the real problem can help if you suspect code is involved.

What not to do

When a site is returning 404s, it is tempting to start changing many things at once. That makes the root cause harder to find and can create a second problem on top of the first.

• Do not delete pages or posts that already exist.
• Do not mass-edit slugs unless you have confirmed a slug conflict.
• Do not overhaul the theme before checking permalinks and server rules.
• Do not keep guessing at plugin settings if you have not isolated the culprit.
• Do not edit live server config without a backup or a rollback plan.

How to prevent this from coming back

Once the site is fixed, the best prevention is boring maintenance and careful change control.

• Take a backup before plugin, theme, or hosting changes.
• After migrations, always test the homepage plus several inner pages, not just the front page.
• Keep a note of any plugin that adds custom post types, multilingual routing, or URL rewrites.
• Avoid stacking multiple plugins that all manage redirects or permalink behavior.
• Use staging for domain moves, theme changes, and major plugin updates.
• After any structural change, revisit Settings > Permalinks and save once.

If you manage more than one site, a backup-and-update routine helps prevent a lot of routing surprises. Our Care Plan covers managed updates, backups, security, and uptime monitoring if you want ongoing help keeping this sort of issue from recurring.

When to call a professional

Call for help if the site is live, the issue started after a migration, the server uses nginx or another nonstandard setup, or you have already flushed permalinks and checked plugins without finding the cause. At that point, the fix may require server access, careful config edits, or tracing a custom rewrite rule without breaking the rest of the site.

If you want a senior engineer to diagnose it without the back-and-forth, start with a free diagnosis at /start/diagnosis. If the site is down for visitors and you need a fast repair, /start/emergency is the quickest path. Mend works backup-first, shares no passwords, and sends a plain-English report of what caused the problem and exactly what changed.

If you already know the issue is likely rewrite-related but you want it handled quickly, /start/quick_fix is the right fit for many single-issue WordPress repairs.

A quick diagnosis checklist

If you are in a hurry, use this order:

1. Back up the site.
2. Test a few broken URLs in incognito mode.
3. Save Settings > Permalinks again.
4. Check .htaccess on Apache or rewrite rules on nginx.
5. Disable URL-related plugins.
6. Test with a default theme.
7. Review recent migration, domain, or server changes.

In most cases, one of those steps will expose the real issue quickly.