Can you redesign your website without losing Google traffic?

Your old website may look dated and still bring in good customers. Before replacing it, find out what is worth keeping. SEO, or Search Engine Optimisation, includes helping search engines find and understand those pages.

These eight checks are for an existing small-business site getting a new design or platform. They are not a guarantee against traffic changes. Google warns that significant changes can cause temporary ranking fluctuations in its site-move guidance.

1. Which pages already bring people to your business?

Save a record of your useful pages, search visits and genuine enquiries before anyone replaces the site. This gives you something concrete to compare after launch.

In Google Search Console, Google's website search-reporting tool, the Performance report shows search clicks and the queries people used. Save the pages report for a recent period, such as the last three months. Note seasonal peaks separately.

Add your own business knowledge. Which page do you send with quotes? Which guide answers a common customer question? A page with modest traffic may still matter if it helps people choose your most valuable service.

Keep a simple sheet with the page address, purpose, search clicks and planned action. Record calls and quote requests separately; a search click is not an enquiry.

2. Can your existing page addresses stay the same?

Keep a useful page's existing URL, meaning its web address, when there is no practical reason to change it. A new colour scheme does not require a new address.

Ask your designer to compare the complete old and proposed addresses. A platform change might remove .html, add a folder or change the final slash. Those are address changes even if the menu still says “Services”.

Our practical starting point is to separate necessary changes from cosmetic ones. Keep working addresses where possible, and document the exceptions before building. Discuss this alongside the layout when planning a small-business website, not as a last-minute launch task.

3. Where will each changed address send visitors?

Give every moved page a relevant destination and test the connection. A redirect automatically sends someone from an old address to its replacement.

Google recommends a permanent server-side redirect when a page moves permanently. Your developer may call this a 301 or 308. Ask them to confirm both the destination and that permanent status.

For an imaginary gardening business, a page plan might look like this:

• /garden-care.html stays at the same address: no redirect needed.
• /hedges.html moves to /hedge-trimming.html: redirect to that service.
• /old-offer.html has no replacement: review whether it should be removed.

Do not send every old page to the homepage. Google's migration guidance warns against irrelevant redirects. It recommends keeping redirects generally for at least a year. Agree who will maintain them before cancelling old hosting.

4. Are the useful answers still on the new pages?

Carry forward accurate service details and customer answers, even when you simplify the layout. A cleaner page should not leave people guessing what you actually do.

Compare old and new versions of each important service page. Can someone still find the service area, what is included, how pricing works and how to request a quote? Correct outdated information instead of copying everything without review.

For example, replacing a detailed hedge-trimming page with a large garden photo and “Beautiful spaces, made simple” removes answers a customer needs. Keep the useful explanation beneath the new design.

Check the page title and main heading too. “Hedge trimming in Hamilton” explains more than “What we do”. An xEO review of your existing site can help identify information worth carrying forward.

5. Will Google be allowed to read the finished site?

Check that launch does not carry over settings meant to hide the unfinished site. Being able to open a page yourself does not prove Google can include it in search.

A noindex instruction tells supporting search engines not to index a page, meaning include it in their searchable collection. A robots.txt rule can instead stop a crawler from fetching it. Google explains that these controls work differently.

Ask your developer to check both page settings and server response headers for accidental noindex, plus crawling rules and leftover password protection. Remove restrictions from intended public pages only; keep private areas private.

Once live, use Search Console's URL Inspection live test on key pages. A successful test confirms access, not guaranteed indexing or rankings.

6. Do the sitemap and links use the final addresses?

Check that menus, page links and the sitemap all point to the intended live pages. A sitemap is a file listing URLs you want search engines to discover.

Ask your developer to check canonical tags too. A canonical tag identifies the preferred address for duplicate or similar content. It should not accidentally point to a preview site. Google's canonical guidance explains why these signals should agree.

Submit the updated sitemap in Search Console after launch. Sitemap submission helps discovery; it does not guarantee indexing.

A redesign on the same domain does not need Google's Change of Address tool. If the domain itself changes, ask your developer to assess that separate migration step.

7. Can a customer still contact you on a phone?

Complete a real enquiry journey on the replacement site before approving launch. Protecting search visits is only part of the job; customers must still reach you.

Start on a service page, not the homepage. On a phone, read the offer, tap the contact button, fill in the form and check that the message reaches the correct inbox. Test any booking link and confirm that the displayed phone number is correct.

Repeat the test on the live domain. A preview can behave differently. Label test enquiries clearly so nobody mistakes them for customers. If the journey feels unclear, use our website enquiry checklist to review it.

8. Who will check the website after launch?

Name the person responsible for launch checks, fixes and follow-up before setting the launch date. Keep a private backup and an agreed way to restore a working site.

Our suggested routine is to test key pages and enquiries immediately, then review search data weekly during the first month. Compare similar periods and note holidays, promotions or seasonal demand. One quiet day is not enough to judge a redesign.

If enquiries stop, check the contact route. If one service loses search visits, inspect that page and its old address. If visits disappear across the site, check public access and launch settings promptly. Keep a dated record of changes and fixes.

What else should you know before a website redesign?

You can usually keep your domain, but keep backups and agree how moved pages will work.

Do I need a new domain for a website redesign?

No. Your domain is your website's main address, and a new design can usually use the existing one. Keep it unless there is a clear business reason to change it. A domain move adds work, including redirects, account checks and updates to links that customers already use.

Do unchanged page addresses need redirects?

No. If a page keeps exactly the same address and still opens normally, it does not need a redirect just because its design changed. Redirects are for addresses that move. Check the full address, including the domain and page ending, rather than comparing only the words in the menu.

Should I delete my old website immediately?

Keep a private backup of the old website and its settings before launch. Do not leave two public versions competing for customers. Before cancelling old hosting, ask which service will run any redirects and whether email depends on that account. Keep access until those arrangements are tested and documented.

How long will Google rankings take to settle after a redesign?

There is no reliable recovery date for an individual website. The effect depends on what changed and whether anything broke. Compare page-level search clicks and genuine enquiries with your earlier records. Investigate missing pages, blocked access and failed redirects promptly instead of treating every drop as something to wait out.