门店页结构化数据实测49页：地址电话齐了，说清是哪家店的一个都没有

摘要：从131个海外品牌的站点地图里筛出门店类网址，取回84个页面，剔掉商品页和专题页之后剩49个真正的门店详情页，来自11个站。带门店类结构化数据的24个，占49.0%，而且全部出自5个站。地址和名字在这24个页面里覆盖率100%，坐标和电话95.8%，可是能让机器把这一页和现实里那家店对上的字段——@id占25%、sameAs占20.8%——追下去发现几乎全部来自同一个站。谷歌地图自己的地点标识，49个页面里一个都没出现。另外21个门店查找入口页，写了门店类结构化数据的是0个。

这个月有一份逆向工程材料被公开，里面是谷歌存放地理实体的那套内部结构。看材料的时候我盯住的不是那张信号清单，而是一句很轻的话：你在商家资料后台编辑的那一栏，不一定就是谷歌内部维护的那个值。它把一件很多人做了很多年的事重新定义了一遍——你填进去的东西，不是一条记录，是一条证据。它要和几百个别的来源写下的同一件事放在一起，按一套没公开的规则被裁决，赢的那一条才是谷歌眼里的事实。

那么门店页在这套裁决里到底扮演什么角色？这件事能自己测。下面这一趟实测就是照着这个问题设计的。

你在商家资料里改的那一栏，谷歌到底存进哪儿了？

先把对象搞清楚。地图上那张卡片，专业一点说叫列表；谷歌内部存的那个东西叫特征对象，一家店、一栋楼、一条路、一个城市、一个交通站点，甚至一个三维模型，在那套结构里都是同一种对象的不同种类。

对一家实体店来说，这个对象里可以装身份、几何形状、来源信息、网址、连锁关系、知识图谱引用、概念标签，还有排序信息。地图上那张卡片是后面才组装出来的。换句话说，卡片是界面，对象在界面底下，而你能编辑的只有界面那一层。

这个区分不是文字游戏。它解释了本地SEO里一类很常见又很难对付的症状：某个字段改完过几天又变回去、某条错误的属性怎么都赶不走、两个重复条目合了又分。如果你把后台当成数据库，这些症状全是说不通的故障；如果你把后台当成一个投证据的窗口，这些症状全是正常结果——只不过你那一票没赢。

谷歌怎么划一家店的实体边界那篇讲过资格和排名是两道不同的门，本篇要接着往下挖一层：在过资格这道门之前，还有一道没人提过的手续，就是让谷歌先确认“这一页说的是哪一个对象”。

一家店的名字、电话、坐标，为什么会有几百个来源同时在说？

那份材料里暴露出来的来源数量是793个。这个数字第一次看会觉得夸张，想一遍就合理了：店名可能来自一个来源，电话来自另一个，分类来自第三个，坐标干脆来自完全不相干的第四个。政府登记、地图测绘、第三方目录、行业协会、用户上报、商家自己填——每一路都在描述同一家店。

几路说法不一致的时候，那套结构里有一套通用机制去处理：可以只挑一个值，可以把几个值合起来，也可以组合出一个新的。挑哪一个，靠来源的信任等级——材料里的等级从被屏蔽、不受信任，一直排到受信任、超级受信任。

这张表里最值得盯的是第二行。你交上去的字段不是覆盖，是参与竞争。而竞争里最要紧的一件事不是你写得多准，是系统能不能确认你写的这一条和别人写的那一条说的是同一个对象。认不出来，你的证据不是输了，是根本没进这一轮。

谷歌凭什么知道你这个门店页说的是哪一家店？

材料里有一层叫做网页引用关联的东西，专门把网页文档和实体挂在一起，挂的时候还存了几样属性：这篇文档在多大程度上是关于这个实体的、这份关联有多少置信度、地理元数据、文档级的分数。更有意思的是，同一个实体的不同文档之间还有一个相对排序信号，并且会区分这篇是作者页、发布方页，还是参考页。

把这层信息翻译成人话：你的门店页除了参加“上海某某路某某店”这类查询的排名，还在同时干另一件事——给那个地理实体当证据。它排第几是一件事，它算不算这个实体的可靠参考页是另一件事。

而要当证据，第一步是被认出来。谷歌那边靠机器标识把文档和实体对齐，你这边能给出的对应物只有三样：结构化数据里的@id、sameAs，以及指向地图的hasMap。这三样写没写，就是本次实测的靶心。

它认的是概念，不是你选的那个分类

顺着那份材料再往语义那一层走，还有一个东西值得单独说：谷歌用的是一套共享的概念词汇，能描述业态、菜品、属性、菜系、服务方式等等，范围远远超出商家资料里那个主分类。材料里恢复出来的本地搜索意图类型有446种。

材料作者拿一个拉面查询跟着走了几段，结果页里出现的并不都属于同一个分类：拉面店、日本料理、亚洲餐厅还有别的相关概念被连在了一起。更往里一层，评论主题和菜单菜品也能被存成实体而不是纯字符串。

这对填资料的人意味着什么？主分类仍然要选准，但它不是唯一入口。你在页面正文、属性、评论里反复出现的那些具体说法，同样在给概念层喂料。用属性共现把模糊的品牌喂成能被认清的实体那篇讲的就是这套打法，本地场景里的抓手比品牌场景更具体：菜名、服务方式、能不能停车，都是概念，都能被单独指认。

49个门店详情页实测，机器读得出的有多少？

取样办法说清楚，好让人能复现。131个海外消费品牌的站点地图前些天已经抓在本地，一共348325条网址。从里面按路径关键词筛出门店类地址，按路径深度分层抽样，得到95条，实际取回84个页面。

接着做一次人工分档：路径像/store/rings/…这种其实是商品页，/livestation/store/…是直播专题页，这两类12条剔掉。剩下的分成门店详情页49条（11个站）和门店查找入口页21条（13个站），另有2条归不进去。下面所有比例都只在这49条里算。

第一行的49.0%已经比我预期的低。更要紧的是那24个页面的分布：它们全部来自5个站，另外6个站的门店详情页一条门店类标记都没有。这不是“大家都做了一半”，这是“做的人做全了，不做的人一点没做”，两种局面要吃的药完全不一样。

做到的那5个站和没做的6个站

做到的是allbirds、bolia、rituals、vuoriclothing、fjallraven。没做的是awaytravel、kotn、lookfantastic、mejuri、on、sulwhasoo。有意思的是，没做标记的那几个站，门店页做得并不粗糙：mejuri、kotn、on这三家的页面上都有指向地图的链接，地址也印得整整齐齐，只是这些东西全写在给人看的那一层。

站内做过一轮页面类型声明的全站实测，结论是产品页大家都写、类目页只有三分之一。门店页这一次的位置比类目页更靠后：它不是写得少，是写的人少。

地址电话都写齐了，为什么还是没把话说清？

把那24个带门店节点的页面拆开看字段，会看到一条很干净的分界线。

上面六行讲的是这家店的属性，下面三行讲的是这家店的身份。属性那一半几乎满分，身份那一半四分之一都不到。

再往下追一步，事情更极端。@id那6个页面里5个来自vuoriclothing，1个来自fjallraven；sameAs那5个页面全部来自vuoriclothing。也就是说，11个品牌里，只有1个给自己的门店写了能跨系统对齐的标识。这个比例和那6个字段的90%以上，不在一个量级上。

电话这一项我另外做了个交叉核对：结构化数据里写了电话、可见文本里也印了电话的页面有23个，两处对得上的22个。这一项做得相当好，说明这些站并不是随手糊的——他们认真填了自己理解的那部分，只是没人告诉他们还有身份这一栏。

那个指向谷歌地图的链接，机器能从里面读到什么？

65.3%的详情页放了指向地图的链接，这个比例看着挺高，容易让人以为身份这件事已经被链接解决了。实际没解决。

我顺手数了另一个指标：页面里出现地图地点标识（也就是那串地点编号或者数字型的客户标识）的页面，49个里是0个。所有地图链接都是搜索式或者坐标式的，点过去能落到大致位置，但那条链接本身不携带“这一条就是地图上那一个对象”的断言。

差别在哪？一条搜索式的地图链接说的是“拿这个名字和地址去地图上找找”，它把消歧这件事推给了对方；一个写在sameAs里的稳定标识说的是“就是它”，消歧在你这边已经做完了。前者对人来说完全够用，对机器来说是一道还没做的题。站内实体消歧机制的信号面那篇把这件事的信号面铺开讲过，本篇给的是它在门店这个场景里最省力的一个落点。

门店查找入口页为什么一个都没写结构化数据？

另外那21个页面是门店查找入口，来自13个站。带门店类结构化数据的是0个，一个都没有。

这个结果我反而觉得情有可原。入口页多半是个地图控件加一个搜索框，门店数据靠脚本按需拉，页面源码里本来就没有门店。问题是很多品牌只有入口页没有详情页，门店信息全在控件里。那种站在本篇这套测量里连样本都进不来——它对机器而言等于没有门店页。

哪些查询值得单开一个地点页那篇给过一套判据。可以把本篇的结果当成它的补充：单开了页面但没写身份，和没单开页面，在机器那边的差距比想象中小。

连锁品牌还要多一层麻烦。连锁多门店照抄模板为什么翻车那篇拆过一遍成因，本篇的数据给它加了一个新的解释角度——复制模板的时候，属性字段跟着复制没问题，身份字段是逐店唯一的，一复制就废了。这也解释了为什么那5个做到的站里，@id和sameAs的覆盖偏偏最低。

这和商品页那次找不到主节点，是同一个毛病吗？

不是。这一点必须说清楚，否则两篇会读成一篇。

商品页里找不到主节点那次实测，量的是页内指认：一页的结构化数据里挂了十几个节点，哪一个才是这一页的主角，有一半的页面回答不了。那是页面内部的秩序问题。

本篇量的是页外指认：这一页的主角，在页面之外那个世界里是哪一个对象。哪怕主节点写得清清楚楚，只要没有稳定标识，它在地图那套结构里仍然是一条无法归位的证据。两件事都会导致“指到的不是你以为的那个”，但断在两头。

顺着这条线还能把另外几篇串起来：实体之间的关系没人审这一层讲的是节点之间的关系有没有审过，专门给机器配一份实体声明文件讨论的是这条路要不要走，关于我们那一页怎么把身份立住讲的是品牌这一层的身份怎么落地。本篇是这条线在门店这个最具体的场景里的一次落点测量。

本地排名官方只给三条，恢复出来的却有72条，该信哪个？

这里要插一段克制的话，因为那份材料里最容易被误用的就是那张信号清单。

官方帮助中心那篇本地排名提升建议，从头到尾只给三个决定因素：相关性、距离、显著性。顺手说一句，这一页自己都不太一致——概括那句话里用的词是知名度，下面小标题用的是显著性，读的时候容易以为是两件事。

逆向材料那边恢复出来的是72个信号名，其中25个明确标着已废弃。这里有两个陷阱。第一个是权重：材料作者自己说清了，恢复出来的是名字，不是系数。第二个是位置：那72个信号打的是实体本身的重要性分，用户的一次查询还要再过查询理解、语义匹配、候选生成、地理与质量、重排这几道；另外还有一个完全离线跑在设备上的打分器，8个信号13个档，和服务端那两套都不是一回事。

四份清单，一份带权重的都没有。所以那72条不能当成72项待办。能当待办的只有一类东西：判据明确、自己能做完、做完能被机器验证的。门店页的身份字段正好是这一类，这也是我把实测放在这里而不是放在那张清单上的原因。

还有一条地理上的发现，值得顺带纠一个常见的心理模型。那份材料的作者直接测了地理这一层：同一个出发点，查询词换成密度高的品类词，搜索范围明显收窄；换成品牌词，范围放得很开；同一个品类词换到人口稀疏的地方，范围又扩得很大。他们还把地理权重整个摘掉重跑了一遍，5083次调用、86584条结果，中位距离从6.87公里跳到4000公里以上，而非地理那部分的顺序几乎没动。

这说明地理不是在既有名单上按距离重排一遍，它在更早的地方决定了谁被拿进候选。“我离得近所以该排前面”这个模型不算错，但它漏掉了更要命的那一半：离得远的时候，你可能根本没进那一轮。

门店页要改成什么样，才算把证据递到了该去的地方？

按本篇的数据，多数站要补的不是内容，是四行字。

字段怎么写，本地商家结构化数据文档和词汇表里的LocalBusiness类型都有明确定义，sameAs这个属性的语义也写得很直白。谷歌那份建立商家信息的指引还提醒了一件容易忽略的事：网页上的商家信息和商家资料里的信息要能互相印证，这句话放在证据这个框架里读，意思就清楚多了。

还有一步在清单之外，但官方把它排在第一条：先把商家认证做掉。官方那篇建议里写得很直接，认证是在告诉谷歌你有资格代表这家店，没认证的条目更难出现在结果里。放在证据这个框架里，认证不是一个手续，它是给你这条来源提信任等级——而信任等级正好是冲突消解那一步用来挑值的依据。

同样要提前想清楚的是数据从哪来。把商家资料的电话、路线、点击和网站行为放在一起看这件事已经能做了，而后台管理被搬进对话式工具之后，批量改字段比以前顺手。顺手也带来新风险：字段能一键批量改，身份字段偏偏不能批量填成同一个值。

按站盘一遍的顺序

我自己排的顺序是这样：先确认门店详情页是否存在于站点地图里，不在的先补；再看源码里有没有门店类节点，没有的先加属性字段；已经有属性字段的，补身份三件套；最后才是把可见文本和结构化数据对一遍，别让两处写的电话和地址打架。

最后这一步别跳过。本篇实测里电话的一致率是23个页面里22个，看着很好，但那是在已经写了结构化数据的站里测的。反过来说，一个站要是连结构化数据都没写，这道核对根本没有对象。用结构化数据的语法校验那类校验工具先确保语法过关，再用把五种格式的字段缺漏一次扒清那种抽取工具把全站的字段缺漏扒一遍，这两步加起来比人工翻页快得多。

保哥手上一个澳洲宠物用品连锁的项目正好撞上过这件事。12家门店都有独立页面，地址电话营业时间一个不缺，可几家分店在地图上长期和一家已经关门的旧店混在一起，后台改了三轮都会回滚。后来的处理不是继续改后台，是把12个页面的身份字段补齐：每页一个唯一的@id，sameAs指向该店的地图稳定链接和两个本地目录条目，hasMap逐店对应。混淆没有当天消失，但从那之后回滚不再发生了。机制上说得通——多了一条能被认出归属的证据，裁决的时候你终于有票了。

哪些事本篇没测，别顺着推

三件事要说明白。第一，本篇只测了源码里的结构化数据，脚本渲染之后才注入的那部分没测，所以49.0%这个数应该理解为源码层的下限。第二，样本是131个海外消费品牌，它们大多以线上销售为主，线下门店是补充，结论不能直接搬给以门店为主业的餐饮、医疗、零售连锁。第三，探测各站门店查找路径这件事，我的尺子中途歪过一次，下一节单独说。

这把尺子第一趟量错了，差15个百分点

为了看门店查找页到底普及到什么程度，我给131个站逐个试了5条常见路径。第一趟开了12个并发，结果49个站一路返回429，也就是请求太密被挡。那一趟算出来的结论是：有门店查找页的站40个，占131个的30.5%。

这个数是假的。第二趟我把并发降到1，每条路径之间停1到2秒重跑那49个站，其中11个站当场翻了过来——它们本来有门店查找页，只是第一趟根本没让我看见。最后被彻底拦住的只剩20个站，占15.3%。在111个给出有效回答的站里，有门店查找路径的51个，占45.9%；文案确实是门店查找页的35个，占31.5%。

30.5%和45.9%，差的不是样本，是探测节奏。这类错误最阴的地方在于它不报错：429是一个正常的响应码，脚本会老老实实记下来，然后把“被挡住”和“没有这个页面”算进同一个分母。写进结论之前得先问一句，这一批零值里有多少其实是我自己制造的。

顺带一个小发现：那111个站里，门店查找入口页源码里带门店类结构化数据的只有2个，vuoriclothing又是其中之一。这个站在本篇几乎每一项身份指标上都是唯一的那个，它显然是有人专门管过这件事。

顺着这套逻辑往AI那一侧看，还有一层。在地图里排第一却在AI推荐里查无此人那篇讲的是两套系统的口味差异，AI概览正在接管本地搜索那篇讲的是入口的迁移。身份字段在那一侧的作用会更明显：AI答案要把一句话归给一个具体的对象，认不出归属的证据比在传统排名里更不好用。评论关键词与后台活跃度那套配方是内容侧的打法，配上身份字段才算完整。

常见问题解答

门店页写了地址和电话，为什么还说没把身份说清？

地址和电话是属性，回答的是这家店什么样。身份回答的是这一页说的是哪一个对象。谷歌内部用机器标识把文档和实体挂在一起，你这边的对应物是@id、sameAs、hasMap。本篇实测里属性字段覆盖率90%以上，身份字段不到四分之一，缺的就是这一半。

页面上已经有指向谷歌地图的链接，还需要sameAs吗？

需要。65.3%的门店详情页有地图链接，但绝大多数是搜索式或坐标式的，它把消歧推给了对方。写进sameAs的稳定标识是一次明确断言，消歧在你这边就做完了。两者不冲突，一个给人点，一个给机器读。

逆向出来的那72个信号，能不能当成本地SEO的待办清单？

不能。材料作者自己说了恢复出来的是名字不是系数，而且那72条只给实体本身打重要性分，用户查询还要另外过好几道系统，设备上还有一个独立的离线打分器。官方帮助中心给的决定因素只有三条。四份清单没有一份带权重，把名字当配方用就会把力气花错地方。

连锁多门店怎么批量补身份字段又不搞错？

把字段分成两类。属性类可以模板化，营业时间、价位、图片都能按门店数据批量生成。身份类必须逐店唯一：@id用该店固定网址加锚点，sameAs和hasMap逐店取值。最常见的事故是整站门店共用一个@id，那等于告诉机器这几十家店是同一个对象。

只有门店查找入口页、没有单店页面，要不要补页面？

先判断值不值得。本篇实测的21个入口页里，写了门店类结构化数据的是0个，原因是门店数据靠脚本按需拉，源码里本来就没有。所以只有入口页的站，在机器那边接近于没有门店页。要不要单开页面，得看那些查询的搜索量和差异度，有专门的判据可以套，不是一律都建。

改完之后怎么确认机器真的认了？

分三层看。语法层用结构化数据校验工具，确保没有尾逗号之类的低级错误；字段层把全站门店页抽一遍，确认身份三件套逐店唯一且取值有效；效果层别指望立刻，冲突消解是一个持续过程，观察窗口按月算。稳定的迹象通常是后台改动不再被回滚。

概念词汇这一层，除了选对主分类还能做什么？

能做的比想象中多。那份材料里恢复出来的本地搜索意图类型有446种，谷歌用的是一套跨业态的概念词汇，评论主题和菜单菜品都能被存成实体。所以页面正文、属性勾选、评论里反复出现的具体说法——菜名、服务方式、能不能停车——都在给概念层喂料，不是只有主分类那一栏算数。

权威参考资料