被忽视的流量入口：文章分享到社交平台后长什么样
很多个人站长把 SEO 的精力全押在搜索引擎上，却忽略了一个同样重要的曝光渠道：当读者把你的一篇文章贴到微信、X（推特）、Facebook、Telegram、Slack 或 Discord 时，平台会自动抓取一个"预览卡片"——标题、摘要、缩略图。这个卡片长得好不好看，直接决定了别人要不要点进来。遗憾的是，绝大多数个人站的卡片要么图片缺失、要么标题被截断、要么干脆是一片灰色占位图，白白浪费了本可以争取到的点击。
控制这个预览卡片的技术标准，就是 Open Graph 协议（OG），外加推特/X 自己的一套 Twitter Card 标签。它们的本质都是写在页面 <head> 里的 <meta> 标签。本文会讲清楚这些标签怎么正确书写、图片尺寸的硬性要求、常见的"分享出去没图"原因，以及如何用官方调试工具验证——全部围绕个人站长能独立完成的实操展开。
Open Graph 到底是什么：给爬虫发的"结构化名片"
搜索引擎蜘蛛和社交平台的抓取爬虫，本质上都是在读你的 HTML。普通页面上，标题在 <title>、摘要在正文里，爬虫得自己去猜。Open Graph 的价值在于，它让你显式地告诉爬虫："标题是这句，摘要是这句，缩略图是这张"，不用它去猜。这套协议最初由 Facebook 提出，现在微信、微博、LinkedIn、Telegram、Slack、Discord 以及大多数内容平台都认这套标签。
最小可用的 OG 标签集是这四个：
<meta property="og:title" content="文章标题，控制在 60 字以内" />
<meta property="og:description" content="一两句话概括，80 到 120 字最佳" />
<meta property="og:image" content="https://www.example.com/img/cover.jpg" />
<meta property="og:url" content="https://www.example.com/article.html" />外加一个 og:type 表明内容类型，博客文章一般用 article，首页用 website。这五个标签写全，绝大多数平台的卡片基本就能正常显示了。
要特别注意 og:url 必须是绝对 URL，且最好与页面的 canonical 链接一致。如果 og:url 指向了带参数的版本、或者和 canonical 不一致，平台会把同一条内容当成两个不同的页面，导致分享数据分散、甚至抓到错误页面。同理，og:image 也必须是绝对 URL——相对路径在很多平台上会直接被忽略，这也是"明明设置了图却显示不出来"的头号原因。
og:image 的尺寸规范：为什么你的图总是显示不出来
图片是社交卡片里最显眼、也最容易出问题的部分。不同平台对尺寸的要求略有差异，但有一个安全的大众选择：
- 推荐尺寸：1200 × 630 像素（约 1.91:1），这是 Facebook、LinkedIn、X 大图卡片最通用的比例。
- 最小尺寸：至少要 600 × 315，低于这个尺寸很多平台会直接不显示缩略图，只留文字。
- 文件大小：控制在 1MB 以内、8MB 是绝对上限。过大不仅抓取慢，还可能被平台放弃。
- 格式：JPG 或 PNG 最稳，WebP 的支持度参差不齐，社交卡片图建议老老实实用 JPG。
除了尺寸，还有几个"隐形杀手"会让图片抓不到：
- 图片地址不可公开访问：如果图片做了防盗链、或者需要登录才能访问，爬虫拿不到图。社交平台的爬虫不会带 referer，也没有你的登录态。
- 图片在 CDN 上但返回了错误的 Content-Type：比如把 JPG 当成了
application/octet-stream返回，某些平台会拒绝。 - 忘记声明图片尺寸：加上
og:image:width和og:image:height能让平台在抓图前就知道比例，避免首屏跳变，也能加速卡片渲染。 - HTTPS 混用：页面是 HTTPS，图片却是 HTTP，会被当作不安全内容屏蔽。
一个稳妥的完整写法是这样的：
<meta property="og:image" content="https://www.example.com/img/cover-1200x630.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="文章封面图的文字说明" />Twitter Card：X 平台的另一套标签
X（原推特）同时认 OG 和 Twitter Card，但会优先使用 Twitter Card。它的关键标签是 twitter:card，取值决定了卡片的形态：
summary：左侧小图 + 右侧文字，适合一般文章。summary_large_image：大图铺在上方，视觉冲击最强，推荐博客文章使用。player：用于视频/音频播放，个人站基本用不到。
典型写法：
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="文章标题" />
<meta name="twitter:description" content="一两句话概括" />
<meta name="twitter:image" content="https://www.example.com/img/cover-1200x630.jpg" />这里有个省事的技巧：如果你的 OG 标签已经写好了，Twitter Card 里标签缺省时 X 会回落到对应的 OG 值（twitter:title 缺省用 og:title，twitter:image 缺省用 og:image）。所以最低成本的兼容方案是：把 OG 五件套写全，再补一个 twitter:card 说明卡片形态即可，不必把两边都完整抄一遍。但 twitter:card 本身不会回落，必须要显式声明，否则默认是 summary 小图。
微信、微博等其他平台的抓取逻辑
国内平台在 OG 之外还有自己的偏好，它们的抓取顺序通常更"土办法"一些：先看有没有专门的自家标签，没有就退回读页面元素。
- 微信：分享到聊天或朋友圈时，微信会读
<title>和og:description，缩略图优先读页面里第一个尺寸合适的<img>，其次才看og:image。所以如果正文第一张图是广告位或者一个很小的 logo，微信卡片很可能抓错图。稳妥的做法是在<head>里显式给出og:image，并保证正文第一张图就是封面。 - 微博：同样认 OG，抓不到时回落到页面标题和首图。
- Telegram / Slack / Discord：基本完全遵循 OG 标准，卡片质量最可控，OG 写对就能显示得漂漂亮亮。
因此，跨平台通用的最佳实践是：OG 标签写全、正文首图即封面、图片绝对 URL 且尺寸达标。不要依赖平台的"猜测"，要主动把信息喂给它。
动手验证：用官方调试工具而不是靠肉眼猜
写好标签后，最忌讳的就是"我觉得应该没问题"然后直接分享。社交平台普遍会缓存抓取结果，一旦第一次抓错了，后续即使你改好了标签，平台也可能还在用旧缓存。所以一定要在分享前用官方调试工具验证，并主动刷新缓存：
- Facebook 分享调试器（developers.facebook.com/tools/debug/）：输入 URL，看它抓到的标题、描述、图片，并提供 "Scrape Again" 强制刷新缓存。这是检验 OG 标签最权威的工具，很多其他平台的行为与它一致。
- X Card Validator：X 官方的卡片预览工具，能直接看到大图/小图卡片效果。
- LinkedIn Post Inspector：同样提供预览和缓存刷新。
如果暂时不想依赖第三方工具，也可以用命令行粗查，确认标签确实输出到了页面源码里（注意要模拟爬虫的 UA，避免被站点的反爬或缓存策略干扰）：
curl -s -A "facebookexternalhit/1.1" https://www.example.com/article.html \
| grep -Ei 'og:|twitter:'如果这条命令输出为空，说明标签根本没渲染到 HTML 里——这在 JavaScript 单页应用或用了懒加载 meta 的站点上非常常见。请记住：社交平台和搜索引擎的爬虫绝大多数不执行 JavaScript，你必须保证 OG 标签在服务器返回的原始 HTML 里就存在。这是"标签写了却没生效"最隐蔽的一类原因。
一次真实的排查：卡片一直是灰图，问题出在爬虫被拦
我运营的一个技术博客上线初期，所有文章的社交卡片都是灰色占位图，标题和描述倒是正常。按经验，标题正常说明 meta 标签本身没问题，问题只可能出在图片上。我先用 Facebook 调试器检查，工具明确提示 Could not fetch the image，并给出了图片 URL。
直接在浏览器里打开那个图片 URL，图片显示得好好的。这就排除了 URL 拼错和图片不存在的可能。接着我用命令行模拟爬虫抓了一次图片：
curl -I -A "facebookexternalhit/1.1" https://www.example.com/img/cover.jpg结果返回了 403 Forbidden。谜底揭晓：我在 Nginx 里配了防盗链规则，valid_referers 只放行了本站域名，而社交平台的爬虫请求图片时没有 referer 头，于是被防盗链规则一刀切拦掉了。这也解释了为什么用浏览器访问正常——浏览器带着 referer。
修复方法是在防盗链白名单里显式放行这些爬虫的 UA，或者对图片目录放宽 referer 校验：
location ~* \.(jpg|jpeg|png|webp|gif)$ {
valid_referers none blocked server_names
*.facebook.com facebookexternalhit
*.twitter.com *.x.com
*.linkedin.com *.telegram.org;
if ($invalid_referer) {
return 403;
}
}注意 none blocked 这两个关键字很关键：none 表示"允许完全没有 referer 的请求"，blocked 表示"允许 referer 被防火墙抹掉的请求"。这两个正是爬虫请求图片时的典型特征，漏掉它们的防盗链规则几乎必然会让社交卡片抓不到图。加上之后，再用调试器 Scrape Again 刷新缓存，卡片立刻恢复成了漂亮的大图。
给个人站的 OG 落地清单
把上面的内容浓缩成一份可以直接照着做的清单：
- 每篇文章的
<head>里都输出og:title、og:description、og:image、og:url、og:type五件套，全部用绝对 URL。 - 封面图统一做成 1200 × 630 的 JPG，控制在 1MB 以内，并声明
og:image:width/height/alt。 - 补一个
twitter:card = summary_large_image，其余 Twitter 标签可依赖对 OG 的回落。 - 确保 OG 标签在服务器端渲染的原始 HTML 中存在，不依赖 JS 注入。
- 防盗链白名单里放行
none blocked和主流爬虫 UA，单独验证图片 URL 能被爬虫抓到。 - 分享前用 Facebook 调试器 / X 卡片验证器检查，并主动刷新缓存。
- 把 OG 标签的生成写进站点模板，让每篇新文自动带上，而不是手动维护。
Open Graph 是一项投入极小、回报很直接的工作：它不改变你的内容质量，却能让同样一篇文章在被分享时多争取到一次点击。对个人站长而言，与其纠结于难以影响的搜索排名算法，不如先把这些"确定性高、成本低"的曝光细节做到位。把 OG 和 Twitter Card 写扎实，你的每一篇文章在被别人转发的瞬间，就已经赢在了起跑线上。