Update to GSC Wizard - SEO analysis
Snapshot Oct 28, 2026 · 12:05 UTC · version 3.0.5
Collection source: downloaded plugin package.
Instructions updated for indexing-health
Skill instructions — Now says: 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...
Observed in instructions or declared skills. Runtime behavior has not been tested.
Up to 3 plugins free · no card required.
All fields and original values.
Skill instructions
Oct 24, 2026 · 12:47 UTC
uses a read-only API key, call `inspect_url` for each URL instead, for at most 10 URLs, and mention that batch inspection needs a read & write key. Group the results by root cause from the verdict and coverage state, for example: 7. **Bi...
Oct 28, 2026 · 12:05 UTC
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: 7. **Bing (optional).** I...
Compare saved observations
Download comparison JSONSKILL.md text changes
− removed · + added
--- before +++ after @@ -17,7 +17,7 @@ 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 uses a read-only API key, call `inspect_url` for each URL instead, for at most 10 URLs, and mention that batch inspection needs a read & write key. Group the results by root cause from the verdict and coverage state, for example: +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 @@ -27,7 +27,7 @@ 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, call `get_bing_crawl_issues` for URLs with 4xx/5xx errors, robots blocks, redirect problems, or malware flags; a `notConfigured` response means no Bing API key is linked, so mention that and move on. When the user wants pages (re)submitted, ALWAYS list the exact URLs and ask for confirmation first, then call `submit_indexnow_urls` (up to 100 URLs). Explain that a 202 response means accepted with key validation pending, not confirmation of delivery or indexing; `list_indexnow_submissions` shows the submission history. +7. **Bing (optional).** If the user cares about Bing or asked to (re)submit pages, call `get_bing_crawl_issues` for URLs with 4xx/5xx errors, robots blocks, redirect problems, or malware flags; a `notConfigured` response means Bing Webmaster Tools is not connected in the app, so mention that and move on. When the user wants pages (re)submitted, ALWAYS list the exact URLs and ask for confirmation first, then call `submit_indexnow_urls` (up to 100 URLs). Explain that a 202 response means accepted with key validation pending, not confirmation of delivery or indexing; `list_indexnow_submissions` shows the submission history. ## Output
Full technical diff · 1 changed fields
changed /skill_md_contents
"---\nname: indexing-health\ndescription: 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\".\n---\n\n# Indexing Health Check\n\nDiagnose 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.\n\n## Workflow\n\n1. **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.\n\n2. **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.\n\n3. **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.\n\n4. **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.\n\n5. **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 uses a read-only API key, call `inspect_url` for each URL instead, for at most 10 URLs, and mention that batch inspection needs a read & write key. Group the results by root cause from the verdict and coverage state, for example:\n - Crawled - currently not indexed\n - Discovered - currently not indexed (not yet crawled)\n - Excluded by noindex\n - Google chose a different canonical than the user-declared one\n - Page with redirect, or Not found (404), still listed in the sitemap\n - Blocked by robots.txt\n\n6. **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).\n\n7. **Bing (optional).** If the user cares about Bing or asked to (re)submit pages, call `get_bing_crawl_issues` for URLs with 4xx/5xx errors, robots blocks, redirect problems, or malware flags; a `notConfigured` response means no Bing API key is linked, so mention that and move on. When the user wants pages (re)submitted, ALWAYS list the exact URLs and ask for confirmation first, then call `submit_indexnow_urls` (up to 100 URLs). Explain that a 202 response means accepted with key validation pending, not confirmation of delivery or indexing; `list_indexnow_submissions` shows the submission history.\n\n## Output\n\nPresent findings as an indexing issue summary grouped by cause, as a compact markdown table:\n\n| Cause | Affected URLs | Examples | Fix |\n|---|---|---|---|\n\nKeep prose for interpretation. Map causes to concrete fixes, for example:\n- Discovered, not crawled: improve internal linking to those URLs, reduce low-value URLs competing for crawl budget.\n- Crawled, not indexed: strengthen or consolidate thin/duplicate content; these pages were seen and judged not worth indexing.\n- Noindex: remove the tag/header if unintentional.\n- Canonical mismatch: align declared canonicals with the pages you want indexed, deduplicate near-identical pages.\n- Redirects/404s in sitemap: regenerate the sitemap so it only lists 200-status canonical URLs.\n- Robots blocked: fix the robots.txt rule.\n\nEnd with a short prioritized list of concrete recommendations (highest impact first), including whether a follow-up inspection run is worthwhile once fixes ship and roughly how much quota that will need.\n\n## Error handling\n\nIf any tool call fails with an authentication or subscription error, 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. If a single tool fails for another reason, report it, skip that step, and continue with the rest of the check.\n\n## Grounding\n\nEvery number you report must name the tool it came from and the date range it covers, for example \"clicks 12,340 (`get_site_summary`, 2026-09-21 to 2026-09-27)\". For a table, state the tool and date range once on the line above it. If you derive a figure yourself (a delta, a sum, a share), say so and name the tool outputs it was computed from. Never report a number no tool returned.\n"
"---\nname: indexing-health\ndescription: 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\".\n---\n\n# Indexing Health Check\n\nDiagnose 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.\n\n## Workflow\n\n1. **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.\n\n2. **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.\n\n3. **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.\n\n4. **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.\n\n5. **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:\n - Crawled - currently not indexed\n - Discovered - currently not indexed (not yet crawled)\n - Excluded by noindex\n - Google chose a different canonical than the user-declared one\n - Page with redirect, or Not found (404), still listed in the sitemap\n - Blocked by robots.txt\n\n6. **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).\n\n7. **Bing (optional).** If the user cares about Bing or asked to (re)submit pages, call `get_bing_crawl_issues` for URLs with 4xx/5xx errors, robots blocks, redirect problems, or malware flags; a `notConfigured` response means Bing Webmaster Tools is not connected in the app, so mention that and move on. When the user wants pages (re)submitted, ALWAYS list the exact URLs and ask for confirmation first, then call `submit_indexnow_urls` (up to 100 URLs). Explain that a 202 response means accepted with key validation pending, not confirmation of delivery or indexing; `list_indexnow_submissions` shows the submission history.\n\n## Output\n\nPresent findings as an indexing issue summary grouped by cause, as a compact markdown table:\n\n| Cause | Affected URLs | Examples | Fix |\n|---|---|---|---|\n\nKeep prose for interpretation. Map causes to concrete fixes, for example:\n- Discovered, not crawled: improve internal linking to those URLs, reduce low-value URLs competing for crawl budget.\n- Crawled, not indexed: strengthen or consolidate thin/duplicate content; these pages were seen and judged not worth indexing.\n- Noindex: remove the tag/header if unintentional.\n- Canonical mismatch: align declared canonicals with the pages you want indexed, deduplicate near-identical pages.\n- Redirects/404s in sitemap: regenerate the sitemap so it only lists 200-status canonical URLs.\n- Robots blocked: fix the robots.txt rule.\n\nEnd with a short prioritized list of concrete recommendations (highest impact first), including whether a follow-up inspection run is worthwhile once fixes ship and roughly how much quota that will need.\n\n## Error handling\n\nIf any tool call fails with an authentication or subscription error, 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. If a single tool fails for another reason, report it, skip that step, and continue with the rest of the check.\n\n## Grounding\n\nEvery number you report must name the tool it came from and the date range it covers, for example \"clicks 12,340 (`get_site_summary`, 2026-09-21 to 2026-09-27)\". For a table, state the tool and date range once on the line above it. If you derive a figure yourself (a delta, a sum, a share), say so and name the tool outputs it was computed from. Never report a number no tool returned.\n"
Full snapshot data
{
"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\".",
"included_files": [],
"name": "indexing-health",
"skill_md_contents": "---\nname: indexing-health\ndescription: 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\".\n---\n\n# Indexing Health Check\n\nDiagnose 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.\n\n## Workflow\n\n1. **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.\n\n2. **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.\n\n3. **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.\n\n4. **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.\n\n5. **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:\n - Crawled - currently not indexed\n - Discovered - currently not indexed (not yet crawled)\n - Excluded by noindex\n - Google chose a different canonical than the user-declared one\n - Page with redirect, or Not found (404), still listed in the sitemap\n - Blocked by robots.txt\n\n6. **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).\n\n7. **Bing (optional).** If the user cares about Bing or asked to (re)submit pages, call `get_bing_crawl_issues` for URLs with 4xx/5xx errors, robots blocks, redirect problems, or malware flags; a `notConfigured` response means Bing Webmaster Tools is not connected in the app, so mention that and move on. When the user wants pages (re)submitted, ALWAYS list the exact URLs and ask for confirmation first, then call `submit_indexnow_urls` (up to 100 URLs). Explain that a 202 response means accepted with key validation pending, not confirmation of delivery or indexing; `list_indexnow_submissions` shows the submission history.\n\n## Output\n\nPresent findings as an indexing issue summary grouped by cause, as a compact markdown table:\n\n| Cause | Affected URLs | Examples | Fix |\n|---|---|---|---|\n\nKeep prose for interpretation. Map causes to concrete fixes, for example:\n- Discovered, not crawled: improve internal linking to those URLs, reduce low-value URLs competing for crawl budget.\n- Crawled, not indexed: strengthen or consolidate thin/duplicate content; these pages were seen and judged not worth indexing.\n- Noindex: remove the tag/header if unintentional.\n- Canonical mismatch: align declared canonicals with the pages you want indexed, deduplicate near-identical pages.\n- Redirects/404s in sitemap: regenerate the sitemap so it only lists 200-status canonical URLs.\n- Robots blocked: fix the robots.txt rule.\n\nEnd with a short prioritized list of concrete recommendations (highest impact first), including whether a follow-up inspection run is worthwhile once fixes ship and roughly how much quota that will need.\n\n## Error handling\n\nIf any tool call fails with an authentication or subscription error, 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. If a single tool fails for another reason, report it, skip that step, and continue with the rest of the check.\n\n## Grounding\n\nEvery number you report must name the tool it came from and the date range it covers, for example \"clicks 12,340 (`get_site_summary`, 2026-09-21 to 2026-09-27)\". For a table, state the tool and date range once on the line above it. If you derive a figure yourself (a delta, a sum, a share), say so and name the tool outputs it was computed from. Never report a number no tool returned.\n"
}SHA-256 of public snapshot: d51f274ff5a6473b0999da5a67d732e8c7a5e43d9c60c4e1640a32b9af446033