先给结论:把“南京”“宁”“金陵”这类城市别名,和“鼓楼区”“江宁区”“建邺区”这类行政区名称,放在同一套导航里时,不要按名称逐条建栏目。更稳的做法是只保留一条能覆盖全市的主路径,把行政区作为筛选或分层入口,用同一份可核对的项目表来统一各方理解。别名用于页面内表述和用户语言,行政区用于业务范围和服务边界,两者职责分开,导航就不会因为叫法不同而反复改版。
假设有一个虚拟团队正在规划一个面向南京本地的SEO咨询项目,成员包括负责内容的编辑、负责投放的运营、负责对接客户的商务。编辑认为导航里应该出现“金陵”和“宁”,因为客户会这么搜;运营认为必须把十多个行政区全部列出来,方便投放落地页对齐;商务则担心只写“南京”太笼统,客户看不出服务范围。这三个人说的其实不是同一件事。
城市别名解决的是“用户怎么称呼这个地方”。它适合出现在标题、正文表述、问答段落和页面内部链接的锚文本里,让内容读起来像本地人写的。行政区名称解决的是“服务覆盖到哪里、责任怎么划分”。它适合作为导航的第二层,或者在列表页里做成可筛选的标签。而“南京”这个正式名称解决的是“这个页面属于哪个城市”,它是主路径的锚点,负责把整站的城市归属说清楚。三者混在一层导航里,就会出现“金陵”和“鼓楼区”并列这种层级错乱,用户点进去也不知道会看到什么。
当多个角色对同一件事有不同理解时,争对错没有用,把分歧写成可以勾选的项目更有效。可以按下面这个顺序做一次核对,每一项都要有人给出明确答案,答不上来的先标记为待定,而不是先建页面。
做完这份表,通常会得到一个反直觉的结果:需要独立入口的行政区数量远少于最初想列出的数量。这个结果会直接影响下一步——如果只有两三个区有独立内容,就不该为它们单独设计一套导航模板,而是复用同一套列表页结构,只在内容层做区分。这一步动作的价值在于,它把“要不要建页面”从主观偏好变成了有依据的判断。
实际操作中,有两种结构是成立的,选择哪一种取决于内容量,而不是取决于哪种叫法更流行。
方式一:单一主入口加筛选标签。主导航只保留正式城市名,进入后用一个列表页承载所有行政区,页面上用标签或分组把区名列出来,别名只出现在正文和锚文本里。这种方式适合内容量中等、各区差异不大的情况。它的好处是导航稳定,不会因为新增一个区就改一次结构;代价是用户需要多点一次才能到达具体区域内容。
方式二:主入口加少量重点区二级导航。主导航保留正式城市名,下面直接挂两到四个确有独立内容的行政区,其余区仍然收在列表页里。这种方式适合少数区有明确不同的服务内容、需要单独说明的情况。它的前提是这些区的内容确实不同,而不是只把区名替换一遍。如果只是替换名称,二级导航会变成一堆高度相似的页面,反而增加维护负担。
判断该选哪种,可以看一个简单条件:把这些区的页面正文互换区名后,内容是否仍然成立。如果成立,说明差异不足,应该退回方式一;如果不成立,说明确有独立内容,方式二才站得住。
假设某团队最初决定为南京全部行政区各建一个导航入口。执行到一半时发现,其中大部分区的页面除了区名不同,服务说明、流程描述、常见问题几乎一致。这时正确的动作不是继续补完剩余页面,而是暂停,把已经建好的页面按“内容是否可互换”重新分类。分类结果会直接决定下一步:可互换的合并进列表页,不可互换的保留为二级入口。这个动作省下的不是建页面的时间,而是后续每次更新时都要同步修改十几个相似页面的维护成本。
需要说明的是,页面数量减少、某些入口访问量下降,这些现象本身不能单独证明结构改对了。访问量下降也可能是因为入口变深、用户习惯没跟上,或者原本的流量来自与业务无关的查询。判断结构是否合理,要看的是不同角色是否还能用同一份名称清单对齐工作,而不是看某一个数字的涨跌。
导航结构定下来之后,还需要一条简单的名称规则,避免后续内容生产时又出现混用。可以约定:正式城市名用于导航、面包屑和页面归属标识;城市别名用于正文表述和内部链接锚文本;行政区名称只用于服务范围说明和筛选标签。规则写清楚之后,新加入的编辑或运营不需要再问一遍该用哪个词,商务对客户解释服务范围时也有统一口径。
最后提醒一点:城市名本身不构成服务能力的证明,也不代表在搜索结果中会获得任何优势。导航怎么组织,影响的是内部协作效率和用户理解成本,这两件事才是可以通过核对清单逐项确认的。