Article 结构化数据标记实战

Article 结构化数据标记的实战要点只有一句话：**选用最具体的子类型、填全四个必备字段、时间用带时区的 ISO 8601，然后用 Rich Results Test 验证到 0 错误再上线**；字段填错或不完整比不写更糟，因为错误标记会被搜索引擎整段忽略。

Article 结构化数据必须写哪些字段？

结论：Google 认定的 Article 必备属性是 headline、image、datePublished、author 四项，缺任意一项该条标记直接作废。

• headline：文章标题，建议控制在 110 个字符以内，超长会被截断显示；不要在这里堆关键词。
• image：配图 URL，建议 1200×630 像素、16:9 比例，且必须是可公开抓取的绝对地址（相对路径无效）。
• datePublished / dateModified：ISO 8601 格式并带时区，如 2025-03-14T09:30:00+08:00。只写 2025-03-14 能通过校验，但丢失时间精度，更新时间的语义也会变弱。
• author：用 Person 类型，至少给 name，有主页就补 url 或 sameAs。

推荐补充的字段有 description（150 字内的摘要）、publisher（指向 Organization）、mainEntityOfPage（指向该页 WebPage）、articleSection、keywords、inLanguage。其中 publisher 建议用 @id 复用全站统一的 Organization 实体，不要每篇文章重复写一份，否则同一实体在站内出现多个不同描述，反而削弱实体一致性。

Article 标记怎么写？可直接复制的 JSON-LD

结论：用 JSON-LD 写在 <head> 里，一个 <script type="application/ld+json"> 承载一个实体图，用 @id 把 Article、Person、Organization 串起来。

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/post/123#article",
  "headline": "Article 结构化数据标记实战",
  "description": "Article 标记的必备字段、子类型选择与 5 个高频错误。",
  "image": ["https://example.com/cover/123.jpg"],
  "datePublished": "2025-03-14T09:30:00+08:00",
  "dateModified": "2025-03-20T16:05:00+08:00",
  "inLanguage": "zh-CN",
  "author": {
    "@type": "Person",
    "name": "作者名",
    "url": "https://example.com/u/1"
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "站点名",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/post/123"
  }
}

上线前用 Google Rich Results Test 和 Schema Markup Validator 各跑一遍，前者测「能不能出富结果」，后者测「语法和类型对不对」。两项都 0 错误再放行。

Article、NewsArticle、BlogPosting 有什么区别，该选哪个？

结论：三者是父子关系，Article 是父类型，NewsArticle、BlogPosting、TechArticle、Report 是它的子类型；能选子类型就不要用泛型 Article。

NewsArticle 面向时效性新闻报道，Google 的 Top Stories 和 Discover 抓取时会重点识别；BlogPosting 面向带作者观点的博客、教程、经验帖，个人站点和社区帖子用这个最贴切；TechArticle 面向 API 文档、技术手册这类有固定结构的说明文。选错子类型的直接后果是搜索引擎把它归错内容池，时效类需求下不会给你新闻位。

为什么加了 Article 标记却没有星级评分？

结论：Article 类型本身不产生星级富摘要，星级来自 Review 或 AggregateRating（配合 ratingValue 和 ratingCount），两套是独立的标记。

论坛和社区最常踩的 5 个错误：

1. 指望 Article 出星——正确做法是在页面里单独输出评分实体，把 1-5 星的均分和评分人数写进 AggregateRating，这是能在搜索结果页显示星级的唯一路径。
2. image 用相对路径或防盗链图片——抓取端拿不到图，整条标记按失败处理。
3. author 写成字符串（"author": "张三"）——部分解析器能容错，但严格校验会报类型错误，必须写成 Person 对象。
4. 标记了页面上看不见的内容——结构化数据必须与用户可见内容一致，隐藏版块、权限内容做了标记属于违规，会被判 spam。
5. 同一页面输出多个互相冲突的主实体——一篇文章同时标 Article 和 QAPage，语义打架，解析器只会挑一个。

论坛帖子该标 Article 还是 QAPage？

结论：按内容形态分流——普通讨论帖、教程帖用 BlogPosting；悬赏问答且有采纳答案的用 QAPage + acceptedAnswer；成组的问答聚合页用 FAQPage；三者不要在同一 URL 上混用。

Clara BBS 内置的结构化数据输出已按这个思路分层：普通帖子输出评分均分进 AggregateRating 拿星级，已解决的悬赏帖输出 QAPage 与 acceptedAnswer，问答聚合页输出 FAQPage，帖子页额外输出 citation 引用元标签，全站统一输出 Organization + sameAs 保证实体一致。GEO 侧配套的是 /llms.txt 站点说明与 /llms-full.txt 内容索引、16 个以上中国系 AI 爬虫的 robots 放行开关、新帖 IndexNow 与百度主动推送，以及后台「系统设置 → GEO 优化」里的爬虫访问监控——这些是让标记被真正抓到和引用的前置条件，标记写得再规范，爬虫进不来也等于零。

实操顺序建议：先定内容形态选子类型 → 填齐 4 个必备字段 → 用 @id 关联 Organization → 本地跑两个校验工具 → 上线后 7 天在 Search Console 的「增强功能」里看有效项与错误项数量变化。把标记当成一次性配置而不是持续维护，是这类优化最常见的失败原因。