Website Redesign Checklist That Protects Outcomes

You will find that the majority of published website redesign checklists read like a creative brief: put in a new layout, give the hero some life, modernize the type and launch. It is that sort of framing which drives up the cost of a redesign. And for what? The 2026 WebAIM Million report has the numbers to back up why you should be cautious. They found WCAG 2 failures on 95.9 per cent of top home pages this year, an increase from last year, with some 56 accessibility errors on average and a 22.5% rise in element counts. Then there is the matter of traffic; SEMrush migration research, much quoted by agencies, puts the odds at 60% for a site to see its organic traffic suffer post-redesign. Hardly ever is it the visual layer that does the damage. It is the migration, the lack of governance and the sheer complexity.

A checklist worth having is one that serves as an instrument of risk and ownership. It should make plain what is non-negotiable for the move, who is responsible for the call, and what you are measuring on either side of a launch. It draws a line between the parts of the site that must be reliably boring and where you can have a go at trend experimentation. We have put together this guide for product owners and marketing leads who have to oversee a redesign without having to be the technical lead.

Decide Whether You Actually Need a Redesign

In a way, the most economical redesign is the one you never begin. So before you sign off on a rebuild, put some distance between the symptom and the cause. Your pages are sluggish, sales is reluctant to link to certain URLs, the CMS has turned minor edits into a queue of tickets and your lead quality has gone to pot. These are genuine issues but they do not all demand the same remedy. You might need a full redesign, or perhaps just a facelift on the current platform, or a more targeted update.

Do the math. Take the 50 pages that bring in the most conversions and traffic and see what is already working. If the trouble is confined to a checkout flow and five templates, you have a fix-it job, not a project to be rebuilt. Only if the platform is actively impeding the team’s ability to scale or integrate does the argument for a complete overhaul hold water. For a different take on when to optimize and when to rebuild, have a look at Refact’s view on the website redesign process.

Put three or five KPIs in place before any design work commences. We are talking non-visual ones: task completion on your main conversion path, Core Web Vitals (LCP under 2.5s, CLS near zero), WCAG 2.2 AA conformance and, if your site is built for it, a support deflection metric. You should also want to know your organic traffic retention at 30 and 90 days out. If you cannot put the primary goal and audience into plain English, you are not ready for design.

Audit Before You Rebuild

There is more to your existing site than the design would have you believe. Some of those URLs are ranking, pulling in backlinks and answering buyers’ questions on a monthly basis. Rebuild without knowing which ones and you will quietly undo all that hard work.

We recommend a four-part audit:

• URL and content inventory. Crawl the live site and export everything, utility and legal pages included. Make a call on each: keep, merge, update or kill. Any page with no strategic value or backlinks and zero traffic should be killed and redirected to the next best thing.
• Search and backlink equity. Look at the queries your top landing pages rank for and the inbound links. Keep those URLs intact. If you have to change them, put a 301 in place to the closest match.
• Accessibility baseline. An automated scan will show you your heading order, alt text and ARIA misuse. WebAIM’s 2026 figures show 83.9% of home pages have low-contrast text, usually down to a palette with too many gradients. Do not let those failures into the new build.
• Complexity baseline. Check your JavaScript weight and third-party scripts. Pages with ARIA had an average of 59.1 errors compared to 42 without it; a reminder that piling on code is more often a risk than an aid to accessibility.

Make sure every page and every decision has an owner. Things do not go wrong because the team has amnesia about a page’s existence, but because everyone was of the mind that someone else was on it.

Protect SEO Like It Pays the Bills, Because It Does

If there is one item on the checklist with the highest leverage, it is migration discipline. Traffic will collapse at launch over restructured navigation, lost metadata and URL changes with no redirect. Most of these are predictable months ahead of time and can be sidestepped with a single document: a redirect map.

The SEO workstream needs to have the following in hand before cutover:

• A complete inventory of the current site’s URLs, variants and all.
• A 301 redirect map for anything that is being removed, merged or changed.
• Transfer of all metadata – titles, canonicals, OpenGraph, structured data – for the pages you are keeping.
• An indexing plan for staging that does not leak, along with a new XML sitemap and verified robots.txt.
• Internal link updates so crawlers and readers are not sent to old URLs.

Our guides on redesigning a website without losing SEO and SEO and website redesign go into this in more detail for projects of this shape. Should you be changing hosting or platform as well, the site pre-migration checklist will cover the operational prep prior to any DNS work. We saw the need for it when we put a new platform behind Teton Gravity Research; their legacy CMS was barely holding on and we had ten thousand articles to get out of it. You would not say the new design was the hard part. The real challenge lay in making the move while safeguarding 20 years of editorial equity and doing away with features the business had no appetite to support any longer. Most checklists don’t account for that kind of work.

Design the User Experience Before the User Interface

In too many projects, you get polished mockups before you are ready for them. Stakeholders will fixate on the visuals and the team will be off chasing type and color, all while structural issues are being put in place. You have to keep the UX and UI as distinct decisions.

UX is about the practicalities: where does a first time visitor end up? How do they go from interested to taking action? What pages have the trust signals and which ones need to bridge the gap to a sale or a demo? Wireframes are the most economical way to have an argument over flow. If it doesn’t hold up in black and white, no amount of color is going to save it.

Then there is the matter of conversion. A visual refresh can only do so much compared to above-the-fold clarity. The consensus among designers and conversion specialists in 2025-26 has been a return to the hero formula: tell us who you help, make a single promise on the outcome and back it with some proof – a number, a product shot, a well known customer. One primary call to action with a good verb and a headline of ten words or less. Pages that don’t convert tend to miss at least one of those marks.

The UI is there to support the decision path, not to get in its way. Sure, brand colors and typography count, but check your contrast in hover and disabled states, not just the default. As for the trendy stuff – WebGL, warm imperfect branding, gradient palettes – treat those as optional in low risk spots like empty states. Keep the core flows unadorned and usable.

Control Complexity and Performance From Day One

A redesign has a way of putting on weight. You add a chat widget, a consent manager, a new analytics package, a heatmap script… WebAIM has pointed out that pages with popular ad systems are rife with accessibility errors. And performance reports will tell you the new site is slower than the old one.

Before you let development begin, put your complexity and performance budgets in writing:

• Cap the JavaScript per template.
• Limit third-party scripts and put down in writing why each is necessary.
• On mobile, LCP should be under 2.5 seconds with CLS near zero on typical pages.
• Set a baseline for element count given that complexity is what drives accessibility regressions.
• Lazy-load your video, images and non-critical embeds as a rule.

With over 60% of traffic coming in on mobile, you are testing against a mid-range phone on a throttled link, not the designer’s laptop. See our note on website redesign cost for how that kind of discipline affects the price and scope.

Make Accessibility a Build Requirement, Not a Final Check

The 2026 figures from WebAIM are sobering. Top home pages are seeing more WCAG failures, not fewer. They even put the blame in part on AI-assisted coding. You can’t just bolt on accessibility when a redesign is done; it has to be part of the build.

We follow three rules:

• Start with semantic HTML. Use ARIA only as a last resort if there is no native element for the job.
• Put automated checks in the CI. Let the build fail if Lighthouse or axe finds a regression.
• Do some manual spot checking before you launch. Verify contrast and run a screen reader over the key templates.

If you are using AI in the build, set some ground rules. It is fine for research or drafts, but any production code for critical components or ARIA patterns should be vetted by someone who knows the standard. Deloitte says only one in five companies has proper governance for autonomous AI in 2026. This is as good a time as any to put yours on paper.

Manage Development and QA Like Operations, Not a Sprint

Everything seems to be going to plan until you send out the first preview link. Then the founder has three gripes with the homepage, sales is missing a field on the demo form, marketing sees some old copy on an important page and you are left wondering who is responsible for the fix and if it holds up the launch. QA requires structure, not just effort.

Have a staging environment with named owners for content, integrations, approvals and the like. Don’t open the floor for review in one go. Run it in rounds: layout and flow first, then content in context, then forms, search and admin workflows in the third.

Every round needs a deadline and an owner to sort out what gets fixed and what can wait, as well as a success check to clear the way to the next step. For teams working with preview deployments we have found tools like those for client feedback on Vercel to be much neater than wading through annotated screenshots in an email.

You need to put some buffer in your plan for the work that invariably shows up late. Approval workflows have a way of breaking, form notifications end up in the wrong inbox, mobile spacing will not cooperate on one template or another and editors will be at a loss to find fields in the CMS. The rule of thumb among practitioners is to allow 20 to 30% per phase, but the discipline you bring to it is what counts. Make sure you treat that buffer as time you own with specific categories: browser checks, stakeholder revisions, content QA, accessibility and regression testing. Leave it unowned and it will dissolve into general delay; you will launch without any record of what was actually put through its paces.

Set Up Analytics Before Launch, Not After

Redesigning without proper tracking is just guesswork dressed up in better typography. Put the analytics stack to the test in staging on the new site, do not take for granted that it has carried over.

Get these things confirmed before you go live:

• That GA4 and tag management are in place and firing on the new templates.
• Search Console is verified on the new property and the sitemap is ready to hand in.
• Your key conversion events are all there: primary CTA clicks, signups, checkouts, downloads, demo bookings and form submissions.
• You have not lost attribution or UTM parameters in a redirect.
• You have an honest baseline of the old site’s performance saved for later comparison.

When session counts or form volume shift after launch you have to know if it is the page, the consent banner, the traffic mix or the tracking. You can only get that answer if your measurement was sound from day one.

Run Launch Day From a Written Script

There is no drama on launch day, and if there is, the team is likely winging it. Have a runbook, a step-by-step script with an order of operations and a name attached to every task.

Task	Owner	Why it matters
Final content freeze	Project lead	Prevents last-minute changes that bypass QA
Backup confirmation	Developer	Defines the rollback point
Redirect activation check	SEO or dev lead	Confirms the 301 map is live and resolving
Sitemap submission	SEO or marketing lead	Speeds reindexing of the new structure
Analytics validation	Marketing or product lead	Confirms measurement is intact from minute one
Form and CTA spot check	QA lead	Catches the failure modes that cost real revenue
Stakeholder communication	PM or founder	Keeps sales, support, and execs informed

We prefer a phased approach to the big-bang switch. A section-by-section rollout keeps the surface area you have to monitor down and gives you a credible way to roll back if a template throws a fit. There is a consensus in web development for incremental release for that very reason. It is far easier to put right a redesign that comes out in three controlled pieces than one that ships in a single motion.

Monitor for Ninety Days, Then Keep Going

The site going live does not mean the redesign is done, it just means it is visible. The first month is about finding regressions – indexing errors, broken redirects, forms that fail, top pages with a change in traffic. The following sixty days let you separate the real impact from the noise.

Our monitoring rhythm is fairly practical:

• For the first week we do daily checks on anything from Search Console errors and redirects to a sudden drop in traffic on a page.
• Then weekly for the first ninety days on Core Web Vitals for representative templates, conversion rates on the main path and rankings for priority queries.
• Monthly audits once you are past that for content quality and performance budgets, ticketing any regressions instead of just making a note of them.

It is hard not to want to start over in week three because a chart wobbled, but most post-launch dips will recover as users and crawlers get used to things. Stick to the baseline and look for sustained directional change.

Then there is the matter of post-launch decay, which most checklists overlook. A PDF style guide is not enforcement and a documented design system is not governance. The teams whose work stands up after a year are the ones with a change-control process for new patterns who run lint and visual regression in CI and put design tokens in code. When we did the SingularityHub publishing platform, as much as we wanted a new look, the aim was editorial control without having to write for it. That is what will determine if the site is still recognisable in two years.

The Founder’s Quick Reference

Phase	Key decision	Primary owner	What success looks like
Strategy	Goals, audience, non-visual KPIs	Founder, strategist	The project ties to measurable outcomes
Audit	Keep, update, merge, or kill each page	Marketing or SEO lead	No valuable URL gets lost in the move
UX and UI	Structure approved before visuals	Designer, founder	Above-the-fold clarity on key templates
Technical planning	Platform, integrations, redirect map	Technical lead	Launch and post-launch risk are bounded
Accessibility and performance	Budgets and CI checks	Engineering lead	The new site is not worse than the old one
Development and QA	Staged review with deadlines	PM, QA lead	Defects are caught and owned before launch
Analytics	Tracking validated in staging	Marketing or analytics owner	Real measurement starts on day one
Launch	Runbook with named owners	PM, tech lead	A boring, recoverable cutover
Post-launch	Ninety-day active monitoring	Founder, partner team	Regressions caught early, gains compounded

Where This Leaves You

A checklist will not make a vague project any less so, it will only show you. Some teams treat it like a creative brief and wind up bickering over headers while their traffic goes. Others use it as an instrument of governance and operations; they tend to launch quietly, keep their search equity and see the metrics they set out to improve.

If you are yet to decide what should change, what should be left alone and how to stage the work, Refact’s product discovery process is designed to settle those early decisions before they become costly to undo in development. And if a platform move is in the offing, our website migration service will handle the operational side of the cutover.