一、导航不是菜单，是站点结构的外化
很多个人站的导航栏是这么来的：先挑几个自己觉得重要的栏目，平铺上去；后来发现分类太多，又往里面塞二级菜单；再后来栏目改过名，旧链接还留着，导航里就出现了「教程」「技术教程」「技术文章」三个指向类似内容但路径不同的入口。
这不是审美问题，而是结构问题。搜索引擎对站点的理解，很大程度上来自你给出的链接结构：哪个页面是主干、哪些页面是分支、哪些页面只是补充。导航是你唯一能明确表达这套层级的地方。导航混乱，爬虫分不清谁是主要内容，用户也找不到路。
导航的根本作用是回答三个问题：这个站是讲什么的、内容分成哪几块、我现在在哪一层。三个问题都答清楚了，导航就算合格；答不清楚，做得再好看也只是装饰。
二、主页、栏目页、文章页：三层不能再多
个人站的信息量通常撑不起四层以上的结构。我见过最夸张的例子是：首页 → 技术 → 教程 → 数据库 → MySQL → 某篇文章，六个层级。用户点到那篇文章要五下，爬虫的抓取深度也跟着变深，权重被一层层稀释。
我采用的结构是固定三层：
第一层，首页。只做一件事：告诉访客和爬虫这个站最核心的六个到八个栏目是什么，以及最近更新了什么。首页不应该承载全部内容入口，那是目录页的职责，不是首页的。
第二层，栏目页。每个栏目对应一个真实的内容主题，比如「服务器运维」「SEO 教程」「性能调优」。栏目页必须有独立的价值，不能只是「文章的倒序列表」。它应该有栏目说明、核心文章的精选入口、以及能被搜索到的栏目级关键词。
第三层，文章页。文章页通过面包屑回到栏目，通过相关阅读和上下篇互相连接。文章页不应该再往下分「第四章第一节」这种层级，那属于文章内部的标题层级，不是 URL 结构。
三层住的结构有个直接好处：任何一个页面的点击深度都不超过三。爬虫的抓取预算有限，深度小的页面被反复抓取的概率高，新文章的发现速度也快。我改完结构后对比过日志，同一批新文章的首次被抓取时间从平均 4 天缩短到 1 天多。
三、栏目怎么定：按用户的问题分，不按你的技术栈分
这是最容易走偏的一步。技术出身的站长容易按技术栈分栏目：Nginx、MySQL、PHP、Docker、Linux。看着整齐，但对访客毫无意义——他遇到的问题是「网站打不开了」，不是「我想读一读 MySQL 栏目」。
按问题分，栏目会长成这样：「网站打不开」「网站变慢」「搜索引擎收录」「服务器选型」。每个栏目都对应访客脑子里的一个疑问，栏目名本身就是一句人话。
但也有例外：如果你的站已经有稳定的搜索词来源，栏目应该跟着搜索词走。比如搜索后台显示「Nginx 配置」的搜索量远大于「网站配置」，那栏目名直接叫 Nginx 相关会更容易获得点击。这时候栏目名不是给访客的，是给搜索结果的。
我的判断标准是：如果这个栏目能在搜索结果里独占一个词，就按技术栈分；如果只能吃长尾，就按问题分。一个站只有六个栏目的话，三四个按问题、一两个按技术栈，是比较平衡的配比。
四、URL 结构与导航要保持一致
导航给出层级，URL 也要给出同样的层级，否则两者会打架。最常见的不一致是：导航里文章在栏目下面，URL 却是 /archives/1234.html 这种扁平结构，或者反过来，导航是平的但 URL 有三级目录。
Typecho 默认是 /archives/{cid}/。这种扁平 URL 的好处是改分类不影响链接，缺点是看不出层级。两种做法各有代价：
扁平 URL：文章换栏目时链接不变，历史外链不会断；缺点是 URL 里没有关键词，也不体现层级。适合栏目会经常调整的站。
层级 URL：/server/nginx-compress/ 这种，URL 里有分类和关键词，对搜索有轻微加成；代价是一旦换栏目，所有旧链接都要做 301，工作量不小。适合栏目已经稳定下来的站。
我自己的选择是：文章页保持扁平，栏目页用语义化路径。这样既有稳定的文章链接，又有可读的栏目路径，改动成本也最低。
五、面包屑是导航的骨架，不是装饰条
面包屑在页面上只占一行，却是导航结构里信号最强的一环。它同时告诉爬虫三件事：当前页面属于哪个栏目、栏目在站内的位置、以及一条回退路径。
<nav aria-label="面包屑">
<ol itemscope itemtype="https://schema.org/BreadcrumbList">
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/"><span itemprop="name">首页</span></a>
<meta itemprop="position" content="1">
</li>
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/ListItem">
<a itemprop="item" href="/server/"><span itemprop="name">服务器运维</span></a>
<meta itemprop="position" content="2">
</li>
<li itemprop="itemListElement" itemscope
itemtype="https://schema.org/ListItem">
<span itemprop="name">本文标题</span>
<meta itemprop="position" content="3">
</li>
</ol>
</nav>结构化数据不保证出现富摘要，但它能帮搜索引擎确认层级关系，是无成本的加分项。注意最后一级不要加链接——那是当前页，加链接只会制造一个自己指向自己的循环。
另外，面包屑的文字要和栏目名完全一致。如果导航里写「服务器运维」，面包屑写「运维」，搜索结果的路径展示就会前后矛盾，用户看着也奇怪。
六、内链不是越多越好，而是越准越好
导航是主干，内链是毛细血管。文章之间互相链接的作用有两个：帮读者继续读下去，以及把权重分给需要排名的页面。
常见的错误做法是在文章底部自动生成「相关文章」十条，全部是同一分类下最近的十篇。这种做法的问题在于：它只按时间排序，不按相关度排序，读者点进去的概率很低，等于白白占用了十个链接位。
我的做法是三个位置，各司其职：
正文内的自然链接：提到某个概念时，如果站内已经写过，就在词上做链接，锚文本用这个词本身。这是最有效的一种，也是最需要克制的——一篇两千字的文章里放三到五个，再多就显得刻意。
文末的延伸阅读：选两到三篇真正在内容上有延续关系的文章，加一句说明为什么推荐它。有说明的链接点击率是没有说明的好几倍。
栏目页的精选：每个栏目挑三到五篇代表作，固定放在栏目页顶部。这是栏目页能获得排名的关键，也是给这些代表作集中权重的机会。
锚文本要多样化。全站都用完全一样的关键词做锚文本，看起来像刻意优化；用「这里」「点击」这种毫无信息量的词，又浪费了链接的价值。合适的做法是同一篇目标页面，锚文本覆盖它的主题词的几种自然说法。
七、标签系统：能不用就别用
标签页是导航结构里最大的坑。个人站常见的做法是每篇文章随手打五六个标签，于是产生了上百个只有一两篇文章的标签页：/tag/nginx、/tag/配置、/tag/服务器……这些页面内容单薄、互相高度相似，是典型的低质量页面。
它们带来的问题很具体：抓取预算被这些页面吃掉、站内出现大量重复内容、搜索结果里冒出「标签：配置」这种毫无吸引力的结果页。
如果确实需要标签，我的做法是：只有当一个标签下的文章超过十篇，才让它出现在导航和链接里；其余的标签只在文章页展示，并给这些标签页加 noindex。这样既保留了标签的整理功能，又不让它在搜索里制造垃圾。
# Nginx 侧给标签页加 noindex 的一种做法
location ~ ^/tag/ {
add_header X-Robots-Tag "noindex, follow" always;
}用 noindex, follow 而不是 nofollow：页面本身不进索引，但里面的链接照样能被跟进，这样文章仍能通过标签页被发到。
八、改完之后怎么验证
导航结构改完，不能只看「看着挺清楚」，要有几个能对数的检查：
点击深度检查：用爬虫工具或者自己写个小脚本，从首页出发爬三层，看有多少文章页没有被覆盖到。如果有大量文章深度超过三层，说明栏目划分有问题。
孤立页面检查：全站有内容但没有任何内链指向的页面，通常是改了分类之后旧链接没处理，或者分页生成出了问题。
重复入口检查：同一个栏目是否有两个不同路径的入口，比如 /category/server/ 和 /server/ 同时存在。这两者必须用 canonical 收敛到一个。
日志验证：改完两周后看日志里爬虫对栏目页和文章页的抓取比例。正常的站，栏目页被抓的次数应当明显少于文章页；如果栏目页被狂抓，说明分页参数过多，爬虫在翻列表。
九、小结
导航与信息架构这件事，投入很小但收益很长期。核心就三条：层级不超过三层、栏目按访客的问题来分、导航与 URL 与面包屑三者保持一致。剩下的内链和标签，都是在这三条之上做加减法。
我见过不少站内容写得很好，但因为结构乱，文章根本被人看到——不是被搜索引擎惩罚，而是它压根没找到路。把导航理顺，等于给已有的每一篇文章都修了一条进站的路，这比再多写十篇文章的性价比更高。