A new website is not a fresh start for every visitor. Some people arrive through an email, a proposal or a QR code distributed long ago. Search services may still know the previous addresses. The replacement therefore needs a plan for these existing routes as well as its new appearance.
Do not wait for broken links to appear after launch. Inventory existing pages and files, choose their destinations and establish verification before moving. Separate a visual redesign from a change of address so neither happens accidentally.
Inventory what people can still reach, not just the menu
Collect addresses from the page inventory, sitemap, traffic records and links the team has used elsewhere. A navigation menu may expose only part of the site, so it should not define the whole migration.
Include images, downloadable documents, post-submission pages and older destinations no longer linked from navigation. Identify what remains useful, what will be consolidated and what is genuinely being retired.
Assign decisions to people who understand the content. Service owners confirm current facts, editors identify suitable replacements and the delivery team implements routing. The person moving the system should not have to infer the business meaning of every old page.
Send existing addresses to relevant information
If only the design changes and an existing address can remain, a new URL may be unnecessary. Where it must change, explicitly record the relationship between the old page and its replacement.
Google's site-move guidance recommends permanent server-side redirects, such as 301 or 308, for permanent moves. It also cautions against sending unrelated old pages to the homepage. The implementation should reflect what actually happened to the content.
| Situation | Option to consider | What to verify |
|---|---|---|
| Same content and usable address | Keep the address | The replacement page remains complete and usable |
| Existing page moves | Redirect directly to its new address | Relevant destination with no loop |
| Several pages are consolidated | Route to the relevant combined page | Important previous information remains findable |
| Content is retired without a replacement | Return an appropriate not-found or gone response | Avoid a successful but empty destination |
| A shared download is renamed | Preserve its route or point to the correct file | The intended document opens successfully |
Sending everything home may conceal an obvious broken-link screen, but it forces people to search again and may obscure that information has disappeared. Decide based on relevance rather than whether an address can display any functioning page.
Check language counterparts and supporting files separately
When a Thai page moves to a new Thai destination, its English counterpart needs its own mapping. Test the language switch against the same subject. It should not silently return to the other language's homepage or a similarly named but different article.
Record missing or unpublished translations too. Do not create empty pages merely to balance the number of language editions. Nor should one edition retain obsolete conditions after its counterpart has been corrected.
Article attachments may live separately from the website pages. Check addresses, actual image loading and access restrictions. Documents intended for specific customers must not become public simply because they were moved alongside general website images.
Agree launch conditions and recovery before switching
Define a content freeze or a process for capturing changes made during migration. Otherwise, information added to the old site may never reach the replacement. Back up the necessary content and configuration, and identify who can decide to roll back after a significant problem.
A test site may restrict access or prevent search services from indexing it. Check that these test-only conditions do not remain on public pages intended for release, while genuinely unpublished material stays restricted.
Ask the delivery team to verify each page's primary-address references, the sitemap and internal links. These should use final destinations directly rather than depending on several redirects as the normal route.
Test from real old links after launch
Open addresses from the original inventory and inspect the destination, content, language, images and contact action. Clicking only through the new navigation does not demonstrate a successful migration: that menu may never exercise the links customers saved.
Prioritise important pages and substantially changed routes, then cover the remaining inventory using a method appropriate to its size. Monitor missing-page requests and customer questions, and update mappings when overlooked routes emerge.
A redirect also needs an owner after launch. Record where it is configured and how future changes will be checked, so a later cleanup does not inadvertently remove a route the team still relies on.
This preparation helps the business verify and reduce controllable problems. It does not guarantee unchanged rankings or traffic immediately after a move. If the direction remains undecided, review whether to improve the existing site or rebuild it, and plan the bilingual content workflow alongside the migration.
Replacing your website without a clear plan for existing links?
Talvyn Labs can map pages, plan their destinations and check the customer journey after launch, including services, articles and contact routes.
Plan a complete website migration