Keep your old URLs unless you have a specific reason to change them. A preserved address needs no redirect, no recrawl, and carries no risk, which makes keeping it strictly cheaper than changing it in every respect. WPBuildAI preserves URL structure by default and changes only what the client asks for or what is demonstrably broken, for three reasons: every changed address becomes a row that has to be mapped, tested, and monitored for years, the aggregate risk of changing 400 URLs lands on a single launch day rather than being spread out, and almost no URL change produces a measurable gain. Here is when changing is justified, when it is not, and how to do it safely when it is.
Why is keeping the cheaper default?
Because a move that preserves addresses is close to invisible to search engines, while a move that changes them is a per URL process with a delay and a failure mode.
Google distinguishes site moves with URL changes from moves without them, and the distinction is not cosmetic. When the same URL returns the same content, nothing has to be relearned. When it does not, every affected address needs recrawling, redirect discovery, and signal transfer.
So preserving a URL removes four things at once. There is no redirect rule to write, no rule to test, no recrawl delay before the page performs at its old level, and no chance of a mistake in that rule costing the page permanently. Multiply by your page count and the difference between preserving structure and redesigning it is the difference between a quiet launch and a month of monitoring.
Preserving also protects what you do not control: links from other sites, bookmarks, links inside old emails and PDFs, references in forum posts and documentation, and QR codes printed on physical material. Every one keeps working with no dependency on a rule staying in place on your server.
Which URL changes are actually worth making?
Three, and they share a property: each fixes a defect rather than expressing a preference.
| Reason to change | What it buys | Risk | Do it during the migration | Verdict |
|---|---|---|---|---|
| http to https | Security, and it is expected rather than optional | Low, a well understood pattern | Yes, combine it with the move | Always worth it |
| Remove platform artifacts | Addresses that outlive the platform you are leaving | Low if mapped properly | Yes | The classic good case |
| Consolidate duplicates | One canonical address per page instead of several | Low, and it fixes an existing fault | Yes, do it once and properly | Worth it |
| Drop dates from article paths | Updated posts stop looking stale | Medium, it touches every post | Only if you actually update old posts | Right for a minority of sites |
| Restructure hierarchy | Clarity for visitors, in theory | High, it touches everything at once | Prefer a separate change later | Rarely worth it during a move |
| Shorter or prettier URLs | A feeling | Medium to high | No | WPBuildAI advises against |
The first three have concrete payoffs and low risk, which is why we recommend making them during a migration: the redirect infrastructure is already being built and tested.
The last row deserves honesty. A URL that reads a little awkwardly costs you nothing measurable, and changing it costs a redirect rule that must survive every future deploy.
Why does changing many URLs at once compound the risk?
Because migration risk is not spread evenly across time. It concentrates on launch day and the fortnight after.
A move that changes 40 URLs has a small, checkable set of things that can go wrong. A move that changes 900 has a set nobody can check by hand, which means the checking has to be mechanical, which means anything the script does not cover goes unverified.
There is also a diagnosis cost. When traffic dips after a launch where everything changed, you cannot tell which change caused what. When traffic dips after a launch where only the platform changed, the list of suspects is short. Structural URL changes are better as a separate project six to eight weeks after the platform move, when the site has settled and any problem has one obvious cause, which is the same reasoning behind the pre-launch discipline in website migration checklist before you switch platforms.
When is keeping an old URL the wrong choice?
When keeping it would perpetuate a fault rather than preserve an asset. Four cases, and they are worth naming so nobody tries to preserve the unpreservable.
| Situation | Why it cannot be kept | What to do instead |
|---|---|---|
| Session or state in the path | The same page has thousands of addresses | Collapse to one clean address, redirect the rest |
| Paths leaking internal structure | Ties public addresses to a platform you are leaving | New clean path, mapped one to one |
| Encoded or broken characters | Already resolving inconsistently as duplicates | Normalize, then redirect every variant |
| Language path contradicting content | Confuses visitors and search engines alike | Correct the path, map the old one |
The test to apply to any proposed change is the same in every case: ask what breaks if this address stays exactly as it is. If the honest answer is nothing, keep it. The same test applied to blog paths, where the structure is usually already fine and the temptation to tidy is strongest, is in how to move WordPress blog posts without losing rankings.
What happens to a URL you keep but no longer use?
Keeping an address is not the same as keeping the page, and the difference matters for pages you are retiring rather than moving.
If a page is genuinely finished, an old campaign, a product you no longer sell, a service you have stopped offering, you have three options and they are not equivalent. Leaving it live and unlinked keeps whatever it earned and leaves stale content representing your business. Redirecting it to the nearest relevant page passes most of its value and gives the visitor somewhere useful to land. Returning gone tells crawlers to stop asking and gives up the value entirely.
The right answer is usually the middle one, and the wrong answer is almost always the first, because unlinked stale pages accumulate until nobody knows which are current. A page nobody links to internally still ranks, still gets clicked, and still describes your business to whoever arrives.
The exception is content with a legal or archival reason to remain exactly as published. That belongs in the keep column with a clear published date on the page, so a reader can see what they are looking at.
Why is consolidating duplicate addresses always worth doing?
Because several addresses serving one page is an existing fault, and a migration is the one moment you are configuring the server from scratch anyway.
If your site answers on both www and non www, on both http and https, and with and without a trailing slash, then several addresses serve the same page. Search engines resolve this reasonably well and you are still asking them to guess, and Google’s guidance on consolidating duplicate URLs is clear that picking one and redirecting the rest beats leaving it ambiguous.
Pick one host form, one protocol, and one trailing slash convention. Redirect everything else to it in a single hop, and make canonical tags, the sitemap, and internal links all use the same form. Getting these rules to interact correctly is where redirect loops come from, so test the combinations rather than each rule alone.
How do you change a URL properly when you do?
Three rules, and all three are simple enough that skipping one is always a choice rather than an oversight.
One permanent redirect per old URL, resolving in a single hop. Google’s redirect guidance treats 301 as the signal that an address has permanently changed, and chains cost efficiency and clarity, so map old addresses directly to final destinations even when your source data already contains an earlier redirect. The file that holds all of this is described in what is a redirect map and how do you build one.
Self referencing canonicals on the new pages. Every new page should declare itself canonical, which is the point of Google’s canonicalization documentation and the migration specific case in do canonical tags matter after a website migration.
Internal links pointing at final addresses. Links that travel through a redirect still work and waste crawl budget on every hop, and that includes links inside old blog posts, which is the tedious part everyone skips.
What should you verify after launch?
Behavior, not intent. Request every old URL and record the status and final destination.
Preserved URLs should return 200 directly, with no redirect at all. Changed URLs should return exactly one 301 to an address that returns 200. Anything else is a defect, and the mechanics are in how to test 301 redirects after a migration.
Then watch Search Console for the pattern that confirms it worked: changed URLs appearing as pages with redirects, new URLs indexed, and nothing large sitting under not found. Coverage moves within days, well before rankings mean anything, which is the leading indicator described in how long does ranking recovery take after a migration.
One nuance worth expecting: if you preserved most URLs, your recovery should be almost invisible. A migration that keeps addresses and content typically shows no meaningful dip. If you see one anyway, the cause is something other than the URLs, most often a crawl block or a content change, and knowing that quickly is worth a great deal.
Key takeaways: preserve first, change deliberately
Preserving a URL costs nothing. Changing one costs a redirect rule, a recrawl, and a permanent maintenance obligation, so the default should be to keep.
Three changes are worth making during a migration: moving to https, removing platform specific artifacts from paths, and consolidating duplicate addresses. All three have concrete payoffs and well understood mechanics.
Restructuring hierarchy or tidying URLs for looks is the expensive category. It concentrates risk on launch day and makes any later problem harder to diagnose.
Verify by behavior. Preserved URLs return 200 with no redirect, changed URLs return one 301 to a 200, and everything else is a defect a mechanical test finds in minutes.
Quick answers
Is it better to keep your old URLs after a migration? Yes by default. A preserved URL needs no redirect, no recrawl, and carries no risk at all, so keeping it is strictly cheaper than changing it in every respect that matters. WPBuildAI preserves URL structure unless there is a specific reason to change, because every changed address becomes a row to map, test, and monitor for years afterwards.
What are good reasons to change a URL during a migration? Moving from http to https, removing a platform specific path such as an index file or a query parameter, dropping dates from article URLs you routinely update, consolidating duplicate addresses that serve one page, and fixing a structure that genuinely misleads visitors about what a page contains. Each of those buys something concrete you can point at afterwards. Preferring how a shorter address looks in a slide does not, and it costs a permanent redirect rule.
Does changing a URL lose ranking value? A correctly redirected URL passes its signals, so the loss should be close to zero. The real costs are timing and risk: the new address has to be recrawled before it performs at the old level, and any mistake in the redirect turns a short delay into a permanent loss. Multiply both by every URL you decide to change.
Should I remove dates from my blog post URLs? Only if you regularly update older posts and the visible date in the address is costing you clicks. That is a real reason and it applies to a minority of sites. If your posts are dated by nature, news, releases, or event coverage, the date in the path is accurate and removing it buys nothing while costing a redirect on every post.
Is it not better to fix a messy URL structure while you are rebuilding anyway? Tempting, and usually not worth it. Messy URLs cost very little on their own, while changing every address at once concentrates all the migration risk on a single day and makes any later problem hard to diagnose. If the structure genuinely needs fixing, do it as a separate, smaller change once the platform move has settled.
