影响收录的3个技术环节
站点不被收录,通常不是内容质量问题,而是搜索引擎根本没机会看到页面,或者看到了却判断为不值得索引。排查时按链路来:抓取层、渲染层、索引层。
抓取层:让爬虫能到达页面
爬虫发现页面的路径主要有两条:XML Sitemap提交和内链传导。很多人只做前者,忽略后者,导致重要页面依赖Sitemap单通道被发现,一旦Sitemap更新延迟,页面就长时间不被抓取。
具体操作步骤:
- 在Google Search Console和百度站长平台同时提交Sitemap,并观察“已发现-已索引”的比例。已发现但未索引的URL超过30%时,说明索引层有问题。
- 检查robots.txt是否误拦截了关键目录。用GSC的robots测试工具逐条验证,特别注意Disallow规则是否覆盖了JS、CSS、图片资源——这些资源被拦截会直接影响渲染抓取。
- 重要页面必须在首页或一级栏目页有直接入口,爬虫深度超过3层时抓取频率会断崖式下降。用Screaming Frog跑一次全站,看关键页面离首页的点击距离是否在3以内。
- 对于百万级URL的大型站点,不要把所有URL都塞进一个Sitemap。按栏目或更新时间拆分成多个Sitemap索引文件,每个文件控制在5万条以内,这样搜索引擎会按优先级分别调度。
渲染层:确保爬虫看到的内容和用户一致
单页应用和重度依赖JavaScript的页面是重灾区。Google虽然能执行JS,但渲染预算有限,复杂页面可能在渲染超时后被截断。百度对JS的渲染能力更弱,依赖客户端渲染的内容大概率被忽略。
验证方法:
- 用GSC的“网址检查”工具查看抓取结果中的屏幕截图,对比实际页面,确认核心文本内容是否出现在HTML快照中。
- 在浏览器中禁用JavaScript后刷新页面,看标题、正文、分页链接是否仍然可见。不可见的内容搜索引擎也不一定能稳定抓取。
- 对于必须用JS渲染的页面,实施服务端渲染或预渲染方案。Next.js用getServerSideProps,Vue用Nuxt的SSR模式,非框架项目用Puppeteer预渲染成静态HTML再返回给爬虫。
索引层:让搜索引擎认为页面值得存入索引库
页面被抓取后,进入索引筛选阶段。搜索引擎会评估页面的唯一性、信息增益和整体质量,决定是否纳入索引。这一步被卡住,前面的抓取和渲染都白做。
索引被拒的常见原因和对应处理:
- 内容重复度过高。用Siteliner或Copyscape检查站内重复比例,超过60%的相似页面需要合并或加canonical标签。产品列表页的筛选组合(颜色、尺寸、价格)会生成大量参数化URL,必须用canonical指向主版本,同时在GSC的参数处理工具中标记非关键参数。
- 页面信息量不足。正文少于300字且没有结构化数据支撑的页面,被判定为“薄内容”的概率很高。分类页如果没有描述文字,至少补充200字以上的分类说明,并添加FAQ结构化数据来增加信息密度。
- noindex标签误用。上线前检查meta robots是否设置了noindex,HTTP响应头X-Robots-Tag是否包含了noindex指令。这个错误在开发环境迁移到生产环境时经常发生。
页面质量评估的量化指标
搜索引擎判断一个页面是否值得索引和排名,底层依赖一系列量化指标。这些指标可以归纳为内容维度、体验维度、权威维度。
| 评估维度 |
具体指标 |
影响权重估算 |
优化方向 |
| 内容维度 |
信息增益、原创比例、内容完整度 |
约40% |
提供搜索结果中不存在的新信息,覆盖用户可能追问的关联问题 |
| 体验维度 |
LCP、INP、CLS、移动端适配 |
约25% |
LCP控制在2.5秒内,INP低于200毫秒,CLS低于0.1 |
| 权威维度 |
外链域名多样性、引用来源可信度 |
约20% |
获取同领域站点的自然引用,作者页展示专业背景 |
| 交互维度 |
点击率、停留时长、回退率 |
约15% |
标题和描述准确反映页面内容,减少用户点击后立即返回 |
权重估算是基于多个SEO测试案例的归纳,不同搜索引擎、不同行业的权重分布有差异。但内容维度始终是最大变量,这个方向投入资源回报率最高。
关键词匹配度的实际作用边界
关键词匹配度影响排名,但作用机制和很多人理解的不一样。精确匹配不再是必要条件,语义理解和意图匹配的权重在持续上升。
精确匹配的退化
2019年BERT模型上线后,Google对同义词、近义词、相关概念的理解能力大幅提升。搜索“笔记本散热不好怎么办”,排名靠前的页面不一定反复出现“笔记本散热”这个词,而是系统性地覆盖了清灰、换硅脂、散热底座、风扇转速这些解决方案。百度在2021年也上线了语义理解模型,中文搜索同样在弱化精确匹配。
测试数据:在100个商业关键词的SERP分析中,标题包含精确匹配关键词的页面占比约62%,但排名前3的页面中,内容全面性得分(覆盖相关子话题的数量)与排名的相关系数为0.71,高于标题精确匹配的相关系数0.48。
关键词布局的现行方法
不是不布局关键词,而是布局逻辑从“密度”转向“覆盖”。
- 核心词放在title标签的前半段,保持自然可读。title是排名权重最高的位置,但堆砌会导致搜索引擎重写标题,反而失去控制权。
- H1包含核心词或语义相近的表达,H2/H3覆盖二级话题和长尾变体。一个页面通过H标签结构,可以同时覆盖5-8个语义相关词。
- 正文前200字出现核心词一次,之后按信息组织的自然节奏分布,不刻意计算密度。1%-2%的关键词密度是自然写作的常见区间,超过3%会触发堆砌判断。
- 图片alt属性使用描述性文字,包含一个相关词即可,不要每个alt都塞核心词。
意图匹配比词匹配更重要
搜索“Python数据分析入门”的用户,意图是找到一套可执行的学习路径,不是看Python的定义。页面如果只解释Python是什么、数据分析是什么,关键词匹配度再高也排不上去。真正满足意图的内容应该包含:环境搭建步骤、常用库(pandas、numpy、matplotlib)的基本用法、一个完整的分析案例。
判断意图的方法:看搜索结果中排名前5的页面都在讲什么内容类型。如果是教程类内容占多数,说明信息型意图为主;如果是产品对比和测评,说明商业调查意图。根据这个来组织内容结构,比纠结关键词出现几次有效得多。
定制化SEO方案的执行框架
不同站点的问题不一样,定制方案需要先诊断后下药。以下是一套可复用的诊断-执行流程。
第一步:日志分析定位抓取问题
从服务器日志中提取搜索引擎爬虫的访问记录,分析三个关键数据:
- 爬虫每日抓取总量。如果持续下降,检查服务器响应时间和错误码比例。5xx错误超过1%就需要排查后端性能。
- 各目录的抓取量分布。重要目录的抓取占比如果低于10%,说明内链权重传导不足,需要调整导航和内部链接结构。
- 抓取与索引的比例。抓取量高但索引量低,问题在内容质量;抓取量本身就低,问题在爬虫引导。
工具方面,小站点用GSC的“抓取统计信息”就够用,大站点用ELK或Splunk分析原始日志,配合Python脚本按User-Agent过滤爬虫请求。
第二步:内容审计确定优化优先级
导出全站URL列表,标注每个页面的以下属性:
- 近30天是否有自然搜索流量
- 页面类型(产品页、文章页、分类页、工具页)
- 内容字数、图片数量、视频数量
- 结构化数据是否部署
按流量从高到低排序,优先优化有流量但排名在第4-10位的页面,这些页面离第一页最近,提升效果最快。然后处理零流量的高价值页面(目标关键词搜索量高但页面没排名),最后处理内容重复或信息量低的页面。
第三步:结构化数据部署
结构化数据不直接影响排名,但会生成富媒体搜索结果,提升点击率。点击率上升带来更多真实用户访问,间接影响排名。
必须部署的类型:
- 文章页用Article Schema,包含headline、datePublished、author
- 产品页用Product Schema,包含name、price、availability、review
- 企业信息用Organization Schema,包含logo、联系方式、社交媒体链接
- FAQ页面用FAQPage Schema,问题数量控制在5-10个
部署后用GSC的“富媒体搜索结果”报告检查错误,Schema属性缺失或格式错误会导致不展示富媒体摘要。
第四步:内部链接权重分配
搜索引擎通过内链计算页面在站内的相对重要性。重要页面应该获得更多的站内链接引用。
操作方法:
- 用Ahrefs或Screaming Frog导出站内链接报告,计算每个页面的内链入链数量。
- 找出内链数量低于5但业务价值高的页面,从相关内容页面添加3-5条上下文链接。
- 分类页和标签页不要无限制生成,每个分类页至少要有5个以上子页面支撑,否则关闭索引。
- 面包屑导航必须使用结构化数据标记,帮助搜索引擎理解站点层级。
收录问题的排查清单
当页面持续不被收录时,按以下顺序逐项检查:
- URL是否在GSC中提交过索引请求,返回的状态码是什么
- robots.txt是否拦截了该URL或关键资源
- 页面meta标签或HTTP头是否包含noindex
- canonical标签是否指向了其他URL,导致当前页面被去重
- 页面加载时间是否超过3秒,移动端LCP是否超过2.5秒
- 页面正文内容是否少于300字,是否存在大段复制内容
- 该URL是否有至少3条来自站内其他页面的链接
- Sitemap中该URL的lastmod时间是否准确,priority值是否合理
- 服务器是否对爬虫返回了不同于用户的响应(cloaking检查)
- 域名是否被搜索引擎处罚,在GSC中查看是否有手动操作通知
每一项检查都能对应一个具体的修复动作,不需要猜测或等待。收录问题的排查本质上就是逐项排除变量,找到阻断点然后修复。