Estimated reading time : 6 min · Published
Follow an old URL to a useful answer
Verify a migration from known old URLs, not just the new homepage. The right destination depends on the original page’s content and purpose.
- Old page
Identify its content, incoming links and usefulness.
- Decision
Keep, replace, merge or retire with a rationale.
- HTTP response
Check the status and destination actually served.
- Final page
Inspect content, links and the action available to visitors.
Fictional teaching scenarios to adapt to your system. This page performs no operation on your website.
Open the situation you want to check
Everything redirects to the new homepage
- What is known
- Old URLs resolve, but their original need may remain unanswered.
- The next check
- Map important pages to genuinely equivalent content; explicitly handle removed content with no equivalent.
The destination is correct after several hops
- What is known
- The final page can be relevant while the chain adds unnecessary steps.
- The next check
- Inspect each hop and aim for a direct connection to the correct destination where configuration permits.
Redirects work, but internal links remain old
- What is known
- The website still sends visitors to replaced addresses.
- The next check
- Update navigation, content links and language versions, then replay priority journeys.
A parameter distinguishes two contents to migrate
- What is known
- In the fictional dataset, https://example.org/fiche?id=42 and https://example.org/fiche?id=43 describe different offers.
- The next check
- Prepare two mappings and test each full old address. Removing the parameter without examining its role could merge distinct needs.
- Evidence to retain
- Both complete old URLs, expected contents, selected destinations and each test’s final response.
Technical reference : Google Search Central · Site moves · Consulted .
Inventory before removing anything
Combine the sitemap, live pages, CMS exports and, where available, visited pages and inbound links. Include documents, images, translations, forms and result pages. For each URL, record its purpose, content owner and decision: keep, improve, combine with a related page or retire.
Do not remove a page solely because it has little traffic. It may serve a rare need, provide a customer reference or contain contractual information. Check facts and usage rights before moving copy and media.
During media recovery, the source must remain accessible as required by the import procedure. A Shopify CSV retains image references; the corresponding files are not embedded in the table. Check which source the new pages actually use before closing the original store.
Keep a list of expected media with their parent content and a readability check. An image displayed through a URL still hosted by the old service can disappear later. Domain switching, media copying and permission to reuse the material are separate checks.
- Old URL and current status.
- New URL or reason for retirement.
- Content, language and media to retain.
Map old addresses to relevant destinations
Build an old URL → destination table. A retained page can often keep its address; if it moves, redirect permanently to its equivalent. When pages are combined, confirm that the destination answers their main questions. A genuinely retired page with no replacement should return an appropriate status.
Avoid redirect chains and sending many unrelated pages to the home page. Google’s migration guide recommends matching destinations and checking both old and new URLs.
Prepare the new site with real content
Retain titles, descriptions, images, alternatives, internal links and structured data where they still describe the page accurately. Update facts that changed. Each language needs its own canonical URL and hreflang links only to versions that are actually available.
Test forms, filters, errors, mobile layouts and loading with real content. Keep the staging site out of the index, then remove accidental crawl blocks when the public site opens.
Check launch and the following days
After launch, sample every page family and test all important redirects. Check HTTP status, final destination, canonical, images, links, sitemap and form delivery. Review 404 errors through logs and monitoring tools without exposing personal data in reports.
Keep redirects while old addresses may still be used. Track problems and correct wrong mappings. Search visibility may fluctuate during a migration; examine content changes and technical errors rather than drawing a conclusion from a single day. The website brief helps assign responsibilities before the move.
- Priority old URLs tested.
- Sitemap limited to new canonical URLs.
- Owner for post-launch monitoring.
Decide in a concrete situation
Fictional example: two old pages will share a new destination. Check that it retains the answers specific to each before merging destinations; similar titles do not establish content equivalence.
Keep old path, destination, retained content and rationale. Check linked files and a real journey after cutover; a redirect list without server responses remains a plan, not completed acceptance.
- Prepare and test a URL redirect plan
Decide when to redirect, retain or remove content, map old URLs and test destinations, HTTP methods and internal links.
Check the destination as well as the status
For an old service page, confirm that the destination still describes the same activity and retains important conditions. A redirect to the homepage may work technically while leaving the visitor without an answer. Also check parameterised URLs, linked images and external incoming links.
Build a URL map with concrete decision criteria
The paths below are fictional and describe pages requested with GET. Each row connects an editorial decision to a technical response. A 301 status alone does not establish the relevance of the resulting content.
Scroll the table horizontally to read every column. With a keyboard, focus the table area and use the arrow keys.
| Old content | Proposed decision | Destination check |
|---|---|---|
| /services/advice/ moves | 301 to /support/ if the service remains equivalent. | The final page returns 200 and still explains the advice offered. |
| Two entries are merged | 301 from each old entry to a summary retaining their useful information. | The summary actually addresses both original needs. |
| An offer is retired with no equivalent | 410 when permanent removal is known and intended. | Explain withdrawal without disguising another offer as a replacement. |
| An unknown address is requested | 404 when no representation is found. | A helpful page can offer search while retaining the 404 status. |
- Google Search Central · Site moves
Google advises against mass redirects to an unrelated homepage. RFC 9110 distinguishes 404 from 410; POST request rules need separate analysis.
Reference documents
- Google’s migration guide · Source consulted
- RFC 9110 · HTTP · 404 / 410 · Source consulted
- Shopify · Product images during migration
- Google Search Central · Localized versions · Source consulted
- IETF · RFC 3986, fragment identifiers · Source consulted
Content updated on
Documented reference points for this topic
| Reference | Value or syntax | Scope |
|---|---|---|
| HTTP · 308 | 308 · Location | Permanent relocation: the request method and body are preserved. |
| Google Search · Canonical | rel="canonical" | A preference signal for Google; neither a redirect nor a selection guarantee. |
| Google Search · Sitemap | 50 000 URL · 50 MB | Limits per uncompressed file; larger sets require several sitemaps. |
| WordPress · Tools Export | WXR / XML | A WordPress content export can include posts, pages, post types, comments, custom fields and taxonomies. Its scope depends on selected filters. Check media files, theme, plugins and configuration separately before treating it as a complete migration. |
| Shopify · Exporting products | CSV UTF-8 · Image Src | Product images are not embedded in the CSV. During import into another store, their URLs must still be accessible. Retain the original store until product, variant and image associations have been checked; inventory has a separate export. |
| GitHub Docs · Repository backup | git clone --mirror | A mirror clone backs up the Git repository and its history. Git LFS objects require an additional fetch, and a wiki has its own repository. For a handover, also inventory data and services that do not reside in Git. |
Dates indicate when references were consulted. These facts are neither a site audit nor an overall compliance statement.