What should I do before starting a website redesign?

Agree the business problem and a handful of measurable goals, then audit the current site and inventory every page. List integrations, set accessibility and performance targets and start the redirect map. With those in hand you can brief suppliers and budget accurately.

How long does a website redesign take?

It depends on template count, content readiness and integrations. Typical phases are discovery at 1–2 weeks, content and structure at 2–4 weeks, design at 3–6 weeks, build at 4–12 weeks, and testing and launch at 1–3 weeks. Phases often overlap, and content is the one most likely to slip.

How much does a website redesign cost?

Typical US market ranges run from $6,000 – $20,000 for a small marketing site to $20,000 – $75,000 for a business site with systems, and $75,000+ for large or complex builds. Our marketing sites start from $18,000 per project. The final figure depends on templates, content readiness, integrations, accessibility and migration.

Will a redesign hurt my search rankings?

It can if URLs change without redirects or content is removed without a plan. Record current search performance, build a complete redirect map, carry over titles and content for pages you keep, and remove staging indexing blocks at launch. Monitor crawl errors and traffic closely in the weeks afterward.

What is a content inventory and why does it matter?

It is a list of every page on your current site with a decision to keep, merge, rewrite or remove each one. It shows how much content work the redesign needs, how many templates are required and which URLs need redirects. Content that is ready before the build moves much faster than content written during it.

Should I include accessibility in a redesign?

Yes, and from the start. Meeting WCAG 2.1 AA from the outset adds modestly to design and build, while retrofitting it later costs several times more. Write the target into the scope so design, development and testing all work to it.

Website Redesign Checklist: What to Do Before You Start

A website redesign checklist is the list of decisions, audits and preparations to complete before anyone opens a design file. Most redesigns that go wrong do not fail in design or development. They fail earlier, when a team starts without agreed goals, without knowing what content exists, without a plan to protect search traffic, or without a realistic budget and timeline. By the time those gaps show, they are expensive to close.

This guide is for marketing leads, business owners, operations managers and anyone about to commission or manage a redesign, whether the site is a twelve-page brochure or a business platform with integrations and a thousand pages of history. It starts with a master checklist you can copy into your own project plan, then works through each phase in order: goals and measures, an audit of the current site, a content inventory, SEO protection, technical and integration requirements, budget and timeline, supplier selection and launch readiness.

Each section explains why the items matter and how to do them well. The aim is that when you brief a supplier, you are handing over answers rather than open questions, which is the single most effective way to keep a redesign on time and on budget.

The master website redesign checklist

Use this as a running list. Not every item applies to every site, but every item you skip should be skipped deliberately, with a reason written down.

Write down the business problem the redesign is meant to solve, in one or two sentences.
Choose three to five measures of success and record their current values as a baseline.
Name one decision-maker and a small group of reviewers, with the scope of each person's sign-off.
Audit the current site: analytics, top pages, conversion paths, speed, accessibility and known problems.
Talk to the people who use the site: customers, sales, support and whoever edits it every week.
Build a full content inventory with a keep, merge, rewrite or remove decision for every page.
Assign owners and deadlines for every piece of new or rewritten content.
Export every current URL and build a redirect map before design begins.
Record the current search performance of the pages that bring in traffic.
List every integration, form, feed and third-party script, with its owner and its contract.
Set accessibility, performance, hosting, security and CMS requirements in writing.
Count the unique templates the new site will need, not just the pages.
Set a budget with a contingency and a timeline that includes content and review time.
Write a scope or brief that suppliers can price against like for like.
Check suppliers' process, references, handover terms and who will maintain the site.
Plan launch: testing, redirects, analytics, rollback and post-launch monitoring.

The sections below take these items phase by phase. If you only have time for one thing before you start, do the content inventory: it drives scope, cost, timeline and SEO protection all at once.

Phase 1: Goals and measures

A redesign without a goal becomes a series of opinions about color and layout. A redesign with a goal becomes a set of decisions that can be tested against it. This phase is short, but every later phase depends on it.

Name the problem, not the solution

"We need a new website" is a solution. The problem underneath it is usually one of a handful: the site does not generate enough inquiries, it does not explain what the business now does, it is too slow or too hard to edit, it cannot support a new product or market, or it has become a patchwork after years of additions. Write the problem down in plain language. If the leadership team cannot agree on a sentence, that disagreement needs to be settled now, not in the third design review.

Choose measures you can actually track

Pick three to five measures that connect to the problem. For a lead-generation site, those might be qualified form submissions, calls from the site and conversion rate on key service pages. For an e-commerce site, they might be conversion rate, average order value and checkout completion. For a content site, they might be organic entrances, engaged sessions and newsletter sign-ups. Add operational measures if editing is the pain: how long it takes to publish a page, or how many changes still need a developer.

Record the current value of each measure before anything changes. Without a baseline, you cannot tell afterward whether the redesign helped, and you will not be able to separate the effect of the new site from seasonal swings. A few months of history for each measure, taken from the same tools you will use after launch, is far more useful than a single snapshot.

Define who decides

Name one person who makes final decisions and a small group who review. Be explicit about scope: the legal reviewer approves terms and claims, not the hero image; the sales lead reviews service pages, not the navigation font. Unclear sign-off is one of the most common causes of delay, because feedback arrives late, from people who were not in the brief, and contradicts decisions already made.

Decide whether you need a redesign at all

Some problems do not need a whole new site. A single campaign may need a focused landing page; a slow site may need performance work rather than new templates; a confusing offer may need rewritten copy more than new layouts. Our guide to choosing between a landing page and a full website helps with that decision, and it is worth having before you commit budget.

Common mistake: Setting the goal as "look more modern." Appearance matters, but it cannot be measured or prioritized against anything else. Tie the visual refresh to a business result, such as clearer positioning for a new service, so design choices have something to be judged against.

Phase 2: Audit of the current site

The current site is the best research tool you have. It shows what visitors actually do, which pages carry the business, and which problems the redesign must fix. An audit also protects what already works: plenty of redesigns have thrown away a page or a path that was quietly generating most of the leads.

Analytics: what people do

Pull a year of data if you have it, so seasonality is visible. Identify the pages that receive the most entrances, the pages that sit on the path to conversion, and the pages with high exits on important journeys. Look at device split, because a site used mostly on phones should be designed phone-first. Note the top internal searches if your site has search; they show what visitors expected to find and could not.

Conversion paths: how the site makes money

Map the routes that lead to a form submission, a purchase, a booking or a call. For each, list the pages involved, the forms, the confirmation messages and the emails that follow. These paths are the parts of the site that must work perfectly on launch day, and they are frequently broken by redesigns because nobody wrote them down.

Technical health: speed, accessibility and errors

Run speed tests on the key templates on a mobile connection, and record the results as part of your baseline. Check accessibility with automated tools and a manual pass using a keyboard and a screen reader; automated tools catch only part of the problems. Crawl the site to find broken links, redirect chains, duplicate pages and missing titles. Each problem found now is either a requirement for the new site or a fix you can make immediately.

People: who uses the site and who runs it

Talk to a handful of customers, the sales team, customer support and the people who edit the site every week. Customers tell you what they could not find. Sales tells you which questions prospects still ask after reading the site. Support tells you what causes confusion. Editors tell you which parts of the CMS are slow, fragile or impossible without a developer. Interviews do not need to be formal: a short conversation with a consistent set of questions is enough.

Audit area	What to collect	What it decides
Analytics	Top entry pages, conversion paths, device split, internal search terms	Which pages and journeys must be protected and prioritized
Conversion paths	Forms, confirmations, notification emails, CRM handoffs	The launch-day test list and integration scope
Speed	Load results for key templates on mobile	Performance targets and hosting requirements
Accessibility	Automated scan results plus a manual keyboard and screen reader pass	Accessibility target and design constraints
Crawl	Every URL, broken links, redirects, duplicates, titles	Redirect map and content inventory
Interviews	Customer, sales, support and editor feedback	Content priorities and CMS requirements

Phase 3: Content inventory

Content readiness is one of the largest drivers of both cost and timeline. A site with copy and images ready moves at roughly twice the speed of one where content is written during the build. The content and structure phase of a project is also the one that slips. An inventory done before you start is how you stop that.

List every page

Start from the crawl in Phase 2 and put every URL into a spreadsheet. Add columns for page title, template type, owner, traffic, conversions, last updated date and a decision. Include PDFs, landing pages from old campaigns and pages that are not in the navigation; these are often the ones that still attract links and search traffic.

Decide what happens to each page

Give every page one of four decisions:

Keep as it is, perhaps with light edits and a new template.
Merge with related pages into one stronger page.
Rewrite because the information is right but the page no longer does its job.
Remove because it is out of date, duplicated or unused, with a redirect to the best alternative.

Then list the pages that do not exist yet but need to: new services, new audiences, comparison pages, answers to the questions sales and support keep hearing.

Assign owners and deadlines

Every page marked rewrite or new needs a named owner, a first-draft deadline and a reviewer. Content written by subject experts often needs editing for the web, so decide who does that too. Put content deadlines in the project plan alongside design and build milestones, because a design approved without real content usually needs reworking when the content arrives.

Count the templates

While you inventory content, note which layout each page needs. The number of unique templates matters more than the number of pages. A fifty-page site with six templates is a much smaller job than a twelve-page site with eleven. Count layouts, not pages. Typical templates include a homepage, a service or product page, a listing page, an article, a case study, a team or location page, a contact page and a landing page. If a page needs a layout nothing else shares, ask whether it really does, or whether an existing template with flexible sections would serve.

Structured content belongs in the same exercise. If services, locations, team members or products are going to be reused across the site, they should be modeled as structured types in the CMS rather than written into pages by hand. It is also the foundation for adding structured data for search engines later.

Myth: Design can be finished with placeholder text and the real content dropped in at the end.

Reality: Real content changes layouts: headings run longer, lists appear, images are missing. Get at least real draft content for each template before design is approved.

Phase 4: SEO protection

A redesign can erase years of search visibility in a day if URLs change without redirects, content is removed without a plan, or technical settings from a staging site reach production. Protecting search performance is not a finishing touch; it is part of the scope from the beginning.

Record your current search performance

Export the pages that receive organic traffic and the queries that bring it, from your search console account and analytics. Note which pages have external links pointing at them. These pages are your search equity, and the redesign should either keep them or redirect them to their closest equivalent.

Build the redirect map early

Testing and launch includes the redirect map, but the map should start in this phase, not the week before launch. For every URL in the inventory, record the new URL it will live at, or the page it will redirect to if it is being merged or removed. Use permanent redirects, point each old URL directly to its final destination rather than through a chain, and avoid sending large numbers of pages to the homepage, which gives visitors and search engines nothing useful.

Migration is its own project. Moving a thousand existing pages, preserving their URLs and their formatting, is its own project with its own risks. If your site is that size, scope the migration separately, with its own testing and its own owner.

Preserve what search engines read

Carry over page titles, meta descriptions, headings and body content for pages you are keeping, unless you are deliberately improving them. Keep or improve internal linking to important pages. Make sure the new templates output clean, crawlable HTML; how a site renders affects what search engines see, and our guide to getting rendering strategies right explains the trade-offs between server rendering, static generation and client-side rendering.

Protect the staging site and the launch

Staging sites should be blocked from indexing, and that block must be removed at launch. A leftover "noindex" setting or a blocking robots file on a live site is one of the most common and most damaging launch errors. Put both checks on the launch list, along with an updated XML sitemap and a resubmission in search console.

Phase 5: Technical and integration requirements

Integrations are where redesigns acquire hidden cost and hidden risk. A CRM, a booking system, a payment gateway, a legacy inventory feed: each one is a separate contract with somebody else's API and somebody else's outage. Listing them before you start turns surprises into scope.

List every integration and script

For each integration, record what it does, which pages use it, who owns the account, where the credentials are, what the contract or plan allows, and whether its API is documented. Include forms that send data to a CRM or email platform, analytics and advertising tags, chat widgets, review feeds, booking tools, payment processors, inventory or listing feeds, and single sign-on. Inventory feeds and listing data are particularly demanding, because they update constantly and the site depends on them being right.

Also list what you want to remove. Old tracking scripts, unused plugins and forgotten widgets slow sites down and create security risk. A redesign is the easiest time to retire them.

Set the accessibility target in writing

Choose an accessibility standard and write it into the scope. Meeting WCAG 2.1 AA from the start adds modestly to design and build. Retrofitting it later costs several times more. Stating the target at the outset means designers choose accessible colors and type sizes, developers build accessible components, and testing checks against a known standard.

Set performance, hosting and security requirements

Write down performance targets for key templates on mobile, based on your Phase 2 baseline. Decide where the site will be hosted, who manages hosting, how backups work and how often software is updated. Record security requirements such as HTTPS everywhere, form spam protection and access controls for editors.

Choose a CMS for the people who will edit it

The right CMS is the one your team can use safely every week. Specify the editing tasks that matter: creating a new landing page from existing sections, updating team members, publishing articles, changing navigation. Consider who maintains the site. Building something you can edit safely costs more up front than building something only a developer can change. It is almost always the cheaper of the two over three years.

Common mistake: Assuming an integration will "just connect." Every third-party system has its own limits, authentication and failure modes. Ask for API documentation and a test account at the start, and treat each integration as its own line in the scope and the test plan.

Phase 6: Budget and timeline

By this point you have what a supplier needs to price the work accurately: goals, an audit, a content inventory with a template count, a redirect map in progress and a list of integrations. That is why budget comes after those phases, not before them.

Understand the market ranges

Typical US market ranges give a sense of scale, though your scope decides where you fall:

Project type	Typical US market range	What it usually includes
Small marketing site	$6,000 – $20,000	Five to fifteen pages, a handful of templates, a CMS you can actually use, accessible and fast.
Business site with systems	$20,000 – $75,000	Custom templates, real integrations, structured content, a migration, and a testing pass that deserves the name.
Large or complex build	$75,000+	Multi-language, complex integrations, design systems, or anything where the site is the product rather than a brochure for it.

For comparison, our published starting rates are: a landing page or microsite from $4,800 per project, with a turnaround of 3–5 weeks; a marketing site from $18,000 per project, with a turnaround of 8–12 weeks; and retained engineering from $145 per hour, with a start within 2 weeks. These are starting prices, not guaranteed totals; the final figure depends on the cost drivers below. Our realistic website budget guide goes deeper into how those numbers are built.

Know what drives the cost

Number of unique templates. Count layouts, not pages.
Content readiness. Ready content moves at roughly twice the speed of content written during the build.
Integrations. Each is a separate contract with somebody else's API.
Accessibility target. Modest to include from the start, several times more to retrofit.
Migration. A large migration is its own project with its own risks.
Who maintains it. Editable by your team costs more up front and usually less over three years.

Plan the timeline phase by phase

A redesign runs through five phases. Each has its own typical duration, and the content phase is the one to watch.

Discovery: 1–2 weeks Goals, audit findings, requirements and scope confirmed with the supplier.
Content and structure: 2–4 weeks Sitemap, content models and real draft content. This is the phase that slips.
Design: 3–6 weeks Templates designed with real content, reviewed against goals and the accessibility target.
Build: 4–12 weeks Development, integrations and CMS setup; the range depends on template count.
Testing and launch: 1–3 weeks Functional, accessibility and performance testing, plus the redirect map.

Laid end to end, those ranges add up to 11 to 27 weeks. In practice phases overlap, for example with content work continuing while early templates are designed, and that overlap is how a well-prepared marketing site can fit inside a shorter window. Our article on how long it takes to build a website explains where time goes and how to protect it.

A worked example

This example is illustrative, not a quote or a real client. A professional services firm has a 48-page site. The inventory shows 30 pages to keep, 8 to merge into 3, 6 to rewrite and 4 to remove, plus 5 new pages. That gives 30 + 3 + 6 + 5 = 44 pages on the new site. Those 44 pages use 7 unique templates: homepage, service page, industry page, article, case study, team page and contact page. The firm needs one integration, forms feeding its CRM, and wants WCAG 2.1 AA from the start.

That profile, with a handful of templates, one integration and a modest migration, sits closest to the marketing site shape: a set of templates, real content, real integrations and a migration. Our marketing site starting rate is from $18,000 per project, and the market range for a small marketing site runs $6,000 – $20,000, with business sites with systems at $20,000 – $75,000. Where this project lands depends mostly on content readiness. If the 6 rewrites and 5 new pages are drafted before design starts, the content phase stays short. If they are written during the build, both the timeline and the cost rise. The redirect map needs entries for the 8 merged and 4 removed pages at minimum, 12 in all, plus any kept pages whose URLs change.

Set a contingency on top of whatever figure you agree, and decide in advance what it can be spent on, such as an integration that proves harder than documented. If you are weighing a fixed project fee against ongoing support, compare the total over several years, not just the launch figure.

Phase 7: Supplier selection

With the first six phases done, you can write a brief that suppliers can price like for like. Without it, every proposal makes different assumptions, and the cheapest proposal is often the one that assumed least.

Write a brief or RFP that can be compared

Include the goals and measures, audit findings, the content inventory with template count, the redirect and migration scope, integrations, accessibility and performance targets, CMS requirements, budget range and timeline. Ask suppliers to state their assumptions, exclusions and how they handle changes. Our guides to scoping a website project and writing a website RFP cover the structure in detail.

Decide what kind of supplier you need

A capable freelancer can be a good fit for a small site with few integrations. A studio or agency is usually the safer choice for a site with several templates, integrations, a migration and a firm launch date, because it can cover design, development, content, testing and project management without single points of failure. Our comparison of freelancers and agencies sets out the trade-offs.

Check process, not just portfolio

A portfolio shows what a supplier can make look good. It does not show whether they deliver on time, handle integrations well or hand over a site you can run. Ask how they run discovery, how they handle content delays, how they test accessibility, how they build redirect maps and what the handover includes. Ask to speak to past clients about the process, not just the result. Our list of questions to ask before hiring a web design agency is a useful starting point.

Agree ownership and maintenance up front

Confirm in the contract that you own the domain, hosting accounts, code, design files and content, and that credentials are handed over at launch. Agree who maintains the site after launch, how updates are handled and what support costs. A site without a maintenance plan decays quickly: software goes out of date, forms break and content drifts.

Phase 8: Launch readiness

Launch is the moment the old site's history and the new site's promises meet. A structured readiness check makes launch day uneventful, which is exactly what it should be.

Test what matters most first

Start with the conversion paths recorded in Phase 2. Submit every form and confirm the data reaches the CRM or inbox, the confirmation message appears and follow-up emails send. Complete test purchases or bookings end to end. Then test key templates on real phones and browsers, run accessibility checks against your target, and measure performance against the targets you set.

Verify redirects and search settings

Run the full redirect map against the staging site or immediately after launch, and confirm every old URL reaches the right destination in a single step. Check that indexing blocks from staging are removed, the XML sitemap reflects the new site, canonical tags are correct and analytics and tags fire on every template.

Plan the launch window and the rollback

Launch early in the week and early in the day, when the team is available to fix problems, and avoid your busiest trading periods. Keep the old site and its database available so you can roll back if something critical fails. Some teams reduce risk by launching in stages; our guide to phased website launches explains when that is worth it.

Monitor after launch

For the first weeks after launch, watch crawl errors, 404 pages, form submissions, conversion rate and search visibility against the baselines from Phase 1 and Phase 4. Fix missing redirects as they appear. Review the measures of success at agreed intervals, and schedule a post-launch review once there is enough data to compare.

Verdict The work that decides whether a redesign succeeds happens before design starts. Set measurable goals, audit what you have, inventory every page, protect search equity, list every integration, budget from a template count and choose a supplier on process. Do those well and design, build and launch become the predictable parts of the project.

Keeping the checklist useful after launch

The checklist does not stop being useful once the new site is live. The content inventory becomes your content calendar: pages marked for later rewrites, new pages that were deferred and reviews scheduled for pages that change often. The integration list becomes your maintenance register, showing which accounts, contracts and APIs need attention when something changes on the other side. The baseline measures become the reporting framework that shows whether the redesign paid off.

Treat the site as something you run rather than something you finished. Schedule regular checks of speed, accessibility, broken links and form delivery, and keep software updated. Our guide to planning website maintenance sets out what a sensible routine looks like. When the next redesign eventually arrives, you will start with an up-to-date inventory, a clean redirect history and real data about what worked, which makes the whole checklist quicker the second time.