1. 一份导航页为什么值得认真做

做站点导航这件事，很多人第一反应是"不就是堆链接吗"。我最初也这么想，直到自己维护的导航页被同事当成日常工作入口、每天要开十几次，才发现这里面的信息架构问题比想象中复杂得多。所谓"最全的搜索引擎入口和分类目录入口"，本质上是一份信息检索入口的索引——它把分散在各类站点上的搜索框、垂直检索工具、主题目录、资源聚合页，按使用场景重新编排成一个可以直接点开就用的页面。它解决的核心问题不是"找不到网站"，而是"知道网站存在但每次都要绕三层才找到那个真正管用的搜索框"。

这份东西适合谁？我梳理了三类。第一类是重度信息工作者，比如做市场调研、竞品分析、素材收集的岗位，每天要跨十几个站点检索，入口效率直接决定产出速度。第二类是刚入门的新手，面对海量站点不知道从哪个开始，一份有分类逻辑的目录能帮他建立基本的地图感。第三类是自建导航页的爱好者，想参考别人的分类维度和维护方式。三类人需求不同：第一类要的是"快"，第二类要的是"全且有解释"，第三类要的是"结构可复制"。

这篇文章我会把自己搭建和维护这类导航页的完整思路拆开讲：分类维度怎么定、入口怎么筛、页面怎么组织、失效链接怎么管、以及那些看起来很小但实际极其影响使用体验的细节。搜索引擎入口和分类目录入口这两个关键词会贯穿全文，因为它们代表两种完全不同的检索哲学——一个是关键词直达，一个是主题浏览，导航页的价值就在于把两者的边界讲清楚，而不是混在一起堆成一片。

先说结论性的判断：导航页的成败，八成取决于分类体系，两成取决于链接数量。一个只有五十个链接但分类清晰的页面，比一个塞了八百个链接但靠搜索框救场的页面有用得多。后面所有内容都围绕这个判断展开。

2. 分类体系怎么搭才不会变成一锅粥

2.1 两种检索哲学的边界要先划清

动手之前必须想明白一件事：搜索引擎入口和分类目录入口不是同一类东西，硬塞进一个列表里必然混乱。搜索引擎是"我知道我要什么，我用关键词去命中"；分类目录是"我大概知道我要什么方向，我沿着主题往下翻"。这两种行为模式对应完全不同的页面位置和心理预期。

我的做法是在导航页顶部做明确的物理分区，而不是靠一个小标题区分。上半区是搜索区，每个入口就是一行输入框加一个直达按钮，用户点进来立刻能打字；下半区是目录区，用网格卡片呈现主题分类，点进去是二级页面。这个分区方式看着朴素，但实测下来误点率最低——人眼在页面顶部会自然期待"输入",在中部以下会期待"浏览"。

为什么不做成混合列表？我试过。早期版本把某几个搜索引擎和几个主题目录混在一个"常用推荐"区块里，结果是我自己都经常点错——本想直接搜索，结果点进了一个目录首页，还得再点两层。混合的代价是每次使用都要多一次判断，一天几十次就是几十次额外的认知负担。这个坑建议直接从设计上避开。

注意：分区不等于加分割线。视觉上要有明确的背景色差或留白区隔，否则用户滚动时会丢失"我现在在哪个区"的位置感。

2.2 分类维度选择：按用途切比按行业切更实用

分类维度是导航页最容易做错的地方。常见错误是按"行业"分——新闻类、科技类、教育类、生活类……看起来整齐，用起来很别扭。因为同一个站点常常横跨多个行业，而用户的检索行为很少以"行业"为起点，更多是以"我要干什么"为起点。

我最终采用的是按用途切分的混合维度，具体拆成六组，每组下面再挂具体的入口：

这个表看着简单，但每个分组的排序有讲究。综合直达放最上面是因为它的使用频率最高、决策成本最低；垂直专题放第二是因为它是"有目标但没方向"时的第二落点；主题目录放第三是给浏览型用户的缓冲；资源聚合和本地工具属于场景触发型，用的时候才找；我的常用放最后不适合，我的实际做法是把它做成侧边悬浮条，永远可见。

为什么按用途切比按行业切好？举个具体例子。我要找一份公开的行业数据图表。按行业分类，我得先判断这属于"财经"还是"科技"还是"教育"，判断本身就要花时间，而且经常判断错。按用途分类，我直接去"资源聚合"里的图表素材组，一步到位。用户的行为路径是"动作→工具"，不是"领域→工具"，分类维度必须贴合行为路径。

2.3 层级深度控制在两层，第三层用标签代替

导航页的层级是个硬约束。我的经验是：从首页到最终搜索框，点击次数不得超过两次。超过两次，用户就会开始怀疑自己点错了，然后返回重来，整个过程挫败感极强。

具体落地上，首页是六个分组，每个分组点进去是二级页，二级页里直接就是可用的入口列表或搜索框——到此为止，不再往下分。那如果某个分组里条目太多怎么办？用标签筛选代替第三层页面。比如"垂直专题"下有四十个入口，二级页顶部放一排标签：图片、视频、文档、音频、问答、学术、代码、地图。点标签即时过滤当前列表，不跳页、不刷新。

这个设计的逻辑是：层级跳转会丢失上下文，标签过滤不会。用户在二级页里点三次标签，仍然停留在同一个页面，随时能切回来；如果做成三级页面，用户点进去之后想换个类别，得先返回、再点另一次，来回折腾。

提示：标签数量控制在七个以内。超过七个，标签栏会换行或横向滚动，可用性骤降。超出就说明这个分组该拆了。

2.4 命名要写"能干什么"，不写"是什么"

这一条是我踩坑最深的。早期我的入口名称写的是站点自身的品牌式叫法，比如"XX检索""XX索引""XX聚合"。结果三个月后我自己都忘了某个入口到底能搜什么，只能一个个点开确认。导航页的命名一旦脱离功能描述，就等于失效。

改法很直接：每个入口名称后面加一个简短的功能后缀，用破折号分隔，写清楚它能检索什么、输出什么。例如统一写成"某检索 — 文档与PDF全文""某目录 — 人工编排主题站""某聚合 — 多源图片素材"。这个后缀控制在六到十个字，太长会挤占布局空间，太短又说不清。

更进一步，我给每个入口加了一行极小的灰色备注，写使用限制或特点，比如"仅支持站内""需登录""支持批量导出"。这些信息在真正使用时价值极高——省掉了点进去再退出来的往返。备注字段是导航页里投入产出比最高的设计，强烈建议保留。

2.5 顺序即推荐，不要滥用"热门"

很多导航页喜欢做"热门推荐"区块，用某种热度指标排序。我的观点是：在自己的私人导航页里，热度排序基本没有意义。因为使用者就是你自己或少数同事，样本太小，热度波动全是噪声。

替代方案是"手动置顶 + 时间衰减"。手动置顶就是前面说的侧边悬浮的常用区，我自己固定放六到八个高频入口，位置永远不变，形成肌肉记忆。列表内部则按最近使用时间倒序，最近用过的排前面，长时间没用的自然沉底。这个机制不需要任何统计系统，手动拖拽调整即可，成本极低但效果明显。

为什么不用纯字母序？字母序看着整齐，但完全无视使用频率，每次都要在几十个条目里视觉扫描。导航页的核心价值是"减少寻找时间"，字母序把这个价值抵消了大半。

3. 入口筛选：怎么判断一个入口值不值得放进来

3.1 三条硬性准入标准

"最全"这个说法很容易变成"什么都往里塞"。我在筛选阶段给自己定了三条硬标准，不符合的直接不收，哪怕它看起来很有名。

第一条，入口必须是可直接使用的检索界面，而不是需要再导航的中间页。很多站点首页只是个门户，真正的搜索框藏在二级页里。这种我一般不放首页链接，直接放那个二级页的地址，把这个站点的导航成本转移给我自己，让使用者一步到位。

第二条，检索结果必须对未登录用户可见。需要强制登录才能看到结果的入口，价值大打折扣，因为登录本身是个中断。确实不可替代的少数几个，我会在备注里明确标注"需登录"，让使用者有心理预期。

第三条，近半年内入口结构没有大改。这条比较主观，但很关键。有些站点喜欢频繁改版，搜索框位置、参数格式、结果页结构一直在变，放进来三个月就失效。我的做法是每次季度维护时集中检查一遍，把改版后需要额外操作的入口降级或移除。

注意：这三条标准要写进维护清单，而不是记在脑子里。人的记忆会随条目增多而失效，写成文档才能在半年后还在执行。

3.2 同类入口只留两到三个，多留是负担

同一个功能方向上的入口，我最多留三个。理由很实际：超过三个，选择本身就成了成本。用户面对五个图片检索入口时，会犹豫、会比较、会随便点一个试试，这个过程花掉的时间可能比直接用第一个还多。

保留哪两到三个？我的取舍逻辑是按"差异化"挑，而不是按"谁更好"挑。比如图片检索方向，我留的是一个覆盖广的、一个偏素材授权的、一个偏特定风格的。三者覆盖的检索场景不重叠，用户可以根据自己要什么直接选，不需要比较优劣。

这条规则执行起来需要克制。看到新入口时很容易觉得"这个也不错，加上吧"，但每加一个都在稀释已有入口的使用频率，最终整个页面变成谁都不常用。我现在的新增流程是：先加进"待观察"的临时列表，自己用两周，真用到了再正式并进去；两周没碰过，直接删。

3.3 分类目录入口的独特筛选逻辑

分类目录入口和搜索引擎入口的筛选逻辑不一样，得单独说。目录站点的核心价值在于"人工编排"，也就是说它的分类体系和收录标准是有人判断过的。所以筛选时我最看重的不是条目数量，而是分类的编辑质量。

具体看三点。第一，分类层级是否合理——有没有出现某个类目下堆了几百个条目、另一个类目下只有两个的情况，这种失衡说明编排者没投入精力。第二，是否有清晰的收录说明——写清楚收什么、不收什么，这种站点通常维护得更久。第三，更新痕迹是否可见——页面上有没有近期更新的标记或时间戳，长期不更新的目录，里面的链接失效率往往很高。

数量指标反而要往后放。一个收录了三百条但每条都经过筛选的目录，比一个收录三万条但夹杂大量失效链接和低质站点的目录有用得多。我在实践中遇到过不少"大而全"的目录，实际翻十页能找到一两个有用的就不错了，投入产出比极低。

3.4 定期淘汰机制比新增机制更重要

导航页有个天然趋势：不断膨胀。新增容易，删除难受——毕竟是当初精挑细选放进来的。结果就是页面越来越长，使用效率越来越低。

我的做法是建立季度淘汰机制，规则很简单：每个季度末过一遍列表，过去三个月内自己没点过的入口，标记为待移除；连续两个季度没点过，直接删除。删除时把链接记进一份归档文件，万一以后需要还能翻出来，心理负担小很多。

这个机制带来的效果超出预期。第一次执行时我删掉了将近三分之一的条目，页面长度缩短，剩下的条目反而更容易被看到。这就是导航页的悖论：减少条目能提高整体的被使用率。

为什么归档这一步不能省？因为删除的心理阻力主要来自"怕以后要用"。有个归档文件兜底，删除就从"永久失去"变成"放进抽屉"，决策轻松很多。这个小心思在长期维护中非常管用。

4. 页面的实际搭建过程

4.1 技术选型：静态页面足够，不要上来就上框架

这类导航页的技术需求其实极低：展示链接、标签过滤、记录最近使用。我不建议一上手就用前端框架搭一套完整应用，理由是维护成本不对等——你会花八成时间在工程配置上，只有两成在真正影响使用体验的信息架构上。

我的方案是单文件静态页面，HTML 加内联样式和一小段原生脚本。数据用一个 JSON 数组描述，字段包括名称、地址、分组、标签、备注、是否需登录。这个结构的好处是数据与展示分离，调整分类只需要改 JSON，不动页面结构。

[ { "name": "某检索 — 文档与PDF全文", "url": "https://example.com/search", "group": "vertical", "tags": ["文档", "学术"], "note": "支持文件类型筛选", "needLogin": false, "lastUsed": "2025-01-12" } ]

字段设计的几个考量值得说明。group用英文键而不是中文分组名，是为了改分组名称时不牵扯数据；tags用数组是为了一个入口能挂多个标签，比如学术检索同时属于"文档"和"学术"；lastUsed存日期字符串而不是时间戳，因为人看日期比看时间戳直观，维护时直接肉眼判断。

为什么不用现成的导航站生成工具？我试过几个，问题在于它们的分组结构往往是固定的，或者要付费才能自定义标签。自己写一个 JSON 加几十行脚本，二十分钟的事，之后完全可控。

4.2 标签过滤的实现细节与那个容易忽略的坑

标签过滤看着简单，但有个坑我踩过：多标签同时选中时，逻辑该用"与"还是"或"。一开始我按直觉写成了"或"，结果选中"文档"和"图片"两个标签，列表反而变长了，因为把所有文档类和所有图片类都并了进来。用户预期其实是"与"——我想看同时属于这两个标签的入口。

function filterItems(items, activeTags) { if (activeTags.length === 0) return items; return items.filter(item => activeTags.every(tag => item.tags.includes(tag)) ); }

关键在于every而不是some。改成"与"逻辑后，标签的用法就变成了"逐步收窄"，符合筛选的心理模型。同时我给标签加了选中计数显示，比如"文档 (12)"，让用户在点击前就知道会剩多少条，减少无效点击。

另一个细节是标签的排列顺序。不要按字母序或数据出现顺序排，按当前列表中该标签的条目数量倒序排。数量多的标签说明是当前分组的主流方向，放前面更容易被点到。这个小优化让我的标签点击率明显上升，因为第一个标签往往就是用户想要的。

4.3 搜索框的本地过滤方案

页面顶部除了外部搜索入口，还需要一个本地过滤框，用来在几十上百个条目里快速定位。这个和外部搜索是两回事，必须视觉上区分开，否则用户会误以为在里面打字会跳转到外部检索。

实现上用输入即过滤，不设搜索按钮，输入时按名称、备注、标签三个字段做包含匹配，不区分大小写。几百条数据量下，每次输入全量遍历完全无压力，不需要做任何索引优化或防抖处理——我实测过，一千条以内输入延迟完全感知不到。

function localFilter(items, keyword) { const k = keyword.trim().toLowerCase(); if (!k) return items; return items.filter(item => [item.name, item.note, ...item.tags] .join(' ') .toLowerCase() .includes(k) ); }

有个小细节值得加：过滤结果为空时，给出明确的空状态提示，并附带一句"试试清空标签筛选"。因为空结果经常不是真的没有，而是标签筛选取交集后剩零条，用户不知道是标签的问题，会以为数据丢了。

4.4 键盘可访问性：一个被普遍忽略的效率提升

导航页的使用场景是高频、快速，所以键盘操作的价值远超鼠标点击。我给自己定的目标是：从页面加载完成到打开目标入口，不超过三次按键。

具体做法是给本地过滤框加自动聚焦，页面一打开光标就在框里，直接打字。列表支持上下方向键移动高亮，回车打开。这样打开一个常用入口的完整操作是：输入两个字母、按一下方向键、回车，四次按键以内。对比鼠标操作要在列表里找、移过去、点击，键盘方案的效率优势在高频场景下非常明显。

还有个更省事的做法：给最常用的那六到八个入口分配数字键，按 1 到 8 直接跳转。这个需要一段自定义的键盘监听，但实现起来不过十来行。用熟了之后，日常最高频的几次操作几乎不需要看屏幕。

提示：数字键跳转要避开浏览器自身的快捷键组合，只处理不带修饰键的单纯数字按键，并且在输入框聚焦时不触发，否则打字打到数字就跳页，极其烦躁。

4.5 记录最近使用：用浏览器本地存储就够

lastUsed字段如果靠手动维护，必然会懒。我的做法是在点击入口时自动写入本地存储，记录名称和日期，页面加载时读出来做倒序排列。本地存储容量对这种小数据完全够用，也不需要任何后端。

function markUsed(name) { const key = 'nav_recent'; const list = JSON.parse(localStorage.getItem(key) || '[]'); const next = [{ name, at: Date.now() }, ...list.filter(i => i.name !== name)].slice(0, 50); localStorage.setItem(key, JSON.stringify(next)); }

几个实现上的注意点。第一，要去重，同一个入口反复点不应该把列表刷满。第二，限制长度，五十条足够，太长了排序反而乱。第三，本地存储可能被清理，所以这个功能只作为"锦上添花"，页面的基础分类结构必须是完整的，不能依赖最近使用记录才能找到东西——这点很重要，否则换了设备或清了缓存，页面就废了。

4.6 移动端的最小适配

导航页大概率会在手机上被打开，但不需要做完整响应式设计。我的做法只处理三件事：列表从多列变单列、字号不小于十四像素、点击区域高度不小于四十四像素。这三条足以覆盖基本可用性。

多列转单列用一行媒体查询就够。字号和点击区域是纯粹的手感问题，手机上点不准是导航页最恼人的问题之一，尤其条目密集排列时。把每行高度撑起来、留足间距，比任何交互优化都直接有效。

至于更深度的移动端优化，比如手势操作、离线缓存，我认为对这类页面的性价比不高。手机上的使用场景通常是"临时查一下"，不是长时间浏览，把基础可用性做扎实就足够了。

5. 维护中遇到的问题与排查思路

5.1 链接失效的高频原因与检查节奏

失效是导航页的必然损耗，问题只在于发现得够不够早。我整理了几类高频原因，并且针对性地定了检查节奏。

检查节奏上，我做全量检查是每季度一次。全量检查很耗时间，如果条目上百，靠手动逐个点会非常烦。可行的自动化方案是写个小脚本批量请求，只需要判断状态码和最终落到的地址是否与配置一致，两者都不对才需要人工确认。这个脚本不需要多复杂，几十行足够，重点是把"人工逐条点"变成"看一份异常清单"。

自动检查的局限也要清楚：它能发现状态码异常和跳转，但发现不了"页面能开、搜索功能已经不好用了"。后者只能靠偶尔实际使用时的体感。所以我的实际策略是自动检查做兜底，日常使用时遇到不顺手就随手记一笔，周末集中处理。

5.2 搜索结果页地址参数不稳定的处理办法

这是最烦的一类问题。有些站点的搜索框用的是一个很干净的参数，比如?q=关键词，直接把地址存进导航页就能用。但不少站点的搜索参数是一长串编码，或者带有时效性令牌，存下来的地址过一段时间就失效。

我的处理顺序是：先试最简参数形式，直接在地址后拼?q=或?keyword=看是否生效；不生效就尝试从实际搜索结果页里把参数结构提取出来，去掉其中明显是会话或时间相关的字段；还是不行就放弃存参数，改成存该站的首页，并在备注里写"需在站内搜索"。

为什么值得花时间试前两步？因为直达搜索的结果页和站点首页之间的体验差距很大。用户点一下就出结果，和点进去还要再输入一次，长期高频使用下，前者省下的操作次数非常可观。值得为常用的几个入口多花十分钟调试参数。

注意：保存参数化的搜索地址时，把关键词部分替换成占位符，并在页面加载时用本地输入框的值填充。这样一次配置，任意关键词都能直达，比存死一个具体搜索地址有用得多。

5.3 分类膨胀后的重新整理

分类体系不是一次设计就永久的。条目增长到一定程度后，原本合理的分组会开始出现"某个分组特别臃肿、点进去要滚半天"的情况，这就是分类该重新拆分的信号。

我的拆分触发条件是：任一分组内条目超过二十五个。超过就考虑把该组内出现频次最高的三到四个标签升格为独立子组。这个阈值是经验值——二十五个条目在单列布局下大约要滚动近两屏，超过这个量，用户会开始用本地过滤框代替浏览，而一旦开始靠搜索找入口，分类的意义就被削弱了。

重新拆分会带来一次性的心智负担，用户（包括自己）要重新熟悉位置，所以不宜频繁。我一般把拆分和季度淘汰合并在一起做，一年最多两到三次，每次做完在页面顶部留一句变更说明，持续两周后撤掉。

5.4 常见问题速查

5.5 几个不写在任何文档里的实操心得

最后说几条纯经验性的东西，都是我维护过程中慢慢摸出来的。

第一条，别在页面里放统计代码。导航页是给自己用的工具，任何额外的网络请求、脚本加载、数据上报，都会拖慢首屏速度。这类页面的价值全在"打开就快"，速度掉一点，使用意愿就掉一截。

第二条，数据文件和页面文件放在一起，用同一个版本管理。这样任何一次修改都是可回退的，误删了一批条目也能找回来。导航页的改动看着小，但条目多了之后，误操作导致的损失不小。

第三条，给每个入口都写备注，哪怕当时觉得没必要。备注的写法没有标准，可以写限制、写特点、写使用场景。我现在的备注里甚至还写了一些"这个入口在什么情况下比另一个更好用"，这类信息在半年后价值极高，因为那时你可能已经忘了当初为什么把它放进来。

第四条，分类名称用动词或场景，不用名词。比如"找素材"就比"素材资源"更容易让人立刻对应到使用场景。名词是描述,动词是触发,导航页需要的是触发。

第五条，定期把整个页面当成陌生人来用一遍。具体做法是清空"最近使用"记录，然后假装自己什么都不知道，从头找三个东西试试。这个过程通常能暴露一些自己已经习惯但实际上很绕的路径。我每隔半年做一次，每次都能发现两三处需要调整的地方。

第六条，不要追求一次性做完。导航页是个长期演进的工具，第一版有二十个入口、分类粗糙，完全够用。真正让页面好用的是后面的持续调整——加一个、删一个、改一个标签，都是在打磨。追求一上来就设计完备，反而容易在细节上纠结太久，最后不了了之。先有个能用的版本，用起来，问题会自己浮出来。

我个人的体会是，这类工具型页面的价值不在于它包含了多少入口，而在于它替你省掉了多少次"想不起来该去哪查"的停顿。每次少想三秒、少点两下，一年累积下来就是相当可观的时间。而维护它的成本其实很低，每季度花两个小时做一次检查和整理就够了。真正难的不是技术实现，是克制住"再加一个"的冲动，让页面始终保持在"够用且清爽"的状态。