
Key takeaways
- Confirm the drop in comparable Search Console periods and locate the affected pages before changing the site.
- Test old and new URLs, redirects, indexability, canonicals and rendered content in that order.
- A redesign may cause temporary fluctuation; a persistent or severe decline calls for evidence-based troubleshooting, not an assumed recovery deadline.
If search traffic fell after a redesign, start with the affected URLs. A redesign can change routes, content, navigation, rendering or analytics. Those changes produce different patterns, so a sitewide percentage alone cannot tell you what broke.
This is a recovery guide for a site that has already launched. If you are still planning the work, use the website redesign SEO checklist instead. Google's traffic-drop guidance recommends using Search Console to identify when and where the decline happened.
Confirm when and where the decline began
Mark the launch date. In Search Console's Performance report, compare equivalent complete periods before and after launch using the same Search type and country. Check clicks and impressions together, then open the Pages tab. Are only a few old URLs affected, an entire service section, or the whole domain? Check the Queries tab for important searches and note whether position changed. A seasonal change or reporting gap may look like a redesign problem.
Also compare analytics and enquiry records, but remember that analytics can miss visits if a new tag or consent setup fails. If Search Console clicks remain steady while analytics sessions collapse, inspect measurement first. If Search Console impressions and clicks fall for the same important URLs, investigate search visibility. Google documents Performance report filters and warns that site changes may take time to appear in Search.
Test the old-to-new URL path
Take the top affected URLs from before the redesign. Open each old URL and record its HTTP status and final destination. If the same content moved, it should lead to the closest relevant new page through a permanent redirect. Avoid sending every old service URL to the home page. Then test that the destination loads, remains accessible on mobile and is linked internally.
Google's site-move guidance calls for an old-to-new URL map and warns about irrelevant redirects, redirect chains and missing new sitemap entries. If URLs did not change, focus on what the redesigned page now returns and displays. Do not create redirects solely because a page's appearance changed.
Check indexability and the rendered page
For affected new URLs, inspect the response, robots directives, canonical and sitemap entry. A production page can accidentally retain a staging noindex or blocked resource. Use Search Console's URL Inspection to compare indexed information with a live test. Then inspect the rendered HTML or browser page: is the main service description visible without relying on a failed script? Are the title, H1 and key internal links present?
Prioritize shared templates. If ten service pages lost their main content after a framework change, repair the component once and retest multiple examples. If one page points its canonical to an unrelated URL, fix that page. Google's crawl troubleshooting describes how missing content or resources can affect Google's understanding of a page.
Compare the content and internal links
Even with working redirects, a redesign can remove the text that explained the service, project evidence, FAQs or links from the main menu. Compare the old and new page by purpose, not just pixel appearance. Did the new version answer the same customer questions? Does the important service page still have a clear path from the homepage and related articles? If the redesign merged pages, check that the destination still covers the useful parts of each.
Do not restore every deleted sentence automatically. Keep material that served a real intent and improve stale or unsupported claims. Google's content guidance favors original, helpful material. A page can pass technical checks but become less useful after a redesign that strips its substance.
Prioritize fixes and monitor recovery
| Observation | First fix | Verify |
|---|---|---|
| Top old URLs lead to irrelevant pages | Map each to the closest equivalent live URL. | Fetch old URLs and confirm final status and destination. |
| New service pages are blocked or noindexed | Remove unintended production directives. | Inspect live URL and later indexed state. |
| Main content vanished from a shared template | Restore the useful visible content. | Test representative rendered pages. |
| Only analytics sessions fell | Repair analytics or consent implementation. | Compare tag events with Search Console clicks. |
Log each fix with its release date and the URLs tested. Google says significant site changes can cause temporary ranking fluctuations while it recrawls and reindexes; there is no universal two-week recovery guarantee. Compare the same page groups over time and investigate remaining outliers instead of declaring the migration complete from one sitewide graph.
Sources and further reading
Need help identifying which redesign change affected search visibility?
Get in touch