Website Redesign Checklist: How to Redesign Without Losing Traffic

A website redesign is often described in terms of what visitors see and experience: new layouts, updated branding, better navigation, and a cleaner experience.

That description is incomplete.

A redesign can change your URL structure, page content, internal links, templates, JavaScript, performance, structured data, analytics, forms, redirects, and hosting environment. Those changes can improve the website, but they can also remove the signals that helped search engines understand and rank the existing site.

The safest redesigns treat SEO, analytics, accessibility, performance, and technical ownership as part of the product, not as checks to run the day before launch.

This website redesign checklist explains how to plan and deliver a redesign without unnecessarily losing organic traffic. It covers discovery, content and URL decisions, technical SEO, migration planning, staging, testing, launch, monitoring, and the point at which a redesign is really a modernisation project.

The short version: Preserve what already works, improve what does not, and make every important change deliberate, testable, and reversible.

Website Redesign Checklist at a Glance

Phase	What to check	Why it matters
Discovery	Business goals, users, technical constraints, analytics, search performance, and ownership	Prevents the redesign from optimising only for appearance
Content and URLs	Valuable pages, traffic, backlinks, conversions, redirects, and new information architecture	Protects existing search equity and user journeys
Design and build	Templates, semantic HTML, accessibility, performance, structured data, and responsive behaviour	Ensures the new site is usable and crawlable
Migration	URL mapping, redirects, canonicals, metadata, sitemaps, robots directives, and analytics	Reduces avoidable traffic and measurement loss
Testing	Crawlability, indexability, links, forms, performance, structured data, and redirects	Finds problems before search engines and users do
Launch	Change control, monitoring, rollback, and communication	Makes the release observable and recoverable
Post-launch	Search Console, rankings, traffic, conversions, errors, and technical regressions	Catches delayed problems and confirms whether the redesign worked

What Is a Website Redesign?

A website redesign changes the way a website looks, works, or communicates. The scope may be narrow or extensive.

A redesign might involve:

• New visual identity or brand application
• Revised page layouts and components
• Improved navigation and information architecture
• New content and messaging
• A new CMS or frontend framework
• A move to a headless or composable architecture
• New forms, integrations, or customer journeys
• Performance and accessibility improvements
• A change of hosting, domain, or deployment process
• A change to the website’s URL structure

These changes do not all carry the same risk. Replacing a colour palette is not equivalent to migrating thousands of URLs from one CMS to another. Combining a brand refresh with a platform change and new information architecture creates a more complex delivery and migration challenge.

A redesign should therefore begin by identifying which types of changes are involved:

1. Presentation changes: visual design, layout, typography, and components.
2. Content changes: page copy, media, resources, products, and messaging.
3. Structural changes: navigation, templates, taxonomy, URLs, and information architecture.
4. Technical changes: CMS, frontend, hosting, integrations, rendering, performance, and deployment.
5. Business changes: new conversion paths, markets, products, audiences, or operational workflows.

The more categories change at once, the more carefully the project needs to be planned.

Redesign vs. Website Modernisation

A redesign and a website modernisation project may overlap, but they do not necessarily have the same scope or objectives.

Project type	Main objective	Typical work
Visual and user experience redesign	Improve appearance and user experience	Layouts, components, typography, brand, responsive design
Content redesign	Improve clarity, relevance, and conversion	Messaging, page hierarchy, content consolidation, calls to action
Technical redesign	Improve how the site is built and operated	CMS, frontend, hosting, deployment, integrations, performance
Website modernisation	Improve the underlying technology and operating model	Architecture, platform migration, application changes, data flows, DevOps, security
Full website replacement	Create a new website and retire the existing one	Discovery, design, content, build, migration, launch, transition

The distinction affects budget, risk, timeline, ownership, and the people who need to be involved.

If the existing website is difficult to deploy, dependent on unsupported technology, or tightly coupled to fragile systems, treating the work as purely visual redesign can overlook important technical risks. Our guide to application modernisation strategy covers how to assess legacy systems and sequence change without assuming that replacement is always the answer.

Why Website Redesigns Lose Organic Traffic

Traffic loss often results from changes that were not identified, mapped, tested, or monitored properly.

Common causes include:

• Important URLs are removed without relevant replacements
• Redirects are missing, incorrect, or chained
• New pages are blocked by robots directives
• Canonical tags point to the wrong URLs
• Internal links still reference old or irrelevant paths
• Page content becomes shorter or less specific
• Important headings and text are removed from templates
• Structured data is lost or invalid
• The staging site is accidentally indexed
• The production site launches with noindex
• JavaScript rendering hides important content
• XML sitemaps contain old, redirected, or non-canonical URLs
• Performance becomes worse on mobile devices
• Analytics or conversion tracking stops working
• Search engines need time to process large-scale changes

Not every traffic change after a redesign is caused by a technical error. Search demand, seasonality, algorithm changes, competitors, and changes in the business can also affect performance. That is why a redesign needs a baseline and a post-launch monitoring plan rather than a vague assumption that rankings will remain unchanged.

Before the Redesign: Build a Baseline

Do not begin by deleting pages or designing templates. Start by understanding the current website.

Apply the checks below according to the scope of the redesign, the systems affected, and the importance of organic search to the business.

Record organic performance

Capture a baseline for at least the most recent representative period available. Useful measures include:

• Organic clicks and impressions
• Non-branded search visibility
• Ranking distribution for important queries
• Organic landing pages
• Organic conversions and assisted conversions
• Leads, purchases, or other business outcomes
• Crawl and index coverage
• Core Web Vitals and real-user performance
• Top pages by backlinks or referring domains
• Pages with meaningful internal links

Use the baseline to identify what must be preserved, what should improve, and what requires investigation.

Identify valuable URLs

Create a complete inventory of current URLs, including pages that may not receive much traffic but still have value through:

• Backlinks
• Internal links
• Long-tail search visibility
• Product or service relevance
• Conversion history
• Brand or partner references
• Legal, support, or customer-service usefulness

Do not decide that a page can be deleted because it has low traffic alone. A page may support another page through internal links or attract links even when it is not a major landing page.

Record technical dependencies

Document the current website’s:

• CMS and plugins
• Frontend framework
• Hosting and CDN
• DNS and certificate management
• Forms and CRM integrations
• Search and filtering
• Analytics and consent tools
• Payment systems
• Authentication and membership systems
• Marketing automation
• Image and video services
• Scheduled jobs and webhooks
• Deployment process

A redesign plan should look beyond frontend changes to assess their impact on the systems behind them.

Content and URL Inventory

A redesign is an opportunity to improve content, but content changes need structure.

Create a page-level inventory with columns such as:

Field	Purpose
Current URL	Identifies the existing page
Page type	Groups templates and content models
Primary topic	Clarifies search and user intent
Organic clicks	Indicates search visibility
Conversions	Indicates business value
Backlinks	Indicates authority and reference value
Internal links	Shows how the page participates in site architecture
Keep, improve, merge, redirect, or remove	Records the decision
New URL	Supports redirect and migration planning
Owner	Assigns responsibility
QA status	Tracks readiness

Keep pages that already work

Preserve pages that attract qualified traffic, conversions, valuable links, or important internal references. Improve them deliberately rather than rewriting them simply to match a new design.

Improve underperforming pages

A page with the right intent but weak content may need clearer messaging, stronger evidence, better structure, better internal links, or a more useful conversion path.

Consolidate overlapping pages

Several weak pages targeting the same intent may be consolidated into one stronger resource. Record the old URLs and redirect them to the final page when the new page genuinely covers their purpose.

Remove pages carefully

Remove pages that are obsolete, duplicated, misleading, or no longer useful. Before deleting a page, check its traffic, backlinks, internal links, conversions, and relationship to other content.

A redirect is not a magic replacement for a page that has no equivalent. Redirecting every retired URL to the homepage can create poor user experiences and weak relevance signals.

URL and Information Architecture Checklist

The new information architecture should help users and search engines understand the relationship between topics, services, products, and resources.

Before build begins, decide:

• Which URLs remain unchanged
• Which URLs need to change
• Which pages are new
• Which pages are consolidated
• Which pages are removed
• How categories and subcategories work
• How pagination works
• How filtered and faceted URLs behave
• How language or regional versions are represented
• How trailing slashes, case, parameters, and file extensions are handled
• Which URLs are canonical

Prefer stable, descriptive URLs. Do not change URLs merely to make them shorter if the current URLs are already clear, indexed, and valuable.

The new structure should also support a sensible internal-linking model. Important service pages should be reachable from relevant resources, and supporting articles should link naturally to the pages that help readers take the next step.

Migration Mapping and Redirects

When URLs change, a URL map is one of the most important deliverables for managing SEO risk.

At minimum, map:

• Every valuable old URL
• Its new URL or final disposition
• Redirect status
• Content owner
• QA status
• Notes about changed intent or content

Use one-to-one redirects where possible

If /old-service becomes /services/new-service, redirect the old page directly to the new equivalent.

Avoid chains such as:

old URL → temporary URL → category URL → final URL

Each extra hop increases complexity and creates more ways for the migration to fail.

Redirect relevant pages to relevant destinations

A redirect should take the user to the closest useful equivalent. If no equivalent exists, consider whether the old page should return a genuine not-found or gone response rather than being redirected to an unrelated page.

Avoid redirecting everything to the homepage

Homepage redirects are rarely a good substitute for a migration plan. They can confuse users and fail to preserve the original page’s topical relevance.

Test redirects before launch

Test a representative sample and then crawl the complete redirect list. Look for:

• Redirect loops
• Chains
• 404 responses
• Incorrect destinations
• Redirects to non-canonical URLs
• HTTP-to-HTTPS problems
• Hostname inconsistencies
• Redirects that accidentally expose staging URLs

Technical SEO Checklist for the New Website

Crawlability

Check that search engines can discover the pages intended for indexing.

Review:

• Internal links
• Navigation
• XML sitemaps
• Robots directives
• JavaScript-generated links
• Pagination
• Faceted navigation
• Orphan pages
• Status codes

Indexability

Confirm that important pages are indexable and that private, duplicate, staging, or utility pages are excluded intentionally.

Check:

• noindex directives
• Canonical URLs
• X-Robots-Tag headers
• Duplicate templates
• Parameter handling
• Thin or empty pages
• Login and account areas

Metadata

Review title tags, meta descriptions, headings, image alternative text, Open Graph data, and other metadata across representative page types.

Do not rely on one template test. A redesign may work correctly on a service page while producing missing or duplicated metadata on articles, products, locations, or filtered pages.

Structured data

Retain or rebuild structured data where it accurately describes visible page content. Validate it after the new templates are rendered.

Do not add structured data simply because a competitor uses it. Markup should describe real entities, content, products, services, articles, organisations, or breadcrumbs visible on the page.

Internal links

Internal links help users navigate and help search engines understand the site’s structure.

Check that:

• Important pages remain linked
• Old links are updated
• Anchor text remains descriptive
• Links do not point to redirects unnecessarily
• New supporting content links to relevant services
• Navigation reflects the new information architecture
• Footer links remain useful rather than becoming an oversized list

Our technical SEO services can support deeper crawlability, indexability, structured-data, and migration reviews when the redesign has a significant search component.

Design and Content Checklist

Design for the actual audience

A redesign should consider how changes affect comprehension and action, as well as visual presentation.

Ask:

• Can visitors understand what the organisation does quickly?
• Are the important services or products easy to find?
• Does the design reflect the seriousness and complexity of the buying decision?
• Are calls to action proportionate to the visitor’s intent?
• Can returning users find familiar information?
• Does the design work for people using keyboards, screen readers, and mobile devices?

Preserve information gain

Do not remove useful detail because the new design favours shorter pages. Concise design and useful content are not opposites.

Retain information that helps users:

• Compare options
• Understand technical constraints
• Evaluate risk
• Decide whether a service is relevant
• Trust the organisation
• Take the next step

Avoid design-led content loss

A new layout may make it tempting to remove headings, explanatory sections, FAQs, examples, or internal links. Record these changes in the content inventory and assess their search and conversion implications before removing them.

Performance and Accessibility Checklist

Performance

Test representative pages on mobile and desktop. Consider:

• Largest Contentful Paint
• Interaction to Next Paint
• Cumulative Layout Shift
• Server response time
• JavaScript execution
• Image and font loading
• Third-party scripts
• Caching and CDN behaviour
• API response times
• Unused CSS and JavaScript
• Render-blocking resources

Do not optimise a single homepage screenshot and assume the whole site is fast. Test article, service, product, search, form, and account experiences where relevant.

Accessibility

Review:

• Keyboard navigation
• Focus order and visible focus
• Heading structure
• Form labels and error messages
• Colour contrast
• Alternative text
• Link purpose
• Responsive behaviour
• Motion and animation preferences
• Screen-reader behaviour for important workflows

Automated tools are useful, but they do not find every accessibility problem. Include manual testing for important user journeys.

Analytics and Conversion Tracking

A redesign can make traffic appear to fall when measurement has simply broken.

Before launch, record:

• Analytics property and data-stream details
• Consent-management behaviour
• Conversion events
• Form and CRM integrations
• Ecommerce events
• Call tracking
• Search tracking
• Campaign parameters
• Server-side or offline conversion flows

Create a test plan for each important conversion. Verify that the event fires once, carries the expected values, reaches the intended platform, and respects consent requirements.

Do not change the measurement model during the redesign without documenting the change. If the new website counts conversions differently, pre- and post-launch comparisons may become misleading.

Staging Environment Checklist

A staging environment should be private but realistic enough to test the new website.

Check:

• Password protection or access control
• Search-engine blocking that cannot accidentally reach production
• Realistic content and media
• Representative templates
• Integrations and test credentials
• Forms and transactional emails
• Redirect testing
• Structured data
• Analytics in test mode
• Performance and responsive behaviour
• Accessibility
• Deployment and rollback procedures

Do not use a blanket robots block as the only protection for sensitive staging data. Keep staging private through authentication or network controls.

Before launch, remove staging-specific settings deliberately rather than relying on memory.

Pre-Launch Website Redesign Checklist

Content

• All important pages have an approved disposition
• New content has an owner
• Consolidated pages have been reviewed for intent
• Images are optimised and have appropriate alternative text
• Downloads and resources are current
• Calls to action have been tested

URLs and SEO

• URL inventory is complete
• Redirect map is complete
• Canonicals are correct
• Metadata exists across page types
• Structured data has been validated
• XML sitemap is ready
• Robots directives are ready
• Internal links have been crawled
• Staging cannot be indexed

Functionality

• Forms submit successfully
• CRM and email notifications work
• Search works
• Filters and pagination work
• Authentication works where relevant
• Payments and checkout work where relevant
• Integrations handle errors
• Scheduled jobs run
• Emails and notifications render correctly

Performance and accessibility

• Important templates have been tested on mobile
• Images and fonts load efficiently
• Core Web Vitals have been reviewed
• Keyboard navigation works
• Focus states are visible
• Forms have labels and useful errors
• Headings and landmarks are logical

Operations

• Deployment process is documented
• Rollback process is tested
• Backups are current
• Access and credentials are controlled
• Monitoring is configured
• Error logging is available
• Ownership and escalation are clear

Launch-Day Checklist

A redesign launch should be treated as a controlled production release.

Before deployment

• Confirm the final release candidate
• Freeze or document content changes
• Take a production backup
• Confirm the rollback version
• Confirm DNS, hosting, certificates, and CDN settings
• Confirm the redirect rules
• Confirm analytics and consent configuration
• Confirm who is available during the release

During deployment

• Deploy according to the runbook
• Check the homepage and representative templates
• Test forms, search, authentication, and checkout
• Test redirects
• Check status codes and canonicals
• Check robots directives
• Confirm the XML sitemap
• Confirm monitoring and logging

Immediately after deployment

• Submit or refresh the sitemap where appropriate
• Inspect important URLs in Search Console
• Crawl the live website
• Review server errors
• Check analytics and conversion events
• Check mobile rendering
• Record issues and owners

Do not make several unrelated large changes immediately after launch. If something goes wrong, a stable release makes diagnosis easier.

Post-Launch Monitoring

The first days and weeks after a redesign need active monitoring.

Review:

• Organic clicks and impressions
• Important landing pages
• Index coverage
• Crawl errors
• Redirect errors
• Server logs where available
• Conversion events
• Form submissions
• Search and navigation behaviour
• Performance and Core Web Vitals
• Revenue or qualified leads

Expect some volatility when many URLs or templates change. The objective is not to panic at every movement; it is to identify technical failures quickly and distinguish them from normal search reprocessing or broader market changes.

First 24 hours

Focus on availability, critical journeys, redirects, robots directives, canonicals, analytics, and obvious rendering problems.

First week

Review crawl and indexation signals, search impressions, landing pages, forms, performance, and error logs.

First month

Compare business outcomes, content performance, ranking changes, technical health, and user behaviour against the baseline.

A redesign should be evaluated against the business reason it was commissioned. If the goal was qualified leads, traffic alone is not enough. If the goal was better publishing efficiency, rankings may not be the primary measure.

Common Website Redesign Mistakes

Treating SEO as a final checklist

SEO decisions affect content, URLs, templates, internal links, rendering, and migration. Leaving SEO review until immediately before launch can make issues harder and more costly to resolve.

Rewriting everything without a baseline

A full rewrite may be justified, but it should be an informed decision. Preserve useful information and compare the new content against the pages it replaces.

Changing URLs for cosmetic reasons

A URL change creates migration work. Make it because the new structure materially improves clarity or architecture, not because the old slug uses one extra word.

Redirecting every old page to the homepage

Use relevant destinations or return an appropriate status when no equivalent exists. A homepage is not a universal replacement page.

Testing only the homepage

Templates, forms, articles, services, search, products, and account areas can fail differently. Test representative journeys.

Ignoring integrations

The visible frontend may work while CRM submissions, payments, analytics, search, or scheduled jobs fail behind it.

Launching without a rollback plan

A rollback plan should identify the version, owner, steps, conditions, and data implications. “We can restore it” is not a rollback procedure.

Measuring only rankings

Rankings can move without business improvement. Monitor qualified traffic, engagement, conversions, revenue, leads, crawlability, and operational outcomes.

When a Redesign Should Become a Modernisation Project

A redesign may expose underlying constraints that need more than new templates.

Consider broadening the project when:

• The CMS is unsupported or difficult to secure
• The frontend cannot meet performance requirements
• Releases depend on manual and undocumented steps
• Integrations are unreliable
• Content teams cannot publish safely
• The website depends on one person’s knowledge
• The site has become a business-critical application
• The architecture prevents new channels or workflows
• Technical debt makes small changes disproportionately expensive

Modernisation does not necessarily mean replacing everything. It may involve incremental changes, better boundaries, a new deployment process, a headless CMS, improved integrations, or a staged migration.

For organisations considering a decoupled content architecture, our guide to headless CMS architecture explains the benefits and operational responsibilities of separating content management from presentation.

How Ridiculous Engineering Can Help

Ridiculous Engineering helps organisations redesign and modernise websites without treating design, SEO, engineering, and operations as separate problems.

Depending on the situation, the work may include:

• Current-state website and technology assessment
• SEO and migration-risk review
• Content and URL inventory
• Information architecture and page-model design
• Headless CMS or composable architecture
• Frontend and backend engineering
• Integration and workflow development
• Performance and accessibility improvements
• Analytics and conversion tracking
• Deployment, monitoring, and rollback planning
• Post-launch support and technical ownership

The right starting point may be a redesign audit, a migration plan, a focused technical review, or a broader modernisation roadmap.

Our software consulting and delivery support can help when the redesign also raises questions about ownership, architecture, delivery, or technical risk.

FAQ

How do I redesign my website without losing SEO traffic?

You cannot guarantee unchanged organic traffic, but you can reduce the risk of avoidable losses.

Start with a baseline of organic performance, conversions, valuable URLs, backlinks, internal links, and indexation. Preserve or improve useful content, map old URLs to relevant new URLs, implement one-to-one redirects, check canonicals and robots directives, test the new website before launch, and monitor search and business performance after release.

What is the most important part of a website redesign checklist?

The most important parts are the current-site inventory, content and URL decisions, redirect map, technical SEO checks, analytics validation, staging tests, rollback plan, and post-launch monitoring. The exact priority depends on how much of the website’s structure and technology is changing.

How long does a website redesign take?

The timeline depends on the number of templates, content volume, integrations, design maturity, CMS, technical complexity, migration work, and stakeholder availability. A small visual refresh may be relatively contained, while a redesign combined with platform migration and new integrations is a larger software project.

Should I change my URLs during a redesign?

Only when the new structure materially improves information architecture, clarity, or maintainability. URL changes create migration work and risk, so keep valuable URLs unchanged when there is no strong reason to move them.

Do I need redirects for a website redesign?

You need redirects when old URLs change or are removed and a relevant replacement exists. Map old URLs to the closest useful new destination, avoid redirect chains, and do not redirect unrelated pages to the homepage simply to avoid 404 responses.

How do I test a website redesign before launch?

Use a private staging environment and test representative templates, content, URLs, redirects, forms, search, authentication, integrations, performance, accessibility, analytics, structured data, XML sitemaps, and robots directives. Crawl the staging site and compare it with the current-site inventory.

Can a redesign improve SEO?

Yes, if it improves content quality, information architecture, internal linking, crawlability, performance, accessibility, and user experience. A redesign can also reduce organic visibility if valuable content, URLs, links, or technical signals are removed without a migration plan.

What is the difference between a website redesign and website modernisation?

A redesign may focus on user experience, content, structure, presentation, or the technology supporting them. Website modernisation typically places greater emphasis on underlying technology, architecture, integrations, deployment, security, and operating practices. They may be delivered together, with the scope and objectives of each clearly defined.

When should I hire a website redesign company?

Consider a specialist partner when the redesign involves a new CMS, custom development, complex integrations, large-scale URL migration, technical SEO risk, performance problems, or limited internal capability. The right provider should be able to explain the technical and business tradeoffs, not only present visual concepts.