适用读者：连锁品牌技术负责人、多门店 SaaS 平台后端工程师、负责本地获客的运营技术团队

七月底接了一个 43 家门店的连锁轻食品牌的技术评审，他们想在 12 个城市做"城市 + 品类"组合落地页，预算给的是"页面越多越好，先铺一千张"。评审会上我把话按住了：组合页这个玩法，铺量阶段最容易踩的就是内容同质化——同一个模板换个城市名，一千张页面就是一千张近重复内容，生成式引擎的相似度去重一刀下去，留三张、废九百九十七张，抓取预算还搭进去。正确的路子是架构上先解决"每张页面的独立信息从哪来"，再谈数量。

这篇文章给出一套完整的多城市落地页架构：数据模型怎么设计、页面怎么按"门店实体"而非"关键词组合"来生成、LocalBusiness Schema 怎么批量输出且和地图平台口径一致，以及上线六周后的抓取与引用数据。方案用 ASP.NET Core 实现，数据库层的设计思路不限技术栈。

需求侧的账：为什么不是铺一千张页

先把商业诉求翻译成技术约束。连锁品牌的本地获客路径是"AI 引擎回答本地问题 → 引用品牌门店页 → 到店"。引擎在回答"XX 城市哪里吃轻食"这类问题时，召回的候选单元是门店（有地址、营业时间、评价的实体），不是关键词页面。所以页面的最小信息单元应该是门店，而不是"城市 × 品类"这种搜索词组合。

表格里最关键的是最后一行：生成式引擎的本地问答走的是实体识别与地理聚类管线，一个拥有完整 LocalBusiness 信息的门店页，天然就是这条管线要消费的原子数据。顺着管线做事，别逆着。

原理剖析：引擎怎么消费本地实体信息

本地实体的引用链路比普通页面多两个环节，先看全景：

flowchart LR
    A[门店页 HTML + LocalBusiness Schema] --> B[实体抽取<br/>名称/地址/时段/品类]
    B --> C[口径比对<br/>站内 vs 地图平台 vs 点评平台]
    C -- 一致 --> D[实体可信度加权]
    C -- 冲突 --> E[降权或丢弃]
    D --> F[地理索引<br/>城市/商圈聚类]
    F --> G[本地问题检索<br/>XX 城市吃轻食]
    G --> H[引用候选排序<br/>可信度 × 距离 × 评价信号]

第二环节的口径比对是本地场景独有的：引擎会拿你站内声明的信息去和地图平台、点评平台的公开数据交叉验证。营业时间、电话、地址三要素只要有一处对不上，实体可信度就打折，多次冲突直接进"信息不可靠"名单。我们上一篇文章写过门店信息三方一致性审计的方法论，这里的架构设计从源头保证一致性——数据只有一个真源，页面和 Schema 都从这个真源派生。

第三环节的地理索引值得多说一句。引擎把门店挂到城市和商圈两级聚类上，依据除了地址本身，还有页面里的地理语境信号：商圈名、 nearby 地标、交通描述。这就是为什么门店页要有一段"到店指引"正文——它不只是给用户看的，也是给地理聚类提供语境证据的。

架构设计：单真源门店数据的四层管线

整体架构分四层，职责划得很清楚：

flowchart TD
    subgraph L1[数据真源层]
        A[(stores 主表<br/>一店一行)] --> B[(store_hours /<br/>store_amenities 子表)]
    end
    subgraph L2[校验层]
        B --> C[三方口径比对作业<br/>每日定时跑]
    end
    subgraph L3[输出层]
        A --> D[Razor 页面模板<br/>门店详情页]
        A --> E[LocalBusiness JSON-LD<br/>批量生成器]
        A --> F[sitemap 分片<br/>按城市切]
    end
    subgraph L4[发布层]
        D --> G[CDN 缓存<br/>长 TTL + 主动失效]
        E --> G
        F --> G
    end

数据模型：一店一行，周边信息放子表

门店主表只存引擎交叉验证最敏感的三要素加身份信息，差异化内容放子表，避免主表膨胀：

-- 环境：MySQL 8.0，InnoDB
-- 设计要点：三要素字段加 NOT NULL 约束，
-- 保证"无完整信息的门店不允许上线"这条业务规则落在库层
CREATE TABLE stores (
    id            BIGINT PRIMARY KEY AUTO_INCREMENT,
    brand_id      INT          NOT NULL,             -- 归属品牌
    store_name    VARCHAR(64)  NOT NULL,             -- 门店名，含城市前缀
    city_code     VARCHAR(12)  NOT NULL,             -- 城市行政区划码，地理索引依据
    biz_area      VARCHAR(32)  NOT NULL,             -- 商圈名，地理语境信号
    address       VARCHAR(128) NOT NULL,             -- 地址：与地图平台逐字一致
    phone         VARCHAR(20)  NOT NULL,             -- 电话：与地图平台一致
    open_hours    JSON         NOT NULL,             -- 营业时间，结构化存储按天分键
    latitude      DECIMAL(9,6) NOT NULL,             -- 精度到 1e-6 度，约 0.1 米
    longitude     DECIMAL(9,6) NOT NULL,
    sync_status   TINYINT      NOT NULL DEFAULT 0,   -- 0 待校验 1 已对齐 2 冲突
    is_published  TINYINT      NOT NULL DEFAULT 0,   -- 校验通过才允许置 1
    updated_at    DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP
        ON UPDATE CURRENT_TIMESTAMP,
    KEY idx_city_status (city_code, is_published),  -- 按城市拉店列表的高频查询
    KEY idx_sync (sync_status, updated_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

sync_status 是这套设计的枢纽字段：每日定时作业拿站内数据去和地图平台开放接口比对，结果写回这个字段，只有状态为 1 的门店才在发布侧可见。冲突门店先挂起修复，宁可少一张页面，不上一份口径分裂的信息。

Schema 批量生成：LocalBusiness 按店输出

43 家门店的 JSON-LD 不手写，用一个生成器从主表批量产出，营业时间数组直接映射到 openingHoursSpecification：

// 环境：.NET 8 / ASP.NET Core，批量生成器为后台任务调用
// 依赖：System.Text.Json（内置）、MySqlConnector 2.3.5
public async Task GenerateAllLocalBusinessAsync()
{
    var stores = await _repo.GetPublishedStoresAsync(); // 只取 sync_status=1 的店

    foreach (var s in stores)
    {
        var ld = new
        {
            _context = "https://schema.org",
            _type = "Restaurant",                     // 轻食品类用 Restaurant 子类型
            _id = $"https://www.example.com/stores/{s.Slug}#store", // 门店实体锚点
            name = s.StoreName,
            address = new                             // PostalAddress 结构化拆分
            {
                _type = "PostalAddress",
                streetAddress = s.Address,
                addressLocality = s.CityName,
                addressCountry = "CN"
            },
            geo = new { _type = "GeoCoordinates",
                        _latitude = s.Latitude, _longitude = s.Longitude },
            telephone = s.Phone,
            openingHoursSpecification = ParseHours(s.OpenHoursJson), // JSON 按天转区间
            servesCuisine = "轻食沙拉",               // 品类标签，参与语义聚类
            priceRange = "¥¥"                         // 人均档位，本地问答高频字段
        };
        await _renderer.WriteJsonLdAsync(s.Slug, ld); // 写入对应门店页 head
    }
}

生成器有两个纪律：_id 锚点全站唯一且 URL 稳定，这个锚点是品牌 Organization 实体到门店实体的挂接点，换了 URL 实体图谱就断线；priceRange 和 servesCuisine 这类字段每家店要有真实差异，别全局写死一个值，写死的字段对引擎是噪音。

组合页放哪：作为门店页的聚合视图

"城市 + 品类"的诉求没有丢，但实现方式变了：城市页以门店页聚合的形式存在，内容主体是"该城市所有门店的真实信息汇总 + 城市级导语"，页面里每家门店链接到门店详情页。城市页相当于 ListPage，门店页是 ItemPage，两级页面的信息互补而不是重复——城市页不复制门店页正文，只做导航和城市级信息（商圈分布、地铁指引）。这样组合页有存在的合理性，又没有近重复风险。

sitemap 与缓存：发布侧的两个配套件

sitemap 按城市分片生成（每城市一个文件），门店页变更时只刷新对应城市分片的 lastmod，避免整份 sitemap 时间戳混淆让引擎误判全站更新。门店页 HTML 走 CDN 缓存，TTL 给到 24 小时，门店信息变更时由发布事件主动刷新对应页面缓存——本地门店页的内容变更频率本来就不高，长缓存对抓取体验没有伤害，还把源站压力压到了地板。

这套发布侧机制上线后有个观察：门店页的首抓延迟稳定在"发布后 4 小时内"，比之前站点地图全站混排时的 1-2 天明显缩短。分片这个动作工作量极小，收益却实在，属于低成本高回报的标配项。

上线六周的数据：抓取、收录与引用

方案六月底上线，43 张门店页加 12 张城市页，六周观察数据如下：

引用质量问题集中在第九次引用前后：有用户拿着 AI 回答里"XX 店周末营业到晚上十点"来问门店，实际周日只开到九点——那次是门店子表改了周末时段，但地图平台侧更新晚了两天，撞上引擎恰好在窗口期内重新抓取。这次事故让校验作业从"每日跑"改成了"门店信息变更后 2 小时内增量跑"，一致性窗口从 24 小时压到 2 小时。本地场景里，口径一致不是一次性对齐，是一个持续的过程指标。

三个设计决策的复盘

复盘之外，记录一条评审会上被否掉又验证了必要性的设计：门店页要不要放评价内容。品牌方最初希望门店页展示精选好评，我们建议第一版不放——评价数据在点评平台的口径和站内很难逐字一致，而评价文本属于引擎交叉验证范围，站内出现与平台侧不一致的评价摘录，等于自己往一致性里掺沙子。六周跑下来，不放评价的门店页引用表现没有受损，LocalBusiness 的核心字段才是本地召回的主信号，评价信号交给平台侧承担即可。这个取舍后续等品牌能拿到评价数据的同步授权再议。

回头看，这套架构里三个决策最值得复盘。第一是"门店实体页优先于关键词组合页"，它把页面数量从一千压到五十五，换来的是零近重复风险和 Schema 原生匹配，从数据看这个交换是值的。第二是 sync_status 枢纽字段，它把"信息一致性"从事后排查变成发布前门槛，三次口径冲突全部在上线前拦截。第三是城市页做聚合视图而不是独立内容页，避免了组合页路线的必然结局——同质化内容被批量去重。

一个遗留问题：门店页的差异化正文目前靠运营每店手写两百字，新店接入的成本还不低。下一步计划用品牌素材库加人工审核的半自动方式压缩撰写成本，但生成内容必须过人工这道闸，这个原则不松。

架构图和表结构是完整的，Schema 生成器代码可以直接复用到其他连锁场景（教培门店、宠物服务、美业都一个套路）。你们的连锁站现在一店一页了吗？评论区聊聊各家的信息一致性怎么管的。

关键词：LocalBusiness、多门店 SEO、城市落地页、GEO、AI优化AIO、实体识别（Entity Recognition）、JSON-LD、生成式引擎优化（Generative Engine Optimization）、数据一致性

参考与延伸

• schema.org LocalBusiness 类型定义
• Google Search Central：本地商家（LocalBusiness）结构化数据
• Microsoft Learn：ASP.NET Core Razor Pages
• schema.org openingHoursSpecification 属性