OGKit

改了 Open Graph 为什么还是旧图

· 阅读约 6 分钟

  • open-graph
  • 缓存
  • rescrape
  • 社交预览

晚上十一点你改完发布页：新主视觉、新的 og:image、部署全绿。早上九点运营把同一条链接丢进 Slack，卡片还是上周的闪购图；LinkedIn 里裁切也是旧的。对方只会问一句：怎么还是旧的？

标签没写错，图片 200 也能打开，你自己的浏览器不是犯人。每个平台各自缓存了「上次抓到这个 URL 时」的结果——它们不会订阅你的发布流水线。

缓存模型：三句话解释大多数事故

  1. 抓取时刻，不是部署时刻。 平台在它的爬虫上次访问页面时存下标题、描述、图片 URL（常常还有图片本身的一份拷贝）。你的 CDN 刷新不会通知 Facebook。
  2. URL 通常就是 cache key。 公开 URL 不变 → 还是同一条缓存。只改 /og.png 背后的字节、路径不动，就是经典的「我覆盖了文件怎么没变」。
  3. TTL 按平台各算，且常常不公开。 社区常说 LinkedIn / X「大约七天」；Meta 的过期时间不是对外 SLA。没有一手来源的数字一律当 unverified；今天就会有人分享时，按强制刷新来规划。

不存在官方的「一键清全世界 Open Graph 缓存」。 这不是你站少做了功能，而是封闭 unfurl 体系的常态。第三方多平台预览站只是替自己的演示重新抓一遍，不会替你失效 Meta、LinkedIn 或 Telegram 的缓存。

常见误解 实际情况
「meta 改对了，预览就该变」 要等各平台 rescrape，或等它们自己的 TTL
「某某预览站已经显示新卡」 那是对方的抓取，不是 Facebook 的缓存
「CDN 已 purge 图片」 平台仍可能按页面 URL 握着旧抓取结果
「一个调试器清掉所有 App」 WhatsApp 可能走 Meta 路径；Slack / Discord 不会

官方工具手册：分享敏感改动后按这个做

需要登录的步骤必须用你的账号。能深链带上 URL 只是省粘贴；真正重新抓取仍发生在平台工具里。

Meta — Sharing Debugger

  1. 打开调试器（需 Facebook 开发者账号）。
  2. 粘贴页面的规范公开 HTTPS URL（与 og:url / canonical 一致）。
  3. 查看抓取结果，点 Scrape Again，让缓存丢掉旧卡片。
  4. 大量 URL 用 Batch Invalidator（每行一个）。WhatsApp 常与 Meta 共用缓存路径，批量失效往往是两者都管用的实务做法。

LinkedIn — Post Inspector

  1. 登录 LinkedIn 后打开 Post Inspector。
  2. 粘贴公开 URL，执行 Inspect。
  3. 确认实时抓取已是新图、新标题。
  4. 若信息流旧帖仍显示旧卡，Inspect 之后重新分享——部分客户端会钉住旧 unfurl。

社区常引用大约一周缓存；当 SLA 用请标 unverified。活动今天就在推，就不要干等。

X — Card Validator

  1. 打开 Card Validator（历史上可用性有波动；打不开时查 X 当前文档）。
  2. 粘贴 URL 预览卡片。
  3. 若工具无法干净强制刷新，改公开 URL（或爬虫会当成新 key 的 cache-bust 查询串）后再发。

TTL 常被说成约七天（社区，非固定官方值）。在意时间线效果时，每次换创意都重新验证更稳。

Telegram — @WebpageBot

  1. 在 Telegram 打开 @WebpageBot。
  2. 发送你刚更新的完整公开 URL。
  3. 等机器人给出新预览后，再在会话里分享该链接。

Slack、Discord、WhatsApp（没有公开的一键调试器）

  • Slack / Discord： 在测试频道里重新分享。Discord embed 有时要改 query 或重贴才松手。没有官方「清 embed 缓存」控制台。
  • WhatsApp： 无公开 debugger。Meta 侧用 Batch Invalidator 往往最实用；否则等待或改 URL。调试器抓取正常但聊天仍无图时，也可能是图片字节预算 / 抓取失败，不只是缓存——系列的图片工程篇会写。

Google（搜索摘要，不是聊天卡片）

痛点在搜索而非社交时：用 Rich Results Test 与 Search Console 的 URL 检查 / 请求编入索引。这条路径和 Facebook Sharing Debugger 无关。

针对单个公网 URL，OGKit 的重新抓取助手 会生成主要调试器链接，并列出与产品同源的平台 TTL 说明——不会替你调用这些工具。已登录浏览器里的一键多平台 rescrape 走浏览器扩展路径。

改 URL vs 同 URL 覆盖

策略 适合 代价
覆盖同一 og:image 路径 微小文案修正，且你会逐个平台 rescrape 容易漏平台；CDN + 平台双重缓存
新图片 URL（…/og-v2.png 或内容哈希） 换活动主视觉、「到处必须是新图」 要改 meta；rescrape 完成前可保留旧对象
新页面 URL 缓存死钉、落地页更名 旧分享失效；重定向时 og:url 要一致
给页面 URL 加 query Discord 等可能按完整 URL 作 key 的客户端 难看；部分爬虫会归一化 query——按平台 unverified

实务：上线换物料时，新图片 URL + Meta / LinkedIn 官方 rescrape 优于「覆盖然后祈祷」。活动冻结后，HTML 里的 og:image 保持绝对 HTTPS 且稳定。

动态 OG（opengraph-image、Satori 模板）最终也是一个 URL。若 URL 不变只改渲染字节，你又回到「覆盖」问题——要么 rescrape，要么给图片路径做版本号。

维护检查清单（给运营 / 发版同学）

对「今天就会被粘贴」的 URL，改过标签或分享图之后：

  • 确认原始 HTML里已是新的 og:*（curl，不要只看 hydration 后的 DevTools）
  • 确认图片 URL 无登录墙、无无限跳转、不是错误占位小图
  • Meta Sharing Debugger → Scrape Again（多 URL 用批量工具）
  • LinkedIn Post Inspector → Inspect；旧帖粘住则重新分享
  • 在意 X 流量则用 Card Validator（或改 URL 后新发）
  • 在意 Telegram 则交给 @WebpageBot
  • 在 Slack / Discord / WhatsApp 用新消息抽查，不要看旧气泡
  • 不要把第三方预览站当成「Meta 已清缓存」的证据

更细的 TTL 与字段优先级见平台档案。标签对不对是另一层：规则。清缓存救不了缺 meta、相对路径图片或爬虫被挡——调试器根本抓不到时，先看为什么卡片一片空白。

OGKit 会说什么、不会说什么

网站上的 rescrape 页负责按顺序给出官方路径并说明 TTL，避免发版后满世界找书签。浏览器扩展可在你的登录态下驱动多平台 rescrape，仍是可见的官方步骤，而不是宣称绕过平台登录的隐秘 API。

我们不会承诺「全球一键失效」。合规措辞与产品一致：用户触发、步骤可见、按平台走官方工具。

下一篇读什么

  1. Open Graph 到底在解决什么 —— 标签 → 预览 → rescrape → CI 全流程图
  2. 为什么你的 Open Graph 卡片一片空白 —— 怪缓存之前先排除的五种失败
  3. 图片工程（系列后续）—— rescrape 成功却仍丢图时的字节、跳转与预算
  4. SPA 爬虫与 CI 门禁 —— 第一次抓错时如何防止下一次

用一条 URL 走一遍官方路径

把线上页贴进重新抓取助手，从生成的链接打开 Meta 与 LinkedIn 并 Scrape Again。若还需要按规则诊断，再把同一 URL 丢进首页扫描。抓取结果已正确却仍见旧卡，几乎总是「另一个平台的缓存」，而不是 meta 写错了两次。