Website Redesign SEO Checklist: Before and After Launch

A redesign can improve a website and still lose useful search traffic if the new version drops pages, changes URLs without a plan, or launches with staging controls still in place. This website redesign SEO checklist treats the redesign as a content and URL migration as well as a visual project.

No checklist can guarantee that rankings will stay unchanged. Google says significant site moves can have temporary visibility fluctuations while pages are recrawled and reprocessed. The goal is to preserve useful information, make the new site understandable, and identify problems quickly.

Before design: document what the current site earns

Export the current public URL list and identify the pages that have impressions, clicks, enquiries, backlinks, or direct business value. Search Console and analytics can help, but speak with sales and support too: some pages answer questions that analytics does not capture well. Save titles, headings, canonical URLs, internal links, form destinations, and any downloads that must remain available.

Mark every URL as keep, improve, merge, or retire. A low-traffic page may still contain a unique specification, policy, or customer answer. Ask the subject owner before removing it. Keep the work focused: if the site also needs a domain move, CMS migration, and a design overhaul, consider sequencing changes so problems are easier to diagnose.

Build a one-to-one URL and content map

For every URL that changes, choose its closest relevant destination. Do not redirect unrelated pages to the homepage just to avoid a 404; Google notes that irrelevant redirects can confuse users and may be treated as soft 404s. Keep the map in the project handoff so design, development, and SEO work from one source of truth.

During development: protect the new site

Build and review the new site on a protected staging environment. Use the old-site inventory to compare content, headings, internal links, and metadata. Check that important information remains available to crawlers in the rendered page. Forms, phone links, downloadable files, and custom scripts should be tested on staging before the launch window.

• Keep staging blocked from indexing until launch, then remove noindex and access restrictions deliberately.
• Set canonical URLs to the final public URLs, not staging URLs or old URLs.
• Retain useful copy, descriptive headings, image alternatives, and internal links unless there is a documented reason to change them.
• Check that analytics and conversion events still measure the actions the business cares about.
• Prepare server-side permanent redirects when technically possible and avoid redirect chains.

Launch day: verify the migration, not just the home page

Test a sample from every page type and every redirect rule. Confirm old URLs resolve to the intended new page, the destination returns successfully, and no redirect loops or chains were introduced. Check canonical tags, robots rules, sitemap URLs, internal links, navigation, forms, and key conversion events on the live domain.

Update the XML sitemap with the current canonical URLs and submit it in Search Console. If the domain itself changed, use Google's site-move guidance for the applicable process. Keep a copy of the pre-launch URL list and test results so a new 404 can be traced to a known decision.

After launch: monitor patterns and fix causes

For the first weeks, review Search Console indexing and query data alongside server errors and real enquiry reports. Group issues by pattern: one redirect rule, one page template, a missing block of content, or a form integration can affect many URLs at once. Fix the underlying template or mapping instead of patching individual symptoms indefinitely.

Keep redirect rules in place for as long as they are useful. Refresh internal links to point directly to the new destinations and update important external profiles where you control them. Google says site moves can take time to be processed; report actual changes and uncertainties to stakeholders rather than promising a recovery date.

Source: Google Search Central: site moves and migrations

Coordinate the launch across the whole team

A migration checklist works best when one person owns the final URL map and each specialist knows when to act. The content owner confirms that copy and media are approved. The developer checks the deployment, redirects, and access rules. The analytics owner verifies measurement. The business contact tests the inquiry path and confirms who will respond. Agree on the launch window and a rollback contact before DNS or hosting changes begin.

Keep a short incident log during launch. Record the affected URL, time discovered, device or browser if relevant, reproduction steps, and whether the issue blocks a customer task. Prioritize critical failures such as unavailable pages, broken redirects, or lost inquiries over small styling differences. When a fix is deployed, repeat the same check and note the result so the team does not rely on memory or assume that a code change solved the user-facing problem.

• Choose a person who can approve a redirect or content decision without waiting for a large group.
• Keep the previous URL list and backup accessible to the people on call.
• Give sales and support a brief note about the change and a path to report customer-facing problems.
• Schedule a follow-up review after the first complete crawl and after enough real-user data is available.

If an important URL has no replacement, decide what visitors should see and whether the old page should return a clear retired-page status. Do not keep a redirect just because it avoids an error in a dashboard. A helpful outcome tells users what changed and offers a relevant alternative when one exists. This small decision keeps the migration plan focused on user intent rather than on making every metric look clean.