先给结论:不要为“重庆”“渝”“主城”“渝中区”各建一套平行导航。更稳的做法是选一个主称谓体系贯穿全站,把别名和行政区名降为同一层级下的筛选入口或锚点。判断依据不是哪个叫法更亲切,而是你手里的页面资料能否让每个入口都落到有独立信息量的落地上。如果做不到,就合并入口。
打开你现有的栏目树或导航草稿,把每个条目按“称谓类型”和“可承载内容”两列标记。称谓类型分三种:城市别名(渝、山城)、城市全称(重庆)、行政区名(渝中区、江北区、沙坪坝区)。可承载内容看该条目下是否已有或能写出服务范围、交付方式、常见问题等独立信息。
关键前提变化在这里:如果业务覆盖整个重庆且各区流程一致,行政区名只是用户所在地的标识,不构成独立内容;如果各区在交付、资质或资源上确有差异,行政区名才值得单独成层。前者应合并,后者才拆分。
“渝”和“重庆”在百度语境里通常指向同一需求,用户不会因为换了叫法而期待不同内容。因此别名入口的合理处理是:在主导航中只保留“重庆”这一称谓,把“渝”“山城”等写法放进页面正文、标题的同义表述或站内搜索的同义词配置里,让它们指向同一批落地页。
实际动作:把导航草稿里所有以别名为标题的条目,合并到对应的“重庆”条目下,检查合并后是否出现两个条目指向同一落地页。若出现,删掉重复项,只留一个。这样做的结果是导航层级减少,你接下来要判断的就是行政区这一层是否还需要保留。
行政区名要单独进导航,需要同时满足两点:一是该区有可区分的服务内容,例如上门范围、对接流程或可交付资源的差异;二是该区有足够的页面素材支撑一个独立落地页,而不是把同一段文字换个区名。只满足第一点,可以用筛选条件或锚点承载;两点都不满足,就并入城市层。
假设一个例子:某服务在渝中区和江北区都提供,但江北区只接预约制、渝中区可即时响应。此时“江北区”和“渝中区”可以各有一个入口,前提是每个入口页都写清各自的预约方式与响应条件。反过来,如果两区流程完全一样,只是用户所在地不同,那么导航里放一个“重庆”入口,区内用筛选或列表区分即可。
执行完这三步后,你会得到一张缩减后的导航表。下一步是验证:逐个点击每个入口,看落地页是否回答了该称谓对应的具体问题。如果某个行政区入口的落地页与城市页内容重合,说明该入口不该独立存在,应回退合并。
把每个区名都做成导航项,看似覆盖了更多搜索表述,但会让用户在每个入口都读到相似内容,也让后续维护成本上升。更实际的做法是让入口数量与内容差异数量对齐。别名和行政区名并存的真正难点不是命名,而是你是否愿意为每个保留的入口写出不同的信息。
如果暂时写不出差异内容,就先合并入口,等某个区确实积累了可区分素材再拆出来。这个判断可以随时回看,不需要一次定死。