内容质量高但搜索引擎不抓取，问题几乎永远不在内容本身，而在技术层。跳过任何一层排查都可能导致误判——比如花时间优化sitemap，却发现根本原因是服务器返回500错误。

以下七步排查法，每一步对应一个可操作的动作。按顺序执行，不要跳步。

第一步：状态码——服务器是否正常响应

状态码是爬虫收到的第一反馈。4xx或5xx错误会让爬虫直接放弃。

餐饮食品网站常见问题：

  • 菜单页面因CMS插件冲突返回404
  • 促销活动页面过期后未设置301跳转
  • 图片资源返回403，导致页面整体被视为错误

检查工具：Google Search Console的“页面索引”报告会列出错误URL。也可用Screaming Frog或Sitebulb全站爬取，筛选非200状态码页面。

修复方法：

  • 404页面：内容已移除则设置301跳转到相关页面；内容仍存在则修复URL或重写路由规则
  • 500错误：检查服务器资源（CPU、内存）、数据库连接、PHP版本兼容性。高分辨率菜品图片常导致超时，建议启用CDN并压缩图片
  • 403错误：检查.htaccess或Nginx配置，确认没有误封爬虫IP

边界情况：过季菜单返回410（已删除）是合理的。但核心产品页面返回410则必须恢复或跳转。

第二步：robots.txt——是否无意中屏蔽了搜索引擎

常见错误：

  • 将/menu/目录误加入Disallow
  • 使用通配符*屏蔽了所有爬虫
  • 测试环境忘记移除Disallow指令

检查工具：浏览器访问https://你的域名/robots.txt。Google Search Console的“robots.txt测试工具”可模拟Googlebot访问权限。

修复方法：

  • Disallow只屏蔽不需要索引的路径（后台管理、临时文件、搜索结果页）
  • 如果用了Disallow: /，所有页面都不会被抓取。除非是开发环境，否则必须移除
  • 有多条User-agent规则时，Googlebot匹配最具体的规则。例如User-agent: Googlebot会覆盖User-agent: *

真实案例：某餐饮连锁网站将/store-locator/路径误加入Disallow，所有分店页面无法被抓取。修复后索引量一周内恢复。

第三步：canonical标签——避免被误判为重复内容

常见问题：同一菜品页面可通过多个URL访问（如/menu/beef-noodles和/menu/beef-noodles?source=home），但canonical标签指向了错误版本或未设置。

检查工具：浏览器查看页面源代码，搜索rel="canonical"。也可用Ahrefs或Screaming Frog批量检查。

修复方法：

  • 每个页面有且只有一个canonical标签，且指向自身URL（自引用）
  • 参数化URL统一指向无参数版本。例如所有带?source=参数的页面，canonical都指向/menu/beef-noodles
  • 不同分店的相同菜品，canonical指向最权威版本（如总店页面）

边界情况：分页列表页（如/menu/page/2/）的canonical应指向自身，而非首页。否则搜索引擎只会索引第一页。

第四步：sitemap——确保所有重要页面都被提交

常见问题：

  • sitemap未包含新菜品页面
  • 包含大量死链
  • 格式错误（如XML标签未闭合）
  • sitemap索引文件超过50MB限制

检查工具：Google Search Console的“Sitemaps”报告显示提交状态和错误数。也可直接访问https://你的域名/sitemap.xml查看内容。

修复方法：

  • sitemap只包含需要索引的页面（200状态码），排除404、301、noindex页面
  • 使用动态sitemap生成工具（如Yoast SEO、Rank Math），自动更新新页面
  • 网站超过5000个页面时使用sitemap索引文件，每个子sitemap不超过50000个URL
  • 提交后在Google Search Console检查“已发现”和“已索引”的数量差异。差异过大说明爬虫发现了页面但未索引，需检查后续步骤

真实案例：某餐饮预订平台每周新增50个餐厅页面，但sitemap每月更新一次，新页面延迟2-4周才被发现。改为每日自动更新后，新页面24小时内被索引。

第五步：内链结构——页面是否被有效链接

内链是爬虫发现新页面的主要途径。

常见问题：

  • 重要页面（菜单、预订页）没有从首页或主导航链接
  • 内链使用JavaScript跳转，爬虫无法跟踪

检查工具：Screaming Frog爬取网站，查看每个页面的“Inlinks”数量。Google Search Console的“链接”报告也可参考。

修复方法：

  • 每个重要页面至少有一个来自首页或主导航的链接
  • 使用HTML文本链接（<a href="...">），避免JavaScript事件或表单提交
  • 面包屑导航是内链结构的基础，确保每个页面都有面包屑且链接可点击
  • 深度页面（如具体菜品详情）通过分类页、标签页、相关推荐增加内链

边界情况：页面只有1个内链时爬虫仍可能发现，但索引优先级会降低。建议每个重要页面至少有3-5个内链。

第六步：渲染——JavaScript内容是否被正确解析

如果页面依赖JavaScript加载核心内容（菜品价格、预订表单、用户评价），搜索引擎可能抓取不到。

常见问题：

  • 菜单数据通过AJAX动态加载
  • 预订日历使用React组件
  • 图片懒加载导致爬虫看不到图片

检查工具：Google Search Console的“URL检查”工具可查看Googlebot渲染后的页面内容。Mobile-Friendly Test工具也可检查渲染结果。

修复方法：

  • 使用服务器端渲染（SSR）或预渲染（Prerendering），让爬虫直接获取完整HTML
  • 无法改为SSR时，至少确保核心内容在初始HTML中可用。例如菜品名称和价格应在HTML中直接输出，而非通过JavaScript加载
  • 避免用display:none或visibility:hidden隐藏重要内容
  • 图片使用<img>标签并添加alt属性，而非CSS背景图

真实案例：某餐饮网站用Vue.js动态加载菜单，Googlebot抓取到的页面只有空白容器。改为SSR后，菜单内容3天内被索引。

第七步：服务器日志——确认爬虫的实际访问情况

服务器日志是排查抓取问题的最终依据。它显示爬虫实际访问了哪些页面、响应时间、返回状态码、以及是否有异常行为（如被限流）。

检查工具：

  • 通过服务器控制面板（cPanel、Plesk）或SSH访问日志文件（通常位于/var/log/apache2/access.log或/var/log/nginx/access.log）
  • 用GoAccess或AWStats分析日志，筛选Googlebot访问记录
  • Google Search Console的“抓取统计信息”提供爬虫访问频率和响应时间概览

修复方法：

  • 爬虫访问频率极低（每天不到10次），说明网站未被充分发现，检查前六步是否有遗漏
  • 爬虫访问了页面但返回500错误，检查服务器资源或代码错误
  • 爬虫访问了页面但返回301/302跳转，检查跳转链是否过长（建议不超过3次）
  • 爬虫被限流（返回429或503），检查服务器配置或CDN设置，确保爬虫有合理访问权限

边界情况：服务器日志显示爬虫正常访问，但Google Search Console显示“已发现但未索引”。这通常意味着内容质量或相关性不足，而非技术问题。此时应检查页面内容是否满足用户搜索意图。

Q&A

Q: 排查顺序可以调换吗？ A: 建议按本文顺序。上层问题（如状态码错误）会直接影响后续排查结果。例如页面返回500错误时，检查sitemap或内链结构没有意义。

Q: 如何查看服务器日志？ A: 通过服务器控制面板或SSH访问日志文件。Google Search Console的“抓取统计信息”可辅助分析。使用云服务（如AWS、阿里云）可在控制台查看访问日志。

如果按上述七步排查后仍无法解决抓取问题，说明可能存在更复杂的技术架构问题。天行GEO提供技术审计服务，可对网站进行全面诊断。同时，研究栏目中有多个餐饮食品网站的抓取优化案例，可作为参考。

内容质量与用户价值原则可参考 Google Helpful Content 官方文档。