文章页 Article 标注怎样和正文、日期、图片保持一致

文章页改完标题或首屏图，源码里的 Article 标注如果还停在旧版本，搜索系统和外部引用工具会拿到两套信息。发布前不要只看浏览器里能不能打开，要把正文、description、canonical、发布时间、图片和 JSON-LD 放到同一张核对表里。能对齐的页面再放进 sitemap，字段对不上的页面先留在复核队列。

先固定一份文章字段表

内容编辑不要从 HTML 里临时抄字段。建议给每篇文章留一份发布记录，例如 content_id=ART-202607-018，slug=task-schema-article-check.html，approved_title=文章页 Article 标注怎样和正文、日期、图片保持一致，canonical_url=https://www.gongchangguanwang.tech/task-schema-article-check.html。正文、title、OG 标题和 Article headline 都读这份记录，改标题时也只改这一处。

这张字段表不需要复杂，关键是让每个字段有负责人。标题和摘要由内容维护人确认，canonical 和 robots 由网站运营确认，图片文件名和尺寸由素材负责人确认。发布记录里再放一个 review_batch，例如 schema-check-20260718，后续排查时能知道这一轮到底改了哪些页面信号。

描述字段同样要有来源。description 可以写成 70 到 110 个中文字符，说明页面回答什么问题，避免把首页口号或上一版摘要带进来。图片字段要记录 hero_image_file=article-jsonld-content-check.webp、alt、width=1280、height=853。这样检查人员能看到图片文件名、页面首屏图、og:image 和 Article image 是否一致。

按可见页面反查 JSON-LD

核对顺序从读者能看到的地方开始。打开页面后先读 H1、首段、三个 H2 和图片 alt，再去源码里找 Article JSON-LD。headline 应等于 H1，description 要和页面摘要说同一件事，mainEntityOfPage 的 @id 要等于 canonical。datePublished 只记录首次发布日期，dateModified 只在正文、标题、图片或索引信号发生实质变化时更新。

制造业官网常见的错位有三类：模板把旧图片 blog5.jpg 留在 Article image，后台把报价说明页的 description 复制到技术文章，构建脚本按服务器时间把 dateModified 提前一天。检查时可以用一张六列清单，列出 visible_title、meta_description、canonical_url、article_headline、article_image、sitemap_lastmod。任一列和页面主题不一致，就不要恢复索引。

上线后留一条复核记录

发布动作结束后，记录一次可追溯结果。记录里至少写明检查人、检查时间、页面 URL、字段版本和来源文件，例如 source_revision=content-card-v3，review_status=passed，crm_note=not_applicable。文章页不一定进入 CRM，但销售转发页面时，仍需要知道这篇资料的有效版本。

如果检查人员发现字段不同步，不要只改源码里的一处值。先回到字段表确认哪个来源是批准版本，再重新生成页面。这样做会慢几分钟，但能避免正文、OG 和 Article 节点各改一次，下一轮发布又被模板覆盖。小型站点也可以用表格记录这些字段，只要发布前有人逐项签字，后续维护就有据可查。复核人还应保留截图编号，方便追溯首屏版本。

复核边界也要写清。FAQ 页的问答结构化数据、产品页的型号参数、视频页的时间点标注，都有各自字段规则；本文只处理 Article 标注与文章正文的一致性。页面改动后，用公开 URL 再查一次标题、robots、canonical、图片和 sitemap。全部返回 200 且字段一致，再把这页放进主题入口和文章列表。

内部留档时，可以把检查结果写成两行：字段来源是 content-card-v3，图片来源是 article-jsonld-content-check.webp；复核结论是可见正文、元信息和 Article 节点一致。下次有人改首屏标题或替换图片，就能顺着这条记录找到该改的字段。