A website redesign should improve the way your business is presented, make the site easier to use and give potential customers clearer reasons to contact you. It should not remove pages that already bring in traffic, break links that Google has been following for years or stop your enquiry forms from working.

The design itself is rarely the cause of a serious loss in search visibility. Problems usually appear because important content has been removed, URLs have changed without suitable redirects, internal links have broken or technical settings from the development site have been carried over to the live version.

A well-managed redesign starts by recording what already works. The new website can then improve the weaker parts without throwing away the rankings, links and enquiries the existing site has built up.

A Redesign and a Website Migration Are Not Always the Same Thing

The level of SEO risk depends on what is changing.

A visual redesign may keep the same domain, pages, URLs and content while changing the layout, colours and branding. This can still affect usability and page speed, but it is usually less disruptive than rebuilding the entire site.

A larger redesign may involve:

• Moving to a different content management system
• Rebuilding the website in WordPress
• Changing the navigation and page structure
• Rewriting or merging service pages
• Replacing old URL addresses
• Moving to a new hosting provider
• Changing from HTTP to HTTPS
• Moving to a different domain
• Removing outdated products, services or locations

Once URLs, content or platforms change, the project also becomes a website migration. That needs more than design approval and a final visual check.

Google recommends preparing the new site, mapping old URLs to their replacements, implementing redirects and monitoring both versions after a move. Google also warns that some ranking fluctuation can occur while its systems recrawl and reprocess the changed pages.

A designer does not need to keep every part of the old website. The important point is to understand what each change may affect before making it.

---

Record What the Current Website Is Achieving

It is difficult to protect a website if nobody has recorded its current performance.

Before redesign work begins, create a baseline showing which pages receive traffic, appear in search results, attract links and generate enquiries. This should happen before content is rewritten or the old site becomes unavailable.

Useful information to record includes:

Google Search Console can show queries, impressions, clicks, indexed pages and crawling problems. Analytics may provide additional information about landing pages, user behaviour and completed enquiries.

Do not rely only on a list of keywords supplied by an SEO tool. A page ranking at position two for an irrelevant phrase may be less valuable than a page at position eight that regularly generates suitable enquiries.

The redesign should protect commercial value, not just a collection of ranking positions.

Decide What Should Stay, Change, Merge or Go

Every existing page should have a planned outcome.

A practical content review usually places each URL into one of four groups:

1. Keep: The page remains available at the same URL.
2. Improve: The URL remains, but the content or layout is updated.
3. Merge: Several overlapping pages are combined into one stronger page.
4. Remove: The page no longer serves a useful purpose and has no suitable replacement.

Pages that already rank, receive links or generate enquiries should not be removed simply because they do not fit neatly into the new design.

A common redesign mistake is to replace detailed service pages with a shorter, more visual website. The new version may look cleaner, but Google and potential customers are left with less information.

For example, an existing service page might explain:

• What the service includes
• Who it is intended for
• The problems it solves
• How the process works
• Relevant prices or timescales
• Common customer questions
• The areas the business covers
• What someone should do next

Reducing that to a heading, a photograph and two short paragraphs may weaken the page considerably.

This does not mean every old sentence must remain. Outdated wording, repetition and weak content can be rewritten. The aim is to preserve the useful subject matter and intent while improving clarity.

---

Keep Important URLs Where It Makes Sense

The safest URL change is often no URL change at all.

If an existing page has a clear, readable address and still covers the same subject, keeping that address avoids an unnecessary redirect and makes the transition simpler.

Changing a URL because the new version looks slightly neater is not always worth the disruption. A page at:

/commercial-window-cleaning/

does not need to become:

/services/commercial-exterior-window-cleaning-solutions/

unless the new structure provides a genuine benefit.

There are valid reasons to change URLs. The old structure may be confusing, contain outdated service names or use addresses created automatically by an old system. Several weak pages may also need to be consolidated.

Where a URL changes, its old address should be matched to the most relevant new page.

Create the Redirect Map Before Launch

A redirect tells browsers and search engines that a page has moved.

For a permanent URL change, Google recommends using a permanent server-side redirect, normally a 301 or 308 response.

The redirect map should contain at least:

Each old page should normally redirect to the closest relevant replacement.

Do not send every removed page to the homepage. Someone following a link to a specific service does not expect to arrive at a general homepage with no explanation. Google also warns that large numbers of irrelevant redirects may be treated as soft 404 errors.

Redirects should also lead directly to the final destination. Avoid arrangements such as:

Old page → temporary page → revised page → final page

These redirect chains make the journey slower and create more places for something to fail.

Google advises keeping site-move redirects in place for at least a year and, from a user perspective, potentially for longer. Internal links and important external profiles should still be updated to point directly to the new addresses.

Do Not Delete Pages Merely Because They Look Old

A page can look dated while still performing an important job.

Before removing one, check whether it:

• Appears in Google Search Console
• Receives visits from other websites
• Ranks for a useful service or question
• Supports another page through internal links
• Generates contact-form submissions
• Contains material that should be moved elsewhere
• Is used as a Google Ads landing page
• Appears in printed material, emails or social profiles

Some pages should be removed. An expired promotion, discontinued service or inaccurate article may have no continuing value.

Where no suitable replacement exists, returning a proper 404 or 410 response is often more accurate than sending visitors to an unrelated page.

Where several pages cover the same subject, they may be merged. The combined page must properly represent the material being removed, rather than mentioning it briefly to justify a redirect.

---

Protect the Meaning of Pages That Already Rank

Search performance is connected to what a page covers, not only its address.

A redesign can retain the exact same URL and still lose visibility if the content changes significantly.

Important elements to review include:

• The main subject of the page
• The service, product or question it addresses
• The title shown in the browser and search results
• The main heading
• Supporting subheadings
• Explanatory content
• Internal links
• Images and image descriptions
• Structured data
• Contact details and calls to action

Do not copy every heading simply because it existed before. Instead, understand why the page was relevant.

Suppose a page ranks for searches relating to emergency boiler repairs in a particular area. Replacing it with a general heating-services page may remove the specific information that made the original useful.

The redesigned page can be better written and better organised, but it should still answer the same need unless there is a deliberate reason to change direction.

Use a Private Development or Staging Website Carefully

Most redesigns are built on a staging website before they replace the live version.

The staging site should not compete with the existing website in search results. It may contain copied content, unfinished pages and test information that should not become public.

Password protection is usually the strongest way to keep a development website private. A noindex instruction can also tell supported search engines not to index accessible pages.

A robots.txt block is not the same as a noindex instruction. Google explains that robots.txt controls crawling and should not be relied upon to keep a web page out of search results. A blocked URL may still appear if Google discovers it through links elsewhere.

The opposite problem occurs at launch. A development site may have been protected correctly, but the noindex instruction is then left active when it becomes the live website.

This can remove the new pages from Google even though the website works normally for visitors.

Before launch, check:

• Site-wide indexing settings
• Page-level robots instructions
• HTTP X-Robots-Tag headers
• Robots.txt rules
• Password protection
• Canonical tags
• Sitemap addresses

Do not assume that changing a WordPress visibility setting has corrected every other indexing instruction.

---

Carry the Main SEO Elements Across

A redesign should include a comparison between the old and new pages.

The new site needs its own carefully written metadata, headings and internal links, but valuable elements should not disappear unnoticed.

Page titles and descriptions

Retain the main relevance of successful page titles while improving any weak or outdated wording.

Meta descriptions are not guaranteed to be displayed exactly as written, but they can help describe the page clearly to potential visitors.

Heading structure

Each page should have one clear main heading, followed by useful subheadings that organise the content.

Changing the visual style of a heading should not accidentally turn every large line of text into an H1.

Canonical tags

Canonical tags should point to the correct live URL. A staging-domain canonical, an old HTTP address or an unrelated page can send conflicting signals.

Google advises using consistent canonical signals, including internal links and sitemap entries that point to the preferred version.

Internal links

Links within the new site should point directly to live, final URLs.

Do not leave internal links passing through old addresses simply because redirects are available. Redirects are a safety net for changed URLs, not a replacement for updating the website properly.

Internal links also help visitors discover related services and help search engines understand how pages are connected.

Structured data

Any useful structured data should be recreated accurately on the new site.

The details must match what visitors can see. Do not retain old business information, prices, reviews or service details merely because they were present in the previous code.

Images and media

Important images, PDFs and downloadable documents can receive traffic and external links of their own.

Move them carefully, update embedded addresses and redirect old file URLs where a suitable new version exists.

Protect Enquiries as Carefully as Rankings

A redesign can maintain its Google visibility and still perform worse commercially.

This happens when attention is given to rankings while the new enquiry journey receives only a quick visual check.

Test every way a potential customer can make contact:

• Contact forms
• Quote-request forms
• Telephone links
• Email links
• Booking systems
• Live chat
• Checkout pages
• Account registrations
• Newsletter forms
• File uploads
• Payment confirmations

Submit each form and confirm that the message reaches the correct destination.

A form displaying a success message does not prove that the email was delivered. Check the receiving mailbox, spam protection, confirmation emails and any customer relationship management system connected to it.

Telephone links also need checking. The visible number may be correct while the underlying tel: link still calls an old number.

Other commercial details to verify include:

• Business name
• Address
• Opening hours
• Email addresses
• Service areas
• Pricing
• Legal company information
• Privacy notices
• Cookie controls

These details may appear in page content, the footer, structured data, forms and reusable website templates. Correcting one visible instance does not necessarily correct all of them.

Preserve Analytics and Conversion Tracking

A redesigned website should not create a gap in reporting.

Check that the correct analytics and conversion scripts are present on the live site. Depending on the business, these may include:

• Google Analytics
• Google Search Console verification
• Google Ads conversion tracking
• Telephone-call tracking
• Form-submission events
• Ecommerce tracking
• Cookie-consent controls
• Social advertising pixels
• CRM integrations

Test whether events are being recorded rather than checking only whether the tracking code exists.

Thank-you pages and confirmation messages may change during a rebuild. If a conversion depends on a specific page address, the tracking setup may need to change with it.

Paid advertising also needs attention. Update campaign landing pages if their URLs have changed, and confirm that those pages still match the advert and keyword intent.

Google specifically recommends updating advertising campaigns, internal links and profile links after a site move.

---

Test the New Website Before It Replaces the Old One

Launch day should confirm a plan that has already been tested. It should not be the first time anyone checks the finished website.

A proper pre-launch review should cover several areas.

Content checks

• All required pages are present
• Important content has been transferred
• Headings are clear and correctly ordered
• Titles and descriptions are in place
• Old placeholder content has been removed
• Contact and business details are accurate
• Images have suitable descriptions where needed
• Policies and legal pages are current

Technical checks

• Old and new URLs have been mapped
• Redirect rules are prepared
• Canonical tags use live addresses
• The XML sitemap contains the intended pages
• Indexable pages are not marked noindex
• Robots.txt does not block important areas
• Broken internal links have been corrected
• Missing pages return the correct status
• HTTPS works throughout the site
• Mixed-content warnings have been removed

Usability checks

• Navigation works on mobile and desktop
• Buttons are large enough to use on a phone
• Text remains readable at different screen sizes
• Forms can be completed without layout problems
• Pop-ups can be closed
• Important information is not hidden on mobile
• Keyboard navigation has been considered
• Pages do not shift or jump excessively while loading

Commercial checks

• Forms deliver messages
• Phone links call the correct number
• Email links use the correct address
• Payments and bookings complete successfully
• Analytics records visits
• Conversion events are triggered correctly
• Google Ads landing pages remain available
• Confirmation messages contain accurate information

Resilience checks

• A full backup exists
• The old site can be restored if necessary
• Hosting and DNS access are available
• The person responsible for fixing launch problems is identified
• Error logs can be reviewed
• Caches can be cleared
• The site has enough server capacity

The old website should remain available until the new version is ready. Replacing it with a temporary holding page for several weeks creates an unnecessary interruption for customers and search engines.

Launch During a Quieter Period

There is no perfect time to launch a redesigned website, but avoid choosing the busiest sales period unless there is a strong reason.

A quieter period gives the developer time to check the live version and correct problems without affecting as many customers.

For many small business websites, a controlled launch will involve:

1. Taking a final backup.
2. Confirming the URL and redirect map.
3. Moving the approved site to the live environment.
4. Removing development indexing restrictions.
5. Activating permanent redirects.
6. Testing a representative sample of old URLs.
7. Checking forms and contact details.
8. Crawling the live site for errors.
9. Submitting or checking the new sitemap.
10. Reviewing Search Console and analytics.
11. Clearing website, server and CDN caches.
12. Testing the site on a device not used during development.

Where the domain changes, both the old and new properties should be verified in Search Console. Google also provides a Change of Address process for eligible domain moves.

A straightforward redesign using the same URLs and domain does not need to be treated like a domain migration. The launch process should match the actual changes being made.

Monitor the Website After Launch

The work is not finished when the homepage loads correctly.

Some problems only appear after search engines and real visitors begin moving through the site.

During the first days and weeks, monitor:

• Organic clicks and impressions
• Important page rankings
• Page-indexing reports
• Submitted and indexed sitemap URLs
• 404 and server errors
• Redirect behaviour
• Form submissions
• Telephone and email enquiries
• Analytics events
• Paid advertising conversions
• Page speed and server response
• Security and uptime alerts

Google says that a small or medium-sized website may take a few weeks for most moved pages to be processed, while larger sites can take longer. Temporary movement in search visibility is therefore possible, especially where URLs or domains have changed.

This does not mean every decline should be ignored.

A sudden loss affecting the whole website may indicate a site-wide problem, such as a noindex instruction, robots block, server failure or incorrect canonical setup.

A decline affecting one section may point to removed content, broken internal links, missing redirects or a changed page purpose.

Monitor individual pages and queries rather than relying entirely on the website’s overall average position. Google itself advises concentrating on impressions and clicks rather than treating an absolute average ranking as the sole measure of success.

What to Check if Rankings Fall After a Redesign

Do not immediately start rewriting every page.

First, identify the scale and pattern of the change.

Check whether the page is still available

Open the old and new URLs. Confirm that the old page redirects to the intended replacement and that the new page returns a successful response.

Inspect the page in Search Console

The URL Inspection tool can show the current index status and whether Google can access the live page. It can also help identify canonical and indexing problems.

Compare the old and new content

Check whether useful sections, headings and internal links were removed.

The new page may technically exist but no longer answer the searches associated with its predecessor.

Review the canonical tag

Confirm that it points to the live version of the same page rather than the staging site, homepage or old domain.

Look for noindex instructions

Check page source, SEO-plugin settings and HTTP headers.

Test the redirects

Confirm that permanent redirects lead directly to relevant working pages.

Review the sitemap

The sitemap should list live canonical URLs, not old pages, redirects or staging addresses.

Check internal links

Important pages may have become difficult to find because the new navigation no longer links to them.

Check server performance

Repeated server errors or severe performance problems can interfere with crawling and frustrate visitors.

Review the date of the change

Compare the traffic decline with the actual launch date. Do not assume every movement around the same period was caused by the redesign.

Once the likely cause is understood, correct that problem and monitor the result. Repeated large-scale changes can make diagnosis harder.

---

Questions to Ask Before Hiring Someone for a Website Redesign

A business owner should not be expected to configure redirects or inspect canonical tags personally. The supplier should still be able to explain how these matters will be handled.

Before agreeing to a redesign, ask:

• Will you review the current website before removing or changing pages?
• Will you check which pages receive traffic and enquiries?
• Are existing URLs being retained where possible?
• Who will create and test the redirect map?
• How will important content be transferred?
• Will the development site be kept out of search results?
• Will titles, headings, canonicals and structured data be reviewed?
• Who will test forms, phone links and email delivery?
• Will analytics and conversion tracking be checked?
• What happens if something goes wrong at launch?
• Will the site be monitored after it goes live?
• Is SEO migration included in the quote or charged separately?
• Who owns and controls the website, domain and hosting?
• Will you receive access to the finished site?

Vague assurances that “SEO will be preserved” are not enough. The proposal should explain which migration and testing work is included.

A Redesign Should Improve More Than Appearance

Protecting existing visibility does not mean freezing the website in its current form.

A redesign is a chance to correct problems that have been limiting the business, including:

• Confusing navigation
• Weak service pages
• Poor mobile layouts
• Slow loading
• Unclear calls to action
• Difficult content editing
• Unreliable forms
• Outdated branding
• Inconsistent contact details
• Unnecessary plugins
• Weak internal linking
• Pages that compete with each other
• Missing tracking

The right aim is not to reproduce the old website with a different colour scheme. It is to understand what should be preserved, fix what is holding the site back and launch the replacement without creating avoidable disruption.