Traffic Drop Diagnosis

Answer "why did my organic traffic drop?" for one Search Console property: date the break, size it, test the usual causes in a fixed order, and name the most probable one with the evidence for and against it. The user's request may contain a property, the date or period the user noticed the drop ("since mid-September"), a metric (clicks or impressions), and a focus hint such as a country, a device or a site section; honor each by narrowing the windows and the segment checks.

Workflow

1. Resolve the property. If the user's request or the conversation names a property, use it. Site URLs use GSC formats: sc-domain:example.com or https://www.example.com/. Otherwise call list_sites and pick the obvious match. If several plausible properties exist, ask the user which one before continuing. GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and if a dip appears at the very edge of the range, say it is likely reporting lag, not a real drop.

2. Date the break. Call detect_change_points with metric: "clicks" and days: 180 (14 to 480). When the user names a period, pass startDate and endDate instead; startDate overrides days. Read the response in this order:

   • changePoints: each entry carries date, direction, beforeMean, afterMean and changePercent (the means cover windowDays days either side of the break; segmentMeanBefore and segmentMeanAfter cover the whole segments). Take the latest entry with direction: "down", or the one nearest the date the user complained about, as the break date.
   • If count is 0, read emptyBecause and nextStep before saying anything, then trendSummary (firstWindow, lastWindow, ratio, slopePerDay, direction, halfwayDate). A gradual slide has no step: report it as a trend dated by halfwayDate, and lower sensitivity (1 to 5, default 2) only when nextStep suggests it.
   • Run the same call with metric: "impressions". A break in both metrics is a visibility loss; a break in clicks alone while impressions hold is a CTR loss (titles, a SERP feature, a layout change), which rankings alone will not explain.

3. Single-day view. Call detect_anomalies with metric: "clicks" and days: 90 (minimum 21; sensitivity 2 to 6, default 3.5).

   • Read anomalies (date, actual, expected, deviationPercent, severity, direction) and keep the down entries around the break; severity runs critical, high, medium, low, info.
   • Check coverage.zeroFilledDays and coverage.trailingGap: days without rows count as zero, so a run of zero days is a data gap or a deindexing, not a demand change.
   • A single-day anomaly with no change point is an event (an outage, a holiday), not a drop; say so and stop the cause hunt early unless the user disagrees.