URL migrations

When changing an existing URL is risky

An existing URL may be connected to bookmarks, backlinks, campaigns, and integrations. Weigh the reason for changing it, then plan the redirect and related updates so people can reach the replacement.

Reviewed October 8, 20266 minute read

Direct answer

Changing a live URL is risky when the old address already earns traffic, has internal or external links, appears in campaigns, or powers an integration. Change it for a clear user, security, or platform need—not cosmetic neatness. For a normal move with a close replacement, use a direct, permanent server-side redirect, updated internal signals, and post-launch monitoring.

First ask whether the URL must change

A URL is an address used by more than a search engine. People bookmark it, other sites link to it, analytics records it, campaigns reference it, and applications may call it. A new slug can be more readable while the migration still creates more risk than value.

Reason for change	Likely decision	Why
One word in the slug is slightly awkward	Usually keep it	The cosmetic benefit rarely offsets migration work for an established page.
Two pages are being consolidated into one stronger resource	Often change with a mapping	Each old address can lead to the relevant consolidated replacement.
A CMS migration requires a new path pattern	Plan it as a migration	The operational need justifies tested old-to-new mappings.
A URL exposes sensitive data or a secret	Handle it as an incident	Remove the exposed value, rotate affected secrets where applicable, and review caches and logs. Changing or redirecting the URL alone is not remediation. If there is no safe, relevant replacement after remediation, return an appropriate `404` or `410` instead of inventing a redirect target.
The current URL is materially wrong or misleading	Consider changing it	A durable correction may justify a managed transition.

Turn the inventory into a redirect map

Record a source, destination, and intended status for each moved page. Start with the actual URLs in navigation, a sitemap, analytics, and known campaign links. Include older addresses that already redirect to the page you are moving, so they can go straight to the final destination instead of gaining another step.

Old path	Planned response	Reason
`/services/bookkeeping`	`301` to `/services/monthly-bookkeeping`	The same service now has a more accurate address.
`/bookkeeping`	`301` directly to `/services/monthly-bookkeeping`	An older redirect also needs the final destination.
`/offers/retired-bundle`	`404` or `410`	The fictional offer is gone and has no relevant replacement.

Use the Redirect Map Builder & Checker for the redirect rows. It detects issues within the supplied map and exports CSV; it does not visit destinations or activate server rules. Keep removed pages in a separate removal list, since a 404 or 410 response is not a redirect.

What can go wrong

The old page returns a 404 instead of leading people to the replacement.
Many unrelated old URLs redirect to the home page, which Google may treat as a soft 404.
A chain sends the browser through several historical addresses before the final destination.
Internal links, canonicals, hreflang annotations, or the sitemap still name the old URL.
Analytics, advertisements, email links, QR codes, or product integrations are not updated.
The new page is blocked from crawling or retains a development noindex rule.

Google advises expecting temporary ranking fluctuations during significant moves while its systems recrawl and reindex URLs. There is no fixed crawl timetable; processing happens per URL and varies with the number of URLs and the server's crawl capacity.

A safe sequence for a page with a close replacement

Record the old URL, proposed destination, traffic, inbound links, and known business dependencies.
Confirm that the new page is a close, useful replacement—not merely a convenient destination.
Publish and test the new URL, including its status code, self-referencing canonical, navigation, and mobile rendering.
Configure a direct server-side 301 or 308 from the old URL to the final destination.
Update internal links, canonical and hreflang references where used, the XML sitemap, and campaign destinations.
Test the old URL from a fresh browser session and verify that it reaches the new page in one redirect.
Monitor crawling, indexing, traffic, conversions, and error logs after launch.

Keep signals aligned

The redirect, internal links, canonical element, hreflang annotations, and sitemap should agree on the new address. Use the canonical URL checker to compare page and canonical URLs before launch; it cannot replace a live redirect test.

Verify the deployed behavior, not just the plan

A browser reaching the right page is only part of the check. Use its developer tools' Network panel, preserving the request log, to inspect the document requests from the old address to the new one. Confirm the redirect status, its Location destination, and a successful final page response. A page that displays a missing-page message with status 200 is not a successful replacement.

Test the exact old URLs, including any real query parameters and slash variants. Server matching may differ from your planning tool.
For an ordinary page move, expect one permanent redirect to the intended page. Review any extra hop or unexpected host.
Confirm the final page's canonical, indexability, content, and main action. A correct redirect into a broken form still breaks the visitor's task.
Check important pages immediately after launch, then review error logs and Search Console as the move is recrawled. Record unexpected old URLs and fix their mappings.

Forms and API addresses need a separate check

A working page-navigation redirect does not establish that an integration still works. Test the actual request method and destination with the system owner. The HTTP specification distinguishes method-preserving 308 redirects from the historical behavior of 301, which permits a POST to become a GET. Choosing a status cannot replace integration testing.

How long should the redirect remain?

For site moves, Google recommends keeping redirects for as long as possible and generally for at least one year. That gives its systems time to recrawl old URLs and transfer signals to the new ones. People, bookmarks, and other systems may rely on the old address for longer, so retaining a correct redirect indefinitely is often sensible when the operational cost is low.

Pre-launch decision check

The change has a user, security, or platform rationale.
Moved content has a relevant destination; truly removed content returns 404 or 410.
The redirect is permanent and server-side where possible.
No avoidable redirect chain is being introduced.
Internal links and canonical signals use the new URL.
Someone is assigned to monitor the move.

No migration can promise unchanged rankings

A technically correct redirect reduces avoidable risk; it does not freeze search results. Make the decision from documented dependencies and a meaningful business benefit, not from a claim that a cleaner slug must rank better.

Primary sources

Current Google documentation

Review Google's guidance for site moves with URL changes, permanent and temporary redirects, and canonical URL signals. The one-year language above is Google's general site-move recommendation, not a promise that every URL will finish processing on a fixed schedule.