Why WordPress Pages 404 but the Homepage Works

If your WordPress homepage works but every other page returns a 404, the problem is usually not the content itself. It’s typically a permalink, rewrite, or server routing issue, which means WordPress cannot map URLs to the right page.

The safest fix is to start with permalink settings and then check the web server rules, page slug conflicts, and any recent changes to your theme, plugins, or hosting setup. Back up first if you’re about to edit files or server config.

What this problem looks like

This issue usually shows up in one of these ways:

• The homepage loads normally, but about, blog posts, product pages, or any other internal URL shows a 404.
• WordPress admin may still work, but clicking a page from the front end fails.
• Some URLs work and others do not, especially after moving the site, changing hosts, or updating plugins.
• The 404 page may come from WordPress, or it may be the server’s own 404 page, which tells you where to look next.

That last detail matters. A WordPress-style 404 usually means WordPress is receiving the request but cannot find a matching route. A server-style 404 can mean rewrite rules or hosting configuration are bypassing WordPress entirely.

The most likely causes

When the homepage works but inner pages fail, the cause is usually one of these:

• Broken permalinks — WordPress rewrite rules need to be refreshed.
• .htaccess problems on Apache or LiteSpeed — the rewrite file may be missing, unreadable, or overwritten.
• Nginx routing issues — the site may need a different try_files rule.
• Plugin or theme changes — a custom post type, multilingual plugin, or SEO plugin may have changed rewrite rules.
• Slug conflicts — a page, category, or custom post type may be sharing a URL path.
• Migration leftovers — the site may still be carrying old paths, bad canonical settings, or incorrect site URLs.
• Security or cache layers — edge caching, security rules, or redirect rules can mask the real problem.

Start with the safest fix: refresh permalinks

This is the first thing I’d try because it often solves the issue in under a minute and does not require code changes.

1. Sign in to WordPress.
2. Go to Settings > Permalinks.
3. Do not change anything yet. Just click Save Changes.
4. Test a few broken URLs again.

Saving permalinks forces WordPress to regenerate its rewrite rules. If the issue was caused by stale routing data, this alone can fix every broken page.

Check whether the server is actually rewriting URLs

If refreshing permalinks does not help, the next step depends on your web server.

If you are on Apache or LiteSpeed

WordPress depends on a working .htaccess file for pretty permalinks. Check whether:

• .htaccess exists in the site root.
• It contains the standard WordPress rewrite block.
• The file is writable by WordPress when you save permalinks.

If the file is missing or damaged, WordPress may still load the homepage but fail to route deeper pages. Restoring the standard WordPress block and saving permalinks again often resolves it.

If you are on Nginx

Nginx does not use .htaccess. The site needs a correct server block that passes requests to WordPress when a file or directory does not exist. If that routing rule is wrong, the homepage may still load while everything else 404s.

On Nginx, this is usually a host-level fix. If you do not have direct access to server config, ask your host to verify the WordPress rewrite rules for the site.

Look for a slug or page conflict

Sometimes the problem is more specific than “all pages.” One page, post type, or section of the site can override another URL path and cause unexpected 404s.

Common examples include:

• A page named blog conflicting with the posts archive.
• A custom post type using the same base slug as a page or category.
• A multilingual plugin generating alternate paths that no longer match the site structure.
• An SEO or redirect plugin sending one URL pattern to the wrong destination.

To test for conflicts, temporarily rename one problem page slug, or check whether the broken URLs share a common prefix such as /shop/, /blog/, or /services/. If only one section fails, the issue is usually a route conflict rather than a global permalink problem.

Test for a plugin or theme rewrite bug

Plugins that register custom post types, taxonomies, or redirects can change how URLs are matched. If the 404s began right after an update, that is a strong clue.

Use this order:

1. Back up the site first.
2. Disable recent plugins one at a time, starting with SEO, redirect, multilingual, membership, and custom post type plugins.
3. Test the broken pages after each change.
4. If needed, switch briefly to a default theme to rule out a theme-level rewrite issue.

If the pages start working after a specific plugin is disabled, you likely found the cause. Re-enable it only after you confirm whether the plugin needs a settings change, a rewrite flush, or a compatibility fix.

Check your site URLs after a migration or domain change

If the site was recently moved, cloned, or had its domain changed, bad URL settings can produce strange routing problems. Make sure WordPress Address and Site Address are correct in Settings > General.

Also check for:

• Old domain names hard-coded in a theme or plugin.
• Redirect plugins sending inner pages to stale paths.
• CDN or cache layers still serving old versions of URLs.

If the homepage is cached correctly but inner pages are not, clear every cache layer: WordPress cache plugin, host cache, CDN cache, and browser cache.

Make sure the 404 is not coming from a security rule

Security plugins, firewall rules, and host-level protection can sometimes block URL patterns and make the result look like a normal 404. This is especially common if the site has a custom login path, translated slugs, or rules that block certain query strings.

If the 404s affect only selected paths and basic permalink refreshes do nothing, review recent security changes, WAF rules, and redirect rules. Hosts often log these blocks, even when WordPress itself does not.

If you have access to logs, they can save time

When the cause is not obvious, server logs often show whether the request reached WordPress, was redirected, or was blocked before routing happened.

Look for:

• Access logs showing the requested URL and status code.
• Error logs showing rewrite failures, missing files, or permission issues.
• Plugin logs if a redirect or security plugin is involved.

If you are not comfortable reading logs, that is a good point to stop guessing. A quick review by an engineer can usually identify whether this is a rewrite issue, a plugin conflict, or a host configuration problem.

How to prevent this from coming back

Once the site is fixed, these habits help keep it stable:

• Back up before major updates.
• Test plugin and theme changes on a staging site when possible.
• Keep permalink changes intentional and documented.
• Use a maintenance routine that includes checks for broken routes after updates.
• Keep redirects, security tools, and caching layers as simple as possible.

If your site uses custom post types or multilingual routing, treat URL structure like application code: changes should be tested, not improvised on a live site.

When to call a professional

If refreshing permalinks did not fix it, and you are now looking at server files, Nginx config, plugin rewrite settings, or log files, it is reasonable to hand this off. The wrong change can turn a 404 issue into a site-wide outage.

If you want this diagnosed quickly and safely, start with free diagnosis. If the site is down or revenue is being lost, Emergency Rescue is the fastest path, and Mend’s senior engineers will work backup-first and explain exactly what changed when the fix is done.

You can also review the broader WordPress fix guides library if you want to compare symptoms, or connect the site securely through Mend Connect without sharing passwords. Mend is independent and not affiliated with or endorsed by the WordPress Foundation or Automattic.

Related reading

• How to Fix the WordPress 500 Internal Server Error
• What a Good WordPress Maintenance Routine Looks Like