在Search Console（GSC，Google站长工具）的设置 → 抓取统计里，先选报错主机，再点“按响应”中的5XX和示例网址。打开请求详情，确认具体响应码是503，记下原网址和抓取时间。这样才能请维护者查到那次故障；今天浏览器能打开，只说明现在这次访问正常。
503表示服务暂时不可用。下面用一个德文产品站举例：英文站是www.example.com，德文站是de.example.com，9月27日德文站的AB120产品请求出现503。网址、时间及后面的日志结果都是教学设定，实际操作用你自己报告里的值。
从主机点到一条具体503请求
在GSC左上角选择正确网站资源，也就是这份报告管理的网站范围。可用域名资源example.com，或根网址资源；只有某个子目录的资源看不到抓取统计。进入设置 → 抓取统计 → 打开报告。如果资源范围正确仍无权打开，请网站所有者给你相应访问权限，无需为此装SEO插件。
接下来按这条路线操作：
- 看“主机”列表，点错误增加的那一台。本例点de.example.com，查看9月27日前后的曲线。www和de是不同主机，英文首页正常不能说明德文产品页也正常。
- 在该主机的“抓取请求细分”中找“按响应”，点服务器错误（5XX），观察错误增加的日期，再看下面的示例网址。
- 点一条示例，读请求详情的响应码和抓取时间。只有详情确实写503，才将这次访问记为503；若写500或502，就记录那个实际代码。
5XX是一组服务器错误，503只是其中一种。图上的数量也按请求计算：同一网址被访问多次，会算多次，不能当成有多少个产品页坏了。具体入口及字段可对照Google抓取统计说明。
本例详情给出的原网址是：
https://de.example.com/products/ab120/
抓取时间写着2026-09-27 14:08:32，响应码为503。将这三个值和主机一起保存，附详情截图。界面没有标时区，就写“时区待确认”，不要先把它当北京时间或UTC。
保留实际请求的网址：协议、路径和查询参数照录，不换成你认为更规范的主要网址。Google请求过重定向链上的不同地址时，会分别记录请求，查日志需要找的是这一条。
列表不一定有你想找的所有记录。主机列表只显示过去90天有流量的前20个子域名，示例网址也只是代表性样本。如果没有主机列表，可先从当前报告的响应分类和样例网址确认主机；看不到某个主机，不等于它从未被访问。
如果9月27日有5XX高峰，却找不到当天的503详情，就保存该主机、日期曲线和能看到的实际详情，请维护者扩大日志查询范围。此时只有“该日5XX增加”的线索，不能编出一条当天503的时间。
用这条记录请维护者查日志
把刚才取得的资料发给网站维护者或主机服务商，可以直接按下面格式填写。网址必须是你的实际原网址，截图随消息一起发。
请查德文站的一次503：
主机：de.example.com
原网址：https://de.example.com/products/ab120/
GSC详情响应码：503
GSC原时间：2026-09-27 14:08:32，界面未标时区，待确认
附件：该条请求详情及9月27日5XX曲线
请先确认这个时间与服务器日志的时区关系，再查对应时段：
这次请求是否来自Google？CDN和源站各返回什么？
两层记录能否关联到同一次请求？
请告知查到的故障位置、处理办法及修复时间。
这样交接能回答“查哪台主机、哪个地址、哪段时间”。仅发一张总图或说“Google访问不了”，维护者很难查对。Cloudflare的5XX排查说明也要求具体错误码、时间、时区和网址，并提醒检查源站前面的代理、缓存、负载均衡器或防火墙日志。
假设维护者确认本例时间对应UTC，先查9月27日14:00–14:20 UTC，换成北京时间是同日22:00–22:20。这个窗口只是教学起点，实际可按故障情况扩大；在确认时区前，不能用22点替换报告上的14点去查。
日志回来了，怎样判断继续查哪里
如果网站使用CDN，它会先接到Google的请求，需要向源站取内容时才转发。CDN是网站前面的缓存、代理服务；源站是提供原网站内容的服务器。503可能由任一层产生，所以直接访问源站正常，也不能证明Google经过CDN时收到正常响应。
先确认两条日志属于同一次请求，再比较响应码。已有请求ID且两层确实传递了它，可以据此关联；没有ID，就由维护者结合完整网址、准确时间、来源等实际记录判断。只看到“CDN在14:08返回503、源站在14:08返回200”，不能自动将它们配成一对。
同一请求关联清楚后，按结果继续查：
- 源站200，CDN503：源站这次返回200，Google收到的仍可能是503。继续查CDN规则、代理处理和中间链路；200只说明响应码，尚不能说明产品内容正确。
- 源站本身503：查当时是否处于维护、程序报错、连接耗尽或容量不足，再针对实际原因处理。
- CDN报错，源站找不到对应记录：查是否在到达源站前失败，也要确认日志有没有漏采。缺一条日志不能直接认定源站健康。
请求来源也要核对。日志里写着Googlebot只是客户端自报的名字，可以被冒用。维护者应拿实际访问IP做反向DNS查询，再正向查询回原IP，或按相应爬虫类型核对Google公布的IP范围，方法见Google请求验证说明。源站若只记录到CDN的IP，还需要可靠的原访客IP记录；不能验证CDN的IP就当Google身份已确认，也不用为排查而关闭整站防火墙。
还有两类报告信息容易被误读。“主机状态”的robots.txt、DNS和连接问题，与某次HTTP响应为503是不同线索；DNS或连接失败可能根本没到服务器。平均响应时间则混合了页面、图片、脚本等资源，单凭平均值变高，不能推出数据库慢造成这次503。
维护者的回复应落到“哪一层、什么原因、改了什么、何时改”，而不只是“清过缓存”。如果查不到旧日志，就说明未能还原历史原因，并保留后续请求供复查。日志权限、保留时间和采样取决于工具及套餐，例如Cloudflare错误分析只用1%的流量样本，不是一份完整访问日志；样本里没找到，也不能证明Google当时没有访问。
修好后，检查同一网址的新访问
先在原记录后追加修复时间，然后做两件不同的检查：
- 检查现在的产品页。在GSC顶部输入原网址，点“测试实际网址”，完成后打开“查看测试的网页”。既看能否抓取，也看返回的内容是不是AB120产品，避免把200维护页或空白页当正常。若仍失败，把这次测试时间和错误交回维护者。
- 检查修复后的自动访问。请维护者找同一主机、同一网址的新Google自动抓取，经身份确认后看实际响应。如果仍是503，用新的时间继续查；还没有新请求，就写“等待新抓取”。实时测试由Google-InspectionTool发起，不能代替下一次自动Googlebot访问。
访问日志通常不保存完整正文，一条200日志不能证明当时返回了正确产品内容。因此，新自动请求的响应记录和当前产品内容检查要分开保留。具体日志读法可接着看Googlebot访问日志与抓取频次排查。
等抓取统计更新后，再看de.example.com修复时间之后是否出现新的服务器错误，必要时点新样例核对代码。旧503记录或主机历史警告不会因一次修复立即消失，判断时看的是新请求，不要求旧曲线当天变绿。
当前产品内容正常、修复后的自动请求也能正常访问，才有依据说这次访问故障已处理。它仍不保证收录或排名；访问已经正常但页面未收录，可转到抓取与索引排查。
如果日志和GSC信息对不上，可把上面的请求记录及维护者回复发到联系页，先判断需要自行调整、技术协助还是持续的Google SEO执行服务。
常见问题
现在浏览器能打开，是否可以忽略GSC里的503？
先看报错时间。现在的浏览器访问与过去的Google请求不是同一次访问，来源和经过的服务也可能不同。找到旧请求对应日志，再检查修复后的新Google访问，才能判断是否仍有问题。
抓取统计和网页索引报告的5XX数量不同，哪个错了？
两份报告计算的对象不同。抓取统计按请求计，同一网址可以重复计算；网页索引报告关注页面状态，更新节奏也不同。不必把两个数字对齐，用具体网址和时间查故障。
删除产品页或重提站点地图，能修好503吗？
不能修复服务器或中间服务的错误。保留仍有用的产品页，让维护者处理实际故障；持续5XX可能降低抓取，时间久了也可能影响索引，但没有适用于所有网站的固定恢复天数。