The short fix: open Settings > Permalinks and click Save Changes to flush WordPress’s rewrite rules, then set up 301 redirects from every old URL pattern to the new one before you tell anyone the URLs have changed. Skipping the redirect step is the most common way a permalink change quietly loses rankings, because an old link can keep loading without ever showing a clean error, which hides the problem from both visitors and Google.
Why it happens
WordPress gives you six permalink formats: Plain, Day and name, Month and name, Numeric, Post name, and a Custom Structure you build from structure tags like %year%, %monthnum%, %day%, %category%, %author%, %post_id%, and %postname%. The official documentation is specific about the one rule that matters: “End your structure with either %post_id% or %postname% so that WordPress can target an individual post.” Miss that, and WordPress has no reliable way to resolve the URL back to a single post.
Most sites settle on Post name, or a custom structure ending in %postname%, because it reads better than the default Plain structure’s ?p=123 query string. Changing that setting looks harmless. What actually happens underneath depends on your server. On Apache, saving the Permalinks screen automatically rewrites your .htaccess file with new rewrite rules, so the new structure works immediately. On Nginx, there is no .htaccess to rewrite at all; Nginx reads its own server block configuration, so a permalink change that works fine on Apache can 404 everywhere on Nginx until someone edits that server config by hand.
The part that actually costs you traffic is what happens to the URLs you already had. WordPress does not generate redirects for you when you change the structure. The reported failure mode is not even a clean 404: an old, now-invalid URL can silently render your homepage instead of an error page. A visitor does not notice anything obviously broken, and neither does Googlebot at first glance. Over weeks, search engines stop seeing a live version of that specific page and quietly drop it from the index, because nothing ever told them the content moved.
Step-by-step fix
1. Pick a structure that ends correctly. Use Post name, or a custom structure ending in %postname% or %post_id%. Avoid Plain unless you have a specific reason to keep it.
2. Save the Permalinks screen, even with no changes. Go to Settings > Permalinks and click Save Changes. This forces WordPress to flush and regenerate its rewrite rules. On the command line, the equivalent is wp rewrite flush. If you are calling flush_rewrite_rules() from your own plugin or theme code, only do it on an activation hook, never on every page load; it is a real performance cost when it runs on every request.
3. If you’re on Nginx, edit the server block by hand. The Permalinks screen save only touches .htaccess. Nginx needs its rewrite location block updated to match the new structure, then a config reload.
4. Check for a missing trailing slash. A custom structure that drops the trailing slash before %postname% parses differently than one that includes it, and can create its own redirect loops or 404s independent of the rest of this fix.
5. Set up 301 redirects from every old URL pattern to the new one. A 301 tells both browsers and search engines the move is permanent, and it is the step that actually prevents the ranking loss. You can do this with a redirect-manager plugin, such as the Redirection plugin’s source URL / target URL mapping, which also logs any 404s it sees afterward so you can catch redirects you missed. Or you can add manual Redirect 301 lines to .htaccess on Apache. Either way, map the pattern, not just a handful of individual URLs, if your old and new structures differ by a whole segment (for example, dropping a date prefix).
6. If you use custom post types, confirm they’re registered as public. A custom post type needs 'public' => true and 'publicly_queryable' => true in its registration for WordPress to generate rewrite rules for it at all. Without that, its URLs won’t resolve correctly no matter which permalink structure you pick.
7. Purge caches. A page cache or CDN edge cache can keep serving a stale 404, or stale old-URL content, even after the redirect is live on the server. Purge before you test.
How to verify it worked
Open a private or incognito browser window, not a logged-in session, since a cached login can mask an error that a real visitor would see. Visit a sample of your old URLs directly and confirm each one returns an HTTP 301 and lands on the correct new URL, not the homepage and not a 404.
While you’re checking URLs, it’s worth confirming the canonical tag on the new URL points to itself and not to the old pattern; see our guide on WordPress canonical URLs for what a correct one looks like. Then check that your XML sitemap has actually updated to the new URLs rather than still listing the old ones, which is a separate and surprisingly common failure covered in our post on a sitemap that stops updating. Once both check out, fold a permalink-structure spot-check into your standing routine; it’s one line item in our broader WordPress SEO checklist.
What to do when the standard fix fails
If old URLs are still broken after you’ve flushed rewrite rules and added redirects, work through these in order.
Redirects got overwritten. Some SEO or caching plugins store their own redirect rules and can silently override or duplicate what you set up in a different plugin. Check whether more than one plugin on the site manages redirects, and consolidate to one.
You’re on Nginx and only touched the WordPress side. The Permalinks screen save does nothing for Nginx. If your host manages the server config, ask them to confirm the rewrite location block was actually updated and reloaded.
A custom post type still 404s. Re-check its registration for 'public' => true and 'publicly_queryable' => true, then flush rewrite rules again after fixing the registration, not before.
Google Search Console keeps showing old 404s or “not indexed” for pages that should be live. That’s frequently a symptom of a page that was accidentally left set to noindex during the migration, not a permalink problem at all; our post on WordPress noindex mistakes walks through how to find those.
Everything above checks out but the old URL still loads something. Purge every layer of cache again, including any CDN, and re-test from a private window. Caching is the most common reason a fix that is genuinely live on the server doesn’t appear to work yet.
Frequently asked questions
Does changing permalinks hurt SEO?
Changing the structure itself does not. Leaving the old URLs unredirected does. The ranking loss comes from the missing 301s, not from picking a new structure.
Do I need a redirect for every single URL?
If your old and new structures differ by a predictable pattern, such as removing a date prefix, one pattern-based redirect rule can cover every affected URL. You only need one-off redirects for exceptions that don’t fit the pattern.
Is Post name really the best structure?
It’s the generally recommended one because it’s readable and ends in %postname% as WordPress’s own documentation asks. A custom structure ending the same way works just as well; there’s no single structure that’s SEO-superior beyond following that rule.
What about WooCommerce product URLs?
WooCommerce has its own product-permalink settings layered on top of the general ones, which is outside the scope of this fix. Check Settings > Permalinks for a separate product permalink section if you run a store.
Leave a Reply