许多单页应用（SPA）在Google Search Console中被报告为“软404”，尽管在浏览器中表现正常。这通常源于Googlebot在执行XHR请求前，会尝试访问后端服务器的/robots.txt文件。如果后端未能妥善处理此请求（例如超时），Googlebot会取消后续的XHR，导致页面渲染不完整，进而被误判为“软404”。解决之道在于确保后端服务器能正确响应/robots.txt请求。
理解Googlebot对SPA的爬取机制
现代的搜索引擎爬虫，尤其是googlebot，已经具备了执行javascript并渲染页面的能力，这使得它们能够更好地理解和索引单页应用（spa）。对于spa而言，页面的大部分内容通常是通过javascript在客户端动态生成，并通过xhr（xmlhttprequest）或fetch api从后端api获取数据。
然而，在Googlebot尝试获取这些关键数据（通过XHR请求）之前，它会执行一项重要的预检查：它会尝试访问目标后端服务器的/robots.txt文件。这里的关键点在于，这个/robots.txt请求是针对提供XHR数据的后端服务器，而不是托管SPA前端代码的服务器。Googlebot通过检查/robots.txt来确定是否有任何规则阻止它访问特定的资源或路径。
“软404”与XHR请求失败的深层原因
当Google Search Console报告SPA页面为“软404”时，往往意味着Googlebot成功访问了页面的URL，但未能获取到预期的主要内容，导致页面看起来像是“空”的或不完整的。尽管在浏览器中一切正常，但在Google Search Console的“URL检查工具”的“实时测试”中，你可能会观察到页面渲染出错，并且在“页面资源”部分看到XHR请求失败，错误类型显示为“Other error”，同时JavaScript控制台消息可能为空。后端日志也可能显示根本没有收到预期的XHR请求。
这种现象的根本原因在于Googlebot在执行XHR请求前的/robots.txt预检查。如果你的后端服务器未能妥善处理来自Googlebot的/robots.txt请求（例如，由于配置不当、服务器超时、连接被拒绝等），Googlebot会认为无法安全地进行后续的XHR请求。在这种情况下，Googlebot会选择取消或放弃原始的XHR请求。
一旦关键的XHR请求被取消，SPA页面就无法从后端获取到渲染所需的数据，导致页面内容缺失。Googlebot因此会将这个不完整的页面判定为“软404”，因为它虽然响应了200 OK状态码，但内容却与一个真正的404页面无异。GSC中显示的“Other error”通常是一个通用的错误信息，它可能掩盖了底层因超时或连接问题导致的/robots.txt请求失败。
诊断与排查方法
要诊断此类问题，可以采取以下步骤：
使用Google Search Console的URL检查工具：对受影响的页面进行“实时测试”。仔细检查渲染截图，看页面是否显示完整内容。查看“页面资源”部分，特别是任何被标记为“Other error”的XHR请求。检查“JavaScript控制台消息”，虽然此处可能为空，但仍值得留意。检查后端服务器日志：在进行Google Search Console的“实时测试”时，同步监控后端服务器的访问日志。重点查找来自Googlebot IP地址的/robots.txt请求。确认这些请求是否被正确接收并响应，或者是否有超时、连接错误等异常。如果根本没有收到XHR请求，那么问题很可能出在/robots.txt的预检查上。
解决方案：正确处理后端/robots.txt请求
解决此问题的核心在于确保你的后端服务器能够正确响应来自Googlebot的/robots.txt请求。最简单且通常最有效的方法是，即使你的后端API服务器不需要提供一个复杂的robots.txt文件，也要确保它能对此路径做出一个快速且无错误的响应。
推荐的处理方式：
让后端服务器对/robots.txt请求返回一个HTTP 404 Not Found状态码。这告诉Googlebot该路径不存在，但请求本身是成功的，并且没有超时。
以下是几种常见后端环境的配置示例（概念性伪代码）：
1. Node.js Express 框架示例：
const express = require('express');const app = express();// ... 其他路由和中间件配置 ...// 专门处理 /robots.txt 请求app.get('/robots.txt', (req, res) => { // 返回404 Not Found状态，表示此路径不存在 res.status(404).send('Not Found'); // 或者，如果你的后端确实需要一个robots.txt文件来控制爬虫行为， // 可以返回一个实际的robots.txt内容，例如： // res.type('text/plain').send('User-agent: *nDisallow: /api/nAllow: /');});// ... 其他API路由 ...app.listen(3000, () => { console.log('Backend server listening on port 3000');});
2. Nginx 反向代理或直接服务示例：
如果你使用Nginx作为后端API的反向代理或直接服务，可以在Nginx配置中添加规则：
server { listen 80; server_name your-backend-api.com; // ... 其他配置 ... // 处理 /robots.txt 请求 location = /robots.txt { return 404; # 直接返回404状态码 # 或者，如果需要提供，可以指向一个静态文件 # root /path/to/your/backend/static; # try_files $uri $uri/ =404; } // ... 其他API代理规则 ...}
重要提示： 这个/robots.txt是针对提供XHR数据的后端服务器，而不是托管SPA前端代码的服务器。许多SPA的前端可能托管在CDN或静态文件服务器上，它们有自己的/robots.txt。这里的重点是后端API服务器。
注意事项与最佳实践
可访问性： 确保所有对Googlebot至关重要的API端点都没有被/robots.txt文件（无论是前端还是后端）错误地阻止。避免超时： 不仅是/robots.txt，所有Googlebot访问的资源都应确保响应迅速，避免因超时而导致抓取失败。持续监控： 定期检查Google Search Console的“覆盖率”报告和“抓取统计信息”，以及后端服务器日志，以发现潜在的抓取问题。服务端渲染（SSR）或预渲染（Prerendering）： 对于大型或SEO要求极高的SPA，考虑采用SSR或预渲染技术。这能确保在JavaScript执行前就提供完整的HTML内容，进一步提高搜索引擎的可抓取性。统一/robots.txt策略： 如果你的前端和后端服务器在同一个域名下，确保/robots.txt策略是统一且清晰的。如果它们是不同的域名或子域名，则每个域名都应有自己的/robots.txt文件。
总结
Google Search Console中SPA页面的“软404”和XHR请求失败，往往是由于Googlebot在执行XHR请求前，未能成功地从后端服务器获取/robots.txt文件所致。通过确保后端服务器能够正确、快速地响应/robots.txt请求（例如返回404），可以有效解决这一问题，让Googlebot能够顺利抓取并索引你的SPA页面内容。理解Googlebot的爬取机制并进行针对性优化，是提升SPA搜索引擎可见性的关键。
以上就是Googlebot爬取SPA时XHR请求失败与软404问题的根源与解决方案的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1513057.html
微信扫一扫 
支付宝扫一扫 
