Open Graph 预览，免费

Open Graph 究竟是什么

Open Graph 协议是 Facebook 在 2010 年创建的,目的是把任何网页变成社交图谱中的一个「富对象」,一组结构化元数据,让其他应用(最早是 Facebook,如今还包括 LinkedIn、Slack、Discord、Microsoft Teams、iMessage、WhatsApp,以及其它数十种)在有人粘贴你的 URL 时读取并渲染出预览卡。官方规范在 ogp.me,这一协议事实上已成为 web 上链接分享的通用语言。

没有 OG 标签时,社交平台会抓取你的页面并猜测:它们挑一个标题、抓住第一张能找到的图片,就当作一张卡片。结果通常不是你想要的。有了 OG 标签,你掌控标题、描述和图片,这就是「精致链接」与「看起来坏掉的链接」之间的差别。

四个必需标签(根据 ogp.me)

Open Graph 官方规范定义了四个必需属性。要被认定为一个 Open Graph 对象,页面必须声明全部四个:

推荐的可选标签包括 og:description(一两句话的摘要)、og:site_name(作为标签显示的站点名)、og:locale(语言和地区),以及图片尺寸提示 og:image:width / og:image:height / og:image:alt。包含尺寸提示能让社交客户端预先分配合适大小的空间,避免图片加载时的布局抖动。

Twitter / X Cards:同一思路,标签略有不同

X(原 Twitter)有自己的元数据命名空间,twitter:card、twitter:title、twitter:description、twitter:image、twitter:site、twitter:creator,但重要的是,当 Twitter 专属标签缺失时,X 会回退到 OG 标签。所以一个只发出 OG 标签的页面在 X 上仍然能得到一张卡。两者真正不同之处在于卡片类型:

• twitter:card = summary,小方形缩略图、标题、描述。
• twitter:card = summary_large_image,卡片顶部为全宽图片。这是内容分享的现代默认,因为它在信息流里更能吸引视觉注意。
• app 与 player,分别用于应用安装和内嵌视频。

注意:cards-dev.twitter.com/validator 那个独立的 Twitter Card Validator 预览,X 已于 2022 年 8 月 2 日移除。当前验证一张卡片的方法是:在推文撰写器里开始一条新推文,粘上 URL,让预览渲染出来,你不必真的发出去。一些第三方工具(包括本工具)会近似呈现渲染后的卡片,这样你可以在上线前迭代。

真正可用的图片尺寸

没有单一完美尺寸,但 1200×630(1.91:1 宽高比)是最可靠的单一选择,在所有平台都不会被严重裁剪。各平台建议:

把重要的文字和人脸放在图片中央附近,每个平台裁剪方式不同,放在角落的 logo 可能会被平台 UI 覆盖层挡住。

为什么你的卡片有时不显示

如果你已添加 OG 标签但预览仍然损坏或为空,常见嫌疑:

• 必须 HTTPS。Facebook 和大多数现代平台会拒绝 http:// 图片 URL。请通过 HTTPS 提供 og:image。
• 图片不可公开访问。在认证之后、被 IP 白名单阻挡,或对平台抓取器返回 403。在隐私窗口打开图片 URL 来测试。
• 图片太小。低于平台最低值(Facebook 200×200、LinkedIn 1200×627),卡片会回退为小缩略图,或者根本没有图。
• 宽高比错误。1:1 的方形图作为 summary_large_image 提交到 X,会被居中裁剪,常常裁得很糟。
• 缓存。社交平台会主动缓存你的 OG 元数据。修复标签后,去 Facebook 的 Sharing Debugger 点「Scrape Again」刷新;LinkedIn 的 Post Inspector 类似;X 在下次有人粘贴 URL 时才会获取变更。
• Robots.txt 阻挡了社交抓取器。确保 facebookexternalhit、Twitterbot、LinkedInBot、Slackbot 等 user agent 能取你的页面和图片。
• 服务器对抓取器返回非 2xx。检查你的服务器日志中社交机器人 user agent 的记录。
• 相对图片 URL。og:image 必须是绝对 URL(https://yoursite.com/og.jpg),决不能是 /og.jpg。

缓存问题

一旦社交平台抓取了你的页面,元数据会被缓存一段时间,社区流传的说法是 Facebook 和 LinkedIn 大约 7 天,虽然两家平台都没有正式记录确切的 TTL。更新 OG 标签不会自动刷新缓存。要强制重新抓取,使用官方工具:Facebook Sharing Debugger、LinkedIn Post Inspector。X 在 URL 下次被分享时获取新元数据。Slack 和 Discord 在 fetch 时根据 OG 标签刷新预览,所以比 Facebook 更快更新。

常见的 og:type 值

og:type 标签告诉社交平台页面代表什么类型的对象。大多数页面是 website(默认)或 article;垂直专属值能让平台渲染更丰富的卡片。出自规范:

• website,一般页面的默认。
• article,博客文章、新闻。与 article:published_time、article:author、article:section、article:tag 配对。
• book,与 book:author、book:isbn 配对。
• profile,用于用户资料页。
• video.movie / video.episode / video.tv_show / video.other,用于视频内容。
• music.song / music.album / music.playlist / music.radio_station,用于音乐。

长度限制实务

没有平台对标题或描述长度有硬性上限,但每个平台过了某个点都会截断:

• 标题,保持在大约 60 字符以内,以便在所有平台上都安全;大约 70 字符在多数平台会被截断。关键信息放在前 50 字符。
• 描述,大约 155-200 字符以内才会被截断。移动端更少(约 100)。把关键信息放在前面。
• 图片 alt 文本,应当存在(og:image:alt),为屏幕阅读器和注重无障碍的客户端服务;100 字符以内。

JSON-LD vs Open Graph(它们是不同的东西)

常见混淆:JSON-LD 结构化数据(用 schema.org 词汇)与 Open Graph 元标签做的是不同的工作。OG / Twitter Cards 控制社交分享预览,即有人把你的 URL 粘到 Slack 或 Facebook 时显示的内容。schema.org 的 JSON-LD 帮助 Google 解析你的页面以生成丰富的搜索结果,菜谱卡、产品信息、Google 搜索中的 FAQ 摘要。两者都建议使用,且互不取代。

常见错误

1. 使用相对 og:image URL。规范要求绝对 URL。相对路径会被悄悄丢弃。
2. 所有页面都用通用站点 logo。OG 图片是你卡片的英雄,每个页面都值得有独特图片,理想情况下与页面内容相关联。
3. 忘记 og:image:width 和 og:image:height。有些客户端会预先分配空间,缺少这些提示就会漏掉图片。
4. 遗漏 summary_large_image twitter:card 类型。没有它,X 会默认使用更小的 summary 卡和方形缩略图,通常没那么吸引人。
5. 把关键文字放在图片角落。不同平台裁剪不同。主体和重要文字应当放在中央 80% 的范围内。
6. 更新了标签但没刷新缓存。每次更改后访问官方 Sharing Debugger / Post Inspector。
7. 提交 HTTP 图片 URL。大多数平台拒绝非 HTTPS 图片;卡片会没有图片地出现。
8. 仅使用 og:title 和 og:description。没有 og:image,卡片在大多数平台上会渲染为只有稀疏文字的占位。

常见问题

<meta property="og:title"       content="Your Page Title" />
<meta property="og:type"        content="website" />
<meta property="og:url"         content="https://yoursite.com/page" />
<meta property="og:image"       content="https://yoursite.com/og.jpg" />
<meta property="og:description" content="A short summary of the page." />

相关工具