三个月写了一百二十篇，自然流量是零
去年秋天，一个做技术博客的朋友找我。他从七月开始坚持每两天发一篇，到十月一共写了一百二十多篇，内容不算水，都是他自己踩过的坑。GSC 里显示「已编入索引」的页面有九十多，但三个月累计点击是 41 次，其中大半是他自己搜标题的时候点的。
他问我：是不是内容还不够多？是不是要再写两百篇？
我看了他的站点结构，发现问题根本不在数量上。他的每篇文章都能从首页到达，页面速度也正常，但有一件事从头到尾没做：每一篇都在回答一个「谁都不会去搜」的问题。比如他写了一篇《我为什么把备份脚本从 bash 改成 Python》，标题里全是个人叙事，没有一个人会把这个词组输入搜索框。
这种情况在「每日更新」的内容站上极其普遍，而且越勤奋越明显。因为每天要交稿，最省力的写法就是写「今天我做了什么」，而搜索引擎不关心你做了什么，它关心的是「有人在找什么，你的页面是否是最佳答案」。
这篇文章讲的是从关键词到选题之间的那一段路，也就是我认为个人站长最容易省掉、但收益最高的一步。
先把三种搜索意图分开
做关键词的第一步不是找词，而是分类。同一个词，用户想要的东西可能完全不同。业界通常分三类，我按自己的理解重写一遍：
第一类，知道型。用户想弄明白一件事，比如「为什么 MySQL 会选错索引」。这类词的流量大，但商业价值低，用户看完就走。个人技术博客最适合做这一类，因为你有真实的踩坑细节，比官方文档更具体。
第二类，操作型。用户想完成一件事，比如「certbot 续期失败怎么解决」。这类词流量中等，但意图极强，转化率高，是技术博客最该抢的地盘。
第三类，交易型。用户想买或想选，比如「最好的 CDN 服务商」。这类词竞争激烈，个人站基本没机会，除非你有真实的横向评测数据。
我那朋友的一百二十篇文章里，第一类和第二类加起来不到十篇。这就是问题的全部：他不是写得不够多，是写的东西没人搜。
词从哪里来：四个不花钱的来源
找词不需要工具，至少起步阶段不需要。我常用的四个来源，按可靠性排序：
第一，你自己的搜索历史。这是最被低估的来源。你上个月为了解决某个问题，在搜索引擎里输入过什么？那些词一定还有别人在搜。把它记下来，就是最真实的选题清单。我现在的做法是开一个纯文本文件，每次在搜索引擎里输入超过五个字的问题，就复制进这个文件。
第二，服务器日志里的站内搜索。如果你的站有搜索框，日志里会有用户输入了什么。这些是「已经在你的站点上、但你没满足」的需求，转化率比外部词更高。提取方法很直接：
grep -oE 'GET /search\?q=[^ &]+' /var/log/nginx/access.log \
| sed 's/.*q=//' \
| python3 -c "import sys,urllib.parse,collections
c=collections.Counter(urllib.parse.unquote(l.strip()) for l in sys.stdin)
print(c.most_common(20))"跑出来的前二十个词，如果其中有任何一个你还没写过专门的文章，那就是下周的选题。
第三，竞品站点的分类与标签。不是抄标题，而是看他们有哪些分类下有大量文章。分类密集说明这个方向有持续需求。你只需要看「他们写了十篇以上的方向」，而不是他们具体写了什么。
第四，搜索引擎的自动补全与相关搜索。在搜索框里输入一个核心词，看下拉提示。这些提示是真实查询的高频组合，而且会自动带上「怎么」「为什么」「失败」「解决」这类修饰词。相关搜索在结果页底部，同样免费。
这四个来源足够撑起半年的选题。工具的作用是验证，不是发现。
长尾词的判断标准：三个数字
找到一个候选词之后，怎么判断值不值得写？我只看三个数字，全部能从搜索结果页直接看出来：
第一个，结果数量级。搜索结果页顶部显示的「找到约 X 条结果」。这个数字不准，但量级有意义。十万以下的词，通常有真实机会；百万以上，基本是红海。
第二个，首页前十里有多少是「专门讲这个」的页面。如果前十名里有六七个是专门的教程文章，说明这个词的意图很明确，值得做；如果前十名全是论坛帖子、问答、百科词条，说明没有人为这个词写过正经内容，这反而是机会——只要你能写出一篇结构完整的长文，很容易排上去。
第三个，首页内容的更新时间。如果前十名里有五篇是三年以前的内容，说明这个领域竞争者在放弃，你的新文章有优势。反过来，如果全是两个月内的新文章，说明有一批人在抢，你要么写得更好，要么换个更细的角度。
三个数字都不需要工具，人工看十分钟就有结论。我给自己定的规矩是：每一次判断不超过十分钟，超时就换下一个词。因为判断本身的成本必须低于写作成本，否则会陷入「研究了三十个词，一篇没写」的状态。
标题要包含词，但不能只是词
确定了词，下一步是标题。这里有一个非常常见的错误：把关键词原样塞进标题，写成一个像商品名的短语，比如《MySQL 索引优化》。这类标题的问题是，它在搜索结果页里没有任何区分度，用户看了不知道你能提供什么。
我的写法是「具体场景 + 核心词 + 结果或方法」，通常控制在二十五个汉字以内。第三批发布的几篇文章就是这么定的：《配置了gzip却没生效：三层缓存与压缩链路排查》，核心词是 gzip，场景是「配置了但没生效」，方法是「三层排查」。这种标题同时满足两个条件：包含搜索词，并且让用户知道这篇文章能解决他的具体状态。
还有一个细节值得注意：标题太长会被主题截断，而截断通常发生在搜索结果的展示上。这不是猜测，是实测过的事——库里的标题是完整的，页面上显示的只有前半截。所以我现在的硬性规矩是标题不超过二十五个汉字，超了就把限定语挪到正文第一段。
另外，冒号后面的部分往往比前面的部分更重要。前半段应该包含搜索词，后半段应该包含差异化。写反了，用户会看到「某某优化实战：MySQL 索引」，没有任何吸引力。
正文结构：先给答案，再讲过程
技术博客最容易犯的第二个错误是「按时间顺序写」。也就是「我先做了 A，然后发现 B，最后解决了 C」。这个顺序对作者是自然的，对读者是折磨的，对搜索引擎也不友好——因为核心答案埋在了第三屏之后。
我现在的结构固定成四段：
第一段，现象与结论。开头两三句话把问题和答案一起说完。比如「图片全挂了但直接访问是好的，原因是防盗链规则漏了 none」。让读者在前两屏就得到答案，哪怕他马上离开，也算一次有效点击。
第二段，原理拆解。为什么会出现这个现象，涉及哪几层机制。这一段决定文章的专业度，也是搜索引擎判断「是否是最佳答案」的主要依据。
第三段，可操作的具体步骤。带命令、带配置、带输出。这一段是读者真正会复制走的部分，也是最容易被其他站点引用的部分——被引用本身就是最强的外链来源。
第四段，边界与判断。什么情况下这个方法不适用，什么情况下应该换方案。这一段是被大多数人省掉的，但它是「有经验的人写的」和「拼凑的」之间最明显的区别。
按这个结构写，一篇文章大概两千到三千字，正好覆盖一个具体问题的完整闭环。再长，读者会分心；再短，多半是因为跳过了原理解释。
内链不是装饰：每篇至少三条有方向的链接
最后一件事，也是我那朋友完全没做的：内链。
他的文章之间几乎没有链接，除了主题自动生成的「上一篇/下一篇」。而「上一篇」是按发布时间排的，与内容相关性无关。结果是每篇文章都是一个孤岛，搜索引擎抓到一篇之后，没有任何理由继续抓下一篇。
我的做法是每篇成稿时，手动加三条内链，方向是固定的：
第一条指向同一问题的前置知识。比如写挂载选项，就链到写分区与文件系统的那篇。让读者有继续读的路。
第二条指向同一问题的后续发展。比如写证书续期失败，就链到写 HTTPS 部署的那篇。
第三条指向一个相关但不同的方向。比如写 Nginx 防盗链，就链到一个讲 CDN 缓存键的页面。这条用于打通不同主题簇。
加内链的成本很低，每篇多花五分钟。但它带来的收益是复利的：随着文章数量增长，每一篇都在给其他篇目投票。一个只有五十篇但内链完整的站点，抓取效率和收录率通常好过一个有两百篇孤岛的站点。
顺带一提，内链的锚文本应该包含目标页的核心词，不要写成「点击这里」。这不仅对搜索引擎有意义，对读者也是——读者能从上文判断出点进去会看到什么。
索引之后还有很长的路
做完上面这些，页面被收录只是第一步。收录到有排名、有排名到有流量、有流量到有停留，每一段都需要时间和调整。我那朋友改完选题方向的第三个月，点击从 41 涨到 380 左右，不算爆发，但至少说明这条路是通的。
他原来那一百二十篇也没有白写。有几篇被重新打造成了教程结构，标题改成包含真实搜索词的写法，反而成了现在流量最好的页面。存量内容不是沉没成本，它只是缺一个有人会搜的标题和一个清晰的结构。
如果让我用一句话总结这件事，大概是：写博客最难的不是写，而是决定写什么。每日更新的纪律很重要，但每一个选题都问一句「这是一个有人会搜的问题吗」，比多写一百篇更有效。