Website Redesign Checklist: SEO & Launch

A launch checklist with observable acceptance criteria

1. Capture a baseline before changing the site.

Record the previous 28 days of search clicks, impressions and average positions by query and page. Note country, device and search-type filters. Keep a longer reference period when the sample is small or the business is seasonal. Save the URLs that already attract visits or links.

Record actual enquiry receipts separately from button clicks or opened email drafts. A redesign cannot be evaluated using a form-submit event that fires on failed delivery. If measurement is incomplete, document that gap before setting outcome targets.

2. Turn the old sitemap into a decision inventory.

Give every useful existing URL a decision: keep, rewrite, merge, move or retire. Include PDFs, product documents and landing pages that may not appear in the main navigation. A page with no recent clicks can still serve a customer task or have external links.

For a B2B site, preserve the information a buyer uses to qualify a supplier: specifications, applications, documentation, approved proof and the RFQ path. Ask sales which missing details currently require repeated emails. Use those answers to shape the new pages.

3. Map moved pages to relevant destinations.

For each moved URL, select the closest useful replacement. Do not send every retired product or article to the homepage. If a resource has no replacement, decide whether an appropriate not-found response is the right outcome.

Use the free redirect map checker linked below to find exact-match loops, chains and conflicting rules. It reviews the plan only. Your developer still needs to implement permanent redirects where appropriate and verify the actual HTTP response and destination content. Wildcard rules require separate testing.

4. Check the complete journey on the release candidate.

Test navigation, long headings, product tables, downloadable documents and the contact journey on mobile and desktop. Use a keyboard to reach links, controls and form errors. Run a real delivery check with the approved receiver and confirm both success and failure behavior.

Check page titles, descriptions, self-canonicals, language alternates, robots directives, structured data and the sitemap against the intended production URLs. Ensure launch pages are not accidentally left noindexed. Test redirects on the actual host configuration; a local route preview cannot prove the production rules work.

5. Release with a named owner, then compare like with like.

Write down who approves launch, who checks the production release, what failures trigger rollback and how the previous release can be restored. Check priority old URLs and enquiry receipt immediately after deployment. Submit the updated sitemap through Search Console when it is ready.

Review crawl and indexing issues over the following days, then compare matching query/page groups over a consistent reporting window. A change in the site-wide average position can reflect a different mix of queries. Google’s site-move guidance explains that rankings may fluctuate while pages are recrawled; a launch checklist cannot promise stable positions.

Turn the website redesign process into a milestone record.

Use this worksheet to build the website redesign timeline from approved inputs. Add actual owners and dates after agreeing the scope; these stages are a planning example, not a fixed delivery schedule.

When a content approval, access requirement or migration decision changes, record the affected milestone and revise its date. Keep release approval separate from visual approval.

A small migration example you can test before launch

Use a three-URL rehearsal before reviewing the full migration: one retained product page, one moved PDF and one discontinued item. The following paths are illustrative, not a ZequnWeb customer result. Record the expected response and compare it with the production response after release.

ZequnWeb’s redirect map checker can flag exact-match loops, chains and conflicting mappings before implementation. It cannot verify live HTTP responses, wildcard rules or whether two pages satisfy the same buyer task. Keep those manual acceptance checks in the worksheet.

Keep AI answers accurate while the site changes

Preserve the facts a buyer or answer system needs: product names, current specifications, company identity, service scope and the conditions behind pricing. Put each answer beside the relevant decision and link to its supporting document or published work. If a capability is an independent concept, label it as a concept rather than a delivered customer outcome.

For a small fixed set of buyer questions, record the AI platform, date, prompt, factual answer and cited URL before and after release. A mention, a citation, a referral and a qualified enquiry are separate observations. Search Console performance for Google AI features is included in overall Web search reporting; it does not provide a standalone AI Overview report.