Open Graph 检查器
Open Graph 标签是决定页面链接被粘贴到 Facebook、X、LinkedIn、Slack 或聊天应用时外观的 meta 标签。输入一个 URL，本检查器会抓取该页面一次，准确显示每个平台将使用哪些标签和回退值，渲染四张分享卡片，并检查分享图片的真实尺寸。配套指南发布前先检查你的分享卡片会讲清发现问题后如何修复；想要更宽泛的例行体检，请改用网站健康检查。
最后更新:
想持续监控这个网站？用 myeventwatch 免费监控——到期和宕机提醒，无需绑卡。
检查的运行方式
检查器会对你输入的 URL 做一次受保护的服务器抓取、跟随重定向，并读取最终页面的静态 HTML——也就是平台抓取器看到的同一份 HTML。它解析 og: 与 twitter: meta 标签、页面 <title> 和 meta 描述，然后逐个平台推算每张分享卡片实际会显示哪个值、这个值来自哪里。由回退提供的值会被标注为回退，因此一张看起来完整的卡片不会掩盖其下缺失的标签。
有一个限制决定了其余一切：这是一次普通 HTTP 抓取，不是浏览器，而平台抓取器也不是浏览器——两者都不运行 JavaScript。由脚本注入、仅在客户端渲染、或只在登录后添加的标签，在这里看不到，在 Facebook、X、LinkedIn 和 Slack 上也同样看不到。如果一个标签只存在于你的 JavaScript 包里，它对分享来说就不存在。结果中显示的内容——最终 URL、HTTP 状态、原始标签表和四张渲染出的卡片——就是抓取器必须依据的静态事实。
回退、相对图片陷阱与抓取器缓存
每个平台的回退方式都不同，这正是同一个页面在一个应用里正常、在另一个应用里损坏的原因。Facebook 直接读取 og: 标签。X 先读取自己的 twitter: 标签，缺失时回退到对应的 og: 标签。LinkedIn 只读取 og: 标签，因此再完美的 Twitter Card 设置对它也毫无帮助。Slack 先读取 og: 标签，再读取 twitter: 标签。下方的清单会标出每个缺失字段、每个空字段，以及每个会被平台用回退填补的字段，并注明它会回退到哪个来源。
最常见的无声失败是相对路径的 og:image：像 /images/share.jpg 这样的值在你的模板和浏览器里看起来没问题，但大多数抓取器无法对它做任何解析，于是卡片干脆不显示图片。修复方法永远是带协议的绝对 URL。第二个陷阱是缓存：每个平台都会缓存其抓取器抓到的内容，因此修复标签并不会更新已经发出的帖子，甚至新的预览也可能继续提供旧卡片，直到你要求平台重新抓取该 URL。先修标签、在这里验证、然后重新抓取——必须按这个顺序，否则你会把损坏的版本再次缓存下来。
诚实的边界：这里的预览是对各平台已公开行为的模拟，不是真实帖子的截图。各平台裁剪、圆角和截断的方式各不相同，卡片布局会不经通知地改变，登录与未登录用户看到的也可能不同，因此请把卡片当作忠实的模型，而不是保证。有一件事不是模拟的：分享图片的尺寸读取自实际图片文件的文件头，而不是页面声明的 og:image:width 与 og:image:height 值——声明值只是说法，本检查器会拿文件本身来核对它。
检查内容及其背后的规则
| 检查的标签 | og:title、og:description、og:image、og:url、og:type 和 og:site_name，加上 twitter:card、twitter:title、twitter:description 和 twitter:image——以及作为回退来源的页面 <title> 和 meta 描述。 |
| 推荐图片尺寸 — 1200 × 630 px | 1200 × 630 是平台指引，不是正式标准：它是 Facebook 推荐的尺寸，也是 X、LinkedIn 和 Slack 处理效果最好的大卡片尺寸。更小的图片仍能显示，但卡片可能裁剪它们，或回退成小缩略图。 |
| 直接读取 og: 标签——og:title、og:description 和 og:image——仅在 og: 标签缺失时才回退到页面 <title> 和 meta 描述。 | |
| X（Twitter） | 先读取 twitter:title、twitter:description 和 twitter:image；每一项缺失时都回退到对应的 og: 标签。twitter:card 决定卡片布局，缺失时 X 会根据找到的内容猜测。 |
| LinkedIn 与 Slack | LinkedIn 只读取 og: 标签——twitter: 标签在那里没有帮助。Slack 先读取 og: 标签、再读取 twitter: 标签，因此是四者中最宽容的。 |
| 相对图片 URL | og:image 和 twitter:image 必须是带协议的绝对 URL。大多数抓取器无法解析相对路径，结果就是一张没有图片、且任何地方都没有报错的卡片。 |
| 图片尺寸 | 读取自实际图片文件——它的 PNG、JPEG、GIF 或 WebP 文件头——同时给出字节大小和格式。声明的 og:image:width 和 og:image:height 会显示出来供对比，但从不单独被信任。 |
| 尺寸未知 | 意味着检查器无法抓取或解析图片文件——它超时了、拒绝了请求，或格式的文件头无法读取。届时页面声明的尺寸（如果有）就是所有人——包括抓取器——唯一拥有的信息。 |
常见问题
为什么我分享的链接不显示图片？
按常见程度排序的原因：根本没有 og:image；og:image 是抓取器无法解析的相对 URL；图片太小，或位于抓取器无法抓取的位置（登录之后、被 robots 规则屏蔽，或返回错误）；或者平台仍在显示图片存在之前那次抓取的缓存。在上方运行检查——它会指出适用的是哪一种——修复标签，然后要求平台重新抓取。
Open Graph 标签和 Twitter 标签——两者都需要吗？
实际工作中，需要。Facebook 和 LinkedIn 只读取 og: 标签，而 X 优先使用自己的 twitter: 标签，并把 og: 标签用作回退。一套完整的 og: 标签加一个 twitter:card 标签能覆盖大多数情况，但显式的 twitter:title、twitter:description 和 twitter:image 是让 X 卡片与 Facebook 卡片有所区别的唯一办法——而 Slack 会读取两套标签，先 og: 后 twitter:。
为什么真实帖子和这里的预览不一样？
几乎总是因为缓存。每个平台的抓取器都会缓存它为某个 URL 抓到的内容，修改标签并不会让该缓存失效。修复前发布的帖子会保留旧卡片，甚至平台自己的调试器在被强制重新抓取前也会继续显示缓存版本。较少见的原因是裁剪：平台会按其当前布局裁剪和截断，而这里的预览是对已公开行为的模拟，不是截图。
这个检查器会运行 JavaScript 吗？
不会——而且这是故意的。检查器只抓取一次静态 HTML，与平台抓取器的做法完全相同，而抓取器同样不运行 JavaScript。因此，由脚本或客户端框架添加的标签在这里缺失的原因，与它在 Facebook、X、LinkedIn 和 Slack 上缺失的原因完全相同。如果你的标签由 JavaScript 渲染，它们必须出现在服务器渲染的 HTML 中，才能对分享起作用。
og:image 应该用多大的尺寸？
尽可能使用 1200 × 630 px。这是平台指引而非正式标准——它是 Facebook 推荐的尺寸，也是 X、LinkedIn 和 Slack 大卡片所围绕的尺寸。让文件保持合理的小体积，使用 PNG 或 JPEG（WebP 的支持因抓取器而异），并始终用绝对 URL 引用它。本检查器会标记小于 1200 × 630 的图片，并告诉你它从文件中测得的真实尺寸。