FastOG

社交预览由两部分组成：您的网站提供的元数据和图片，以及平台在抓取您的页面后保存的副本。修复前者并不会自动清除后者。

这是一份简洁的平台指南，用于诊断过时、缺失或被裁剪的产品预览。

平台对比

平台	您可控制的内容	刷新机制
Facebook	公开 HTML、`og:image`、图片 URL 与页面缓存	Facebook 支持通过 Sharing Debugger 及其文档化的抓取端点重新抓取。配置后，FastOG 可请求 Facebook 刷新。
WhatsApp	后续的公开 HTML 与图片响应	无公开的预览刷新 API。缓存预览由 WhatsApp 控制，且可能因接收者而异。
LinkedIn	公开 HTML 与图片响应	无文档化的程序化失效端点。LinkedIn 自行决定何时重新抓取。
X	公开 HTML、`twitter:image` 及备用 Open Graph 标签	无文档化的程序化失效端点。X 自行决定何时重新抓取。
Slack	公开 HTML 与图片响应	Slack 会缓存已分享 URL 的链接预览；应用无法强制重建所有现有消息。
Discord	公开 HTML 与图片响应	Discord 会缓存已分享 URL 的嵌入内容；应用无法在所有位置重写现有嵌入。

平台行为与端点会发生变化。请将上表视为操作边界，而非刷新时机的承诺。

先诊断问题根源

在归咎于平台之前，请先检查爬虫实际接收到的页面内容：

bash

curl -s https://example.com/product/example | grep -Ei 'og:image|og:title|twitter:image'

然后从响应中获取图片 URL：

bash

curl -I "https://cdn.example.com/cover.png"

页面应展示最新的元数据，图片 URL 应为公开可访问，且图片响应应返回受支持的图片内容类型，并带有 200 OK。如果页面缓存提供的是旧 HTML，那么任何平台都无法发现新的封面图。

为什么更改图片 URL 会有帮助

社交平台会缓存页面 URL，也可能缓存图片 URL。因此，当产品数据发生变化时，动态封面应使用新的图片 URL。产品固定链接（permalink）保持规范，而图片缓存键（cache key）则随之变化。

在产品固定链接中添加 ?v=2 可以让测试看起来是新的，但这会为同一产品创建第二个地址，并可能导致分析和分享历史数据分散。请尽可能改为对图片 URL 进行版本控制。

Facebook 是例外情况

在本指南中，Facebook 是唯一一个 FastOG 提供主动重新抓取（re-scrape）路径的平台。启用后，产品更新可将针对该产品 URL 的请求排队发送至 Meta 的抓取端点。该请求为排队且尽力而为（best-effort）模式，因此速率限制或 Meta 的临时错误不会阻止商店提供正确的元数据。

此操作不会刷新 WhatsApp、LinkedIn、X、Slack 或 Discord。请勿将 Facebook 重新抓取描述为通用的社交缓存清除（social-cache purge）。

实际操作顺序

抓取实时页面，确认当前标签。
如果标签已过期，清除站点的页面缓存或 CDN。
确认图片 URL 是公开的，并且能返回图片。
当图片字节发生变化时，更新图片 URL。
对于 Facebook，使用其调试工具或配置好的重新抓取路径。
对于其他平台，等待新的抓取，或分享一个尚未被缓存的 URL。不要承诺具体的延迟时间。

免费 OG 图片测试器可以抓取产品 URL，并显示爬虫可见的元数据以及生成的封面图。它有助于区分是商店端的问题还是平台端缓存的问题。

常见问题解答

不能。插件只能控制网站提供的 HTML 和图片 URL。每个平台都控制着自己的爬虫和缓存。

为什么预览在 Facebook 上显示正确，但在 WhatsApp 上却显示旧内容？

各平台维护着独立的缓存。Facebook 的重新抓取只会更新 Facebook 上的副本；WhatsApp 则保留其接收者专属的预览。

每次价格更新后，我是否应该更改产品 URL？

通常不需要。请保持规范的产品 URL 稳定，仅在封面内容变化时更改生成的图片 URL。更改页面 URL 是一种粗暴的缓存刷新手段，会带来 SEO 和分析成本。

新的图片 URL 能否保证 WhatsApp 立即更新？

不能。它只能保证下次抓取该图片 URL 时能获取到新数据，但无法强制 WhatsApp 抓取页面，也无法替换已存储在接收者应用中的预览。

社交预览缓存指南：Facebook、WhatsApp、LinkedIn、X、Slack 和 Discord