WordPress 404 after a permalink change: why your posts go missing

Why does WordPress give a 404 after a permalink change?

WordPress does not read your permalink setting on every visit. It turns the setting into a list of rewrite rules, stores that list in the database and matches each address against it.

Change the structure, or add a plugin that brings a new post type, and the stored list is out of date until something rebuilds it. Any address the old list cannot match gives a 404.

Finding why a site’s links stopped working, on a copy so the live site stays up, is part of our WordPress maintenance work.

How did we test it?

On 17 Oct 2026 we set up WordPress 7.1.3 on PHP 8.3.33 in WordPress Playground, with permalinks set to post name. It started with 94 stored rewrite rules, and the Hello world post loaded at /hello-world/.

We wrote one small plugin for the test. It adds a recipe post type at /recipes/ and, like many hand-written plugins and theme snippets, never rebuilds the rules. We switched things on by writing the settings straight to the database, so nothing rebuilt the list for us, and checked each address with curl.

What happens when a plugin adds a new post type?

We switched the recipe plugin on and published a recipe called Lab Lemon Soup.

Its pretty address, /recipes/lab-lemon-soup/, gave a 404. The plain address, /?recipe=lab-lemon-soup, loaded with a 200. The stored list still held 94 rules and none of them for recipes.

That split is the tell. When the plain link works and the pretty one does not, the content is there and only the rule is missing.

After one rebuild the list held 111 rules, 17 of them for recipes, and the recipe loaded at its pretty address.

What happens when you change the structure?

We changed the structure to year, month and post name, and stopped short of rebuilding the rules.

The old address, /hello-world/, answered with a 301 to /2026/10/hello-world/. That new address gave a 404. So a visitor clicking an old link was sent on to the new one and landed on “not found”.

The redirect makes the change look done, and the 404 makes the post look deleted. Neither is true. The list was stale.

After a rebuild, /2026/10/hello-world/ loaded with a 200, and the old /hello-world/ still sent a 301 to it, so old links kept working.

How do you fix a 404 after a permalink change?

Rebuild the rules:

1. Go to Settings > Permalinks in the dashboard.
2. Leave the structure as it is.
3. Click Save Changes.
4. Open a post, a page and, if you have one, a product or other custom type.

The screen runs the same rebuild our lab ran, flush_rewrite_rules(). In the WordPress source for the Permalinks screen, read on 17 Oct 2026, that call sits after the save handler and before the page is drawn, so it runs each time the screen loads, including the reload straight after a save. The flush_rewrite_rules() reference also says it is costly and belongs on plugin activation, not on every page load. A plugin that rebuilds the rules on every visit slows the site down, so a one-time save is the fix, not a snippet that keeps running.

If you write your own post type, the register_post_type() reference notes that its rules need a flush, which is the step our lab plugin left out.

What if saving permalinks does not fix the 404?

Then WordPress has the right rules and the web server is not using them. On Apache, check the .htaccess file in the site folder. It needs the block between # BEGIN WordPress and # END WordPress that the WordPress .htaccess guide shows. It also fails when the file cannot be written, or when the host has turned off overrides or mod_rewrite. On nginx the site’s config needs the try_files line from the WordPress nginx guide, which hands unknown addresses to index.php.

A cache can also keep serving an old 404 after the fix. Clear the caching plugin and any CDN, then test in a private window.

We do this as a single fix. On a staging copy we check the stored rules, the .htaccess or nginx config and the cache, and hand back working links with the old addresses still redirecting.

What did we not test?

• Apache and nginx. Playground serves PHP itself, so a missing .htaccess, overrides switched off or mod_rewrite missing could not be reproduced.
• The Permalinks screen itself. We ran the function its source calls, not the button.
• Multisite.
• Caching plugins or a CDN holding an old 404.
• A post type from a real plugin. The recipe plugin was ours.

Are your links giving 404s right now?

Tell us which addresses fail and what changed last, and we will say whether it is the rules, the server or the cache.

Not sure the 404s are the only problem? Send your site address for the free site check, and a written reply comes within 2 business days. If the 404s started with a redirect loop instead, our guide to ERR_TOO_MANY_REDIRECTS in WordPress covers that one.