先把“镇江”和“京口”“润州”“丹徒”等行政区名称当作两套并行的检索语言,而不是互相替代的标签。导航的组织方式取决于你的服务半径:服务覆盖全市时,城市别名适合做总入口,行政区名称适合做筛选或落地页;只服务某一个区时,反过来用行政区名称做主导航,镇江只作为页面上下文出现。下面用一个假设情境把决策过程走完。
假设有一家做办公设备维护的小团队,服务范围覆盖镇江市区及下辖区域。运营、客服和外地来的顾问对导航各有主张:运营认为用户会搜“镇江”,所以主导航只放镇江;客服发现来电用户常直接说“我在京口”“我在丹徒”,找不到对应入口;顾问则主张把所有行政区平铺到首页。三种理解都成立,但指向的是不同的检索与浏览行为。把分歧转成可核对的项目,可以从一张“名称—角色—证据”的清单开始。
这张清单的作用不是证明谁对,而是让三方在同一张表上争论。假设客服记录显示,提到具体行政区的用户占比明显高于只提“镇江”的用户,那么客服的诉求就有了可核对依据,而不是印象之争。
方案一:城市别名做总入口,行政区做二级筛选。适用于服务覆盖全市、各区服务内容基本一致的情况。主导航保留“镇江”,进入后按行政区筛选或分区展示。好处是结构稳定,不会因为行政区名称调整而频繁改动导航;代价是用户需要多点一次才能到达自己所在区。
方案二:行政区名称直接进主导航。适用于各区服务差异明显,或某一区是主要业务来源的情况。此时“镇江”退为标题、面包屑和页脚中的上下文词,不占主导航位置。好处是用户一眼看到自己所在区;代价是导航项变多,且当行政区名称存在多种叫法时容易遗漏。
判断用哪一种,看一个动作的结果:把当前导航截图发给客服,请他们按最近二十通电话中用户的自述位置,逐一指出“用户会点哪里”。如果多数电话找不到对应入口,方案二更合适;如果多数能通过一次筛选到达,方案一够用。这个动作的结果直接决定下一步是改主导航,还是只调整筛选文案。
“镇江”作为城市别名,和“京口”“润州”这类行政区名称不在同一层级,不要并排放在主导航里。更稳妥的做法是让它们承担不同职能:城市别名负责页面归属和标题上下文,行政区名称负责用户定位和内容分组。
主导航只保留一套主词。若选方案一,主导航是“镇江”,行政区出现在下拉或筛选区;若选方案二,主导航是行政区,镇江出现在页面标题和面包屑。
每个行政区名称对应一个可独立访问的页面,页面内再说明覆盖范围。城市别名不单独再建一套平行页面,避免两套结构互相竞争、内容重复。
在页面正文里同时出现两种叫法是正常的,但要在同一句里建立关系,例如“服务范围覆盖京口、润州等镇江市区”。这样用户和检索系统都能确认两者指向同一服务区域。
把“用户到底怎么称呼自己所在的位置”变成可查的数据,是这类分歧唯一可靠的收敛方式。可以核对的项目包括:站内搜索词中出现的行政区名称、客服工单里用户自述位置的用词、导航各入口的点击分布、以及各落地页的到达路径。注意,某一入口点击量低,可能是位置不明显、文案不匹配,也可能是该区本来需求就少,不能单独归因于导航结构错误。
假设站内搜索里“丹徒”出现频次高,但导航中没有对应入口,那么先补入口再观察,而不是直接重做整个导航。补入口后,如果该入口点击上升且客服重复询问减少,说明定位问题确实存在;如果没有变化,则要回到服务范围本身去核对,而不是继续调整导航层级。
回到开头的假设情境:三方争论的其实不是“哪个词更好”,而是“用户在哪一步需要看到哪个词”。把名称、角色、证据列成同一张表,再用客服指认入口这个动作去验证,导航结构就从偏好问题变成了可以核对、可以修改的项目。下一步该改主导航还是只改筛选文案,取决于指认结果,而不是取决于谁的职位更高。