Website redesign checklist: what to do before, during and after launch, with the SEO checks

The short answer

A website redesign goes well when the old site is measured before anyone opens a design file. Export the baseline first: Search Console keeps only 16 months of data, and Google Analytics 4 explorations only 2 or 14 months on the free tier. Then list every URL that earns clicks, leads or links, and decide what happens to each one. Build the new site against written goals, with content owners, an accessibility target (WCAG 2.2 AA), a performance budget and a staging site Google can't index. On launch day, test DNS, redirects, robots rules, Search Console and every form. Then compare against the baseline at 30, 60 and 90 days.

Google's own advice for big site changes is to change one thing at a time (Google Search Central). If you're also changing platform or domain, do the move as its own phase and use our website migration SEO checklist for it. To budget the work, see how much a website redesign costs.

Which checklist you need

Before: capture what the old site knows

Export the baseline while it still exists

Every source of "what was working" has a retention limit or a row limit. Export these in the first week of the project, not the week before launch:

Write the numbers into one sheet with the date you exported them. After launch, this sheet is the only fair comparison you'll have.

Rank the pages that earn their keep

Sort pages twice: by organic clicks and by conversions. A pricing page with modest traffic and most of your leads matters more than a blog post with lots of clicks and none. Mark the top pages on both lists as protected: they keep their URL if at all possible, their content is rewritten with care rather than replaced, and each is checked by hand on launch day.

Inventory the content and decide per URL

Crawl the site, add every URL in the sitemap and every URL from the Search Console export, then give each one a decision:

Cutting is a legitimate outcome. When we retired 15 machine-translated languages on dardo.studio on 14 October 2026, it removed 795 of the site's 954 URLs, which together brought about four search clicks a week; every one of them now answers with a 301 to its English version, the closest equivalent, so no visitor or link hits a dead end.

Audit the old site's plumbing

From the crawl, note status codes, existing redirect chains, canonicals, hreflang, structured data, robots rules and sitemaps. Then list everything that isn't a page: forms and where submissions go, booking, chat, payments, maps, embedded videos, PDFs people link to, and every tracking tag. Each needs an owner and a plan on the new site.

Set goals, KPIs and who decides

Then name the people: one decision-maker who approves each phase, the reviewers, an owner for each section's content, whoever signs off legal pages, and whoever controls the domain registrar and DNS. That last one is often found on launch day. Our website brief and RFP builder puts goals, pages, content ownership and approvals on one document you can send to studios.

During: build the new site on purpose

Information architecture

Start from the tasks visitors come to do and the protected pages, then draw the page list and the URL patterns. Keep existing URLs wherever the new structure allows; every URL you keep is one redirect you don't need. Make sure navigation uses real links, because Google can only reliably follow <a> elements with an href attribute (Google Search Central).

Content plan with owners and dates

Content is the part of a redesign most likely to run late, and design can't be approved against placeholder text. Track it like any other deliverable:

When a page is rewritten, keep the topics and terms it ranked for unless you've decided to change its purpose. Our guide to how long it takes to build a website covers why content and approvals, not code, set most schedules.

Design system and accessibility

Build the components once, accessibly, and every page inherits it. Aim for WCAG 2.2 AA, the W3C Recommendation published on 5 October 2023, which added six success criteria at levels A and AA: focus not obscured, dragging movements, target size (at least 24 by 24 CSS pixels, or enough spacing), consistent help, redundant entry and accessible authentication (W3C).

A redesign is the cheapest time to fix the errors most sites carry. WebAIM's 2026 scan of the top million home pages found detectable WCAG failures on 95.9% of them, and the same six errors cause most problems (WebAIM):

Every one of these lives in a component or a template: the color tokens, the image component, the form field, the icon button. Check the full list of criteria with our WCAG 2.2 checklist.

Performance budget

Write limits before design starts, so a heavy hero video or a third chat widget is a decision, not an accident. Google's targets are LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, at the 75th percentile of visits (web.dev). Translate them into budgets per template, such as kilobytes of JavaScript or the number of web fonts; web.dev's performance budgets guide gives examples like keeping critical-path resources under 170 KB. Our INP guide covers the scripts that most often break the interaction budget.

Analytics and consent plan

List every key event on the old site (form submitted, call booked, checkout started) and its name on the new one, so reports stay comparable across launch. Decide which tags fire before and after consent, install them on staging and test that each event arrives once.

A staging site Google can't index

Robots.txt isn't the way to hide staging: Google says it "is not a mechanism for keeping a web page out of Google" (Google Search Central), and a page blocked by robots.txt can't show its noindex rule, because the crawler never sees it (Google Search Central). Put staging behind a password or HTTP authentication. If you use noindex too, keep a list of every place it's set so none survives launch.

SEO preservation, in one table

Keep redirects for at least a year, as Google's site-move guide advises. Our free redirect map generator matches old and new sitemaps and flags chains, loops and redirects to the home page; the migration SEO checklist covers each row in depth, platform by platform.

Launch day

1. DNS. If hosting changes, lower the TTL at least a week ahead (Google Search Central). If nameservers change, allow up to 24 hours for the registrar to update them (Cloudflare). Make sure the person with registrar access is available.
2. Redirects. Ship them in the same release as the new site, then test the whole map with the script below.
3. Crawl rules. Remove staging passwords and every noindex on your list, and check that the production robots.txt doesn't block what should be crawled. Run Search Console's URL Inspection live test on the home page and two protected pages.
4. Search Console. Confirm the property is verified, submit the new sitemap and check that it's read without errors.
5. Forms and email. Submit every form for real. Confirm each submission reaches the inbox and the CRM, and that confirmation emails aren't landing in spam: Gmail requires every sender to authenticate its sending domain with SPF or DKIM (Gmail Help).
6. Analytics. Watch the real-time report while you trigger each key event once.
7. Smoke test. Load the protected pages on a phone, check the 404 page, and run an accessibility and speed check on the main templates.

For step 2, a short script checks that every old URL answers with a 301 to the right target in one hop:

# redirects.csv: old_url,new_url (one per line)
while IFS=, read -r old new; do
  result=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old")
  [ "$result" = "301 $new" ] || echo "CHECK $old -> $result (expected $new)"
done < redirects.csv

The first 30, 60 and 90 days

Search Console data normally appears with a lag of two to three days (Search Console Help), and Core Web Vitals use a rolling 28-day window, so the first useful comparisons come weeks after launch.

Expect movement in the first weeks. With any significant change to a site, Google warns of temporary ranking fluctuations while it recrawls, and for moves with URL changes it says a small to medium-sized site can take a few weeks for most pages to move (Google Search Central). A lasting drop on a protected page is a bug to find, not weather to wait out.

The whole checklist

What to do next

Write the brief first: our website brief and RFP builder turns goals, pages and content ownership into a document studios can quote against, and the redirect map generator handles the first pass of URL mapping. If you'd like Dardo to run the project, see website redesign, or website migration if the platform or domain changes too.