需要提供什么
具体问题,或网站构建产物与记录的 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:
- Reachable? Server responds, robots.txt allows, no
noindex, canonical points where
you think it does.
- Indexed? URL Inspection in Search Console — not a
site: query, which isn't a
diagnostic tool.
- Helpful? Self-assess against
references/fundamentals.md. The audit cannot answer
this and shouldn't be asked to.
- Presented well? Titles, snippets, structured data — run the audit, then
references/search-appearance.md.
- 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
- Confirm the content is genuinely on the page and visible — everything else is wasted
if this fails.
- Pick the most specific supported type from
references/structured-data.md. Valid
schema.org markup for an unsupported type does nothing in Search.
- Use JSON-LD; all three formats work, but Google recommends it and it's easiest to keep
correct.
- Include every required property, then add recommended ones.
- 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.
---
name: google-official-seo-docs
description: Authoritative answers about Google Search from Google's own Search Central documentation, plus an executable audit of 826 extracted rules. Covers crawling and indexing, robots.txt, robots meta tags, canonicalization, sitemaps, redirects and site moves, JavaScript SEO, structured data and rich results, titles and snippets, page experience, hreflang, ecommerce markup, AI Overviews and AI Mode, spam policies, and diagnosing traffic drops. Use whenever the user asks what Google officially says or requires, wants a site or page audited for SEO problems, or mentions Googlebot, robots.txt, noindex, canonical, sitemap, hreflang, schema.org, JSON-LD, rich results, Search Console, E-E-A-T, core updates, manual actions, AI Overviews, or llms.txt. Also for "will this hurt my rankings", "why did my traffic drop", "why isn't my page indexed", "audit my site", or "is this against Google's guidelines" - prefer it over general SEO folklore whenever an official Google answer exists.
---
# 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](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)).
The same holds for indexing: meeting every requirement doesn't oblige Google to crawl,
index, or serve a page
([How Search Works](https://developers.google.com/search/docs/fundamentals/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:
```bash
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](https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag)
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](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)).
### 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](https://developers.google.com/search/docs/fundamentals/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](https://search.google.com/test/rich-results), 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](https://developers.google.com/search/docs/fundamentals/third-party-seo)
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](https://developers.google.com/search/blog).