Between late January and mid-March 2026, Google search traffic to sfserviceguide.org collapsed by roughly 84%. April recovered most of the loss, but the underlying cause is still in place. This report documents what we found, why it happened, and the work needed so the next algorithm shift doesn't take us offline again.
Weekly Google search clicks to sfserviceguide.org. The shaded band marks the period of suppressed traffic. Source: Google Search Console, 1 January – 29 April 2026.
The drop wasn't evenly distributed. Brand searches (people typing sf service guide) barely moved — 48 clicks in February, 57 in April. The homepage was almost untouched. What collapsed was long-tail service-seeker traffic: people searching for an actual service or category and landing on a service detail page like /services/3578.
Every one of the top affected pages tells the same story: roughly zero impressions in February, then thousands in April. The pages didn't change. Google's willingness to rank them did.
| Page | Feb 1–28 | Apr 1–30 | Δ |
|---|---|---|---|
| /services/3578 | 1 | 33,698 | +33,697 |
| /services/3131 | 0 | 11,857 | +11,857 |
| /services/2664 | 5 | 6,031 | +6,026 |
| /services/3422 | 0 | 4,086 | +4,086 |
| /services/2562 | 0 | 3,641 | +3,641 |
| /services/3560 | 0 | 3,038 | +3,038 |
| /services/236 | 0 | 2,816 | +2,816 |
| / (homepage) | 2,741 | 5,367 | +2,626 |
Search Console impressions, comparing the trough month (February) against the recovery month (April). Service detail pages went from effectively invisible to ranking; the homepage was barely affected.
Before diagnosing the cause, we ruled out the usual suspects.
sfserviceguide.org has three structural gaps that, in combination, leave Google guessing about which of our pages are worth indexing. When Google's algorithm updated in late January, it guessed against us.
Requesting /sitemap.xml returns a 200 with Content-Type: text/html: the React SPA's catch-all route serves the homepage shell. The Submitted Sitemaps table in Search Console is empty.
A sitemap is the directory we hand Google so it knows which pages exist and matter. We've never given Google one. It's discovering our 8,750 service pages only by following stray links.
/robots.txt returns the SPA's HTML shell, not a robots file. There is no Sitemap: directive, no crawl guidance, no canonical host signal.
This is the standard file every reputable website publishes to guide search engines. Its absence is itself a quality signal — one Google reads as “this site is unmaintained.”
Every URL on sfserviceguide.org returns the same shell HTML: one <title>SF Service Guide</title>, an empty <div id="root">, and a JavaScript bundle. There is no per-page title, description, canonical link, or Open Graph metadata in the initial response. Google must execute the bundle in its rate-limited rendering pipeline before it sees real content.
When Google's crawler arrives, every page on our site looks identical at first glance. It has to do extra work — and decide we're worth the effort — to discover what each page actually is. That work happens on a separate, slower, less-reliable schedule than normal crawling. When Google tightens the rules on which sites get that effort, we're on the wrong side of the line.
Three critical fixes, two high-value follow-ups, and ongoing operational changes. The first three close the structural gaps identified above; the rest harden the recovery.
User-agent: *, Allow: /, and a Sitemap: directive pointing to the new sitemap. Make sure the SPA catch-all does not intercept this path.<title>, a unique <meta name="description">, a <link rel="canonical">, and the service's name, address, and description in the body. Options ranked by effort: a build-time prerender of the top N pages, a render-on-demand service in front of the SPA, or a phased migration to a server-rendered framework.schema.org/LocalBusiness or schema.org/Service metadata for each service: name, address, phone, hours, service area.Treat sitemap, robots.txt, and per-page metadata as non-negotiable parts of the service-page contract. Add a lightweight CI check that fails if /sitemap.xml or /robots.txt ever stop returning their expected content types.
Hold a 15-minute traffic review every Monday using this dashboard. If the gap between brand traffic and long-tail traffic widens by more than ~30% week-over-week, treat it as a P1 signal: something between us and the people we serve has broken.
Include a one-line traffic note in the monthly board update — weekly users, bounce rate, and a flag for any week that looked unusual. The Q1 drop was visible in the data on day one; we just weren't looking at it together.
The dashboard at the home page of this site is now live, refreshed from Google Analytics hourly, and historisable by month. It is the foundation for the operational and board practices above — use it.
GADaily and monthly user counts pulled from the Google Analytics 4 Data API against property 352293213. Source / medium attribution comes from the sessionSourceMedium dimension.
GSCClick, impression, query, and indexing data pulled from Google Search Console for the property sfserviceguide.org, verified 30 April 2026. Period coverage: 1 January – 29 April 2026.
SiteLive HTTP probes against /sitemap.xml, /robots.txt, and the homepage shell to confirm absence of SEO scaffolding and the SPA-only rendering pattern.
CaveatsThe weekly clicks chart is an aggregation of daily Search Console data; small variances against direct GSC totals are expected. GA4 under-reports user counts by 10–30% across the board due to tracking blockers and browser tracking-prevention; the shape of the drop is reliable even if absolute counts skew low.