网站结构其实只由内链决定：一个话题一个落地页

说网站结构，大多数人先想到的是一张树状图。爬虫读不到那张图 —— 它只能顺着 <a href> 走。所以能被抓取的网站结构其实只由两个决定构成：每个新页面指向谁，以及用哪几个字承载这条链接。深度几层、一页几条链、权重怎么雕，都是搭在这两件事上面的，价值小得多。

动手之前

需要两样：一份自己的 URL 清单（sitemap 就是），以及能改正文的权限。不需要先上爬虫。第一轮就拿 sitemap 和你更新最勤的那几个页面开工，因为新链接本来也是在那儿加的。

能被抓到的链接只有一种写法

Google 关于可抓取链接的文档（页面标注 2025-12-10 更新，2026-08-23 读）在格式上说得很硬：「Generally, Google can only crawl your link if it's an <a> HTML element (also known as anchor element) with an href attribute. Most links in other formats won't be parsed and extracted by Google's crawlers.」

这一句就把相当一部分现代导航排除在外了。挂点击事件的 <span>、没有 href 的路由指令、目的地只写在 onclick 里的 <a>，都在那份文档的「不推荐」一列里。它们对浏览器里的人是好用的。但在抓取这件事上它们不是链接，所以这样做出来的菜单，什么权重都传不过去。

要跑完脚本才出现的链接是个功能，带 href 的链接才是一条路。

网站结构怎么搭：一个话题一个落地页

每个话题只挑一个页面当「要排上去的那个」。同话题的其它页面全部向上链到它，锚文本写话题本身；这个页面再往下链回两三篇最深的。整套结构就这些。它比互相乱链好，是因为它在收拢而不是摊开。

1. 列话题。不是列页面类型，是列读者带着什么问题来的。
2. 每个话题指定一个落地页。两个页面都想当，那是另一个问题，先合并再谈链接。
3. 该话题的每个新页面，在正文里向上链一条，句子本来就该有那一句。
4. 落地页向下链一到两个最强的分支页，让从顶上进来的人走得到细节。
5. 把锚文本单独拎出来读一遍。这是 Google 自己给的判据。

第 5 步有明文的通过条件。同一份文档建议：「Try reading only the anchor text (out of context) and check if it's specific enough to make sense by itself.」它还直接点了名：「Click here」「Read more」，以及拿「website」「article」当锚文本。中文侧对应的就是「点这里」「查看更多」「这篇文章」。

第 2 步里那个落地页怎么定，也有个不用吵架的办法：翻 Search Console，看这个话题下哪个页面已经有曝光，就用那个，不用你觉得应该是哪个。已经有曝光说明搜索引擎已经把它和这个话题对上了，往它身上加链接是在推一辆已经在动的车。反过来，把链接全指向一个你新写的、一次曝光都没有的页面，等于从零开始说服搜索引擎换人，代价高很多，而且你还得同时管住老页面别继续抢。

分页翻过去之后，那些页面就没人链了

这一节英文版没有，因为它在中文独立站上出现得格外多。商品页只能从筛选后的列表进、博客文章只挂在「最新文章」那一屏，列表翻到第二页之后，前面那些页面在全站的 HTML 里就再也没有人链向它们了。它们还在 sitemap 里，所以后台看着一切正常。

但 sitemap 只告诉爬虫这个页面存在，没告诉它这个页面重要。这类页面就是孤岛。补法不需要重构导航：在还有链接进来的老页面正文里，加一句自然指向它的话就够了。选哪个老页面也有讲究，挑同话题里已经有人进的那个，别挑最新发的那个。下面那段命令能把这批 URL 找出来。

交付物：四列内链审计表

一页一行。写文章的时候顺手填，审计就永远不会攒成一个项目。

# 找出 sitemap 里没有任何站内页面链向它的 URL。
# 单层、粗糙，但足够把头十个孤岛页揪出来。
curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | sed 's/<loc>//' > /tmp/all-urls.txt

while read -r u; do
  curl -s "$u" | grep -o 'href="[^"]*"' | sed 's/href="//; s/"$//'
done < /tmp/all-urls.txt | sort -u > /tmp/linked.txt

comm -23 <(sort -u /tmp/all-urls.txt) /tmp/linked.txt

一页放几条链接算多

Google 没发过这个数，我们也不发。能给的是大站实际在放多少：2026-08-23 抓的 27 个可读首页里，一共 5,104 条链接，每个首页中位 165 条，其中 81% 是站内链接。这是对现状的描述，不是目标 —— 首页是全站链接最密的一页，一篇博客放 165 条没法读。

真正管用的约束是另一条：你每加一条链接，它都在和这一页上别的链接抢读者的下一次点击。读者真会点的三条，比划过去的三十条值钱。而把链接全塞进页脚区块，等于告诉 Google 它们都不属于内容。

四种做法要停掉

最后一种活得最久，因为它看起来像在干活。

• 只有跑完脚本才出现的链接，没有 href 兜底。
• 图片链接 alt 留空。Google 拿 alt 当锚文本，留空就是空锚文本。
• 同一句锚文本在不同文章里指向不同页面。等于告诉爬虫两个页面是同一个问题的答案。
• 用「相关文章」区块代替正文链接。全站三条一样的，挂在内容下面，什么也没描述。

想链到某个小节，前提是那个小节有锚点，而多数页面没有：我们自己那批样本里，967 个标题只有 69 个带 id。写 #某节 之前先确认这个目标存在。

这一章修不好的事

内链搬运注意力，不创造注意力。一个没有外链、也没有排名的站做完这一章，会得到一个更整齐的结构和一模一样的流量。这种结果常见到必须直说，而不是藏在文末。落地页本身没有竞争力的话，诚实的顺序是先修页面 —— 诊断路径从这里开始。

还有一件答不了的：单独一条内链值多少。除了 Google 没人算得出，这个效应和页面上同时改的其它东西分不开，我们也没跑过能隔离它的实验。所以上面这套结构是「弯路最少的版本」，不是一个测出来的收益。

常见问题

一个页面应该放多少条内链

没有公开的数字。用读者当约束：他有可能点的链接，放在句子本来就需要它的位置。参照值是我们量的 27 个大站首页中位 165 条，而首页是极端情况，不是范本。

锚文本对内链真的有影响吗

Google 文档说锚文本「tells people and Google something about the page you're linking to」，并给了一个判据：单独读锚文本，看还知不知道它通向哪儿。这个测试不花钱，能筛掉大部分烂锚文本。

能用 nofollow 控制站内抓取吗

Google 的指引指向别处：站内链接要挡，它点名的是 robots.txt 的 disallow 规则，不是 rel 属性。拿 nofollow 在站内雕抓取，是在绕一个 robots.txt 已经解决的问题。

页脚里的链接算不算

只要是规规矩矩的 <a href>，就能被抓取。它和正文里的链接权重是否一样，Google 没说，我们也没测过，所以我们只把正文链接当成值得认真写的那一批。