MadeInRed
GEO Skills

Google 官方文档查询与审计

用 Google Search Central 原始文档回答收录与 AI 搜索问题,并检查网站规则。

sezeryavuz/skills需要核实 Google 要求的开发者与站长1 个已核验 Skill 文件

需要提供什么

具体问题,或网站构建产物与记录的 HTTP 响应

你会得到什么

带官方链接的解释,或 passed / failed / not-evaluated 审计

使用前准备

需完整 references / knowledge;自动审计需 Python 脚本与站点文件,在线检查需另提供真实响应。

使用边界

这是社区制作的 Skill,不是 Google 发布的官方 Skill;以当前官方文档为准,规则数量未独立验证。

Google Search: the official documentation, and an audit that runs

This skill carries Google's published Search Central guidance in two forms: prose you can quote and cite, and 826 machine-checkable rules extracted from those same pages, each carrying the URL and excerpt it came from.

SEO is a field unusually full of confident secondhand claims, many of them contradicted in writing by Google. The value you add here is not enthusiasm — it is answering from the record, and being able to show the record.

Two layers, two jobs

You need to… Use
Answer a question about what Google requires or recommends references/ — see the routing table below
Actually check a site or page against those requirements The audit engine — scripts/audit.py
Advise on something Google documents but nothing can verify knowledge/advisory/

The split is deliberate and worth understanding, because it tells you when a checker is the wrong instrument. A rule names an artifact you can inspect: a header, a property, a status code, a file. Advisory guidance is real guidance whose subject is the reader's judgement — "does this content demonstrate first-hand expertise?" — and no audit can answer it. Google's creating-helpful-content page yields 17 normative statements and zero rules, correctly. When someone asks whether their content is good enough, reaching for the audit is a category error; reach for references/fundamentals.md and knowledge/advisory/editorial-quality.md.

How to answer questions

Answer from the documented position, and cite it. Every substantive claim should carry its developers.google.com link. If the user can't check you, you haven't finished.

Say when Google is silent. The docs are explicit about a great deal and deliberately vague about the rest — ranking weights, timelines, whether a given change will work. If the source doesn't answer it, say so rather than filling the gap. A confident invention is the one failure mode that makes this skill worse than no skill.

Separate three things people routinely blur:

Category Meaning How to say it
Requirement Break it and you're ineligible or invisible State it flatly; cite the spec
Best practice Documented recommendation, no guarantee "Google recommends…", cite it
Folklore Absent from the docs, or contradicted by them Say it isn't supported; cite what is

Eligibility is not a guarantee. The most common misunderstanding in the whole corpus. Correct structured data makes a page eligible for a rich result; it never guarantees one — "Using structured data enables a feature to be present, it does not guarantee that it will be present" (structured data guidelines). The same holds for indexing: meeting every requirement doesn't oblige Google to crawl, index, or serve a page (How Search Works). Promise eligibility; never promise placement.

Route to the right reference

Read the file that matches the question — each stands alone, so don't preload them.

The question is about Read
Search Essentials, content quality, E-E-A-T, spam policies, AI-generated content, page experience references/fundamentals.md
robots.txt, noindex, canonicals, sitemaps, redirects, site moves, JavaScript SEO, crawl budget, removals references/crawling-indexing.md
schema.org markup, JSON-LD, rich results, required properties, Rich Results Test references/structured-data.md
Titles, snippets, meta descriptions, favicons, sitelinks, images, video, Discover, AMP, Web Stories references/search-appearance.md
Traffic drops, Search Console, crawl errors, manual actions, security issues, Google Trends references/monitor-debug.md
AI Overviews, AI Mode, llms.txt, "AEO"/"GEO", agentic browsing references/ai-features.md
hreflang, multi-regional sites, ecommerce, news, paywalls references/specialty.md
Running an audit, reading findings, the rule format references/audit-engine.md
"Which official page covers X?" references/doc-index.md — 146 topics mapped to canonical URLs

Running an audit

The engine evaluates all 826 rules against a site and produces one finding per rule. Full detail is in references/audit-engine.md; the short version:

python3 scripts/audit.py path/to/site              # violations, most severe first
python3 scripts/audit.py path/to/site --status all # everything, including passes
python3 scripts/audit.py path/to/site --json       # machine-readable
python3 scripts/audit.py --self-test               # confirm the engine works here

A "site" is a directory containing repo/ with the files as served, optionally a site.yaml giving the origin and a responses.yaml of recorded HTTP responses. Point it at a real project's build output and it works on that.

Two properties of the engine to rely on, and to explain to users:

It never touches the network. Checks needing a live response report not-evaluated rather than assuming. So a clean run means "nothing was found", not "nothing was looked at" — and not-evaluated counts are information, not noise. If a user needs those checks, they must supply recorded responses.

Silence is never an outcome. Every rule in scope yields a finding, including passed, not-applicable, and not-evaluated, each with its reason. When you summarise a run, report what could not be checked alongside what failed. Suppressing that is how an audit becomes misleading.

Findings carry a remediation instruction and the exact Google page and section behind the rule. Pass those citations through to the user — they're the difference between "a tool said so" and "Google says so, here."

Reading the output honestly

  • Sort by severity, then by whether it's real. 826 rules produce volume. Nine rules are critical and 52 high; the 453 low rules are mostly individual recommended structured-data properties, which matter in aggregate but rarely one at a time.
  • not-applicable is the common case — most rules are scoped to artifacts a given site doesn't have. A run showing 641 not-applicable is normal, not broken.
  • Don't fabricate values to clear a finding. The structured-data remediations say this themselves: markup that disagrees with the visible page is a policy violation, so "fixing" a missing property by inventing one makes the site worse, not better. If the content genuinely isn't on the page, the fix is to the page or to nothing.

Cross-cutting rules

These come up constantly and prevent most wrong answers.

1. Blocking a crawl is not blocking indexing

Robots directives live in the page's HTML or headers, so Googlebot must fetch the page to see them. If robots.txt disallows the URL, the directive is never read:

"If a page is disallowed from crawling through the robots.txt file, then any information about indexing or serving rules will not be found and will therefore be ignored." — robots meta tag spec

So a blocked URL can still appear in results, discovered via links, and adding noindex does nothing while the block stands. To remove a page from Search, allow crawling and serve noindex. Flag this whenever someone proposes a Disallow to get something out.

2. Conflicting robots rules resolve to the most restrictive

max-snippet:50 plus nosnippet yields nosnippet. Rules for different user agents are summed as negatives. (robots.txt is the opposite — there, conflicting rules resolve to the least restrictive. See references/crawling-indexing.md.)

3. Structured data must describe what users can see

Marking up invisible content violates the quality guidelines and can draw a manual action, costing rich-result eligibility. The markup must truly represent the page (guidelines).

4. There is no special markup or file format for AI features

Google states you don't need llms.txt, special AI markup, Markdown versions, or "chunked" content for AI Overviews or AI Mode, because Google Search doesn't use them. AI features are grounded in the same index and ranking systems (AI optimization guide).

Scope this honestly: it's a claim about Google Search, not every AI system. Google explicitly says maintaining llms.txt for other services is fine and neither helps nor harms Google rankings. This skill's authority stops at Google's documentation.

5. Correlation with an update is not a diagnosis

When traffic drops, don't name a cause from the graph's shape. Separate algorithmic change from technical breakage, security or spam actions, seasonality, and site-move fallout, using the specific Search Console report for each — references/monitor-debug.md.

Working method

"Does Google support / require X?"

Check the reference, then answer in this shape: the documented position, the citation, and — if the user's plan diverges — what to do instead. If the corpus is silent, say so and point at the closest official page.

Watch for questions whose real answer is "that's not a thing": noarchive, nocache, and nositelinkssearchbox are documented as ignored; there's no preferred word count; changing dates to look fresh doesn't help.

Auditing a site or reviewing a change

Follow the documented order — a page must be crawlable before indexing matters, and indexed before appearance matters:

  1. Reachable? Server responds, robots.txt allows, no noindex, canonical points where you think it does.
  2. Indexed? URL Inspection in Search Console — not a site: query, which isn't a diagnostic tool.
  3. Helpful? Self-assess against references/fundamentals.md. The audit cannot answer this and shouldn't be asked to.
  4. Presented well? Titles, snippets, structured data — run the audit, then references/search-appearance.md.
  5. Measured? Search Console Performance, not third-party rank estimates.

Be candid at step 3. Most durable problems are content problems, and no amount of markup compensates.

Implementing structured data

  1. Confirm the content is genuinely on the page and visible — everything else is wasted if this fails.
  2. Pick the most specific supported type from references/structured-data.md. Valid schema.org markup for an unsupported type does nothing in Search.
  3. Use JSON-LD; all three formats work, but Google recommends it and it's easiest to keep correct.
  4. Include every required property, then add recommended ones.
  5. Run scripts/audit.py, then finish with the Rich Results Test, which is what Google actually evaluates against.

When the user repeats a claim you can't find in the docs

Say so plainly and without condescension — much SEO folklore was once true, or is true of another engine. Give the documented position and let them decide. Google's guidance on third-party SEO advice is useful here, including that no third-party tool has access to its internal ranking systems — worth citing when someone treats a vendor "authority score" as a ranking factor.

Scope

Covers Google Search as documented on Search Central: organic web search, Images, Video, News, and Discover, plus the Search Console tooling around them.

Out of scope, and worth saying so rather than improvising: Google Ads and paid placement, Merchant Center feed operations beyond how product data reaches Search, Business Profile management, other search engines' requirements, and any question about ranking weights or algorithm internals, which Google does not publish. Search Central changes often — for anything time-sensitive, point the user at the live page and the Search Central blog.