Open an old service-page link before approving the new website. Does it reach the right information? Try the French equivalent, then the Italian one. A relaunch becomes much easier to assess when you start with the routes customers already use, including links in search results, saved bookmarks and quotations sent months ago.
For a Swiss SME, the essential working document can be a simple list: old URL, decision, new URL, language, test result and responsible person. Prepare it before the switch. Otherwise launch day becomes a guessing exercise about which old pages still matter, carried out while customers are trying to use the site.
Keep useful addresses when the design changes
A new layout doesn't automatically require new URLs. Better typography, clearer content and a different content-management system can often use existing addresses. For each proposed change, ask what benefit it brings and which additional handover it creates. A tidier path may be worthwhile, but it should earn its place in the plan.
Separate the changes on paper: hosting, content-management system, page structure and copy. They need not become four expensive projects. The point is to know what changed when a problem appears. Our comparison of WordPress, Webflow and a custom website helps with the platform decision. The migration checks apply whichever platform you choose.
Preserve content decisions as well. An old guide or PDF may still serve customers even if it has no obvious place in the new navigation. Decide whether to retain, improve, combine or remove it. Letting a new page builder quietly discard it is a poor substitute for that decision.
Build an inventory wider than the navigation menu
Collect URLs from the current sitemap, a crawl of the website and available Search Console information. Add important destinations from advertisements, business profiles, quotation templates and external links. Include downloads and older campaign pages where relevant. Note the period covered by each source; a list can look comprehensive while missing a whole earlier version of the site.
For important pages, record the reader's task and the language. This exposes mismatches such as redirecting a detailed plumbing-repair page to a general homepage. Save useful enquiry and search baselines where you actually have them. Label assumptions as assumptions rather than inventing traffic value for a page nobody has measured.
A small example inventory might contain four different decisions. A German repair page keeps its address. A renamed French guide moves to a corresponding French page. Two overlapping English articles become one stronger English resource. An expired promotion without a suitable replacement is removed. These decisions require different technical outcomes, so a single catch-all rule will be inadequate.
A fictional mapping ledger makes those decisions testable. These paths illustrate the method; they are not planned changes to AlpenAgent:
/repairs/stays/repairs/: useful content present, response 200./old-service/moves to/service/: permanent 301 redirect to the relevant replacement./fr/ancien-guide/moves to/fr/nouveau-guide/: 301, with French content and language navigation checked./promotion-2024/has no replacement: deliberate 404 or 410, without an unrelated destination.
Give each moved page a relevant destination
For a permanent move, arrange a permanent server-side redirect, commonly 301 or 308. The destination should still meet the original need. Sending every old URL to the homepage may shorten the configuration, but it gives somebody looking for a specific service a confusing result. Also check whether the destination redirects again; unnecessary chains make diagnosis and maintenance harder.
Google's site-move guidance recommends URL mapping and generally keeping redirects for at least a year. That doesn't guarantee stable rankings. Treat the redirects as maintained infrastructure, so a later hosting change doesn't accidentally delete the migration plan.
Where there is no relevant replacement, an honest 404 or 410 response can be more appropriate than an unrelated destination. Have somebody make that choice explicitly. A useful error page can still offer navigation while returning the correct status. A polished “not found” page returning 200 conceals the real state from automated checks.
Don't publish the preview environment's restrictions
An access barrier can protect a preview before launch. The public replacement must then be reachable and carry the intended indexing instructions. Test response status, robots metadata and HTTP headers on the real domain. An unchecked box in the administration interface is a setting, rather than proof of what visitors and crawlers receive.
Google explains that a crawler must be able to fetch a page to read its noindex instruction. A robots.txt crawl block doesn't perform the same job. During acceptance, check access protection, crawling rules and indexing instructions separately, removing preview restrictions deliberately.
Look for quieter leftovers too: canonicals pointing at the preview domain, form actions using a test endpoint, or images only available to a logged-in administrator. Test from a fresh browser session. A page that works on the developer's authenticated computer can still fail for an ordinary customer.
Move each language journey deliberately
Check every language as a complete route. A French legacy service URL needs a suitable French destination. The language selector should reach the equivalent page, rather than repeatedly dropping readers on another language's homepage. Review the heading, contact destination and downloadable documents in the same pass.
Canonical URLs, language annotations and sitemap entries must describe the published structure. When a translation is deliberately discontinued, decide what happens to its old address and remove links to a nonexistent replacement. The article on multilingual websites in Switzerland covers the long-term structure. A relaunch turns that structure into a finite set of old-to-new checks.
For a useful manual sample, choose five important customer questions and follow each in every available language. Enter once through an old link and once through the new navigation. This won't replace a complete URL test, but it catches irrelevant mappings that a list of successful HTTP responses would miss.
Run acceptance in three passes
Keep technical and business evidence together. A redirected URL leading to an empty content area is a poor result. So is a good-looking service page with a broken enquiry route. Record who checked the important journeys, when they checked them and what remains unresolved.
- Before the switch, save the old inventory, agree mappings, compare content and metadata, test redirects in the preview setup and document a recovery route.
- At launch, request old URLs on the real domain, inspect final destinations and response codes, rule out accidental restrictions and follow controlled enquiries to their destination.
- Afterwards, review technical errors, search visibility and usable enquiries over an appropriate period. Tie findings to specific URLs and changes instead of repeatedly rebuilding the whole website.
Testing an enquiry means following more than its success message. The guide to missing contact-form emails follows submission and notification separately. Include mobile use, keyboard navigation and browser zoom in your acceptance too. Moving the URLs successfully doesn't protect a contact button from being clipped by the new layout.
Write down what recovery would actually involve
A saved copy of the previous design is only part of a recovery plan. Establish who can restore the earlier version, what access they need and how enquiries received since launch will survive. New form submissions or content edits must not disappear because somebody restores an older database snapshot. Try the process with a limited example before the public switch.
Define concrete triggers: a central contact route fails, key service pages disappear or a broad section returns server errors. A single search position moving up or down is a different kind of evidence. Repeated hasty reversals can add confusion, so also identify faults that can be repaired directly without reversing the migration.
Keep the recovery instructions somewhere the people on duty can reach without the new website working. Name the person who decides and a substitute. You don't want a technical supplier restoring an old version while somebody else is simultaneously repairing the new one, each unaware of the other.
Compare like with like after the switch
Save an appropriate baseline and annotate the actual deployment date. Compare the same countries, devices, languages and page groups. A holiday week, a changed advertising campaign or a quieter trading period can affect enquiries without indicating a redirect fault. With small numbers, conclusions need more time and more caution.
Watch important landing pages, unexpected errors and the number of enquiries your team can actually handle. Maintain the mapping so somebody can still answer where an old address goes. Search engines need time to process changes; nobody can honestly promise a loss-free relaunch. What you can require is evidence that the intended routes work and a clear way to resolve the remaining defects.
FAQ
Does a relaunch require changing every URL?
No. A new design and stronger content can often retain existing addresses. Change an address when the benefit justifies the extra migration and maintenance work.
Can every old page redirect to the new homepage?
The destination should meet the original need. Map important addresses to relevant pages and make deliberate removal decisions where no replacement exists, rather than hiding every issue behind the homepage.
Should the URL inventory include PDF files?
Include documents customers still need or link to directly. Decide whether each download stays, moves or is removed, and request the published file directly even if the new navigation no longer links to it.