Website Redesign Checklist: Protect Leads and SEO

A website redesign is often treated as a visual project. The homepage gets a sharper headline, the palette feels fresher, and the launch announcement goes out on schedule.

Then someone notices that an important service page has vanished. Paid campaigns still point to old URLs. Form submissions are no longer tracked. Organic traffic drops because redirects were an afterthought.

The design can be excellent and the launch can still fail.

This checklist treats a redesign as what it really is: a coordinated change to your sales journey, content, search footprint, analytics, and technology. Use it whether you are rebuilding five pages or five hundred.

Before design: agree on the job

Define outcomes, not just deliverables

“Launch a modern website” is a deliverable. A useful outcome sounds more like:

• Increase qualified consultation requests from service pages.
• Help enterprise buyers understand security and implementation earlier.
• Reduce the number of support questions about onboarding.
• Make publishing a case study take hours instead of days.
• Improve mobile speed on pages receiving paid traffic.

Choose one primary outcome and two or three supporting measures. Record the current numbers before changing anything. Depending on the site, that might include conversion rate, qualified leads, organic entrances, task completion, page speed, or publishing time.

Without a baseline, every post-launch discussion becomes subjective.

Interview the people closest to the problems

Speak with customers, sales, support, marketing, and whoever maintains the site. Each group sees a different part of the journey.

Ask customers what they came to find, what was missing, and what almost stopped them from contacting you. Ask sales which misconceptions they repeatedly correct. Ask support which information would prevent a ticket. Ask editors where the content management system slows them down.

Patterns from these conversations should shape the information architecture before wireframes begin.

Inventory what you already have

Create a spreadsheet with every indexable URL. Include:

• URL and page title
• Page purpose and intended audience
• Organic entrances and conversions
• Backlinks or referral traffic
• Content owner
• Decision: keep, improve, merge, redirect, or remove
• Planned destination URL

Do not judge pages only by traffic. A low-traffic security page may help close large deals. A technical article may earn valuable links even if it generates few direct inquiries. A frequently used support page may save the team hours each month.

The inventory is where content strategy meets risk management.

Plan the new structure around user questions

Navigation should reflect how visitors think, not the company org chart. Start with the questions people arrive with:

• Can you solve my kind of problem?
• Have you done something similar?
• How do you work?
• What will this require from my team?
• What is the likely investment or engagement model?
• Why should I trust you?
• What do I do next?

Give each important page one clear job. A service page can explain fit and move a qualified visitor toward a conversation. A case study can reduce perceived risk. A comparison page can help someone choose between approaches. Trying to make every page do everything usually creates long, repetitive pages with weak calls to action.

Protect search visibility before URLs change

Search engines have already built a history around your current pages. Preserve that history deliberately.

Build a one-to-one redirect map

Map every old URL to the most relevant new URL. Use a server-side permanent redirect, normally 301 or 308, when the move is permanent. Avoid sending a large group of unrelated pages to the homepage. That is unhelpful to visitors and may be interpreted as a soft 404.

Google's official site migration guidance recommends preparing a URL map, implementing permanent redirects, and monitoring both old and new URLs.

A simple map looks like this:

Test the map in staging and again in production. Check that each old URL goes directly to the final destination rather than through a chain.

Carry forward the SEO essentials

For every indexable page, review:

• A unique, descriptive title and meta description
• One clear page heading
• Useful body content, not a shortened placeholder
• Descriptive internal links
• Canonical URL
• Crawl and index directives
• Structured data where it truthfully applies
• Image alternative text
• Open Graph and social preview metadata

Do not automatically copy weak metadata from the old site. Preserve the subject and intent, then improve the language.

Design the conversion path, not only the page

A call to action works when it feels like the natural next step. Match it to the visitor's readiness.

Someone reading an early-stage guide may want a checklist or related case study. Someone comparing vendors may need process detail, proof, pricing context, or a discovery call. “Contact us” repeated after every section is not a journey.

For each core page, write down:

1. What the visitor probably knows when they arrive.
2. What question the page must answer.
3. What evidence reduces their risk.
4. What sensible action comes next.

Prototype that path across mobile and desktop. Forms should ask only for information the team will actually use. Explain what happens after submission; uncertainty is friction.

Keep accessibility in the definition of done

Accessibility is easier to build in than bolt on. During design and development, check:

• Text and controls have sufficient color contrast.
• Every interactive element works with a keyboard.
• Focus indicators are easy to see.
• Form fields have persistent labels and useful error messages.
• Heading levels follow a meaningful order.
• Images have appropriate alternative text, or empty alt text when decorative.
• Motion can be reduced and does not block access.
• Tap targets are large enough to use comfortably.
• Zoom and text resizing do not break the layout.

Test with a keyboard and at least one screen reader. Automated checks are useful, but they cannot tell you whether the reading order makes sense or an error message is actually helpful.

Set a performance budget before development ends

“Make it fast” is too vague to guide tradeoffs. Agree on limits for page weight, image size, JavaScript, font files, and third-party scripts.

Pay special attention to the largest above-the-fold image, font loading, tag managers, chat widgets, video embeds, and animation libraries. Each may be reasonable on its own; together they can make a page feel heavy on an ordinary phone.

Test on real devices and a realistic connection, not only a fast office laptop. The companion guide, Core Web Vitals for business websites, explains what the main experience metrics mean and how to prioritize fixes.

Make analytics part of QA

Write a measurement plan before launch. List each important action and the event that should represent it:

Use a test property or debug view and confirm events fire once, carry the right values, and respect consent choices. Keep a dated annotation of the launch so future reporting has context.

Pre-launch QA checklist

Run the final review against a production-like build.

Content and links

• Approved copy is present; no placeholder text remains.
• Names, dates, claims, and contact details are accurate.
• Internal and external links work.
• Downloads open and have sensible file names.
• The custom 404 page returns a real 404 status.

Search

• Redirects have been tested from the full URL inventory.
• Canonicals point to the preferred production URLs.
• Accidental noindex tags and crawl blocks are removed.
• XML sitemap contains only canonical, indexable URLs.
• Structured data validates and matches visible content.
• Search Console ownership will remain verified.

Experience

• Navigation, search, forms, filters, and checkout paths work.
• Keyboard order and focus are logical.
• Error, empty, loading, and success states are designed.
• Mobile layouts are checked at several widths.
• Images have correct dimensions and alternative text.

Operations

• Analytics and advertising events are verified.
• Cookie and consent behavior is tested.
• Backups and a rollback plan exist.
• DNS, certificates, email, and form delivery are confirmed.
• Someone owns launch-day monitoring and decisions.

The first 30 days after launch

Do not declare the project finished when the new homepage loads.

On launch day, crawl the production site and spot-check your highest-value journeys. Watch server errors, form delivery, analytics, and payment or authentication flows if applicable.

During the first week, review 404s, redirect failures, Search Console indexing, Core Web Vitals, and traffic to important landing pages. Compare like-for-like periods and account for campaigns or seasonality.

Over the next month, combine the numbers with real behavior. Watch session recordings if your privacy policy permits them. Ask sales whether lead quality changed. Look for pages where visitors hesitate or return to navigation. Fix clear defects quickly; collect larger design hypotheses for a measured iteration.

Some search fluctuation is normal after a substantial move while pages are recrawled and reprocessed. The goal is not to panic at every daily change. It is to make sure search engines and people can reach the right content without friction.

The short version

A safe redesign preserves what already works, makes deliberate improvements, and measures the result. The non-negotiables are:

1. Agree on measurable business outcomes.
2. Inventory content before deciding what disappears.
3. Design around user questions and next steps.
4. Map old URLs to relevant new destinations.
5. Build accessibility, performance, and analytics into the work.
6. Test the complete journey in a production-like environment.
7. Monitor and improve after launch.

Questions about redesign risk

If you are planning a redesign and need product thinking, visual design, and engineering to move together, see our web and mobile development services, product design services, or tell us what is changing.