Changing the permalink structure on a live WordPress site changes the address of every post at once. If you have decided to do it, build the permanent redirect from each old address to its new address before you save the setting. A new structure saved without redirects leaves outside links and search listings pointing at addresses that no longer exist. Whether you run a blog, a company site or a small shop, the mapping table, the sample rules and the rollback plan turn the change into a controlled piece of work.
Choosing the first structure is a different job; for general address rules see URL structure and slug best practices. A structure change on the same domain is not a domain or server move, and preserving backlink value during a site migration covers that wider case.
What breaks when addresses change
The documentation's position
The WordPress permalink documentation (Opens in a new tab) describes permalinks as the permanent URLs of posts, pages, categories and other archives, and says they should never be changed. It lists who uses the address: another blogger linking to your article, a social media share, an email to a friend, and Google when it indexes the article. Changing the structure therefore touches copies of your address that you do not control.
Copies you cannot edit
Think about where an address lives before you touch the setting: links on other sites, newsletter archives, printed QR codes, social posts and search listings. None of these can be corrected one by one. The only workable correction is a redirect from the old address to the new one.
What Google does with a missing address
The Google documentation on HTTP status codes (Opens in a new tab) says all 4xx errors except 429 are treated alike, including 404 and 410. The page is treated as nonexistent, a URL that was indexed before is removed from the index, and newly encountered 404 pages are not processed. The documentation does not say how large the resulting loss is, so plan as if every unredirected address is lost.
Is the change worth it?
Not every structure deserves a migration. Look at what the current structure actually costs.
| Current situation | Reason to change? | Suggested move |
|---|---|---|
| Addresses look like ?p=N, the Plain structure | Yes | Move to a readable structure; fewer posts means lower risk |
| Structure ends in %postname% or %post_id% and addresses work | Not by itself | Leave it; taste alone does not justify moving every address |
| Dates are in the address and the content is evergreen | Conditional | Plan the move if dated addresses are creating a real problem |
| A category appears in the address and categories are being redesigned | Conditional | Fix the category names first, then move once |
| Posts return 404 after a recent edit | No, repair first | Check the server rules instead of changing the structure |
A go or no-go rule
- Does the current address do measurable harm to readers or editors? If not, stop.
- Can every old address be assigned exactly one new address? If not, the map is unfinished.
- Do you hold a backup and a written record of the old setting? If not, do not begin.
Practical suggestion: if any answer is no, postpone. A half-prepared migration creates more work than a migration never started.
Building the redirect map
Collect every address
The raw material is a list of every address under the old structure. Count posts, pages, category and tag archives and author archives separately. Post addresses change with the structure while page addresses and the category and tag bases may not, which narrows the list. The XML sitemap, the post list in the dashboard and the server access logs together give a fuller picture; XML sitemap audit and error fixes explains how to read the sitemap output.
The layout of the map
One row ties one old address to one new address. Fixed columns make later checking easier.
| Old address | New address | Status to return | Check |
|---|---|---|---|
| /2024/05/sample-post/ | /sample-post/ | 301 | Does the new address return 200 |
| /2024/06/second-post/ | /second-post/ | 301 | Does it arrive in one step |
| /category/guides/sample-post/ | /sample-post/ | 301 | Does another rule collide |
| /retired-page/ | No equivalent | Retirement decision | Nearest topic page, or a 404 |
Addresses that collide
Two posts published on different dates can carry the same slug. Under a structure without dates they would fight for one address. Rename one slug first, then write the mapping. Practical suggestion: sort the new-address column and look for duplicates; a duplicate means a collision.
Choosing the redirect status
The Google redirect documentation (Opens in a new tab) lists HTTP 301 and 308 server redirects, instant meta refresh and JavaScript location changes as permanent redirects. Temporary redirects are HTTP 302, 303 and 307 and delayed meta refresh. With a permanent redirect the indexing system treats the redirect as a signal that the target should be canonical. With a temporary redirect it does not, and the source page stays in results.
Why the server side is preferred
The documentation recommends a permanent server-side redirect whenever possible, because it best ensures users and Google reach the right page. JavaScript redirects are named a last resort when neither server-side nor meta refresh redirects are possible. Its examples are Redirect and mod_rewrite in Apache and return and rewrite in NGINX.
Permanent or temporary during the rollout
The documentation advises permanent redirects when you are sure the redirect will not be reverted, and temporary ones for short-term situations. Practical suggestion: if you are still testing and may reverse the change, use a temporary redirect until you are certain, then switch to 301. The documentation does not say how long a redirect should stay in place.
Writing the rules on Apache
This section applies to Apache servers. If your server runs Nginx, the rules live in the server configuration, and the WordPress .htaccess documentation says nothing about Nginx. If you do not know which server you have, ask your hosting provider.
The core WordPress block
The WordPress Apache HTTPD and .htaccess documentation (Opens in a new tab) says WordPress modifies the file to handle pretty permalinks. The basic block it gives is this:
# BEGIN WordPress
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]
# END WordPress
The same page says it can be used to restore a corrupted .htaccess file, for example one damaged by a misbehaving plugin.
One pattern rule for a whole family
If the old structure was year, month and post name and the new one is the post name alone, one pattern rule can cover every old post. The sample rule uses the RedirectMatch directive from Apache's mod_alias module:
RedirectMatch 301 ^/[0-9]{4}/[0-9]{2}/([^/]+)/?$ /$1/
The pattern does not touch year and month archive pages, because it requires a post name after the year and month. It can still match another path with the same shape, such as /2024/05/feed/, where feed would be read as a post name, so test feed and similar addresses too. Practical suggestion: test the rule on a staging copy with a handful of real addresses before it goes live. The documentation does not say whether such a rule belongs inside or before the WordPress block; keeping it outside the block, in its own section, is a sensible choice but should be confirmed on your own server.
Avoiding chains
If the new address trips a second rule, a redirect chain appears. An old address that goes first to a slash-less address and then to a slash version takes two steps. Write the destination as the final canonical address. Redirect chains and loops shows how to find and repair them.
Everything that points at the old address
The sitemap
A redirect rescues the old address, but the sitemap must show the new ones. If it keeps listing old addresses, every entry returns a redirect. Practical suggestion: regenerate the sitemap on cutover day and sample its entries to confirm they return 200.
Internal links
Redirects are a safety net for outside copies, not for your own links. Update hard-coded old addresses in post bodies, menus and widget areas. For a bulk search and replace in content, take a database backup first and open several posts by hand afterwards.
Canonical tags
Canonical values written by a theme or plugin should show the new structure. A tag that names the old address as canonical contradicts the redirect. Check which plugin outputs the canonical, and clear its cache after cutover.
Who links to the address decides the order
| Type of address | How you find it | Priority |
|---|---|---|
| Post with links from other sites | Backlink report or referring-domain list | High: one-step 301 required |
| Post that brings search visits | Search Console performance report, analytics | High: watch first after the switch |
| Post shared in newsletters or social posts | Send archive, posting calendar | Medium: open campaign links by hand |
| Old post with no visits | Access logs, analytics | Low, but still redirected if the pattern covers it |
If you use the Search Console interface in a language other than English, report names can look different.
Cutover day
- Take a full database and file backup. Copy the old permalink setting and the .htaccess contents into a text file.
- Review the map one last time and remove duplicate new addresses.
- Write the redirect rules, then save the new structure under Settings, Permalinks.
- Open a sample of real old addresses and confirm the address bar moves to the new address and the new address returns 200.
- Regenerate the sitemap and confirm it holds no old address.
- Update internal links and menus, and verify the canonical tag on a sample post.
- Clear the cache plugin and any CDN cache.
Draw the sample from several types: posts, pages, category archives and attachments. On a large site, enlarge the sample.
Verification table
| Requested address | Expected response | Symptom of trouble |
|---|---|---|
| Old post address | 301 to the new address | 404, 302 or a two-step chain |
| New post address | 200 | 404 or a fall back to the home page |
| Address of a retired post | 301 to a close page or a 404, as decided | Bulk redirect to an unrelated page |
| Sitemap entries | 200 | Entries that return a redirect |
| Page canonical | The page's own new address | A tag naming the old address |
The status meanings are laid out in the HTTP status codes guide.
After the switch: monitoring and rollback
What to watch
Watch for 404 responses on old addresses. Google removes previously indexed URLs that return 404, so every missed address is a loss. Server errors are a separate problem: the Google documentation says 5xx and 429 responses make its crawlers slow down for a while, and that indexed URLs are eventually dropped if errors persist.
The first week
- Day one: open every priority address by hand and confirm the sitemap is live on the server.
- Day three: pull the busiest old addresses that return 404 from the access logs and add the missing rows to the map.
- Day seven: crawl the site for internal links still using old addresses and fix them.
- Record each fix with a date. The record doubles as evidence for a rollback decision.
If the host runs a server-level cache, you may need to clear it before the new rules take effect. The documentation says nothing about caching, so list cache clearing as its own item and test the rule with a request that bypasses cache.
The rollback plan
Rolling back means restoring the files from backup and saving the old permalink setting. Remove or disable the redirect rules at the same moment; otherwise the old addresses work again while the rules keep sending them to the new ones. Set the triggers before you start: new addresses not opening within the first day, server errors, or a redirect loop can each be a reason to roll back.
Example scenario: a travel photography blog
Example scenario: A photographer has run a travel blog under a year and month structure. The posts are trip stories that do not age, and the dates in the address make them look dated. She wants post names only.
- She answers the three questions: the dated look is a real issue, one pattern rule can map the posts, and a backup is possible.
- She exports the post list and finds two trips that share a slug. She renames one.
- Her host runs Apache, so she writes one RedirectMatch rule in its own section, away from the WordPress block.
- She saves Post name and opens six old addresses, including one with image attachments.
- She regenerates the sitemap and updates the menus that carried dated links.
- For two weeks she checks the logs for 404 responses on old addresses and adds rows for what the pattern missed.
Content that has no counterpart
Every migration turns up posts that you would rather retire than carry across. Decide their fate in the map instead of letting the new structure decide it by accident.
| Kind of old post | Options | Deciding question |
|---|---|---|
| Outdated but still linked from outside | Refresh it and redirect one to one | Is there a reason someone still lands on it? |
| Merged into a newer article | 301 to the newer article | Does the newer article answer the same question? |
| Thin or duplicate with no links | Let it return 404 or 410 | Would a redirect mislead the reader? |
| Private or test content | Remove and let it return an error | Should it ever have been public? |
Redirecting to a related page
A redirect to a close topic page keeps a reader who follows an old link on a useful page. A redirect to a page about something else sends them somewhere they did not ask to go. Practical suggestion: redirect only when a reader who clicked the old link would accept the new page as an answer; otherwise a plain 404 is the honest response. The Google documentation lists 404 and 410 as handled the same way, so either works for content you are retiring.
Writing the decision into the map
Add a column that records why each retired address was handled the way it was. Months later, when someone asks why an address returns 404, the answer is in one cell and nobody has to reconstruct the reasoning.
Working on a copy first
A staging copy lets you test the rules without exposing visitors to errors, but it has limits. The WordPress documentation says the hosting provider is expected to have configured the web server for pretty permalinks, and that you should contact the provider if it has not. A staging site on a different server type or configuration can behave differently from production, so ask the provider whether both environments run the same server software before you trust a staging result.
What a staging test can prove
- That the pattern rule matches the old address shapes you listed.
- That the destination returns 200 and not another redirect.
- That archive pages, such as year and month archives, are not caught by the rule.
What it cannot prove
- How a production cache or CDN will treat the new responses.
- Whether a security rule or firewall on production interferes with the redirect.
- How real crawlers and visitors will behave in the first days.
Treat the staging result as a rehearsal and keep the first-week monitoring plan on the live site regardless.
Readiness items
- A complete list of old addresses exported, not guessed.
- Redirect rules tested on a copy with several sample addresses.
- A backup of the files and the database, and the old setting written down.
- Internal links, menus and related-post blocks reviewed for hard-coded old addresses.
- A named person who watches errors on the day after and a week later.
Mistakes that do the damage
| Mistake | Result | Fix |
|---|---|---|
| Saving the structure with no redirects | Old addresses return errors | Rules first, save second |
| Redirecting every old address to the home page | Readers do not reach the content they wanted; the documentation does not describe the search effect | Map each address to its own counterpart |
| Leaving chains | Extra steps and a risk of loops | Write the final address as the target |
| Forgetting the sitemap | Entries return redirects | Regenerate on cutover day |
| Leaving a temporary redirect in place | The source page can stay in results | Switch to 301 once sure |
| Skipping the cache purge | Old addresses keep showing | Clear plugin and CDN caches |
Categories and tags in the map
The WordPress documentation says category and tag archive URLs use a category base and a tag base, which default to the words category and tag. Changing the post structure does not by itself require those prefixes to change. If the old structure carried the category tag, the category slug appears in each post address, nested for sub-categories, and when a post has several categories only one appears, chosen alphabetically. In that case one pattern rule may not find the right category, and per-post rows are safer.
Sites in several languages
Language plugins can add their own prefix to addresses. The documentation says nothing about how such plugins handle redirects, so read the plugin's own documentation first and give each language its own rows in the map.
A finished redirect that leaves half the job undone
A working redirect rescues the old address, but internal links that still point to old addresses create an extra hop on every click. Updating menus, related-post blocks and hand-typed links is the second half of the job.
Choosing the day and the order of work
The technical steps of a permalink change are only half of the plan. The other half is deciding when to do it, who watches afterwards and what counts as a failed result that triggers rollback.
Example scenario: a small guesthouse blog
A guesthouse publishes frequent posts in summer and few in winter. The team moves the change to a quiet week, because a redirect mistake then reaches the fewest visitors. They also agree that the person who ran the change does not review it alone; a second person opens a handful of old addresses on a phone and on a desktop.
Writing the rollback trigger first
Practical suggestion: write the rollback trigger before the change, for example that a sample of old addresses fails to reach the right post. A trigger written afterwards bends toward whatever result has already happened.
Frequently Asked Questions
Is changing the permalink structure bad for SEO?
The WordPress documentation says permalinks should never be changed. If you do change them, every old address needs a permanent redirect to its new address. Without redirects the old addresses return errors, and Google removes URLs that return 4xx errors from its index.
Should I use a 301 or a 302?
Per the Google documentation, 301 and 308 are permanent and 302, 303 and 307 are temporary. If you are sure you will not revert, use a permanent redirect.
How long should I keep the redirects?
The Google documentation gives no duration. Practical suggestion: keep the rule for as long as your access logs still show requests for the old addresses.
Can I redirect without editing .htaccess?
The Google documentation names Redirect and mod_rewrite for Apache, return and rewrite for NGINX, and PHP header() calls. Server-side methods are preferred and JavaScript redirects are a last resort.
What if posts return 404 after the change?
Re-save the setting under Settings, Permalinks, then check whether the WordPress block in .htaccess is damaged. The WordPress documentation gives the basic rule block for restoring a corrupted file.
What happens if I roll back to the old structure?
Save the old setting and remove the redirect rules you added. If the rules stay, old addresses start working again but keep being sent to the new ones.
Conclusion
Changing a permalink structure looks like a setting but behaves like an address move. The WordPress documentation says addresses should not change; if you must, build the map, write permanent server-side redirects, switch the sitemap, internal links and canonicals to the new structure, and then watch for 404 and server errors. Write the rollback plan down before you start.
If you are reviewing your content inventory while the addresses change, it is a good moment to strengthen the posts themselves. For growing with articles that serve readers, take a look at our content writing service.
Post a comment
Please log in to leave a comment. Login