# Traffic-Drop Triage ``` name: Traffic-Drop Triage slug: traffic-drop-triage tier: forward-deployed (operations) role: fda status: template score: 51 (demand 5, pain 5, differentiation 4, usability 4, connectors 4) intent: diagnose an organic traffic drop with a disciplined decision tree, evidence per branch, before anyone acts on it when to use: organic traffic is down and the team is about to do something about it when not to use: routine performance review (use Conversion-by-Source Diagnosis); a known deploy broke something (use Incident Response and Lane Demotion); paid traffic changes (off-catalog) validation note: gated on a showcase-designated property experiencing a diagnosable drop; the pattern generalizes a real production diagnosis on an unnamed property ``` ## Connectors ``` connectors: - capability: warehouse.query access: read bounds: every query carries a date range pushed down as a partition filter - capability: search-performance.read access: read - capability: analytics.read access: read - capability: crawl.read access: read - capability: repo.change access: write-held # only if Phase 4 routes to a technical fix ``` This workflow is read-only until Phase 4, and Phase 4 only ever produces held changes. Nothing in the triage acts on production. ## Prerequisites - Claude with the catalog installed: `/plugin marketplace add rampstackco/claude-skills` - At least one demand-side data source (search-performance export) AND one behavior-side source (analytics events), because the single most valuable discriminator in the tree is whether they disagree. - Enough history to compute a baseline: the same period last year if seasonality is plausible, or at minimum several stable weeks pre-drop. - The deploy log or release history for the drop window. ## Phases ### Phase 1: Pin the drop · lane: convergent (Tholo) Skills: seo-traffic-diagnosis Capability class: traffic.baseline (substitute equivalents if off-catalog) Input: search-performance and analytics data spanning the drop and the baseline window Run: Invoke seo-traffic-diagnosis against the traffic data. Establish, with numbers: when the drop started (day precision), its magnitude vs the pre-drop baseline, and its shape across segments: which page templates, which query classes, which devices, which countries, which traffic sources. Do not explain the drop yet. Produce the drop profile only. Output artifact: a drop profile (start date, magnitude, segment breakdown) Done when: the profile states when, how much, and where, each with a number Fails look like: averaging over segments. A sitewide average of minus 30 percent can be one template at minus 90 and everything else flat, and those are different diagnoses; the segment breakdown is the whole point of this phase ### Phase 2: Run the branches · lane: gate (Basano) Five branches, every one checked, none acted on. Each produces evidence for or against; skipping a branch because another already looks guilty is the failure this phase exists to prevent. **Branch A, tracking breakage.** Skills: product-analytics-setup (nearest anchor; the breakage-detection core is a DECLARED GAP, procedure inline) Run: Cross-check the two data sources for the drop window: if search-performance impressions and clicks are steady while analytics sessions dropped, the traffic did not fall, the measurement did. Check: the analytics tag present and firing on affected templates (crawl.read the live pages), consent-flow changes in the window, filter or property configuration changes, and whether the drop starts at a deploy boundary rather than a demand boundary. **Branch B, technical regression.** Skills: seo-site-health-audit, seo-technical Run: Invoke seo-site-health-audit and seo-technical against the affected segments. Check: robots directives and noindex on affected templates, canonical correctness, status codes and redirect chains, sitemap presence, render-blocking or hydration failures on the live pages, and whether any of these changed at a deploy inside the drop window. **Branch C, algorithm-update timing.** Skills: seo-traffic-diagnosis Run: Compare the drop start date against the published update timeline. Check the drop's shape against the update class: sitewide vs template-scoped vs query-class-scoped losses point at different update types. Timing correlation alone is not a diagnosis; require shape agreement too. **Branch D, seasonality and demand shift.** Skills: seo-keyword Capability class: demand.trend Run: Query the warehouse for the same period in prior years (bounded date ranges). Invoke seo-keyword against the affected query classes: did the demand itself fall? A drop that tracks the category's demand curve is not a site problem, and treating it as one wastes a quarter. **Branch E, SERP displacement.** Skills: seo-rank-tracking, seo-competitor Run: Invoke seo-rank-tracking on the affected queries: are positions held or lost? Positions held with clicks down points at SERP-feature displacement (check the affected queries' current result layout). Positions lost points at a competitor or a relevance change; invoke seo-competitor to identify who took them and with what. Output artifact: a branch evidence table: five branches, evidence for, evidence against, per-branch confidence Done when: all five branches have evidence recorded, including the branches that came back clean Fails look like: stopping at the first guilty-looking branch. Real drops are frequently compound (an update lands the same week a consent banner breaks measurement), and a one-branch diagnosis on a compound drop fixes half the problem while the other half compounds ### Phase 3: Diagnosis · lane: divergent (Krine) Skills: none; this is the judgment stop Input: the drop profile and the branch evidence table Run: Rank the candidate causes by evidence strength, stating per-branch confidence and explicitly noting compound possibilities. Present the ranked diagnosis with the evidence attached. Recommend nothing yet. Stop for the human. Output artifact: a ranked diagnosis with per-cause confidence and the compound read Done when: a human has confirmed the diagnosis or sent specific branches back for deeper evidence Operated-layer note: in an operated deployment, the engine's ranked diagnosis and the human's confirmation or override land as an agreement-log row; diagnosis agreement over time is what earns this lane trust Fails look like: the diagnosis arriving pre-merged with the treatment. The moment the diagnosis says "and therefore we should," the human is reviewing a plan, not a finding, and anchoring does the rest ### Phase 4: Route the response · lane: convergent (Tholo) Skills: routing per diagnosis; the responses live in their owning workflows Input: the confirmed diagnosis Run: Route each confirmed cause to its owner: technical regression -> a held change (repo.change) with the specific fix; tracking breakage -> a held fix to the measurement path, plus an annotation on the drop window so the record shows measurement loss, not traffic loss; update-class losses -> the content-quality program (Corpus Integrity and Correction, Content Pipeline refresh triggers), never a quick technical counterattack; demand decline -> a strategy note, not a fix; SERP displacement -> targeted format or coverage work through the Content Pipeline. Every response lands held; nothing merges from inside the triage. Output artifact: held changes and routed work items, each tied to its diagnosed cause Done when: every confirmed cause has a routed response or an explicit decision to accept it Fails look like: fixing inside the triage. The triage's authority is diagnostic; the moment it merges its own fixes, the diagnosis and the treatment share an author and the verification story collapses ### Phase 5: Recovery watch · lane: gate (Basano) Skills: seo-rank-tracking, seo-traffic-diagnosis Input: the pre-registered recovery metric (set it now, before watching: which segment, back to what level, measured how) Run: On a fixed cadence, measure the affected segments against the pre-registered recovery metric and the pre-drop baseline. Report trajectory per diagnosed cause. Declare recovery only when the pre-registered condition holds across the pre-registered window, not on the first good week. Output artifact: recovery reports on cadence; a closure record when the pre-registered condition holds Done when: recovery is declared against the pre-registered condition, or the diagnosis is reopened because the trajectory contradicts it Fails look like: victory on one good week. Traffic is noisy; a recovery declared on a single datapoint reopens as a mystery a month later, now with the trail cold ## Failure modes - First-plausible-branch tunnel vision (Phase 2's inline failure; the discipline is that clean branches get recorded too). - Measurement loss recorded as traffic loss: the record must say which it was, or every future baseline is quietly wrong. - Timing-only update attribution: correlation with an update date without shape agreement is a coin flip wearing a citation. - Treatment anchoring: diagnosis and recommendation delivered as one artifact (Phase 3's inline failure). - Unpre-registered recovery: the metric chosen after watching begins always finds recovery. - Compound drops resolved as single causes: fix half, and the remaining half now looks like the fix failed. ## Worked example Pending. Populates when this workflow is executed as written on a showcase-designated property experiencing a diagnosable drop. The decision tree generalizes a real production diagnosis (a mass deindexation timed to a core update, root-caused to content quality rather than technical failure, on an unnamed property); that incident informs the branches but is not validation evidence. ## Boundaries - Incident Response and Lane Demotion owns drops caused by the pipeline's own promoted changes (a post-merge regression is an incident with a known suspect, not a mystery). - Conversion-by-Source Diagnosis owns conversion problems on stable traffic; this workflow owns the traffic itself. - Corpus Integrity and Correction and the Content Pipeline own the content-quality responses this workflow routes to; the triage never edits content.