Article、BlogPosting、NewsArticle、WebPage、mainEntityOfPage、author 和 publisher 有什么区别？
核心差异速查
项目 表示对象 常见取值 主要作用
-- --- --- ---
Article 通用文章 CreativeWork 子类型 描述文章内容
BlogPosting 博客文章 Article 子类型 更具体描述博客内容
NewsArticle 新闻文章 Article 子类型 更具体描述新闻内容
WebPage 网页本身 CreativeWork 描述承载页面
mainEntityOfPage 实体到页面的关系 URL 或 CreativeWork 指明该实体是页面主体
author 创作者关系 Person 或 Organization 标记文章作者
Article 是什么
Schema.org 的 Article 是文章类 CreativeWork 的通用类型，适合无法或无需细分为新闻、博客等类型的文章。Google 的 Article 功能文档接受 Article、NewsArticle 和 BlogPosting 三种类型。
使用 Article 不代表内容质量较低，也不会自动失去资格。Google 的通用指南建议使用真实且最具体适用的类型，而不是为了追求更“高级”的名称进行误标。
BlogPosting 是什么
BlogPosting 是 Article 的更具体子类型，用于博客中的帖子。它适合个人博客、企业技术博客、更新日志式深度文章等真正属于博客发布体系的内容。
站点使用 WordPress 或页面路径包含 /blog/ 并不足以单独决定类型，仍应看页面实际内容和栏目性质。普通产品详情页不能因为带长篇文案就标为 BlogPosting。
NewsArticle 是什么
NewsArticle 用于新闻文章，例如报道近期事件、公共事务或其他新闻内容。它是语义分类，不是申请进入 Google News 的开关。Google 明确说明，Article 标记可更明确提供标题、图片、日期和作者信息，但进入 Top stories 等新闻功能并没有结构化数据硬性门槛。
常青教程、百科解释和营销软文不应仅为争取新闻展示而标为 NewsArticle。结构化数据必须真实反映用户可见的主体内容。
三种 Article 类型怎么选
若内容明确是新闻报道，选 NewsArticle；若明确是博客帖子，选 BlogPosting；其他文章型页面可用 Article。Schema.org 允许使用最具体类型，同时继承父类型属性，无需再额外创建一个重复 Article 对象。
类型选择应由编辑模板或内容模型控制，并允许人工覆盖。仅根据发布时间新旧或 URL 路径自动猜测，容易造成大规模误标。
WebPage 是什么
WebPage 描述网络页面这个 CreativeWork，包括页面 URL、语言、面包屑、主要实体等页面级信息。Article 描述页面承载的文章内容。两者在很多简单页面上一一对应，但概念仍不同。
一个 WebPage 也可能主要描述 Product、Person、Event 或 Dataset，而不是 Article。不能把 WebPage 视为 Article 的同义类型。
为什么一个页面可有两个实体
网页是载体，文章是作品。把它们拆开后，可以表达 WebPage 的 breadcrumb、isPartOf 和 primaryImageOfPage，同时为 Article 表达 headline、author、datePublished 与 publisher。
使用 @graph 时应为对象设置绝对、稳定、唯一的 @id，再通过属性引用，减少重复嵌套和字段冲突。
mainEntityOfPage 是什么
Schema.org 将 mainEntityOfPage 定义为：指出某个 Thing 是某个 WebPage 或其他 CreativeWork 主要描述的实体。对 Article 来说，它通常连接到承载该文章的 WebPage 或其 URL。
方向是“文章实体的 mainEntityOfPage 指向页面”。其逆属性是 WebPage 上的 mainEntity。不需要在同一图里无意义地同时重复两个方向。
mainEntityOfPage 不是 canonical
canonical 是搜索规范化信号，用于说明一组重复或近重复 URL 中偏好的规范 URL。mainEntityOfPage 是结构化数据实体关系。两者可能引用同一页面地址，但不能相互替代。
即使 JSON-LD 指向规范页面，HTML 中错误 canonical、重定向和站点链接仍需独立修复。
mainEntity 与 mainEntityOfPage 的方向
如果从 WebPage 出发，可用 mainEntity 指向 Article；如果从 Article 出发，可用 mainEntityOfPage 指向 WebPage。建模时选择一个清晰方向，并用相同 @id 连接。
常见错误是把 Article 自己的 @id 填入 mainEntityOfPage，形成自指，而没有表达承载页面。
author 表示什么
author 表示 CreativeWork 的创作者。Google Article 文档支持 Person 或 Organization，并建议提供 author.name 和能够唯一识别作者的 author.url。多人合著时应分别列出每位实际作者。
作者字段应与页面可见署名一致。不能用关键词、栏目名或不存在的人物填充，也不应把站点组织机械写成每篇文章作者，除非内容确实由该组织署名创作。
Person 作者如何建模
个人作者至少应有真实显示名称；可提供作者简介页 URL，并用稳定 @id 在多篇文章中复用同一实体。简介页应向用户展示相符身份和专业信息，而不是只为结构化数据创建空页。
作者名称在正文、署名区域和 JSON-LD 中应一致。改名时应同步更新实体引用，避免把同一个人拆成多个作者。
Organization 作者何时合理
编辑部、研究团队或没有个人署名的机构报告可以使用 Organization 作为 author。它表达“机构创作”，不是“网站发布”。如果页面同时明确列出记者或撰稿人，应按真实署名建模。
不要仅因为站点属于某公司，就把所有用户投稿或第三方转载标成该公司创作。
publisher 表示什么
publisher 表示负责发布该 CreativeWork 的主体，通常是网站背后的媒体、机构或品牌组织。它与作者可能相同，也可能不同。例如记者是 author，新闻机构是 publisher。
发布者信息应与站点身份、组织页面及可见品牌保持一致。伪造知名媒体作为 publisher 属于误导性标记。
author 与 publisher 能相同吗
可以。个人独立博客可能由同一个 Person 创作并发布；公司研究团队也可能以同一 Organization 作为 author 和 publisher。但这必须反映真实编辑关系，而不是为了填满属性。
相同实体应复用同一个 @id，不要因为扮演两个角色就复制成名称不同的对象。
headline 应该写什么
headline 是文章标题，应准确反映用户可见主标题。Google 建议加入适用的推荐属性，标题文本不应塞入关键词、品牌重复或正文之外的宣传语。
HTML <title、页面 H1 和 headline 可以因展示环境略有差异，但语义应一致；严重冲突会降低结构化数据可信度。
datePublished 与 dateModified
datePublished 表示首次发布文章的时间，dateModified 表示内容最近一次实质更新的时间。仅重建页面、刷新缓存或修改无关模板不应伪装为文章更新。
Google 的日期指南要求结构化数据日期与用户可见日期一致，并建议提供准确时区。未来日期和页面事件日期不应冒充发布日期。
image 应满足什么条件
Article 的 image 应与文章主体相关，并能被 Google 抓取和索引。Google 示例会提供多个适合不同裁剪比例的图像，但实际字段应只包含页面真实、可访问的代表图片。
不要使用与文章无关的 Logo、追踪像素或占位图冒充主图。图片 URL 若受登录、robots 或防盗链阻止，也无法正常被获取。
publisher logo 怎么处理
组织 Logo 属于发布者实体信息，不等于 Article 的 image。可为 Organization 提供其规范 logo，并在全站复用一致实体。文章主图仍应描述文章内容。
不要在同一 JSON-LD 中为 publisher 生成多个尺寸矛盾、地址失效的 Logo 对象。
visible content 一致性要求
Google 通用指南要求结构化数据真实代表页面内容，且标记内容应对用户可见。JSON-LD 中出现作者、日期、图片或标题，而页面正文没有相应信息，会形成质量问题。
结构化数据是机器可读的内容说明，不是向搜索引擎提交一套用户看不到的替代页面。
更具体类型不等于更好排名
选择 BlogPosting 或 NewsArticle 的目的是准确分类，不是获得排名加分。Google 不保证正确标记一定显示富媒体结果，最终展示还受页面质量、查询、设备和系统判断影响。
因此验收指标应是标记准确、可抓取、无关键错误以及实际监控，而不是“上线后必须出现某种样式”。
required 与 recommended 怎么理解
Google 当前 Article 文档说明没有必填属性，但建议加入适用于页面的属性。没有 required 不代表可以提交空对象；完整、准确的 headline、author、日期和图片能帮助系统理解内容。
Schema.org 允许某属性，也不代表 Google 的特定搜索功能一定读取它。实现时应同时核对 Schema.org 语义和 Google 功能文档。
JSON-LD @graph 的推荐结构
可用一个 @graph 放置 Organization、WebSite、WebPage、Person 和 Article 等实体，每个实体使用稳定 @id，再以引用连接。例如 Article 的 author 指向 Person，publisher 指向 Organization，mainEntityOfPage 指向 WebPage。
避免不同插件分别输出相互冲突的 Article。多个语法正确但语义矛盾的对象，比单个精简一致对象更难处理。
常见错误：所有页面都输出 Article
首页、分类页、搜索结果、联系页和产品页通常不是文章。模板层无条件注入 Article 会把页面主要目的标错，还可能生成虚假的作者和发布日期。
应让结构化数据由页面类型驱动，并为未知模板提供安全降级，而不是默认伪装成文章。
常见错误：把网站名当 author
网站名更常对应 publisher 或 Organization。若页面明确署名个人，author 就应指向个人；若确由编辑部集体创作，可使用真实组织作者。
不要为了品牌曝光改变署名事实。作者身份还应与页面 byline、简介页和编辑政策相符。
常见错误：隐藏或虚构更新日期
自动把 dateModified 设置为每次构建时间，会让搜索系统和用户误以为内容持续更新。正确做法是由内容层记录实质修订时间，并在页面可见位置展示一致日期。
批量迁移、样式修改或 CDN 刷新通常不应修改文章语义更新时间。
测试工具各自证明什么
Rich Results Test 可检查 Google 支持功能的语法和属性问题，但通过测试不代表一定展示，也不能证明页面内容真实。Schema.org Validator 更适合检查通用词汇结构，但不等于 Google 功能资格验收。
发布后还应通过 URL Inspection 确认 Google 可访问渲染页面，并在 Search Console 的增强功能报告中监控规模性错误。
上线前检查清单
确认页面类型真实，正文可见标题、署名、日期和图片与 JSON-LD 一致；检查 Article、WebPage、author、publisher 的 @id 引用；验证绝对 URL、canonical、状态码和抓取权限。
再用测试工具检查，抽样查看源代码与渲染 DOM，确保 CMS 插件没有重复输出，最后小批上线并观察抓取结果。
FAQ：普通教程用 Article 还是 BlogPosting？
若它属于明确博客栏目，可用 BlogPosting；若只是通用文章型内容，Article 足够。应按真实内容模型选择，而不是猜测哪种更有排名优势。
FAQ：NewsArticle 能帮助进入 Google News 吗？
它能更明确描述新闻内容，但不是进入 Google News 或 Top stories 的保证和硬性门票，内容与站点仍需满足相应政策和质量要求。
FAQ：必须同时输出 WebPage 和 Article 吗？
不是硬性要求。简单 Article 对象可以工作；复杂站点若需要表达页面、面包屑、网站和作者关系，可用 @graph 清晰建模。
结论
Article、BlogPosting 和 NewsArticle 描述不同粒度的文章内容，WebPage 描述页面载体，mainEntityOfPage 建立主体与页面关系，author 和 publisher 则分别表达创作与发布责任。正确实现的重点是类型真实、实体连接稳定、字段与可见内容一致，并用工具和实际抓取持续验证，而不是堆叠类型或伪造属性追求展示。
官方资料
Google Article 结构化数据文档：https://developers.google.com/search/docs/appearance/structured-data/article
Google 结构化数据通用指南：https://developers.google.com/search/docs/appearance/structured-data/sd-policies
Google 结构化数据工作原理：https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
Google 搜索结果日期指南：https://developers.google.com/search/docs/appearance/publication-dates
Schema.org Article：https://schema.org/Article
Schema.org BlogPosting：https://schema.org/BlogPosting
Schema.org NewsArticle：https://schema.org/NewsArticle
Schema.org WebPage：https://schema.org/WebPage