Website Relaunch: What Needs to Be Ready Before Go-live

The new website is ready. The design is clearer, the team is happy and the launch date is set. Then someone notices that a link in an old customer email goes nowhere. A useful download page is missing. The contact form does not send messages to the right person.

A relaunch changes a system people already use. Alongside a design brief, it needs a handover plan. These questions help you make that plan concrete with your agency or internal team.

Which content already does useful work?

Before starting the project, list the important pages. Include services, frequently read articles, downloads and pages your sales team sends to prospects. Ask support too: which links do they regularly share with customers?

Add each page's purpose. Does it answer a question, help someone compare options or prepare an enquiry? Record who can review its accuracy. This gives you a basis for decisions beyond the age or appearance of a page.

An article with few visits may be valuable to a particular group of buyers. A busy page may attract questions that have little to do with your offer. Consider content, usage and business purpose together.

Who decides what gets carried over?

Give every important piece of content a decision: keep, revise, merge or remove. Name someone who approves that decision. This helps prevent useful information disappearing between copy, design and development.

A fictional consultancy might combine three similar service pages. First, it should check whether their audiences actually ask the same questions. If a page is removed only because it does not fit the new menu, the structure may need more thought.

What happens to existing URLs?

If addresses change, plan the transition before launch. Google recommends mapping old URLs to new ones and using permanent redirects to the relevant destination. Avoid sending everything to an unrelated homepage. Temporary search fluctuations can also occur during a move.

The practical project question is: who creates the mapping, who implements it and who checks it? Those may be three different people. Ask for a demonstration using important pages so you can see that the transition works.

Can a prospect complete the main task?

Ask someone outside the project team to follow a complete journey: find a service, understand its scope, look at supporting evidence and make contact. Give them the task without instructions for operating the site. Note where they need help.

Repeat that journey on a phone. Send an actual test enquiry using fictional contact details clearly labelled as a test. Check receipt, ownership, confirmation and the reply process. A success message on screen does not establish that the enquiry reaches the working team.

What will you monitor after launch?

Record a baseline before the switch: relevant enquiries, important entry pages and recurring problems. Agree on a specific review date afterwards. Without an owner, “we will keep an eye on it” can easily become nobody's task.

When URLs change, include a technical review of search journeys. For indexing and migration details, refer to Google Search Central's documentation. Alongside that, assess whether suitable prospects can find the contact route and get the information they need.

Approval that means more than “looks good”

Before going live, ask for a shared review: Is important content approved? Have existing links been accounted for? Do core tasks work? Is it clear who handles issues after launch? Assign every unresolved answer an owner and a date.

We explain how structure and design work together in A Website Is Not a Brochure. For your next relaunch, explore our web design and development services, or talk to us about the planned switch.