从一次「半年没人点进来」说起
去年秋天我做过一次流量复盘,把 Search Console 的查询词导出,按「一个月内曝光大于 200、点击小于 5」筛了一遍,结果有一百多条。全部集中在一类词上:都是三到六个字的长句,比如「nginx 站点证书过期怎么查」「mysql 连接数满了会报什么错」。这些词的排名大多在 20 到 60 名之间,曝光加起来占了全站的三成,点击不到百分之一。
当时我的判断是「排名不够高,得做外链」。现在回头看,完全错了。真正的原因是我为这些词写的页面,没有回答搜索者当时想问的问题——搜索「证书过期怎么查」的人想要的是一条能立刻执行的命令,而我给的是一篇讲证书原理的长文,正文里那句命令在第六小节。排名二十名的人不会翻到第六小节。长尾关键词的转化率从来不取决于排名,取决于「落地的第一屏是否直中意图」。这篇文章就写这件事:怎么系统地找出这批词、怎么给它们配上真正对的落地页。
先弄清「长尾」到底指什么
行业里对长尾的定义有两种,一种是「搜索量低的词」,一种是「词更长、意图更明确的词」。前者是统计结果,后者才是可操作的对象。因为一个词搜索量低可能有两个完全不同的原因:需求本身很小,或者需求被分散到了几十种说法里。后者才是金矿——总量不小,但每个具体说法只有几十次搜索。
| 类型 | 例 | 月搜索量 | 说明 |
|---|---|---|---|
| 核心词 | mysql 优化 | 数千 | 竞争极强,个人站基本无望,且意图模糊 |
| 中长尾 | mysql 索引失效 | 数百 | 可竞争,但已被大量文章覆盖 |
| 长尾(真金) | mysql 用函数包住索引列 会走索引吗 | 几十 | 意图极其明确,写对就能稳定拿住 |
| 长尾(伪金) | mysql 为什么慢 | 几十 | 看似长,其实意图散,落地页写什么都行=都不行 |
判断标准是「这个词背后的人,是不是只想要一个答案」。上面最后一行是典型的伪长尾:词长,但提问者是新手,他自己都不知道自己在问什么,你给什么他都可能不满意。真正的长尾金矿有一个特征——你能不假思索地说出他要的答案是什么形状:一条命令、一段配置、一个数字、一张对照表。
四个零成本找词来源,按性价比排序
我不买词库,也不装付费工具。下面这四个来源全部免费,而且比第三方工具更贴近你自己站点的真实状况,因为前两个用的是「发生过的事」,不是「可能发生的事」。
一、Search Console 的查询词表,按「有过曝光但排名很差」筛
这是最值钱的来源,因为它告诉你搜索引擎已经把你的站点理解成能回答这个问题,只是你的页面没答好。筛选逻辑是:曝光 > 100、平均排名 > 15、点击率 < 2%。这三个条件同时满足的词,就是「你有资格但没拿到」的词。
导出的 CSV 有两个坑。第一,界面单次导出有行数上限,如果站点收录页面多,要按时间分段导,别指望一次导完。第二,平均排名是按曝光加权的平均值,一个词排在第 4 名和第 40 名各曝光一次,平均排名会是 22——看起来很难看,实际你已经拿到了一个第 4 名。所以别只按平均排名筛,还要看这个词的「排名波动」,GSC 里点进去能看到 3 个月曲线,稳定在 20 名上下与在前五和后五十之间跳,是两种完全不同的机会。
二、站内搜索日志
这个来源几乎没人重视,但它的数据质量极高——有人在你站上找某样东西却没找到,这本身就是最强烈的需求信号。做法很简单:
# 假设搜索页是 /search?q=xxx,access.log 是 combined 格式
cat /var/log/nginx/access.log | awk -F'"' '{print $2}' \
| grep -o 'q=[^& ]*' | cut -d= -f2 \
| python3 -c "import sys,urllib.parse
from collections import Counter
c=Counter(urllib.parse.unquote(l.strip()) for l in sys.stdin if l.strip())
for k,v in c.most_common(30): print(v,k)"
注意两点:URL 是编码过的,必须 unquote;cat | awk 对百万行日志也能撑住,不要一开始就上 Python 逐行解析。跑出来的前三十个词,如果其中有「搜了但没结果」的,那些词对应的文章就是你的下一篇选题。
三、搜索引擎的下拉补全与相关搜索
这一层信息是「别人还在搜什么」,它的价值不在于给你推荐同义词,而在于告诉你这个词的用户通常会往下追问什么。搜索一个核心词,下拉框里出现的那些长句,往往就是同一个人的下一步疑问。
手工做十几次就够,不建议写爬虫——这类接口对频繁请求很不友好,而且你一天也只需要十几个候选。方法:输入核心词,记下下拉框全部内容;再输入核心词加空格加 a 到 z,每个字母补全一遍,你一次就能拿到一两百个真实长尾。这一步十分钟能做完。
四、你自己的技术笔记与聊天记录
最被低估的一个来源。你踩过的坑、给别人解释过的问题、在群里回答过三次以上的东西,都是现成的选题,而且天然符合「有明确答案」这个标准。我现在的做法是维护一个纯文本文件,凡是「同一个问题被问到第二次」就记一行,月底整理一次。这个文件里的条目比任何词库都更值得写,因为它们是从真实困惑里长出来的。
判断一个词值不值得写:三分钟三个问题
找词不难,难的是一天找出五十个词结果写了五十篇没人看。我给自己定了一个三分钟的判断法,三个问题过关才动笔:
- 搜索一下这个词,前十名里有几篇是「专门回答这个问题」的? 如果前十全是论坛帖、问答页、文档片段,说明没有像样的教程,这是最理想的情况。如果前十全是同质化的 SEO 聚合页,那也说明竞争者的质量很低,你写一篇干货就能挤进去。最怕的是前十全是知名博客的深度长文,那就放弃。
- 这个词的搜索结果里,有没有「官方文档只讲一半」的情况? 有的话你有巨大的操作空间——官方讲原理,你讲「怎么在你的场景里用」,这是最典型的内容机会。
- 你能不能在三分钟内想清楚这篇的「答案形状」? 想不出来就别写。想得出来但需要大量实验数据才能写的,优先做,因为这种别人抄不走。
这套判断法的核心是判断成本必须低于写作成本。我一开始用的是很复杂的打分模型(搜索量、竞争度、商业价值、难度加权),结果是判断一篇要半小时,写一篇要一小时,最后我干脆不判断了。三分钟能出结论的方法才有资格进入日常流程。
落地页怎么写:长尾文章的固定骨架
长尾词的价值在「精准」,所以落地页必须让搜索者在第一屏就确认「这是我要的」。我现在所有长尾文都用同一个四段结构:
| 段落 | 位置 | 内容 | 长度 |
|---|---|---|---|
| 现象与结论 | H1 之后第一段 | 先复述用户遇到的症状,然后立刻给结论 | 100~200 字 |
| 可操作步骤 | 紧接着 | 命令、配置、代码,能复制粘贴 | 视内容 |
| 原理 | 中段 | 为什么这样做,讲清机制 | 主体部分 |
| 边界判断 | 结尾 | 什么情况下这个答案不适用 | 100~200 字 |
这个顺序与常见的「先讲背景、再讲原理、最后讲结论」正好反过来,理由是长尾搜索者的耐心只有十几秒。他已经在别的地方看了一堆背景,来你这里是要一条能用的命令。如果第一屏看不到,他就会回退重搜。
一个具体的改写例子。原来我写「Nginx 证书过期怎么查」,开头是三段「HTTPS 的重要性」和「证书链的原理」,那篇文章的点击率是 0.4%。改版时我把开头换成:
<p>查证书剩余天数,不用等浏览器报警,一条命令:
<pre><code>echo | openssl s_client -servername www.example.com \
-connect www.example.com:443 2>/dev/null \
| openssl x509 -noout -enddate</code></pre>
输出 notAfter 就是过期时间。如果显示的是「昨天」,说明已经过期;
如果显示的时间比你现在的时间还早很多,先检查服务器时钟。</p>
同一篇文章,只改了开头的第一屏,两个月内这个词的点击率从 0.4% 涨到 6.8%,排名基本没动。排名不变、点击翻十倍,这就是第一屏直中意图的威力。
标题怎么写:把长尾词放进去,但别照抄
长尾词本身往往就是一句提问,直接拿来做标题有两个问题:一是太长,超过 25 个汉字会在搜索结果里被截断;二是太像提问,读起来不像一篇文章。
我的写法是「具体场景 + 核心词 + 结果」,控制在 22~26 个汉字。比如:
- 核心词「mysql 索引失效」,写成「索引明明建了却不走:三个隐蔽原因」。
- 核心词「nginx 证书过期」,写成「证书过期前七天:自动检查与告警脚本」。
- 核心词「服务器磁盘满」,写成「磁盘写满但找不到大文件:deleted 句柄排查」。
这样做的目的是:既包含搜索者会输入的关键词(搜索引擎能匹配上),又不像一个提问(人是会点开一个「有信息量的标题」的)。同时标题不能写死一个长句当 H1,H1 应该是完整标题,但正文第一段要自然复述那个搜索词——不是为了堆砌,而是让读者确认「找对地方了」。
内链:长尾文章的流量放大器
长尾文章有一个天然缺陷:单篇流量小。要让它们形成合力,靠的是内链。我给自己定的三条固定方向:
- 前置:这篇是某个大主题的细分,在正文里链回那个大主题的聚合页或核心文章,锚文本用具体词而不是「点击这里」。
- 后续:这篇解决完之后用户会遇到的下一个问题,链到对应文章。比如「证书怎么查」的下一篇是「证书怎么自动续期」。
- 旁支:同一层级的相邻问题,比如「查证书」旁边是「查服务器时间」。这条最容易漏,但对形成主题簇帮助最大。
内链还有一个容易被忽略的作用:它决定了爬虫发现这篇新文章的速度。新文只挂在列表页第一页,一周后就被新文挤到第二页,如果没有任何正文链接指向它,它的抓取频次会很快掉下来。我现在的做法是发布时立刻在 2~3 篇相关老文的正文里加链接,这一步花三分钟,收益远大于去外部发十个帖子。
别做的几件事
最后列几个我在长尾上踩过、并且看到很多人还在踩的坑:
- 别为一堆近义词各写一篇。「mysql 索引失效」「索引不生效」「索引没走」是同一个意图,应该写一篇覆盖全部说法,而不是三篇互相竞争。后者的直接后果是自我稀释——搜索引擎会在这三篇里挑一篇,另外两篇被判定为重复内容。
- 别在长尾文里写太多个人叙事。我早期很喜欢用「上周有个朋友问我」开头,写了三段才进正题。这类开头在公众号有效,在搜索落地页无效,因为搜索者不是来听故事的。
- 别为了长尾词硬凑一篇。如果一个词你确实没有独特的经验,写出来的就是网上那些内容的转述,这类文章长期看是负资产——它占用了站点的抓取预算,还不带来点击。
- 别只看一个月的排名变化。长尾词的排名波动极大,一个词这个月 12 名下个月 35 名是常态。判断一篇文章是否有效,应该看三个月的累计点击,而不是每周的名次。
收尾:把长尾当成一个持续的系统
我现在每季度做一次固定动作:导出 GSC 查询词,筛出「高曝光低点击」,取前二十个,逐个问那三个判断问题,挑出一半来改进落地页或重写。这个动作半天时间,比写新文章划算得多——因为那些词已经有排名、有曝光,只差一个能让人点进来的第一屏。
换句话说,长尾关键词的运营不是「找更多词」,而是「把已经找到你的那批人留住」。前者需要运气,后者只需要一点耐心。