What are WordPress permalinks, and where do you change them?
WordPress's documentation defines permalinks as the permanent URLs of your posts, pages, categories and other archive pages, and adds that they should never be changed, which is where the name comes from. So is a permalink just a URL? Yes: it's the URL, chosen so it doesn't move. The pattern for all of them is set on one screen, Settings, Permalinks, and changing that pattern on a live site is the kind of move my site migration work exists for.
The docs sort permalinks into three kinds. Plain ones carry a query string like ?p=123. Pretty permalinks carry words, like /2012/12/30/post-name/. Almost pretty permalinks put /index.php in front, and they're for servers without a true rewrite module. The same screen also holds the category base and tag base, and on a store, WooCommerce's product base.
What is the best permalink structure for WordPress?
Post name, which WordPress writes as /%postname%/. I set it on day one, before a single post or page is published, because a structure that never changes never needs an old address mapped to a new one.
A fresh install often doesn't start there. The documentation says the default is Plain and calls it not user-friendly and not optimized for search engines, though since 4.2 the installer tries pretty permalinks first and falls back to Plain only when they don't work. Google's URL guidance points the same way: readable words rather than long ID numbers, hyphens rather than underscores, and one consistent case, because Google treats /APPLE and /apple as two distinct URLs.
| Setting | What the URL carries | My view on a new site |
|---|---|---|
| Plain | ?p= and the post's database ID | Never. It's the first thing I change |
| Day and name | /%year%/%monthnum%/%day%/%postname%/ | Only for a news site where the date is the point |
| Month and name | /%year%/%monthnum%/%postname%/ | Same problem, one level shorter |
| Numeric | The post's ID from the database | No. A number tells a searcher nothing |
| Post name | /%postname%/ | My default for almost every site |
| Custom structure | Any mix of structure tags | Only when there's a real reason, like keeping an old platform's pattern |
Two more settings sit on the same screen. The category base and tag base are the prefixes in archive URLs, /category/ and /tag/ by default; WordPress lets you rename them but not remove them. WooCommerce's product base puts /product/ in front of product URLs, or the shop page's name with Shop base. I pick these once, before launch, because changing any of them later moves every URL that carries it.
When is changing an existing structure worth the risk?
Less often than people think. A structure that's ugly and ranks is worth more than one that's pretty and has to earn its place again, so I ask one question: does the old pattern cost more, every month, than a redirect costs once? If it doesn't, I leave it.
| The situation | My call | Why |
|---|---|---|
| Still on Plain ?p=123 URLs | Change it, with a 301 map | The URLs say nothing, and WordPress's own docs call them not optimized for search |
| Dates in the URLs of posts that get updated | Usually change it | A 2019 in the address of a post rewritten this year looks stale in the results, whatever the page says |
| %category% in the structure, posts in several categories | Worth a look | Only one category can show, the one with the lowest ID in the code, and moving a post between categories moves its URL |
| A misspelled or clumsy slug on a page that ranks | Leave it | The spelling isn't what's holding it back, and the redirect puts the ranking at risk |
If the change is part of a bigger redesign, the build is your developer's job. What I own is the search side: the URL list, the map and the checks either side of launch.
Rather have me do this? One person, whole job.
Book a call on UpworkDoes changing a URL affect SEO?
Yes. Google ranks addresses, so a new URL starts as a new page until Google follows a redirect from the old one. Every link from another site, every bookmark and every internal link still points at the old address, and without a 301 each of them hits a 404.
With a 301, the history moves, but not instantly. Google's guidance on moves with URL changes says rankings may fluctuate while it recrawls and reindexes, and that a medium-sized site can take a few weeks or more before the new URLs show in place of the old ones. So I won't tell anyone a change will be invisible, and I won't give a date for things to settle.
The same page sets the rules I work to: server-side permanent redirects, kept for at least a year, and never a pile of old URLs pointed at one irrelevant page like the homepage, which Google says might be treated as a soft 404.
How I change WordPress permalinks safely, step by step
Saving the Permalinks screen takes one click. All the care goes into what happens before and after it.
- Step 01
Write down the new pattern first
The exact structure tags, whether any category, tag or product base changes, and what happens to pages, which don't use the post structure at all.
- Step 02
Export every URL that exists now
The XML sitemap, a full crawl, the Search Console Performance report by page and a backlink export, which finds old addresses other sites still send people to.
- Step 03
Map every old URL to exactly one new URL
Going from Day and name to Post name, /2019/05/12/slug/ becomes /slug/. I still keep the full list, because the leftovers, like a slug edited since, are where redirects go wrong.
- Step 04
Write the rule as a server-side 301
In the server config or a redirect plugin that sends a real 301 status, written the way the next section shows. I check the response code itself, not the browser.
- Step 05
Rehearse it on a staging copy
Same content, same plugins. I change the setting there, save it, switch the redirects on and leave the live site untouched until the test passes.
- Step 06
Test the whole list over HTTP
Every old URL should answer with one 301 and land on a page that returns 200. Chains, loops, 404s and anything that lands on the homepage get fixed before I go further.
- Step 07
Change the live setting and the redirects together
Both go live in the same few minutes, never a day apart, then I run the full list again against the live domain within the hour.
- Step 08
Update everything that still names the old URLs
Menus, links inside posts, canonicals and the XML sitemap. Google's move guidance names two of these outright: point internal links at the new URLs, and submit the new sitemap in Search Console.
Don't change the setting on the live site to see what happens. The old URLs start failing the moment you save, and if you change it back, anything Google crawled in between has already seen the 404s.
How do I set up the redirects for a permalink change?
With one pattern rule for the structure, and one-off rules above it for the leftovers. These are the three ways I write the Day and name to Post name rule, depending on what the site runs on.
- i.
The Redirection plugin
It has full support for regular expressions. The source is
^/\d{4}/\d{2}/\d{2}/(.+)$with Regex ticked, and the target is/$1, where the captured slug fills in $1. - ii.
Apache, in .htaccess
Outside WordPress's own # BEGIN WordPress block, so saving permalinks doesn't overwrite it:
RedirectMatch 301 ^/\d{4}/\d{2}/\d{2}/(.+)$ https://example.com/$1 - iii.
Nginx, in the server block
rewrite "^/\d{4}/\d{2}/\d{2}/(?<slug>.+)$" /$slug permanent;The quotes matter, because Nginx needs them round a pattern with curly braces, and permanent sends a 301.
| Old URL | New URL | How it's handled |
|---|---|---|
| /2019/05/12/fix-a-slow-store/ | /fix-a-slow-store/ | The pattern rule |
| /2021/03/02/old-slug/, renamed since | /current-slug/ | A one-off rule placed above the pattern |
| /about/, a page | /about/ | No rule: pages don't use the post structure |
| /category/news/ | /category/news/ | No rule, unless the category base changed too |
Why do permalinks 404 after a change?
When the new URLs themselves 404, it's almost always the rewrite rules, not the content. I check these in order.
- i.
Re-save Settings, Permalinks
WooCommerce's documentation says WordPress flushes its rewrite rules when you save, and that clicking Save Changes again, even with no edits, forces WordPress to regenerate them. It's the first thing I try.
- ii.
Check .htaccess on Apache
Pretty permalinks on Apache depend on the rules between # BEGIN WordPress and # END WordPress. If a plugin mangled that block, WordPress's own handbook has the basic version to restore it.
- iii.
Check the Nginx config
Nginx ignores .htaccess, so re-saving writes nothing it reads. The site's location block needs
try_files $uri $uri/ /index.php?$args;as WordPress's Nginx handbook shows. - iv.
Purge every cache
The page cache, the host's cache and the CDN can keep serving the old answer after the rules are fixed.
- v.
Old URLs 404, new ones work
That's a gap in the redirect map, not a rewrite problem. I add the missing rule the day it shows up.
Doesn't WordPress redirect the old URLs on its own?
Partly, for one narrow case. When you edit a single post's slug, WordPress keeps the old slug on record, and its code reference describes a function that redirects a request for that old slug to the current permalink when it would otherwise be a 404.
The same reference says it skips hierarchical post types, and pages are hierarchical, so a renamed page gets no help. And it's about slugs, not structures, so I don't rely on WordPress guessing its way from one pattern to another. I write the rule myself and test it.
After launch I watch the Pages report in Search Console. Old URLs moving to Page with redirect is the healthy sign, and new URLs that sit unindexed for weeks have a diagnosis of their own. If Search Console reports that Google chose a different canonical than the one you set, the old and new URLs are both still answering with a 200, which is two copies of every post and the kind of problem the duplicate content service untangles.
Why did I leave a misspelled URL alone?
Because it ranks. On a WooCommerce jewellery store where I mapped the redirects after a redesign, the turquoise category lives at /tourquoiseferoza/. It pairs the English and Urdu names for the stone, the way Pakistani buyers search, and the English half is spelled wrong.
It's also a misspelled category URL that still ranks at 4.3 on 51,693 impressions between 13 June and 11 September 2026, the window the case study covers. Correcting it would change a URL that ranks, and that's the mistake the store's traffic drop started with: a redesign renamed its addresses without a redirect map. I wasn't going to repeat it for one letter.
If you're weighing a permalink change and want one person to make the call, build the map and test it before anything goes live, that's the URL change work I do, remotely, from the first export to the Search Console checks after.
Book a call on Upwork
