被降权的页面，多数不是被"惩罚"了
今年三月，一个内容站的自然流量在两个星期里掉了四成。老板的第一句话是"是不是被算法惩罚了"，第二句是"要不要去买外链救回来"。我先把 Search Console 的数据按页面拆开看，结论很快就出来了：不是整站掉，是其中 60 多个页面单独掉了，其余页面基本没动。整站被惩罚的形态是全面下跌，而单页面的集体下滑，通常是别的原因。
这一点判断错了，后面所有动作都会错。把"页面级降权"当成"站点级惩罚"处理，你会去申请复审、去清理可疑外链、去重写全站文案，花三个月做正确的事，但解决不了那个具体问题。
这篇文章讲的是单页面排名下滑的排查次序：先确认是不是真的掉了，再区分"排名掉了"和"展示掉了"，然后按"页面自身、站内结构、技术层、外部信号"四条线依次排除，最后给出多页同时下滑时怎么找共性原因。前提是站点有 Search Console 或百度站长平台的权限，能拿到按页面的点击、展示、平均排名。
一、先确认掉的是不是真的
数据上的"掉"有三种假象，如果不先排除，会把大量时间浪费在不存在的问题上。
假象一：数据延迟。 Search Console 的数据有 2 到 3 天的延迟，而且统计窗口是按"页面被爬取的时间"归集的，不是按用户访问时间。所以「昨天改了标题，今天掉了一半」这种因果判断基本不成立，至少要等一周再看。
假象二：统计口径变化。 展示量（impressions）会因为你排名上升而暴涨，也可能因为你排名稳定但竞品大量新增内容而摊薄。如果点击掉了、展示也掉了，但是平均排名没变，那多半是需求本身在下降，比如季节性的词、或者一个热点事件的搜索量退潮。这种情况做任何技术优化都没用。
假象三：筛选条件。 看数据时选了"网页"维度之外的其他维度（比如"查询"维度），会看到完全不同的形状。排查单页面必须固定到「网页」→「具体 URL」，然后再叠加时间对比。
确认真掉了的判据是三条同时成立：同一 URL 的点击下降超过 30%，持续两周以上，并且展示量下降幅度小于点击下降幅度。第三条是关键——展示掉得比点击少，说明你还在被展示，只是位置后移了（排名掉了）；如果展示和点击同步下降，更可能是需求消失或者页面被移出索引。
# 用 GSC API 拉单页面 90 天的按日数据做趋势对比
# 需要 service account 的 JSON 与站点权限，查询维度设为 page
curl -s -X POST \
"https://searchconsole.googleapis.com/webmasters/v3/sites/sc-domain%3Aexample.com/searchAnalytics/query" \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"startDate":"2026-02-01","endDate":"2026-04-30",
"dimensions":["date"],"dimensionFilterGroups":[{"filters":[
{"dimension":"page","operator":"equals","expression":"https://example.com/1234.html"}]}],
"rowLimit":100}' \
| python3 -m json.tool | head -40二、第二步：分清"排名掉了"还是"页面没了"
这一步用一条命令就能分。如果页面已经不在索引里，所有排名讨论都没意义，先去修收录。
# 1. 页面是否可访问、返回什么状态码
curl -s -o /dev/null -w "code=%{http_code} bytes=%{size_download} time=%{time_total}" \
"https://example.com/1234.html"
# 2. 是否被 noindex
curl -s "https://example.com/1234.html" | grep -oiE '<meta[^>]*robots[^>]*>'
# 3. robots.txt 是否拦住了它
curl -s "https://example.com/robots.txt"
# 4. 首字节时间：慢到一定程度爬虫会降低抓取频率
curl -s -o /dev/null -w "ttfb=%{time_starttransfer}" "https://example.com/1234.html"四种结果对应四种处置：
- 404 / 410：页面真的没了。查 Nginx 日志里这个 URL 的历史状态码，看是什么时候开始 404 的（改版、误删、伪静态规则变更是三大原因）。
- 200 但带
noindex：模板层被批量加了 noindex。这类事故在"防重复内容"的改动里最容易发生，因为规则写得太宽，把正常文章也套进去了。 - 200 但 robots.txt 拦了：注意这条在 GSC 的"已排除"里显示为"已被 robots.txt 屏蔽"，但爬虫连页面都抓不到，也就看不到页面上的 canonical 和 noindex。
- 200 但 TTFB 超过 1.5 秒：爬虫的抓取预算会被压缩。这条不直接导致降权，但它会让"新内容被发现"和"旧内容被重新评估"都变慢，间接造成排名波动。
还有一种状态是 200 但内容已经变了。用 Wayback Machine 或者你自己留的备份，把现在的正文和三个月前的版本对一遍。我遇到过一次"排名掉了 70%"，最后发现是发布流程里一个替换脚本把正文里所有段落序列改了——文章还在，但搜索引擎认为内容已被大幅替换，重新评估了它的价值。
三、页面自身：内容质量是被重新评估的最主要原因
如果页面正常在索引里、排名却持续后移，最可能的原因是搜索引擎对这篇内容的价值评估变了。这不是"惩罚"，而是"重新打分"。
具体判据有三组，我一般按这个顺序看：
第一组，搜索意图是否变了。 把你目标关键词现在的搜索结果前十条拉出来看一遍。如果三年前这个词的头部结果是"教程类长文"，现在全是"工具页"和"视频"，那说明用户意图变了，你的长文不再是这个查询的最佳答案。这种情况改标题、加段落都没用，得考虑换一个更具体的长尾词，或者补一段"工具入口"式的内容。
第二组，内容是否与同站其他页面重复。 这是内容站最容易踩的坑。同一主题写过几篇（比如"备份方案"写了三次），搜索引擎会挑一篇保留，其他的降权。用站内搜索找出这些候选，再决定合并还是加 canonical。判断重复不重复，看的是"正文前 200 字的相似度"和"小标题结构是否一致"，不是看标题像不像。
第三组，页面有没有"缺陷"。 我把缺陷分成四类：正文过短（去掉导航和广告后不足 800 字）、关键信息缺失（一篇文章全在讲概念、没有一个可执行步骤）、页面有大量死链、正文里嵌了失效的外部资源。这四类里任何一类，都足以让一个原本排第二的页面掉到第二页。
一个常被忽略的信号：页面被其他站引用的情况。不是看外链数量，而是看有没有权威站点的链接。如果原来有几个外链，现在都撤了（对方改版、站点关闭），这个页面会明显下滑。用 Search Console 的"链接"报告或者外部工具核对一下引荐域名列表有没有变化。
四、站内结构：内链被改动是最隐蔽的原因
这一条我放在第三位，是因为它的隐蔽性最高，而修复成本最低。
一个页面能排上去，很大程度上靠的是站内有多少链接指向它、这些链接的锚文本是什么。如果改版时导航结构变了、相关文章模块的推荐算法变了、或者标签页被删了，这个页面的内链数量可能在不知不觉中从 30 个降到 3 个。
检查方法：直接抓站内链接图谱，不用任何工具。
# 抓首页 + 最近 20 个列表页，统计指向目标 URL 的内链数
TARGET="/1234.html"
for p in "" 2 3 4 5 6 7 8 9 10; do
curl -s "https://example.com/${p:+page/$p/}"
done | grep -o "href=\"[^\"]*\"" | grep -c "$TARGET"
# 看锚文本是什么（决定这个链接对该关键词的权重）
for p in "" 2 3; do curl -s "https://example.com/${p:+page/$p/}"; done \
| grep -oE "<a [^>]*href=\"[^\"]*${TARGET}\"[^>]*>[^<]{2,40}</a>" | head -10如果内链从几十个掉到个位数，处置顺序是：先在"相关文章"模块里把这篇加回去，再检查标签页是否还在（标签聚合页是一个页面获得内链的重要来源），最后看侧栏的"热门文章"是不是被改成了只按时间排序——只按时间排序会让老文章彻底失去内链入口。
另一个结构性问题：URL 变更没有做 301。很多站在换 URL 结构（比如从 /archives/123.html 换成 /123.html）时，只改了新页面，旧地址返回 404。搜索引擎会把旧地址积累的权重丢掉，新地址从头开始积累。如果你不确定有没有做过跳转，抽查几条老 URL 看返回码。
五、技术层：四个容易造成"局部掉权"的配置
前三条是内容与结构，这一条是技术。它们共同的特点是：影响一批页面而不是一篇，所以一旦发生，掉的往往是一整片。
1. canonical 指错了。 模板里写死了 canonical 指向首页或者分类页，会让所有文章都被当成"副本"。判据是 curl 那一篇，看 rel="canonical" 的 href 是不是自己。这条在"给分页加 canonical"的优化里最容易写错——分页页的 canonical 应该指向自己，不是指向列表第一页。
2. hreflang 配错或者缺失。 如果站点有中英双语或者简繁两版，两个版本互指的关系必须有。单向 hreflang（A 指向 B、B 不指向 A）会被忽略，等于没配。这类问题在"从单语言站改成双语站"的站上普遍存在。
3. 结构化数据报错。 文章页的 Article schema 里如果 datePublished 或 author 缺失，搜索结果不会显示富媒体摘要，点击率会明显下降。这会让"展示量没变、点击掉了"——容易被误判成内容问题。
4. 移动端可用性。 现在的排名基本以移动端为准。如果页面在手机上出现了正文被遮挡、横向滚动、按钮太小，移动端的排名会掉，而你在桌面浏览器里完全看不出来。用 GSC 的"移动设备易用性"报告看，或者直接用手机打开那一篇。
# 一次性看一篇页面的四项技术指标
B=$(curl -s "https://example.com/1234.html")
printf '%s' "$B" | grep -oiE 'rel="canonical" href="[^"]*"'
printf '%s' "$B" | grep -oiE 'hreflang="[a-zA-Z-]*"'
printf '%s' "$B" | grep -oiE 'application/ld\+json' | wc -l
printf '%s' "$B" | grep -oiE '<meta name="viewport"[^>]*>'第二个命令返回 0 条而站点确实有多语言版本，就是缺失。第四个命令必须能抓到 width=device-width，缺了它手机端会按 980px 渲染再缩放，正文会变得极小。
六、多篇同时下滑：找共性，而不是逐篇救
回到开头那个案例。60 多个页面在两星期内一起掉，逐篇分析是徒劳的，正确做法是把这 60 个页面放在一起找共性。我用的三个切分维度：
- 按发布时间：是不是集中在某一段时间发布的？如果是半年前某个批次的文章，那可能是那个批次的模板或内容生成方式有问题。
- 按页面类型：是文章页、标签页、还是某个系列页？如果是标签页，那大概率是标签聚合页被判成了低质量页面，整片降权。
- 按目标关键词：是不是都围绕同一组词？如果都围绕"某某教程"，说明这个词的结果集被重新排序了，头部被更强的站点占了，你的位置只是自然后移，不是被罚。
那次案例的结论是第二个维度：掉落的页面都是某次改版后被加进"相关推荐"模块的页面，而这个模块在改版时把 nofollow 加在了所有链接上。内链权重瞬间归零，一批页面同时下滑。找到共性之后，修复动作只有一个：去掉那个 nofollow。 两周后大部分页面的排名回来了。
所以面对多篇下滑，最有价值的问题不是"这一篇怎么了"，而是"这一批有什么共同点"。这一点如果搞反，你会花几十个小时逐篇改内容，最后发现改完毫无效果。
七、恢复期的现实预期与不要做的事
修好之后，恢复一般不是立刻发生的。搜索引擎需要重新抓取、重新评估，这个周期从两周到两个月不等，取决于站点的抓取频率。用 GSC 的"网址检查"手动请求重新编入索引可以加快一轮，但它不保证排名回来。
恢复期里有三件事最好不要做：
不要连续改标题。 每次改标题都会触发一次重新评估，如果你一周改三次，每次评估还没稳定就被打断，排名永远在波动，你也没有稳定的数据可用来判断哪次改动有效。改一次，等两周。
不要为了"救"页面去买外链。 页面级下滑的原因在站内和技术层的比例远高于外链不足。在原因没确认之前加外链，等于在错误的方向上花钱，还可能引入新的风险。
不要大量删除"看起来没流量"的页面。 低流量页面在站内结构里承担着内链和主题覆盖的作用，删掉它们会让剩下的页面也失去支撑。真要精简，先合并（把两篇合成一篇更强），而不是直接 404。
八、小结：排查次序本身就是方法
单页面排名下滑的排查，本质上是把"一个笼统的降权"拆成四类可以分别验证的问题。顺序不能乱：先确认数据不是假象，再确认页面还在索引里，然后依次看内容、结构、技术、外部信号。
乱序的代价很具体：如果你先去看外链，会发现"外链没变"这个正确的观察，但它不能排除其他三个原因，于是你会停在原地；如果你先改内容，你会改掉一个本来没问题的正文，然后失去判断的基线。
要记的判据只有一条：看展示量和点击量的下降幅度是否同步。展示掉得少、点击掉得多，是排名后移，查内容和结构；两者同步下降，是需求或收录出了问题，查索引状态和搜索意图。这一个数就能把排查范围砍掉一半。