Website Launch

Website Redesign Checklist

Redesigning a website introduces real risk: lost rankings, broken redirects, missing tracking, and launch surprises. This checklist keeps scope, inventory, handoff, QA, and monitoring under control from day one.

Use when: You are planning or actively running a website redesign — not a minor content update.

Best for: Agencies, freelancers, and in-house teams managing full site rebuilds or platform migrations.

Start with: Clarify redesign goals and document the current site before touching anything.

Then review: Website Launch Checklist before publishing.

Copy workflow

Clarify redesign goals

A redesign without defined goals produces a site that looks new but performs the same. Lock these in before any design work starts.

  1. Step 1

    Write the redesign brief

    Define what the new site must accomplish that the current site does not. Include business goals, audience changes, and any new features required.

  2. Step 2

    List what is not changing

    Identify pages, content, and functionality that must be preserved exactly. This protects high-performing pages from being inadvertently dropped.

  3. Step 3

    Agree on the scope boundary

    Confirm which pages are in scope, which are out of scope, and who approves changes to that list during the project.

  4. Step 4

    Set measurable success criteria

    Decide how you will know the redesign worked — conversion rate, page speed, lead volume, bounce rate, or another metric tied to the brief.

Audit current site and content

You cannot protect what you have not inventoried. Run this audit before wireframes or copy are produced.

  • Export a full page list using a crawl tool (Screaming Frog, Sitebulb, or similar).
  • Flag each page as keep, update, merge, redirect, or remove.
  • Note which pages drive organic traffic, backlinks, or conversions — these are highest risk to lose.
  • Document all forms, integrations, tracking pixels, and third-party scripts currently in use.
  • Screenshot or archive the current design for reference during QA.
  • Identify all existing redirect rules before the new site is built.

Protect SEO and URLs

URL changes and missing redirects are the fastest way to lose organic traffic in a redesign. Treat this section as non-negotiable.

  • Map every old URL to its new URL or confirm it stays the same.
  • Write 301 redirect rules for every URL that is changing or being removed.
  • Verify that all canonical tags, meta titles, and meta descriptions are migrated to the new site.
  • Confirm that the new site preserves heading structure and internal link anchor text for key pages.
  • Check that structured data (schema) is carried over or updated for all relevant page types.
  • Test that XML sitemaps and robots.txt are correct on the new site before launch.
  • Preserve any Google Search Console and analytics integrations.

Design and build handoff

Most redesign surprises happen at the handoff between design, development, and content. Resolve these before content is loaded.

  • Confirm final design files are approved and version-locked before development begins.
  • Agree on a component or template naming system that matches between design and code.
  • Establish who enters final content — designer, developer, content editor, or client.
  • Define who has sign-off authority at each stage: design, content, QA, and launch.
  • Create a staging environment that mirrors production before content population begins.
  • Lock the staging URL from indexing with robots.txt or password protection.

Pre-launch QA

Run QA on staging before any DNS change. Fix blockers, then re-verify the items most likely to break after migration.

  • Test every page at mobile, tablet, and desktop breakpoints.
  • Submit every form and confirm confirmation emails and CRM entries work.
  • Verify every internal link, navigation item, and breadcrumb leads to the correct destination.
  • Confirm all redirects return 301 — not 302 or a chain of multiple hops.
  • Check that analytics tags, conversion pixels, and event tracking fire correctly.
  • Run a Lighthouse or PageSpeed test and resolve any critical performance issues.
  • Review all page titles, meta descriptions, and canonical tags are unique and correct.
  • Confirm the favicon, logo, and brand assets appear correctly in all browsers.

For a detailed pre-launch process, use the Website QA Checklist alongside this section.

Launch monitoring

The first 72 hours after a redesign launch carry the highest risk. Run these checks immediately after DNS propagation completes.

  • Confirm the live site resolves correctly and SSL is active.
  • Verify Google Search Console shows no spike in crawl errors or 404s.
  • Check analytics is receiving data and key conversion goals are firing.
  • Spot-check redirects on the live domain — not just staging.
  • Monitor Core Web Vitals for any regression versus the old site.
  • Review any error logs or server monitoring alerts in the first 24 hours.

After launch, continue monitoring with the Post-Launch Monitoring Checklist and the SEO Site Launch Checklist.

Website Redesign Checklist

CLARIFY REDESIGN GOALS
[ ] Write the redesign brief with goals and constraints
[ ] List what is not changing
[ ] Agree on scope boundary and change process
[ ] Set measurable success criteria

AUDIT CURRENT SITE AND CONTENT
[ ] Export full page list via crawl tool
[ ] Flag each page: keep / update / merge / redirect / remove
[ ] Note high-traffic and high-conversion pages
[ ] Document all forms, scripts, and integrations
[ ] Screenshot current design for QA reference
[ ] Document existing redirect rules

PROTECT SEO AND URLS
[ ] Map every old URL to new URL
[ ] Write 301 redirect rules for all changed or removed URLs
[ ] Migrate canonical tags, title tags, meta descriptions
[ ] Preserve heading structure and internal links on key pages
[ ] Carry over structured data / schema
[ ] Verify sitemap and robots.txt on new site
[ ] Preserve Search Console and analytics integrations

DESIGN AND BUILD HANDOFF
[ ] Version-lock final design files before dev starts
[ ] Agree on component naming between design and code
[ ] Define who enters final content
[ ] Assign sign-off authority at each stage
[ ] Set up staging environment that mirrors production
[ ] Block staging from indexing

PRE-LAUNCH QA
[ ] Test every page at mobile, tablet, desktop
[ ] Submit every form and verify delivery
[ ] Check all internal links and navigation
[ ] Verify all redirects return 301
[ ] Confirm tracking tags fire correctly
[ ] Run Lighthouse / PageSpeed check
[ ] Review all title tags, meta descriptions, canonicals
[ ] Check favicon, logo, and brand assets

LAUNCH MONITORING
[ ] Confirm live site resolves with active SSL
[ ] Check Search Console for crawl errors / 404s
[ ] Verify analytics is receiving data
[ ] Spot-check redirects on live domain
[ ] Monitor Core Web Vitals for regression
[ ] Review error logs in first 24 hours

Next step

Use this next

After completing the redesign checklist, move to launch and post-launch resources to confirm the new site is stable.

Or return to the Website Launch hub to choose a different path.

Website Redesign FAQ

When should you redesign vs. just refresh?

A refresh makes sense when visual changes and content updates are enough to meet your goals. A full redesign is warranted when the site architecture, technology stack, or fundamental user flow needs to change. If top-performing pages are working well, preserve them — the risk from a full redesign is rarely worth it for pages that already convert.

What should you do before deleting old pages?

Check organic traffic, inbound links, and conversion data for every page before removing it. If a page has meaningful traffic or backlinks, set a 301 redirect to the most relevant new page. Never delete a page without a redirect if it appears in Google Search Console with impressions.

Who needs to sign off before the new site goes live?

At minimum: the project owner who defined the brief, the person responsible for tracking and analytics, and whoever owns the SEO. If the site has legal or compliance requirements, add the relevant stakeholder. One person should have final authority — redesigns that require unanimous approval from large groups tend to stall at launch.

How long should QA take for a redesign?

Allow at least one full day per 20–30 pages for thorough QA, plus time for a second pass after fixes are applied. For larger sites or complex integrations, budget more. Rushing QA at the end of a redesign is the most common cause of post-launch cleanup work.