What does re-saving permalinks do, and when do you need it?

What gets rebuilt

WordPress decides what a URL means by comparing it against a list of patterns: this shape is a post, that one a category, another a feed. Building the list is slow, because every post type, taxonomy and plugin contributes to it, so the finished list is stored in the database as the rewrite_rules option and reused on every request.

Saving the Permalinks screen runs a hard flush:

1. the stored list is thrown away and rebuilt from whatever is registered right now;
2. on Apache, the WordPress block in .htaccess is written again; on IIS, the equivalent in web.config;
3. on nginx nothing is written, since its rules live in the server configuration.

That is all. No post is edited, no slug changes, and no redirect is created.

The problems it solves

Everything but the homepage is a 404 after moving hosts. The usual cause is a missing .htaccess: hidden files are easy to leave behind when copying a site. Saving permalinks writes a fresh one. If the file cannot be written, the screen prints the rules to paste in.

A new custom post type's pages are 404. A plugin or theme registered a post type, but the stored pattern list was built before it existed. Well-behaved plugins flush on activation; many do not. Saving once adds the missing patterns.

A changed base or slug is not taking effect. After altering a post type's slug or a taxonomy base in code, old patterns linger until the list is rebuilt.

Feeds, pagination or sitemap addresses 404 after an update. Anything that adds URL patterns, including SEO plugins that serve /sitemap.xml, depends on a current list.

It will not fix a single missing post, a slug typo, or links that point to deleted content. For those, see fixing 404 errors.

Why it has no SEO effect of its own

The stored list is a cache of rules, not of URLs. Rebuilding it with the same structure produces the same addresses for the same content. Search engines cannot tell that it happened.

What does matter for SEO is the 404 period before the fix. If the whole site returned 404 for an hour during a migration, crawlers that visited saw errors. A short outage is tolerated: Google retries, and pages that return to 200 keep their place. A long one leads to URLs being dropped from the index until they are recrawled. So after a move, test a post URL straight away, not just the homepage.

There is a real risk on that screen, though, and it is the radio buttons. Choosing a different structure before saving changes every post URL on the site, with no automatic redirects for the structure change. If you only mean to flush, scroll past the options without touching them and press Save.

A quick diagnostic routine

When several URLs 404 at once:

1. Open one affected address in a private window to rule out a logged-in cache difference.
2. Go to Settings → Permalinks, confirm the selected structure is the one you expect, and save.
3. Reload the address. If it works, the pattern list or .htaccess was stale.
4. If it still fails on Apache, open .htaccess in the site root and look for the block between # BEGIN WordPress and # END WordPress. No block means the file could not be written; fix its permissions or paste the rules in.
5. If it still fails on nginx, the server configuration lacks try_files $uri $uri/ /index.php?$args; for this site. That is a hosting-level fix.
6. Purge any page cache and CDN so stored 404 responses are not served again.

Developers can do step 2 from the command line with wp rewrite flush --hard.

WordPress also rebuilds the list by itself when the stored option is empty, so a database migration that drops it is self-healing. A stale, non-empty list is the case that needs your click.