An SEO Launch Checklist for Your Website Redesign

Keep a working page at its existing address unless there is a good reason to move it. A new layout, colour scheme or content management system does not require a new URL for every service. If the redesign does change addresses, approve the destinations and test them before the old site disappears.

A redesign can affect search even when every address stays the same. A service page might lose the information that answered a buyer’s question. A navigation change might leave that page without a clear route from the rest of the site. A staging setting might stop Google from indexing it. The point of a launch checklist is to catch these separate problems before they turn into one unexplained drop.

If you are still comparing suppliers, start with our website quotation checklist. This guide is for the next decision: what evidence should the project owner ask for before signing off the release?

What should you record before the old site changes?

Make a list of the old URLs while you can still visit them. Start with the existing sitemap, a crawl that follows internal links, and an export of Search Console’s top pages and queries. Add pages known to the sales or support team, linked documents and useful landing pages that may not appear in navigation. A sitemap is a starting list, not proof that it contains every address people use.

Record a baseline for important pages: clicks, impressions, the queries that surface them, and the period used. Give particular attention to pages that bring enquiries, have external links or answer distinct questions. A quiet page may still be important to customers or a campaign. Search Console and your enquiry records answer different questions; a high-traffic page is not necessarily the page that produces the best leads.

Save representative copies of the old pages, including headings, useful content, internal links and the action customers are expected to take. This is a reference for comparing the redesign, not an instruction to preserve every word. Name an owner for each page group so someone can decide what to keep when a designer, developer and content editor disagree.

Which URLs should stay, move or disappear?

Decide this page by page. The following are illustrative paths, not instructions for an existing website:

Old address	Decision	Expected result at launch
/services/installation	Keep the service at its current address	Returns 200, with the relevant service information and a canonical for that address
/old-installation-guide	Move the same guide to a new location	A permanent redirect leads directly to the new guide, which returns 200
/installation-faq	Consolidate genuinely overlapping content	Redirect to the page that now answers those questions
/expired-event	Retire it with no useful equivalent	Return 404 or 410 and remove obsolete internal links
/brochures/installation.pdf	Keep or map a document customers still use	The document opens, or its replacement is clearly relevant

Google’s site move guidance recommends mapping old URLs to new ones when addresses change. It also warns against sending many unrelated URLs to the home page: Google may interpret those responses as soft 404s. A visitor looking for a specific guide should not have to start the search again from the front door.

Keep a column for the reason behind each decision, alongside the expected status and destination. Ask the person who understands the content to approve the match. An automatic rule that substitutes the first similar slug can be useful for preparing a draft map, but it cannot tell whether the new page answers the same question.

What should you test before opening the new site?

Check important pages in the new design as a visitor would see them. If the old service page explained coverage, supported integrations and how to request a quote, confirm the replacement still does those jobs. A shorter page can be better. A page that replaces specific answers with a generic promise is a different proposition, even if it keeps the old address.

Check a sample from each template as well as individual priority pages. A service detail page, article and listing can use different code for their titles, canonicals and links. Confirm those details against the intended public address. Google’s canonicalisation guide explains that redirects, canonical annotations and sitemap inclusion are signals. Keep them consistent rather than expecting one setting to override contradictory ones.

A staging copy should be protected appropriately. Search indexing controls are not access controls. If a staging template uses noindex, put removal from intended public pages on the release checklist. Google’s noindex documentation explains that a crawler must be able to access a page to see that instruction. Blocking crawling in robots.txt is not a substitute for keeping a private preview private.

Give the release owner explicit reasons to stop: an important page missing, an old address leading to the wrong service, production blocked from crawling, a canonical pointing to staging, or an enquiry form failing. Agree who can fix each class of problem and how the previous release can be restored. A screenshot of the new home page does not settle any of those checks.

What should you verify on launch day?

Test the actual public host, not just the preview. For a retained page, check its response, visible content, canonical and indexability. For a moved page, check the first response, the redirect target and the final page. A request that follows redirects and reports only a final 200 can hide a chain or an irrelevant destination.

Use an appropriate permanent server-side redirect for a permanent move. Google’s redirect documentation lists 301 and 308 as permanent redirects. Where possible, update navigation and contextual links to point straight to the final address. Review the sitemap so it lists the intended current pages. Keep redirects available for users and old links; Google’s site move guidance generally recommends keeping them for at least a year.

For a domain or subdomain move, check whether the Change of Address tool applies and verify the relevant properties. It is not needed for a redesign that keeps the same addresses or moves paths within the same domain. Treat it as a step for eligible moves after redirects are working, not a button that repairs a missing map.

Finally, run agreed tests for the actions the site exists to support: enquiries, calls, bookings or checkout, as relevant. Use test arrangements that keep fake leads and purchases out of business reporting. Record whether the action works and whether measurement sees it. A missing conversion event is a different fault from a page losing search visibility.

What does useful sign-off evidence look like?

Imagine a small equipment supplier replacing its website. Its installation service stays at the same address, but a guide moves into the new resources section. The release owner records both decisions in the same sheet. For the service, they attach the public response and a screenshot showing the installation coverage and enquiry button. For the guide, they record the old response, the destination, and the link from the new resources page. Someone from sales reads the guide to check that the replacement still answers the questions customers ask.

The project owner does not need to inspect server configuration to review this. They need a record that connects each important page to a result: expected behaviour, observed behaviour, time checked, and who will resolve a mismatch. A result of “passed” without the tested address is hard to use when a customer reports that an old link still fails.

If the site has hundreds of similar pages, use automated checks for repeatable properties such as status and destination. Reserve manual review for the pages that matter most and for representative examples of each template. A script can confirm that a redirect reaches a page; it cannot approve the match on behalf of the person who owns the content.

How do you tell a real problem from reporting noise?

Review failures you can reproduce immediately. A broken redirect, accidental index block or unavailable landing page can be investigated without waiting for performance reports. If a page is reachable but Google’s index status is unclear, use URL Inspection to examine the indexed record and, where appropriate, test the live page. A successful live test does not guarantee indexing or tell you what canonical Google will select.

For traffic, compare completed periods with comparable weekdays and account for seasonal changes or changes in campaigns. Use the Search Console performance report to examine pages and queries rather than relying on one total. On a move, look at the old address and its successor together before interpreting a loss on the old address as a loss to the business.

Temporary movement in search visibility can happen during a move. That does not excuse a reproducible launch fault, and a few good days do not prove the move is finished. Keep the inventory and test evidence so you can distinguish a problem on one template, a missing group of pages and a change in demand for a particular service.

When should you make the redesign smaller?

Do not change the domain, paths, navigation and service messaging together merely because a rebuild makes them easy to change. If one part goes wrong, the other changes make the diagnosis harder. If the job is to improve usability and keep the same offer, you may be able to change the design while leaving proven addresses and page purposes in place.

Do not pay for a promise of unchanged rankings. Ask for a mapped inventory, named release checks and a plan for investigating changes after launch. Those are deliverables you can verify. If the redesign needs an address change, there may be sound reasons to accept the extra work; make that decision in the scope rather than discovering it after the launch.

Our web development team and SEO team can review a proposed launch plan together. Tell us what is changing and which pages matter most. A list of public addresses and the intended scope is enough for an initial conversation.