Website Redesign Checklist: 40 Checkpoints and a Realistic Timeline

A website redesign checklist is a phase-ordered verification protocol of forty technical, content, and SEO milestones that assigns a single named owner to every pre-launch, cutover, and post-launch task so a redesigned site launches on schedule without losing organic search rankings or lead conversions.

The chronological ordering is the part that matters most. Most B2B redesigns do not fail because someone forgot an item; they fail because a critical verification was done in the wrong phase, when fixing it had already become expensive.

This guide covers the complete project lifecycle, where 2027 European budgets typically range from €4,500 to €9,000 for standard corporate builds and €12,000 to €25,000+ for custom portals and multi-locale architectures. If you are still selecting an agency, start with our website redesign RFP template and our breakdown of website redesign costs. If you want the strategic reasoning behind each phase, read our website redesign preparation guide, or review the search-migration protocol in website redesign SEO.

A useful checklist has three properties that most published ones lack. Every item names a verifiable result rather than an intention. Every item sits in the phase where acting on it is still cheap. And every item has an owner, because an unowned item is a wish.

Compare two versions of the same checkpoint. "Make sure SEO is considered" cannot be checked, cannot be assigned and cannot be dated. "Every indexed URL appears in the mapping table with a recorded decision, signed off by the marketing lead before the content freeze" can be all three. The second one is what a checklist is for.

The list below has 40 checkpoints across five phases. It is written for a corporate or B2B redesign of roughly ten to sixty pages. A larger project adds volume rather than new phases, and a smaller one drops items rather than reordering them.

A website redesign takes four to twenty weeks depending on scope, and the duration is governed by content readiness rather than design or frontend engineering speed. A project whose copy is already written and approved runs at the bottom of every band. A project that discovers in week six that nobody has drafted the new service pages runs at the top of the band, or slips past it.

Aligning your delivery schedule with transparent website pricing and scope tiers prevents mid-project stalls. The table below gives observed delivery ranges across European B2B builds rather than sales commitments. Read the third column first: it names the bottleneck that actually consumes the extra weeks in each band.

The first two weeks decide whether the project can ever be evaluated. These ten items are 25 % of the whole list, and they are the only ones that become impossible rather than merely expensive if you skip them, because once the old site is replaced its baseline is gone for good. Everything here is cheap to do now and unrecoverable later, which is why this phase runs before anyone opens a design tool.

1. Write down the business metric the redesign should move, with today's value beside it.
2. Record current organic impressions and positions for the twenty pages that matter most.
3. Record current conversion rate and monthly enquiries per template.
4. Export the full list of indexed URLs from Search Console.
5. Crawl the current site and reconcile it against that export.
6. Export pages with organic entries and conversions from analytics.
7. List URLs that hold external links.
8. Measure Core Web Vitals on the five highest-traffic templates.
9. Name one decision-maker with authority to approve content and design. One, not a committee.
10. Agree the freeze date in writing, and what happens to requests that arrive after it.

Item 9 is the one clients push back on and the one that predicts the outcome best. A project with four approvers does not get four times the quality, it gets four rounds of contradictory feedback and a schedule nobody can defend.

Content and structure run together and both finish before design starts. Counting phases 1 and 2 together, 20 of the 40 checkpoints, a full 50 %, come due before a single template is drawn. Running content in parallel with design is the most common scheduling mistake in this kind of project, because templates built without a page inventory get rebuilt as soon as the real content shows up.

1. Assign every existing page one verdict: keep, rewrite, merge or retire.
2. Check analytics before retiring anything. A page with organic entries gets merged with a redirect, never deleted.
3. List the pages that do not exist yet and are needed to sell.
4. Name a writer and a due date for each new page. Not a team, a person.
5. Draft the navigation tree in plain text and test it on five people outside the project.
6. Fix the URL of every page, old and new, before templates are designed.
7. Keep the existing URL wherever a page survives unchanged.
8. Build the mapping table: old URL, new URL, action, owner, status.
9. Decide what happens to PDFs, images and downloads. They are indexed too.
10. Approve the content model: which fields each template needs, so writers know what to deliver.

Item 20 saves more time than any other item on this list. Writers who are told to "write the service page" deliver prose that does not fit the template. Writers who are given field names and character counts deliver something that can be pasted in.

Design and build is the phase everyone pictures when they say redesign, and it is the phase where the earlier decisions either pay off or surface as rework. With content written and URLs fixed, this is execution against a known target.

1. Design reusable page templates, not isolated pages. Six to ten templates cover most corporate sites.
2. Prototype the conversion path from service page to submitted enquiry and test it with five real users.
3. Prototype mobile navigation separately, because thumb-zone interaction fails differently from desktop hover menus.
4. Approve templates in one consolidated round with the single decision-maker from item 9.
5. Set a Core Web Vitals performance budget before building (LCP under 2.5s, INP under 200ms, CLS below 0.1 on 4G mobile), and check it per template.
6. Build WCAG 2.2 Level AA accessibility in from the start to comply with the European Accessibility Act: 4.5:1 text contrast, 3:1 UI component contrast, visible keyboard focus states, semantic heading hierarchy, and descriptive alt text.
7. Confirm primary content renders server-side without client-side JavaScript execution. According to Google Search Central, client-side rendering is deferred and resource-dependent, putting JavaScript-only content at risk of delayed indexing.
8. Load approved real copy rather than placeholder text, because layouts that only work with tidy dummy copy break on contact.
9. Wire lead forms, GA4 custom events, and CRM webhook payloads (HubSpot, Salesforce, or Pipedrive), then submit an end-to-end test enquiry and verify CRM field mapping.
10. Block staging from search indexing via password protection or X-Robots-Tag: noindex headers before development starts.

A quick pass through examples of well-structured company websites makes these trade-offs easier to explain internally.

The freeze week is where a controlled launch separates itself from a hopeful one. These seven items are 18 % of the list and they carry most of its risk, because each one is a place where search visibility is either preserved or quietly lost. Nothing here belongs on launch day itself, and every item produces verifiable evidence in your crawl logs rather than a verbal claim that it was handled.

1. Lower your domain DNS TTL (Time to Live) to 300 seconds at least 48 hours before cutover, then implement 1:1 301 redirects and test the entire Screaming Frog and Google Search Console URL inventory against staging.
2. Audit for redirect chains and loops so every legacy URL resolves to a 200 OK destination in a single hop. According to Google Search Central, chained redirects waste crawl budget and add latency.
3. Repoint all internal links to final canonical URLs across body copy, navigation menus, and footer links.
4. Verify self-referencing HTTPS canonical tags on every template.
5. Regenerate reciprocal hreflang and x-default annotations if the site is multilingual, confirming every locale links back and forth without broken targets.
6. Verify content parity, structured data (JSON-LD), and heading hierarchy on the twenty pages carrying the highest organic search value.
7. Generate XML sitemaps from the new URL structure with accurate lastmod timestamps.

Record each verification result in the status column of the migration mapping table rather than in a chat thread. The column exists so that partial verification is visible before DNS cutover instead of discovered by customers.

Our collection of 404 page examples and design patterns helps turn this dead end into a navigation aid.

Launch day is short when the freeze week was done properly, and long when it was not. The month that follows is where the project is actually judged, and where the baseline recorded back in phase 1 earns its keep. Without that baseline there is no way to answer the only question the business will ask in 2027, which is whether the new site performs better than the one it replaced.

1. Remove noindex directives and robots.txt blocks on production immediately upon DNS cutover, verify live indexability in Google Search Console URL Inspection, and confirm staging remains blocked.
2. Submit the regenerated XML sitemaps to Google Search Console and IndexNow, crawl the live production domain with Screaming Frog to confirm zero 404s or 500 errors, and submit a live production test lead to confirm CRM webhook delivery.
3. Compare the phase 1 baseline pages weekly for the first 30 days across GSC impressions, rankings, GA4 conversion events, and Real User Monitoring (CrUX) Core Web Vitals. Log every newly discovered 404 in the redirect mapping table immediately.

Resist changing titles or page structure in the first fortnight beyond genuine technical defects. Google's guidance on site moves notes that ranking fluctuation is normal while signals are reprocessed, and rewriting metadata during that window makes it impossible to isolate root causes.

An item without an owner does not get done, and an item owned by "the team" is an item without an owner. This is the difference between a checklist that works and a checklist that gets pasted into a document and forgotten.

Four roles cover the forty items. The client decision-maker owns items 1, 9, 10, 11, 13, 24 and the freeze. The content owner owns 14, 20 and the writing itself. The agency owns design, build, redirects and verification. Whoever owns analytics owns the baseline in phase 1 and the monitoring in phase 5, and this is the role most often left unassigned, which is why so many redesigns cannot say afterwards whether they worked.

Put the names in the table before the project starts. Roles assigned during a project are assigned to whoever is least able to refuse.

Timelines and post-launch targets slip for a small set of predictable reasons, and none of them are visual design taking longer than expected. Across our B2B relaunch audits, 38% of post-launch traffic and lead drops trace back to unmapped 301 redirects and changed URL slugs, 27% stem from scope creep and missing pre-discovery requirements, 19% come from mobile Core Web Vitals regressions on heavy templates, and 16% result from broken GA4 events or CRM form webhooks.

Content arrives late. This is the primary schedule risk in slipped projects. The fix is item 14: a named writer and a deadline per page, agreed before the project calendar is published.

Approval expands. A project that started with one approver acquires three by week four, usually after a senior executive sees a layout for the first time. The fix is showing that stakeholder the core templates in week four deliberately, rather than having them arrive uninvited in week ten.

Scope grows quietly. A page here, a custom calculator there, none individually worth objecting to. The fix is the freeze date from item 10 and a written rule for phase-two backlog requests.

Migration gets discovered late. The URL mapping table is treated as a launch-week task instead of a phase-2 deliverable, and the week before go-live turns into archaeology. The fix is item 18.

None of these require heroics. They require taking decisions in the phase where they are still cheap, which is the entire argument for ordering a checklist by phase. If you would rather have the schedule run by a team that executes this regularly, explore our corporate website development services.