URL migrations

When changing an existing URL is risky

Decide whether a cleaner URL is worth migration risk, then map redirects, internal links, canonicals, and monitoring correctly.

Reviewed August 26, 20268 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.

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.

Generic example-company placeholder

Old: https://example.com/blog/payroll-guide-2024

New: https://example.com/guides/multi-state-payroll

The change is defensible if the page has become an evergreen, substantially updated resource and the organization is intentionally moving editorial content into a durable guide library. The old URL should redirect directly to the new one, while internal links, the canonical element, and the sitemap should use the new address.

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.