Website Redesign Checklist: What to Fix Before Paying for a New Website

Do not redesign a website simply because it looks old

An outdated appearance can be a valid reason to change a website.

But appearance should not be the only reason.

A website exists to perform business functions.

Those might include:

• generating leads;
• selling products;
• taking bookings;
• communicating trust;
• answering customer questions;
• attracting organic traffic;
• supporting paid campaigns;
• recruiting staff;
• providing customer services;
• or presenting information to stakeholders.

If the existing website performs these jobs well, a redesign should preserve what works.

If it does not, the project should identify why.

A visually impressive replacement that retains the same structural problems will produce limited improvement.

Start with baseline data before changing anything

Before redesigning a website, record how the current one performs.

Once the new website launches, you need something to compare it with.

Useful baseline data can include:

• organic clicks;
• organic impressions;
• conversion rate;
• lead volume;
• ecommerce revenue;
• top landing pages;
• Google Ads conversion rate;
• page speed;
• Core Web Vitals;
• form-completion rate;
• phone enquiries;
• booking conversions;
• bounce or engagement behaviour;
• traffic by device;
• traffic by acquisition channel.

The objective is not to collect every available metric.

Record the metrics connected to the website's actual purpose.

If the primary objective is lead generation, knowing that the website receives 20,000 monthly page views is less important than knowing which pages generate qualified enquiries.

Export your important analytics data

Do not assume all historical context will be obvious after launch.

Record:

• best-performing pages;
• highest-converting landing pages;
• main traffic sources;
• top organic landing pages;
• high-value referral traffic;
• conversion paths;
• mobile versus desktop performance.

This helps protect against decisions that might otherwise look harmless.

For example, an old article may appear visually poor but generate 30% of the website's organic traffic.

Deleting it because it does not fit the new design would be very different from improving it while preserving its URL and topic.

Audit Google Search Console before redesigning

Search Console should be reviewed before structural website changes.

Google recommends using Search Console during site moves and migrations and specifically advises monitoring indexing, crawling and search performance during the process.

Before the redesign, identify:

• pages receiving the most search clicks;
• pages receiving large numbers of impressions;
• important search queries;
• indexed pages;
• excluded pages;
• sitemap status;
• Core Web Vitals;
• manual actions;
• crawl issues.

This gives the project team a clearer picture of what currently matters to Google Search.

Create a complete URL inventory

One of the most important redesign tasks is identifying every existing URL.

That includes more than the pages visible in the main navigation.

A website may contain:

• service pages;
• articles;
• landing pages;
• PDFs;
• campaign pages;
• old product pages;
• category pages;
• location pages;
• author pages;
• downloadable resources;
• hidden conversion pages.

Create a list using multiple sources where possible:

• website crawler;
• XML sitemap;
• Search Console;
• analytics;
• CMS export;
• server logs;
• backlink tools.

No single source necessarily contains every URL.

Decide what happens to every important old URL

Each meaningful page should normally have an explicit outcome.

It might be:

Keep the URL unchanged

Move the content to a new URL

Merge it into another page

Redirect it

Remove it intentionally

Do not leave this decision until launch day.

A URL migration spreadsheet can contain:

The mapping becomes the basis of the redirect plan.

Avoid changing URLs unnecessarily

A redesign does not automatically require new URLs.

If a page already has:

• strong rankings;
• backlinks;
• historical authority;
• existing advertising links;
• bookmarks;
• good URL structure;

there should be a reason to change it.

Changing:

/website-maintenance-london

to:

/services/web/maintenance/support/

simply because the new CMS prefers another structure may create work without creating meaningful value.

URL changes introduce migration risk.

Preserve stable URLs where practical.

Create the redirect map before launch

When URLs do change, redirect old URLs directly to their closest relevant new destinations.

Google's site-move documentation recommends mapping old URLs to new URLs and redirecting directly to the final destination rather than creating unnecessary redirect chains.

For example:

Bad:

/old-service → /services-old → /services-new → /new-service

Better:

/old-service → /new-service

Redirects should preserve relevance.

Do not automatically redirect every deleted page to the homepage.

If an old PPC page about CRM automation is replaced, redirecting it to a generic homepage is less useful than sending visitors to the new CRM automation page.

Do not redesign and change everything at once without a reason

One common redesign mistake is simultaneously changing:

• CMS;
• hosting;
• domain;
• URL structure;
• navigation;
• written content;
• design;
• analytics;
• forms;
• CRM;
• SEO strategy.

This makes problems harder to diagnose.

If organic traffic falls after launch, which change caused it?

If conversions fall, was it:

• the new page layout;
• tracking;
• form design;
• traffic quality;
• changed content;
• or technical errors?

Sometimes large combined migrations are unavoidable.

But unnecessary simultaneous changes increase risk.

Audit the site's information architecture

Before designing individual pages, decide how the website should be structured.

Ask whether users can quickly understand:

• what the business provides;
• which service is relevant to them;
• where to find important information;
• what action to take next.

A website with eight overlapping services may need clearer hierarchy rather than simply a new menu style.

For example:

Services

• Web
• Website Maintenance
• SEO & AI Search Optimisation
• PPC & Google Ads
• Analytics & Tracking
• CRM & Automation
• AI Chatbots
• Security, Privacy & Accessibility

This helps both users and search engines understand relationships between topics.

Google's guidance continues to emphasise clear navigation and links that allow users and search engines to discover important pages.

Audit your navigation before redesigning it

Navigation decisions should reflect user priorities.

Review current analytics to understand:

• which navigation links receive clicks;
• which pages users search for;
• common landing pages;
• exit points;
• conversion paths.

Do not assume every existing navigation item deserves to remain.

But do not remove a high-value page simply because the navigation becomes visually cleaner without it.

Identify orphan pages

An orphan page has no meaningful internal links pointing to it.

These often appear after multiple redesigns and content changes.

An orphan page may still receive traffic through:

• Google;
• backlinks;
• old campaigns;
• bookmarks.

Before migration, identify them.

Then decide whether they should be:

• integrated into the new structure;
• redirected;
• consolidated;
• or retired.

Audit your best-performing content before rewriting it

Redesigns often trigger complete copy rewrites.

That can be useful, but existing search performance should be considered.

Suppose an SEO service page currently ranks well for several important commercial searches.

The redesign team completely rewrites it to make the page shorter and more visual.

The new copy contains half the detail.

Important subtopics disappear.

Internal links are removed.

The page title changes.

The URL changes.

That is no longer simply a design change.

It is a substantial SEO change.

Content should be improved deliberately, not removed simply to create more whitespace.

Identify content gaps before building templates

A redesign is an opportunity to improve content architecture.

Ask what customers need to know before they contact you.

For a service business this might include:

• what you provide;
• who it is for;
• how the process works;
• pricing approach;
• likely timelines;
• technologies used;
• FAQs;
• examples;
• risks;
• next steps.

Templates should accommodate useful content rather than forcing every service page into a rigid five-section visual layout.

Review title tags and metadata

A redesign frequently introduces new page templates.

This can accidentally create metadata problems.

Check how the new CMS will generate:

• page titles;
• meta descriptions;
• canonical tags;
• Open Graph metadata;
• robots directives.

Do not launch with every title formatted as:

Page Name | Company

without considering whether major service pages need more descriptive search titles.

Preserve heading structure

Designers sometimes use heading tags based on appearance rather than document structure.

For example:

• H1 used for a tiny decorative label;
• H3 used because it looks visually attractive;
• several H1s generated by reusable components;
• important headings rendered only as styled <div> elements.

Design and semantic structure should work together.

The redesign should have a clear page hierarchy that users, accessibility tools and search engines can interpret.

Audit mobile UX separately

A design can look excellent on a 27-inch desktop screen and perform poorly on a phone.

Mobile testing should not simply mean shrinking the browser window.

Test real tasks.

Can a mobile user:

• understand the main offer;
• access navigation;
• click the CTA;
• complete forms;
• select dropdown options;
• read tables;
• interact with sliders;
• dismiss cookie banners;
• use live chat;
• make a call?

Google's current page-experience guidance continues to recommend that content display and function well on mobile devices.

Audit forms before rebuilding them

Forms are one of the most commercially important components on a lead-generation website.

Document every existing form:

• contact;
• quote;
• newsletter;
• booking;
• downloads;
• applications;
• support;
• PPC landing pages.

For each one, record:

• form name;
• page;
• fields;
• destination;
• CRM integration;
• analytics event;
• Google Ads conversion;
• confirmation message;
• confirmation email;
• spam protection.

Otherwise, the new website may visually recreate the form while silently removing half the operational functionality.

Review form friction

The redesign is a good time to ask whether every field is necessary.

A business may currently request:

• name;
• email;
• telephone;
• company;
• job title;
• address;
• postcode;
• industry;
• employee count;
• budget;
• message.

Do you genuinely need all of that before the first conversation?

Sometimes yes.

Often no.

Reducing unnecessary friction can improve conversion.

But shorter is not automatically better.

A qualified B2B enquiry may require enough information to route the lead properly.

Design the form around the sales process, not around an arbitrary target number of fields.

Document CRM integrations

If the website sends leads into:

• HubSpot;
• Salesforce;
• Zoho;
• Pipedrive;
• another CRM;

document the integration before redesigning the form.

Record:

• endpoint;
• field mapping;
• lifecycle stage;
• contact owner;
• lead source;
• consent fields;
• hidden fields;
• lead ID;
• workflow triggers.

A form can appear to work successfully while the CRM integration behind it fails.

Audit current tracking before redesign

Before launch, document every analytics and advertising tag currently running.

Common systems include:

• GA4;
• Google Tag Manager;
• Google Ads;
• Meta Pixel;
• LinkedIn Insight Tag;
• Microsoft Advertising;
• call tracking;
• heatmaps;
• CRM tracking;
• consent management.

Use Google Tag Manager exports or equivalent documentation.

Do not assume the redesign agency automatically knows which tags matter.

Preserve Google Tag Manager correctly

If GTM is used, the container should normally remain consistent unless there is a deliberate reason to create a new one.

Replacing a website does not inherently require replacing the GTM container.

The new site should implement the container correctly and recreate the required data layer.

Define conversion events before development finishes

A redesign should not reach launch week before somebody asks:

“How are we going to track leads?”

Define conversion events during the project.

Examples:

generate_lead
form_submit
phone_click
booking_complete
purchase
newsletter_signup
download

Define required parameters as well.

For example:

lead_id
service
method
page_type
page_path
value
currency

This allows developers to implement the necessary data while building the website.

Test Google Ads conversions

Businesses running paid campaigns should treat this as a launch-critical requirement.

After redesign:

1. open Google Tag Manager Preview;
2. complete each conversion path;
3. inspect the event;
4. confirm Google Ads tags fire correctly;
5. check parameters;
6. verify deduplication where required;
7. test different consent states.

A beautiful new landing page that stops sending conversion data can damage campaign optimisation.

Review consent management during redesign

Cookie and privacy implementation is often copied from the old site without being reviewed.

That is an opportunity missed.

Document:

• CMP platform;
• consent categories;
• Google Consent Mode;
• tag behaviour;
• privacy links;
• cookie-policy links;
• preference controls.

Check what actually happens when somebody rejects optional cookies.

Do not judge the implementation only by whether a banner appears.

Audit accessibility before choosing design patterns

Accessibility should be considered while designing components, not added after launch.

Review:

• colour contrast;
• keyboard navigation;
• focus states;
• form labels;
• error messages;
• headings;
• image alt text;
• modal behaviour;
• interactive controls;
• text resizing;
• screen-reader semantics.

Some visual design patterns create unnecessary accessibility problems.

For example:

• low-contrast text;
• text placed over moving video;
• unlabeled icon buttons;
• hover-only navigation;
• non-standard custom form controls.

Designing accessibly from the beginning is usually easier than retrofitting accessibility later.

Audit performance before selecting the new technology stack

A redesign can make a site slower.

This is surprisingly common.

The new version may add:

• animation libraries;
• large background videos;
• multiple font files;
• heavy JavaScript;
• page-builder scripts;
• third-party widgets;
• more tracking;
• oversized imagery.

The design may look more modern while performance becomes worse.

Measure the current site before development.

Then define performance expectations for the new one.

Understand Core Web Vitals

Google currently defines Core Web Vitals as metrics measuring real-world loading performance, interactivity and visual stability.

They include:

• Largest Contentful Paint;
• Interaction to Next Paint;
• Cumulative Layout Shift.

Google also warns that strong Core Web Vitals alone do not guarantee search rankings and should be considered as part of broader page experience.

For a redesign, the important point is not chasing a perfect performance score.

It is preventing the new design from introducing unnecessary performance regressions.

Set a performance budget

A useful redesign requirement might specify limits or targets for:

• JavaScript;
• image size;
• font loading;
• LCP;
• INP;
• CLS.

A performance budget creates a constraint before the design becomes too heavy.

For example:

Instead of designing a 12 MB autoplay hero video and trying to optimise it later, the team knows from the beginning that it needs a lighter approach.

Choose images deliberately

Redesigns often use much larger imagery.

Plan:

• image dimensions;
• responsive images;
• compression;
• modern formats;
• lazy loading;
• hero-image priority.

A 4000-pixel image should not be sent unchanged to a 390-pixel mobile screen.

Review fonts

Custom fonts can contribute significantly to page weight and layout shift.

Ask:

• How many font families?
• How many weights?
• Do we need them all?
• Are they self-hosted or external?
• What fallback font is used?
• Does loading cause visible layout movement?

Typography is important to brand design, but loading eight font files may not be necessary.

Audit third-party scripts

Before rebuilding, list external scripts.

Examples:

• live chat;
• review widgets;
• heatmaps;
• embedded calendars;
• social widgets;
• CRM tracking;
• advertising pixels;
• analytics;
• A/B testing.

Ask whether each one is still needed.

Legacy websites often contain scripts installed years earlier for tools the company no longer uses.

A redesign is a good opportunity to remove them.

Do not install every possible plugin again

WordPress redesigns often inherit unnecessary plugins.

An old site may contain plugins for:

• redirects;
• image optimisation;
• caching;
• forms;
• SEO;
• backups;
• duplicate functionality;
• abandoned features.

Review each plugin rather than automatically cloning the old stack.

Ask:

What business or technical function does this perform?

If nobody can answer, investigate before migrating it.

Decide whether you actually need to change CMS

A redesign is often treated as an opportunity to change CMS.

Sometimes that is justified.

Reasons may include:

• unsupported technology;
• poor security;
• difficult editing;
• integration limitations;
• performance problems;
• licensing cost;
• development constraints.

But changing CMS adds migration complexity.

If WordPress already supports the organisation effectively, moving to another system simply because it is fashionable may not create enough value.

Likewise, organisations trapped in an unsuitable platform should not preserve it solely to avoid migration work.

The decision should follow requirements.

Consider editor experience

Website projects often focus entirely on visitors.

But somebody also has to manage the website.

Ask internal users:

• Can you publish content easily?
• Can you create landing pages?
• Can you update SEO fields?
• Can you edit forms?
• Can you manage redirects?
• Can you update menus?
• Do you need developers for routine changes?

A new website that performs well for visitors but makes every marketing change dependent on a developer creates ongoing cost.

Avoid unrestricted page builders

Flexibility is useful.

Unlimited flexibility can create inconsistency.

If every page editor can independently change:

• fonts;
• spacing;
• colours;
• button styles;
• layouts;

the website may lose design consistency quickly.

A component-based system often provides a better balance.

Editors can choose from approved elements without rebuilding the design system on every page.

Build reusable components around real content

Useful components might include:

• hero;
• service overview;
• benefits;
• comparison table;
• case study;
• testimonial;
• FAQ;
• process steps;
• CTA;
• article summary;
• related services.

Build these around actual content needs.

Do not create components purely because they looked attractive in a design file.

Audit the homepage objective

The homepage does not need to explain everything.

But it should answer essential questions quickly:

Who are you?

What do you provide?

Who do you help?

Why should somebody continue?

Where should they go next?

Many redesigns become overloaded with animations while these fundamental questions remain unclear.

Audit each service page

For every major service, ask:

• Is the service clearly defined?
• Does the page explain the problem it solves?
• Is the intended customer clear?
• Is the process explained?
• Are supporting services linked?
• Is there evidence?
• Is the CTA appropriate?
• Can someone understand the offer without speaking to sales?

This affects both SEO and conversion.

Improve CTAs before changing their colour

Conversion optimisation is sometimes reduced to visual button changes.

Before experimenting with button colours, consider whether the action itself is appropriate.

Weak:

Submit

Better:

Request a Website Review

Weak:

Learn More

Potentially better:

See Our Website Maintenance Services

The CTA should tell the user what happens next.

Map customer journeys

Different visitors may need different paths.

A new visitor researching SEO may want:

Article → SEO service → case study → consultation

An existing customer may want:

Homepage → support

A paid visitor may follow:

Google Ad → landing page → form

Map those journeys before finalising navigation.

Identify unnecessary steps

If a user currently needs to:

1. open Services;
2. open Digital Marketing;
3. open SEO;
4. open Search Optimisation;
5. find Contact;
6. open form;

there may be unnecessary friction.

The redesign should reduce needless steps around important tasks.

Decide how trust will be communicated

Businesses often redesign because the website no longer reflects their capability.

Trust can be supported through:

• client examples;
• reviews;
• case studies;
• accreditations;
• team expertise;
• process transparency;
• clear contact information;
• meaningful evidence.

Avoid filling the site with vague claims such as:

“World-class solutions.”

Specific evidence is stronger.

Audit old case studies

Existing case studies may contain useful proof but outdated:

• screenshots;
• statistics;
• branding;
• services.

Decide whether to:

• update them;
• keep them;
• consolidate them;
• remove them.

If a case study has strong backlinks or organic traffic, consider that before deleting it.

Audit backlinks before deleting URLs

Pages with external backlinks deserve special attention.

If another website links to an old resource that is removed without a redirect, part of that referral and SEO value may be lost.

Use backlink data alongside analytics and Search Console when deciding which URLs to preserve.

Create a content migration spreadsheet

For larger websites, use a structured plan.

Possible fields:

Old URL
New URL
Page type
Organic traffic
Backlinks
Keep/rewrite/remove
Redirect
Title
H1
Owner
Status

This reduces the chance of valuable content disappearing during migration.

Protect PPC landing pages

PPC pages are especially easy to forget because they may not appear in public navigation.

Audit all active advertising destinations.

For every Google Ads campaign, confirm:

• current final URL;
• replacement URL;
• page content;
• conversion event;
• tracking template;
• form functionality.

Do not launch a redesign and discover that active campaigns still point to deleted pages.

Update ads if URLs change

If landing-page URLs change, update advertising platforms deliberately.

Even when redirects exist, ads should generally point directly to the final appropriate URL rather than relying on unnecessary redirect hops.

Preserve campaign parameters

Check whether the new website correctly accepts:

• UTM parameters;
• click identifiers;
• tracking parameters.

Make sure redirect rules do not unnecessarily strip important campaign data.

Test analytics on staging

Before launch, verify that the staging version produces the intended data.

Use separate controls where needed so that development traffic does not contaminate live reporting.

Test:

• page views;
• form submissions;
• ecommerce events;
• CTA clicks;
• consent behaviour;
• data-layer variables.

Keep staging out of search results

Staging sites should normally not appear in public search results.

Use appropriate access controls and indexing restrictions.

Then confirm that these restrictions are not accidentally transferred to production.

One of the most damaging migration mistakes is launching the new site with a staging noindex directive still active.

Remove staging credentials from production workflows

Staging systems often use:

• test API keys;
• test payment environments;
• development webhooks;
• sandbox CRMs.

Create a launch checklist to switch each one deliberately.

Do not assume developers will remember every integration from memory.

Test the site before launch

A proper pre-launch QA process should include multiple areas.

Content

• missing pages;
• placeholder copy;
• incorrect contact details;
• broken images;
• spelling errors.

Technical

• 404s;
• redirects;
• canonical tags;
• robots directives;
• sitemap;
• HTTPS.

Conversion

• forms;
• bookings;
• checkout;
• telephone links;
• CRM integration.

Measurement

• GA4;
• GTM;
• Google Ads;
• other advertising platforms;
• consent signals.

UX

• navigation;
• search;
• mobile layout;
• keyboard navigation.

Performance

• page speed;
• Core Web Vitals;
• oversized resources.

Test on real devices

Browser emulation is useful.

It does not replace real-device testing completely.

Check common:

• iPhones;
• Android devices;
• tablets;
• desktops.

Test important browsers.

Pay particular attention to forms, menus, cookie banners and third-party widgets.

Test validation and error states

Do not test forms only with perfect data.

Try:

• missing required fields;
• invalid email;
• unusual characters;
• very long messages;
• duplicate submissions;
• failed network request.

The website should fail gracefully.

Test keyboard navigation

Use only the keyboard.

Can you:

• open navigation;
• move through links;
• see focus;
• complete the form;
• close overlays;
• operate interactive controls?

If not, accessibility needs attention.

Test the 404 page

Users will eventually encounter missing URLs.

The 404 page should:

• explain what happened;
• provide navigation;
• help visitors continue.

It should also return the correct HTTP status rather than pretending to be a normal 200 page.

Create a launch-day monitoring plan

The work does not end when DNS changes.

Monitor:

• uptime;
• server logs;
• Search Console;
• analytics;
• conversions;
• CRM leads;
• advertising landing pages;
• 404 errors;
• redirects.

Google specifically recommends monitoring Search Console during site moves, and notes that traffic fluctuations can occur while Google processes changed URLs.

Expect some migration processing time

Google says small to medium-sized websites can take several weeks for many URLs to move fully during migrations, while larger websites may take longer.

This does not mean every post-redesign traffic drop should be ignored.

It means migration performance should be monitored over an appropriate period and compared against known changes.

Investigate unexpected traffic drops

If organic traffic falls sharply, compare:

• Search Console;
• analytics;
• rankings;
• indexing;
• crawl errors;
• redirects;
• canonical tags;
• robots directives.

Google's own traffic-drop guidance recommends using the Search Console Performance report to identify the pattern and notes that migration errors can cause persistent issues after a site move.

Do not immediately assume:

“Google just needs time.”

Verify that the migration is technically correct.

Compare old and new conversion rates

A redesign can increase traffic while reducing conversions.

It can also reduce page views while increasing qualified leads.

Evaluate business outcomes.

Compare:

• lead conversion;
• qualified lead rate;
• ecommerce revenue;
• bookings;
• phone calls.

A redesign should be judged by what matters to the company.

Watch form volume immediately

If the business normally receives fifteen forms per weekday and receives zero the day after launch, investigate immediately.

Do not wait for monthly reporting.

Create alerts or operational checks for critical lead channels.

Monitor Google Ads after launch

Advertising campaigns can expose migration issues quickly.

Check:

• landing-page availability;
• conversion volume;
• CPA;
• disapprovals;
• tracking;
• mobile performance.

A significant change immediately after redesign should trigger investigation.

Re-submit or update sitemaps where appropriate

The production XML sitemap should contain current canonical URLs.

Remove obsolete URLs.

Submit or verify it in Search Console.

Google's migration guidance also recommends using Search Console as part of migration monitoring.

Keep redirects in place

Do not remove migration redirects after a few weeks merely because the new website is indexed.

Old URLs can remain in:

• external links;
• bookmarks;
• emails;
• documents;
• old advertising materials.

Maintain important permanent redirects long-term.

Do not use the redesign as an excuse to delete useful content

Minimalism can look attractive in a design presentation.

But a website is not a poster.

Customers need enough information to make decisions.

Search engines need enough context to understand pages.

Sales teams need the website to answer common questions.

Reduce repetition and weak content.

Do not reduce useful information simply because shorter pages look cleaner.

Decide what success means before launch

Create measurable redesign objectives.

Examples:

Increase qualified enquiries

Reduce mobile form abandonment

Improve Core Web Vitals

Reduce dependency on developers

Improve CRM lead attribution

Increase organic visibility for core services

Improve accessibility

Reduce maintenance overhead

Without defined outcomes, success becomes subjective.

The project risks ending with:

“Everyone thinks the website looks nicer.”

That is difficult to connect to commercial value.

Questions to ask a website redesign agency

Before appointing a supplier, ask:

1. How will you audit the existing site?
2. Will you crawl all current URLs?
3. How do you handle SEO migrations?
4. Who creates the redirect map?
5. How will existing rankings be protected?
6. How will analytics be implemented?
7. Who is responsible for Google Tag Manager?
8. How will conversions be tested?
9. How will CRM integrations be migrated?
10. How will mobile UX be tested?
11. What accessibility standards are considered?
12. How do you approach Core Web Vitals?
13. Will we receive a staging environment?
14. Who performs QA?
15. Who owns the website after launch?
16. Who owns hosting and domain accounts?
17. Can our team edit pages?
18. What happens after launch?
19. What support is included?
20. How is success measured?

The answers should be clear.

If SEO, analytics and redirects are described as things to “sort out after launch”, that should raise questions.

Redesign versus rebuild

Not every website needs a complete rebuild.

Sometimes improvements can be made through:

• new design system;
• page-template changes;
• navigation improvements;
• content rewrite;
• performance optimisation;
• CRO;
• better forms.

A full rebuild makes more sense when the existing technical foundation creates significant limitations.

For example:

• unsupported CMS;
• unreliable codebase;
• major performance problems;
• poor editor experience;
• security concerns;
• architecture cannot support requirements.

Do not rebuild technology that is working well merely because the frontend appearance needs improvement.

Redesign versus CRO

If the website already has:

• strong brand;
• good technical foundation;
• adequate performance;
• clear content;

but conversions are weak, conversion-rate optimisation may be more appropriate than a complete redesign.

CRO can test specific issues such as:

• value proposition;
• CTA;
• form length;
• pricing communication;
• page hierarchy;
• trust signals.

A full redesign changes many variables simultaneously.

That can make learning harder.

Redesign versus website maintenance

Sometimes the site does not need replacement at all.

It needs consistent maintenance.

For example:

• outdated content;
• broken plugins;
• poor performance;
• old images;
• technical errors.

These problems can often be fixed incrementally.

The correct project should match the actual problem.

A practical pre-redesign checklist

Before approving a redesign, confirm that you have:

Business

• Defined website objectives.
• Identified primary conversions.
• Recorded current performance.
• Identified target audiences.

SEO

• Exported Search Console data.
• Crawled current URLs.
• Identified top organic pages.
• Reviewed backlinks.
• Created redirect mapping.
• Reviewed internal linking.
• Planned sitemap changes.

Content

• Audited existing pages.
• Identified content worth preserving.
• Identified missing topics.
• Assigned content owners.
• Planned metadata.

UX

• Reviewed navigation.
• Tested mobile journeys.
• Audited forms.
• Identified conversion friction.
• Mapped important user journeys.

Analytics

• Documented GA4.
• Documented GTM.
• Listed conversion events.
• Listed advertising tags.
• Planned data-layer requirements.

CRM

• Documented form integrations.
• Defined field mapping.
• Preserved attribution fields.
• Tested lead routing.

Performance

• Recorded existing Core Web Vitals.
• Defined new performance expectations.
• Audited scripts.
• Audited images and fonts.

Accessibility

• Reviewed contrast.
• Planned keyboard navigation.
• Planned semantic components.
• Considered form accessibility.

Infrastructure

• Confirmed domain ownership.
• Confirmed hosting.
• Confirmed DNS.
• Confirmed SSL.
• Prepared backups.

Launch

• Created QA checklist.
• Tested redirects.
• Tested forms.
• Tested analytics.
• Tested ads.
• Tested CRM.
• Prepared monitoring.

If several of these are missing, the project may not yet be ready for launch.

The most expensive redesign mistakes usually happen before development

Developers can build what they are asked to build.

The bigger risk is asking them to build the wrong thing.

If the project begins without understanding:

• current SEO value;
• conversion data;
• CRM workflows;
• customer journeys;
• technical dependencies;

important decisions may be made based primarily on visual preference.

By the time problems appear, substantial development work may already be complete.

A good redesign therefore invests time in discovery before design.

A redesign should improve the system, not only the interface

A modern business website sits between multiple systems.

It may connect:

SEO

Google Ads

Analytics

CRM

Email

Automation

Customer support

AI tools

The redesign should consider those connections.

For example, improving a form may require changes to:

• frontend UX;
• data layer;
• GTM;
• CRM;
• lead routing;
• automated email;
• Google Ads tracking.

Looking only at the visual component misses most of the system.

The best redesign preserves what is working and fixes what is not

A redesign should not erase the history of a successful website.

It should build on it.

Keep:

• useful URLs;
• strong content;
• backlinks;
• successful customer journeys;
• working tracking;
• reliable integrations.

Improve:

• weak design;
• poor navigation;
• outdated content;
• slow performance;
• unclear conversion paths;
• inaccessible components;
• technical debt.

Remove:

• obsolete technology;
• unnecessary scripts;
• duplicate content;
• dead pages;
• unused integrations.

The process should be selective rather than destructive.

What businesses should do before requesting redesign quotes

Before asking agencies:

“How much does a new website cost?”

prepare a clearer brief.

Include:

• what the current website does;
• what is not working;
• business objectives;
• required integrations;
• current CMS;
• preferred CMS if relevant;
• approximate page count;
• key customer journeys;
• conversion requirements;
• SEO importance;
• performance requirements;
• accessibility expectations;
• future plans.

This allows suppliers to price the actual project rather than making assumptions.

A website redesign is a migration project as well as a design project

This is the central point.

If your existing website already has:

• traffic;
• rankings;
• backlinks;
• analytics;
• conversions;
• customers;
• CRM integrations;

then a redesign is not simply:

old design → new design

It is:

existing digital system → replacement digital system

That transition needs to protect valuable assets while introducing improvements.

Google's own site-migration guidance reflects this reality by emphasising URL mapping, redirects, monitoring and Search Console throughout moves and structural changes.

What to fix before paying for the redesign

Before development begins, try to answer these questions:

Which existing pages generate business?

Which pages generate organic traffic?

Which URLs have external links?

Which forms are commercially important?

Which conversions are being tracked?

Which CRM workflows depend on the website?

Which customer journeys currently fail?

Which design problems actually affect usability?

Which technical problems affect performance?

What should be measurably better after launch?

If those answers are documented, the redesign has a much stronger foundation.

If they are unknown, the first phase should probably be an audit rather than a design mock-up.

A new website can create significant value.

But the value comes from improving how the website supports the business, not merely replacing one visual style with another.

London Digital Works provides web, website maintenance, SEO/AIO, PPC, analytics, tracking and CRM automation services for businesses planning website improvements or full redesigns.

For organisations preparing to replace an established website, auditing SEO, conversion tracking, integrations, performance and customer journeys before development can significantly reduce migration risk and help ensure the new website improves more than appearance.

Sources

Google Search Central — Site Moves and Migrations Google's current guidance on planning URL changes, redirects, monitoring and Search Console during website migrations.

Google Search Central — URL Mapping and Redirects Google's site-migration guidance recommending direct redirects to final destination URLs rather than unnecessary redirect chains.

Google Search Central — Understanding Page Experience Google's guidance covering Core Web Vitals, HTTPS, mobile usability and broader page experience.

Google Search Central — Core Web Vitals Google's documentation defining Core Web Vitals as measurements of real-world loading performance, interactivity and visual stability.

Google Search Central — Search Console Google's documentation explaining how Search Console can be used to monitor indexing, page performance and real-user Core Web Vitals.

Google Search Central — Debugging Search Traffic Drops Google's current guidance on investigating search-traffic declines and diagnosing migration-related issues.

Google Search Central — Requesting Recrawling Google guidance on requesting indexing after significant page updates or site moves.

Google Search Central — Technical SEO Guidance Google's overview of technical SEO areas including site moves, crawling, Search Console and ongoing website management.