The home page opens normally. Click anything else, an About page, a blog post, a product, and you get “404 Not Found”. Sometimes it is your theme’s own “Page not found” screen; sometimes it is a plain white server page that says “Not Found. The requested URL was not found on this server.” The content is still in the dashboard. It just will not open.
That particular pattern, home page fine and everything else missing, is one of the most recognisable faults in WordPress. It almost never means your pages are gone. It means the server no longer knows how to hand pretty addresses such as /about-us/ over to WordPress. The fix is usually quick once you know which part of the chain broke.
Why the home page survives
WordPress pages do not exist as separate files on the server. There is no about-us folder. Every request is meant to be passed to one file, index.php, which looks at the address, finds the matching page in the database and builds it.
The home page works because a request for / goes to index.php by default on almost any server. Every other address relies on rewrite rules, instructions that tell the server: “if the requested file does not exist, send the request to index.php instead”. Remove or ignore those instructions and the server goes looking for a real /about-us/ folder, finds nothing, and returns 404.
WordPress also keeps its own internal list of rewrite rules in the database, which maps addresses to content. If that list is out of date, WordPress itself returns a 404 even when the server passes the request on correctly. So there are two layers: the server’s rules and WordPress’s rules.
Is this your problem, or a different 404?
It is worth ruling out the look-alikes first, because they need different fixes.
- Only some old addresses 404 after a redesign or a change of URL structure. That is a redirect problem, not a rewrite problem; our post on 404 errors after a redesign deals with it.
- Individual links inside your content point to the wrong place. That is a broken link problem; see finding and fixing broken links.
- Every page, including the home page, fails with a server error or a blank screen. That is a different family altogether, covered in our guide to WordPress errors.
Here is a quick test that confirms you are in the right place. Find the ID of a page (hover over its title in the Pages list; the edit link contains post= and a number). Visit https://yoursite.com/?page_id= followed by that number. If the page opens with that plain address but not with its normal one, the rewrite rules are the problem.
Causes, most likely first
- The .htaccess file is missing, empty or overwritten. On Apache and LiteSpeed servers, WordPress’s rewrite rules live in a file named
.htaccessin the site’s main folder. Security plugins, caching plugins, a migration tool or a person editing by hand can remove or damage the WordPress block. - The site was moved to a new server. Hidden files such as
.htaccessare easy to leave behind when copying files. A move from Apache to Nginx is a classic trigger too, because Nginx ignores.htaccesscompletely. - WordPress’s internal rules are stale. This often follows activating a plugin that adds a custom post type (portfolios, events, products) or changing the permalink setting, and it tends to affect only that type of content.
- The server is not reading .htaccess. The Apache rewrite module may be switched off, or the server configuration may ignore
.htaccessfiles for that folder. This usually appears on a fresh server or VPS. - The site lives in a subfolder and the rules still point to the root, or the reverse.
Fixes, from gentlest to most hands-on
Download a copy of your current .htaccess (or your whole site) before you change anything. If the edit makes things worse, you can put the original back in seconds.
Step 1: re-save the permalink settings
In the dashboard, go to Settings > Permalinks. Do not change anything. Just click Save Changes. This makes WordPress rebuild its internal rewrite rules, and on Apache it will also try to write the correct block into .htaccess if it has permission to. Then test a page in a private window, after clearing any cache.
This one click fixes a large share of cases, especially those caused by newly added custom post types.
Step 2: check the .htaccess file
Open the site’s main folder in your host’s file manager or over FTP. You may need to enable “show hidden files”. Open .htaccess and look for the WordPress section. For a site installed in the root folder, the standard block looks like this:
# BEGIN WordPress
<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>
# END WordPress
If the file is missing, create it with that block. If the WordPress section is missing, add it. Leave other sections (from your caching or security plugin, for example) in place, but make sure none of them sits inside the WordPress markers. If the site is in a subfolder such as /shop/, the RewriteBase and last rule need that folder in them, which is why re-saving permalinks is the better way to generate the file when WordPress can write it.
If WordPress cannot write the file, Settings > Permalinks usually shows the rules for you to copy at the bottom of the page after saving. Wrong file permissions are often the reason; our post on WordPress file permissions explains what they should be.
Step 3: if the server runs Nginx
Nginx does not read .htaccess, so adding the block above changes nothing. The equivalent rule lives in the server configuration, usually inside the site’s location / block:
try_files $uri $uri/ /index.php?$args;
On most managed hosting you cannot edit this yourself. Ask your host to confirm that the WordPress rewrite rule is present for your site. If you are not sure which server you are on, Tools > Site Health > Info > Server usually shows it.
Step 4: confirm the server allows rewrites
On a server you manage, check that Apache’s rewrite module is enabled and that the site’s configuration allows .htaccess overrides. On shared hosting this is the host’s job; a short message saying “plain permalinks work, pretty permalinks 404, please check mod_rewrite and AllowOverride” will get you to the answer faster.
Step 5: look for a plugin interfering
If the rules are correct and pages still 404, a plugin may be changing rewrite rules or intercepting requests. Redirect managers, multilingual plugins, membership plugins and security plugins that hide the login page are the usual suspects. Test on a staging copy by deactivating them one at a time and re-saving permalinks after each.
Only one kind of content 404s
If normal pages work but every portfolio item, event or product returns 404, the content type was probably registered after the rules were last rebuilt, or two things are using the same base word in their addresses (for example, a page called “shop” and a post type also using /shop/). Re-save permalinks first. If that does not help, look for clashes between page slugs and the bases used by your plugins.
When the fix works for you but not for visitors
Caches can store a 404 just as they store a working page. If you repair the rules and inner pages open for you while logged in, but visitors or a private window still get “Not Found”, purge your caching plugin, any host cache and your CDN. Some CDNs keep error responses for a short time on purpose. Search engines may also have recorded the errors; once pages load again, they normally pick that up on their next visit, and you can check the affected addresses in Google Search Console if you use it.
If this started right after a move
Rewrite trouble is one of several things that tend to go wrong together when a site changes host or domain. Old addresses stored in the database, missing hidden files and a different server type all show up in the first hour. Our post on errors after migrating WordPress goes through that whole checklist, so it is worth reading if inner pages are only one of the problems you are seeing.
Preventing it next time
- When moving the site, check that hidden files came across, and test inner pages straight away, not just the home page.
- When changing hosts, ask whether the new server is Apache, LiteSpeed or Nginx, and plan the rewrite setup accordingly.
- Keep a copy of a working
.htaccesssomewhere safe. - After activating any plugin that adds a new content type, visit Settings > Permalinks and save.
- Do not edit the WordPress section of
.htaccessby hand unless you have to; let WordPress manage it.
When to hand it over
If plain addresses work but nothing you change in WordPress makes the pretty ones load, the fix is almost always at server level, and that can mean talking to your host in their terms. If you would like us to do that part, send a link to one failing page and tell us what changed recently. We will copy the current configuration first, find which layer is broken and explain the fix. Our bug fixing service page sets out how we handle jobs like this.
Next in this series: WordPress Changes Not Showing? Clear the Right Cache
