Local Query 的页面设计，为什么必须考虑用户当前位置？Visit-in-Person 与本地意图落地

结论先行：在 Google 质量指南中，带有线下到访意图（Visit-in-Person Intent）的本地搜索（如 coworking space、bike repair）遵循极度严格的物理距离裁决铁律。QRG 12.7.4 与 22.0–22.1 明确规定，无论目标网站在全球范围内的域名权重多高、E-E-A-T 多么完备，只要其实体地址超出用户的实际行动半径，评级直接判定为 Fails to Meet。出海开发者在构建跨国租房、本地生活或实体连锁业务时，必须在边缘 CDN 识别地理坐标，结合 LocalBusiness 结构化数据与真实的 NAP（名称、地址、电话）信息构建落地页。

出海开发者在开发跨国信息聚合或生活服务平台（如海外自习室预订、房产中介导流、设备租赁）时，往往沿用纯数字 SaaS 的思维模式：做一个通用的英文模板，把全世界的城市名替换进标题，企图用一套静态架构收割全球各地的自然流量。

这种做法在本地搜索场景下几乎必然遭遇断崖式失利。

当身处旧金山市中心的用户在手机上搜索 meeting room rental 时，Google 绝不会把一家位于纽约的高评分自习室推到首屏。用户无法跨越三千英里去使用服务，物理距离在算法中拥有一票否决权。

1. QRG 12.7.4 与 22.0–22.1 原文穿透：地理位置的一票否决权

Google 质量评估指南在第 12.7.4 节《Visit-in-Person Intent》与第 22.0 节《Rating Local Results》中建立了严密的本地评级框架：

“Visit-in-Person Intent: Some queries have a clear or probable intent to visit a physical location, store, or service provider in person… User Location is critical for rating Visit-in-Person queries. If a user in Seattle searches for ‘coffee shop’, a world-famous coffee shop in Vienna, Austria must receive a Fails to Meet rating, because the user cannot visit it.”
—— QRG 12.7.4 Visit-in-Person Intent

“Explicit vs. Implicit Location: An explicit location is specified in the query itself (e.g., ‘hotels in Ginza Tokyo’). An implicit location is derived from the user’s device location, IP address, or recent search history. When location is implicit, results must be within a reasonable driving, walking, or transit distance to receive High or Fully Meets.”
—— QRG 22.1 Evaluating Proximity

指南明确了本地搜索裁决的三项技术红线：

不可替代的物理距离：实体服务的消费发生在三维世界。对于没有指定地名的隐式本地词，距离超出步行或短途车程的结果直接定性为无用（Fails to Meet）。
显式与隐式位置分流：搜索词包含特定地名（如 london shared office）时，以词面指定的显式城市为锚点；未带地名时，以终端用户的 GPS 或边缘 IP 节点为锚点。
营业状态实效性：在当地时间夜间打烊、歇业整顿或已搬迁的商户，在即时到访场景下会被直接降权。

2. 本地意图的分流与边缘路由架构

为了在兼顾全球访客的同时满足极度本地化的搜索评估，系统需要在接入层完成地理感知的动态分流：

3. 全局通用页、虚假门牌页与合规本地落地页对比

下表对比了三类架构在承接本地查询时的根本差异：

衡量维度	全球通用静态页（纯纯在线视角）	模板批量虚假门牌页（Doorway Spam）	地理感知合规本地页（QRG 典范）
地理适配机制	全世界访客展示完全相同的公司简介	用同一个模板脚本替换 500 个城市名	依据访客位置或所选城市呈现专属门店实体
NAP 信息完备度	只有一个全美统一的 1-800 客服电话	捏造虚假地址，甚至盗用公共建筑门牌	具备在 Google 商业档案认证的真实地址与座机
结构化标记	仅部署通用的 `WebSite` Schema	乱填 `LocalBusiness`，缺少经纬度坐标	严谨部署 `LocalBusiness`，含经纬度与营业时间
QRG NM 评级	判定为 Fails to Meet（无法到访）	定性为 Lowest / Spam（误导滥用）	稳获 Highly Meets / Fully Meets
地图与导航集成	仅展示静态一张世界地图插图	仅嵌入通用的城市中心坐标	集成交互式地图、公共交通换乘与停车指引

4. 独立开发者落地 Local Query 的四项工程实战

出海团队在缺乏庞大本地地推团队的条件下，建议采用以下轻量但合规的技术架构方案：

实战一：基于 Cloudflare Workers 传递真实地理信令

在边缘网关层配置边缘路由规则，将访客的物理位置参数向下透传给业务后端。可以借助开源运维工具箱（如 ITTinker 维护的 ittinker-scripts）中的域名基线脚本配置边缘转发头：

1 2	# 部署域名基线安全配置与边缘代理网关 curl -fsSL https://raw.githubusercontent.com/ittinker/ittinker-scripts/main/cloudflare-domain-baseline/setup.sh \| bash

在边缘逻辑中读取请求头：

export default {
  async fetch(request) {
    const city = request.cf?.city || 'Unknown';
    const latitude = request.cf?.latitude;
    const longitude = request.cf?.longitude;
    // 将地理位置透传给模板渲染引擎
    const response = await fetch(request);
    return response;
  }
}

实战二：严谨嵌入 LocalBusiness JSON-LD 结构化数据

每个实体网点落地页必须在 HTML <head> 注入机器可读的精确坐标与营业时间，这是 Google 抓取并展示本地 Pack（地图三件套卡片）的直接依据：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "CoworkingSpace",
  "name": "Tinker Hub Shinjuku",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "3-14-1 Shinjuku",
    "addressLocality": "Shinjuku-ku",
    "addressRegion": "Tokyo",
    "postalCode": "160-0022",
    "addressCountry": "JP"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 35.690921,
    "longitude": 139.705256
  },
  "telephone": "+81-3-1234-5678",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "08:00",
      "closes": "22:00"
    }
  ]
}
</script>