技术博客 SEO 不靠堆词：description、structured data 和归档入口要一起设计

我现在做技术站点的 SEO，已经很少从“关键词密度”开始想了。对这种长期积累型博客来说，真正决定搜索质量的，经常是另外几件更基础的事：description 写得像不像人话，结构化数据有没有最小字段，归档和最近文章入口稳不稳定，文章之间有没有形成明确的主题路径。

说白了，SEO 在这类站点里更像信息架构，不像文案游戏。

我先不允许 metadata 出现低级错误

tests/blog-content-quality.test.js 里有一条我很认同的规则：description 不能和 title 完全一样。这个检查听起来很小，但它本质上是在挡一种特别常见的懒惰写法。

比如下面这种写法就很糟：

title: 技术博客 SEO 不该只靠关键词堆出来
description: 技术博客 SEO 不该只靠关键词堆出来

它对搜索结果几乎没有额外信息量，对站内列表页也没有帮助。读者看到了标题，description 却没有补充任何预期。

我更希望 description 干的是另一件事：告诉读者“这篇文章到底会展开哪一层问题”。

title: 技术博客 SEO 不靠堆词：description、structured data 和归档入口要一起设计
description: 技术站点的 SEO 更像信息架构问题。只有摘要、结构化数据、归档入口和内链同时稳定，搜索流量才不会越来越虚。

同样是摘要，后者明显更能解释页面价值。

结构化数据最怕的不是复杂，而是缺最小字段

src/lib/blogStructuredData.js 里的逻辑很朴素，只检查三件事：

• title
• date
• permalink

少任何一个，这条内容就不该进入结构化数据列表。

我很喜欢这种保守思路。因为结构化数据不是为了“看起来高级”，而是为了告诉搜索引擎和站点自己：这是一篇有明确身份、有时间、有稳定地址的内容。如果最小字段都不齐，硬塞进去只会制造噪音。

归档和最近文章入口，本身就是 SEO 的一部分

很多人谈 SEO 只盯单篇页面，但站点真正的可发现性，常常来自列表页。

plugins/recent-blog-posts.js 会把 blog/ 目录里的内容递归读出来，整理成最近文章数据。src/lib/archiveUtils.js 则把归档数据按年月分组，生成稳定的锚点和月份标签。对读者来说，这意味着：

• 新文章可以从首页或最近文章被快速找到
• 老文章不会因为发布时间早就从系统里“消失”
• 同主题内容有机会通过归档和时间线重新被发现

这件事对搜索引擎也一样重要。一个技术站如果只有单页，没有稳定的列表组织，后面再怎么补关键词，也很难形成长期可索引的结构。

我更在意的是页面之间有没有合理关系

在 blogV2 里，我会把页面关系粗略分成四层：

1. 首页和最近文章，负责把最近发布的东西露出来。
2. 归档页，负责把旧内容按时间重新组织。
3. 标签页，负责把主题相近的内容聚在一起。
4. 文章页，负责承接具体搜索词和问题。

如果这四层之间没有清楚的连接，SEO 结果通常就会很怪：

• 新文章一阵流量，过几天就沉到底
• 旧文章没有回流入口
• 同主题文章互相不认识
• description 和页面主题对应不上，点击率越来越差

一个我更愿意使用的摘要写法

我现在写技术博客摘要时，会尽量避免这几种句子：

• “本文介绍了……”
• “本文从多个角度分析……”
• “这篇文章会带你全面了解……”

不是因为这些句式绝对错误，而是它们太容易把摘要写成模板。

我更愿意直接把读者会遇到的具体问题写出来，比如：

• 坏例子：介绍技术博客 SEO 的一些经验和方法。
• 好例子：这篇文章重点讲 description、structured data、归档入口和内链如何一起工作，避免技术站只剩单篇流量。

前者像开场白，后者像页面承诺。

关键词当然重要，但它只是最后一层

我并不是说关键词完全不重要。标题、slug、正文里的术语当然要能反映主题。但这些东西真正生效的前提，是站点已经把内容组织好了：

• 每篇文章有清楚的 title 和 description
• structured data 至少能稳定输出最小字段
• 归档和最近文章页持续提供入口
• 同一主题之间能互相跳转

这套基础结构稳定以后，关键词才不是飘在空中的词。

我对技术站 SEO 的结论

技术站点做 SEO，最不该先做的事情就是堆词。真正该先做的，是让内容对象、列表入口、摘要信息和结构化数据先变得可靠。等这些基础稳定了，搜索流量会更像系统结果，而不是偶然命中。