Traffic Dropped After the New Site Launched. Diagnose It in an Afternoon.

Most post-relaunch traffic drops are measurement problems, not ranking problems. Work in this order: is the analytics tag actually firing on the new site, is the new site indexed, do the old URLs redirect one hop to the right new ones, and is this simply the week your demand always dips. Four checks, one afternoon. Recovery talk comes after, not before.

All four layers produce the same symptom: a chart that falls off a cliff the week you launched. They do not produce the same fix, and three of the four are not SEO problems at all. Start at the bottom — rewriting content, chasing links, arguing about keywords — and you can burn a week on a site whose tracking code is missing from half its templates. Start at the top and each layer either clears in minutes or hands you the answer.

A reported drop starts life as a number on a dashboard. That dashboard is code. Code gets replaced during a rebuild. Check the instrument before you treat the patient.

The fastest test settles it in a minute: compare Search Console clicks against your organic sessions for the same dates. Search Console does not depend on your tag — Google counts the click on its own side. Compare organic to organic, or paid and direct movement will fake a result in either direction.

• Organic sessions down, Search Console clicks flat → measurement problem. Nothing was lost.
• Both down together → keep going to the indexing layer.
• Impressions flat, clicks down → rankings held, but your titles, descriptions or the SERP features around you changed. A snippet job, not an emergency.

Then work the usual suspects, in the order they actually happen during a rebuild:

• New property, new stream. The rebuild shipped a fresh measurement ID, and the historical property is still the one on the bookmark you check every morning.
• Tag on some templates, not all. Home and services carry it; the blog and the thank-you page do not. View source on one page of every page type, not just the homepage.
• Consent banner defaults. New sites ship new consent tools, often set to block analytics until accepted — a legitimate decision with an illegitimate-looking chart.
• Filters re-applied wrong. Internal IP filters, bot filtering, referral exclusions and cross-domain setup for a booking subdomain all get rebuilt from scratch, and rarely rebuilt identically.
• Two hosts, one site. www and non-www, or http and https, both resolving and splitting the data.

sessions: down hard  ·  gsc clicks: flat  ·  tag missing on /services/*
→ measurement, not ranking. close the ticket.

The next place to look is a switch someone flipped for a good reason and never flipped back. Staging sites are built to be invisible. Sometimes they launch that way.

1. Read robots.txt on the live domain. Not the staging one. A single Disallow: / carried over from the build environment ends the investigation right there.
2. Check for a leftover noindex. View source on a service page and search for noindex. Check a blog post too — CMS and framework defaults often differ by template.
3. Check the canonical target. A canonical still pointing at staging.yourdomain.com tells Google your real pages are duplicates of a site it cannot see.
4. Open the Page indexing report in Search Console. Look for changes in shape, not absolute numbers. A jump in Excluded by noindex, Blocked by robots.txt, Not found (404) or Page with redirect dated to launch week is your answer in one screenshot.
5. Compare the Pages tab against the Queries tab. Loss spread thinly across hundreds of queries is a re-evaluation. Loss concentrated in a handful of URLs that used to earn clicks is a plumbing problem, and the redirect audit will find it.
6. Submit the new sitemap, confirm the old one is not still live, then run URL Inspection with Live Test on your five money pages. The main service page, the top two city pages, the highest-traffic post. Live Test shows what Google sees right now, not what it saw last week.

Indexing failures are the good outcome of a bad afternoon. They are usually a one-line fix, and once the block lifts the pages are re-crawled on Google's schedule rather than yours.

This is the layer that actually loses rankings, and the one most often declared "done" because a redirect plugin is installed. Installed is not audited. The audit is mechanical.

Step one — rebuild the old URL list. Three sources cover almost all of it:

• The old XML sitemap, if you saved it. Save it next time.
• Search Console → Performance → Pages, 16-month range, exported. This is the important one: it is the list of URLs that earned traffic.
• The analytics landing-page export for the same window.

Step two — crawl that list against the live site. Any crawler in list mode will do. You want the status code and the final destination for every old URL.

Step three — sort the failures by impressions, not by count. Two hundred dead tag archives matter less than one dead service page. Three patterns account for nearly all of it:

• 404s on pages that used to rank. Cross-reference the crawl against the Search Console export. Every URL with meaningful impressions that now returns 404 goes on the fix list.
• Chains. Old URL → old category → new category → new page. Each hop is a place for the mapping to be wrong and a reason for a crawler to give up early. Rewrite chains so every old URL lands in one hop.
• The blanket redirect to the homepage. The most tempting shortcut on the internet and the one that quietly destroys the most value. A redirect to a page that is not the equivalent of the original is treated as a soft 404 — the old page's relevance does not transfer, it evaporates. If /raccoon-removal-yourtown/ now redirects to /, you did not preserve that page — you deleted it with extra steps.

/wasp-removal/          → 301 → /pest-control/   ✓ one hop, matched
/gutter-cleaning/       → 301 → /                ✗ blanket, treat as 404
/furnace-tune-up-tips/  → 301 → 301 → /blog/     ✗ chain + wrong target
/emergency-service/     → 404                    ✗ ranked, now gone

Fix rule: one hop, closest true equivalent, exact match wherever a match exists. Where no equivalent exists, that is a content decision, and we get to it below.

Before you accept that the rebuild caused this, check whether the calendar did.

• Compare year over year, not month over month. Home-service demand is violently seasonal. Wasp and bat calls collapse in the fall whether or not you launched a site. Roofing spikes after storms. HVAC follows the first heat wave and the first cold snap. A steep drop in September against August is a season. The same drop against last September is a signal.
• Put the exact launch date on the chart. If the decline began ten days before the flip, the rebuild is not your culprit, and you were about to spend a week fixing the wrong thing.
• Check what else changed that week. Paused ads, a Google Business Profile edit, a core update. Rebuilds happen during busy weeks, and busy weeks move several variables at once.
• Rule out the ugly one. If the decline predates launch and Search Console shows a manual action or unfamiliar indexed pages, you are looking at a compromise, not a migration. That is a different playbook — see what to do when a WordPress site gets hacked.

We have cleaned a business out of a roughly 1,200-page spam infestation, rebuilt it, re-ranked it, and moved it onto an architecture with no database and no plugins to reinfect. We do not name that client, and we never will. Discretion in a sensitive situation is part of the service — an agency that would trade someone's incident for a case study would trade yours.

A recrawl wobble is not a penalty. When URLs, templates and internal links all change at once, Google re-evaluates the whole site, and re-evaluation is neither instant nor smooth. Expect positions to jitter, impressions to bounce, and indexed-page counts to move in both directions for a couple of weeks. That is the system working, not failing.

Here is the threshold we use — a rule of thumb, not a law of physics. Export the Search Console Pages report for the 28 days before launch and the 28 days after, and compare URL by URL:

• Wobble: loss spread across many queries, positions moving but staying in range, direction turning back up within two to four weeks. Individual URLs still collect impressions. Direct and referral traffic are unaffected.
• Lost URLs: specific pages that carried impressions before launch now sitting at zero impressions for three-plus consecutive weeks. That page is not being re-evaluated. Google cannot reach it, or it no longer exists.

Zero is the tell. A page that fell from position 4 to position 11 is still in the index and still fighting. A page at zero impressions for three weeks has left the building — and you will almost always find it on the 404 list from the redirect audit.

Not every loss is an accident, and not every loss should be reversed.

Old sites accumulate. A decade of a WordPress install leaves thin city pages written for towns nobody was ever going to service, near-duplicate posts targeting the same query five ways, tag archives that somehow rank, and a service page for something the business stopped offering in 2019. A rebuild cuts them. Traffic to them stops. That was the point.

So when the audit surfaces a ranking URL with no equivalent on the new site, ask three things:

• Did that traffic ever convert, or did it only look good on a chart?
• Does the page describe work the business still wants and can profitably deliver?
• Rebuilt properly today, would it be a page you are proud of — or a page that exists purely to catch a keyword?

If the answers are yes, rebuild it properly and point the old URL at it. If they are no, let it go and redirect to the nearest genuinely relevant page. Keeping a bad page alive to protect a number is how sites get bloated in the first place.

What we will not do is put a date on recovery. Nobody honest can tell you how many weeks Google needs to re-crawl and re-evaluate a site, and an agency quoting you a timeline or a percentage is selling certainty it does not have. What we can tell you is what the audit found, what we fixed, and what the trend is doing week to week — which is exactly what our SEO work reports every month.

Every step above is recovery. All of it is preventable at build time, and the prevention is a checklist run before the flip rather than an audit run after it.

The URL map gets built before the new site does. The old sitemap and the 16-month Search Console export get saved as the source of truth. Every old URL gets a one-hop destination, and the crawl that proves it runs against staging, then again five minutes after the DNS flip. Analytics gets verified on every page type on launch day, not the following Monday. That process is the whole subject of migrating off WordPress without losing rankings.

It is also why our builds ship as static sites with no database and no plugins — fewer moving parts at launch means fewer things that can silently unhook. The Critter Guy, portfolio work of ours, came off WordPress onto that stack: open thecritterguy.ca and run Lighthouse yourself. batsandwildlife.ca was built from zero on the same stack, with a 37-town service-area architecture mapped before a single page shipped. That click is the receipt.

Send us the domain, the launch date, and what you have found so far. We will run the same four layers against your site and tell you which one it is — including the answer where the rebuild is not the cause and there is nothing for us to sell you. Tell us what you want to rank for. One form. A real reply from the people who'll do the work.