A Practical
Website Redesign Checklist

Start with a simple document that defines the main goals of the redesign (improve UX, revamp site structure, fix performance issues, clarify messaging, rebrand...), and the specific KPIs you care about.

This is the foundation of your website redesign strategy.

As an example, for our rebrand, we cared about three things:

• •Performance: LCP < 2.5s, CLS < 0.1, INP < 200ms
• •SEO: Maintain traffic for top 20 landing pages
• •Team: Empower marketing to launch new pages without dev help

We create a project dashboard where each task, role, deadline, and priority is clearly assigned to the appropriate team member.

Roles & responsibilities

Priorities and project steps are clearly defined so everyone knows exactly when and how to contribute.

• •Who is responsible for design, content migration, performance QA, SEO, and go-live?
• •Who owns communication, change management, stakeholder updates?
• •Who has the authority to approve designs and go-live?

Timeline with key milestones

We build a shared roadmap between the project team and the main stakeholder.

Each milestone is clearly defined, and we do not move forward until the previous step is validated.

The roadmap is updated in near real-time whenever there's a shift in planning or an unexpected event.

Communication & escalation

• •Set up weekly check-ins: one general meeting, and several specific sessions (design, dev, content...)
• •Create dedicated Slack channels for the project and by area of expertise
• •Use a Notion dashboard with a Kanban board to manage the workflow, plus a Knowledge Base to centralize information
• •Connect Google Drive with Notion for storage and access to all source files

Data analysis combines dashboards and journey mapping to show how users behave, where they drop off, and which segments matter most.

It clarifies your site's performance, exposes hidden friction points, and reveals opportunities to improve the funnel.

Analyze the baseline performance of your existing website.

• •Build a dashboard to track critical metrics as a baseline to measure improvement after launch
• •Analyze key website funnel drop-off points on desktop and mobile to prioritize opportunities
• •Identify best customer segments by size/conversion opportunity, and map where their journeys break
• •Highlight what users search for (or can't find)
• •Identify top-performing content & landing pages

From insight to impact. Start smart to ensure success.

Create a technical scope doc that includes:

Core systems & integrations

• •CMS, CRM, analytics, tag manager, chat, forms, heatmaps
• •Any platform constraints (Webflow/WordPress limitations, hosting rules, etc.)
• •Login systems, gated content if relevant

Third-party scripts

• •What scripts need to run? Where (all pages, certain templates)?
• •Are there any old scripts you should remove?

Non-negotiables

• •Must preserve CMS structure (blog, case studies, etc.)
• •URL structure and redirects must match legacy site where needed
• •Legal/compliance needs: GDPR consent, cookie banners

This is a great doc to review with both marketing and engineering. It's common for important scripts or URL behaviors to get missed.

Before you build anything, I want you to sit down and answer this one question:

What is the single thing you want website visitors to do?

This is your Primary CTA and should be the default action people can take across the site. Obviously, there will be exceptions, but knowing the #1 thing ahead of time is critical.

Once you have your sitemap created, go through each page and define the primary and secondary CTAs for each page.

This will help guide the wireframing process (because now you know the target for each page).

Here are some examples of key milestone steps that are defined ahead of a website project and included in our roadmap:

1. Wireframes & Copywriting → Review and Proofreading
2. Sitemap & Architecture → Review and Approval
3. UX Research → Features Mapping, Data Analysis, and User Interviews
4. Art Direction → Mockups & Prototyping
5. UI → Style Guide and Components
6. Performance + Accessibility Optimization
7. Go-live prep + DNS switch

We've all been to websites where something simply feels off.

You can't put your finger on it, but navigating the site feels clunky, and reading pages takes more effort than it should.

There's a good chance that the site has experienced Design Drift. Every page looks a little different. The buttons look a bit off. Colors are used seemingly randomly.

When you're going through this redesign process, I want you to change the way you think.

Rather than designing page-by-page, I want you to ask this question:

What are the building blocks I need in order to lay out every page on the site?

Your website is a puzzle, and you need to design the pieces.

This is a core principle of scalable web design.

Here's an exhaustive list of the most common reusable components found in most marketing and product sites:

• •Hero/header sections (with CTA and image)
• •Feature blocks (icon, text)
• •Call-to-action strips (e.g. "Get started" bars across pages)
• •Stats or number counters ("Trusted by 1000+ customers")
• •Comparison tables
• •Testimonial rows
• •Logo grids (clients, partners...)
• •Navigation bars
• •Search bars
• •FAQ accordions
• •Cards / grids with hover effect
• •Author and contact boxes
• •Alert banners
• •Form components

Pick one high-impact page and build it using your actual design tokens and reusable layout components.

Then, QA the following:

• •Does the layout hold across breakpoints?
• •Do paddings and text styles match Figma?
• •Are components easy to duplicate and update?

Use this as a first milestone review with design, dev, and marketing to spot layout and content issues early.

Don't wait until QA to design a user-friendly website. Accessibility starts with design.

• •Color contrast: Ensure all text has at least 4.5:1 contrast (use WebAIM Contrast Checker).
• •Don't rely on color alone: Pair colors with icons, underlines, or text labels to convey meaning.
• •Keyboard flow: Design interactive elements (menus, accordions, modals) with focus order and focus visibility in mind.
• •Text spacing & line length: Use readable font sizes and line spacing. Keep line lengths under 80 characters.
• •Touch targets: Buttons and interactive elements should be at least 24x24px (WCAG 2.2: 2.5.8 Target Size).
• •Consistent help: Make help mechanisms like chat widgets, contact info, or FAQs consistently available (WCAG 2.2: 3.2.6).

Prioritizing accessibility from the start ensures a better user experience for everyone.

Once your website design is complete, test it with real users before development.

Prototype testing puts your proposed journey in front of a closed group of participants using guided and unguided tasks.

Observe how they navigate, interact, and respond. You'll see what works, what confuses, and what needs refinement before a single line of code goes live.

• •Create a prototype of your new website design to cover pages you intend to include in the study
• •Build a user study to answer key questions from your research and ensure the new designs solve real pain points — use platforms like Useberry or UserZoom
• •Structure your questions in a way that does not create biased feedback
• •Analyze responses to find key themes — only consider what multiple users comment on
• •Translate those themes into design iterations

The smartest way to launch is to test before you invest.

Ensure developers have everything they need to build accurately.

• •Review designs with your lead developer before final stakeholder approval to catch potential issues
• •Annotate all functions, interactions, and animations; include examples when possible
• •Package all assets (images, fonts, etc.) for easy developer access
• •Schedule a walkthrough session or record a detailed walkthrough of the design

A 30-minute design review can save hours of back-and-forth during development.

Start by systematically cataloging everything on your existing site to avoid losing important pages or content during the revamp or redesign.

• •Crawl your current site (tools: Screaming Frog, Sitebulb, etc.)
• •Export all live URLs (trim query parameters if any)
• •Don't forget hidden/noindex pages
• •Images and their alt tags
• •Capture meta data (title, description...) + OpenGraph data during this step if possible

Start with your full URL inventory from the previous step and prioritize SEO preservation:

• •Map every existing URL from your current site to its new location before migration starts
• •Transfer all metadata intact: page titles, descriptions, structured data
• •Set up 301 redirects proactively — don't wait until after launch
• •Preserve URL structures when possible to minimize redirect chains
• •Remove outdated content during migration — this actually benefits SEO rankings
• •Test redirect chains and canonical tags before going live

An SEO-first approach protects your search visibility and often improves it. Our clients typically see 25-30% increases in organic traffic post-migration when SEO is prioritized from day one.

We follow this framework to prepare and update media assets effectively:

1. Audit and inventory all media assets. Gather existing photos, videos, graphics, and other brand visuals. Identify what needs updating to match the new design's style and layout.
2. Plan for new content production. Consider what new assets you'll need, whether simple photos or more advanced elements like video clips or animations.
3. Align assets with design requirements. Ensure your team knows where and how assets will appear in mockups or prototypes so they're produced at the right resolution and format for your web design.
4. Organize and name files clearly. Use a consistent folder and naming structure to improve collaboration and support SEO (e.g. descriptive/keyword-friendly filenames)
5. Prepare assets for web performance. Resize images, compress videos, and optimized advanced elements (animations, scroll-triggered sequences) using tools like TinyPNG or Lottie to ensure fast loading on all devices.

Staging is crucial for risk mitigation — do your QA here before pushing anything to production, so you can catch bugs before your customers do.

Aim for production parity

A staging environment is most useful when it mirrors the setup of your production environment: same infrastructure, integrations, SSL configuration. Different conditions = different bugs.

Look for scripts in the following places:

• •Head and footer of your HTML (<head> meta tags)
• •Platform-specific code (Site Settings → Custom Code)
• •Theme-specific code
• •Apps & plugins
• •Embed components
• •Google Tag Manager container
• •Form events
• •Cookie banners
• •Page-specific scripts

Pro tip: now is a great time to do a full walkthrough with script owners, not just website/marketing ops — sales, product, support...

A backup is your safety net, but only if it's complete, restorable, and timed perfectly.

In tandem with version control, backups ensure that you can recover quickly from launch-day issues, server faults, or last-minute client change reversals.

At the CMS level

Most CMS platforms offer built-in or plugin-based solutions for backup and version control. For WordPress projects, our preferred approach includes:

• •Version Control: All code (themes, custom plugins, functions) is stored in Git repositories (e.g., GitHub), enabling precise rollback of changes and collaborative review workflows.
• •Backups: Use UpdraftPlus, BlogVault, Jetpack VaultPress, or server-level backups or snapshots via your service provider such as Vultr or AWS.
• •Ensure automated, incremental backups are running daily, with full backups taken prior to launch.
• •Storage: Off-site storage (S3, Backblaze B2, or Wasabi) provides redundancy beyond the origin server.
• •Database-specific backups are often scheduled separately in high-performance environments, especially where WooCommerce or LMS plugins are in use.

At Made Neat, we never go live without a proven, automated backup system, tied into our version control process, and recoverable within minutes.

Once your reference page is locked:

• •Reuse the validated containers, typography, and layout rules
• •Stick to your design system: no one-off paddings, colors, or components
• •Spot-check pages against the reference: "Does this match the homepage logic?"
• •Don't try to batch it all: go page by page and log issues as you go

This creates a scalable system instead of a patchwork of exceptions, streamlining your web development process.

Follow best practices for reponsive design.

Don't trust browser dev tools alone. Pinch zoom and text scaling, for example, are hard to simulate.

• •Minimum test matrix: Desktop: ≥1440px, Laptop: 1024px, Tablet: 768px (portrait & landscape), Mobile: 375px (portrait & landscape)
• •Browsers: Chrome, Safari, Firefox...

Key things to check

• •Light and dark mode (if supported)
• •Fixed headers/footers — do they block content at small viewports?
• •Responsive menus — do they open and close correctly on touch devices?
• •Does content reflow logically on narrow screens? (Cards stacking, font sizes, image scaling)
• •Pinch-to-zoom and text scaling — nothing should break or overlap

Remember that browser emulation will miss stuff like touch target spacing, gesture conflicts, and more, so ensure your site is fully mobile-friendly by testing on real hardware.

When migrating platforms, forms require extra attention since integrations often break:

• •Inventory all current form integrations before starting: HubSpot, Mailchimp, CRM systems
• •Test form handlers in staging with real data submissions (not just test data)
• •Verify form data flows correctly to all connected systems post-migration
• •Check form confirmation emails, auto-responders, and thank-you page redirects
• •Test lead routing and sales team notifications — these often use different APIs
• •Validate marketing automation triggers still work with new form structure

Don't assume integrations will "just work" on the new platform. Test every connection point with real data to avoid losing leads post-launch.

In eCommerce, search should be treated like a growth channel.

You can use native search, but consider integrating with tools like Algolia, Searchspring, or others to build smarter query parsing and ranking logic.

Here are some more ideas:

• •Enable faceted and filtered search
• •Let users combine filters
• •Ensure filters persist across paginations and don't kill performance
• •Dynamically promote top-converting SKUs, seasonal collections, high-inventory products
• •Demote out-of-stock, low margin items, or duplicate variants

Search result UX tips for higher conversions:

• •Show product title, image, price, ratings, badges ("New", "Only 3 left...")
• •Typo tolerance, synonym mapping, smart autocomplete
• •Load fast: search should respond in <300ms — cache results and prefetch when possible

Finally, don't forget to track "zero results" terms so you can build pages for them.

Don't try to reach 100/100 on PageSpeed Insights.

Here are some of the most common reasons for slow pages, and website redesign tips to avoid them:

• •Large images above the fold: consider removing them, or move them further down the page (lazy-loaded)
• •Self-host fonts and enable font-display: swap for a faster perceived load speed
• •Defer non-critical scripts
• •Minimize animations and GIFS if not critical (e.g. fade-ins... is it really necessary?)
• •Minimize DOM complexity in general: unused wrappers, deep nesting, etc. — just reuse components and containers!

Here's a systematic approach to content migration:

• •Export CMS collections using a CSV export or your CMS API (the latter is preferred)
• •Preserve rich text fields, images, and metadata
• •Watch for broken formatting in embeds (code blocks, tables)
• •Maintain slugs and canonical tags where possible

Here's a quick review checklist:

• •Consistent naming for classes, sections, components
• •Reusable components clearly labeled and documented
• •No orphaned styles, IDs, or unused classes
• •Scripts scoped to only the pages that need them
• •Clean folder structure (sections, partials, assets)
• •Comment tricky logic or custom embeds in a shared document

Here's what teams tend to forget:

• •Bad inputs: invalid emails, empty fields, duplicate submissions
• •Mobile experience: CTA taps, keyboard overlap, form spacing
• •Slow network conditions: simulate 3G or throttled connections
• •Lead attribution: test if UTM parameters are preserved through the flow
• •Confirmation steps: check emails, thank-you pages, and CRM triggers

When every core journey is properly tested, you can be confident that your website redesign delivers the intended user experience.

List of interactive components to test:

1. Check every button, link, and menu with both a mouse and keyboard (Tab, Enter). Try them on desktop and mobile.
2. When filling out a form, make sure you get a clear message if you miss something or type something wrong.
3. Open and close all pop-ups and dropdown menus to confirm they display and close without issues.
4. Try a screen reader or your device’s accessibility options to make sure every field, button, or message is announced clearly.
5. Make sure buttons and clickable items aren’t too small or too close, especially on mobile devices.
6. Add clear icons or labels to explain actions or status; don’t rely on color only to show differences.
7. Open your site on different devices (phone, tablet, computer) to check that everything works easily everywhere.

Here's how you can audit your links:

• •Use Screaming Frog or Sitebulb to crawl both old and new sites
• •Export URL maps and diff for missing pages or bad redirects
• •Use the Check My Links Chrome extension for individual pages
• •Watch for edge cases like download links (PDFs), anchor links, and campaign URLs

Quick technical SEO checklist:

1. Use an SEO tool or browser extension to see if every page has a clear, short (less than 60 characters) and unique title and description.
2. Check that each important page has a canonical tag to avoid Google showing duplicates.
3. Go to yoursite.com/robots.txt and /sitemap.xml to make sure search engines can access your pages and your sitemap is up to date.
4. Test your business info, articles, or products with Google Rich Results Test to confirm schema and structured data are correct.
5. Look for the lock symbol (https) in your browser; if it’s missing, ask your host to activate SSL.
6. Use PageSpeed Insights to check your site’s speed, and follow the main tips to improve your score.
7. Open your site on a phone and check that it’s readable—or use Google’s Mobile-Friendly Test tool.
8. Look for broken links and 404s with a tool like Screaming Frog; fix or redirect anything that doesn’t work.

Tools like Lighthouse, Axe DevTools, and WAVE are great for catching low-hanging issues (e.g., missing alt text, low contrast).

But they don't catch:

• •Poor focus order
• •Missing ARIA live regions
• •Overuse of "clickable divs" with no semantics
• •Contextual cues like link meaning ("Click here")

Always combine manual testing with automation.

Stakeholder feedback is often where web ops team lose their momentum.

Without a clear system, feedback trickles in via Slack threads, vague screenshots, or messy Notion docs, and things fall through the cracks.

Instead, use Marker.io to collect clear visual feedback during the redesign, directly on the staging site.

1. Install Marker.io in 2 minutes, no dev time required.
2. If stakeholders spot an issue, they can click the "Report a bug" button directly on the page.
3. Issues sync to tools like Jira, Linear, Notion, Trello, and more.

Every report includes metadata like browser info, URL, screen size, and console logs.

No more "what page was this on?" or "can you reproduce this?" back-and-forth.

Here's what a real launch day checklist should cover:

• •Who updates DNS?
• •Who will monitor for bugs or downtime—and how are these issues reported internally?
• •Who has authority to say "we revert"?
• •Where is the rollback plan stored?
• •Where do issues get reported (Slack, Notion, email)?
• •Who is watching those channels?

Prepare your DNS cutover:

• •Reduce TTL to 300s (5 min) at least 24h before launch
• •Confirm you have access to DNS or know who does
• •Prepare new A/CNAME records in advance
• •Schedule the cutover during low-traffic periods
• •Expect propagation delays of 5–30 mins

Catch issues before your customers do.

1. Assign ownership

• •Document all key user journeys (page views, purchases, sign-ups...) in your collaboration tool (e.g., Coda)
• •Assign ownership to each flow to speed up investigation and resolution

2. Automate testing

• •Use tools like Ghost Inspector to record core workflows and run automated tests on deploy and at regular intervals
• •Start with your most critical flows, then expand coverage to secondary ones

3. Monitor continuously

• •Use services like Oh Dear to monitor HTTP errors, page load times, SSL issues, cron jobs, and broken links
• •Set clear thresholds (e.g., 5×5XX errors in 5 minutes) to avoid alert fatigue
• •Send routine alerts to group chats (Slack, Teams); escalate major incidents to on-call developers via SMS or push

Incidents will happen. Prioritize fast detection and response over chasing perfection.

Over time, you'll reduce go-live windows and rely less on manual QA.

Here's what to explicitly confirm in your final pre-launch checklist:

Access & credentials

• •Are full site and database backups complete, verified, and accessible?
• •Are rollback credentials stored in a secure password manager (e.g., Dashlane, Bitwarden) and accessible to key team members?
• •Who has permission to trigger a rollback, and is this clearly documented?

Trigger thresholds

What constitutes a "no-go" or rollback event? Set clear thresholds such as:

• •Over 5% increase in critical error rates
• •Checkout failures or form submission errors
• •Load time spikes above 3s for key pages
• •Visual or content issues flagged by clients or QA post-deploy

Agree in advance who has final authority to declare a rollback and how quickly the decision must be made.

Right after launch, test any flow tied to:

• •Revenue (checkout, pricing tier, discount logic, upsells)
• •Onboarding (signup, login, password reset)
• •Lead capture (contact forms, newsletters, demo requests)

Depending on your traffic, these flows can break very silently and cost you money while you're celebrating.

Check whether the right tag fires, the form actually submits, and the right data is sent to your CRM.

Pro tip: a prewritten QA checklist for each core flow does wonders here.

After go-live:

• •Immediately re-crawl your site (Screaming Frog, Sitebulb) to catch broken internal links and unexpected 404s
• •Use redirect checkers (HTTPStatus.io) to validate 301s from old → new slugs

Watch out for:

• •Old hardcoded links still in templates or navigation
• •Missing redirects for campaign URLs or query strings
• •Canonical tags pointing to staging

Run these checks as soon as DNS switches to ensure search engines and users land where they should.

Once your new website is live, real-time performance and uptime tracking are critical for early detection of regressions or outages.

At Made Neat, we implement a multi-layered monitoring strategy to protect our clients and ensure high availability.

Here's what to do once your redesigned website is live:

Key metrics to monitor

• •LCP (Largest Contentful Paint): Aim for under 2.5s on both mobile and desktop.
• •CLS (Cumulative Layout Shift): Watch for layout instability from fonts, animations, or image dimensions.
• •INP (Interaction to Next Paint): Ensure interactive elements (forms, nav) respond within 200ms on real devices.
• •TTFB (Time to First Byte): Aim for under 0.8s. TTFB reflects network latency, connection setup, and server processing time.

These are monitored via tools such as GTmetrix, Google PageSpeed Insights, Google Search Console, and Cloudflare Analytics.

Uptime and incident detection

We use:

• •MonSpark and UptimeRobot to monitor global uptime, page response, and SSL status
• •Grafana dashboards (when appropriate) for VPS-level metrics like CPU/memory
• •Logify WP to track WordPress errors, plugin updates, login activity, and configuration changes offering early warnings on site instability

Bonus: Load and failover preparedness

We test under simulated traffic loads prior to launch, and where uptime is business-critical, we implement failover-ready hosting with automated snapshots and geo-distributed DNS options.

A solid pipeline helps you separate signal from noise and act quickly.

Example feedback / bug report setup via Marker.io:

1. Collect: add widget on your site (bug reports, feedback from real users).
2. Track: auto-create issues in your tool (Linear, Jira, GitHub, Notion).
3. Triage: add tags and assign to the right person.
4. Feedback loop: close the loop with users via email.

Also monitor feedback from:

• •Support tickets (tag with keywords in HelpScout/Zendesk)
• •Sales calls (log in CRM or shared doc)
• •Heatmap tools (rage clicks, dead clicks, unusual sessions)

Go to GSC → Index → Coverage and check for:

1. "Crawled – currently not indexed". Google visited, but didn't index. Often a quality or duplicate content signal.
2. "Discovered – currently not indexed". Your site is linking to it, but Google hasn't crawled it yet: check internal links and XML sitemap.
3. "Soft 404". Page loads, but looks empty or irrelevant to Google: often caused by empty templates or CMS edge cases.
4. "Blocked by robots.txt". Make sure you're not accidentally blocking key pages or collections post-launch.

A website is never done, maintenance and regular updates are just as important.

1. Set a monthly or quarterly maintenance routine to check security, speed, backups, and apply updates as soon as they’re available.
2. Make automatic backups regularly and try restoring from a backup now and then to be sure it works.
3. Install and run a security scanner; fix any issues it finds quickly.
4. Test your site speed with PageSpeed Insights or a similar tool and follow the advice to make things faster.
5. Clean up your content: remove unused stuff, fix broken links, and add alt text to all images.
6. Look at your stats (Google Analytics) every month, spot any problems or slowdowns, and think of what to improve next.
7. Keep a simple log each month (or ask your agency) of what’s been updated or fixed and what’s left to do.
8. Once a year, do a “checkup” of your site: either ask someone from outside or use a checklist to make sure security, accessibility, and SEO are all good.

Hold a 30–60 minute retrospective once the dust settles.

Start with these prompts:

• •What surprised us (good or bad)?
• •Where did we miss scope or underestimate time?
• •What bottlenecks slowed us down?
• •What worked well that we want to repeat?
• •Where did communication break down?
• •What internal tool or checklist would've helped?

Close the meeting with one clear improvement for next time, and assign an owner.

Then, market the outcome:

• •Add the project to your portfolio
• •Share the launch and learnings on LinkedIn
• •Write a short case study on the impact

Success isn't just about delivery, it's about learning, visibility, and building your reputation.

Document your learnings for future website redesign projects.