最后更新: 2026-09-05

OGP 文本优化 - 改善社交媒体分享显示效果

OGP (Open Graph Protocol) 是控制网页在社交媒体上分享时显示内容 (需注意截断问题) 的协议。该协议最初由 Facebook 开发并于 2010 年公开，截至 2026 年 8 月，主要的社交媒体和即时通讯应用都已广泛采用。如果未正确设置，标题可能会被截断，或显示非预期的描述文本，使链接本身失去吸引力。本文将详细解析 OGP 文本的优化方法，以及如何区分哪些内容可以在官方规范中得到确认、哪些不能。

Open Graph Protocol 的规范与历史

OGP 最初是在 Facebook 内部开发的元数据规范，并于 2010 年公开。通过在 HTML 的 <head> 中添加 <meta property="og:..."> 标签，向爬虫传递页面的结构化信息。规范在 ogp.me 上公开，其中把 og:title、og:type、og:image、og:url 四个属性定义为所有页面都必需的属性。规范的初版以 RDFa 为基础，因此书写形式采用 property 属性。

这里需要先明确一点。ogp.me 的规范只规定了"写哪些属性、怎么写"，并没有为 og:title 或 og:description 定义任何字数上限。关于 og:description，规范中也只有"一到两句话的说明"这样的描述，没有给出具体字数。也就是说，后文提到的字数目标全部不是规范的规定，而是从显示端的条件反推出来的实务参考值，并非平台官方保证的数字。

在 OGP 出现之前，社交媒体通过读取页面的 <title> 标签和 <meta name="description"> 来生成预览。然而，这些内容是为搜索引擎优化的文本，在社交媒体信息流中显示时往往过于冗长或缺乏上下文。OGP 通过提供专用于社交媒体显示的元数据层来解决这一问题。

显示字数为什么没有"官方数字"

谈到 OGP 的写法，最常被追问的就是"每个平台到底显示多少字"。但截至 2026 年 8 月，各平台都没有以字数为单位公布过显示上限，因为决定显示量的并不是字数本身。同一段 og:title 在窄屏手机上会提前折行，在桌面浏览器的宽卡片里可能一行放完；用户把系统字号调大，可见的字数就随之减少；西文与中日韩文字的字宽不同，同样的"三十个字符"占据的横向空间也不一样。再加上同一个平台会依据是否有大图、是否为纯链接、是否在对话气泡内而切换成不同的卡片形态，所以"显示 N 个字"这类数字只能描述某一台设备在某一次更新中的一次观察，无法作为规范来引用。下表整理的是影响显示量的几个维度，而不是可以直接套用的数值。

因此，本文提到的字数目标都只是为了让文本在最窄的显示条件下也能读懂而设的余量，而不是任何平台承诺的界限。与其追求某个精确的数字，更实用的做法是假定"随时可能在任意位置被切断"，再据此安排语序。

无论在哪里被切断都能成立的语序

既然截断位置无法预先确定，能自己掌控的就只有语序。要点是把"读到这里就已经知道这篇讲什么"的成分尽量往前挪。例如"介绍改善分享显示效果的五种做法"这样的句子，一旦后半被切掉就只剩下修饰语，读者无从判断内容；改成"五种做法｜改善分享显示效果"这种把核心先摆出来的结构，即使只剩前段也仍然成立。中文的定语常常堆在中心词之前，写长了就容易让真正的主题被推到末尾，这一点尤其需要留意。

同样的原则也适用于说明文本。把结论放在第一句，把背景、条件、补充说明依次往后排，这样即便只有开头进入视野，信息也没有缺口。相反，先铺陈背景再抛出结论的写法，在被截断时损失最大。另外，如果标题依赖说明文本才能读懂，那么在完全不显示说明的卡片形态下就会失去意义，所以标题应当能够单独成立。

og:title 的优化

og:title 是分享时最醒目的元素，也是读者在信息流里最先读到的一行。由于可以与页面的 title 标签分开设置，因此可以使用针对社交媒体场景调整过的表达方式。

撰写高效 og:title 的要点如下：

• 以 40 字左右为目标：在较窄的显示条件下也能把主要内容读完，留出被截断的余量
• 省略网站名称：分享卡片本身已经标出了域名，把有限的横向空间让给文章内容
• 写入具体的数量或范围："五种做法"这类成分即使后文被切掉，也仍然保留了可判断的信息
• 避免把主题词放在句末：疑问句和呼吁式表达如果关键词落在末尾，被截断后就只剩语气

og:title 与 HTML title 不一致时的行为

og:title 和 HTML 的 <title> 标签是独立的元素，可以设置不同的值。各平台的爬虫会优先读取 og:title，但如果 og:title 未设置，则会回退到 <title> 标签的值。

但需要注意的是，og:title 也是 Google 生成搜索结果标题链接时会参考的材料之一。因此如果两者内容差异过大，搜索结果里显示出来的可能并不是为搜索优化的 title 标签。建议 SEO 用的 title 标签包含关键词，og:title 则侧重社交媒体场景的可读性，但两者的主题必须保持一致。

Google 的官方说明列出了会改写标题链接的几种情形：标题写了一半、几乎是空的；标题内容与页面实际内容不符；标题里带着已经过时的年份；站内多个页面使用完全相同的模板化标题；页面的主标题不明确、难以判断哪一行才是标题；标题的语言与正文的语言不一致。值得注意的是，"标题太长"并不在这份改写理由之列。

换句话说，过长的标题遇到的是另一种现象，也就是被切短显示，而不是被换成别的文字。这两件事的应对方式完全不同：改写要靠修正标题与内容的对应关系来避免，而切短只能靠语序设计来减轻影响。把它们混为一谈，就容易得出"缩短标题就能防止被改写"这种无效结论。

og:description 的写作方法

og:description 是显示在标题下方的补充文本，承担着补充标题未能传达的信息、促进点击的作用。

og:description 在实务上以 70-100 字符左右为宜，这同样只是为被截断留出余量的参考值，并非规范的规定。将最重要的信息放在前 40 个字符中，确保即使被截断也能传达完整含义。内容可以与 meta description 相同，但针对社交媒体用户群体使用更轻松的表达方式也是有效的策略。

og:description 未设置时的回退机制

未设置 og:description 时，各平台会使用各自的逻辑生成回退文本。Facebook 会使用 <meta name="description"> 的值，如果也未设置则自动提取页面正文的开头文本。X (Twitter) 会优先采用以 twitter 为前缀的标签，未设置时则转而参考以 og 为前缀的标签，两者都没有的情况下从页面正文中提取。

自动提取的文本可能混入导航菜单或侧边栏的文字，产生非预期显示的风险很高。务必明确设置 og:description。可以使用字符计数器确认 og:title 和 og:description (字数限制相关) 的字数，检查是否在各平台的显示限制范围内。

OGP 图片 (og:image) 的设计

OGP 图片是分享卡片里占面积最大的部分，也是唯一能在读者尚未阅读文字时就传达信息的元素。图片的具体条件当中，Facebook 是把数值写进官方文档的少数平台之一：最小尺寸为 200×200px，推荐使用 1200×630px 以上，若希望以大卡片形式呈现则需要 600×315px 以上，宽高比按 1.91:1 设计，文件大小的上限为 8 MB。

如果要在图片里放文字，字数越少越好。卡片在信息流中会被缩小显示，原封不动搬进去的长标题在缩小后基本无法辨认，所以应当只提取核心成分再排版。下表汇总了常被引用的图片条件，但需要说明的是，除 Facebook 一行之外，其余平台并未把这些数值作为规格公开，它们属于截至 2026 年 8 月被广泛沿用的实务参考值。

• 图片尺寸：以 1200×630px (横向) 为基准。官方给出的上限是 8 MB，但实务上建议压到 1MB 以下以确保加载速度
• 文字位置：放置在图片中央至上部，下部可能与平台 UI 重叠
• 字体大小：按缩小后仍能辨认为准，宁可偏大
• 背景色：确保与文字有足够的对比度。以 WCAG AA 标准 (对比度 4.5:1 以上) 为参考

各平台爬虫的行为特征

获取 OGP 信息的爬虫在不同平台上表现各异。Facebook 的爬虫 (facebookexternalhit) 可通过 User-Agent 头识别，且不执行 JavaScript。因此，使用客户端渲染 (CSR) 动态生成 OGP 标签的网站会出现 OGP 信息无法正确获取的问题。

X (Twitter) 的 Twitterbot 同样不执行 JavaScript。LINE 的爬虫也只解析静态 HTML。Slack 的 Slackbot 会跟随重定向，但同样不执行 JavaScript。共同的前提是，这些爬虫都不会等待页面在浏览器里跑完脚本，因此应当让首次访问就能直接返回含有 OGP 标签的 HTML。

如果使用 React 或 Vue.js 等 SPA 框架，OGP 标签需要通过服务端渲染 (SSR) 或静态站点生成 (SSG) 输出。利用 Next.js 的 generateMetadata 或 Nuxt 的 useHead，可以在框架机制内正确输出 OGP 标签。

OGP 缓存机制与更新方法

各平台会缓存 OGP 信息，即使更新了页面的 OGP 标签也不会立即生效。至于缓存保留多久，截至 2026 年 8 月各平台都没有公开过具体数值，所以与其去猜有效期，不如按"是否存在明确的更新手段"来区分应对方式。

• Facebook：提供了分享调试器，输入 URL 并执行"重新抓取"即可主动刷新，属于有明确更新手段的一类
• X (Twitter)：没有对外公开的缓存周期，也不宜假定某个固定天数。可靠的确认办法是先发一条仅自己可见的草稿贴，直接看预览
• LINE：官方未提供手动清除缓存的方法，因此只能视为无法主动刷新，尽量在对外公布之前就把标签定好
• Slack：重新粘贴 URL 可能仍显示旧缓存。可在 URL 末尾添加查询参数 (如 ?v=2) 使其被识别为新 URL 来规避

由此可以得出一条比记住任何数字都实用的原则：发布后的修改，其生效时间不在自己的掌控之内。所以在把 URL 分发给别人之前，先自己分享一次、亲眼确认卡片的样子，才是最省事的做法。

OGP 调试工具的使用方法

设置 OGP 后，使用各平台的调试工具确认显示效果是不可或缺的步骤。如果在未发现设置错误的情况下发布，每次被分享时都会传播非预期的显示效果。

确认手段可以分成三层，从不依赖外部服务的一层开始更为稳妥：

• 先看原始 HTML：用 curl 取回页面并查看 <head> 里的 OGP 标签，可以立刻判断标签究竟有没有被输出。这一步与任何平台的工具都无关，也不会受缓存影响
• 再用草稿预览：在目标平台上把 URL 贴进输入框但不发布，就能看到实际的卡片形态。这是唯一能反映该平台当前渲染方式的办法
• 最后借助平台自带工具：Facebook 分享调试器输入 URL 后会显示 og:title、og:description、og:image 的预览，"警告"部分还会报告缺失的属性；LinkedIn Post Inspector 可以确认在该平台上的分享显示效果。这类工具的可用性由平台方决定，不宜作为流程中不可替代的一环

为防止 OGP 标签设置遗漏，建议养成使用字符计数器预先检查 og:title 和 og:description 长度、确认留有被截断余量的习惯。

各 CMS 的 OGP 设置方法

主流 CMS 和框架的 OGP 标签设置方法各不相同。

• WordPress：可通过 Yoast SEO 或 All in One SEO Pack 等插件在 GUI 中设置。在文章编辑界面的"社交"选项卡中可单独指定 og:title 和 og:description
• Next.js：通过 generateMetadata 函数返回 openGraph 属性，可为每个页面动态生成 OGP 标签
• Nuxt：使用 useHead 组合式函数或 nuxt.config.ts 的 app.head 设置 OGP 元标签
• 静态 HTML：在 <head> 中直接编写 <meta property="og:..."> 标签。使用模板引擎时可通过变量动态插入值

动态 OGP 生成的注意事项

基于用户输入或数据库值动态生成 OGP 标签时，需要注意以下几点。

首先，必须彻底进行 HTML 转义。在 og:title 或 og:description 中包含用户输入时，如果未正确转义 <、>、&、"，将产生 HTML 注入漏洞。

其次，动态生成 og:image 时 (如使用 Vercel OG Image Generation 或 Cloudinary 的动态转换)，如果图片生成耗时过长，爬虫可能在图片就绪之前就放弃抓取。各平台并未公布等待多久才算超时，所以稳妥的做法是不要让爬虫等待生成过程，而是预先缓存图片或通过 CDN 分发，使首次访问就能直接返回结果。

此外，当 URL 包含查询参数或片段标识符时，og:url 应设置为规范化的 URL (不含查询参数)。这可以防止同一内容的不同 URL 导致分享数分散。

变化的不是规范，而是显示端

回顾 OGP 的沿革，会发现一件对日常维护很有帮助的事：ogp.me 所定义的必须属性构成一直没有变过，og:title、og:type、og:image、og:url 这四项从公开至今保持一致。真正在变的是各平台的卡片形态和它们推荐的图片尺寸，而这些属于显示端的规格，并不是 OGP 规范本身的修订。因此维护的优先顺序也就清楚了：标签结构写对一次即可长期沿用，需要定期回头确认的只有图片的尺寸与裁切效果，以及卡片实际呈现出来的样子。

X (原 Twitter) 拥有独立的 Twitter Card 元标签 (twitter:card、twitter:title 等)，但当 Twitter Card 标签未设置时会回退到 OGP 标签。因此，只要正确设置了 OGP 标签，即使省略 Twitter Card 标签也能确保基本显示。不过，twitter:card 标签在 OGP 中没有对应属性，需要单独设置。

常见错误模式

• 将 og:title 与 title 标签设为完全相同，未能发挥社交媒体的吸引力。建议 SEO 用的 title 标签包含关键词，og:title 则使用更具感染力的表达来提升点击率
• 未设置 og:image 就被分享，平台自动选择了无关的图片。特别容易选中 logo 图片或图标，结果卡片无法说明这篇页面究竟讲什么
• 未设置 og:url 或使用了相对路径。og:url 必须使用以 https:// 开头的绝对 URL。使用相对路径时，部分平台可能无法正确解析 URL，导致分享数在不同页面间分散
• 省略 og:type。ogp.me 把 og:type 定义为必须属性，省略就等于把如何解释这个页面交给各平台的默认处理。为博客文章明确指定 article，才能用上发布日期和作者信息等附加元数据

专业技巧

• 把最重要的信息放在 og:title 的开头。信息流是被快速滚过的，而且末尾随时可能被截掉，开头承担的信息量因此最大
• 图片里的文字宁少勿多。卡片在信息流中会被缩小，文字铺得越满，缩小后越是一片糊成一团、什么都读不出来，留白反而提升了可辨识度
• og:description 的第一句就把结论写完。放在后面的补充说明本来就有可能不进入视野，先给结论至少保证读到的部分是完整的
• 把同一篇文章的不同写法在自己的时间线上先各发一次预览，比较哪一种在窄屏上仍然读得通。这比推敲字数更能发现语序上的问题

总结

整理 OGP 文本优化，可以归结为两点。第一，规范本身没有规定任何字数上限，og:title 以 40 字左右、og:description 以 70-100 字符左右为目标，都只是为不可预测的截断留出余量的实务参考值，不是需要严守的界限；既然截断位置无法控制，能做的就是把结论放在前面，让文本在任何位置断开都还成立。第二，OGP 标签与 HTML 的 title 标签、meta description 是彼此独立的，可以分别写成适合各自场景的文字，但主题必须一致。最后，由于发布后的修改何时生效并不由自己决定，把 URL 分发出去之前先自己分享一次、确认卡片的实际样子，是最有效的一道检查。也可以使用字符计数器预先掌握文本长度，为截断留足余量。