sameAs写的社交账号，和页脚那排图标是同一批吗？

摘要：131个海外品牌站的首页，117个能拿到完整HTML。结构化数据里写了sameAs的62个、页面上挂着社交图标的91个、填了twitter:site的37个，三份都齐的只有20个站。两边都写了社交身份、能拿来逐条对的52个站里，两份平台清单完全一致的只有22个，占42.3%；更硬的是有11个站的同一个平台在两处指向两个不同账号，一共17处。推特改名快三年了，站上还写着旧域名的39个站，写新域名的21个，两种混着写的5个。还有12个站往sameAs数组里塞了64条空字符串，以及一个把平台默认值原样发出去的twitter:site：@shopify。

做GEO这两年，被问得最多的一句话是“我schema都写全了，AI为什么还是不提我”。这句话背后通常有个隐含假设：结构化数据是一份权威声明，写上去就代表事实。

可结构化数据里那份声明，是从别的地方抄过来的。你的Instagram账号写在页脚一份、写在schema的sameAs里一份、写在分享卡片的twitter:site里一份。三份的来源是同一件事，维护它们的却是三套完全不同的机制——页脚归前端模板，sameAs归主题设置或者某个应用，twitter:site归SEO插件。

所以保哥把这三份放在一起量了一遍。规则很简单：只看首页，只做就地比对，不去社交平台验活（平台对爬虫大面积403和登录墙，验不出真假，只会把尺子弄坏）。

一个品牌在自己首页上，“我是谁”要说几遍？

131个站里，117个能拿到完整HTML。剩下14个要么403，要么返回的是空壳，一律不进样本。

在这117个里，三份副本的覆盖情况是这样的：

交叉起来看更清楚：三份都有的20个站，只有页面那一份的27个，三份一份都没有的16个。

先别急着说27那批做得差。他们至少把最要紧的那份给了人，而且哪些结构化数据值得先做这件事上，Organization本来就不该排在产品之前。真正尴尬的是另一头——有9个站写了sameAs、写了twitter:site，页面上却没有一个社交图标。写给机器的三份齐了，写给人的那一份反而不见了。

写了sameAs的站，一般写几条

62个站一共319条，中位数5条，最多的20条，最少的1条。页面上那份的中位数也是5条，最多19条。两边的量级几乎一样——这说明它们本来就应该是同一份东西，不是一个详一个略的关系。

两份清单对得上吗？

把两边都写了社交身份的站挑出来，一共52个。比对方法是先把地址归一到平台粒度（instagram、facebook、twitter这一级，x.com和twitter.com算同一个平台），再看两个集合差在哪。

两份平台清单完全一致的22个，占42.3%。剩下30个站，两边至少差一个平台。差法分两种：

一种是schema写了、页面上没有，命中最多的是推特8个站、领英8个、YouTube 8个、Pinterest 7个——典型场景是页脚图标下线了，schema那份没人动。另一种反过来，页面上有、schema没写，最多的是TikTok 6个、Pinterest 6个、Spotify 2个——新开的账号只加了图标，schema没跟上。

这两行的方向很有意思。往回缩的时候，缩的是页面；往前加的时候，加的也是页面。schema那一份在两个方向上都是慢的——它既留着已经不维护的旧账号，又不知道新开了哪几个。

几个具体的：cybex-online的schema里只多了领英，页面上却多出Instagram、Pinterest、YouTube三个；joolz反过来，schema多了TikTok，页面多了四个；ecoflow最极端，schema里是Facebook、Instagram、推特、YouTube这套国际组合，页面上挂的是B站、抖音、微博——两份说的根本不是给同一批人看的账号。

同一个平台，两处写着两个账号，是怎么发生的？

比“少写一个平台”严重得多的是这一类：两处都写了同一个平台，但指向两个不同的账号。11个站，17处。

这张表里有三种不同的病因，值得拆开：

第一种：账号改过名，只改了一处

getquip那两行最典型：TikTok上schema写getquip、页面写quip；YouTube上刚好反过来，schema写quip、页面写getquip。这个品牌显然在某个时点把账号从quip统一成getquip，两个平台各改了一半，另一半留在了另一份副本里。改一处、漏一处，而且漏的不是同一处。

第二种：地区账号顶替了主账号

weber的Instagram，schema写的是webergrills，页面上挂的是weberasia。cybex-online的Facebook，schema写国际号、页面挂德国号。jackery的YouTube，schema是全球的jackeryinc、页面是jackeryusa。这类不是错，是页脚被本地化了而schema没有。但对机器来说结果是一样的：它拿到两个候选，得自己猜哪个是主体。

第三种：另一家公司的账号

joolz那一行最值得看：schema里写的是myjoolz，页面上那个领英链接指向milk-design-bv——一个完全不同的公司名。这种通常是收购、拆分或者代运营留下的，页面上那条从来没人回头检查。

三种病因的共同点是：没有任何一个环节会在你改账号的时候提醒你“还有两个地方也写着它”。这和首页的title、og:title和H1说的常常不是同一件事是同一类问题，只不过那一轮量的是同一句话被抄成几份之后的漂移，这一轮量的是同一个身份指向了不同的对象——前者是措辞不一致，后者是指错了人。

推特改名快三年了，站上那份跟着改了吗？

这是一个天然的时间标尺。域名从twitter.com换成x.com是2023年的事，旧域名至今仍然会跳转到新域名，所以“不改也能用”。正因为不改也能用，改不改就完全取决于有没有人去改。

写旧域名的比写新域名的多了将近一倍。品牌名在不同语种、不同平台上有几种写法这件事本身就够麻烦了，跨语言监测品牌提及时最先撞上的就是这类同一实体多种字面的问题；域名换代不过是又给它加了一层。而两种混着写的那5个站——bollandbranch、shopify、soundcore、traeger、vuoriclothing——正是本文主题最直白的样本：同一个账号，在同一个首页上，一处写着旧域名、一处写着新域名。有人改了其中一份，没人负责去改另一份。

这对机器意味着什么？sameAs的作用是把你的站和一个外部实体连起来，让引擎确认“这个品牌就是那个账号的主人”。两条指向同一个账号但域名不同的链接，最好的情况是引擎自己做了归并，差一点的情况是它当成两个实体各记一笔。实体消歧那套信号管控的前提，是你给出的信号本身不打架。

那个@shopify是谁留下的？

twitter:site这个字段规范上要求填@开头的账号名。37个站填了，写法上：

• 规规矩矩写成@账号的35个；
• 没加@直接写账号名的2个（eufy、shopify）；
• 把整条网址塞进去的3个：awaytravel写的是@https://x.com/away，brooklinen和reebok同理。@后面跟一整条https地址，卡片解析器读不出账号。

再把它和另外两份对照：24个站三处都写了推特账号，其中账号真的对不上的有2个。

一个是eufy：twitter:site写eufy，另外两处都是eufyofficial。

另一个是chubbiesshorts，它的twitter:site写的是@shopify——不是它自己的账号，是建站平台的官方账号。这个值来自主题模板的默认设置，从上线那天起就没人填过。分享这个品牌的页面到社交平台，卡片底下署的是平台的名字。

这就是那句老话的又一个版本：缺省值不是空白，缺省值是别人替你做的选择。而它偏偏躲在一个平时没人看的地方。

sameAs数组里为什么会有64条空字符串？

解析ld+json的时候我顺手统计了条目本身的形态，结果比预想的脏：

空字符串（或者只有一个空格）一共64条，散在12个站上，beistravel一家就13条，everlane和wusthof各9条；还写着http开头的13条，来自bigcommerce、harrys、kotn和canyon四个站。

空字符串的来源很好猜：主题给了十几个社交平台的设置项，品牌只填了其中五个，模板照着循环全渲染了出来。剩下的位置就成了一串引号里什么都没有的条目。

这不会导致报错，JSON-LD校验器也不会拦——语法完全合法。它只是在告诉引擎：“我在这些平台上有账号，地址是空的。”

还写着http的那13条更微妙。它们能跳到https，所以人点着没问题。但sameAs比对的是字面地址，harrys那四条全是http开头，包括http://x.com/harrys——一条既用了新域名、又用了旧协议的链接。

同一个页面上三个块各写一份，机器该信哪个？

117个站里有3个站的首页上，不止一个结构化数据块带着sameAs，而且几份内容不一样：

• beistravel：两个Organization块，一个写1条，一个写5条。
• monos：一个Organization块写5条，一个OnlineStore块写2条。
• fahertybrand：三个块，第一个是OnlineStore加Organization写7条，另外两个是Person，分别写4条和1条。

fahertybrand那个最有意思。后两个块是人——大概是创始人或者代言人——他们的sameAs指向的是espn.com和yalebulldogs.com这类地址。同一个页面上有三份sameAs，其中两份根本不是这个品牌的。

严格说这不算错，schema本来就允许描述多个实体。问题在于当两个同类型的块给出不同的清单时（beistravel那两个Organization），没有规则说该信哪个。实体之间的关系完整性之所以比字段完整性更难做，正是因为这一层没有校验器会报错。

这份声明到底挂在什么东西上？

还有一层容易被忽略：sameAs不是随便挂的，它挂在哪个类型上，决定了引擎把这些账号算给谁。62个站一共67个带sameAs的块，类型分布是：

最后两行值得单独看。Person那两块出自同一个站，写的是人的社交账号。而挂在WebSite上的那一块更微妙：网站和运营网站的组织，在结构化数据里是两个不同的东西。把品牌的社交账号挂在WebSite上，语法完全合法，只是它声明的是“这个网站等同于那几个社交主页”，而不是“这家公司拥有那几个账号”。引擎要认的是后者。

这类错误比拼写错误隐蔽得多，因为校验器不会报。页面类型声明那一轮量到过同一种毛病的另一个形态——写了，但写在了错的类型上，等于没写。

这三份副本分别是给谁看的？

把机制说清楚，才知道哪一份出错代价最大。

差别在反馈回路上。这也是AI会推荐出根本不存在的品牌这类事情的土壤之一：机器手里的那份材料没人验收过。页脚那份错了，用户会点、会投诉、客服会转过来；另外两份错了，没有任何人会发现——它们的读者是机器，机器不投诉，只是默默按错的那份理解你。

这也解释了前面那个方向性的发现：页面那份总是最新的，不是因为前端更用心，是因为只有它有人验收。

顺带说一个容易被误解的点。sameAs不是排名因素，把社交账号写全了不会让你排上去，社交信号那笔账该怎么算是另一个话题。sameAs的价值在实体这一层：它是你把散在各平台上的自己声明成同一个主体的方式，用在AI回答“这个品牌是谁”的时候。做实体主页的人都知道这层地基，只是很少有人回头检查地基有没有裂。

最该放进sameAs的那类地址，有几个站放了？

sameAs最初的设计意图，是指向能唯一标识这个实体的权威地址——维基百科条目、维基数据的实体号，这类东西比社交主页更能钉死“你是谁”。

117个站里，往sameAs放了维基百科或维基数据的只有11个：babybjorn、bollandbranch、braun、buckmason、bugaboo、canyon、cybex-online、fahertybrand、on、shopify、zwilling。放了Crunchbase的2个。

这11个站一共给出13条维基类地址，其中10条出自同一家：on.com一口气列了十种语言的维基百科条目，德英西法葡匈之外还有波斯语、印尼语、乌克兰语和中文。剩下10个站各只放了1条。canyon放的是维基数据的实体号Q318730——不过它写成了http开头，而且是从www.wikidata.org那个形式。

做出海品牌的人不妨对着这份名单想一件事：这11个里有7个是欧洲的老牌制造商（babybjorn、braun、bugaboo、canyon、cybex、on、zwilling），另外4个是北美公司。它们的共同点是本来就有维基条目，所以顺手放了进去。而新一代DTC品牌大多没有条目可放，于是sameAs里只剩下社交主页——这恰恰是最容易改名、最容易废弃的一类地址。AI说错你的品牌事实之后怎么纠错那套流水线，源头卡的就是这一步：你能拿出的权威锚点越少，纠错的成本越高。

我的尺子错在哪几处

三次，其中两次改变了结论。

第一条特别值得记：那个错误方向恰好是“更有故事”的方向——“8个站还挂着Google+”比“1个站还挂着Google+”好看得多，也更容易让人信。一把尺子如果总是往有利于结论的方向偏，就该先怀疑尺子。

自己站上怎么查、按什么顺序改

不用工具，浏览器控制台一行就够。打开自己首页，粘这段：

const sa = [...document.querySelectorAll('script[type="application/ld+json"]')]
  .flatMap(s => { try { return JSON.stringify(JSON.parse(s.textContent))
    .match(/"sameAs":\[[^\]]*\]/g) || [] } catch (e) { return [] } });
const link = [...document.querySelectorAll('a[href]')]
  .map(a => a.href)
  .filter(h => /facebook|instagram|twitter\.com|x\.com|youtube|tiktok|pinterest|linkedin/.test(h));
console.log('schema:', sa); console.log('页面:', [...new Set(link)]);
console.log('卡片:', document.querySelector('meta[name="twitter:site"]')?.content);

三份打在一起，肉眼就能看出差在哪。关于我们那一页顺手也查一遍，多数站的社交入口在那儿还有第四份。要批量做多个站，结构化数据审计工具能一次扒清页面上几种格式的字段，省掉写脚本的功夫。

改的顺序，按“错了谁会发现”排：

1. 先把同平台指向两个账号的那几处对齐。这是唯一一类会让机器认错人的错误，优先级最高。定一个主体：哪个是全球主账号，地区号放不放进sameAs，一次定死。
2. 清掉空字符串和http开头的条目。顺手就能做完，而且不做的话后面每次新增都会再复制一遍。
3. 把twitter:site那个默认值找出来。判据很简单：它的值如果不含你的品牌名，八成不是你填的。
4. 推特域名统一成一种写法。用x.com还是twitter.com都行，重要的是全站只有一种，别让引擎去猜两条链接是不是同一个账号。
5. 找出可以当权威锚点的地址补进去。维基数据实体号、行业协会会员页、公司注册信息页，都比多列一个社交主页有用。这一步和页脚署的公司名能不能查到编号是配套的：机器认你，靠的是你给的锚点能不能被独立验证。
6. 最后，把这三处写进同一个地方。能用一份配置渲染出三处，就永远不会漂。做不到的，至少在改版清单里加一行：改社交账号时，这三个位置一起改。

说到底，这一轮和同一天那篇301重定向链上三层各写一份规则是一个题目的两面：那边是给机器看的路径被三层各写了一份，这边是给机器看的身份被三处各写了一份。再往前，政策页那行最后更新日期和Cookie到期日那一轮问的是同一句话的上半段——写下来之后有没有人管。这一轮问的是下半段：一件事被写在三个地方，你改其中一个的时候，另外两个会不会跟着动。答案通常是不会。

常见问题解答

sameAs和页脚社交链接不一致，会被判成作弊吗？

不会。这类不一致在引擎眼里是噪音不是欺骗，它只会降低这些信号的可信度，或者干脆两边都不采信。真正的代价是实体识别变模糊：引擎拿到两个候选账号，得自己猜哪个代表你，猜错了你也收不到任何通知。

sameAs里到底该放几条？

没有硬性数量。实测的中位数是5条。判据不是多少，是每一条能不能独立验证到你身上——一个正在运营的官方账号、一个维基数据实体号，比十条早就不更新的主页有用。宁可少放，别放空字符串和废弃账号。

地区账号要不要写进sameAs？

主体只写一个全球主账号最省事。要写地区号，就在对应语言版本的页面上写对应的那个，别在同一个页面里把全球号和地区号混着给。实测里几个对不上的案例，多半都是页脚被本地化了而结构化数据没有。

twitter:site填的是账号还是网址？

填@开头的账号名，不是网址。本轮有3个站把整条https地址塞进了这个字段，卡片解析器读不出来。另外记得检查它是不是主题的默认值，有个站发出去的是建站平台自己的账号。

推特改名之后，站上的twitter.com要不要全换成x.com？

旧域名仍然会跳转，所以功能上不换也能用。但同一个站里两种写法混着出现，会让引擎多做一次归并判断。选一种，全站统一，比选哪一种更重要。

没有维基百科条目的新品牌，权威锚点从哪儿找？

不必盯着维基。公司注册登记页、行业协会会员名录、交易所或监管机构的公开备案页、专业媒体的品牌档案页，都属于能被独立验证的锚点。挑那些不由你自己控制、别人查得到的。把这件事系统化做一遍，可以对着实体覆盖缺口那套方法排一遍优先级。

这些数据能代表中文站吗？

不能直接代表。样本是海外品牌的独立站，平台构成和社交生态跟国内完全不同——国内站的这三份副本会落在微信、微博、小红书上，字段写法也不一样。但“同一个身份写在三处、只有一处有人验收”这个机制跟地域无关。

权威参考资料