What Is a Website Redesign Checklist and How Do You Use It?

The Document That Prevents the Most Expensive Mistakes

Website redesigns have a failure pattern. The visual design gets all the attention — weeks of iterations on layout and color and typography. Then the build gets done. Then, three days before launch, someone realizes the contact form wasn't configured. Nobody mapped out what happens to the blog posts that are ranking in Google. The 301 redirects were never implemented. The analytics tracking wasn't set up on the new site. The mobile experience was never tested on actual phones.

Each of these is a predictable failure mode that a checklist prevents. A checklist doesn't make the project faster — it prevents the scramble that happens when critical items are discovered at launch time, when fixing them is most disruptive and most expensive.

This guide is that checklist: every meaningful task across every phase of a website redesign, organized so the right things happen in the right order.

Phase 1: Discovery and Planning Checklist

Before any design begins. The decisions made here shape everything else.

Business and Goal Alignment

• □ Primary business goal for the new website documented (lead generation, e-commerce, brand awareness)
• □ Secondary goals ranked by priority
• □ Success metrics defined and measurable (conversion rate target, organic traffic target, lead volume target)
• □ Timeline established with key milestones and hard deadlines documented
• □ Budget allocated and approved including contingency
• □ Decision-maker identified — one person with authority to approve deliverables
• □ Stakeholders identified and roles defined (who reviews, who approves, who provides content)

Current Site Audit

• □ Google Analytics data exported — 12 months of traffic by page
• □ Google Search Console data exported — 12 months of queries, impressions, clicks
• □ Complete URL crawl exported from Screaming Frog — every URL with response code
• □ Backlink profile exported from Ahrefs or Semrush — all pages with external links
• □ Top-performing pages documented (by traffic, by conversion, by rankings)
• □ Core Web Vitals baseline recorded for key pages
• □ Content inventory completed — what to keep, update, merge, or delete
• □ Conversion funnel analysis completed — where visitors currently drop off
• □ User testing or session recording review — known UX issues documented

Platform and Technology Decisions

• □ CMS/platform selected (Webflow, WordPress, Shopify, custom) with rationale
• □ Hosting environment selected
• □ Required third-party integrations identified (CRM, email marketing, payment, booking, analytics)
• □ Integrations verified as compatible with chosen platform
• □ Performance requirements defined (target Core Web Vitals scores)
• □ Domain and SSL situation documented (existing domain? new domain? migration needed?)

Information Architecture

• □ New site architecture documented — all pages, hierarchy, navigation structure
• □ URL structure decided for new site (matching existing where possible to minimize redirects)
• □ Redirect map built — every old URL mapped to new URL equivalent
• □ Redirect map reviewed by someone with SEO expertise
• □ Important pages verified to have equivalent destinations in new architecture

Phase 2: Design Checklist

Brand and Visual Direction

• □ Brand guidelines document available and provided to designer
• □ Logo files provided in all required formats (SVG, PNG with transparency)
• □ Color palette documented with hex codes
• □ Typography choices confirmed (web fonts licensed for web use)
• □ Photography and imagery direction established
• □ Visual reference sites provided with specific notes on what's liked/disliked

Design Review Criteria

• □ All key page templates designed (homepage, services, about, contact, blog listing, blog post)
• □ Mobile designs reviewed alongside desktop designs
• □ All interactive states designed (hover, focus, active, disabled, error states)
• □ Color contrast checked against WCAG AA requirements for all text/background combinations
• □ Typography hierarchy clear at a glance — headings obviously differentiated from body
• □ Navigation design clearly functional on mobile (hamburger menu or equivalent)
• □ Form designs have visible labels above fields (not just placeholder text)
• □ Primary CTA visible above the fold on homepage
• □ Social proof integrated into key conversion pages
• □ Design approved by decision-maker before development begins

Phase 3: Content Preparation Checklist

Content should be ready before or during development — not after.

• □ All page copy written, reviewed, and approved
• □ Homepage headline tested with non-insider feedback (does it pass the 5-second clarity test?)
• □ All team/about photos taken or selected
• □ All product/service imagery collected or photographed
• □ All images compressed before delivery to developer (or format/compression requirements specified)
• □ Alt text written for all images
• □ All blog posts identified for migration — decisions documented (migrate, update, archive)
• □ Title tags written for all key pages
• □ Meta descriptions written for all key pages
• □ Testimonials collected and approved for use
• □ Case studies written or updated
• □ Legal pages current (Privacy Policy, Terms of Service, Cookie Policy if required)

Phase 4: Development Checklist

Technical Foundation

• □ SSL certificate installed and verified (HTTPS active)
• □ HTTP to HTTPS redirect configured and tested
• □ www to non-www (or vice versa) redirect configured
• □ Canonical tags implemented on all pages (self-referencing canonicals at minimum)
• □ Robots.txt configured correctly for production environment (not blocking crawlers)
• □ XML sitemap generated and accessible at /sitemap.xml
• □ Page titles and meta descriptions populated on all pages
• □ H1 tags present and unique on all pages
• □ Alt text on all images
• □ Language attribute on HTML element (<html lang="en">)

Performance

• □ All images compressed and served in modern formats (WebP/AVIF where supported)
• □ LCP image preloaded on pages with image hero
• □ Image dimensions specified on all img elements (prevents CLS)
• □ Lazy loading on below-fold images
• □ JavaScript deferred or async where appropriate
• □ Third-party scripts minimized — only those necessary for launch
• □ Server-side caching configured (for WordPress/dynamic sites)
• □ CDN configured (Cloudflare or platform CDN)

Functionality

• □ All contact forms tested and delivering to correct email addresses
• □ All forms have confirmation messages or redirect to thank-you pages
• □ Thank-you pages implemented for conversion tracking
• □ All checkout flows tested end-to-end (e-commerce)
• □ All third-party integrations connected and tested (CRM, email marketing, etc.)
• □ All external links verified working and opening in new tab where appropriate
• □ All downloadable files accessible and downloading correctly
• □ Search functionality tested (if included)
• □ Booking/scheduling system tested (if included)

Redirect Implementation

• □ All redirects from the redirect map implemented on staging
• □ Every redirect in the map tested — old URL → new URL verified
• □ No redirect chains (A→B→C should be consolidated to A→C)
• □ No redirect loops detected

Phase 5: Pre-Launch QA Checklist

Cross-Browser and Cross-Device Testing

• □ Tested in Chrome (Windows and Mac)
• □ Tested in Firefox
• □ Tested in Safari on Mac
• □ Tested on iPhone using Safari (iOS)
• □ Tested on Android device using Chrome
• □ Tested on iPad (tablet breakpoint)
• □ Tested at multiple viewport widths in Chrome DevTools (320px, 375px, 768px, 1024px, 1280px)

Performance QA

• □ PageSpeed Insights run on homepage — mobile score documented
• □ PageSpeed Insights run on primary service/product page — mobile score documented
• □ Core Web Vitals in "Good" range on key pages (or issues documented and scheduled)
• □ Performance scores equal to or better than pre-redesign baseline

SEO QA

• □ Screaming Frog crawl of staging — no broken links, no missing title tags, no missing H1s
• □ Staging environment confirmed as noindexed (robots.txt or noindex meta tag)
• □ Structured data validated with Google Rich Results Test on key templates
• □ Breadcrumb schema implemented where appropriate
• □ Open Graph tags verified (Facebook/LinkedIn sharing preview)

Accessibility QA

• □ Lighthouse accessibility audit run — score and flagged issues documented
• □ WAVE or axe accessibility scan completed on key templates
• □ Keyboard navigation tested — all interactive elements reachable by Tab
• □ Focus indicators visible on all interactive elements
• □ Color contrast verified for all text/background combinations

Content QA

• □ Every page read for typos and factual accuracy
• □ No placeholder text (Lorem Ipsum) remaining anywhere
• □ All contact information current and correct
• □ Team page reflects current team
• □ Service/product pages accurate to current offerings
• □ Legal pages current

Phase 6: Launch Checklist

• □ DNS TTL lowered to 300 seconds (5 minutes) — 48 hours before launch
• □ Launch scheduled for Monday–Wednesday, morning hours (team available)
• □ Staging environment backup taken before launch
• □ New site deployed to production
• □ HTTPS verified on live domain
• □ Robots.txt production version verified (not blocking crawlers)
• □ Noindex tags NOT present on production pages that should be indexed
• □ 10–20 sample redirects from redirect map tested on live site
• □ All forms tested on live site
• □ Checkout tested on live site (e-commerce)
• □ Google Analytics 4 property verified receiving live data
• □ Google Analytics conversion goals/events configured and tracking
• □ XML sitemap submitted to Google Search Console
• □ Google Search Console property configured for new site (domain migration tool if domain changed)
• □ Search Console verified with no immediate errors
• □ Bing Webmaster Tools sitemap submitted
• □ Social media profiles updated with new URL if changed
• □ Email signature URLs updated
• □ Google Business Profile URL updated if changed

Phase 7: Post-Launch Monitoring Checklist

Days 1–3

• □ Google Search Console Coverage report checked for new errors
• □ Organic traffic monitored in GA4 — no dramatic unexpected drops
• □ Forms continue delivering (re-test manually)
• □ Any critical bugs reported by internal team or users addressed immediately

Week 1

• □ Organic traffic trend compared to pre-launch baseline
• □ Search Console for crawl errors and coverage issues
• □ Core Web Vitals data beginning to populate in Search Console
• □ Any redirect errors or 404s flagged in Search Console addressed

Month 1–3

• □ Organic traffic comparison: new site vs. 3 months pre-redesign
• □ Keyword rankings comparison: pre vs. post redesign
• □ Conversion rate comparison: contact form submissions, purchases, etc.
• □ Core Web Vitals field data — key pages in Good range?
• □ Any sustained traffic or ranking losses investigated and addressed

The Bottom Line

A checklist doesn't make a website redesign succeed — talent, strategy, and good execution do that. What a checklist does is prevent the specific, predictable failures that happen when items fall through the cracks during a complex project. Missing redirects, unconfigured analytics, production environments inheriting staging noindex settings — all preventable with systematic tracking.

Use this checklist as a working document, checking off items as they're completed, flagging items that need investigation, and treating any unchecked item at launch time as a launch blocker until it's either resolved or consciously accepted as a known risk.

At Scalify, every website launch follows a version of this checklist — a systematic process that ensures every site we deliver is technically correct, performance-optimized, and SEO-ready from the moment it goes live.