Preparing for a website Redesign: The exact Steps to Take Before Design Begins

The decision is made. Budget is tentatively approved, leadership wants a cleaner, higher converting site, and someone has already said “let’s get some design concepts.” This is exactly the moment where most teams quietly set their website redesign up to fail.

When businesses skip structured website redesign preparation and jump straight into visuals, they typically get misaligned expectations, scope creep, and traffic drops bundled into one project. Many teams launch a better looking site that actually performs worse, with a large share of redesigns missing their goals and even cutting into revenue after launch instead of lifting it.

If you are a CEO, CFO, founder, or operator in a business, the risk is not cosmetic. A poorly prepared redesign can break lead flows, damage organic search, and create support load your teams were not staffed to absorb. Fixing issues late in the lifecycle regularly costs multiples more than addressing them in discovery, which is why mature teams treat the pre design phase as the real control point for cost and risk, not the build.

This guide focuses on what happens after the decision is made but before a single wireframe exists. It walks through a practical, operator level website redesign preparation process that secures your current site, audits reality, aligns stakeholders, captures user insight, locks in technical and content requirements, and mitigates risk before design work starts.

By the end, you will have a concrete pre redesign checklist so your redesign is not just a nicer skin, but a controlled, de risked project that can actually move revenue, pipeline, and customer experience in the right direction.

Step 1: Secure Your Current Website (Backups, Data, Access)

The first operational task in website redesign preparation is simple: protect what you already have. Before anyone touches layouts, plugins, or templates, you need a complete, restorable snapshot of the current site and a clear view of the data and access that sit behind it.

1.1 Full Site Backup

Treat your current site like a production database migration, not a cosmetic change. You are about to modify the system that handles lead capture, sales, and customer information, so you need a full backup that can be restored without drama if a deployment, plugin change, or hosting move goes wrong.

A proper backup for a modern site typically includes:

• Application files such as themes, plugins, custom code, and configuration
• Static assets including images, documents, downloads, fonts, and scripts
• The full database for content, product data, users, and form entries
• Key environment details like PHP version, database version, and important server settings

Treat this as a hard gate. No work starts until there is a verified, recent full site snapshot and database export created just before major changes begin.

1.2 Critical Business Data Exports

A file backup is not the same as a business backup. If your redesign or migration corrupts or drops live transactional data, you are not just fixing a site, you are reconstructing your pipeline and customer history.

Before design or development work starts, export and store:

• CRM leads and contact records generated by site forms
• Recent orders, invoices, and transaction logs
• Product catalog data that syncs with other systems
• Email subscriber lists and preferences
• Any user generated content that matters to the business, such as reviews or account data

Store these exports in human readable formats, not only system level backups, so you can recover or audit specific data if needed.

1.3 Access Inventory And Permission Cleanup

The third part of securing your current website is access control. Many organizations discover, midway through a redesign, that no one can find the DNS login or that the primary analytics account is tied to an ex employee.

Build a single, secure access inventory that includes:

• Hosting control panel
• Domain registrar and DNS
• CMS admin accounts and roles
• Database and SFTP or SSH
• Analytics, tag manager, marketing automation, CRM, and related tools

At the same time, clean up permissions. Remove accounts that should not exist, reduce shared logins, and move anything business critical into a managed password vault with proper ownership. A clear inventory of DNS, analytics, and admin credentials prevents last minute scrambles when your agency or internal team needs access.

Once the current state is backed up, your critical data is safe, and access is under control, you can move into diagnostic work without worrying that a single bad deployment will put the business in the dark.

Step 2: Conduct A Complete Website Audit

With the site secured, the next move in website redesign preparation is diagnosis. Before you fund new layouts or features, you need a clear picture of how the current site behaves in the wild.

A useful audit for a redesign covers four areas: performance, analytics, SEO, and content. Together, they give you a baseline you can use to define requirements and avoid breaking what already works.

2.1 Performance And UX Baseline

Start with how the site actually feels to use. Slow pages and poor mobile experiences are often the real reason leadership wants a redesign, so measure those issues explicitly.

At minimum, capture:

• Load time for key templates such as homepage, product pages, and landing pages
• Mobile responsiveness problems like layout breaks and awkward forms
• Recurring errors such as 404s, broken images, or failed scripts

Run structured tests, record the numbers in a short table, and prioritize the worst offenders. This performance baseline becomes one of your success measures post launch.

2.2 Analytics And User Behavior Audit

Next, look at how real users move through the site. Pull a meaningful window of analytics data and focus on patterns that actually change how you will design and prioritize.

Key questions:

• Which pages bring in most traffic, and from which channels
• Which pages act as primary entry points for organic, paid, and email
• Where users drop out of core funnels such as quote requests, demos, or checkout
• How mobile behavior differs from desktop in those flows

A small, focused set of behavioral and conversion reports during a redesign is more useful than a large analytics dump. The outcome here is a shortlist of high impact pages and broken journeys that the new site must handle carefully.

2.3 SEO And Visibility Audit

Once you know how users behave, check how they are finding you. An SEO audit before a redesign is your insurance against losing organic visibility.

Collect:

• All current URLs, grouped by content type
• A list of top organic landing pages and their primary keywords
• Basic ranking data for critical terms
• A view of your backlink profile and the pages carrying those links

Scan for technical issues like broken internal links, duplicate content, and confusing canonical setups. The goal is to identify URLs and structures that are SEO assets and must be protected. Many traffic drops after launch trace back to simple issues like missing redirects or deleted high value pages, which this audit is meant to surface early.

2.4 Content Inventory And ROT Review

Finally, you need to know what you actually have on the site. Most teams underestimate the volume and inconsistency of their content until they try to migrate it.

Build a content inventory listing:

• Each page and key asset with URL and type
• Last updated date, owner, and primary purpose
• Status tags like keep, improve, or retire

Apply a ROT lens to find content that is redundant, outdated, or trivial. Redundant items can be merged, outdated content can be rewritten or archived, and trivial content can often be removed, reducing clutter and migration cost.

This content view feeds directly into your sitemap, copywriting workload, and SEO mapping. Without it, you risk dragging legacy clutter into a new interface instead of fixing the underlying content issues.

Step 3: Stakeholder Alignment And Business Goal Setting

Once the audits are complete, the next move in website redesign preparation is alignment. If stakeholders do not agree on what the new site is supposed to achieve, the project turns into a quiet political tug of war.

This step should produce a clear owner group, a short list of agreed business goals, and a defined scoreboard for success.

3.1 Internal Team Alignment

Map everyone who has a real stake in the site: leadership, marketing, sales, customer success, product, IT, finance. For each group, capture what the site needs to do for them and what they will commit to for the project to succeed.

Structured prompts help:

• What is broken or painful about the current site
• What cannot be lost in the redesign
• Which outcomes would make the project a success for your team

Normalize the language into concise problem statements. Then define a core decision group with real authority and a review cadence. Strong redesign processes treat stakeholder engagement as a primary phase in the project plan, not an occasional check in.

3.2 Goal Definition Workshop

Convert expectations into a small set of concrete business goals. Avoid vague language like “modernize the brand” or “improve UX”.

Focus on:

• Impact on revenue, pipeline, and retention
• How the site supports sales, marketing, and customer success
• Which markets, products, or segments need more visibility

Turn these into measurable goals, such as increasing qualified demo requests, reducing support tickets from missing information, or shifting more initial education to the site. Limit yourself to a few primary goals so they can actually guide trade offs.

3.3 Success Metrics And Baselines

Goals need a scoreboard. Before you move on, define how you will measure each goal and what the baseline is today.

For each objective, define:

• A small set of KPIs
• Current baseline numbers from your audits
• A realistic target range and time frame

Write this in plain language so anyone can understand what improvement looks like. Teams that skip this often end up with launches that feel successful while key numbers stagnate or decline, a pattern that shows up repeatedly when redesigns are reviewed months later.

By the end of this step, you should have a compact alignment pack: stakeholder map, clear owners, three to five business goals, and a KPI set with baselines. That becomes the control system for the rest of the project.

Step 4: User Research And Customer Feedback Collection

Website redesign preparation is not just an internal exercise. If you only rely on stakeholder opinions and analytics, you get a clean deck and a half truth. The missing half lives in your customers’ heads.

This step turns vague assumptions like “users are confused” into specific, observed problems you can design against.

4.1 Customer Surveys And Interviews

Start with lightweight surveys aimed at people who recently interacted with the site. Ask what they came to do, whether they completed it, what slowed them down, and what was missing.

Use on site surveys at key points and follow up with recent customers or trial signups. You are looking for repeated patterns in language, not huge sample sizes. When multiple users describe the same friction on a page, it becomes a redesign priority.

From this pool, recruit a small group for short interviews. Have them walk through a recent task on the site while you watch where they hesitate or switch channels. Practical redesign checklists treat this kind of qualitative input as core discovery because it reveals issues analytics alone do not show.

Summarize findings as problem statements tied to specific flows, not generic complaints.

4.2 Behavioral Observation And UX Tools

Pair what people say with what they actually do. Use session recordings, click maps, and scroll maps to see real behavior.

Look for:

• Repeated clicks on non interactive elements
• Long pauses on simple form fields
• Important content or CTAs placed where most users never reach

Overlay this with your funnel and performance data. If a high value page has strong traffic but weak engagement and recordings show confusion around one module, that becomes a design requirement. Some project plans explicitly call out heatmap and behavior tools as inputs to redesign requirements for exactly this reason.

4.3 Support Tickets And Frontline Insight

Your support, sales, and account teams already see where the site fails. Mine recent tickets, chats, and sales notes for anything tied to the website: missing information, confusing forms, login issues, or tasks people could not complete online.

Group them by theme and map them to specific URLs or flows. Validate the patterns with frontline staff and ask which issues are most frequent, which are most costly, and which are most frustrating.

By the end of this step, you should have a concise, evidence based list of user problems in their own language. That list is more valuable to your redesign than any moodboard and tells you what to fix, what to protect, and what actually matters to users.

Step 5: Competitive And Market Benchmarking

Once you understand your own site and your users, you need to understand the environment you operate in. A redesign that ignores competitors and wider UX standards often launches behind from day one.

This step is about focused, business grade benchmarking so you know what you must match and where you can pull ahead.

5.1 Direct Competitor Teardown

Start with a shortlist of five to seven real competitors your buyers actually compare you to.

Review:

• Positioning and messaging on key pages
• Structure of navigation and core flows to pricing, demos, and support
• Conversion surfaces such as forms, CTAs, and contact paths

Document strengths, weaknesses, patterns worth matching, and gaps you can exploit. The goal is to understand the minimum expectations your users have, not to copy design. Many project plans treat structured competitor reviews as core discovery because they surface table stakes and differentiation opportunities in one pass.

5.2 Benchmarking Outside Your Category

Your users are also trained by large consumer and SaaS sites. Pick a handful known for clear flows and strong self service.

Look at how they handle onboarding, navigation, search, filters, and help content, then translate what you see into principles rather than aesthetics. You want patterns you can adapt to your context, not a visual clone of someone else’s site.

5.3 Gap Analysis And Strategic Positioning

Combine your internal audits, competitor teardown notes, and external benchmarks into a gap analysis.

Create a simple table of dimensions like performance, clarity of offer, proof, self service support, and buying friction. Compare your current site, competitor average, and your desired future state, then highlight where you lag, where you lead, and where there is open space.

Many redesign failures come from treating design as a taste exercise instead of a positioning tool. A structured gap analysis turns this into a strategic exercise that links user problems with market context and business goals.

By the end of this step, you should know what needs to be at least as good as everyone else, where you will be intentionally different, and which choices will actually matter in your category.

Step 6: Technical Requirements Documentation

At this point, you know what users struggle with, how the current site performs, and where competitors stand. Now you need a technical blueprint.

This is where you define what the new site must run on, what it must do, and what constraints it must respect.

6.1 Platform And Stack Decisions

Decide whether to keep your current CMS and hosting stack or move. If your team struggles to publish basic content or planned features are already pushing limits, staying put just to save effort usually backfires.

Evaluate:

• How easily non technical staff can publish and update
• Whether content models and workflows support where you are going
• Whether the platform can handle expected traffic and security needs

Then look at hosting and infrastructure. If performance and uptime showed up as issues, you may need better resources, a different architecture, or a modern deployment flow with staging, automated backups, and rollbacks. Map every external system that touches the site and define what each integration needs to do.

6.2 Feature Requirements And Priorities

With the stack in mind, define what the site needs to do at launch.

Group features into:

• Core features that the business cannot function without
• Supporting features that improve UX and conversion
• Admin capabilities that keep your team effective after launch

Describe behavior in concrete terms. “Better search” is not enough; specify what content is indexed, how filtering works, and performance expectations. Practical website redesign roadmaps push teams from wish lists to implementation ready descriptions.

Then cut ruthlessly. Mark what must be in version one and what can move to later phases.

6.3 Constraints, Risk, And Future Proofing

Technical work operates inside constraints. Spell out:

• Budget ranges with a realistic contingency
• Hard dates driven by events or launches
• Internal capacity to own and maintain the site

If your team cannot own a complex stack, simplicity becomes a requirement. For regulated sectors, document compliance expectations so they are first order, not last minute additions.

Finally, connect the plan to future growth in traffic, content, and product complexity. Redesigns that ignore capacity tend to repeat themselves when the new build hits the same limits as the old one.

By the end of this step, you should have a technical requirements document that developers can estimate against and finance leaders can understand.

Step 7: Content Strategy And Architecture Planning

With goals, data, and technical requirements set, the next step is deciding what goes where and why. This is where the site becomes a structured system rather than a pile of pages.

You are designing navigation, content, and visual constraints together.

7.1 Site Architecture Built From Tasks, Not Departments

Start from user tasks and business goals, not internal org charts. Your sitemap should reflect how buyers think.

Use your content inventory to group pages into journeys like learning, evaluation, purchase, and support. Run a simple card sort with internal and external participants, then draft navigation that lets key personas complete their main tasks with minimal steps. A basic tree test or card sorting exercise can reveal confusing labels before you invest in mockups.

7.2 Content Strategy And Page Level Intent

Define what each key page is for.

For each major template, capture:

• Primary intent
• Primary audience segment
• Key questions that must be answered
• Supporting assets such as case studies, FAQs, or comparison tables

Map target keywords into this framework so SEO supports real intent rather than forcing phrases into random places. A focused content plan built before design helps avoid the late realization that half the copy is missing.

Assign ownership and deadlines for content so it can move in parallel with design and development.

7.3 Visual Direction, Brand Constraints, And Accessibility

Set boundaries for how the site should look and behave without dictating pixels.

Clarify:

• Which brand elements are fixed
• What needs to evolve in imagery and style
• How strict the design system should be for future landing pages

Document a few principles: clarity over decoration, reduced cognitive load on key pages, and predictable interactions. Call out accessibility expectations early so they are baked into design rather than bolted on at the end.

By the end of this step, you should have a working sitemap, a content map with intent and ownership, and a visual brief designers can execute against.

Step 8: Vendor Selection Prep (If Hiring An Agency)

If you plan to work with an agency or external team, this is where many projects go sideways. Vague scopes and subjective selection criteria create cost overruns and misaligned expectations.

You want a clear scope, a disciplined shortlist, and a scoring framework.

8.1 Project Scope And RFP Inputs

Translate everything you have so far into a concise project scope.

Include:

• Objectives, goals, and KPIs
• Sitemap and content plan with estimated page counts
• Technical stack decisions and integrations
• Feature priorities for version one
• Budget, timing, and compliance constraints

If you turn this into an RFP, be explicit about deliverables, templates, migrations, redirects, QA cycles, analytics setup, and launch support. Strong RFP templates emphasize clarity on scope, criteria, and deadlines for exactly this reason.

8.2 Vendor Research And Shortlist

Build a shortlist instead of sending the scope to everyone.

Filter for:

• Experience on your target stack or in similar ecosystems
• Case studies with measurable results
• References that confirm they hit deadlines and handle change well

Keep the list tight so your team is not buried in proposals. Pay attention to how vendors question your preparation work; strong partners probe requirements instead of pitching generic processes.

8.3 Evaluation Framework And Decision Rules

Define evaluation criteria before proposals arrive.

Create a scoring matrix that weighs:

• Fit with goals and proposed approach
• Evidence of solving similar problems
• Clarity of project plan and communication
• Budget fit and commercial terms
• Post launch support and ownership of code and assets

Have stakeholders score independently, then review and stress test the top option with questions about risk and change control. This keeps the decision grounded instead of hinging on the best sales pitch.

Step 9: Risk Mitigation Plan Before Design Begins

Up to now, the focus has been on designing a better site. This step is about making sure the project does not quietly damage traffic, revenue, or credibility when you launch.

You are protecting search visibility, day to day operations, and your delivery timeline.

9.1 SEO Protection And Redirect Planning

Treat your current URL structure as a set of assets. Your SEO audit should already highlight URLs that drive organic traffic, carry backlinks, or anchor key terms.

Create a redirect map listing every URL that will change and its new target. For merged or retired content, send users to the closest matching intent, not just the homepage. Plan a crawl of the staging site to catch broken links, redirect chains, and accidental noindex flags. Many teams only learn this discipline after a sharp traffic drop post launch, when simple redirect gaps have wiped out years of equity.

Decide how you will monitor impact with dashboards for organic sessions, rankings, and 404s, and have someone review anomalies daily for the first period after launch.

9.2 Business Continuity During Cutover

Protect the flows that keep the business running: lead forms, pricing requests, logins, payments.

Identify critical journeys and define acceptable risk for each during cutover. Often this means scheduling a short maintenance window during low traffic hours with clear messaging, rather than silently breaking interactions.

Prepare:

• A rollback plan describing exactly how you would revert if needed
• An issue intake process for internal teams
• Short scripts so support and sales respond consistently to reported issues

Confirm all associated integrations are working in the new environment using real data, not just sample submissions.

9.3 Timeline Contingencies And Failure Modes

Accept that not everything will go to plan and build that into schedule and budget.

Identify the critical path, usually content, complex development, and integrations, and add explicit buffer. Define a minimum viable launch scope that still meets core goals and treat the rest as phaseable.

Include a contingency line in the budget for unknown but necessary work. We recommend a defined percentage because surprises are common in complex redesigns.

Document likely failure modes and assign owners and response plans so risks are managed deliberately rather than reactively.

Step 10: Pre Design Documentation Package

The last step in website redesign preparation is packaging everything into one coherent playbook. At this point you are not inventing anything new; you are consolidating what you have.

Handled properly, this becomes the single source of truth for design, build, QA, and launch.

10.1 Complete Requirements And Strategy Document

Assemble a primary document that pulls the story together for anyone joining the project.

Include:

• An executive summary of why the redesign is happening and what success looks like
• Goals and KPIs with baselines
• Key insights from audits, research, and competitive analysis
• Technical stack decisions and integration requirements
• A feature list with priorities
• High level sitemap, key flows, and content strategy highlights

Treat this document as the anchor for the engagement because it prevents scope creep and misaligned expectations once work is underway.

10.2 Supporting Evidence And Working Artifacts

Collect the underlying material that supports the main document so the team can trace decisions back to data when needed.

Bundle:

• Analytics extracts and funnel analyses
• Summaries of surveys, interviews, recordings, and support insights
• Competitive teardown notes and gap analysis tables
• Content inventory, page level intent mapping, and ownership lists
• Risk register, redirect plan, and launch monitoring checklist

Supporting material are important because it speeds up onboarding and keeps debates grounded in evidence.

10.3 Internal Sign Off And Ownership

Close the loop internally.

Run a short review with core stakeholders to walk through the summary, goals, scope, and constraints, confirm budget and timeline, and clarify who owns decisions and how scope changes will be handled.

Capture explicit approval. That approval is what lets you push back when new ideas surface that do not fit the agreed goals or constraints.

At this point, website redesign preparation is complete. You have a documented current state, a clear diagnosis, hard requirements, a risk plan, and a playbook that a capable team can execute.

Conclusion: Turning Preparation Into A Safer Redesign

Most redesigns are decided in a boardroom and judged in a dashboard. The part in the middle is where they fail. The core idea of website redesign preparation is that the outcome is largely locked in before anyone opens a design tool.

What you have here is a practical control system. You secure the current site, run audits to build a hard baseline, align stakeholders around measurable goals, capture user reality, define a buildable technical and content blueprint, and plan how to protect SEO and business continuity so launch day is uneventful in the best way. 

If you are a CEO, CFO, founder, or operator in a business the key is simple: do not pay for design to solve planning problems. Use this checklist to force clarity before you sign contracts, approve budgets, or set launch dates. The time and money invested in structured discovery, requirements, and risk planning usually comes back as avoided rework, tighter scope, and fewer surprises.

From here, your next move is to adapt this framework to your context and turn it into a living document for your team and vendors. Once that is in place, visual design stops being guesswork and becomes an implementation of decisions you have already made.