og image not showing 到底卡在哪：30 个首页 27 个声明，3 个文件过不了分享卡片的规则
og image not showing 多半不是标签的问题，是文件的问题。2026-09-27 读的 30 个首页里，27 个声明了 og:image，其中 3 个文件分别是一个 404、一个 SVG、一个 9.4 MB 的 GIF——各自踩了分享卡片明文规定的一条线。
实测 · 2026-09-27 · 30 个首页 + 我们自己的 6 个站 · 单次抓取
样本与口径：30 个首页和我们自己跑的 6 个站，各抓一次（2026-09-27，curl，桌面 Chrome UA，跟随跳转，不执行 JavaScript）。做法是从返回的 HTML 里取出第一个 og:image，再把这个地址抓一遍，读它真实的 HTTP 状态、内容类型和像素尺寸。
og image not showing 多半不是标签的问题，是文件的问题。这次 30 个首页里有 28 个正常应答，其中 27 个声明了 og:image；而在这 27 个文件里，有 3 个踩到了分享卡片明文规定的某条线：一个是 404，一个是 SVG，一个是 9.4 MB 的动图 GIF。三个页面都写了标签，问题出在标签背后的那个文件。
怎么测的
口径在抓取前定死，抓完没有改。
- 对
https://<域名>/发一次请求，跟随跳转，用浏览器 UA，保留响应体。 - 读返回 HTML 里所有
<meta>，取第一个og:image，以及有的话取og:image:width/og:image:height。 - 把这个地址原样抓一遍，记下状态码、
Content-Type和文件大小。 - 从下载到的文件头里读出真实像素尺寸，和声明的尺寸对照。
有一条规则让样本保持干净：返回 200 但其实是挑战页、不是首页的，不算数。medium.com 和 nytimes.com 返回 403，被剔除，30 个里剩 28 个。
og image not showing：27 个声明里那 3 个出了什么
27 个文件里有 24 个是返回 200 的 JPEG 或 PNG。剩下 3 个各自违反了一条平台明文写下的规则——那些平台是要真的把这张图渲染出来的。
| 步骤 | 数量 |
|---|---|
| 请求的首页 | 30 |
| 返回 200 | 28 |
| 声明了 og:image | 27 |
| 文件返回 200 | 26 |
| 是 JPEG 或 PNG | 24 |
| 还声明了宽高 | 6 |
| 站点 | 声明 | 实际抓回 |
|---|---|---|
| techcrunch.com | .png | HTTP 404 |
| substack.com | 400 × 400 | image/svg+xml |
| figma.com | 1200 × 630 | image/gif，9.4 MB |
| supabase.com | 800 × 600 | 1200 × 600 png |
| wikipedia.org | 无 | 250 × 229 png |
前三行各自对得上一条写下来的规则。Meta 的分享图片文档要求文件「must not exceed 8 MB」，那个 9.4 MB 的 GIF 越了线。X 的 cards 参考页说得很直接：「SVG is not supported」，而且动图「only the first frame of an animated GIF will be used」，这一句cover了其中两个。404 则不需要任何规则——文件根本不在。
后两行不是失败，是不一致。supabase 声明 800 × 600，实际给的是 1200 × 600；维基百科那个标识是 250 × 229，贴着 200 × 200 的下限，离填满宽卡的 1200 × 630 很远。27 个声明文件里，正好 1200 × 630 的有 8 个。
我们自己的站也在这一批里，而且有两个是问题最明显的。biaojixia.com 和 querywin.com 的首页压根没声明 og:image。byerisk.com 和 sizemarker.com 是干净的 1200 × 630 PNG。
轮到你的页面，按这个顺序查
标签是最好办的一步，也几乎从不是原因。按下面这个顺序查。
- 先把 og:image 那个地址本身抓一遍。它必须返回 200 且内容类型是图片。404 在页面源码里完全看不出来，所以这一步放第一。
- 用 JPEG 或 PNG。卡片规范是围绕位图写的。SVG 是一份文档、不是一个位图，X 的参考页直接点名排除它。
- 别超体积上限，尺寸贴着 1200 × 630。Meta 写了下限 200 × 200、推荐 1200 × 630、上限 8 MB；一个 9.4 MB 的文件就是一张永远加载不出来的预览。
- 用绝对的 HTTPS 地址。这次面板上 27 个声明全是绝对地址，所以这一条不是本次样本的坑——但在别处它仍然是常见原因。
- 还是不显示，就怀疑平台缓存。各家平台都会把卡片缓存下来、按需回来取；用它的调试器重新抓一次，而不是再回去改标签。
预览图不出来，是文件坏了的情况，远多于标签没写。
这次测量说不清的一件事是：某个平台是不是真的拒绝了这三个文件里的某一个。我们抓了地址、读了返回，但没跑分享调试器去看一张卡片失败。这是这篇的局限，也是我们只报文件事实、不报「坏了几个预览」的原因。
常见问题
og image 为什么不显示？
顺序多半是文件、缓存、标签。先确认地址返回 200 且是图片、是位图格式、没有超体积；文件没问题，再让平台重新抓一次页面。
og:image 要多大？
Meta 的分享图片指引要求至少 200 × 200 像素、推荐 1200 × 630 以适配高分屏，文件上限 8 MB；1.91:1 的比例能填满宽卡而不裁切。这次面板上 27 个声明文件里有 8 个正好是 1200 × 630。
og:image 会影响收录或排名吗？
不是排名因素，Google 的文档里也没有把它写成排名输入。它影响的是页面被分享出去时别人看到的那张卡片，那是点击率的问题，不是排名的问题。把它当成一个分发修复来看。
没写 twitter:image，X 会用 og:image 吗？
会回退。X 的 cards 参考页在自家图片标签的 OpenGraph 一栏里写的就是 og:image，所以只写 og:image、不写 twitter:image 的页面仍然能出卡片。
你们是怎么测的？
2026-09-27，每个首页各一次请求，桌面 Chrome UA，跟随跳转。从返回 HTML 里读第一个 og:image，把那个地址抓一遍，读状态、内容类型和尺寸。两个首页返回 403 被剔除。我们没打开任何平台的调试器。
这个规律比那个百分比值钱：一个声明出来的标签，完全不能证明它背后的文件是可用的。同一道缝在外一层也有——open graph 标签实测数了字段齐不齐，但没有去抓那些文件；这里用到的尺寸口径是 og image 怎么配 那一篇；og:url 那一半另有 og url 和 canonical 对不对得上 这次实测。把这些变成你今天能上线的一个改动，是 QueryWin 在做的那部分。
