SEO排名下降怎么办：从关键词意图、页面匹配到百度收录验证的实战排查

先说结论

SEO 排名下降不是一个单一故障。页面可能仍然可以访问，但搜索引擎没有重新抓取；也可能已经抓取，却没有进入索引；还可能已经收录，只是查询词、页面意图、竞争页面或搜索结果环境发生了变化。先把问题定位到正确的一层，再决定是修技术信号、补内容、调整内链，还是等待数据重新稳定。

本文提供一套可以复查的排查流程，适合百度和 Google，也适合有日志、搜索平台数据和文章后台的小型内容站。文中示例不会承诺固定排名或固定收录周期；每次结论都应保留查询词、地区、设备、日期范围和页面版本。

一、先把“排名下降”定义清楚

不要只看某一次手动搜索。先从搜索平台导出至少 28 天的数据，与前一个 28 天周期比较，并把下面几种现象分开记录：

平均排名只是平台定义的汇总指标，不等于每个用户、每个地区和每次搜索都处在同一位置。排查时固定平台、地区、设备和日期范围，才能比较前后变化。先用SEO查询怎么做建立单页基线，再看本文的诊断顺序。

二、先建立一张页面基线表

对发生变化的 URL，记录以下字段。没有证据的项目填写 unknown，不要把未知直接写成“未收录”或“被惩罚”。

这张表的作用是把“感觉掉了”变成可复核的事件。若某个查询词的着陆页在周期内改变，要把改变前后的 URL 同时记录，避免把页面切换误认为排名波动。

三、按四层漏斗定位问题

1. 访问层：页面是否真的可用

先检查最终 URL，而不是只看浏览器是否偶尔能打开：

PAGE_URL='https://blog.zenleak.cn/post/307/'
curl -sS -L -D /tmp/seo-headers.txt \
  -o /tmp/seo-page.html \
  -w 'HTTP %{http_code}; final %{url_effective}; redirects %{num_redirects}; time %{time_total}s\n' \
  "$PAGE_URL"

重点看：

• 是否返回 200，以及 Content-Type 是否是 HTML；
• 是否出现多次重定向、HTTP/HTTPS 循环或主机名切换；
• 错误页是否错误地返回 200；
• 页面是否因为登录、限流、WAF 或异常耗时而无法稳定读取；
• 移动端请求是否得到另一份缺少正文的模板。

如果页面在某些时间段返回 5xx、超时或错误的 200，先修服务稳定性，再讨论内容排名。抓取日志中可按状态码、路径和响应耗时分组，方法可参考SEO访问日志分析实战。

2. 抓取层：搜索引擎能不能发现并读取

检查 robots.txt、sitemap 和站内入口是否互相一致：

curl -sS https://blog.zenleak.cn/robots.txt
curl -sS https://blog.zenleak.cn/sitemap.xml | grep -F "$PAGE_URL"

需要确认：

• robots.txt 没有误写成 Disallow: /；
• 文章详情页没有被模板规则统一禁止；
• sitemap 使用规范 URL，协议、主机名和尾部路径一致；
• 分类页、专题页或相关文章能够提供 HTML 链接入口；
• 重要正文没有只依赖点击后才执行的客户端请求。

robots.txt 是抓取规则，不是权限控制；私密内容必须使用认证和服务端权限。想让平台看到页面中的 noindex，不能同时禁止平台抓取这个页面。

3. 索引层：抓取后是否选择进入索引

“已抓取”不等于“已收录”。如果平台显示已经抓取但没有索引证据，通常要检查：

• 页面正文是否足够独特，是否只是另一篇文章的改写；
• 标题、摘要和正文是否真正回答一个明确问题；
• canonical 是否指向了另一篇页面或首页；
• 页面是否有稳定的站内入口，还是孤立 URL；
• 模板是否产生大量参数、分页或重复版本；
• 页面是否长期没有更新，且内容已明显落后。

不要通过堆砌关键词、隐藏文本或批量改写制造“新鲜度”。这些做法不能替代独特证据和清晰结构。本文涉及的 canonical、robots、sitemap 发布前检查，可以结合Django SEO 发布前检查执行。

4. 排名层：已收录页面为何位置变化

页面已经有索引证据时，再检查查询意图和竞争关系：

• 查询词是在找定义、教程、工具、价格、案例还是排错步骤；
• 当前页面是否在开头直接给出结论和适用范围；
• 标题承诺的内容是否在正文中有证据支持；
• 页面是否缺少例子、命令、限制条件或复盘方法；
• 同一站点是否有多篇页面争夺同一个主要查询词；
• 页面是否因为标题相似而在结果页互相替换。

一个页面不应同时承担互相冲突的意图。例如“SEO 是什么”适合解释概念，“SEO 排名下降怎么办”适合诊断流程，“SEO 查询工具”适合工具比较。把三种意图塞进同一页，常常会让读者和搜索引擎都难以判断页面重点。

四、先做关键词与页面映射，再改标题

为每个目标词建立一行映射：

词库中的“SEO排名”“网站优化排名”“百度 SEO 排名优化”等词有一定指数，但指数只能用于判断需求规模，不能证明某个词适合直接做首页或文章标题。先观察真实查询意图，再决定页面类型。地域词如“上海 SEO”“宁波网站优化”还需要真实服务范围、案例和联系方式；没有对应业务证据时，不要为了指数批量生成城市页面。

如果两个页面在同一个周期里争夺同一查询词，可以采用以下顺序：

1. 选择更完整、更符合意图的页面作为主页面。
2. 将另一页中独有的事实、例子或步骤合并到主页面。
3. 给被合并页面设置准确的重定向或 canonical，避免保留两个近似入口。
4. 更新站内链接，让分类、专题和文章链接指向主页面。
5. 在平台和日志中记录变更日期，至少观察一个完整周期。

文章合并的判断方法见SEO内容更新与文章合并实战，不要简单批量删除章节。

五、页面优化要围绕“可验证的回答”

标题和摘要

标题应包含页面要解决的具体问题，摘要说明适用对象、方法范围和结果边界。避免使用“终极、保证、快速上首页”等不可验证承诺。标题改动后不要每天重复修改，否则无法判断哪一次变化产生了影响。

首屏和正文结构

正文前几段应回答：问题是什么、如何判断、下一步先做什么。后文再补细节、命令、限制和例外。每个小节最好只解决一个子问题，代码、表格和清单要能独立复查。

证据与时效

涉及平台接口、额度、爬虫身份、报告字段的内容，应写明检查日期和证据来源。平台界面会变化，不要把当前界面描述成永久规则。引用官方文档时，保留链接和访问时间；无法确认的结论写成待验证事项。

图片与可读性

图片必须有实际说明价值，并使用稳定尺寸、清晰的 alt 文本和可读的图注。不要把关键文字只放在图片里，也不要让图片、代码块或表格挤压正文。页面出现图片与字体重叠时，先检查图片容器的宽高、object-fit、移动端断点和 Markdown 输出结构，再进行 SEO 判断。

六、内链修复：让主题有入口、有回路

内链不是把关键词重复塞进每一段。可以按“主题页—诊断页—执行页—复盘页”组织：

SEO 专题页
  ├─ SEO 查询：建立数据基线
  ├─ 本文：定位排名下降原因
  ├─ 站内链接审计：修复发现路径
  ├─ 内容合并：处理重复与关键词冲突
  └─ 发布后监控：观察抓取、收录和提交结果

每篇文章至少应有：

• 一个指向上级专题或分类的入口；
• 两到四个与当前步骤直接相关的文章链接；
• 一个能继续执行或验证的下一步链接；
• 不指向已合并、失效或与当前页面意图冲突的 URL。

链接文字描述目标页面，不要所有链接都写成“点击这里”。修复后可以运行站内链接审计，找出孤立文章、断链和过深页面，具体方法见站内链接审计实战。

七、用一段脚本做发布后的基础检查

下面脚本只做快速检查，正式系统应使用 HTML/XML 解析器。它不会判断收录和排名，只用于发现状态码、标题、canonical 和 robots 的明显问题：

from urllib.parse import urljoin
import requests
from bs4 import BeautifulSoup

url = "https://blog.zenleak.cn/post/307/"
response = requests.get(
    url,
    timeout=15,
    headers={"User-Agent": "seo-audit/1.0"},
    allow_redirects=True,
)
soup = BeautifulSoup(response.text, "html.parser")
canonical = soup.select_one('link[rel="canonical"]')
robots = soup.select_one('meta[name="robots"]')

print("status:", response.status_code)
print("final:", response.url)
print("title:", soup.title.get_text(" ", strip=True) if soup.title else "missing")
print("h1:", [h.get_text(" ", strip=True) for h in soup.select("h1")])
print("canonical:", urljoin(response.url, canonical.get("href")) if canonical else "missing")
print("robots:", robots.get("content") if robots else "default")
print("word_count:", len(soup.get_text(" ", strip=True)))

检查结果应回到基线表中保存。200、有 title 或存在 canonical 都只是技术条件，不能单独推出页面会收录或排名上升。

八、7 天、14 天、30 天复盘计划

第 1 天：确认问题边界

固定平台、地区、设备和日期范围，导出查询与页面数据；检查状态码、重定向、robots、canonical、sitemap 和最近的模板变更。

第 2—7 天：完成页面和内链修复

修复明确的技术错误，确定一个主页面，合并明显重复内容，补充真实例子和限制条件。新页面通过发布前检查后，再使用百度主动提交或 IndexNow 告知更新；接口接收不等于收录，仍要观察抓取日志和平台状态。

第 8—14 天：看抓取和索引证据

检查搜索引擎请求是否出现、页面和资源是否返回成功、平台是否更新最近抓取时间。若没有抓取证据，优先修发现入口和访问稳定性，不要继续堆关键词。

第 15—30 天：看查询和页面趋势

比较展现、点击、点击率和平均排名，同时检查实际查询与目标意图是否一致。记录标题、正文、内链和模板改动，避免在没有数据窗口时连续多次改版。

九、这些做法容易让诊断失真

只看一次搜索结果

个性化、地区、设备和结果特征都会改变一次搜索的页面顺序。一次手动搜索适合发现现象，不适合证明趋势。

把提交成功当成收录成功

百度主动提交、IndexNow 或 sitemap 都是发现线索。它们不能替代平台索引报告和日志证据。提交规划可以参考百度主动推送与 IndexNow。

同时大批量修改所有页面

标题、模板、正文、链接和服务器配置一起变化时，后续无法判断原因。先修复有明确证据的问题，并记录变更。

只增加关键词密度

关键词出现次数增加，不会自动补足案例、步骤、证据和意图匹配。先问页面是否比已有结果更好地回答了用户问题。

用 User-Agent 直接认定爬虫身份

Baiduspider、Googlebot 或其他名称都可以被伪造。真实身份要按对应平台的官方方法核验，日志分类只能作为初步线索。

十、最后保存一份可复查的结论

一次排查结束时，至少写下四句话：

1. 哪些 URL、查询词和平台出现了什么变化。
2. 哪些证据已经确认，哪些仍然是 unknown。
3. 做了哪些具体改动，改动发生在什么时间。
4. 下一次在什么日期、用什么条件复测。

这样做的价值不在于给排名变化找一个听起来合理的解释，而在于让下一次排查可以复现。SEO 的优化应围绕可访问、可发现、可理解和可验证的页面信号展开；当页面真的解决了查询意图，技术信号和内链也保持一致，排名变化才有机会转化为可持续的搜索表现。