Content Decay Triage

Identify which content is losing search traffic, diagnose why per page, and produce a concrete recovery plan. The user's request may contain a property (e.g. sc-domain:example.com) and/or a focus hint such as a URL path, a topic, or a custom date range; honor it if present.

Workflow

1. Resolve the property. If the user's request or the conversation names a property, use it as siteUrl (GSC formats: sc-domain:example.com or https://www.example.com/). Otherwise call list_sites and pick the match; if several sites plausibly match, ask the user which one before proceeding.

2. Aggregate trend: get_decay_overview. Call it with dimension: "page", metric: "clicks", and the default granularity (month) and window (last 16 complete months) unless the user specified a range.

   • Read the per-period TOTALS to describe the site-wide trajectory: steadily declining, seasonal dip, cliff after a specific month, or flat.
   • If a sharp cliff is visible, note the month; you may optionally call detect_change_points to pin down the exact date and cross-reference list_algo_updates for a coinciding Google update.
   • Check the response dataSource; if history looks short, mention whether data came from the warehouse or the live API.

3. Ranked decliners: find_decaying_content. Call with dimension: "page".

   • Period semantics: startDate/endDate is the RECENT period; comparisonStartDate/comparisonEndDate is the earlier BASELINE.
   • Defaults (last 28 days vs the previous period) are fine unless the user asked for something else, but for slow decay a wider gap is more revealing, e.g. recent 28 days vs the same-length window 6-12 months earlier, guided by where the overview showed the peak.
   • Results are bucketed by click loss: severe (> 50%), moderate (20-50%), mild (< 20%).
   • Present the top decliners as a compact markdown table: page, baseline clicks, recent clicks, change %, severity, position change.