GSC Wizard - SEO analysis

View saved version →

---
name: ai-assistant-traffic
description: Measure the traffic and the search queries that AI assistants send to one property from the user's own first-party data via the GSC Wizard MCP server: GA4 sessions, conversions and revenue referred by assistants with their share of all traffic, the Search Console query-shape classification that spots AI-conversation fingerprints (reply artefacts, pivot follow-ups, conversational questions, tracker probes, agent harnesses), the AI-shaped share trend by month or week, and the pages serving those queries. Use when the user asks "how much traffic do I get from AI assistants", "is AI traffic growing", "AI Mode or AI Overviews impact", "LLM referrals in GA4", or "weird long queries in Search Console".
---

# AI Assistant Traffic

Report how much of one property's traffic comes from AI assistants and what the shape of its search queries says about AI-driven use, from GA4 referrals and Search Console queries only. The user's request may contain a property, a date range, a focus hint (one assistant, one section of the site, "trend only"), or a search type; honor it and resolve the rest below.

## 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. Use the last 28 days compared with the previous period unless the user specifies dates; the trend step uses complete months. 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. The GA4 tool reads the same settled window when the dates are omitted; when explicit dates reach the last day or two, say GA4 may still be processing them.

2. **Assistant referrals in GA4.** Call `get_ga4_llm_traffic` with `siteUrl`, `comparisonStartDate` and `comparisonEndDate` set to the previous period (without both, the `prev*` fields are 0 and `hasComparison` is false), `limit: 25` landing-page rows (max 1000) and `includeDailySplit: true` only when the user wants a daily series (`sourceTimeseries`, one point per assistant per day). When the tool reports no assistant sessions at all, say that plainly (its `emptyBecause` says whether the property had any sessions in the window); otherwise read the response in four parts:
   - The totals: `summary` (sessions, active, total and new users, page views, `engagementRate`, `averageSessionDuration`, `bounceRate`, event count and key events, all for assistant-referred sessions) against `prevSummary`, `totalSessions` for the whole property, and `llmShareOfSessions` (a 0-1 fraction; multiply by 100 for display) against `prevLlmShareOfSessions`.
   - The `assistants` table: one row per assistant under the name the tool puts in `key`, with sessions, activeUsers, engagedSessions, `engagementRate`, keyEvents, totalRevenue, transactions and addToCarts, sorted by sessions. Present the rows under those names and never rename or merge them.
   - The `landingPages` table: where assistant visitors land, with sessions, activeUsers, `bounceRate`, keyEvents and totalRevenue; `hasEcommerce` says whether `ecommerceSummary` carries revenue (`currencyCode`).
   - The caveats, which go into the report: `methodLimits` says that Google's own AI surfaces pass no distinct referrer, so their visits count as google / organic and are not in these numbers; and, by the tool's contract, an assistant's activeUsers adds up its referrer domains, so a user who arrived through two of them counts twice (`summary.activeUsers` is exact).

3. **Query shapes.** Call `analyze_query_shapes` with `siteUrl`, `examplesPerBucket: 10` (0-100; 0 returns counts only) and the default `searchType: "web"`. The tool classifies every visible query by how it looks, in 27 languages, into 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: anomaly-check
description: Quiet daily or weekly health check for one Search Console property, built to run unattended from a scheduler with the GSC Wizard MCP tools and a read-only connection. Scans clicks and impressions for severe anomalies and downward level shifts, compares the last settled week with the one before, checks the indexing tracker for lost pages, and overlaps findings with Google updates. Stays silent with one fixed line unless a threshold is crossed, then reports the dated finding, cause class and next skill to run. Use when the user asks "check my site for anomalies", "anything wrong today", "daily SEO check", "monitor my property", or sets up a scheduled check.
---

# Anomaly Check

Run a quiet health check on one property and speak only when something needs a human. It is meant for a scheduler: it calls no write tool, works with a read-only connection, and its quiet-case reply is one fixed line so a log stays readable. The user's request may contain a property (or several, checked one after another with the same rules), a cadence (daily or weekly; daily is the default) and a metric to focus on; nothing else is needed.

## 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; a scheduled run with no clear match reports that as its finding. GSC data lags about 2 to 3 days: the tools end at the latest settled date, so the check window is the last 7 settled days for a daily run and the last 14 for a weekly one; never treat the most recent 2 days as complete.

2. **Single-day anomalies.** Call `detect_anomalies` with `metric: "clicks"`, `days: 28` (minimum 21) and the default `sensitivity` (3.5; the range is 2 to 6 and lower finds more). Repeat with `metric: "impressions"`.
   - Keep only `anomalies` whose `date` falls inside the check window; read `severity` (`critical`, `high`, `medium`, `low`, `info`), `direction` (`up` or `down`), `actual`, `expected` and `deviationPercent`.
   - `summary` carries the counts per severity. `coverage.zeroFilledDays` says how many days had no rows at all; a drop to zero is flagged, which is also what a data gap looks like.

3. **Level shift.** Call `detect_change_points` with `metric: "clicks"`, `days: 60` and the default `sensitivity` of 2.
   - Read `changePoints` (`date`, `direction`, `beforeMean`, `afterMean`, `changePercent`) and keep entries dated within the last 14 days.
   - When `count` is 0, `trendSummary.direction` and `trendSummary.ratio` describe the slope. A gradual slide is not a finding for this check, but mention it in a weekly run when `ratio` is below 0.8.

4. **Week over week.** Call `get_site_summary` with `days: 7` (`days: 14` for a weekly run).
   - Compare `current` with `previous` on `clicks` and `impressions`; derive the percentage change yourself and say so.
   - `ctr` is already a percentage on a 0-100 scale, never multiply it by 100; `avgPosition` is lower-is-better, so a move toward a lower number is an improvement.

5. **Lost pages.** Call `get_indexing_tracker_report` with `days: 7` (`days: 14` weekly; max 90).
   - `configured: false` means no tracker exists for the property: skip this signal without comment.
   - Otherwise read `lostPagesTotal`, the first entries of `lostPages` (`url`, `changedAt`, `coverageState`) and `healthScore`; a failed check is not counted as a lost page, so the figure is conservative.

6. **Context, not a trigger.** Call `list_algo_updates` with `startDate` 21 days ago.
   - An entry in `updates` whose `beginISO` to `endISO` span overlaps a fired signal is its likely cause class.
   - An update on its own, with nothing else firing, stays quiet; an empty list is not proof that nothing changed, since only confirmed updates are listed.

## Thre

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: bing-crawl-health
description: Check Bing crawl, index and link health for a Search Console property with the GSC Wizard MCP server's Bing Webmaster tools: daily pages crawled and indexed with the response-code breakdown, crawl issues grouped by type (4xx, 5xx, redirects, robots blocks, DNS and timeout errors, malware) with fixes, sitemap and feed status, the most-linked URLs and whether they are healthy, the URL submission quota, and an optional confirmed IndexNow resubmission of fixed pages. Use when the user asks "is Bing crawling my site", "Bing crawl errors", "Bing index count", "Bing sitemap status", "backlinks in Bing", "resubmit to Bing", or "IndexNow".
---

# Bing Crawl Health

Diagnose how Bing crawls, indexes and links a property, and produce an issue summary grouped by type with concrete fixes, the feed status, the most-linked URLs and recommendations. This is the Bing counterpart of the indexing-health skill; for Google's index run that one. The user's request may contain a property name or URL, a date range for the crawl trend, a focus hint (a path or section), or a list of fixed URLs to resubmit; use it to skip resolution or narrow the suspect set.

## 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. Every property-scoped Bing tool takes that same GSC `siteUrl` and maps it to Bing's form itself (`sc-domain:example.com` becomes `https://example.com/`), echoing the result as `bingSiteUrl`.

2. **Confirm the Bing side.** Call `list_bing_sites` (no arguments). A `notConfigured: true` answer means Bing Webmaster Tools is not connected for the property's Google account in the GSC Wizard app; tell the user to add it there, point them at the indexing-health skill for the Google side, and stop. Otherwise find the property in `siteDetails` and read `isVerified`: Bing serves data only for a verified site, an unverified one makes the property-scoped tools answer with a not-verified error that names the fix (a subfolder property has to be verified as its own site in Bing Webmaster Tools), and a property missing from `sites` has to be added there first.

3. **Crawl trend.** Call `get_bing_crawl_stats` with `startDate` and `endDate` for the last 28 days unless the user set a range; omit both dates for everything Bing has, about 6 months of crawl data, when the user wants the long trend. `daily[]` rows (oldest first) carry `crawledPages`, `inIndex`, `inLinks`, `code2xx`, `code301`, `code302`, `code4xx`, `code5xx`, `blockedByRobotsTxt`, `allOtherCodes`, `crawlErrors` and `containsMalware`. A day Bing did not report is missing from the series, not a zero, so never read a gap as a crawl stop. Compare the first and last reported weeks: whether pages crawled and `inIndex` rise or fall, and the share of the crawl that hit a 4xx, a 5xx or a robots block (derived from the row sums; say so). An `inIndex` drop with a 5xx or robots rise on the same days is the pattern to flag first. Bing reports on its own calendar and carries no `settledThrough` or `partialDays`, so do not apply the Google reporting-lag rule here.

4. **Crawl issues.** Call `get_bing_crawl_issues`; the `limit` default of 200 is fine, and raise it when `rowCount` equals the limit. `issues[]` rows carry `url`, `httpCode`, `inLinks` and `issues`, a list of decoded labels: "301 redirect", "302 redirect", "HTTP 4xx", "HTTP 5xx", "Blocked by robots.txt", "Important URL blocked by robots.txt", "Contains malware", "DNS error" and "Timeout error". Rows come most inbound links first, so the top of the list is the most damaging. Group by label (a URL with several labels counts under each), count the URLs per group, keep the two or three examples with the most `inLinks`, and narrow to the user's focus

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: bing-performance
description: Report Bing search performance for a Search Console property with the GSC Wizard MCP server's Bing Webmaster tools: daily Bing clicks and impressions with a trend and a prior-period comparison, top Bing queries and landing pages, query-to-page pairs, one page's queries, a single query and page pair over time, Bing keyword demand, and the Bing-only versus Google-only winners against the Google top list, and Bing's share next to Google. Use when the user asks "how is my site doing on Bing", "Bing traffic", "Bing vs Google", "top Bing queries", "which pages get Bing traffic", "did this page slip on Bing", "Bing keyword volume", or about Bing Webmaster Tools performance.
---

# Bing Performance

Report how a property performs on Bing (Bing, Yahoo and DuckDuckGo organic, as served by Bing Webmaster Tools) next to its Google numbers, and end with recommendations. The user's request may contain a property name or URL, a date range, a focus hint (a page URL, a query, or "compare with Google"), or a keyword for the demand check; honor it by going deeper on that part while still producing the full report.

## 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. Every property-scoped Bing tool takes that same GSC `siteUrl` and maps it to Bing's form itself (`sc-domain:example.com` becomes `https://example.com/`), echoing the result as `bingSiteUrl`.

2. **Confirm the Bing side.** Call `list_bing_sites` (no arguments). A `notConfigured: true` answer means Bing Webmaster Tools is not connected for the property's Google account in the GSC Wizard app; tell the user to add it there, report the Google side from step 4 only, and stop. Otherwise find the property in `siteDetails` and read `isVerified`: Bing serves data only for a verified site, an unverified one makes the property-scoped tools answer with a not-verified error that names the fix (a subfolder property has to be verified as its own site in Bing Webmaster Tools), and a property missing from `sites` has to be added there first.

3. **Set the windows.** Use the last 28 days compared with the previous 28 unless the user specifies dates, and pass the same `startDate` and `endDate` to the query, page and pair calls so the sections line up. Omitting both dates on a Bing tool returns everything Bing has (about 16 months of search data), not a settled 28-day default. Bing dates its query, page and pair rows by week, so a window selects whole weeks, and a short window that falls between two week dates comes back empty with an `emptyBecause` explanation; widen the window rather than retrying. Bing reports on its own calendar and carries no `settledThrough` or `partialDays`; if the newest days of a daily series read low, say they may not be fully reported yet instead of calling them a drop.

4. **Anchor on Google.** Call `get_site_summary` with `siteUrl` and `days: 28`, or with `startDate` and `endDate` when the user set a window, for Google clicks, impressions, CTR and position with the prior-period comparison. Later, derive Bing's share of combined clicks as Bing clicks divided by Bing plus Google clicks, say it is derived from `get_bing_traffic_stats` and `get_site_summary`, and call it approximate because the two engines count on their own calendars.

5. **Bing totals and trend.** Call `get_bing_traffic_stats` once with `startDate` set to the start of the prior window and `endDate` to the end of the current one. `totals` covers that whole span, so sum the `daily` rows (oldest first, each with `clicks` and `impressions`) per window yourself for the current and prior totals and the change, and say so. Note the peaks, dips and any week-shaped pattern in the series.

6. **Top queries an

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: branded-split
description: Split a Search Console property's performance into branded and non-branded search with the GSC Wizard MCP tools: totals, branded click share, the daily trend and the top queries per side from get_branded_performance, the brand filter status from get_filter_options, brand variants missing from the saved list spotted with query_top_queries, and the saved branded keywords created or extended with update_site after confirmation, anchored on get_site_summary. Use when the user asks "how much of my traffic is branded", "brand vs non-brand", "is my growth just brand demand or real SEO", "set up or fix my branded keywords", or wants the non-branded trend for a client report.
---

# Branded versus Non-branded Split

Measure how much of one property's search traffic is brand demand and how much is non-branded SEO, how each side is trending, and what share of the period's growth each side explains. The user's request may contain a property (a GSC site URL or a recognizable name), a date range, the brand name or a list of brand terms to save, or a focus such as "non-branded only for the client report".

## 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.

2. **Anchor and windows.** Call `get_site_summary` with `days: 28`, or with `startDate`/`endDate` when the user gave dates. Use the last 28 days compared with the previous period unless the user specifies dates.
   - Read `current`, `previous` and `deltas`, and keep `range.startDate`/`range.endDate` and `comparison.startDate`/`comparison.endDate`: the split tool only compares periods when both comparison dates are passed, so these four dates are what keep its comparison aligned with the anchor.
   - 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.

3. **Is a brand filter defined?** Call `get_filter_options` with `siteUrl`. This call reads configuration only and fetches no Search Console data.
   - Read `brand.configured`, `brand.keywordCount` and `brand.skippedKeywords` (saved keywords the filter could not compile).
   - When `brand.configured` is false, or the response carries `emptyBecause`, no branded keywords are saved: go to step 5 to propose a list before running the split, and say the split cannot run until it is saved.

4. **The split.** Call `get_branded_performance` with `siteUrl`, `startDate`/`endDate` set to the current window, `comparisonStartDate`/`comparisonEndDate` set to the comparison window (both are required for a comparison; omitting them gives no baseline), and `limit: 25`.
   - If it answers `notConfigured: true`, read `reason`: `no_branded_keywords` means none are saved (step 5), and `no_usable_keywords` means none of the saved ones compile; `savedKeywords` lists the stored keywords verbatim and `hint` says what to fix.
   - Otherwise read `branded`, `nonBranded` and `total` (each `clicks`, `impressions`, `ctr` on 0-100, `position`), `brandedClickShare` (0-100), `anonymized` (the part of `nonBranded` with no query row), `daily[]` (`date`, `brandedClicks`, `nonBrandedClicks`, `brandedShare`, oldest first), `topBrandedQueries` and `topNonBrandedQueries` (`query`, `clicks`, `impressions`, `ctr`, `position`), `previous` (`branded`, `nonBranded`, `total`, `brandedClickShare` for the comparison window), `brandedKeywords` (`total`, `used`, `skipped`) and `savedKeywords`.
   - Two caveats the tool states: `nonBranded` is the property total minus `branded`, so the two sides always add up to `total`; and Search Console leaves anonymised queries out of any query-filtered read, so those rare queries land in `nonBranded`, `brandedClickSha

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: cannibalization
description: Detect and resolve keyword cannibalization in Google Search Console data via the GSC Wizard MCP server. Finds queries where multiple pages of one property compete for the same search, compares the contenders on clicks, impressions, CTR, and position, picks a canonical winner per cluster, and recommends fixes (consolidate, canonicalize, differentiate intent, adjust internal anchors). Use when the user mentions cannibalization, keyword cannibalization, pages competing for the same keyword, multiple URLs ranking for one query, or asks which page should rank for a keyword.
---

# Keyword Cannibalization Analysis

Find queries where several pages of one property compete against each other, decide which page should win each cluster, and recommend concrete fixes. All data comes from the GSC Wizard MCP tools.

Optional user input: the user's request may contain a property (site URL or domain), a date range, or a focus hint such as a specific query or URL path. Honor it when present.

## 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.

2. **Set the date range.**
   - Default: last 28 days (the tools default to this when you omit dates). Use the user's range if they gave one.
   - GSC data lags about 2 to 3 days; never treat the most recent 2 days as complete. If a dip is visible at the edge of the range, say it is likely reporting lag, not a real drop.

3. **Find cannibalized clusters.** Call `analyze_cannibalization` with the `siteUrl` (plus `startDate`/`endDate` if the user specified a range). Defaults are fine to start: `minImpressions: 10`, `limit: 100`. Raise `minImpressions` (for example to 100) on large properties to cut noise; if the user gave a focus query or path, filter the returned clusters to it.
   - Each result is a query with 2 or more competing pages, scored by impression entropy: higher entropy means impressions are split more evenly across pages, which is worse cannibalization. Each contender already carries clicks, impressions, ctr, and position.
   - Present the top clusters (typically 5 to 10) as a compact markdown table: query, number of pages, total clicks, total impressions, entropy. If nothing clears the threshold, say the property shows no meaningful cannibalization in this range and stop.

4. **Inspect the top clusters in depth.** For each of the top 3 to 5 clusters (or the ones the user cares about), call `query_search_analytics` with:
   - `dimensions: ["query", "page"]` and `filters: [{ dimension: "query", operator: "equals", expression: "<the query>" }]`
   - Optionally a second call with `dimensions: ["date", "page"]` and the same query filter when you need to see whether Google is flip-flopping between URLs over time (alternating pages day to day is a strong cannibalization signal; one page consistently ahead is a weaker one).
   - Show each cluster as a markdown table of contenders: page URL, clicks, impressions, ctr, position. The `ctr` values are already percentages on a 0-100 scale; never multiply them by 100. For position, lower is better.

5. **Decide a canonical winner per cluster.** Weigh, in order: most clicks; better (lower) average position; higher ctr; and best intent match between the query and the page content (judge from the URL and what you know of the pages). Name the winner explicitly and say why. If two pages genuinely serve different intents (for example a product page and a guide), say so; that cluster may not need consolidation at all.

6. **Recommend a fix per cluster.** Choose the most fitting action:
   - **Consolidate or merge**: the losing pages substantially duplicate the winner. Merge their unique content into the winner and 301-redirect the losers.
   

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: client-report
description: Produce a client-facing SEO report for a Search Console property and share it through the GSC Wizard client portal: generates the full report with generate_seo_report (ready-to-open HTML, a compact digest with a drill per section, or JSON), saves a table of the key rows as a shareable report, adds the client contact, grants access and hands back the share URL with who can open it, and audits or deletes earlier reports. Use when the user says "make a report for my client", "share this with the client", "create a shared report", "give my client access to the report", "who can see my shared reports", or "delete that shared report".
---

# Client Report

Turn one property's performance into a deliverable a client can open: a self-contained HTML report, a client-portal table, or both. The output is the report summary for the user, the exact share URL with who has access to it, and the next steps. The user's request may contain a property, a date range or `days`, the client's email and name, a title, a focus (queries, pages, movers), and whether the user wants the HTML file, the portal link or both. For the content of a weekly digest, run the weekly-report skill and bring its mover tables here.

## Workflow

1. **Resolve the property and the window.** 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. Use the last 28 days compared with the previous period unless the user specifies dates; `generate_seo_report` sizes both windows from `days`. GSC data lags about 2 to 3 days and the tools count back from the latest settled date, so state the dates the response reports (`range`, `comparison`) rather than implying the report runs through today, and if a dip appears at the very edge of the range, say it is likely reporting lag, not a real drop.

2. **Confirm the deliverable.** Ask, or infer from the user's request, what the client gets and who receives it (email, optional name):
   - the HTML report: one self-contained file the user forwards or uploads;
   - a portal table: one URL behind a client login, which the user sends once access is granted;
   - both, with the portal table carrying the one table the client will look at most.
   Every write step below lists what it will create and waits for the user's yes, and all of them need write access. If a write is refused because the connection is read-only, say so and complete the read-only parts.

3. **Generate the report.** Call `generate_seo_report` with `siteUrl`, `days` (7 to 180, default 28), `format` and `includeSitemap` (default `true`; `false` skips the sitemap fetch). Choose `format` by use:
   - `html` (the default): a finished, self-contained report in `html`, with `bytes` as its size. Save that string as a `.html` file and hand the file to the user; do not paste it into the conversation.
   - `compact`: a few numbers per section in `sections` (`summary`, `trend`, `topQueries`, `topPages`, `countries`, `devices`, `ctrCurve`, `opportunities`, `rankingByQuery`, `rankingByPage`, `decay`, `cannibalization`, `sitemaps` and more), each with a `drill` naming the tool and the exact arguments that reproduce it. Use it to narrate the report in chat and to fetch full rows for the portal table over the same window.
   - `json`: every sub-result in full, which is large; only when the user asks for the raw data.
   Every format carries `highlights` (`kpis`, `topQueries`, `topPages`, `movers`), `range`, `comparison`, `settledThrough` and `dataSource`. One call fans out to about twenty reads, so call it once per format you need, not once per question. `ctr` values are already percentages on a 0-100 scale; never multiply them by 100. `position`: lower is better, so a change toward a lower number is an improvement; never color i

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: content-decay
description: Find, triage, and build recovery plans for decaying content in Google Search Console using the GSC Wizard MCP tools (get_decay_overview, find_decaying_content, per-page drill-downs, optional traffic forecast). Use when the user asks about decaying content, pages losing traffic, content refresh candidates, which pages are dying, declining organic clicks, or wants a content refresh or recovery plan.
---

# 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.

4. **Drill into the worst 5-10 pages.** Pick by absolute clicks lost, not percentage alone (a 60% drop on 5 clicks matters less than a 25% drop on 5,000). For each page:
   - `get_page_performance` with the full `pageUrl` and a window covering both periods: read the shape of the decline (gradual erosion vs step change) and which metric moved first (position, impressions, or CTR).
   - `query_search_analytics` twice, filtered to the page, to find which queries drove the loss:
     - `dimensions: ["query"]`, `filters: [{ dimension: "page", operator: "equals", expression: "<pageUrl>" }]`
     - one call for the recent period, one for the baseline period; diff the two result sets per query.
   - Classify the loss pattern:
     - position slipped on the same queries: content freshness or competition;
     - impressions collapsed: demand drop, deindexing, or cannibalization;
     - CTR fell at stable position: SERP feature or title/snippet problem;
     - or the page lost a single dominant query.

5. **Optional: quantify the cost with `forecast_traffic`.** If the user wants to know what continued decay costs, call it for the property with `metric: "clicks"`; if the user supplies a conversion rate or average order value, pass them as `cvr` (decimal, e.g. 0.025) and `aov` to derive revenue. Contrast the projected trajectory with the baseline-period run rate. Frame it as an estimate.

6. **Output a recovery plan.** Per triaged page, recommend exactly one primary action with a one-line justification tied to the diagnosis:
   - **Refresh**: p

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: content-groups
description: Define and measure content groups, the URL-rule segments (blog, product, category or locale folders, subdomains) of one Search Console property, with the GSC Wizard MCP tools. Lists the saved groups and their rules, proposes new groups from the site's folder structure with breakdown_by_path, creates, edits or deletes groups after confirmation, and measures clicks, impressions, CTR, position, page count and click share per group plus the uncategorized remainder with get_content_group_performance. Use when the user asks about content groups or site sections, "how is the blog doing versus the product pages", wants to segment pages by URL pattern, or asks which part of the site drives organic traffic.
---

# Content Groups

Define URL-rule based content groups on one property and measure how each group performs, so the user sees which parts of the site carry the organic traffic and which pages fall outside every group. The user's request may contain a property, a date range, a focus hint (a folder, a group name, "propose groups"), or an instruction to create, edit or delete a group; honor it when present.

## 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. Use the last 28 days compared with the previous period unless the user specifies dates. 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. **Read the saved groups.** Call `list_content_groups` with `siteUrl` and read:
   - `groups`: each entry carries `id`, `name`, `description`, `rules`, `color` and `created_at`, sorted by name;
   - the order caveat: that list is a display order only. When the groups are measured, matching is first-match-wins with the newest group evaluated first, so a page that matches two groups counts in the newer one;
   - `emptyBecause`: the property has no groups yet. Continue with step 3 and propose groups instead of measuring.

3. **Propose groups from the site's structure.** Call `breakdown_by_path` with `siteUrl` and `depth: 1` (host plus first folder; raise `depth` to 2, at most 4, when one folder holds most of the traffic and the user wants it split). Omit the dates for the last 28 settled days; `limit` defaults to 100 (max 1000). Each row in `groups` has `path`, `host`, `subdomain`, `clicks`, `impressions`, `ctr`, `avgPosition` and `pageCount`, sorted by clicks. Quote the property totals from `coverage.siteTotals`, never from summed rows, and relay `truncationNote` when `truncated` is true (on the live-API path the least-clicked pages are missing from every group). Turn the folders and subdomains that carry meaningful clicks into proposed groups, one rule each. A rule is a `{ "type", "value" }` object and a group takes 1 to 50 of them:
   - `prefix` with the full URL start, for example `{ "type": "prefix", "value": "https://www.example.com/blog/" }`, for a folder or subdomain;
   - `contains` for a token anywhere in the URL, such as a locale segment or a query parameter;
   - `equals` for one exact page;
   - `regex` for a pattern, in RE2 syntax (no lookahead, lookbehind or backreferences).

4. **Measure the saved groups.** Call `get_content_group_performance` with `siteUrl`. The tool compares periods only when both comparison dates are given, so compute the windows: `endDate` is today minus 3 days, `startDate` 27 days before that, `comparisonEndDate` the day before `startDate`, and `comparisonStartDate` 27 days before that. Omitting the comparison pair returns `hasComparison: false` and no `prev*` fields; to avoid guessing the settled edge, call once without dates, read `range` back and derive the compar

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: core-web-vitals
description: Review page experience for a Search Console property from Chrome UX Report field data with the GSC Wizard MCP tools: Core Web Vitals (LCP, INP, CLS) plus FCP and TTFB with ratings, good-share trends and week-over-week regressions via get_core_web_vitals, split by device and by page, tied to the pages that carry the clicks with query_top_pages and to GA4 engagement with get_blended_landing_pages when linked, ending with a vitals table, the pages or templates to fix first, and metric-specific recommendations. Use when the user asks "how are my Core Web Vitals", "is my site slow", "page speed", "LCP", "INP", "CLS", "page experience", or whether a speed fix worked.
---

# Core Web Vitals Review

Report the real-user page experience of one property from Chrome UX Report (CrUX) field data, find the regressions, and rank the pages or templates to fix by the clicks at stake. The user's request may contain a property, a single page URL, a device hint ("mobile", "desktop"), or a metric to focus on (LCP, INP, CLS); honor it by narrowing the calls, but still report all three Core Web Vitals.

## Steps

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.

2. **Origin-level vitals.** Call `get_core_web_vitals` with `siteUrl` and `formFactor: "ALL"` (the default; the other values are `PHONE`, `DESKTOP`, `TABLET`). Omit `url` so the whole origin is measured. Three answers are possible:
   - `notConfigured: true` with a `hint`: the Chrome UX Report connection is not set up in the GSC Wizard app. Tell the user so, relay the hint (the Core Web Vitals report in the app is where that connection is set up), and stop the vitals part of this workflow; still run steps 4 and 5 so the user gets the traffic picture.
   - `noData: true` with `message`, `emptyBecause` and `nextStep`: CrUX holds no record for that target and device class because it had too little real-world Chrome traffic. Do what `nextStep` says (the whole origin instead of a page, `formFactor: "ALL"` instead of one device); if the origin itself has no data, say the site is below the CrUX traffic threshold and that lab data is the only option.
   - A result: `periods` (oldest first, each a 28-day collection window ending in that week; never read a series newest-first), `periodLabels` and `latestPeriod`.
   - `metrics[]` with `key`, `label`, `coreWebVital` (true for LCP, INP, CLS; false for FCP and TTFB, which are diagnostics), `unit`, `latestP75`, `latestP75Formatted`, `latestRating` (good, needs-improvement or poor), `latestGoodDensity` (a 0-1 fraction of page loads rated good; multiply by 100 only when you present it as a percent and say so), `p75Series` and `goodDensitySeries` aligned with `periods`.
   - Use `latestRating` as the verdict; do not re-rate the numbers yourself. CLS is unitless, the other metrics are milliseconds.
   - `regressions[]`: each with `metricKey`, `fromRating`, `toRating`, `fromValueFormatted`, `toValueFormatted`, `fromPeriod`, `toPeriod`. It lists only a Core Web Vital whose rating band got worse between its two latest weeks with data; when it is empty the response carries `methodLimits`, so read `p75Series` for drift inside a band or over a longer span and report that as a trend, not as a regression.
   - `adMetrics[]` (only when Chrome detected ads): experimental ad count, density, CPU and network weight as p75 trends with no rating and no thresholds; mention them when a site carries ads and INP or LCP is poor.
   - `softNavMetrics[]` (experimental): LCP, INP and CLS counting single-page-app route changes, rated on the stable thresholds, with `pageLoadsOnlyLatestP75` beside each for the same week; entries are null before October 2026 and never appear in `regress

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: country-device
description: Analyse a Search Console property's international and device performance with the GSC Wizard MCP tools: per-country and per-device tables for the current and prior window from query_countries and query_devices, market-specific winning and losing pages and queries from filtered query_search_analytics pulls, the property anchor from get_site_summary, and real-user Core Web Vitals per form factor from get_core_web_vitals. Use when the user asks "which countries drive my traffic", "how do I perform in Germany", "mobile vs desktop", "is mobile dropping", "where is my CTR low for the position I hold", or about hreflang, local content or international SEO.
---

# Country and Device Performance

Build a markets table and a device table for one property, find the gaps (markets where the position is fine but the CTR is low, declines that only mobile shows), and recommend fixes. The user's request may contain a property (a GSC site URL or a recognizable name), a date range, a country (a name or an ISO 3166-1 alpha-3 code), a device, or a URL path to narrow the winners and losers step.

## 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.

2. **Anchor and windows.** Call `get_site_summary` with `days: 28`, or with `startDate`/`endDate` when the user gave dates (a date you pass always wins and `days` only sizes an edge you leave out). Use the last 28 days compared with the previous period unless the user specifies dates.
   - Read `current` and `previous` (`clicks`, `impressions`, `ctr`, `avgPosition`) and `deltas` (`clicks`, `impressions`, `ctrPoints`, `positionDelta`).
   - Keep `range.startDate`/`range.endDate` and `comparison.startDate`/`comparison.endDate` from the response and pass those exact dates to every later call, so all sections line up.
   - 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.

3. **Markets.** `query_countries` takes a single date range and no comparison argument, so call it twice: once with the current window and once with the comparison window, with `limit: 25` (raise it, or page with `offset` set to `pagination.nextOffset`, when the user wants more markets).
   - Rows are `countries[]` with `country`, `clicks`, `impressions`, `ctr` (0-100) and `position`, sorted by clicks. Country codes are lowercase ISO 3166-1 alpha-3 as the tools return them (for example `usa`, `gbr`, `deu`); print the country name next to the code and keep the code, in that case, for filters, since an `equals` match is case-sensitive on both data paths.
   - Join the two calls by `country` and derive the click, impression, CTR-point and position deltas; say they are derived. Quote property totals from `coverage.siteTotals`, not from summed rows, and give each top market's share of total clicks as a derived figure.

4. **Devices.** Call `query_devices` twice the same way (current window, then comparison window). Rows are `devices[]` with `device` (`DESKTOP`, `MOBILE`, `TABLET`), `clicks`, `impressions`, `ctr` and `position`.
   - Join by `device`, derive the deltas and the mobile share of clicks.
   - A mobile-only decline is mobile clicks down while desktop is flat or up. Check whether mobile `position` worsened (a ranking problem, often page experience or mobile content parity) or only mobile `ctr` fell (a SERP-layout or snippet problem).

5. **CTR gaps.** For each of the top 5 to 10 markets, compare its `ctr` and `position` with the property anchor from step 2 and with the best-performing market at a similar position. Apply the same comparison to `MOBILE` versus `DESKTOP`.
   - A market whose positio

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: ctr-optimization
description: Find the query and page pairs whose click-through rate underperforms for the position they hold, and turn them into title and meta description rewrite briefs, using the GSC Wizard MCP CTR-curve benchmark comparison, top queries and pages, a query-by-page pull, the striking-distance click upside and an on-page audit of the current titles. Distinct from quick-wins, which merges every opportunity signal: this skill asks only where CTR is low at a stable position and what the title should say. Use when the user asks about CTR optimization, low CTR, "my CTR is bad", title tag rewrites, meta description improvements, snippet optimization, or which titles to rewrite first.
---

# CTR Optimization

Find where the property's click-through rate falls short of what its positions should earn, and produce a candidates table plus a rewrite brief per page. The user's request may contain a property, a date range, a site section or path, a country, and a focus hint such as "product pages only"; honor all of them. When the user wants one merged list of every kind of opportunity, run the quick-wins skill instead.

## Workflow

1. **Resolve the property and the window.** 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.
   - Use the last 28 days unless the user specifies dates; a shorter window makes the per-position CTR too noisy to judge.
   - When the user's request names a section, a path or a country, carry it into the step 4 filters rather than judging the whole property.
   - 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. **CTR curve against benchmarks.** Call `analyze_ctr_curve` with `siteUrl`, the dates, `minImpressions: 10` and `benchmarkSource: "all"` (or one of `awr`, `awr2026`, `awrAio`, `firstPageSage`, `sistrix`, `backlinko`, which adds the flat `expectedCtr` and `ctrDelta` fields). `buckets` always holds positions 1 to 20 in order, each with clicks, impressions, `queryCount`, `ctr`, `benchmarks` (expected CTR per source) and `deltas` (actual minus expected).
   - `ctr` values are already percentages on a 0-100 scale, never multiply them by 100, and the deltas are percentage points: a negative delta means the bucket underperforms that benchmark.
   - Keep the buckets whose delta is negative against most sources and whose impressions are large; a bucket with `queryCount` 0 has no data, and `emptyBecause` means every bucket is empty, so its zeros are placeholders, not underperformance.
   - The gap between `awr2026` and `awrAio` is the AI Overview click tax: a property that trails `awr2026` but matches `awrAio` is probably losing clicks to AI Overviews rather than to weak titles, which a rewrite cannot fix.
   - `truncated: true` means the live API read was cut at `scanLimit` queries and zero-click queries were dropped first, so the bucket CTRs read high, not low.

3. **Volume context.** Call `query_top_queries` and `query_top_pages` with the same dates and `limit: 200`. Rows carry clicks, impressions, `ctr` (0-100) and position, sorted by clicks.
   - Use them to see which pages and queries hold the impressions in the underperforming buckets, and to quote property totals from `coverage.siteTotals`.
   - Note `coverage.hiddenClicksShare` (0-1), the share of clicks with no query row that no pair below can explain.

4. **Query and page pairs.** Call `query_search_analytics` with `dimensions: ["query", "page"]`, the dates and `rowLimit: 1000`; rows run by clicks, highest first, so page with `startRow` set to `pagination.nextOffset` when the first page has not yet reached the impression floor you chose. Add a page `contains` filt

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: experiment-results
description: Read out an SEO split test for a Search Console property with the experiment tools of the GSC Wizard MCP server: the experiments with their control and variant URL groups, the control-versus-variant click growth with significance test, uplift confidence interval and winner, a sanity check of a few URLs per group, confounders (Google algorithm updates and logged site changes during the test), and a roll-out, extend or stop verdict that can be logged as an annotation. Use when the user asks "how is my SEO test doing", "did the variant win", "read my experiment results", "is the uplift significant", or "should I roll out the change".
---

# Experiment Results

Read out one SEO split test: which group won, by how much, whether the difference is significant, what else happened during the test, and what to do next. Experiments are created in the GSC Wizard app (its Experimentation page, where the control and variant URL groups are defined), not through the MCP; the tools here read and score them. The user's request may contain a property, an experiment name or id, a test window, a confidence level, or a note on what was changed on the variant pages.

## Steps

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.

2. **Find the experiment.** Call `list_experiments` with the `siteUrl`; add `includeArchived: true` when the user asks about a finished or old test.
   - Each entry carries `id`, `name`, `description`, `status`, `startDate`, `groupCount` and `groups` (`group`, `urlCount`, `color`); the first group is the control.
   - Pick the experiment the user named, or show the list in a short table and ask when more than one is active.
   - An empty list comes with `emptyBecause` and `nextStep`. When `error` is set the list could not be read, and the empty result does not mean the property has none.
   - When none exists, tell the user to create one in the app first (define the control and variant URL groups there) and stop.

3. **Score it.** Call `get_experiment_results` with `siteUrl`, `experimentId` and, unless the user wants the default last 28 settled days, `startDate` set to the experiment's `startDate` (when it has one) with `endDate` left out, so the window runs to the latest settled day. The comparison window is always the same-length period immediately before the window, so this makes the pre-test period the baseline. `confidenceLevel` is 0.8 to 0.999 (default 0.95). Read:
   - `groups`: per group `matchedPages`, `totalClicks`, `totalImpressions`, `prevTotalClicks`, `prevTotalImpressions`, `ctr` (0-100), `avgPosition` (impression-weighted), `clickGrowthPct` (null when the group had no clicks in the comparison window) and `ctrConfidenceInterval` (`lower`, `point`, `upper`).
   - `comparisons`: one per variant against the control, with `controlGrowthPct`, `variantGrowthPct`, `upliftPoints` (variant growth minus control growth, in percentage points), `upliftCI` (`lower`, `upper`), `pValue`, `significant` (true exactly when the uplift CI excludes 0), `ctrPValue` (a separate CTR comparison, for reference), `confidenceLevel`, `winner` (the winning group's name, set only when `significant` is true, otherwise null), `powerWarning` (true when either group has under 100 clicks in either window) and `clicksDiff`.
   - `emptyBecause` and `nextStep` when no group matched a page: the group URLs do not match the pages Search Console reports (matching ignores case, a trailing slash and www), so the zeros measure nothing. Relay `nextStep` and stop scoring.
   - `truncated` and `truncationNote`: a page read hit its row cap and low-traffic experiment pages may be missing from a group; compare `matchedPages` with each group's `urlCount` from step

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: ga4-overview
description: Review the Google Analytics 4 side of a Search Console property through the GSC Wizard MCP server: which GA4 properties are readable and linked, the traffic overview with its previous-period comparison, the channel mix with the organic share and trend, one breakdown dimension of choice, the key event (conversion) that matters, error pages, and the site's own custom dimensions. Use when the user asks "how is my GA4 traffic", "show me analytics for my site", "sessions and conversions this month", "which pages get traffic in GA4", "is organic growing in analytics", "which pages show a 404", or "what custom dimensions do I have".
---

# GA4 Overview

Read the Google Analytics 4 property linked to one Search Console site and present a traffic overview, the organic channel's share and trend, conversions, error pages and recommendations. The user's request may contain a property, a date range, a key event name (for example "form_submit"), a dimension to break down by, or a custom dimension name; honor what is given and resolve the rest below.

## 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. Use the last 28 days compared with the previous period unless the user specifies dates. Every GA4 tool here defaults to the same settled window as the Search Console tools (the last 28 days ending about 3 days back), so omitting `startDate` and `endDate` is the safe choice; when the user asks for explicit dates that reach into the last day or two, say that GA4 may still be processing them and treat the newest day as incomplete rather than as a drop.

2. **Confirm the GA4 link.** Call `list_ga4_properties` (no arguments). Read `connected`: `false` means the Google Analytics consent has not been granted in the GSC Wizard app for this account (`account` names it), and `connected: false` with `reauthRequired: true` means it was granted but Google now rejects every Google account carrying it, so the user has to reconnect it on the Account page of the app. Find the property whose `linkedSiteUrls` contains the resolved site; linking happens in the app, not through the MCP, so if no property lists the site, say so and tell the user to link one in GSC Wizard. `linkedSiteUrls` only covers the GSC Wizard account this connection is authenticated as, so a link made from another account of the user shows as empty here. Read `errors` for Google accounts whose properties are missing from the list and relay each `message`.

3. **Traffic overview.** Call `get_ga4_overview` with `siteUrl`; it always compares against the same-length period immediately before unless both `comparisonStartDate` and `comparisonEndDate` are passed. Read `summary` and `prevSummary`: sessions, active, total and new users, page views, `engagementRate`, `averageSessionDuration` (seconds), `bounceRate`, event count and key events. The two rates are 0-1 fractions, so multiply them by 100 for display and say so. When `comparisonHasData` is false, `prevSummary` is null because the data stream did not exist yet; report the current period alone instead of a change. Set `includeTimeseries: true` only when the user wants the daily shape (`timeseries`, oldest day first). If the response carries `siteScope`, the GA4 property is shared by several sites and every number is limited to this site's hostnames; say that once.

4. **Channel mix and the organic share.** Call `query_ga4_report` with `dimension: "channel"`, `comparisonStartDate` and `comparisonEndDate` set to the previous period (this tool only compares when both are given; without them the `prev*` fields are 0 and `hasComparison` is false) and `limit: 25`. Rows carry the metric names listed in `metrics` (sessions, activeUsers, engagem

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: indexing-health
description: Run an indexing and crawl health check for a Search Console property via the GSC Wizard MCP server; reviews tracked-URL indexing status, sitemap coverage, and quota-aware targeted URL inspections, optionally Bing crawl issues and IndexNow resubmission, then reports issues grouped by cause with concrete fixes. Use when the user mentions indexing problems, pages not indexed, deindexed or dropped pages, crawl issues, sitemap coverage, or asks "is Google indexing my site".
---

# Indexing Health Check

Diagnose why pages are missing from Google's (and optionally Bing's) index and produce an issue summary grouped by cause, with affected URL counts and concrete fixes. The user's request may contain a property name and/or a focus hint (for example a URL path or "check my blog section"); use it to skip resolution steps or narrow the suspect set.

## Workflow

1. **Resolve the property.** If the user (or the request) named a property, use it; site URLs use GSC formats like `sc-domain:example.com` or `https://www.example.com/`. Otherwise call `list_sites` and pick the obvious match. If several plausible matches exist, ask the user which one before continuing.

2. **Tracked-URL status.** Call `get_indexing_tracker` for the tracker config and status summary. If URLs are being tracked, also call `get_indexing_tracker_report` for the indexing health score, coverage, crawl freshness, and lost / newly-indexed URLs; the lost list is your primary suspect pool. Use `list_tracked_urls` with a status filter when you need the concrete non-indexed URLs. If the tracker is not set up, say so briefly and continue; the sitemap and inspection steps still work.

3. **Sitemap coverage.** Call `list_sitemaps` and check for errors, warnings, and stale last-download dates. For the main sitemap (or the one matching the user's focus), call `get_sitemap_performance` to join sitemap URLs with GSC metrics over the default range (last 28 days compared with the previous period, unless the user specifies otherwise). URLs present in the sitemap but with zero impressions across the range are indexing suspects. Remember GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and say so if a dip is visible at the edge of the range. `ctr` values are already percentages on a 0-100 scale; never multiply them by 100. Position: lower is better.

4. **Check inspection quota BEFORE inspecting anything.** Call `get_inspection_quota` and report the remaining daily quota for this property. Plan the inspection batch so it uses well under half of what remains; never spend the whole quota in this workflow. If the quota is exhausted or nearly so, skip step 5, rely on step 6 instead, and tell the user the quota is a daily per-property limit (2,000 inspections per day) that resets each day, so they can rerun this check tomorrow.

5. **Targeted bulk inspection.** Build a small suspect set, typically 5 to 15 URLs and never more than 25: lost or never-indexed URLs from the tracker, sitemap URLs with zero impressions, and any URLs the user named. Call `bulk_inspect_urls` on that set. If it is refused because the connection is read-only, call `inspect_url` for each URL instead, for at most 10 URLs, and mention that batch inspection needs write access. Group the results by root cause from the verdict and coverage state, for example:
   - Crawled - currently not indexed
   - Discovered - currently not indexed (not yet crawled)
   - Excluded by noindex
   - Google chose a different canonical than the user-declared one
   - Page with redirect, or Not found (404), still listed in the sitemap
   - Blocked by robots.txt

6. **Recent inspection history.** Call `list_url_inspections` to pull recent persisted results without spending quota. Use it to widen the evidence base and to spot status changes (previously indexed URLs that flipped to not indexed).

7. **Bing (optional).** If the user cares about Bing or asked to (re)submit pages, c

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: indexing-tracker
description: Set up and run the GSC Wizard Indexing Tracker for a defined set of URLs (new content, a migration batch, one section) using the GSC Wizard MCP tools: adds the URLs, inspects a first sample against the daily quota, reads back which are indexed and which are not with their verdicts and canonicals, and turns the tracker report into a status with re-check timing. Use when the user says "track indexing of these pages", "watch whether my new posts get indexed", "monitor the migration URLs", "add these URLs to the indexing tracker", "are the tracked pages indexed yet", or wants ongoing indexing monitoring rather than a one-off diagnosis.
---

# Indexing Tracker

Put a chosen set of URLs under continuous indexing monitoring and report where they stand. The output is the tracker status, the URLs still not indexed with their verdicts, and recommendations with a re-check plan. The user's request may contain a property, a list of URLs or a path prefix (for example `/blog/`), a sitemap URL, and an action hint ("add", "check", "status", "remove"). This skill sets up and monitors; when the user wants to know why pages are not indexed, run the indexing-health skill, which diagnoses by cause.

## 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.

2. **Read the current tracker.** Call `get_indexing_tracker` with `siteUrl`. `tracker: null` means no tracker exists yet; `add_tracked_urls` creates one, so carry on. Otherwise read `tracker.isActive` and `stats` (`total`, `indexed`, `notIndexed`, `pending`, `errors`, `warnings`, `lastCheckAt`), and compute the free capacity yourself as 1,800 minus `stats.total`, since a tracker holds at most 1,800 URLs per property. `emptyBecause` on an existing tracker means it holds no URLs.

3. **Build the URL set.** Take it from whichever source the user has:
   - The user's own list (a batch of new posts, the pages of a launch).
   - A section or a sitemap: call `list_sitemaps` to find the sitemap path, then `get_sitemap_performance` with `sitemapUrl` and `maxUrls` (default 500, max 2000) and keep the URLs whose path matches the user's prefix; its rows also show which of them already receive impressions.
   - A migration batch: call `list_migration_redirects` with `siteUrlB` set to the property (and `label` when the user names one; `limit` default 500, max 5000) and take each mapping's `toUrl`, the new URL that has to get indexed.
   Every URL must be absolute and on the property's host, or `add_tracked_urls` rejects the whole batch. Deduplicate, drop URLs the tracker already holds (step 7 lists them), and trim to the free capacity, telling the user what was left out. Prefer the pages whose indexing matters (new content, migrated URLs, revenue pages) over bulk lists.

4. **Add the URLs (write).** Before calling anything, show the user:
   - the exact URLs and their count;
   - the capacity they take out of the 1,800-URL cap;
   - that the tracker's hourly run will inspect each of them on the property's inspection quota.
   Then ask for confirmation and call `add_tracked_urls` with `siteUrl` and `urls` (1 to 1,800). Read and report `added`, `alreadyTracked`, `skippedOverCap` and `capacityRemaining`. New URLs start as `pending`. If the call is refused because the connection is read-only, say this step needs write access and continue with the read-only steps (2, 7 and 8).

5. **Check the inspection quota before any immediate check.** Call `get_inspection_quota` with `siteUrl` and read `count`, `limit` and `remaining`; the limit is 2,000 inspections per property per day, shared with the web app, and `unavailable: true` means the counter could not be read and the figures are placeholders, so treat the quot

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: indexnow-submit
description: Set up IndexNow for a Search Console property and submit changed URLs with the GSC Wizard MCP tools: checks that a key and its published key file are in place, generates or sets a key when needed, draws the URL set from the user's list or a sitemap, submits up to 100 URLs per batch, reads the outcome (a 202 is accepted pending key validation, not delivered), and reviews the submission history and the Bing URL-submission quota. Use when the user says "submit these URLs to IndexNow", "ping Bing about my new pages", "set up IndexNow", "did my IndexNow submissions go through", or wants Bing told about changed pages.
---

# IndexNow Submit

Get IndexNow working for one property and submit a set of changed URLs to it. The output is the setup status, what was submitted with each URL's response, and what to check later. The user's request may contain a property, a list of URLs, a path prefix or sitemap URL to draw URLs from, and an action hint ("set up", "rotate", "submit", "history"). IndexNow reaches the engines that take part in it (Bing, Yandex, Seznam); it tells Google nothing, so say so when the user's goal is Google indexing and point them to the indexing-tracker skill for that.

## 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. The IndexNow tools take the GSC `siteUrl`; when the user also cares about the Bing side, `list_bing_sites` shows which sites Bing has verified (`siteDetails[].isVerified`), and `notConfigured: true` there means Bing Webmaster Tools is not connected in the GSC Wizard app.

2. **Check the setup.** Call `get_indexnow_settings` with `siteUrl` and read `indexnowApiKeySet`, `indexnowApiKeyMasked` (the last four characters only), `keyFileVerified` and `keyFileUrl`. Both halves must hold before engines accept anything: a key stored, and the key file reachable on the site. Read `keyFileVerified` as follows:
   - `true`: ready, go to step 4.
   - `false`: the file is missing or holds the wrong key, and `keyFileUrl` names the exact file to publish; hand that to the user before submitting anything.
   - `null`: the probe was inconclusive (a timeout or a bot rule), which is not a failure and does not block a submission.
   `keySiteUrl`, when present, means another of the owner's properties that covers this one already holds the key, so no new key is needed. With no key set at all, go to step 3.

3. **Create, set or rotate the key (write).** Say what will happen and ask for confirmation first. Pass `siteUrl` and exactly one mode to `update_indexnow_settings`:
   - `generateKey: true` creates a key and returns `keyFileUrl`, `keyFileUrls` (every host of a domain property) and `keyFileContent`. The user must publish `keyFileContent` as a plain-text file at each of those URLs before any submission validates; a key generated this moment is not probed, so `keyFileVerified` reads `false` until they do. It refuses to replace an existing key.
   - `indexnowApiKey` (8 to 128 letters, digits and hyphens) sets a key the site already publishes; the file is checked at once and `keyFileVerified: true` means submissions can start.
   - `clear: true` removes the key and disables submissions. To rotate, run `clear: true`, then `generateKey: true`, then have the file republished.
   After the user publishes the file, call `get_indexnow_settings` again and only proceed on `keyFileVerified: true` (or `null`). If the write is refused because the connection is read-only, say this step needs write access and continue with the read-only parts (steps 2, 4, 6 and 7).

4. **Choose the URL set.** IndexNow is for URLs that were added, updated or removed, so do not submit a whole site because it exists. Draw the set from:
   - The user

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: long-tail-analysis
description: Measure how much of a Search Console property lives in the long tail and how much of its traffic is invisible in query and page rows, using the GSC Wizard MCP tools: Head / Chunky Middle / Long Tail page tiers from get_longtail_clusters, the anonymised versus truncated share from analyze_sampling_impact, the ranking-band mix from get_position_distribution, and a raw query pull to characterise tail queries by length and intent. Use when the user asks "how long-tail is my site", "how much of my traffic is hidden or anonymised", "what is in my long tail", "which tail topics deserve a page", or about the head versus tail split.
---

# Long-tail Analysis

Quantify the head-versus-tail shape of one property, measure the share of its traffic that no query or page row carries, and turn the named tail into themes worth a page. The user's request may contain a property (a GSC site URL or a recognizable name), a date range, a `preset` hint (for example "ecommerce" or "small site"), or a focus such as a topic or a URL path to concentrate the theme step on.

## 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.

2. **Fix one window.** Use the last 28 days compared with the previous period unless the user specifies dates. Every tool below defaults to the last 28 settled days when `startDate` and `endDate` are omitted, so either omit both everywhere or pass the same explicit pair everywhere; mixing the two misaligns the shares. Each response echoes the window it covered (`range`, or `startDate`/`endDate` on `query_search_analytics`), which is the range to cite.
   - 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.

3. **Page tiers.** Call `get_longtail_clusters` with `siteUrl`, `preset` (`default`, `content`, `ecommerce`, `small_site` or `enterprise`; pick from the user's hint, else `default`) and `pagesPerCluster: 10`. The tiers are pages, not queries: the tool runs elbow detection on the cumulative-clicks curve and returns `clusters` head to tail.
   - Read per tier: `label`, `urlCount`, `urlPercentage`, `totalClicks`, `clickPercentage`, `totalImpressions`, `impressionPercentage`, `avgCtr` (already 0-100), `avgPosition`, `avgQueryDiversity` (distinct named queries per page), `zeroClickCount` and `topPages`. `knees` are the two cut points by rank, and `totals` holds the page universe (`urls`, `clicks`, `impressions`).
   - A Head tier holding most clicks on a few percent of URLs is concentration risk: a handful of pages carry the property. A Long Tail tier with a large `urlPercentage`, a small `clickPercentage` and a high `zeroClickCount` is index bloat. A Chunky Middle with `urlRange: null` means the curve had no middle (a few dominant pages over a flat rest).
   - If `truncated` is true, quote `truncationNote` and say the Long Tail tier is understated. If the response carries `emptyBecause`, follow its `nextStep` (usually a second call with `includeZeroClicks: true`). `sensitivity` (`low`, `normal`, `high`) only moves the knees; re-run with another value only when the tiers look degenerate, and say so.

4. **The hidden share.** Call `analyze_sampling_impact` with `siteUrl` and the same dates. Read `totals` (the property's clicks and impressions for the window), then `querySampling` and `pageSampling`.
   - In each, `missingClicksPercent` (0-100) is the share of clicks the top rows do not carry, and the nested `gap` object says why. Inside it, `anonymisedShare` (0-1) is traffic that belongs to no row at all; on the query dimension that is Search Console withholding rare queries under its privacy th

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: merchant-center-health
description: Check whether the Merchant Center account linked to a Search Console property is healthy and whether its products are eligible for free listings, using the GSC Wizard MCP Merchant Center tools: readable accounts and links, account issues by severity, feed data sources with their latest uploads, and the products invisible in free listings with the reason, ending in a verdict and recommendations. Use when the user asks "is my Merchant Center account ok", "why are my products disapproved", "are my products showing in free listings", "is my feed uploading", "Merchant Center health check", or mentions a suspension, a policy issue or a feed that stopped.
---

# Merchant Center Health

Check the health of the Merchant Center account linked to one Search Console property and find the products that are not serving in free listings, ending with a verdict and a fix list. The user's request may contain a property, a Merchant Center account name or id, a language code for the issue text, or a focus hint (for example "only the feed" or "disapproved products"); honor the hint by going deeper there, but still run every step.

## 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.

2. **Find the linked account.** Call `list_gmc_accounts` with the property's `siteUrl` (the argument is optional, but passing it adds `linkedAccountId`, the account this property is linked to). The `accounts[]` rows carry `accountId`, `accountName`, `accountEmail`, `isAdvanced` and `linkedSiteUrls`. Interpret the response before anything else:
   - `connected: false` with `reason: "no_scope"` means the Merchant Center consent has not been granted in the GSC Wizard app; `reason: "credentials_revoked"` means it was granted but Google now rejects the saved connection, so the Google account has to be reconnected on the Account page. Relay the `hint` and stop the Merchant Center steps, since nothing below can answer.
   - Accounts listed but no `linkedAccountId` means the property is not linked yet. Linking happens in the GSC Wizard app, not through a tool: show the account table and tell the user which account to link. For a grantee without the Merchant Center opt-in the id is withheld with a note; say so.
   - `isAdvanced: true` marks a multi-client parent that cannot be reported on; one of its sub-accounts has to be linked instead.
   - `incomplete: true` means the list is a floor: read `gaps`, `unprobedAccountIds` and `errors`, say what could not be read, and suggest a retry.

3. **Account health.** Call `get_gmc_account_health` with `siteUrl`, optionally `languageCode` (BCP-47, for example `"nl"`, default en-US) for the issue text and `limit` (default 200, max 500, most severe first). Read `overallStatus` first: it is the worst of the checks and the issues. Then read:
   - `issues[]` (`title`, `detail`, `severity`, `affectsFreeListings`, `impactedDestinations` with the `reportingContext` and the regions each one hits, `documentationUri`) and the `issueCounts` totals.
   - `checks[]` (`key`, `status`, `message`), where status is one of `ok`, `suggestion`, `warning`, `critical` or `unknown`. A setting this Google login may not read answers `unknown` and `sections` says why: report it as unverified, never as passed.
   - `programs[]` for the free-listings program `state`, its `activeRegionCodes` and any `unmetRequirements`; `homepage.claimed` for whether the website is claimed; `countriesWithoutShippingService` against `targetCountries` for the markets without an account-level shipping service.
   Business info is reported as presence flags only (`businessInfo`), and shipping and returns set per product in the feed are not read, so those two checks can fl

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: onpage-audit
description: Run a technical on-page audit of a set of pages on a Search Console property with the GSC Wizard MCP tools: pick the URLs from the user's list, the top pages by clicks, or a sitemap, crawl them in batches with audit_onpage_seo (indexability, canonical, titles and meta, headings, links, images, structured data), optionally confirm a canonical mismatch with a quota-aware URL inspection, then report issues grouped by severity with affected URLs and fixes. Use when the user says "audit these pages", "check my on-page SEO", "technical check of my top pages", "are my titles and meta descriptions ok", or asks for a technical review of specific URLs.
---

# On-Page Audit

Crawl a chosen set of pages on one property, run the technical on-page checks on each, and report the issues grouped by severity with the affected URLs and the fix. The user's request may contain a property, a list of URLs, a sitemap URL, a section path (for example "/blog/"), or a page count; use it to skip resolution and to narrow the URL set. This skill reads the pages' own HTML. For whether Google indexed them, run the indexing-health skill.

## 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.
   - The property also bounds the crawl: `audit_onpage_seo` fetches only URLs that belong to it (a domain property covers its subdomains, a URL-prefix property only its own origin and path prefix) and lists any other URL in `skipped` with a reason, so a URL on another host needs its own property.

2. **Choose the URL set.** Take the first source that applies, and keep the whole workflow to about 25 to 50 pages unless the user asks for more, because every page is fetched live from the user's site.
   - The user named URLs: use them as given, at most 25 per call (the `urls` cap).
   - "My top pages" or no hint: call `query_top_pages` with the `siteUrl` and `limit: 25`, omitting `startDate` and `endDate` for the last 28 settled days, and take the `page` values. Rows are sorted by clicks, highest first; `ctr` is a 0-100 percentage, never multiply it by 100; `position` is lower-is-better. GSC data lags about 2 to 3 days, so the window ends before today.
   - No list and no traffic read: omit `urls` and let the tool auto-pick the top pages by impressions with `maxUrls` (default 10, max 25) and `minImpressions` (default 0, counted over the same 28 days).
   - A sitemap or a section: call `get_sitemap_performance` with `sitemapUrl` (on the property host; one level of sitemap-index expansion) and `maxUrls` (default 500, max 2000). Audit the URLs with clicks or impressions first.
   - URLs with zero impressions are an index-coverage question for the sitemap-audit and indexing-health skills, not an on-page one, unless the user asks about them.

3. **Run the audit in batches.** Call `audit_onpage_seo` with `siteUrl` and `urls` (up to 25).
   - The tool fetches each page live, honouring robots.txt Crawl-delay per host and the property's crawl rate, and stops after about 50 seconds. When `truncated` is true, the URLs in `notAudited` were not fetched: call again with `urls` set to that list and repeat until `notAudited` is empty.
   - On a slow or throttled site, batches of 10 finish more reliably than batches of 25. A site that keeps answering 429 can be crawled more gently with `update_site` (lower `crawlMaxConcurrency`, raise `crawlMinDelayMs`) once the user confirms the change; a read-only connection refuses it.
   - Read `auditedCount`, `skipped`, `contextRange` (the 28-day window behind `impressions` and `clicks`) and `summary`: `total_pages`, `total_issues`, `by_severity` (critical, high, medium, low, info), `indexable_pages`, `non_indexable_pages`. `summary` covers one call

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: page-deep-dive
description: Build a picture of one URL in a Search Console property with the GSC Wizard MCP tools: its daily click, impression, CTR and position series, the queries it wins and loses, its country and device split, stored and live URL inspection results (quota-aware), a single-page on-page audit, Core Web Vitals, and GA4 sessions, bounce rate and key events when GA4 is linked, ending in a page scorecard with recommendations. Use when the user asks "how is this page doing", "deep dive on this URL", "why did this page drop", "what does this page rank for", or names a single URL and wants everything about it.
---

# Page Deep Dive

Explain everything the connected tools know about one URL and condense it into a page scorecard (search, indexing, on-page, speed, engagement), the queries it wins and loses, and recommendations. The user's request may contain a property, the page URL or path, a date range, and a focus hint such as a country or "mobile only"; honor all of them.

## Workflow

1. **Resolve the property, the URL and the window.** 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.
   - The page must be a full URL. When the user gives only a path, build the URL from the property's host, and for a `sc-domain:` property confirm host and protocol against the rows of `query_top_pages` rather than guessing between www and the bare host.
   - Use the last 28 days compared with the previous period unless the user specifies dates. The daily tools take no comparison parameter, so compare the first and second half of the window yourself and say the delta is derived.
   - 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. **Daily series.** Call `get_page_performance` with `siteUrl`, `pageUrl` and the optional `startDate`/`endDate`. `daily` holds one row per day, oldest first, with clicks, impressions, `ctr` and position.
   - `ctr` values are already percentages on a 0-100 scale. Never multiply them by 100. `position`: lower is better, and a change toward a lower number is an improvement; never color it as a decline.
   - Describe the shape of the trend: flat, a step change on a named date, a gradual slide, a spike, or a weekly rhythm. Impressions rising while clicks stay flat point at the snippet or the position; impressions falling with position steady point at demand or indexing.
   - The `pageUrl` filter is an exact match on the full URL. When `daily` is empty the response carries `emptyBecause` and a `nextStep` that calls `query_search_analytics` with a page `contains` filter to list the URL variants Search Console records (trailing slash, protocol, host); rerun with the variant that carries the traffic and tell the user which one it was.

3. **Queries the page wins and loses.** Call `query_search_analytics` with `dimensions: ["query"]`, `filters: [{ "dimension": "page", "operator": "equals", "expression": "<page URL>" }]` and `rowLimit: 100`; follow `pagination.nextOffset` as `startRow` only when the user wants the long tail. Rows carry `keys` (the query), clicks, impressions, `ctr` on the 0-100 scale and position.
   - Sort the rows into winners (page 1 with clicks), near misses (position 11 to 20 with real impressions) and snippet losers (page 1 with far fewer clicks than the impressions suggest).
   - Query rows cover only the queries Google lists: quote the page total from `coverage.filteredTotals`, mention `coverage.hiddenClicksShare` (0-1) when it is large, and never sum the rows into a total.

4. **Markets and devices.** Repeat the same filtered call with `dimensions: ["country"]` and then `dimensions: ["device"]`; country codes come

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: portfolio-overview
description: Build an agency or multi-site portfolio view across every Search Console property on a GSC Wizard account. Lists owned and shared properties with their readiness (list_sites, get_account_info), ranks them by clicks against the prior period and names the sites that lost the most (get_cross_site_summary, optionally split by search type and country), reports each client tag's aggregated view (list_tags, get_tag_group_view), and manages tags and dashboard slots after confirmation (manage_tags, set_dashboard_visibility). Use when the user asks "how are all my sites doing", wants a client or portfolio overview, asks which site dropped the most, groups properties by client or tag, or asks which property to look at next.
---

# Portfolio Overview

Produce a cross-property view of the account: which sites carry the traffic, which lost the most, how each client tag performs, and which property deserves the next deep dive. The user's request may contain a tag name, a number of days, a search type, a focus hint ("only client X", "which sites dropped"), or a tag or visibility instruction; honor it when present.

## Workflow

1. **Inventory the account.** Call `get_account_info` (no arguments), then `list_sites` (no arguments), and read:
   - from `get_account_info`: `user`, `googleAccounts` (each with `email`, `isPrimary`, `scopes`, `connectedAt`), `subscription` (`plan`, `status`, `currentPeriodEnd`, `cancelAtPeriodEnd`, or null), `access.level` and `apiKey.scope`, which tells you up front whether the writes in steps 6 and 7 will be refused. If the response carries `warning`, a read failed: relay it and do not tell the user to connect Google or subscribe on the strength of empty fields.
   - from `list_sites`: owned properties first, then shared ones, each by `siteUrl`. Each row carries `siteUrl`, `tags`, `dataSource`, `permissionLevel`, `readable`, `activated` and, when known, `gscScope`; a shared row adds `sharedBy` (the owner) and `accessLevel` (`READ_ONLY` or `FULL`).
   - the readiness flags: `readable: false` means the property is listed in Search Console but not verified, so every read of it fails until the user verifies it; `activated: false` means an owned property is neither on the dashboard nor synced, so the other tools refuse it and the portfolio tools leave it out. Count owned, shared, unreadable and not-activated properties for the account line.
   - the empty and error cases: if the list is empty, relay `emptyBecause` and `nextStep`; if the call errors with reason `google_account_disconnected`, relay its message (reconnecting Google on the Account page fixes it; re-authorizing this integration does not).

2. **Set the window.** Use `days: 28` unless the user asks for another length (1 to 180). The portfolio tools take no dates: they count `days` back from today minus 3 (the Search Console lag) and compare with the same-length window before it, and each response states the exact `range` and `comparison` dates, so quote those. GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and if the newest days of a daily trend look low, say it is likely reporting lag, not a real drop. `searchType` defaults to `web` (also `image`, `video`, `news`, `discover`).

3. **Portfolio totals and per-site ranking.** Call `get_cross_site_summary` with `days` and no `tag`, so the properties shared with the account are included (`shared: true` on their rows). Add `includeSearchTypes: true` only when the user asks about the Discover, image, video or news mix (five extra reads per property), and `includeCountries: true` with `countryLimit` (default 25, max 250) when markets matter (one extra read per property). Read out of the response:
   - `scope` (`siteCount`, `sharedCount`, `truncated`), `range`, `comparison`, `current` and `previous` (`clicks`, `impressions`), `deltas`.
   - `sitesIncluded`, `sitesFailed` and `warning`: when `warning` is set, the totals cover only part of the

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: property-setup
description: Onboard a new client site into GSC Wizard and get it ready for the other skills; checks the account and plan with get_account_info, inventories list_sites, registers Search Console properties with add_site or creates folder-level ones with create_gsc_property, shows them on the dashboard, sets tags, branded keywords, sitemap URLs and crawl rate with update_site, manages filter presets, unregisters a property on request, and hands back a setup checklist and the first skills to run. Use when the user says "add my site", "onboard a new client", "set up this property", "register example.com", "create a property for /blog/", "set branded keywords", "save a filter preset" or "remove this property".
---

# Property Setup

Take a property from "not in GSC Wizard" (or half configured) to ready for the analysis skills, and hand back a checklist of what was done and what still needs the user. The user's request may contain the property (a GSC site URL or a recognizable site name), a client name to use as a tag, brand terms, sitemap URLs, folder paths to create as separate properties, filter presets to save, or a request to remove a property; honor what is given and ask for the rest only when a step needs it.

## Workflow

1. **Check the account first.** Call `get_account_info` (no arguments) and read:
   - `googleAccounts` (`email`, `scopes`, `isPrimary`): an empty list with `emptyBecause` means no Google account is connected, so send the user to tool.gscwizard.com/account unless they only use properties shared with them.
   - `subscription` (`plan`, `status`, `currentPeriodEnd`, `cancelAtPeriodEnd`) and `access.level`: `paid` means the property tools will run. A `payment_required` refusal on this first call means there is no running trial or active paid plan (the free tier serves only the GSC Wizard mobile app, so from an MCP client every tool refuses): tell the user to start or renew a plan at tool.gscwizard.com/settings/subscription, mark every step as blocked, and stop. `unknown`, or a `warning` saying a read failed, means retry before acting on those fields.
   - `apiKey.scope`: `read` means every write below needs write access, so report those steps as "needs write access" instead of attempting them.

2. **Inventory what is registered.** Call `list_sites` (no arguments) and show a compact table of `siteUrl`, `tags`, `permissionLevel`, `readable`, `activated`, `gscScope` and, on shared rows, `sharedBy` and `accessLevel`. Read the flags like this:

   | Flag | Meaning | What to do |
   |---|---|---|
   | `readable: false` | Listed in Search Console but not verified (`permissionLevel` is `siteUnverifiedUser`); Google refuses every data request | The user verifies it at search.google.com/search-console; no tool here can fix it |
   | `activated: false` | Registered but hidden from the dashboard and not synced; every other property-scoped tool refuses it | Show it in step 5 |
   | `gscScope: "readonly"` | The Google connection behind it has read-only Search Console access; Google refuses `submit_sitemap` and `create_gsc_property` | The user reconnects that Google account with full access in the app |
   | `sharedBy` present | Someone else's property; `accessLevel` `READ_ONLY` refuses every write in this skill, `FULL` allows `update_site` and presets | Only the owner can delete it or create properties under it |

   If the user's property is already listed, skip to step 5 or 6. An empty list carries `emptyBecause` and `nextStep`; relay them.

3. **Register a property that already exists in Search Console.** 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/`. If several plausible properties exist, ask the user which one before continuing. List the exact URL and tags, confirm, then call `add_site` with:
   - `siteUrl`: must already be in Search Console and verified for a connected Google account; the schem

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: query-deep-dive
description: Build a picture of one query for a Search Console property with the GSC Wizard MCP tools: its click, impression, CTR and position series, the pages Google serves for it, its country and device split, whether several pages cannibalize it, its estimated GA4 value when GA4 is linked, and Bing keyword demand plus the pages Bing ranks for it, condensed into a query scorecard with recommendations. Use when the user names one keyword and asks "how am I doing for X", "why did I lose rankings for X", "which page ranks for X", "deep dive on this keyword", or "what is the demand for X on Bing".
---

# Query Deep Dive

Explain everything the connected tools know about one keyword and condense it into a query scorecard, the pages serving it, where it ranks by market and device, and recommendations. The user's request may contain a property, the query text, a date range, a market or device, and a focus hint such as "compare with Bing"; honor all of them.

## Workflow

1. **Resolve the property, the query and the window.** 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.
   - Take the query text exactly as given; the tools below match it exactly, and step 2 says what to do when no row matches.
   - Use the last 28 days compared with the previous period unless the user specifies dates. The daily tool takes no comparison parameter, so compare the first and second half of the window yourself and say the delta is derived.
   - 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. **Daily series.** Call `get_query_performance` with `siteUrl`, `query` and the optional `startDate`/`endDate`, leaving `pageUrl` out so the query is measured site-wide. `daily` holds one row per day, oldest first, with clicks, impressions, `ctr` and position.
   - `ctr` values are already percentages on a 0-100 scale. Never multiply them by 100. `position`: lower is better, and a change toward a lower number is an improvement; never color it as a decline.
   - Describe the shape: flat, a step change on a named date, a slide, a spike, or seasonality. Position worsening with impressions steady is a ranking loss; impressions falling with position steady is demand; clicks falling with both steady is the snippet or a SERP feature.
   - The `query` filter is an exact match. When `daily` is empty the response carries `emptyBecause`: call `query_search_analytics` with `dimensions: ["query"]` and `filters: [{ "dimension": "query", "operator": "contains", "expression": "<core term>" }]` to list the variants Google records (plural, word order, accents), pick the one with the most impressions or roll the close variants up, and say which you did.
   - Once step 3 names the top page, call `get_query_performance` again with `pageUrl` set to it; the gap between the page series and the site-wide series is the share other pages take.

3. **Pages serving the query.** Call `query_search_analytics` with `dimensions: ["page"]`, `filters: [{ "dimension": "query", "operator": "equals", "expression": "<query>" }]` and `rowLimit: 50`. Rows carry `keys` (the URL), clicks, impressions, `ctr` (0-100) and position.
   - One page holding most impressions is a clear owner; two or more with comparable impressions and different positions is a split, which step 5 scores.
   - Quote the query total from `coverage.filteredTotals` rather than summing rows.

4. **Markets and devices.** Repeat the same filtered call with `dimensions: ["country"]` and then `dimensions: ["device"]`; country codes come back as lowercase ISO 3166-1 alpha-3 (`usa`) and device values as uppercase (`MOBILE`), and an `equals` filter

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: quick-wins
description: Find and rank quick-win SEO opportunities for a Search Console property by combining opportunity scoring, position distribution, CTR-curve underperformance, and striking-distance click-upside estimates from the GSC Wizard MCP server, then merge everything into one prioritized action list with expected impact and effort. Use when the user asks for quick wins, low hanging fruit, easy SEO improvements, striking distance keywords, or which pages or queries to optimize first for the fastest gains.
---

# Quick Wins

Build a single prioritized list of quick-win SEO opportunities for one property. The user may pass a property or a focus hint in their request (for example a site URL, a country, or "focus on product pages").

## Step 1: Resolve the property

1. 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/`.
2. Otherwise call `list_sites`. If exactly one plausible match exists, use it and say which one you picked. If several are plausible, ask the user which property to analyze before running anything else.
3. If any call fails with an authentication or subscription error, stop and tell the user to reconnect the GSC Wizard app from their app or connector settings, and that a GSC Wizard account with an active plan or trial plus a connected Google Search Console account is required.

## Step 2: Set the date range

Default to the last 28 days compared with the previous period, unless the user specifies otherwise. GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and if a dip is visible at the very edge of the range, say explicitly that it is probably the reporting lag, not a real drop.

## Step 3: Gather the four signals

Run these for the resolved property and date range. They are independent, so call them together where possible.

1. `score_opportunities`: the core scored list. It ranks queries at positions 3-30 by an impression-weighted opportunity score favoring near-threshold positions with low CTR, and estimates the extra clicks available. Keep the top 15-25 rows.
2. `get_position_distribution` (granularity `period`): size the striking-distance set. Report how many queries and impressions sit in the 4-10 and 11-20 bands versus 1-3 and 21+. The 4-10 band plus the lower half of 11-20 approximates the classic striking-distance zone (roughly positions 4-15); say so rather than pretending the bands match exactly. This frames how big the total opportunity is.
3. `analyze_ctr_curve`: the property's actual CTR by position bucket (1-20) versus industry benchmarks. Negative deltas mean the bucket underperforms its expected CTR; deltas are in percentage points. Note which position buckets underperform most, then use them to flag scored queries sitting in those buckets as likely title/meta problems rather than pure ranking problems.
4. `find_page_poaching_opportunities`: queries ranking just outside the top spots (defaults: positions 4-20, target position 3) with the estimated click upside of pushing each to the target. Check `ctrSource` in the response: "own" means the upside was computed from the property's own CTR curve; a benchmark key means the property had no data at the target position and an industry benchmark was used instead, so label those estimates accordingly.

None of these four tools accept dimension filters. If the user gave a focus hint, apply it after merging in Step 4: for a page or section focus, filter using the page mapping; for a country or device focus, say that these signals aggregate all countries and devices, and cross-check the top items with a `query_search_analytics` call using a matching country or device filter before recommending them.

## Step 4: Merge, deduplicate, rank

1. Build one combined list keyed by query; all four tools return query-level rows, none returns a page. A query that appears in both `score_opportunities` and `find_page_poaching

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: ranking-changes
description: Compare search rankings between any two periods for one Search Console property with the GSC Wizard MCP tools: new, lost, improved and declined queries and pages, movement between position bands, daily drill-downs on the top movers in each direction, and the Google updates or logged site changes that explain them. The user picks both windows, from last week against the week before to this quarter against the same quarter last year. Use when the user asks "what moved up or down", "winners and losers", "which keywords dropped", "ranking changes since", "compare this month with last month", or "year over year rankings".
---

# Ranking Changes

Report the winners and losers between two periods on one property and explain the biggest moves. Unlike the weekly-report skill, which is a fixed digest over the last settled week, this skill lets the user choose both windows, including year over year. The user's request may contain a property, the two periods in any phrasing ("September vs August", "last 14 days vs the 14 before", "Q3 2026 vs Q3 2025"), a dimension to lead with (queries or pages), a search type, and a focus hint such as a country or a section; honor each.

## 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.

2. **Fix the two windows.** The default is the last 28 settled days compared with the previous 28, which is what the tools use when all four date fields are omitted. Otherwise:
   - Translate the user's phrasing into `startDate`/`endDate` (the current window) and `comparisonStartDate`/`comparisonEndDate` (the baseline) as YYYY-MM-DD, and keep both windows the same length.
   - Keep the newest 2 days out of the current window: GSC data lags about 2 to 3 days, so 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.
   - For year over year, use the same calendar dates one year earlier; on a site with a weekly rhythm shift by 364 days rather than 365 so the weekdays line up.
   - State both windows on the first line of the output. If `get_position_distribution` answers the baseline window with `emptyBecause`, or `get_ranking_changes` files nearly every key as `new` with an empty `lost` bucket (its own `emptyBecause` appears only when both periods are empty), the stored history does not reach that far; say so instead of guessing.

3. **Query movers.** Call `get_ranking_changes` with `dimension: "query"`, the four dates from step 2, and `limit: 50` (per bucket, 1 to 10000; raise it to 200 on a large property). Pass `searchType` only when the user asked for image, video or news; the default is web.
   - Read `counts` for the full size of each bucket, then the buckets `new`, `lost`, `improved` and `declined`.
   - Each row carries `key`, `clicks`, `impressions`, `ctr`, `position`, `prevClicks`, `prevImpressions`, `prevPosition` and `positionDelta` (prevPosition minus position: positive is an improvement, negative a decline; a new or lost key's missing side reads 0).
   - `improved` and `declined` arrive sorted by the size of the position move, `new` by `clicks` and `lost` by `prevClicks`; re-rank improved and declined by click impact (`clicks` for improved, `prevClicks` for declined) before choosing the rows to show.
   - Note `dataSource`: on the live API a key just below the scan cut can show as new or lost, so treat small new and lost rows there with care.

4. **Page movers.** Repeat the call with `dimension: "page"`.
   - Match page losers against query losers: a page that lost its top queries is the unit to fix.
   - A query that moved although its page held means another page on the site took it over, which is the ca

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: shopping-performance
description: Analyze how a store's products perform in Google's free listings and against the market, using the GSC Wizard MCP Search Console and Merchant Center tools: merchant-listing performance, organic shopping clicks, impressions and conversions per offer or brand, price position against the market benchmark, best-seller rankings and the demand the catalog does not cover, competitive visibility by country and category, and raw Merchant Center queries when the fixed tools fall short. Use when the user asks "how are my products doing in Shopping", "which offers get the most free-listing clicks", "am I priced above the market", "who are my Shopping competitors", or "which best sellers am I missing".
---

# Shopping Performance

Report how one store's products perform in Google's free listings and how they stand against the market, ending with the offers and prices to act on. The user's request may contain a property, a date range, a country (ISO 3166-1 alpha-2), a Google product taxonomy category id, a brand or offer id, or a focus hint such as "pricing" or "competitors"; honor it by going deeper there, but still run the core steps.

## Workflow

1. **Resolve the property and the window.** 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. Then fix the window:
   - Use the last 28 days compared with the previous period unless the user specifies dates; omitting both `startDate` and `endDate` gives the default window.
   - For the Search Console data in step 2, 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.
   - Merchant Center (steps 3 to 7) reports on its own calendar and carries no `partialDays` flag, so say that the newest day may still fill in rather than reading it as a drop, and the best-seller reports lag up to two weeks.
   - Neither performance tool takes a comparison range: for a period-over-period view call it a second time with explicit prior-period dates and derive the deltas yourself, saying so.

2. **Merchant listings in web Search.** Call `get_merchant_listings_performance` with `siteUrl` and the default `appearance: "MERCHANT_LISTINGS"` unless the user asks for another code (`limit` default 25, max 1000, top pages by clicks; `includeAppearances` defaults to true). Read:
   - `hasAppearance` and `appearances` first: that breakdown is the only way to learn which search appearance codes the property has (`PRODUCT_SNIPPETS` and `ORGANIC_SHOPPING` are common) and how big each one is.
   - `totals`, the daily `timeline` and the top `pages`.
   This is always the live Search Console API: it counts enriched product results in web Search only, the appearance can only be filtered on and never grouped with another dimension, the window is capped at 16 months, and the call costs 3 rate-limit units. `ctr` values are already percentages on a 0-100 scale. Never multiply them by 100. `position`: lower is better. A change toward a lower number is an improvement; never color it as a decline.

3. **Organic shopping performance.** Call `get_organic_shopping_performance` with `siteUrl`, `groupBy: "offer"` (the default; the enum also allows `"brand"`, `"category"` for Google taxonomy level 1 and `"productType"` for the merchant's own taxonomy), `limit` (default 25, max 200, ordered by organic clicks) and `includeNonProduct` (default true). Read `totals` and the daily `timeline` (`clicks`, `impressions`, `ctr`, `conversions`, `conversionValue` in `currencyCode`), the `rows[]` (`key`, `title` and the same metrics) and `nonProductTimeline` for clicks to category and home pages. The `ctr` here is on the same 0-100 scale as step 2, so never

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: site-audit
description: Run a comprehensive SEO health audit of a single Search Console property using the GSC Wizard MCP tools, covering a 28-day performance overview with comparison, ranking mix, significant movers, anomalies, content decay, cannibalization, opportunity scoring, and Core Web Vitals, synthesized into a health verdict, top risks, top opportunities, and a prioritized action plan. Use when the user says things like "audit my site", "SEO health check", "how is my site doing in search", "give me a full SEO audit", or asks for an overall assessment of a property's organic search health.
---

# Site Audit

Run a full SEO health audit of one property and synthesize the results into a verdict and action plan. The user's request may contain a property name or URL and an optional focus hint (for example "focus on decay"); honor the hint by going deeper on that section, but still run the full audit.

## Step 1: Resolve the property

1. 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/`.
2. Otherwise call `list_sites`. If exactly one plausible property matches, use it and say so. If several match, show them in a short table and ask the user which one before proceeding.
3. Use the last 28 days compared with the previous period unless the user specifies dates. You may omit date parameters entirely; the performance tools default to the last 28 settled days with the prior same-length period as comparison. 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.

## Step 2: Gather the data

Call these tools for the resolved property. Keep going if one fails; note the gap and continue.

4. `get_site_summary`: clicks, impressions, CTR, and average position with the prior-period comparison. This anchors the verdict.
5. `get_position_distribution`: the ranking mix across bands (1-3, 4-10, 11-20, 21+). Note where impressions concentrate and whether the mix shifted versus the comparison period.
6. `get_ranking_changes`: new, lost, improved, and declined queries between the two periods. Pull the largest movers by click impact.
7. `detect_anomalies`: anomalous spike or drop days for clicks over the range. Record severity and dates; cross-reference dates with the movers from step 6.
8. `get_decay_overview`: the decay pressure picture (per-query or per-page metric matrix over recent complete months; this tool defaults to whole months rather than the 28-day window). Judge how much of the property's traffic sits in decaying rows versus stable or growing ones.
9. `analyze_cannibalization`: queries where two or more pages compete, scored by impression-split entropy. Keep this high level: report how widespread it is and the 3 to 5 worst affected queries, not an exhaustive list.
10. `score_opportunities`: impression-weighted opportunities favoring near-threshold positions with low current CTR (positions 3-30). These are the fastest wins.
11. `get_core_web_vitals`: CrUX field data with ratings and week-over-week regressions. If it returns `notConfigured`, say the Chrome UX Report connection is not set up in the app and skip page experience rather than guessing.

## Step 3: Interpretation rules

- `ctr` values are already percentages on a 0-100 scale. Never multiply them by 100.
- `position`: lower is better. A change toward a lower number is an improvement; describe it as such and never color it as a decline.
- Present every multi-row result as a compact markdown table (top rows only, typically 5 to 10); keep prose for interpretation, not for restating numbers.
- Weight findings by click and impression volume: a 50% drop on a 10-click query matters less than a 5% drop on the top page.

## Step 4: Synthesize the audit

Produce these four sections, in order:

12. **Overall health verdict.** One short paragraph plus a

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: sitemap-audit
description: Audit sitemap health and coverage for a Search Console property with the GSC Wizard MCP tools: the submitted sitemaps with their errors, warnings and download dates (list_sitemaps), the join of one sitemap's URLs with Search Console metrics to find URLs that never show (get_sitemap_performance), stored inspection verdicts for those suspects without spending quota (list_url_inspections), the Bing side (get_bing_feeds), and, after confirmation, submitting or resubmitting published sitemaps (submit_sitemap). Use when the user asks "is my sitemap ok", "which sitemap URLs get no traffic", "sitemap errors", "resubmit my sitemap", "does Google read my sitemap", or about sitemap coverage.
---

# Sitemap Audit

Check the sitemaps a property has submitted, measure how much of one sitemap Google actually shows in search, group the URLs that never show by their likely cause, and, when the user wants it, submit or resubmit a published sitemap. The user's request may contain a property, a sitemap URL, a section path, a date range, or "bing"; use it to skip resolution, pick the sitemap, or widen the engine side. For a diagnosis that spends inspection quota, hand over to the indexing-health skill.

## 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. Note the property's `gscScope` from `list_sites` ("full" or "readonly"): step 6 depends on it. For the Bing side, `list_bing_sites` shows which sites Bing has verified (`isVerified` in `siteDetails`) and answers `notConfigured: true` when Bing Webmaster Tools is not connected.

2. **Submitted sitemaps.** Call `list_sitemaps` with `siteUrl`. Read `sitemaps[]`, sorted by `path`: `lastSubmitted`, `lastDownloaded`, `isPending`, `isSitemapsIndex`, `type`, `warnings`, `errors`, and `contents[]` with `type` and `submitted` per content type.
   - Google has deprecated `contents[].indexed` and it typically reads 0, so never present it as an indexed count or as evidence that nothing is indexed.
   - Flag `errors` above 0 (Google could not parse part of the file) and `warnings` above 0 (usually URLs that redirect, 404 or are blocked).
   - Flag `isPending` long after `lastSubmitted` (Google has not fetched it yet) and a `lastDownloaded` older than the site's publishing cadence (a daily news sitemap downloaded two weeks ago is stale).
   - An empty list carries `emptyBecause` and `nextStep`; say Search Console lists no sitemap and offer step 6.

3. **Coverage of the main sitemap.** Pick the sitemap the user named, else the sitemap index or the one with the most submitted URLs. Call `get_sitemap_performance` with `siteUrl`, `sitemapUrl` (it must be on the property host or a subdomain), `maxUrls` (default 500, max 2000) and, unless the user gave dates, no `startDate` or `endDate` so the join covers the last 28 settled days. `searchType` defaults to web.
   - GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and a URL published in the last few days with zero impressions is new, not broken.
   - Read `urlCount` (URLs extracted), `indexedInGscCount` (URLs with impressions above 0) and `range`; compute the share yourself and say so.
   - Read `urls[]`, sorted by clicks then impressions, highest first, each with `url`, `clicks`, `impressions`, `ctr` (a 0-100 percentage, never multiply it by 100) and `position` (lower is better); zeros mean the page had no Search Console data.
   - Read `truncated` with `scanLimit` and `truncationNote`: on the live API the join pages through the property's top pages by clicks and may not reach every sitemap URL, so a zero is then unknown rather than "no impressions" and `indexedInGscCount` is a lower bound. `dataSource` tells which path served t

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: site-migration
description: Check a site migration (a domain move, an HTTP to HTTPS switch, a URL restructure) before and after go-live with the migration tools of the GSC Wizard MCP server: the saved migrations, the health check around go-live (recovery, pace, momentum, projected milestones, URL success, a 0-100 risk score), the before-versus-after query and page winners and losers, the saved old-to-new redirect mappings, a quota-aware inspection of the worst new URLs, and a go-live annotation. Use when the user asks "how is the migration going", "did the site lose traffic after the domain move", "check my redirects", "which old URLs are not recovering", or wants a pre-launch baseline.
---

# Site Migration Check

Read out a site migration before or after go-live: how much of the old traffic the new setup has recovered, where the losses sit, which old URLs are unmapped or failing, and what to fix first. The user's request may contain the old and new property, a go-live date, a saved migration name, a mapping label, a URL prefix or regex pair for a move inside one property, or a focus such as "redirects" or "losers".

## Steps

1. **Resolve the properties.** 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. A migration has two sides:
   - for a domain move, side A is the old property and side B the new one, and both must be in `list_sites`;
   - for a protocol switch or a URL restructure inside one property, both sides are the same property split by a URL prefix or a regex;
   - the go-live date is required: ask for it when neither the user's request nor a saved migration supplies one, because `get_migration_health` refuses to run without a `goLiveDate` or a `migrationId` that carries one.

2. **Saved migrations.** Call `list_migrations` (no arguments).
   - Each entry carries `id`, `name`, `mode` (`cross-property`, `two-urls` or `regex`), `siteUrlA`, `siteUrlB`, `urlPrefixA` / `urlPrefixB` or `regexA` / `regexB`, `goLiveDate`, `windowStrategy`, `windowDays`, `yoyBaseline`, `mappingLabel`, `alertsEnabled`, `lastCheckedAt` and `lastHealth` (the daily re-check's last status, recovery, risk score and problem counts).
   - Pick the one the user means, or ask when several match.
   - An empty list carries `emptyBecause` (saved migrations are not available on the account, or none are saved) and `nextStep`; continue with explicit arguments, since nothing needs to be saved to run the analysis.

3. **Health check.** Call `get_migration_health` with `siteUrl` set to the OLD property (side A) and either `migrationId` (its saved setup fills in everything the arguments leave out) or `siteUrlB` plus `goLiveDate`.
   - Without a `migrationId` the tool always runs in cross-property mode, and omitting `siteUrlB` reads one property joined by path. The prefix or regex split of a move inside one property comes only from a saved migration, so without one use `compare_migration` (step 4) for that case.
   - Options: `windowStrategy` `recent` (default: the last `windowDays` days against the `windowDays` days before go-live), `from-go-live` (the first `windowDays` days after launch, dip included) or `full` (the 90 days before against every day since); `windowDays` 1 to 365 (default 28); `yoyBaseline: true` to compare with the same weeks a year earlier when the migration straddles a seasonal turn; `mappingLabel` to narrow the redirect mappings (`__none__` means unlabelled only); `onlyMapped: true` to count only the pages the mappings claim.
   - `health`: `status`, `headline`, `recoveryPct` (new clicks per day as a share of the old), `baselineClicksPerDay`, `currentClicksPerDay`, `daysSinceGoLive`, `stage`, `pace` (`status`, `expectedPct`, `ratio` against the stage's expected recovery), `momentum` (`status`, 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: traffic-drop
description: Diagnose why organic traffic dropped on one Search Console property using the GSC Wizard MCP tools. Dates the break with the change-point and anomaly detectors, sizes it with before and after windows, then tests causes in order: Google ranking updates, logged site changes, query and page ranking losses, position-band shifts, device or country segments, reporting artefacts, and deindexed tracked pages. Ends with the most probable cause, a runner-up, what the evidence rules out, and an optional annotation. Use when the user asks "why did my traffic drop", "clicks fell last week", "did the Google update hit me", "lost rankings", "traffic down since", or "what happened on" a date.
---

# 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.

4. **Size the drop.** Call `get_site_summary` with `startDate` set to the break date and `endDate` set to the latest settled date (both explicit, so the window is reproducible).
   - The response holds `current` and `previous` blocks with `clicks`, `impressions`, `ctr` and `avgPosition`; `previous` is the same-length window immediately before, which is the baseline. Derive the deltas yourself and say s

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: traffic-forecast
description: Project future clicks or impressions for a Search Console property with the GSC Wizard MCP tools and put the projection in a seasonal context: the seasonal-decomposition forecast with its auto-selected trendline (optionally a growth target, and a conversion rate plus order value for revenue), the same window last year, the monthly seasonal shape, a level-shift check on the history, and logged or planned changes. Use when the user asks "forecast my traffic", "how many clicks next quarter", "project organic traffic for next year", "what does seasonality look like", "set a realistic traffic target", or "estimate revenue from organic growth".
---

# Traffic Forecast

Project future clicks or impressions for one property, place the projection next to last year's numbers and the seasonal shape, and say what has to change to beat the baseline. Every projected figure is an estimate and is labelled as one. The user's request may contain a property, the metric (clicks or impressions), a horizon ("next quarter", "12 months"), a growth target, a conversion rate and average order value for a revenue view, or the window to compare year over year.

## Steps

1. **Resolve the property and the inputs.** 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. Then translate the horizon into `granularity` and `forecastPeriods`:
   - "next quarter" is `weekly` with 13 periods, "six months" `weekly` with 26 (the default), "next year" `monthly` with 12.
   - Weekly needs about 105 days of history (13 complete weeks) and monthly about 240 days (6 complete months), because the first and last period of the window are dropped as partial.

2. **Check whether the history is representative.** Call `detect_change_points` with `metric` set to the metric being forecast and `days: 180`; raise it to `480` to cover the forecast's full default history (the window must stay between 14 and 480 days). Read:
   - `changePoints`: each break carries `date`, `direction`, `changePercent`, and `beforeMean` / `afterMean`, which are window means over `windowDays` days either side of the break, not whole-period means (`segmentMeanBefore` / `segmentMeanAfter` cover the full segments).
   - A break dated inside the last 90 days means the series moved to a new level recently and the trendline will blend the old level with the new one. Say so, and offer to shorten `historyDays` to the days since the break, never below 90 and never below what the granularity needs.
   - When `beforeMean` is 0, `changePercent` is 0 by convention and the shift is traffic from zero, not "no change".
   - With `count` 0, `trendSummary` still carries the overall movement (`firstMean14d`, `lastMean14d`, `ratio`, `slopePerDay`, `direction`, `halfwayDate`); read `emptyBecause` and `nextStep` before calling the traffic stable.

3. **Run the forecast.** Call `forecast_traffic` with:
   - `siteUrl`, `metric` (`clicks` or `impressions`, default clicks), `granularity` (`weekly` or `monthly`) and `forecastPeriods` (1 to 104, default 26).
   - `historyDays`: the default 480 (90 to 1000; more history improves the seasonal indices) unless step 2 argued for a shorter fit.
   - `trendlineType` left on `auto`, which picks the best R-squared among `linear`, `polynomial`, `logarithmic`, `exponential` and `power`.
   - `growthRate` only when the user named a target: a decimal per forecast period, compounded by default (`compoundGrowth: true`), so 0.05 on a weekly forecast means +5% every week. Convert a yearly target first (a 20% yearly goal is about 0.0035 per week or 0.0153 per month) and state the conversion.
   - `additionalSessions` for a flat amount added to every period (a planned content batch, for example).
   - `cvr` (a decimal: 0.025 is 2.5%

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: weekly-report
description: Produce a weekly SEO performance digest for a Search Console property using the GSC Wizard MCP tools; compares a lag-adjusted 7-day window against the prior week, surfaces headline metrics, top query and page movers in both directions, ranking changes, trend breaks, Google algorithm update overlap, and logged site changes, then delivers a concise digest with watch items and recommendations. Use when the user asks for a weekly report, a weekly SEO update, "how did we do this week", a week-over-week summary, or a recurring performance digest for a site.
---

# Weekly SEO Report

Produce a concise weekly SEO performance digest for one Search Console property, using the GSC Wizard MCP tools. The user's request may contain a property (a GSC site URL or a recognizable site name) and/or a focus hint (a market, a site section, a topic); use it to resolve the property and to slant the analysis.

## Steps

1. **Resolve the property.** If the user (or the request) named a property, use it. Otherwise call `list_sites` first. Site URLs use GSC formats: `sc-domain:example.com` or `https://www.example.com/`. If several plausible matches exist, ask the user which one before continuing.

2. **Compute the date windows.** GSC data lags about 2 to 3 days, so offset the report week back by 3 days:
   - Current week: `today - 9` through `today - 3` (7 days inclusive).
   - Prior week: `today - 16` through `today - 10`.
   Use these exact windows in every dated call so all sections line up. If the user asks for a specific range, honor it, but keep the newest 2 days out of any window and say why. When presenting results, state the actual dates covered; do not imply the digest runs through today.

3. **Headline metrics.** Call `get_site_summary` with `days: 7`. This tool applies the same 3-day lag offset internally and returns a same-length prior-period comparison, so its window matches step 2. Report clicks, impressions, CTR, and average position with week-over-week change. `ctr` values are already percentages on a 0-100 scale; never multiply them by 100. Position: lower is better; a change toward a lower number is an improvement.

4. **Top query and page movers.** `query_top_queries` and `query_top_pages` take a single date range with no comparison parameter, so call each tool twice: once with the current week's `startDate`/`endDate` and once with the prior week's (use `limit: 50`). Join rows by query (or page), compute click and position deltas, and keep the largest gainers and largest decliners in each dimension.

5. **Ranking movement.** Call `get_ranking_changes` with `startDate`/`endDate` set to the current week, `comparisonStartDate`/`comparisonEndDate` set to the prior week, and `dimension: "query"`. If step 4 showed the movement is page-driven, call it again with `dimension: "page"`. Highlight notable entries from all four buckets: new, lost, improved, declined.

6. **Trend break check.** Call `detect_change_points` with `metric: "clicks"` and `days: 90`. If any detected change point falls inside or within a few days before the report week, the week's move is a sustained level shift rather than noise; note the before/after averages the tool reports.

7. **Algorithm update overlap.** Call `list_algo_updates` with `startDate` about 21 days before the current week's start (rollouts span days to weeks). Flag any update whose begin-to-end span overlaps the report week or the days just before it, and connect it to the movers where plausible.

8. **Logged site changes.** Call `list_annotations` with the property's `siteUrl`, `startDate` set to the prior week's start, and `endDate` set to the current week's end. Correlate deploys, content changes, and other logged events with the gains and losses.

## Output

Present the digest in this order, using compact markdown tables for multi-row data and prose only for interpretation:

1. **Headline**: one or two sentences with the week's dates and the four core metrics we

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: yandex-performance
description: Report Yandex Webmaster performance for a Search Console property with the GSC Wizard MCP server's Yandex tools: verification status and canonical mirror, site quality index (SQI), pages in search and excluded pages, open site problems by severity, the top Yandex queries with derived CTR and both position metrics, and the crawl and indexing trend with the pages that appeared in or were removed from Yandex search, with the Google totals alongside for scale, ending with recommendations. Use when the user asks "how is my site doing on Yandex", "Yandex traffic", "SQI", "top Yandex queries", "Yandex indexing", "pages in Yandex search", "Yandex problems", or about Yandex Webmaster.
---

# Yandex Performance

Report how a property stands in Yandex search (which matters mainly for Russian, Turkish, Kazakh, Belarusian and Uzbek traffic) and end with recommendations. The user's request may contain a property name or URL, a date range, a device (desktop, mobile or tablet) or a focus hint ("indexing", "queries", "problems"); honor it by going deeper on that part while still producing the full report.

## 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. The Yandex tools take that same GSC `siteUrl`. Yandex Webmaster tracks whole hosts, so a URL-prefix property with a path (such as `https://example.com/blog/`) is matched to its host and every figure covers the whole host; the response then says so in `limitations`.

2. **Confirm the Yandex side.** Call `list_yandex_sites` (no arguments; the host list is cached for ten minutes, so a site verified a moment ago can take that long to show). `sites[]` rows carry `hostId`, `url`, `unicodeUrl`, `verified` and `mainMirrorUrl`, and an `emptyBecause` answer means the connected account holds no sites yet. Only a site added and verified in Yandex Webmaster itself reports data, so a host with `verified: false` needs the owner to verify it there, which can take a few days. When `mainMirrorUrl` differs from `url`, Yandex keeps the data on the main mirror; name it.

3. **Read every `notConfigured` answer.** Each Yandex tool answers `notConfigured: true` with a `reason` and a `hint` instead of an error. Tell the user what each reason means and what to do:
   - `not_connected`: no Yandex account is connected to the property owner's GSC Wizard account; connect Yandex in the app.
   - `reauth`: the owner must reconnect Yandex in the app, because Yandex rejected the connection or the grant predates the `webmaster:verify` scope.
   - `host_not_found`: the host is not in the connected Yandex Webmaster account; add and verify it there.
   - `host_not_verified`: the site is in the account but Yandex has not verified it; verify it in Yandex Webmaster and expect no data until then.
   - `owner_only`: the property is shared, and Yandex reads use the owner's connection, which is not shared; only the owner can run this report.
   A Yandex 429 comes back as a `rate_limited` error whose message gives the retry delay in seconds, taken from Yandex's own reset time: wait that long before one retry and never loop. When Yandex refuses only a secondary section (the problem list, pages in search, the appeared/removed series), the tool keeps what it read and returns that section as `null` with an entry in `warnings` when the host is not verified, or empty with a warning after a rate limit or timeout; report the rest and call that section unknown, never clean or zero. Whatever the reason, still run the Google anchor in step 7.

4. **Site status.** Call `get_yandex_site_summary` with `siteUrl`. Read `sqi`, `pagesInSearch`, `excludedPages`, `problemCountsBySeverity` and `problems[]` (each with `code`, `severity` and `la

Preview of the first 4,000 characters. Read full instructions →