A website relaunch often changes more than appearance. Content moves, forms are replaced and page addresses are renamed. When these changes are considered together only immediately before release, information important to customers or everyday operations can disappear.
Begin with an inventory of the existing website. Include more than the pages in the main navigation. Older articles, downloads, linked offer pages and second-language content may still be used. An exported URL list is a starting point, but it does not replace inspecting what those addresses contain.
Evaluate content by its purpose
Assign each page a job. Does it support an enquiry, explain a requirement or describe a service still offered? Then decide whether to retain, revise, combine or remove it. A page need not survive merely because it exists, but it should not disappear merely because it is awkward to fit into a new layout.
Record special cases. A PDF may be regularly linked from quotations, or a rarely visited page may contain delivery instructions. Visit counts do not tell the whole story in those circumstances. Ask people who deal with customers which addresses and files they use in ordinary work.
Save original text and images in a traceable version. Check whether permissions cover the intended reuse. An image on an old page is not automatically cleared for every new placement. Record unresolved questions instead of allowing implementation to make the decision silently.
Connect old addresses to appropriate destinations
Map each relevant old URL to its intended destination. If content remains at the same address, a visual redesign alone does not require changing it. If several pages are combined, the new page should genuinely take over their important functions.
Do not send every old detail page to the homepage. Someone following a link to maintenance conditions expects that information, not a general introduction to the company. If no relevant replacement exists, make a deliberate decision about the removed page.
Google's site-move documentation recommends server-side permanent redirects for permanent URL changes where technically possible. Plan these with whoever manages the server or CMS. A well-designed error page does not replace an appropriate redirect.
Approve content before treating layout as finished
Separate factual review from layout inspection. The person responsible for a service checks its scope, conditions and figures. Another review can assess readability on small screens. If everyone looks only at appearance, factual problems may remain unnoticed.
For multiple languages, every new or revised page needs its corresponding version. Check that language links open the equivalent content rather than always returning to a language homepage. Translation is complete only when navigation, contact information and functional messages carry the same meaning as well.
Agree an editorial cutoff. Any change made to the old website after that point needs explicit transfer to the new version. Otherwise, a corrected telephone number can revert to its earlier value during the switch. A simple change log helps prevent this kind of regression.
Test complete tasks
Follow routes from a service page to an enquiry, from an article to a download and from an old link to its new destination. For forms, verify receipt by the real recipient. A visible success message alone does not show that the responsible team received the request.
Inspect images, internal links, page titles and relevant metadata. Open representative pages on desktop and mobile, including long text and unusual content. A correct-looking homepage says little about an extensive form or a wide comparison elsewhere on the site.
Record the checks performed and unresolved failures. Avoid a blanket “everything tested” approval when only a few pages were viewed. Critical problems need a clear decision before the switch: repair them, postpone the affected section or delay the release.
Prepare release and recovery
Keep a recoverable copy of the old version and establish how it could be restored. Identify who performs the switch, who checks the main tasks afterwards and who is reachable if something fails. A recovery plan should exist before the contact route stops working.
After the switch, repeat the important checks on the actual production address. Revisit old URLs, redirects, forms and downloads. Local tests cannot fully establish how the final server configuration behaves. Review reported problems afterwards and correct their specific causes.
A controlled relaunch preserves the website's necessary jobs and makes changes traceable. Its visual presentation can change substantially. Whether important information remains available should remain a deliberate decision throughout the work.
