官网菜单越改越简，定价和文档为什么更难找

假设一家 SaaS 公司把官网从六个一级栏目收成“产品、解决方案、资源”三个下拉菜单。价格页和文档页仍在，只是从页头可见入口移到了第二层。改版后如果销售频繁收到“有没有公开价格”“API 文档在哪里”这类提问，团队就该检查这两类页面的发现机会是否下降。

这种变化很容易被当成文案问题，团队接着改栏目名、换下拉样式。真正要先回答的是：哪些页面必须让访客一眼看到，哪些页面允许晚一步出现，晚一步之后会损失多少发现机会。菜单减项会重新分配注意力，评估改版也要把“更清楚”和“更容易找到”分开看。

菜单越短，入口也可能一起消失

访客打开官网时，还不知道站内有多少页。他只能根据眼前的栏目名判断下一步点哪里。NN/g 把这种点击前的判断称为信息线索：链接名称、周围文字和访客已有认知，共同决定一个入口看起来是否值得点击。

“资源”在公司内部可能包含文档、客户案例、博客和帮助中心，对第一次来的技术负责人却太宽。他要找 API 文档，看见“资源”时无法确认里面有没有；“平台”也可能装着产品功能、集成和安全说明。页面虽然存在，入口给出的线索不足，访客仍可能直接离开或回到搜索引擎。

隐藏还会增加一次操作。NN/g 对桌面导航的研究指出，可见链接更容易被发现、扫描和点击；收进图标或下拉层级后，用户要先意识到那里有菜单，再打开、阅读、选择。这个过程不代表所有二级入口都会失效，却说明团队每收起一项，都在主动降低它被偶然看到的机会。

先列四个买家任务，再决定哪些链接必须露出

一级导航没有通用答案。先把最近三个月的站内搜索词、销售反复收到的问题、主要落地页入口和导航点击整理成表，再按访客当时要完成的任务归类。Balsamiq 整理的软件公司网站可用性测试覆盖 10 家中大型软件公司，描述性标签、定价、How it works 和集成入口反复影响用户理解产品；这项小样本只提供检查方向。结合自己的站内数据，先从下面四类任务开始分：

• 第一次来，确认产品做什么、适合谁；
• 正在比较，查看价格、客户案例和安全说明；
• 进入技术评估，寻找文档、集成和 API；
• 已经准备行动，登录、试用或预约演示。

这四类任务不等于四个固定栏目。产品简单、免费试用为主的网站，价格和“开始使用”可能需要直接露出；产品复杂、销售主导的网站，安全、集成或文档可能比博客更重要。决定顺序时，先看页面服务哪个任务，再看公司内部由哪个部门负责。

如果销售每周都在回答“有没有 API”，站内搜索也持续出现“API”“文档”，把文档藏进“资源”通常没有省下复杂度，只是把解释工作从网站转给了销售。反过来，一项低频服务即使对内部团队很重要，也适合放到相关产品页、页脚或登录后的场景里，不必和定价争夺同一层注意力。

先重排页面树，再改菜单名称

有些争论表面上是栏目名，实际来自页面归属。一个“数据分析”页面既被当成功能，又被当成解决方案；客户案例同时按行业、地区和产品分类；文档里还混着帮助中心和开发者 API。此时给菜单换一组更顺口的名字，访客进入下一层后仍会迷路。

先把真实页面标题写成卡片，请目标客户或一线销售按他们理解的方式分组并命名。卡片分类适合发现用户会把哪些内容放在一起，随后还要用树测试验证拟定的层级：给参与者“找到企业版安全说明”“找到 Shopify 集成文档”之类的任务，只展示文字树，观察他第一次选了哪一项、是否反复返回、最后有没有找到目标。

如果卡片怎么分都冲突，说明页面归属已经影响整站结构，团队要先处理页面清单、目录层级和 URL。网站架构规划工具会把现有页面、增长渠道和优先级整理成目录树，让菜单承接一个已经说清楚的结构。页面树稳定以后，再讨论一级和二级入口会省下很多来回改名。

清楚和被发现会同时变化

ImmoScout24 的公开改版过程很能说明这项取舍。随着租房、买房、业主服务、融资和搬家等业务增加，原有导航在多个设备上越来越拥挤。设计团队通过工作坊和卡片分类重排目的地，把主要用户任务和战略业务入口保留在显眼位置，次要服务收进结构化菜单。

项目复盘记录了两个同时发生的结果：可用性测试里，用户认为新结构更清楚、负担更轻；A/B 测试里，被收进菜单的目的地流量下降，获得更高位置的区域使用增加。公开资料没有给出具体百分比，也没有把变化连接到营收，因此这段案例能支持的结论很明确：界面更清楚，并不保证每个页面都更容易被发现。

GOV.UK 的导航测试复盘又补了一层。第一版原型展开更多架构、删掉栏目描述，熟练用户找信息更快，数字技能较弱的参与者却容易被多列和多列表干扰。团队随后恢复二级描述、降低未选项的视觉权重，再继续观察用户选择。对 SaaS 官网来说，这意味着一次内部评审觉得“简单”，还不足以代表新访客、采购和技术评估者都能找到自己的入口。

改版前后，要看两组不同结果

上线前先做一轮轻量树测试。选定价、客户案例、API 文档和安全说明四个真实任务，找几位不了解网站结构的人完成。记录任务是否完成、第一次进入哪个栏目、是否返回上层，以及参与者怎样解释栏目名。小样本能尽早找出明显歧义，仍不能替代上线后的真实行为。

上线后至少连续看四类信息：

• 主导航各入口的点击占比怎样变化；
• 定价、文档等目标页从主导航、站内搜索、内容页还是外部搜索进入；
• 站内搜索是否增加“价格”“API”“集成”等本应由导航回答的词；
• 销售、客服是否开始重复回答某类“在哪里”的问题。

单看导航点击会漏掉一部分损失。入口被隐藏后点击下降，既可能是页面优先级确实降低，也可能是访客根本没发现；要结合目标页总访问、搜索词和销售提问判断。页面树和优先级确认后，网站导航菜单设计工具会继续输出一级与二级菜单、锚文本和桌面、手机交互清单，方便市场、设计和开发在同一版结构上工作。

开发交付还要写清抓取和操作状态

菜单原型通过以后，还要防止开发实现重新把重要入口藏起来。Google Search Central 的链接规范建议主要入口使用带有效 href 的 a 元素，并让锚文本准确说明目标页。只在点击事件里跳转，或把页面藏在站内搜索里，会让搜索引擎更难发现这些地址；可抓取也只解决发现问题，不自动带来收录和排名。

同一份交付还要写清桌面和手机的展开方式、键盘焦点、当前页状态、触控区域和关闭动作。W3C 的菜单教程特别提醒，下拉菜单要让鼠标、键盘和触控用户都能操作，并清楚显示当前位置。访客用键盘打不开二级菜单，或者手机端一滑就收起，结构设计再合理也到不了目标页。

所以，导航改版完成时，团队要能说清三件事：哪些买家任务获得了更显眼的入口，哪些页面被主动下沉，下沉后准备用什么数据观察影响。菜单更短只是页面外观；访客能不能找到价格、文档和下一步，才是这次改版真正要解决的问题。