A useful URL migration plan for a website redesign, replatform, or relaunch needs more than a two-column redirect spreadsheet. Every known public legacy URL should receive one approved disposition; business priority determines whether a failed row blocks launch. Each row also needs an accountable owner and a test that proves the live behavior matches the decision. That shared specification is the URL migration contract.
The contract does not promise unchanged rankings, and it is not a legal document. It is a technical acceptance agreement between the people deciding what content should survive and the people implementing the new site. It turns “we added the redirects” into evidence that users, search engines, campaigns, and measurement systems still reach the right destination.
That distinction matters because a relaunch can look correct while its old entry points fail. Google's current site-move guidance includes an accurate URL mapping, then directs teams to test redirects and align canonicals, robots rules, internal links, sitemaps, and monitoring. The contract makes those dependencies reviewable before the release window.
A redirect sheet records intent; a contract defines acceptance
A redirect sheet normally says old URL, new URL, perhaps status code. It does not say why the match is valid, which source proved the old page still matters, whether the destination may be indexed, who approved a consolidation, or what should happen if the test fails.
The URL migration contract adds those missing decisions. Each row becomes a small release requirement: the source is known, the destination preserves the user need, the expected response is explicit, the new page sends consistent search signals, and an owner can resolve an exception without inventing a launch-day answer.
This is especially useful when a redesign changes the content model, CMS, domain, navigation, and page copy at once. Google recommends changing one thing at a time when possible. When the project cannot be separated cleanly, the contract at least keeps the URL consequences visible instead of burying them inside design approval.
Discover the old site from more than one source
The current sitemap is a starting point, not a complete inventory. A useful discovery pass combines the URLs the site publishes now with entry points that still exist outside the new information architecture.
- Current crawl and sitemap: indexable pages, media, downloads, language variants, and canonical targets the site exposes today.
- Search and traffic evidence: Search Console landing pages, analytics landing pages, server logs, and high-value external links.
- Commercial entry points: paid ads, email campaigns, social profiles, directory listings, QR codes, partner pages, and saved sales documents.
- Operational endpoints: forms, confirmation pages, booking paths, account areas, feeds, API routes, and files that may not appear in navigation.
- Known variants: HTTP and HTTPS, www and non-www, uppercase or trailing-slash variants, parameters, and historical paths that still receive requests.
Record the discovery source on each row. It changes priority and follow-up. A page with no current navigation but steady qualified traffic is not the same as an obsolete preview URL found only in an old crawl.
If the relaunch is part of a company-name or domain change, also review the continuity work in our rebranding checklist. The URL contract covers routing and verification; the wider rebrand still has customer, profile, naming, and operational dependencies.
Give every old URL one honest outcome
Choose the content outcome before choosing the status code. Four dispositions cover most public pages.
- Keep: the page and address survive. The refreshed URL should return a successful response and retain the intended canonical.
- Move: an equivalent page now lives at a different address. Use an approved permanent server-side redirect directly to that destination.
- Merge: several old pages genuinely become one stronger page. An editor must confirm that the combined destination satisfies the old user needs before the redirect is approved.
- Retire: the content is gone and no honest replacement exists. Return a real 404 or 410, with useful navigation for people, instead of sending every missing page to the homepage.
Google treats 301 and 308 as permanent redirects. Its site-move guidance warns that redirecting many old URLs to one irrelevant destination may be treated as a soft 404. Google's crawling-error guidance recommends a permanent redirect when a clear replacement exists and a 404 or 410 when it does not.
Forms and transactional endpoints need a separate lane
Do not apply ordinary page rules blindly to form submissions, webhooks, downloads, authenticated routes, or APIs. The HTTP specification distinguishes redirect behavior that may change a request method from behavior that preserves it. A GET page moving permanently is a different risk from a POST endpoint carrying customer data.
Flag those rows for technical review against HTTP semantics, application behavior, and privacy requirements. The contract should name the method, expected response, safe test data, and rollback owner rather than assuming every old path is a marketing page.
The minimum columns turn intent into evidence
A useful contract can live in a spreadsheet, database, or test fixture. The format matters less than the questions each row can answer.
Identity and evidence
Record the exact source URL, discovery source, current status, current canonical, content type, language or market variant, and the evidence that determines priority. Add the page owner when meaning depends on product, legal, sales, or support knowledge.
Approved outcome
Store the disposition, destination URL when one exists, expected first response, expected final URL, and the reason the destination is equivalent. For a consolidation, name the editor or subject-matter owner who accepted the combined page.
Acceptance criteria
Define what the automated test should observe: first status, Location header, hop count, final status, target canonical, robots.txt crawlability, meta or X-Robots-Tag indexability, language annotations when relevant, internal-link replacement, sitemap inclusion, and required analytics or conversion behavior.
Keep the signals consistent. Google's canonicalization documentation explains that redirects, canonical annotations, and sitemap inclusion all contribute to the preferred URL. Its sitemap guidance says to list the preferred canonical URLs rather than every duplicate variation.
Ownership and exceptions
Add the implementer, approver, test result, exception state, decision deadline, and rollback note. A failed row without an owner is only a warning. A failed row with a named owner and an agreed release rule can stop a preventable defect from shipping.
Rollback should be specific to the failure: restore the old route, disable one redirect rule, revert the affected release, or hold that section out of cutover. Name who may trigger the action and what evidence allows the new route to return.
A fictional row might record example.com/services/audit-old, discovered in Search Console with qualified visits; disposition move; destination example.com/services/website-audits; expected 301 followed by 200; a self-canonical target; old internal links and sitemap entry replaced; content lead approval; automated test passed. If the new page omits the service scope promised by the old one, the row stays on hold even when the redirect resolves. The exception owner disables that rule and restores the old route until the content passes.
Launch approval should fail for predictable defects
Define release thresholds before launch-day pressure. Priority determines which failed rows stop the whole cutover and which can proceed only as approved exceptions.
- No high-priority legacy URL may remain unmapped or use a placeholder destination.
- No permanent move may end in a loop, avoidable chain, server error, unrelated page, or blocked destination.
- No intended indexable page may retain a staging noindex rule, robots block, old-domain canonical, or redirecting URL in the new sitemap.
- No navigation, breadcrumb, campaign, or other controlled internal link should point to the old address when the final URL is known.
- No critical form, booking, purchase, file, or tracked action may be assumed to work without an end-to-end test.
- No lower-priority failure may ship without an explicit approver, exception owner, correction deadline, and rollback action.
Run the suite against staging where the infrastructure allows it, then run it again against production immediately after cutover. Compare the observed result with the row rather than merely checking that a browser eventually displays something.
That release discipline fits the Web & Mobile Apps service, where redirects, analytics, accessibility, performance checks, browser QA, content population, and launch support belong to the same implementation scope. It also protects the acquisition work described in our Growth Marketing service: paid traffic and search visibility cannot compensate for a broken destination.
Search Console is a monitor, not the contract runner
Use Search Console after the direct HTTP and browser checks, not instead of them. Google's URL Inspection documentation says the live test follows redirects without showing the redirect path or the final URL it tested. A valid result also does not guarantee indexing or Google's eventual canonical selection.
For an eligible whole-site move, run Search Console's Change of Address tool from a source property with no path segment after redirects are live; the same Google account must own both the old and new Search Console properties. Do not use it for moving only some paths within the same site, HTTP-to-HTTPS, www/non-www, or hosting/CDN-only changes. Google permits an entire domain to move to a path on another domain.
Google's Change of Address guidance describes those boundaries. Its broader site-move guidance also recommends keeping redirects for as long as possible, generally at least one year, and warns that temporary search fluctuations can occur while URLs are recrawled and reprocessed.
Monitor old and new URL traffic, Page Indexing patterns, crawl errors, server logs, conversions, and the exception queue. The contract reduces preventable ambiguity; it cannot guarantee a ranking curve or replace editorial judgment about whether two pages truly satisfy the same need.
Freeze approved rows before cutover
Build the URL migration contract while the new architecture is still negotiable. Approve a disposition for every known public legacy URL, set the priority thresholds, and freeze those decisions before cutover. A late redirect change should reopen the relevant content, technical, and measurement checks instead of bypassing them.
Run the contract against production, keep the exception owners active after launch, and close rows only when the observed result matches the approved outcome. That is how a redirect map becomes a release control instead of a cleanup list.
If a redesign, replatform, or domain move needs a clearer migration scope, send a project brief to discuss the site inventory, ownership boundaries, launch tests, and monitoring that should be agreed before URLs change.
