If your Google traffic dropped after a website redesign, start with the pages and customer tasks that changed. A broken redirect can be tested immediately. A fall in search clicks needs a dated comparison before you can explain it. Keep those two investigations connected without assuming that every fall was caused by the redesign.
This guide is for a UK business that has already launched its replacement site. If you are still preparing the move, use the website redesign migration checklist. Here, the output is a recovery brief: affected URLs, observed faults, responsible people and the checks needed to close the work.
Confirm what fell and when
Write down the launch date, deployment changes and the first date of the reported decline. Keep any earlier URL list, approved content and reporting export. A recollection that the old website “got more traffic” is a useful starting question, but it cannot identify the missing page or failed journey.
Use the source that answers the question:
| Signal | Investigation after a redesign |
|---|---|
| Search Console clicks fell | Compare equivalent complete periods and the affected old/new page group. Keep country, search type and other filters consistent. |
| Analytics visits fell | Check whether tracking, consent, redirects or the measured property changed alongside the website. |
| Received enquiries fell | Test the public contact journey and check the agreed destination, then review whether visits match the services offered. |
Include the old and new URLs in the comparison. Looking only at the former address can hide activity attributed to its replacement. For the wider reporting setup, use the small-business SEO measurement guide.
Build one old-to-new URL record
The following decorating-business example is a teaching fixture, not a customer case study or a report of Nolixia's traffic. Its fictional paths show why different failures need different owners. We checked the route responses in an isolated example on 2 November 2026; no live business website was changed.
| URL or task | Evidence in the example | Decision |
|---|---|---|
| Old /decorating address | A permanent redirect leads to the homepage, although an interior-decorating replacement exists | Correct the destination after confirming the replacement answers the old page's task |
| New /services/interior-decorating page | Returns 200 with the intended interior-decorating heading and contact link | Retain the useful page and check incoming routes to it |
| Existing commercial-decorating page | Returns 503 because its content service is temporarily unavailable | Investigate the service failure; do not describe a temporary outage as permanent deletion |
| Withdrawn offer with no replacement | Returns 410 in this example | Record the intentional retirement and remove misleading current-service links |
The incorrect destination is a demonstrated routing defect. It is not proof of how much Google traffic that defect would lose. Likewise, a 200 response establishes successful delivery of the example response, not a search ranking.
Google's site-move guidance recommends matching moved URLs to their relevant replacements. It also explains that visibility can fluctuate as changes are processed. A useful investigation checks both the implementation and the subsequent search evidence.
Turn a fault into work someone can accept
Here is a completed specification for the first row. Adapt the fields to your own website rather than copying its destination.
| Field | Illustrative repair brief |
|---|---|
| Issue | MIG-01: an old interior-decorating address sends visitors to an unrelated general page |
| Expected customer outcome | A visitor using the old address reaches the corresponding current service and can request the right work |
| Agreed change | Update the permanent redirect to /services/interior-decorating; retain the existing service content |
| Dependencies | Business owner approves the replacement; developer checks whether another rule overrides the destination |
| Acceptance | Check the old address's response and destination; open the final page signed out; verify its main information and contact route |
| Recovery boundary | Record the previous routing rule and how to reverse this specific change without rolling back unrelated content or enquiries |
In the controlled example, the destination changed from the homepage to the intended service page. That closes the example's routing check. Search reprocessing and later enquiries remain separate outcomes.
For a more detailed handover across several issues, use the SEO-audit developer brief. It helps turn accepted findings into sequenced changes rather than another general report.
Investigate pages without an obvious routing fault
For an important page that still opens correctly, compare the previous and current service explanation, headings, media and useful links. Establish whether approved content disappeared or whether a new template serves only part of it. Ask for evidence from the affected page before commissioning a site-wide rewrite.
Inspect an important URL in Search Console and keep the indexed information alongside a current live test. Google's URL Inspection documentation explains that these answer different questions. A live pass does not show that the new version has already been indexed or selected for a particular search.
If the intended and selected canonical differ, continue with the canonical comparison worksheet. If the website itself still serves an old or broken version, assign that publishing or application fault first.
Separate repair evidence from a recovery claim
Keep one dated change log and repeat the same page checks after release. Then compare suitable complete reporting periods, recording any changes in query mix, seasonality, tracking or the offer itself. With little data, extend the observation period rather than treating a few visits as proof.
Google's traffic-drop investigation guide covers technical faults and wider causes. A decline starting near launch is a reason to investigate; timing alone does not establish its cause.
Ask for a scoped recovery assessment
Bring the launch date, previous and current URL lists, two or three affected pages and any preserved reporting comparison. Explain which services and UK areas the website should support. Share account access through an agreed invitation process after scope, rather than sending passwords in an enquiry.
Discuss an existing website fault with Nolixia. We can review the relevant implementation and agree suitable repair work, responsibilities and verification. The practical first goal is a working, understandable website journey with a clear record of what was fixed.
