在搜索蜘蛛的日常抓取活动中，服务器响应状态码是影响抓取效率的核心因素之一。大多数站长都熟悉200和404，却容易忽略304状态码的价值。304表示“未修改”，它允许蜘蛛在页面内容没有变化时直接跳过正文传输，仅获取一个轻量级的判定结果。虽然这一机制在浏览器缓存中很常见，但正确运用于搜索蜘蛛抓取场景，却能显著降低带宽消耗，间接加快新URL的发现速度。
为什么304能帮助蜘蛛更快发现URL
搜索蜘蛛的抓取资源存在上限，业界常称之为“抓取预算”。每次重复抓取一个未更新的页面，如果服务器返回完整的200响应，蜘蛛就必须消耗下载时间和带宽。而如果服务器能依据条件请求返回304，蜘蛛便能在极短时间内判断“无需重取”，从而把节省下来的预算用于发现和抓取站内的新链接。尤其对内容更新不频繁的站点，启用304优化后，蜘蛛每日轮询的页面数量可能提升百分之几十。
例如：站点有1万个页面，每天实际更新100个。如果蜘蛛需要每天重新下载全部页面来确认变化，成本极高。通过304，蜘蛛只需发送带有校验头的请求，服务器返回“未修改”，则蜘蛛可以保持原有缓存并继续爬行。这样一来，蜘蛛能在同一次抓取周期内探访更多深层URL，这相当于间接优化了站内链接的发现效率。
条件请求的实现基础
要实现304响应，需要静态或动态页面正确提供两种头部信息：Last-Modified和ETag。服务器在初次返回页面内容时附带这些头，蜘蛛后续抓取时会携带If-Modified-Since或If-None-Match头，服务器通过比较时间戳或实体标签来决定是否返回304。
- Last-Modified：页面最后修改时间，精确到秒。蜘蛛在第二次请求时会发送If-Modified-Since，如果服务器时间未超过该时间，则直接返回304。
- ETag：一个内容哈希或版本标识符，更精确。蜘蛛使用If-None-Match头与服务器当前生成的值比较，不同则返回200，相同则返回304。
常见配置方法
在Apache中，可通过mod_headers和mod_expires设置默认缓存头，同时使用FileETag MTime Size来生成ETag。在Nginx中，默认已开启ETag和Last-Modified，但需要确认是否被代理或CDN剥离。若使用CDN，应确保CDN节点不删除原始响应头，并在CDN缓存规则中优先透传源站的304验证。
对于动态页面如PHP，可在输出时手动设置头部。例如：
header("Last-Modified: " . gmdate("D, d M Y H:i:s", filemtime($file)) . " GMT");并在页面处理逻辑中检测If-Modified-Since与文件修改时间的关系，相同则返回304并退出。
注意：304响应必须不包含页面正文，只包含状态行和必要的头部。生成时不要计算页面内容，否则就失去了优化效果。
配置中的常见陷阱
ETag变化导致缓存失效
多台Web服务器组成的集群，如果每台服务器基于inode或时间戳生成不同的ETag，会导致蜘蛛对同一页面反复收到200响应。解决方案是去除ETag中的inode字段，或使用统一的基于内容哈希的ETag。在Nginx中可配置etag off，然后统一生成自定义ETag；在Apache中设置FileETag MTime Size即可。
Last-Modified缺失
很多动态页面默认不输出Last-Modified头，即使内容是从数据库读取的，也可能未被正确赋值。此时蜘蛛无法发起条件请求，只能每次下载完整页面。建议对动态页面根据数据更新时间强制输出Last-Modified，或使用伪静态时由重写模块附加。
与压缩协商冲突
当服务器同时启用Gzip时，ETag生成需考虑内容编码。如果压缩前后ETag不同，蜘蛛可能误判。一般建议ETag基于原始内容而非压缩后内容，并且始终返回正确的Vary: Accept-Encoding头。
如何通过日志验证效果
配置完成后，需要观察蜘蛛的实际响应状态。在服务器访问日志中，过滤百度蜘蛛或Googlebot的UA，统计304与200的比例。如果304占比达到70%以上，说明缓存命中率高。同时，你还可以对比优化前后蜘蛛单次抓取的URL数量是否上升，以此判断URL发现效率是否改善。若日志中没有任何304，则需检查是否缓存插件或安全软件拦截了If-Modified-Since请求。
总结
304状态码配置不是一项复杂工程，却常被忽略。合理运用条件请求，可以让搜索蜘蛛以更低的成本完成重复抓取，将有限的抓取预算导向真正需要发现和更新的页面。每个站点都可以审视日志，确认是否让蜘蛛做了一些“无意义”的完整下载。适度优化服务器响应，不仅降低了负载，也为站内新内容的穿透提供了更多机会。从实际运营角度出发，这是一项投入小、回报稳定的基础优化手段。