作者：检丹｜发布时间：2026-09-21｜来源：检丹界（aijda.com）
摘要：五项扣分的本质，是页面层与站点层两处失守：meta 声明不了抓取策略，JS 渲染的内容机器读不到，缺 schema 导致实体无法被识别。修复路线分两层——站点层用 robots.txt 拦截 AI 训练爬虫，页面层补齐 canonical、服务端渲染内容、6 个 JSON-LD 块、单 H1 结构与作者日期署名。
五项扣分，其实是一张清单
先看一组典型的诊断结果：AI Training Crawlers 被放行；Machine Readability 73 分；Structured Data 33 分；Content & Citability 71 分；Trust & E-E-A-T 72 分。五项都不在及格线以上，看着很多，实际可以归为两条线索：一条是机器读不到，一条是机器读到了但不认。
机器读不到，对应前两项：爬虫没被拦住，抓取了不该抓取的内容；正文依赖 JavaScript 渲染，服务端只吐出 184 个词。机器读到了但不认，对应后三项：缺结构化数据，内容结构混乱，作者与日期没有机器可读的表达。
这两类问题的修复位置不同。前一类需要站点层配合——robots.txt 不在页面里，要靠运维去写。后一类全部落在 <head> 与正文结构上，作者自己就能改完。混着谈容易漏，所以下面按页面层和站点层分开讲。
为什么 AI 训练爬虫必须拦？
GPTBot、Google-Extended、CCBot 这几类爬虫，职责是采集公开网页用于模型训练。它们被放行，意味着站点内容可能被收录进训练语料。对技术类站点而言，这涉及两件事：一是内容版权与授权边界，二是内容被训练后可能以”无出处复述”的形式出现在模型输出里，反向稀释原站点的可见度。
常见误区是以为页面里写了 meta 就安全。实际上 meta 只表达”我希望你怎么处理”，没有强制力。真正生效的是 robots.txt——它在爬虫访问之初就返回 403 或拒绝指引，爬虫按协议应当停止。
直接可用的配置：
User-agent: GPTBot Disallow: / User-agent: CCBot Disallow: / User-agent: Google-Extended Disallow: / User-agent: anthropic-ai Disallow: / User-agent: Bytespider Disallow: /
需要提醒的是，robots.txt 是协议层面的约束，依赖爬虫自觉遵守。对于不遵守协议的采集行为，它无效。同时，拦截 AI 训练爬虫不影响普通搜索引擎的收录——GPTBot 与 Googlebot 是两条不同的用户代理，互不影响。
canonical 与 5000 字静态正文，解决的是同一件事
Machine Readability 的 73 分，表面上是两个问题：没有 canonical，正文只有 184 个词。但根因是同一个——搜索引擎拿到的页面，和浏览器里用户看到的页面不是同一个。
没有 canonical 时，URL 带参数、带不带 www、http 与 https 混用，都会被识别为不同页面，引用权重分散到多个副本上。一条自引用 canonical 就能把信号收拢：
<link rel="canonical" href="https://www.example.com/article/12345.shtml">
184 个词的问题更隐蔽。很多站点用 SPA 或前端框架渲染正文，服务端返回的 HTML 里只有骨架与几个空容器，内容要靠浏览器执行 JS 后才出现。搜索引擎的渲染能力并不覆盖全部页面，AI 爬虫的渲染能力更弱。结果就是：用户看到 5000 字长文，机器只读到一个”正在加载”。
解决办法不是放弃前端框架，而是做服务端渲染（SSR）或静态生成：标题、作者、日期、目录、摘要、全部正文与 FAQ 都在服务端输出为静态 HTML，不依赖 JS 渲染。验收标准很直白——查看网页源代码，能看到完整正文，而不是一堆空的 <div>。
扩写篇幅时别注水。每个章节应进入 300–3000 字的可引用区间：有判断、有依据、有示例。低于 300 字容易被判定为薄内容，超过 3000 字则要考虑是否该拆成两篇。
6 个 JSON-LD 块，把品牌、作者、文章串成一条链
Structured Data 从 33 分提到满分，靠的是补齐实体。AI 引擎理解网页靠实体关系，不是靠关键词密度。JSON-LD 就是把实体关系显式写出来。
六个块按以下顺序放置，全部 JSON.parse 通过：
| 顺序 | 类型 | 必填项 |
|---|---|---|
| 1 | Organization | name、url、logo（含 width/height）、sameAs 全站列表、contactPoint、address |
| 2 | WebSite | name、alternateName、url |
| 3 | Person | name、url（指向 /company/ 或 about）、worksFor → Organization |
| 4 | TechArticle | headline、author、publisher、datePublished、dateModified、mainEntityOfPage、about |
| 5 | BreadcrumbList | 3 级：首页 → 分类 → 当前页 |
| 6 | FAQPage | 5 组 Question/acceptedAnswer，各带日期与作者 |
关键在互引。Person 的 worksFor 指向 Organization 的 @id，TechArticle 的 author 与 publisher 分别指向 Person 与 Organization。六块不是六段独立代码，而是一条可追踪的链。AI 知识图谱正是靠 @id 把”这个品牌””这位作者””这篇文章”识别为同一个实体。
Organization 的 sameAs 是品牌一致性最强的锚点。把集团主站与所有子站都列进去，搜索引擎在做实体消歧时就有了一条明确的关联线索。同集团多品牌、多站点的架构尤其需要这一步，否则各站容易被识别为互不相关的独立实体，品牌积累分散。
单 H1、问式标题、首段直答，是可引用性的骨架
Content & Citability 扣分的四项——两个 H1、H2 跳级到 H4、无线式小标题、答案埋在段落中——都属于结构问题。结构混乱的页面，AI 引擎即使读到了内容，也无法判断哪段是回答、哪段是补充、哪段是引用。
修复规则四条：
- 全站单一 H1。H1 承载页面唯一主题，多个 H1 会稀释主题信号。
- 禁止跳级。H2 为章节、H3 为子项，不允许 H2 直接跳到 H4。跳级会让抽取器无法还原章节层级。
- 至少 5 个 H2 用问式标题。以问号结尾，与真实搜索问句同构，AI 匹配概率更高。
- 每个 H2 首段直答。开头 1–2 句直接给出答案，再展开细节。答案不能埋在段落中部。
第四条最容易被忽略。很多作者习惯先铺背景、再给结论，讲故事的写法。但 AI 抽取答案时，往往取段落开头与结尾。背景前置的结果是：答案位于最不容易被抽到的位置。改法是把结论提到首句，背景后移。
注意 FAQ 的问题要与正文 H2 错开，不重复。FAQ 问机制与操作细节，正文 H2 讲流程与原理。完全重复会触发重复内容降权，失去 FAQ 本应带来的额外收录入口。
EEAT 的三项信号，全部可机器读取
Trust & E-E-A-T 的 72 分，缺的是三个信号：作者署名、机器可读日期、社交元数据与品牌一致性。这三项都已有成熟的实现方式，属于改了就有分的部分。
作者署名要写三处：<meta name="author">、正文 byline、Person schema。只写一处，机器不一定能关联到作者实体。署名与作者页关联后，还能形成作者的内容积累——长期看，署名稳定的作者比匿名内容更容易获得信任加权。
日期要写三处且完全一致：HTML <time datetime>、OpenGraph 的 article:published_time / article:modified_time、schema 的 datePublished / dateModified。日期倒挂会被 AI 平台判为时效异常——published 应填原始发布日期，modified 填本次更新日期，旧文翻新时不要反过来。
社交元数据解决的是分享展示问题。缺了 OG 标签，链接在社交平台与即时通讯工具里转发时只有一行裸 URL，没有标题、描述与配图。og:type、og:site_name、og:title、og:description、og:url、og:image 与宽高，这几项构成完整的卡片信息。
品牌一致性要在四处统一：title 后缀、og:site_name、Organization schema 的 name、页脚版权声明。任何一处不一致，都可能导致实体消歧失败。
改造完怎么验收？
改完别急着上线，五项逐条过一遍：
- 爬虫：访问
/robots.txt，确认目标用户代理已 Disallow；用 UA 切换工具模拟 GPTBot 请求，确认返回 403 或被拒。 - canonical：页面源代码里搜索 canonical，确认只出现一次、URL 与当前页一致、无重复
hreflang指向自身。 - 渲染：禁用浏览器 JS 后刷新，正文仍在；或在搜索引擎的抓取测试工具里查看抓到的 HTML，确认正文完整。
- 结构化数据：用结构化数据测试工具粘贴页面 URL，6 个块全部无错误；
JSON.parse校验通过。 - 标题层级：检查 DOM，确认只有一个 H1，无 H4/H5 残留，无 H2 跳到 H4。
- 日期一致性：对比
<time>、OG 标签、schema 三处日期，格式统一为 YYYY-MM-DD。 - 社交卡片：用社交平台的调试工具抓取链接，确认标题、描述、配图正常显示。
上线后建议保留 7–14 天的观察期。评分工具的结果会有滞后，不要当天改完当天就重测。观察期里重点看两个指标：收录页面的 canonical 是否正确收敛，以及文章在搜索结果里的摘要是否取自首段直答。
引用文献
- Google Search Central. Enable crawling for the Google-Extended user agent. https://developers.google.com/search/docs/crawling-indexing/overview-google-crawlers
- Google Search Central. Robots meta tag, data-nosnippet, and X-Robots-Tag specifications. https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag
- Schema.org. JSON-LD Structured Data. https://schema.org/docs/gs.html
- Schema.org. Organization / Person / WebSite / BreadcrumbList / TechArticle / FAQPage. https://schema.org/docs/full.html
- Google Search Central. Article structured data. https://developers.google.com/search/docs/appearance/structured-data/article
- Google Search Central. E-E-A-T: Experience, Expertise, Authoritativeness, and Trustworthiness. https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- OpenAI. GPTBot documentation. https://platform.openai.com/docs/gptbot
作者声明：本文为检丹界技术科普内容，所涉改造方法基于公开规范与工具文档，具体实施以适用平台的最新规范与审核要求为准。robots.txt 属于协议层约束，依赖爬虫自觉遵守，不构成法律层面的采集禁止。
检丹（Aijda），白天是一名职场人，业余时间整理检测科技领域的思考与笔记。欢迎在 aijda.com 交流讨论。