A website redesign has a way of feeling simple at the start and overwhelming halfway through. The strategic decisions get made up front, but most of the work happens in the messy middle: content audits, redirect maps, plugin reviews, design feedback rounds, QA across browsers, and the dozens of small decisions that determine whether the new site actually performs better than the old one.
This checklist organizes everything that needs to happen across a typical website redesign, from the planning phase before a vendor is selected to the optimization work in the months after launch. It’s built for businesses planning a strategic redesign in the $15,000–$75,000 range, though most of it applies to larger and smaller projects too.
Use it as a reference, a discussion guide with your team, or a way to evaluate whether a potential design partner has thought through the work as carefully as you have.
Phase 1: Before the redesign starts.
This is the planning work that happens before any design or development begins. Done well, it makes every later phase more efficient. Skipped or rushed, it’s where most redesign problems originate.
Define the business case for the redesign.
A redesign without a clear business reason almost always disappoints. Before anything else, get clear on what the new site needs to do that the current one does not, and document the answer in a way you can return to when scope debates come up later in the project.
- Document the specific business problems the current site is creating, with concrete examples wherever possible. Vague complaints like “it feels outdated” become real arguments to design around when paired with the actual moments where the site falls short.
- Identify the measurable outcomes the new site needs to deliver, including lead volume, conversion rate, search rankings, time on page, and any other metrics that connect to revenue. Without baseline numbers and target numbers, you cannot tell whether the redesign succeeded.
- List the audiences the new site needs to serve in priority order, and clarify what each audience needs to find quickly when they arrive on the site.
- Decide whether this is a refresh, a strategic redesign, or a full rebuild based on the actual gap between your current state and your desired state. Misjudging this is the most common source of project disappointment.
- Confirm internal alignment among decision-makers before going to vendors. Misalignment that surfaces during the project costs significantly more to resolve than misalignment caught upfront.
Audit your current website.
You cannot plan a redesign without understanding what you are redesigning. A proper audit covers content, technical health, SEO performance, and user behavior. The findings shape the scope, the budget, and almost every strategic decision that follows.
- Run a full crawl of the current site using a tool like Screaming Frog or Sitebulb to inventory every page, asset, and broken link. The crawl becomes the master reference for the migration plan
- Pull analytics data covering at least the last 12 months, focusing on your top-performing pages, your highest-converting paths, and any pages with unusually high exit rates that suggest a user experience problem.
- Pull Google Search Console data showing your current ranking keywords, click-through rates, and which pages are earning organic traffic worth preserving through the redesign.
- Identify which pages are earning their place on the site and need to carry forward, ideally with their existing URLs intact to preserve search authority.
- Identify which pages can be removed, consolidated into stronger pages, or significantly rewritten as part of the redesign. Pruning low-value content is one of the most underrated benefits of a rebuild.
- Document existing schema markup, structured data, and any custom integrations on the current site that will need to be rebuilt, migrated, or replaced.
- Note any technical debt that the redesign should address, including outdated plugins, slow load times, broken links, accessibility issues, and security warnings flagged by Google or hosting providers.
Set the scope and budget.
Scope and budget are easier to define than most teams expect, and the discipline of writing them down protects everyone involved. A clearly scoped redesign is faster to quote, faster to build, and far less likely to run into the awkward “we thought that was included” conversations that derail otherwise good projects.
- Define the project scope clearly in writing, including what is in scope and what is explicitly out of scope. Edge cases that seem obvious now will not seem obvious in week eight of the project.
- Establish a realistic budget range based on the type of redesign you actually need, not the type you wish would fit your current budget. A short blog post breaking down typical redesign costs by tier can help you calibrate this.
- Decide whether content creation is part of the project or whether you will handle it separately with internal staff or freelance writers. This is the single most common source of timeline slippage.
- Decide whether photography, video, and illustration are part of the project or whether you will handle those production costs outside the redesign budget. Custom imagery is often the difference between a generic site and a memorable one.
- Identify any custom functionality, third-party integrations, or content migrations that will affect both cost and timeline. The redesign budget needs to account for all of these, not just the design and development of standard pages.
- Build in a contingency of 10 to 20 percent for the scope changes that almost always surface once the project is underway. Treat the contingency as expected spend, not optional spend.
Choose the right partner.
The right partner depends as much on your project’s complexity as on the partner’s portfolio. A freelancer who’s perfect for a 10-page refresh may struggle with a strategic redesign that touches multiple integrations, and a mid-size agency that handles enterprise work may overcharge for what your project actually needs. Match the partner type to the project type, then evaluate fit within that tier.
- Decide between a freelancer, boutique studio, mid-size agency, or enterprise firm based on the complexity, scope, and budget of your project rather than the prestige of the partner.
- Request proposals from two to four vendors rather than eight to ten. More vendors slows the decision process without meaningfully improving the quality of the choice.
- Evaluate process as much as portfolio. A studio with a strong, repeatable process will deliver more reliable outcomes than one with beautiful work but no clear method behind it.
- Ask each vendor specifically how they handle SEO migration, redirect mapping, and search authority preservation. The answers will quickly separate the strategic teams from the design-only ones.
- Confirm who the day-to-day project lead will be, not just the salesperson who pitched the work. The person on calls in week eight is the person who actually determines your experience.
Phase 2: During discovery and strategy.
Most strategic redesigns include a discovery phase between contract signing and the first design work. This is where the foundational decisions get made that everything downstream depends on.
Run discovery workshops.
Discovery is where assumptions get tested and decisions get aligned. The best redesign teams treat workshops as structured conversations with specific outputs, not open-ended brainstorms. Done right, discovery surfaces conflicts early when they’re cheap to resolve, instead of late when they’re expensive.
- Schedule structured discovery sessions covering goals, audience, brand, competitors, and project realities. Each session should have a clear input, a clear output, and a clear decision that comes out of it
- Document what each stakeholder wants the redesign to accomplish. The list often surprises people when it surfaces priorities that were never explicitly discussed before.
- Resolve conflicts between stakeholder priorities before they become design feedback fights later in the project. Unresolved priority conflicts always show up eventually, usually at the worst time.
- Confirm primary and secondary audiences with specificity. “Business customers” is not a useful audience definition; “mid-market operations directors evaluating workflow software” is.
- Review competitor websites with the design team to align on positioning and visual direction. Knowing what you do not want is as useful as knowing what you do.
Build a new sitemap and information architecture.
The sitemap is the single most important strategic deliverable in a redesign. It defines how visitors find information, how search engines understand your site, and how every other decision downstream connects. Get this right and the rest of the project gets easier; get this wrong and every later decision compounds the problem.
- Map every existing URL to its new destination, including 301 redirects for any pages being removed or consolidated.
- Plan navigation structure based on user journeys and search intent, not on internal organizational charts or how the team thinks about the business.
- Decide on page hierarchy and how supporting content links to primary pages. Strong internal linking concentrates search authority on the pages that drive revenue.
- Identify content gaps the current site has and the new site should fill. New pages that target unmet search intent often perform better than redesigned versions of existing pages.
- Validate the proposed sitemap with stakeholders before design begins. Late-stage sitemap changes ripple through every design and development decision that came after.
Plan the content strategy.
Content is the part of a redesign most likely to fall behind schedule. Designs are easier to produce than the words and images they’re built around, and content delays are the most common reason redesigns slip past their planned launch date. Decide early who’s writing what, when it’s due, and what happens if it’s late.
- Decide what existing content carries forward unchanged, what gets rewritten or refreshed, and what content is genuinely new for the redesign.
- Assign content responsibility to specific people, whether that is an in-house writer, an agency copywriter, a freelance writer, or AI-assisted drafts with editorial review. Vague ownership is how content deadlines slip.
- Build a content production schedule that does not bottleneck design or development. Content needs to be ready when the page templates need it, not after.
- Plan for SEO-relevant content, including target keywords for each page, meta titles, meta descriptions, and internal linking opportunities.
- Plan for AEO-relevant content, including structured data, FAQ sections, and clear question-and-answer formats that AI search platforms can extract and cite.
Phase 3: During design and development.
Once the strategic foundation is set, the project moves into design and build. This is where most of the visible work happens, but also where small decisions can quietly compound into big problems if no one is tracking them.
Manage the design phase.
Design is the phase most people enjoy and the one most likely to expand beyond its scope. Clear feedback rules and decision-making boundaries protect the design team’s output and your timeline. The goal isn’t to limit input; it’s to channel input into useful direction.
- Approve wireframes before mockups begin. Wireframes lock in structure and content hierarchy; mockups should refine that structure visually, not redefine it.
- Limit feedback rounds to a defined number, typically two to three per stage, with all stakeholder input consolidated before each round.
- Consolidate feedback from all internal stakeholders before sending it to the design team. Conflicting or piecemeal feedback wastes time and confuses direction.
- Review designs at the device sizes your audience actually uses, not just on desktop. Most B2C and increasing amounts of B2B traffic happen on mobile.
- Verify the design system covers every page type the site needs, including blog posts, landing pages, case studies, and any utility pages that often get overlooked early in design.
Manage the development phase.
Development is where most issues become invisible until launch. The work is technical, the deliverables are harder to evaluate visually, and small problems can quietly compound for weeks. Good development teams build with QA in mind from day one, not as a final phase.
- Confirm the development team is using a staging environment for all development work, not building directly on the production site.
- Test core functionality such as forms, search, and integrations early in development rather than waiting until the final QA pass. Issues found early are dramatically cheaper to fix.
- Verify the site is built with accessibility standards in mind, targeting at minimum WCAG 2.1 AA conformance. Accessibility done at build time is significantly cheaper than accessibility retrofitted afterward.
- Review the page speed and performance plan before significant content is loaded into the site. Performance baselines set during development hold up better than performance fixes added after launch.
- Confirm the site is being built mobile-first, with desktop layouts adapted from the mobile foundation rather than the other way around.
Plan the technical foundations.
The infrastructure choices made during a redesign affect performance, security, and ongoing costs for years afterward. These are not decisions to defer to launch week. The right setup makes everything that follows easier; the wrong setup creates problems that surface long after the project team has moved on.
- Confirm the hosting environment, server configuration, and CDN setup well before launch. Hosting decisions made under launch-week pressure are rarely the right ones.
- Plan SSL certificate management and HTTPS-only enforcement across the entire site, including any subdomains.
- Document every third-party integration the site depends on, including CRM, marketing automation, analytics, and ad platforms, along with the credentials and access required for each.
- Plan the analytics setup carefully, including Google Analytics 4, Tag Manager, conversion tracking events, and any heatmap or session recording tools you intend to use post-launch.
- Plan ongoing site monitoring for uptime, performance, and security so issues can be caught proactively rather than reactively.
Prepare for SEO migration.
This is the single most underestimated part of a redesign. A poorly handled SEO migration can erase years of organic search authority overnight. Treat this as a non-negotiable project work stream and assign it explicit ownership rather than letting it default to whoever happens to think about it.
- Build a complete 301 redirect map covering every existing URL on the current site, with each one mapped to its appropriate destination on the new site.
- Verify schema markup is implemented on the new site at parity or better than the current one, including any rich result markup that drives current search visibility.
- Review meta titles and descriptions for every page on the new site, prioritizing the pages with the most existing search traffic and ranking value.
- Confirm the internal linking structure on the new site preserves authority for high-performing pages and does not unintentionally orphan content that previously had strong internal link signals.
- Plan a post-launch crawl error monitoring schedule so any redirect failures or coverage issues are caught and resolved within days rather than weeks.
- Submit an updated XML sitemap to Google Search Console immediately after launch to accelerate recrawling of the new site structure.
Phase 4: Pre-launch quality assurance.
The week before launch is where small mistakes become public mistakes. A structured QA pass catches issues before users do.
Test functionality across the site.
Every interactive element on the site is a potential point of failure, and the only reliable way to catch failures is to test them deliberately. Do not assume anything works just because it looks correct. The forms, integrations, and conversion paths are where real business outcomes happen, and those are exactly the things that need the most testing.
- Test every form submission on the site and confirm submissions are reaching the correct destination, whether that is your CRM, your email inbox, or another integrated system.
- Test all interactive elements including filters, search, calculators, modals, accordions, and any custom-built components.
- Test integrations with your CRM, email marketing platform, and any other third-party platforms that the site depends on for business operations.
- Test the eCommerce checkout flow end to end if applicable, including payment processing, shipping calculation, tax calculation, and order confirmation emails.
- Test login and account flows if applicable, including password resets, account creation, and any gated or member-only content.
Test across devices and browsers.
Browser developer tools are useful but not sufficient. Real devices behave differently, especially on mobile, and rendering quirks that are not visible in Chrome on a laptop can break the site for a meaningful portion of your audience. Cross-device testing is tedious and necessary in equal measure.
- Test on Chrome, Safari, Firefox, and Edge at a minimum. Older or less common browsers may also matter depending on your audience and analytics data.
- Test on actual iOS and Android mobile devices, not just browser developer tools simulating mobile views. Real devices reveal issues that simulators do not.
- Test on multiple screen sizes including small phones, large phones, tablets, laptops, and large desktop displays. Layouts that look fine at one size often break at another.
- Verify accessibility with screen readers and keyboard-only navigation, ideally including testing by people who actually use those tools rather than developers checking off a list.
Verify the technical foundations.
The technical setup decisions made earlier in the project need to be validated before launch, not assumed. A site can look complete and still be missing analytics tracking, have a misconfigured SSL certificate, or fail Core Web Vitals on the pages that matter most. Verify everything; trust nothing until it is confirmed.
- Run a full crawl of the staging site to identify any broken links, missing alt text, orphan pages, or other technical issues that need to be addressed before launch.
- Run page speed tests on the most important pages including the homepage, top service or product pages, and your most-trafficked blog posts.
- Verify Core Web Vitals scores are at or near the “Good” thresholds for Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.
- Confirm the SSL certificate is properly installed, HTTPS is enforced across the entire site, and there are no mixed content warnings in the browser.
- Verify analytics tracking is firing correctly on every page and that conversion events are recording in the analytics platform of record.
Prepare the launch plan.
Launch is a coordinated event, not just a button push. The team needs to know what is happening when, who is responsible for what, and what the contingency is if something breaks. A few hours of planning here prevents the stressful scramble that happens when something unexpected shows up at the worst possible moment.
- Choose a launch window that minimizes traffic disruption, typically not late on a Friday afternoon or first thing on a Monday morning.
- Plan DNS changes with appropriate TTL settings ahead of launch, allowing for fast rollback if something unexpected goes wrong after the site goes live.
- Prepare a rollback plan in case of critical post-launch issues, including who has the authority to call the rollback and what the trigger conditions are.
- Identify who is on-call during and immediately after launch, including the developer responsible for any quick technical fixes that may be needed.
- Notify internal stakeholders of the launch window and any expected brief downtime, so the support and sales teams are not blindsided by changes they need to know about.
Phase 5: Launch and the first 30 days.
The redesign goes live, but the work is not finished. The first month after launch is when the new site’s real performance becomes visible and when most issues that need quick attention surface.
Execute a clean launch.
A clean launch is methodical, not heroic. Every step has a purpose, and skipping steps to save time creates problems that take longer to fix than the steps would have taken to do. Work the plan, verify each step, and resist the temptation to declare victory too early.
- Deploy the new site during the planned launch window, following the launch checklist step by step rather than from memory.
- Verify DNS propagation is complete across major networks before considering the launch finished. Propagation can take several hours and is not always uniform across regions.
- Confirm all 301 redirects are firing correctly on the live site, especially redirects from high-traffic and high-ranking URLs that you cannot afford to break.
- Submit the new XML sitemap to Google Search Console as soon as the site is live to accelerate recrawling and reindexing of the new structure.
- Verify analytics tracking is recording sessions and conversions on the new live site, not just on staging where final tests were run.
- Test the most important forms and conversion paths on the live site, since some integrations behave differently in production than they did in staging.
Monitor closely for the first two weeks.
The first two weeks after launch are when issues are most likely to surface and easiest to fix. Search engines are recrawling the site, users are encountering it for the first time, and any gaps in the migration plan will start showing up in real data. Pay close attention during this window; it gets harder to spot problems once normal traffic patterns reassert themselves.
- Check Google Search Console daily for crawl errors, coverage issues, and any sudden changes in indexed page counts that might signal a migration problem.
- Monitor analytics for unusual drops in traffic, time on page, or conversion rate. Small fluctuations are normal post-launch; sharp drops on specific pages need investigation.
- Review heatmap or session recording tools to spot user friction points that did not exist on the old site, especially around forms, navigation, and key conversion paths.
- Track ranking changes for your most important search terms. Small fluctuations are expected during the migration; large drops sustained over more than a week need investigation.
- Address any 404 errors or broken links immediately as they surface in Search Console or analytics. Every day a 404 sits unfixed is a day of lost search authority.
Wrap up the project cleanly.
A project that ends without proper documentation creates problems that do not show up for months. Credentials get lost, decisions get forgotten, and the institutional knowledge that lived in the project team disappears when the team moves on. A clean handoff protects the investment you just made.
- Document all credentials, hosting access details, and ongoing service accounts in a place your team can find them six months from now.
- Confirm the development team has handed off ownership cleanly, including any source files, design files, and brand assets created during the project.
- Schedule a post-launch retrospective with the project team to capture learnings, both for your team’s future projects and for any ongoing work with the same partner.
- Plan the first round of post-launch optimizations based on early data from the new site rather than assumptions made during planning.
Phase 6: Ongoing optimization and maintenance.
A redesign is a starting point, not a finish line. Sites that do not evolve after launch lose ground to competitors that do. The work in the months after launch is what turns a redesign investment into compounding business value.
Establish a maintenance routine.
Maintenance is the work that keeps a redesign valuable. Without it, the new site degrades the same way the old one did, just on a slower curve. The good news is that maintenance is predictable and inexpensive compared to the redesign itself, and most of it can run on autopilot once the routines are established.
- Plugin and theme updates on a regular cadence, weekly or monthly depending on site complexity and the level of automated testing in place. Skipping updates is the most common path to security incidents.
- Security monitoring with automated alerts for vulnerabilities, unauthorized access attempts, or suspicious changes to site files.
- Off-site backups verified and tested for restoration on a regular schedule, since a backup that has never been tested is not really a backup.
- Uptime monitoring with alerts routed to the right person when issues occur, ideally before customers notice the site is down.
- Performance monitoring to catch slowdowns and Core Web Vitals regressions before they affect rankings or conversion rates.
Continue improving the site.
A launched site is a starting point for learning, not a finished product. The data that comes in over the first few months will surface things you could not have known during the project, including pages that underperform, content gaps that visitors expose through their behavior, and conversion paths that need refinement. The redesign teams that win are the ones that keep working after launch.
- Review analytics on a regular monthly cadence to identify pages that are over-performing or under-performing relative to expectations, and use those findings to prioritize the next round of optimization work.
- Test changes to high-traffic pages using A/B testing or staged rollouts rather than rolling out untested changes to the entire audience at once.
- Update content as your business, services, or positioning evolves so the site does not drift back toward the same outdated state that prompted the redesign.
- Add new content on a sustained schedule, including blog posts, case studies, and resource pages that target search opportunities and support the broader business.
- Track Core Web Vitals scores on a regular cadence and address any performance regressions quickly before they affect rankings.
Build for what comes next.
Most websites get redesigned every three to five years, and the work between redesigns is what determines how big the next one needs to be. Sites that evolve continuously avoid the major rebuild cycles that come from years of accumulated stagnation. Plan small improvements consistently, and the next redesign becomes a refresh instead of a rescue.
- Identify the next round of improvements based on early performance data, including any new pages, additional functionality, or ongoing CRO work that the new site’s data has surfaced as valuable.
- Plan annual content audits to retire stale content, refresh evergreen pages, and identify gaps that have emerged as your business and audience have evolved.
- Reassess the redesign’s performance against the original business goals after six to twelve months of post-launch data, and use the findings to inform both ongoing optimization and the next major project.
Planning a redesign of your own?
This checklist works whether you are managing the redesign internally, hiring a freelancer, or working with a studio or agency. If you are evaluating partners and want to see how we approach the work, our website redesign services page walks through our process in detail. Or, if you want a quick budget estimate before going further, our cost calculator gives you a ballpark in about five minutes.
Related Reading
Website Redesign Cost in 2026, a complete breakdown of what to budget across project tiers, what drives the price up or down, and how to know if your budget is realistic.
Get a personalized estimate for your website project in minutes.
Embark on your Expedition
Ready to explore the possibilities? Let's talk.
Every great idea starts with a conversation — and we want to have it. Whether you’re looking to build a brand, design a website, or craft a new digital experience, tell us a little more about your project and we’d be happy to see if our team is the right fit.
