企业官网导航怎么规划？栏目、层级、菜单、面包屑、移动端与验收清单
企业官网的导航问题往往在内容逐渐增多后才暴露。产品、行业、服务和资料各自建了一套栏目，同一页面出现在几个入口下，访客看见菜单却不知道该点哪一个。
可用的信息架构需要回答三件事：网站有哪些内容，访客按什么任务寻找，页面之间是什么关系。菜单只是这些关系的一种展示方式，不能代替前期梳理。
先定义导航服务的对象
采购人员、工程人员、经销商、求职者和现有客户寻找的内容不同。项目先确定主要访客及其优先任务。
不能把所有人都列为同等目标，否则主导航会不断增加入口，最后失去重点。
记录访客要完成的任务
任务可以是查找适配产品、核验证书、下载图纸、了解交付能力或提交售后问题。每项任务写明起点、所需信息和完成页面。
企业内部部门名称通常不是访客任务。内容归谁负责，可以留在后台字段中。
盘点现有页面与文件
导出当前 URL、标题、栏目、模板、状态、访问量、入站链接、负责人和更新时间。PDF、图片库和外部工具也要纳入。
只看顶部菜单会漏掉搜索入口、活动落地页、旧产品和被外链引用的孤立页面。
区分保留、合并与下线
盘点后给每条内容标记保留、重写、合并、归档或删除，并记录理由。重复页面先确定权威版本。
需要迁移的旧地址保存映射，不能等上线后再凭印象寻找。
用内容对象建立底层关系
产品、系列、应用、案例、资料、证书和服务都是不同内容对象。它们通过型号、行业、地区或主题关联。
如果 CMS 只保存一篇篇无字段文章，前台很难稳定生成筛选、相关内容和面包屑。
栏目树从内容关系生长
先把对象和任务画成关系图，再决定哪些关系需要成为层级。并非每种关联都要放进主导航。
标签、筛选、相关推荐和站内搜索可以承担交叉关系，栏目树只保留主要归属。
主导航控制入口数量
主导航展示最重要、最稳定的几个入口。新增一个入口前，先说明它服务哪个核心任务，是否能合并到现有栏目。
业务部门调整不应自动导致官网菜单重排。访客习惯和旧链接也有维护成本。
栏目名称使用客户语言
“产品中心”“解决方案”“资料下载”需要配合实际内容，避免只使用企业内部缩写、事业部代号或抽象口号。
名称应能预示点击后的内容。若两个栏目听起来相近，访客会反复试错。
同一级栏目保持同一维度
产品类型、客户行业、服务流程和公司信息不宜混成一组互相包含的分类。每一层尽量沿同一种判断维度展开。
确需交叉时，选定一个主要归属，其他关系用链接或筛选表达。
层级深度服从内容规模
层级过浅会让单页塞入大量混杂链接，层级过深则增加查找和维护成本。应根据实际内容量与任务路径决定。
不能为保持三层或四层而创建只有一个子项的空栏目。
空栏目不上线
栏目入口至少要有明确介绍、可用子页面和下一步动作。只有标题、占位图或“敬请期待”的栏目应留在草稿状态。
产品尚未准备好时，可以先建立后台模型，不必让访客看到半成品入口。
每个页面只有一个主要归属
一个案例可能同时属于多个行业和产品，但面包屑、URL 管理和责任归属需要稳定的主要路径。
其他维度作为标签或相关链接。不要复制页面生成多套近似 URL。
首页导航不替代首页内容
顶部菜单提供全站入口，首页正文还要解释业务重点、目标客户和关键路径。访客不应靠展开全部菜单理解企业做什么。
移动端默认收起菜单时，首页主体尤其需要承担方向说明。
全局导航保持跨页一致
主菜单的顺序、名称和核心入口在同一语言站内保持稳定。登录后或不同产品区需要变化时，应明确说明上下文。
页面之间随意更换菜单会增加记忆负担，也难以进行统一回归测试。
局部导航解释当前范围
产品系列、帮助中心或专题区可以设置局部导航，让访客浏览同一范围内的兄弟页面。
局部导航需要名称和视觉边界，不能与全局菜单长得完全一样。
页脚导航承担补充入口
隐私、条款、联系、招聘、语言、证书和常用资料适合放在页脚。页脚不能成为所有被主导航删除页面的堆放区。
每个链接仍要有明确名称、有效目标和维护责任人。
重要页面获得上下文链接
Google 的站点链接文档建议采用逻辑清楚的结构，并从相关页面链接重要内容。正文内链比孤立的菜单入口更能解释关系。
链接文字应简洁且与目标相关，避免大面积使用“了解更多”。
链接使用可抓取的 HTML
Google 对站点结构的说明建议使用带 `href` 的 `` 元素链接内容。只靠脚本点击、画布或不可识别控件可能让抓取与键盘操作失效。
上线验收需要查看最终渲染结果，不能只检查 CMS 中是否配置了目标地址。
下拉菜单只展示必要层级
下拉菜单适合显示直接子项或少量分组。把全部产品、文章和下载文件塞入巨型菜单，会让焦点、触控和维护变复杂。
内容很多时提供栏目页、筛选和搜索，不让菜单承担数据库浏览器的工作。
父级名称决定是否可点击
如果父级本身有内容页，它应是正常链接，旁边另设展开按钮。若父级只负责分组，就不要让文字看起来像可访问页面。
同一站点保持一致规则，避免有的父级打开页面，有的只展开菜单。
展开按钮提供状态语义
W3C 的 Disclosure 模式要求控制元素具备按钮语义，并用 `aria-expanded` 表达展开状态，必要时以 `aria-controls` 关联内容。
箭头方向只是视觉提示，不能代替程序可读状态。
Enter 与 Space 都能操作
键盘焦点到达展开按钮后，Enter 或 Space 应切换子菜单。Tab 继续按正常顺序进入可见链接。
不能只监听鼠标悬停。触屏设备也没有稳定的悬停状态。
Esc 关闭已展开菜单
打开的下拉内容可能遮挡页面。键盘用户应能用 Esc 关闭，并把焦点返回相应控制按钮。
焦点离开导航区域后的关闭规则保持可预测，不让菜单在操作中突然消失。
普通站点导航慎用 menu 角色
W3C 的示例指出，常见站点链接导航通常不需要应用程序式的 `menu` 或 `menubar` 角色。错误角色会让辅助技术期待另一套复杂键盘行为。
语义化的 `nav`、列表、链接和按钮更容易实现，也需要在目标浏览器和辅助技术中实测。
导航区域提供可识别名称
页面同时有主导航、产品导航和页脚导航时，每个 `nav` 区域需要可区分的名称。
名称面向用户说明范围，例如“主导航”或“产品分类”，不使用开发组件编号。
当前页面状态清楚可见
当前栏目或页面除了颜色变化，还应有文字、图标或 `aria-current` 等可识别状态。访客要知道自己在哪里。
父级栏目也可以显示激活状态，但不能让多个无关入口同时高亮。
焦点样式不能被删除
键盘用户需要看见当前焦点。自定义样式可以匹配品牌，但必须保持足够对比和清楚边界。
不要因为鼠标点击后出现轮廓就全局设置 `outline: none`。
触控目标留出操作空间
链接、展开按钮和关闭按钮应有足够点击区域，彼此不能挤得过近。文字换行后仍保持完整触控范围。
真机测试拇指操作，不能只在桌面浏览器缩小窗口。
移动端菜单保持层级线索
抽屉菜单或全屏菜单打开后，缩进、标题和返回行为要说明当前层级。深层菜单不能把父级上下文全部隐藏。
用户关闭再打开菜单时，是否保留展开状态需要统一规则。
打开菜单时管理页面滚动
全屏菜单打开后，背景页面不应继续意外滚动；关闭时恢复原来的页面位置。
滚动锁定不能造成焦点丢失、页面跳顶或关闭按钮不可达。
菜单关闭后归还焦点
用户从汉堡按钮打开导航后，焦点进入可操作区域；关闭后回到原按钮。焦点不能落到页面顶部或不可见元素。
这种细节要用真实键盘和屏幕阅读器检查。
横竖屏切换不丢失状态
设备旋转或窗口跨越响应式断点时，隐藏菜单中的焦点和滚动锁定要正确清理。
桌面导航与移动导航若使用两套 DOM，需避免重复链接被辅助技术同时读取。
面包屑表达页面层级
Google 将面包屑描述为页面在站点层级中的位置。访客可以从当前页逐级回到上层。
面包屑应反映网站信息架构，不能简单复制浏览器访问历史。
面包屑末项标记当前页
前面的层级使用可访问链接，最后一项显示当前页面名称，并通过合适语义表明当前位置。
标题很长时可以适度缩短，但不能改成无法识别的内部编号。
移动端面包屑避免截断关键层级
窄屏可换行、横向滚动或保留最近层级。首页与当前页之间的重要栏目不能被无提示省略。
省略号需要有明确展开方式，不能只留下一个不可操作符号。
BreadcrumbList 与可见内容一致
如果使用 BreadcrumbList 结构化数据，项目应从同一层级数据生成可见面包屑与标记。
不能为搜索展示虚构一条用户看不到的路径，也不能把测试通过当成搜索结果保证。
URL 不必机械复制菜单层级
稳定、可读的 URL 有助于管理，但菜单调整不应迫使所有地址一起改变。URL 与信息架构可以相关，不必完全绑定。
需要改地址时建立逐条映射，保留查询参数和锚点的实际需求。
语言切换保留等价页面
访客在产品详情页切换语言，应尽量到对应语言的同一产品，而不是跳回另一语言首页。
没有等价页面时清楚提示，并提供当前语言可用的相关入口。
地区导航与语言导航分开
语言决定内容表达，地区还可能改变产品、法规、联系方式和交付条件。两者可以关联，但不能混成一个含义不清的选择器。
系统保存访客选择，同时允许随时修改。
搜索补充导航而不替代结构
站内搜索适合处理长尾任务、旧型号和不确定词汇。主导航仍要让新访客理解内容范围。
索引、筛选、同义词和无结果分析见企业官网站内搜索清单。
选型工具需要稳定返回路径
访客从导航进入选型流程后，应能回到产品系列、修改条件或查看详细型号，不能被困在独立工具中。
工况字段与候选结果的组织方法见工业品官网选型指南。
资料下载跟随产品关系
手册、图纸和证书可以从产品页、资料中心和搜索进入，但后台应保存唯一文件与关联关系。
文件版本、权限、缓存和下线规则见企业官网资料下载中心清单。
联系入口按任务分流
询价、技术支持、售后、媒体和招聘可以进入不同表单或渠道。导航名称先说明用途，再显示联系方式。
联系页面的地址、营业时间与送达验收见企业官网联系页面清单。
CMS 保存栏目稳定标识
栏目名称和前台顺序会变化，后台使用稳定 ID 关联页面。删除栏目前检查子项、外链、权限和语言版本。
内容模型、权限与导出要求见企业官网 CMS 选型清单。
栏目变更经过内容审核
调整导航会影响多个页面、搜索索引、统计和客户资料。提交人说明原因、影响范围、生效时间和回滚方案。
重大调整由业务、内容、技术和 SEO 负责人共同审核，不由某个页面编辑直接上线。
菜单配置区分草稿与发布
后台应支持预览待发布菜单，生产站继续使用已批准版本。发布记录保存操作者和差异。
不能在高访问时段边拖拽边试验线上结构。
权限避免误删全站入口
普通编辑可以维护页面内容，不一定需要修改全局导航。栏目删除、批量移动和语言同步使用更高权限。
权限测试要覆盖正常操作和越权尝试。
记录菜单点击但尊重隐私
可以观察入口点击、下拉展开、返回、搜索和任务完成。事件名称包含菜单版本与位置。
导航分析通常不需要收集访客输入的完整查询、姓名或项目机密。
低点击不等于入口无用
联系、隐私或紧急支持可能访问量低却很重要。是否保留要结合任务价值、替代路径和用户研究。
菜单位置也会影响点击，不能只按百分比删除内容。
路径分析识别绕路
连续返回、反复展开、进入后立即退出或转而搜索，可能说明名称含糊或归类错误。
分析样本后安排可用性测试，不能只凭事件序列猜测访客动机。
用真实任务做树测试
在视觉设计前，把栏目名称和层级交给目标用户，让他们指出完成具体任务会走哪条路径。
记录首次选择、返回次数、完成率和理由。内部员工熟悉组织结构，不能替代外部用户。
原型测试菜单交互
树测试验证分类，交互原型再检查展开、焦点、移动端和内容预期。两个阶段解决的问题不同。
测试用任务来自真实咨询，不用“请找到产品页面”这类直接暴露答案的措辞。
上线验收覆盖每类入口
抽样测试主导航、局部导航、页脚、正文链接、面包屑、语言切换、搜索和 404 页面。每条路径检查状态码与最终内容。
完整的环境、浏览器、回归和缺陷管理见企业官网上线验收清单。
自动检查抓取死链
定期抓取公开站点，识别 404、重定向链、循环、孤立页和指向测试域名的链接。工具结果需要人工确认业务意图。
robots、站点地图、canonical 和索引核验见企业官网技术 SEO 验收清单。
迁移后保留旧路径证据
旧 URL 清单、映射、上线时间和验证结果要保留。不能只保存最终配置，因为后续还要解释历史外链和异常流量。
重定向目标必须与旧页面意图相符，不能把所有旧地址统一跳到首页。
导航设定定期复审触发
新产品线、并购、停产、语言扩展和 CMS 更换都会触发复审。日常复审关注空栏目、失效链接、命名冲突和内容堆积。
复审不等于每季度重排菜单，稳定性也是用户体验的一部分。
交付可维护的信息架构资料包
企业应取得内容清单、对象关系、栏目树、命名规则、页面归属、菜单配置、重定向表、权限、事件和测试用例。
交接时由企业人员新增一个页面，完成归类、关联、菜单判断、面包屑、搜索、发布和下线演练。
凯乐丰可以参与的环节
凯乐丰官网列有企业官网建设、外贸独立站建设和SEO/GEO 增长方案等业务页面。企业咨询导航规划时，可以提供现有 URL、产品目录、访客任务、语言地区、后台权限和历史统计。
凯乐丰可在约定范围内协助内容盘点、信息架构、菜单与面包屑实现、移动端交互、结构化数据判断和上线验收。产品归属、业务优先级、合规内容和最终栏目名称仍由企业负责人批准。
