Guide Redesign and launch
Traffic dropped after a redesign: what to check first
By Studio Swing
Start by confirming the drop is real, and do it in Google Search Console, not in your analytics alone. Then find its shape: which pages lost clicks, which searches, which devices. Then check, in this order: whether your measurement changed, whether the old addresses still lead somewhere, whether the new pages are allowed into Google's index, whether the new pages say less than the old ones did, and whether something outside the redesign explains the timing. Most drops have a findable cause, and the cause decides the fix. Google says changes can take anywhere from a few days to several months to show, and advises waiting a few weeks, so a dip in the first days is a reason to look, not to panic.
On this page
- 01What does this look like in practice?
- 02Step 1: Is the drop real?
- 03Step 2: What is the shape of the drop?
- 04Step 3: Which pages lost the most?
- 05Step 4: Where did each old address go?
- 06Step 5: Can Google see the new pages?
- 07Step 6: What did the pages lose?
- 08Step 7: Is something outside the redesign involved?
- 09What should you do once you find the cause?
- 10What this guide will not tell you
- 11The traffic-drop checklist
- 12Where to go from here
- 13Sources
What does this look like in practice?
- Step 1: Is the drop real?
- Step 2: What is the shape of the drop?
- Step 3: Which pages lost the most?
- Step 4: Where did each old address go?
- Step 5: Can Google see the new pages?
- Step 6: What did the pages lose?
- Step 7: Is something outside the redesign involved?
This guide is for after the fact. If you have not launched yet, our guide to redesigning without losing search traffic covers the preparation that prevents most of what follows.
Say you run a veterinary clinic with about thirty-five pages. The new site launched three weeks ago. Your receptionist says fewer new clients are mentioning the website. You open your analytics and see a lower line than last month. Your developer says everything is working. The site's designer says Google just needs time.
All three could be right, and none of them has looked at evidence yet. The questions are sharper than "who is to blame": did visits from Google actually fall, which pages lost them, and what is different about those pages now?
Step 1: Is the drop real?
Analytics tools count visits their own way, and a redesign often changes how they are set up. Before blaming search, rule out a counting problem.
Use Search Console as the referee for search traffic. Its Performance report counts clicks from Google Search to your site, and it is separate from your analytics tag. If clicks are flat there and your analytics fell, the problem is a tag, not your rankings. Our guide to Google Analytics and Search Console explains how the two differ.
Check the tag is on every page template. Browse your site and look for activity in the Realtime report of Google Analytics. Google notes it can take up to 30 minutes for data to begin appearing in a new property, so allow for that when testing.
Ignore the newest days. Search Console says the newest data can be preliminary, shown as a dotted line, and may change within hours.
Zoom out. Set the date filter to the longest range, 16 months. Google recommends this to put a drop in the context of past patterns.
Compare with the same weeks last year. Seasonal demand makes last month a poor benchmark. A clinic that is quiet every August has not lost traffic by being quiet this August.
If clicks really did fall, and not just a chart, go on.
Step 2: What is the shape of the drop?
Google's guidance for diagnosing a drop starts with the shape, because different shapes point to different causes.
Use the Compare tab to set the weeks before launch against the weeks since, and then filter by query, page, country, device and search type to see whether the change is concentrated. A useful extra split of our own: searches that include your business name against those that do not. Name searches show whether people who already know you still find you, and the others show whether new people do.
Step 3: Which pages lost the most?
In the Performance report, open the Pages table, compare the two periods, and sort by the click difference. The pages at the top of the list are your suspects. Copy the top ten into a sheet with three more columns: the old address, the new address, and what happens when you open the old one.
Do not diagnose the average. A total can fall because one valuable page vanished, and it can also hide the fact that a hundred small pages barely moved.
Step 4: Where did each old address go?
For each suspect page, open its old address in a browser, and then in a redirect checker that shows the status code. You are looking for one of these:
A permanent redirect (301 or 308) to the matching new page, in one hop. This is correct. Google treats permanent redirects as the signal that the new address should replace the old one in its results.
A "not found" error (404 or 410). Google removes an address that returns either from its index. If a page that earned visits returns an error, this is the most likely cause, and the fix is a redirect to its new equivalent. If the page has no equivalent, a retired page is a decision, and it explains that part of the drop.
A redirect to the home page, or to an unrelated page. Google's site-move guidance advises against redirecting many old addresses to one unrelated destination, and notes it can look like a soft 404. Send each page to its closest equivalent.
A temporary redirect (302, 303, 307). It tells Google the old address is coming back, so the new one may not take its place. Change it to permanent.
A chain of several redirects, or a redirect from an address that was already redirected once in a past redesign. Point the oldest address straight at the newest page.
A page that loads, unchanged. The address was never moved, so look at the page itself in step 6.
Also check the Page indexing report. It lists non-indexed addresses with reasons, such as "Not found (404)", "Page with redirect", "Soft 404" and "Server error (5xx)". A rising count of those after launch tells you where Google is hitting walls.
Step 5: Can Google see the new pages?
A test site is often hidden from search on purpose, and the settings that hide it can travel to the live site.
Check the new address of each suspect page:
A noindex tag, in the page or in a response header. It tells Google not to index the page, and a page with a noindex tag is a page Google will drop.
A robots.txt block. The robots.txt file controls crawling, not indexing, and Google says it is not a way to keep a page out of search. The two interact badly: if a page is blocked in robots.txt, Google can never see a noindex tag on it, so the two need checking separately.
A wrong canonical tag. The tag names the main address for a page. Google advises a self-referencing canonical on each page, so a canonical that points to the test server or the old site tells Google to index something else. The URL Inspection tool shows both the canonical you declared and the one Google chose, and if they differ, you have found something worth fixing.
A sitemap listing the old addresses. A sitemap is a hint, and it should list the canonical addresses you want indexed, which are now the new ones.
Server errors. Google slows its crawling when a server returns 5xx errors, and addresses that persistently return one are removed from results. Ask your host about outages near launch.
Content that depends on scripts. Google can render JavaScript, though it does so in a second step, and it can only discover links that are real <a> elements with an href. A menu built from clickable scripts is a menu Google may not follow, and it may skip rendering a page that carries a noindex tag, so removing the tag with a script later does not reliably work.
URL Inspection is the quickest single tool here. For one address it tells you whether the page is on Google, shows when it was last crawled, and lets you run a live test and view a screenshot of how Google renders the page.
Step 6: What did the pages lose?
If the old addresses are fine and the new pages are allowed in, the pages themselves may be the cause. Put the old and new version of each suspect page side by side (a saved copy of the old site, or your pre-launch notes) and compare:
Words. If the new page says less than the old one did, it may rank for less. Redesigns often trim text to make a cleaner layout, and the trimmed text was sometimes the part that matched what people searched for.
Title and headings. If the title changed from a descriptive one to something short and brand-led, impressions may hold and clicks may fall. Google advises a distinct, descriptive title on every page, and says it may rewrite titles that mislead.
Meta description. Google may use it as the snippet when it thinks it describes the page better than the page's text does, and a new one is a new snippet.
Phone content. Google uses the mobile version for indexing, so anything the new phone layout hides or removes counts as removed. Its advice is to keep the same content, titles, descriptions and structured data on both versions.
Internal links. If menus and body text still point to old addresses, visitors and Google pass through redirects or hit errors. Update them to the new addresses directly.
Structure. If the page used to sit two clicks from the homepage and now sits five, it has less internal prominence than before. That is our reasoning, not a number from Google, so test it against what you see.
Step 7: Is something outside the redesign involved?
If Steps 3 to 6 find nothing, or only a small part of the loss, look wider. Google lists, among the usual reasons for a drop in search traffic, algorithm updates, technical issues, security problems, spam-policy violations, and shifts in demand or seasonality.
Core updates. Google says it makes these several times a year. Check the Search Status Dashboard for exact dates, and wait at least a full week after an update completes before analyzing the data in Search Console. If a core update overlaps your launch, you cannot cleanly separate the two effects, and a good report says that plainly.
Seasonality. Compare with the same period last year, and not with last month.
Security and manual actions. Search Console has a Security Issues report and a Manual Actions report. Both should be empty.
Reporting glitches. Search Console has a Data Anomalies page for known issues in its own reporting.
Demand. If fewer people are searching for what you sell, no redesign fix will change that.
What should you do once you find the cause?
Fix one thing at a time and record when. Redirecting a missing page, removing a leftover noindex or restoring a lost block of text are all targeted changes. Resist the urge to revert the whole redesign: undoing it is another migration, with its own risks.
Then wait, and check again. Google says that some changes can take effect in a few days, while others take several months, and recommends waiting a few weeks before analyzing again in Search Console. It also says there is no guarantee that changes you make will have a noticeable effect, and we would add the same caution. A careful diagnosis removes avoidable causes. It does not promise that traffic returns to where it was.
What this guide will not tell you
It cannot say which step will find your cause, or how much traffic will come back. Some drops are partly permanent: a page that was retired on purpose, or a question the new site no longer answers, will not return because you fixed a redirect. If the numbers still do not make sense after the seven steps, a second pair of eyes helps, and that is a reasonable time to ask someone to look.
The traffic-drop checklist
Checklist
- Confirm the clicks fell in Search Console, over 16 months, against the same period last year.
- Check the analytics tag on every template, and use the Realtime report.
- Set the compare view, and filter by page, query, device and search type.
- List the ten pages that lost the most clicks.
- Open each old address and record its status code and where it leads.
- Replace temporary redirects with permanent ones, and error pages with redirects to real equivalents.
- Check each new page for noindex, a robots.txt block, a wrong canonical and a stale sitemap entry.
- Run URL Inspection on the worst pages and read the rendered screenshot.
- Compare old and new text, titles, descriptions and phone content.
- Check core update dates, the Security Issues report and the Manual Actions report.
- Change one thing at a time, note the date, and re-check after a few weeks.
Where to go from here
If the cause was a missed address, the full method for mapping and redirecting is in redesigning without losing search traffic. To check a site before the next launch, use our website launch checklist. Our website redesign and migration service covers the redirects, launch checks and tracking that this guide works back from, and if you would like to talk it through, you can discuss your project with us without a technical brief.
Sources
Google Search Central, "Debugging drops in Google Search traffic": https:/
Google Search Central, "Site moves with URL changes": https:/
Google Search Central, "Redirects and Google Search": https:/
Google Search Central, "How HTTP status codes, and network and DNS errors affect Google Search": https:/
Google Search Central, "Block search indexing with noindex": https:/
Google Search Central, "Introduction to robots.txt": https:/
Google Search Central, "How to specify a canonical URL": https:/
Google Search Central, "Build and submit a sitemap": https:/
Google Search Central, "Understand the JavaScript SEO basics": https:/
Google Search Central, "Mobile-first indexing best practices": https:/
Google Search Central, "Influencing your title links in search results": https:/
Google Search Central, "Control your snippets in search results": https:/
Google Search Central, "A guide to Google Search ranking systems: core updates": https:/
Search Console Help, "Performance report (Search results)": https:/
Search Console Help, "Page indexing report": https:/
Search Console Help, "URL Inspection tool": https:/
Google Analytics Help, "Verify data collection": https:/