本地搜索是最难精确追踪的东西,原因在于结果集变化的粒度比大多数追踪系统能够表达的更细。同一座城市两端的两个用户看到的地图包不同。某个郊区的一次查询会让某家商户上榜,而三英里外则完全看不到它。追踪工具报告的却是一个数字,而这个数字对几乎所有人来说都是错的。
如果你在开发本地SEO软件,那么你产品的准确性上限就取决于你能多精确地指定搜索发生的位置。以下是这实际涉及的内容。
位置不是一个参数
首先要弄清楚的是,告诉搜索引擎你在哪里有两种不同的机制,它们产生的结果并不相同。
请求来自哪里,即IP地址及其地理定位。这是环境信号,也是真实用户的位置在引擎看来的样子。
你声明自己在哪里,即搜索界面或API接受的一个明确的位置参数。这是一种声明的偏好,而不是一种推断。
真实用户会持续产生这两种信号,因为他们确实身处那个地方。追踪系统往往只产生第二种信号,来自别处某个数据中心的IP,而结果也反映出这种不匹配:你得到的结果比全国平均值更接近所请求的区域,但并非当地居民所看到的结果,而这种差异恰恰集中在你试图测量的本地包结果上。
准确的本地追踪需要这两者相互一致,这就是为什么采集层和位置参数不是独立的选择。相关的基础论述见本地化的Google搜索结果。
粒度阶梯
本地结果会在多个层级上响应位置变化,你的追踪工具应该明确说明它声称的是哪个层级。
国家层级对全国性关键词已经足够,但对本地意图查询毫无用处。
地区或州层级对受监管的类别和区域性连锁企业很重要,而且往往是追踪工具能做到的最细程度。
城市是大多数本地SEO产品所使用的层级,对许多查询来说是够用的,但对客户最关心的那些查询来说并不够,因为就基于距离的排名而言,一座城市并不是单一的地点。
邮政编码或区域是本地包追踪真正开始具有代表性的层级,因为它近似于一个社区,而不是一整个都市区。
坐标是最细的层级,对于比较相距几英里的多个分店表现的多地点经营企业来说很重要,而在这种情况下,城市级别的数字会把你所出售的整个信号平均掉。
给产品的实用建议是:让客户按照自己业务所处的粒度来指定位置,并在界面上明确说明你测量的到底是什么。一个不加限定条件、只报”纽约”的排名,是一个无法复现的数字,而可复现性正是当客户对报告提出异议时,报告能否站得住脚的关键。关于更细粒度定位的一般性论述见城市级定位何时重要。
距离改变了排名的意义
本地包结果受到搜索者与商户之间距离的强烈影响,这带来了两个后果,而大多数追踪产品处理得都不好。
首先,如果不附带位置信息,一个本地关键词的单一排名几乎没有意义。同一家商户可能在其门店附近的本地包中排名第一,而在两个郊区之外则完全不出现,这两者都是真实的。那些每个关键词只报告一个数字的产品,报告的其实只是他们追踪运行地点的偶然结果。
其次,更有用的呈现方式是网格而不是数字:在服务区域内的一个点阵上对同一个查询进行采样,你就能得到一张覆盖地图,显示商户实际出现的地方。这比单一排名要好得多,但它只有在你的采集层支持细粒度位置的情况下才能实现。
成本影响是真实存在的,因为网格会把检查量按点数倍增,这使得单次检查的成本成为决定你能提供多密网格的关键数字。相关的算法在规划请求量与并发数中有说明。
设备在这里比在其他任何地方都更重要
本地搜索在很大程度上偏向移动端,因为这类查询往往是在移动中进行的,而移动端的本地结果在布局上、地图包的显著程度上,有时在构成上都与桌面端不同。
对于本地SEO追踪而言,移动端应该是默认选项而不是一个可选项,如果你两者都追踪,应该分别呈现而不是把它们混合成一个数字。混合会产生一个既不描述任何一种体验的数字。
顺带把设备声明与其他一切保持一致:移动端的用户代理配上桌面端形态的请求是一种矛盾,各种信号应该保持一致,参见设置正确的请求头和匹配地理位置、时区和语言环境。
验证你的地理定位是否真实
这部分很值得纳入你自己的测试套件,因为地理定位的失败往往是无声的。
**检查出口位置是否与请求相符。**这是必要但不充分的条件,因为地理定位数据库和目标本身的判断可能会有分歧。
**检查结果的本地行为是否正确。**发起一个具有明确本地意图的查询,确认返回的商户确实位于该区域。这才是真正的测试,它能捕捉到这样一种情况:某个地址的地理定位本身是正确的,但引擎却把你安置到了别处。
**按你所出售的粒度逐一检查。**如果你提供邮政编码级别的定位,要验证两个相邻的邮政编码在应该不同的地方确实返回不同的本地包。如果它们到处都返回相同的结果,那么你的精细定位其实什么都没做,你的产品在悄悄出售它并不具备的精确度。
**留意静默回退。**当某个非常狭小的位置在当时没有覆盖时,系统可能会回退到更大的区域,却仍然返回一个结果。这对可用性而言通常是正确的做法,但对于一个地理敏感型产品来说却是错误的做法,因为一个针对错误地点给出的看似合理的答案,比直接报错更糟糕。要清楚你得到的是哪种行为,并在数据中把它体现出来。
跨时段采样,因为特定小区域的可用性会随一天中的时段变化,参见国家可用性。
自建还是购买地理层
采集方面的问题与本类目中其他地方相同。自己运行意味着需要具备国家和城市定位能力的住宅出口,以及随之而来的解析和节奏控制方面的维护工作。购买则意味着使用一个接受位置作为参数并返回已解析结果的SERP API,这样你的工程投入就能放在网格可视化和分析上,而不是放在抓取本身上。
无论哪种方式,准确度的上限都取决于位置能被指定得多精确,以及请求能多真实地代表身处该地的一个人。这是选择时最应该重点评估的部分,而评估方式就是把上面这份验证清单套用到你自己的服务区域上,而不是套用到某个供应商的示例上。
结论
本地追踪的准确性受位置精度所限,而大多数产品都在同一个环节上失分:声明一个位置,却从别的地方发出请求,导致环境信号与声明信号相互矛盾。要明确说明你测量的粒度,从国家一直细化到坐标,并让客户选择其业务实际运作的那个层级。把一个本地关键词的单一排名视为不完整的信息,除非附带位置,并考虑改用网格,同时为其所隐含的检查量倍增做好预算。对本地查询默认使用移动端,永远不要把不同设备混合成一个数字。然后要持续验证,不仅要验证出口位置是否与你所请求的相符,还要验证结果是否真正是本地的,相邻的细粒度位置在应该不同的地方是否确实不同,以及是否存在静默回退,用针对错误地点的看似合理的答案来填补空缺。
如果你想要地理问题已被处理好的解析结果,位置层可以是SERP API;如果你想自己构建采集流程,也可以使用具备国家和城市定位能力的住宅代理,按每GB计费,这样网格密度就仍然是一个产品决策。