agentleFS
runxhqrunxhq/runx/skills/google-search-console/SKILL.md

google-search-console

Skill97 starsChanged 33 days agoApache-2.0View on GitHub

Read and normalize Google Search Console performance, indexing, site, and sitemap evidence through any compatible Runx connector; plan and govern sitemap submission without coupling the skill to credential custody or a connector vendor.

10 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use google-ads.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • webrenewSkill

    google-ads

    Plan, build, audit or run Google Ads search campaigns for a local service business (plumber, dentist, roofer, cleaner, lawyer, clinic) on a small budget, with the agent drafting and the owner approving every change that spends money. Use this skill for a new Google Ads account or campaign, keyword research from customer questions, match types, negative keywords, location targeting, responsive search ads and assets, landing page message match, conversion tracking from GA4 or the Google Ads tag, budgets and bidding, Local Services Ads, a weekly check, and when the user says "PPC", "Google Ads is not working", "too expensive per lead", "wasted ad spend", "search terms" or "should we run Google ads".

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 4 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when an operator needs Search Console evidence that another model or workflow can act on: which queries and pages are …

    line 8
  2. Distinctive:

    Start with the narrowest question.

    line 23
  3. Very specific:

    Use performance for live query/page/search-performance evidence.

    line 25
  4. Very specific:

    Use inspect-url for the current indexed state of one canonical URL.

    line 26
  5. Very specific:

    Use sites or sitemaps to discover accessible resources before assuming a property or sitemap exists.

    line 27
  6. Very specific:

    Use normalize-performance only when Search Console-shaped results were already supplied by a trusted import or connector test.

    line 29
  7. Very specific:

    Use plan-sitemap and then submit-sitemap for an exact, reviewable sitemap mutation.

    line 32
  8. Very specific:

    Use plan-indexing to test whether a request belongs in Google's restricted Indexing API lane.

    line 34
  9. Distinctive:

    Keep the exact scheme returned by Google, especially during migration diagnosis.

    line 46
  10. Distinctive:

    Stop when the property is ambiguous, the connector lacks the exact capability, the date range or dimensions do not match the decision, data …

    line 108

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Google Search Console

Use this skill when an operator needs Search Console evidence that another model or workflow can act on: which queries and pages are gaining or losing visibility, whether a URL is indexed, which properties and sitemaps are visible, or whether an exact sitemap should be submitted.

The skill owns the Search Console procedure and evidence shape. It does not own OAuth, credential storage, tenant configuration, or connector routing. A local, self-hosted, third-party, or Runx-hosted connector is equally valid when it implements the declared provider operations and scopes. Connector identifiers, credential handles, provider-config keys, service URLs, and tenant ids belong in the operator's Runx grant and connector configuration, never in this package or its packets.

Operating model

Start with the narrowest question.

  • Use performance for live query/page/search-performance evidence.
  • Use inspect-url for the current indexed state of one canonical URL.
  • Use sites or sitemaps to discover accessible resources before assuming a property or sitemap exists.
  • Use normalize-performance only when Search Console-shaped results were already supplied by a trusted import or connector test. Its packet says provider_status: not_called; it is not live-provider proof.
  • Use plan-sitemap and then submit-sitemap for an exact, reviewable sitemap mutation. Submission requires a matching scoped grant and provider readback.
  • Use plan-indexing to test whether a request belongs in Google's restricted Indexing API lane. Ordinary page-indexing requests are refused.

A useful performance run names the property, date range, search type, data state, and row bound. It defaults to the page dimension; supply another ordered set only when the decision needs it. Keep dimensions minimal: adding query, page, country, device, date, hour, or search appearance changes aggregation and can produce a much larger, privacy-filtered result. Use hourly_all only with the hour dimension; those rows are provisional and their timestamps use Google's reported offset.

HTTP and HTTPS URL-prefix properties are distinct Search Console identities. Keep the exact scheme returned by Google, especially during migration diagnosis; do not silently rewrite an HTTP property to HTTPS. Compare like with like and do not interpret a differently grouped query as a trend.

The performance packet preserves clicks, impressions, CTR, average position, aggregation type, pagination state, and Google's incomplete-data metadata. decision: usable_with_caveats means the evidence can inform exploration but must not be treated as a settled period. A packet with pagination.complete: false is a bounded slice, not the whole property. Search Console can omit low-volume queries and does not guarantee that row totals reproduce every chart total, so never manufacture missing rows or causal explanations.

URL inspection is a point-in-time observation. A non-indexed result does not by itself prove a defect or authorize a mutation. Check the canonical URL, robots state, fetch state, last crawl, sitemap references, and any rich-result verdict before proposing remediation.

Sitemap change boundary

plan-sitemap validates the property boundary and produces a native digest-bound plan. It does not call Google. submit-sitemap recomputes that binding, requires an admitted sitemaps.submit grant for the exact property and sitemap URL, sends one idempotent mutation through the configured connector, and reads the same sitemap back. Only the final submission packet may say provider_status: readback_verified.

A failed, missing, or identity-mismatched readback is not success. Keep the plan and receipt, inspect connector/provider evidence, and retry only with the same idempotency key when the intended mutation is unchanged.

Google's Indexing API is not a general "index this URL" API. This skill refuses ordinary articles, product pages, home pages, and arbitrary URLs. Eligible JobPosting or BroadcastEvent requests are marked specialist_required; this package deliberately does not execute them.

Connector capability contract

A compatible connector exposes provider google-search-console with these stable operations and scopes:

  • sites.list under sites.read, projecting sites.
  • search.analytics.query under search.analytics.read, projecting the property, request fields, rows, counts, aggregation, incomplete-data metadata, pagination, and fetch time.
  • url.inspect under url.inspect, projecting the inspected URL, property, index verdict fields, inspection link, and fetch time.
  • sitemaps.list and sitemaps.get under sitemaps.read.
  • sitemaps.submit under sitemaps.submit, accepting an idempotency key and returning the exact property and sitemap identity for readback.

The connector may acquire and refresh credentials however its operator chooses. It must enforce the Runx grant, project only declared result fields, keep secrets out of results and receipts, and preserve provider errors rather than converting them into empty success.

Handoffs and stop conditions

This is an evidence and bounded-provider skill. Feed its sealed packets to the operator or to a higher-level organic-growth workflow for comparison, diagnosis, and prioritized recommendations. Do not jump from a traffic change to an SEO claim without analytics, deployment, content, and business-context evidence.

Stop when the property is ambiguous, the connector lacks the exact capability, the date range or dimensions do not match the decision, data is incomplete beyond the operator's tolerance, a supplied packet lacks provenance, the sitemap falls outside the property, provider authority is absent, or provider readback cannot bind the exact resource.

The deterministic module exists only for Search Console domain work that generic Runx tools cannot express: mapping ordered row keys to named dimensions, preserving incomplete-data semantics, validating property coverage, and classifying restricted indexing requests. Runx owns digesting, authority, provider execution, idempotency, and receipts.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.