HTTP状态码SEO完整图谱：301/302/410三大场景+5步实战

TL;DR：HTTP状态码不是给浏览器看的装饰，是网站给搜索引擎签的一张响应合同。301、302、304、404、410、503这几个码，各自约束的是抓取频率、索引归属、权重传导、抓取预算这几条完全不同的链路。把它们当成一张全图谱来用，而不是单点查手册，才能在改版、迁移、删页、维护停服这些高风险动作里不掉量。本文按从200到5xx的完整码段，配上这些年线上踩过的真实坑与决策矩阵，让一行响应头说清楚到底在告诉Googlebot什么。

为什么搜索引擎对一行状态码这么较真？

很多人写代码时把HTTP状态码当成可选的语义糖，反正页面能打开、能渲染、用户看得见，状态码是301、302、200还是307，没什么大区别。这种心智在面向真人的产品里成立，但在面向搜索引擎的SEO里，是站长经常踩坑的源头之一。

保哥这些年带客户做技术SEO诊断，能列出来的明确因状态码错配掉量的案例，少说几十次。有人改版后所有旧URL用302转新URL，半年后排名稳稳掉了一半才发现问题；有人删稿用了404，几个月后这些早就不存在的URL还在Googlebot的抓取队列里反复来扫；有人促销日触发了大范围503没带Retry-After头，活动结束后索引覆盖率从92%掉到67%，再花两个月才修回来。

状态码是给Googlebot的合同，不是装饰

搜索引擎爬虫读一个URL，第一件事不是读HTML，是读响应头里那一行状态码。这一行就是网站对爬虫的明确表态：这个URL现在存在不存在？它跳到哪里？是永久的还是临时的？需不需要再回来抓？需不需要把它从索引里清掉？

HTML可以骗用户，状态码骗不了爬虫。一个返回200的页面里写着大大的“页面不存在”，对真人来说是没找到内容，对爬虫来说是一个有内容的页面，于是索引里就多了一个名叫“页面不存在”的入口，几千几万个这样的入口堆出来，整站的内容质量画像就被拉低了。这就是软404陷阱的核心机制。

一行响应头能决定整页的命运

我们来看一组对照：

• 返回200 OK ＋ 正常内容 = 页面活在索引里，按内容质量竞争排名
• 返回200 OK ＋ 错误/空内容 = 软404，进入低质画像，长期拖后腿
• 返回301 到新URL = 旧URL被替换，权重平滑过渡
• 返回302 到新URL = 临时跳转，Google继续把旧URL当主URL看
• 返回404 = 找不到了，可能是暂时，Googlebot会反复来确认
• 返回410 = 永远没了，索引清出曲线明显更快
• 返回503 ＋ Retry-After = 维护中，Googlebot知道几小时后再来
• 返回503 不带Retry-After = 服务挂了，长时间持续会掉索引

同一个动作（删除一个页面），用404还是410，对Google的语义完全不同；用301还是302，对权重传导的影响截然不同。所以做技术SEO项目要做的第一件事，永远是全站状态码盘点：用日志按status_code聚合、用Screaming Frog爬一遍、再对照GSC的索引报告，把所有错配先列出来再说。

200 OK真的就万事大吉了吗？

200是最常见的状态码，也是最容易被忽视的。绝大部分人觉得200就是健康，没什么可看的。其实200下面藏着SEO最隐蔽的几类杀手。

软404：返回200却内容空白

软404是经典坑。页面打开能看到“抱歉，找不到这个产品”、“该商品已下架”、“分类暂无商品”这种文本，但HTTP状态码却是200。从用户视角看，这就是个找不到的页面；从爬虫视角看，这是一个有内容的页面，被收录后还会参与排名竞争。

当一个站积累了几千上万个这种软404，Google会在GSC的索引报告里把它们标成“软404”并不再当主排名页对待。更严重的是，这些薄页和空页会被算进站点的内容质量画像里，把整站的有用内容比例拉低。这是HCU之后变得更要命的代价：质量分类器是站点级的，软404多了，不止这几个页面排名差，整个目录甚至整站都被拉下来。

200壳页：JS未渲染或加载失败

用纯CSR做的SPA站点经常遇到这种情况：服务器返回200，但HTML body几乎是空的，所有内容靠JS动态加载。Googlebot第一次抓取拿到的就是空壳，等渲染队列处理完才能看到真内容，这中间有几小时到几天的延迟。如果JS加载失败或者执行报错，Googlebot拿到的就是一个200状态码加几乎空白的内容，结果就是一个被收录但没有内容的URL。

举个真实场景：一个Vue单页站，所有产品页都是CSR渲染，老板抱怨Google基本不收录产品页。爬虫日志一拉，Googlebot确实来抓了，每次都是200，但HTML body只有1KB左右的骨架。换成SSR后两个月，索引覆盖率从23%涨到79%。JS渲染的内容Google抓不到？机制与排错全拆解这篇里有更细的SPA渲染诊断流程。

200重复：内容相同URL不同

排序、筛选、分页、追踪参数让一个站可以瞬间产生成千上万个URL，每个都返回200，每个都有内容，但内容彼此重复或近似重复。Google抓了之后要做去重，去重过程消耗抓取预算，被判定为重复的URL不会获得独立排名位置，反而会和主URL竞争被选展示页的过程。

这类问题正确的处法不是改状态码，是用canonical、参数管理、robots指令去收敛URL集合本身。但很多人发现这些重复URL之后，第一反应是用301把它们301到主URL，问题来了：原本的200重复变成301重定向，Googlebot仍然要抓一遍才知道是301，抓取预算反而被烧得更厉害。正确做法是从源头不让这些URL被链接，或者用canonical让Google直接收编。

哪些“伪200”需要警觉

下面这张表是诊断时常用的伪200快查清单：

301和302到底怎么选才不会丢权重？

301和302是网站做改版、迁移、合并、下架时绕不开的两个状态码。Google多次官宣这两个码（加上307、308）传递的权重差不多，但实际工程操作里，二者远不是可以互换的。差别藏在语义、信号稳定性、缓存与历史信用这几个看不见的维度上。

永久迁移用301，临时下线用302

301说的是“这个URL以后永远不在这了，请把所有信号都搬到新URL去”。它意味着Google可以放心地把旧URL从索引里清出、把所有权重转给新URL、把外链历史信用一并转移。301处理一旦完成，旧URL基本就退出排名战场了。

302说的是“这个URL暂时挪到另一个URL，过几天就回来”。Google对302的默认处理是保留旧URL作为主URL，新URL只是临时替身。如果你预期某天会把跳转撤掉、回到旧URL，那302是合理的；如果实际上以后永远不回来了，却用了302，Google会持续地把两个URL都当独立资产，权重摊在两边，长期下来等于两边都没得到完整加权。

长期302会被Google自动重判为301

Google的John Mueller在多场AMA里明确说过：如果一个302跳转持续了相当长的时间（几个月以上），Google会自动开始把它当成301处理。但这个自动重判有显著的延迟，可能要等三到六个月才生效。这段延迟里，权重传导被卡在不确定的过渡态。

保哥这些年遇到过最典型的302滥用案例：一个出海宠物用品DTC站，把所有缺货商品页用302跳到首页，理由是“等补货回来还要切回来”。一年过去，补货早就完成了几十轮，但302从未撤过。我们做诊断时拉GSC，发现这些缺货页累计有1.2万条外链信用全部卡在了302的灰色地带，新页拿不到完整加权，老页也回不来。换成301并指向对应的同类商品页之后两个月，整站非品牌词流量回升了38%。

302跳到不相关页面等于丢权重

不少改版操作里，人懒得做URL映射，干脆把所有旧URL都301（或302）到首页，觉得至少流量没掉到外面去。这是技术上能跑、SEO上灾难的做法。

Google对“跳转到不相关页面”的判定机制是：如果301目标页与原页主题相关性低，跳转可能被识别为软404，权重传递大幅降低甚至清零。Google早就明确过这点。所以做改版时，URL映射要尽量做到“同类页对同类页”，分类对分类、产品对产品、文章对文章；找不到对应页的，宁可让它返410也别一锅端到首页。

307和308这两个新状态码什么时候用？

307和308是相对新的状态码（HTTP/1.1后期才正式纳入），用得不多但碰到必要场景就非用不可。这两个码补的是301和302的一个语义漏洞。

308保留请求method的永久重定向

301在历史上有个尴尬的实现：很多浏览器和爬虫会在跟随301时把POST请求自动降级成GET。也就是说，一个POST到旧URL的请求，被301跳转后变成了GET到新URL，原本携带的请求体就丢了。这个行为是浏览器历史遗留，不是HTTP规范的本意。

308就是为了堵这个漏洞设计的：语义上和301完全一样（永久迁移），但严格要求客户端跟随时保留原method。如果原请求是POST，跟到新URL时还是POST；如果是PUT，仍然是PUT。在API端点迁移、表单提交URL变更这类场景，必须用308而不是301。

307保留请求method的临时重定向

同理，307是302的严格版本：语义上等于302（临时跳转），但保证method不变。这在AJAX端点、WebHook回调、第三方API集成这些POST驱动的场景里非常关键。

对SEO的影响基本等同301和302

从SEO角度看，307对Google等同于302、308等同于301，权重传递规则一致。所以在常规页面级的跳转里，301、302足够用，不必专门换成307或308。但凡是API、AJAX、表单POST这类有method敏感性的端点，工程实现一定要走307或308，避免数据丢失。

实际工作里碰到过一个B2B数据服务商，他们的搜索API端点从v1迁到v2，运维直接用301做了重定向，结果客户端的POST请求大量变成空GET，业务方一周内投诉炸了。最后改成308，问题才彻底解决。这就是状态码语义没读细的代价。

304 Not Modified怎么帮抓取预算省钱？

304是大站做SEO时最值钱的一个状态码。但绝大多数小站根本没启用304，因为没意识到它在抓取预算上的价值。

条件请求的机制：If-Modified-Since与ETag

Googlebot抓页面时，请求头里通常会带两个字段：If-Modified-Since（上次抓的时间）和If-None-Match（上次拿到的ETag）。服务器收到请求后比对：

• 如果页面自上次抓取以来没变过，返回304 Not Modified，响应体为空
• 如果变过了，返回200 OK加新的完整页面内容

关键点：304响应体是空的，只有响应头。Googlebot拿到304，知道页面没变，跳过下载和重新解析，直接复用之前已经索引的内容。这一来一回，服务器省了一次完整页面渲染的成本，Googlebot省了一次完整下载的字节预算。

大站为什么必须支持304

对一个100万URL量级的站点来说，Googlebot每天平均抓取一定比例的URL。如果每次都返回200带完整字节，抓取预算很快就被消耗光。开启304之后，那些没变化的页面（往往占总量60%以上）几乎不占字节预算，Googlebot同样的预算可以抓更多新URL或更深的层级。

保哥前年帮一个百万级商品站做技术SEO优化，那时候日志里几乎看不到304响应，每次都是200。我们让开发把Last-Modified和ETag正确实现起来，两周后Googlebot的日均抓取URL数从42万涨到78万，新商品页的发现速度从平均6天降到48小时内。这就是304对抓取经济学的实打实价值。

304的常见误用陷阱

错误一：永远返回304。有些缓存配置写错了，无论If-Modified-Since传什么时间都返回304，结果Googlebot以为页面永远没变，新内容长期不被重新索引。这个坑特别隐蔽，因为没掉收录、只是新内容上不去排名。

错误二：ETag用不稳定的字符串。如果ETag每次响应都变（比如带了时间戳），Googlebot永远命中不了304，等于没启用。正确做法是用页面内容的稳定签名（比如内容哈希加修改时间）。

错误三：Last-Modified时间漂移。如果服务器集群之间时钟没同步，同一个URL在不同节点上返回的Last-Modified不一致，会让Googlebot困惑地一会儿命中304一会儿不命中，缓存策略失效。

关于AI爬虫与304的具体行为差异，AI爬虫到底在抓你什么？拿代码逆向出它的真实偏好里展开过条件请求作为爬虫经济学第四维的实测数据，做大站的可以参考。

404还是410哪个删页面更干净？

404和410语义上都是“页面不存在”，但对Google的信号强度完全不同。理解这个差别能让删页这件事做得既快又干净。

404是“暂时找不到”，410是“永远没了”

404对Google说的是：这个URL现在我找不到，可能是临时的，也可能是永久的，你过几天再来确认一次。Googlebot会反复来抓同一个404 URL，频率从一周一次衰减到一月一次，但很多月之后才彻底放弃。所以删稿用404，索引清出曲线是慢的。

410说的是：这个URL永远没了，请把它从索引里清出，不用再来抓。Googlebot拿到410后清出速度明显比404快，Google官方多次确认过410在索引清出上的优先级高于404。

什么时候必须用410

下面这些场景，建议直接上410，别留404：

• 电商商品永久下架，且没有同类替代品
• 博客文章因质量问题或合规问题永久删除
• 历史活动页过期且不会再办
• 已知的低质量软404页，从200改成410
• 被处罚后清理的薄页或站点声誉滥用页
• HCU降权后决定砍掉的旧内容

有同类替代品的情况下，应该301到替代页，而不是410。410是用在“确认永远不需要这个URL了”的场景。

实战案例：博客大量删稿用410比404清得快3倍

有个出海美妆DTC博客，长年积累了大约2400篇旧内容，经过HCU审计后判定有800多篇是低质或过时不可救的。第一轮处理用了404，3个月过去GSC的索引报告里那800篇还有460篇被Google标记成“已抓取但找不到”，依然在反复来抓。

第二轮我们改成410，并提交了一份只包含这800个URL的临时sitemap让Google加速重新抓。一个月后还剩100多个，两个月后基本清完。抓取预算的释放让剩下的1600篇高质内容获得了更高的抓取频率，三个月后整站非品牌词流量回升了22%。

404、410、disavow的决策矩阵

451、521、523、5xx这些边缘状态怎么影响SEO？

常用状态码之外，还有一组边缘但关键的码。在合规、CDN、维护、灾难场景下，它们决定了一次事故会不会从运维问题升级成SEO事故。

451 Unavailable For Legal Reasons

451是2015年才正式被纳入HTTP规范的状态码，专门用来表示“因法律原因不可用”。比如某商品因地区版权限制不能展示、某内容因当地法规被强制下架、某用户的隐私信息被GDPR要求清除。

451的SEO语义是页面级的，不会拉低整站权重，Google会保留该URL在索引中但标注法律下架状态。这比让法律下架的页面返200空内容、或者跳到首页要好得多，因为它向Google清晰传达了下架原因，避免被误判为故意制造软404或排名操纵。

521、523这些Cloudflare码

521 Web Server Is Down和523 Origin Is Unreachable是Cloudflare独有的状态码，意思是CDN这一层活着但源站挂了。Googlebot抓到521或523的反应和抓到5xx一样：先降抓取频率、过段时间再来。

这里的坑在于：很多站长盯GA4或服务器日志根本看不到521、523，因为这些响应是CDN层返回的，根本不会进源站日志。结果就是源站“看起来一切正常”，但实际上Googlebot访问失败了好几天。诊断这类问题必须直接查Cloudflare的Analytics面板，或者用GSC的抓取统计报告反推。

503加Retry-After是计划维护的正确做法

503 Service Unavailable是为计划维护设计的状态码。但很多人用503时漏了一个关键字段：Retry-After头。这个头告诉客户端（包括Googlebot）多久后可以重试，可以是秒数或具体时间。

带Retry-After的503对Google说的是：站点在维护，预计X分钟后恢复，请按这个时间再来。Googlebot会按这个提示来安排重抓。不带Retry-After的503是赤裸的服务不可用，Googlebot会按默认策略降低抓取频率，恢复后还要慢慢爬回原本的频率。

5xx持续多久会被踢出索引

这个数字Google没公开过，但综合实测和Mueller的几次访谈里能拼出来：短时5xx（几小时内）几乎不影响索引；持续24小时左右开始有部分URL进入“暂时不展示”状态；持续72小时以上一部分URL会被实际清出索引；持续两周以上整站索引覆盖率会大幅下降。

关键是：5xx期间Googlebot会快速降低抓取频率，恢复后频率慢慢爬回来要好几周。所以哪怕事故只持续了一天，索引和抓取的余震可能持续一个月以上。带Retry-After的503事故余震明显短。

电商促销日503没设Retry-After的真实代价

保哥接过一个跨境3C配件独立站的诊断，他们去年双十二搞大促，三天里高峰流量打满服务器，触发了大量裸503（没Retry-After头）。促销结束一周后索引覆盖率从88%掉到64%，关键品类页排名平均掉了4到6位。

排查发现，运维当时只是临时把超载请求兜底返503，根本没意识到Retry-After的SEO影响。后续我们做了三件事：把维护模式标准化（503＋Retry-After: 3600）、把超载兜底改成排队+200稍后重试、把促销期间的容量评估列入运维标准流程。两个月后索引覆盖率恢复到86%，关键页排名基本回到原位。

重定向链应该限制在几跳以内？

重定向链是大站运维多年下来的隐形包袱：每次改版加一跳、每次域名调整加一跳、每次HTTPS切换加一跳，几年下来一个URL可能要跳5、6、7次才能到最终目标页。这是抓取预算的隐形吞噬大户。

Google能跟5跳，但权重每跳衰减

Google官方说过Googlebot最多跟随5跳重定向，超过5跳就放弃。这是硬上限。但即使在5跳以内，每跳传递的权重也会有一些损耗。具体损耗多少Google没公开，但社区实测和实战里看下来，跳数越多权重传导越不彻底。

更要命的是：重定向链的中间任何一跳如果是404或5xx，整链权重传递就崩了。比如一个4跳链路里第3跳的中间URL因服务器配置问题返了500，前两跳的权重过不到第4跳，等于彻底丢了。

实战诊断：curl、Screaming Frog、cf-headers

诊断重定向链的工具梯度，常用的是：

1. 单URL用curl -ILk URL，能看到每一跳的完整响应头
2. 批量URL用Screaming Frog的Redirect Chain报告，能导出每条链的完整轨迹
3. CDN层加挂的跳转用curl -ILk -H "CF-Connecting-IP: x.x.x.x"对比真实IP和CDN返回的差异
4. 移动桌面差异用-A "Mozilla/5.0 (iPhone; CPU iPhone OS...)"切UA再curl一次

11跳链路被收敛到1跳的真实案例

有个老牌B2B工业工具站做诊断时，跑Screaming Frog一爬，发现整站平均重定向链长度是3.7跳，最长的一条达到了11跳。原因是这个站历经了4次大改版（旧域→新域→HTTPS→新URL结构→分类合并→产品集中），每次改版都没把上一轮的重定向链收敛，而是新加一跳。

我们用脚本把所有重定向链拉平，11跳的全部直接改成1跳到最终目标。两个月后整站平均抓取深度降低40%，Googlebot日均抓取URL数翻倍，3个月后流量回升31%。这就是重定向链收敛带来的SEO杠杆。

移动端和桌面端跳转必须一致

移动优先索引以后，Google主要看移动版来打分，但桌面版仍然存在并会被检查。如果一个URL在移动端是301到新URL、在桌面端是302、或者跳转的目标URL本身就不一样，Google会把这个站标成跳转不一致，长期不一致会影响整体信任分。

这个坑最常见的形式是：m.子域 + www子域，两套独立路由表，运维迁移时只改了一套。诊断方法：用两个UA分别curl，看响应头是否完全对齐。网站迁移为什么总掉排名？不掉量的SEO机制与完整方案这篇里有改版时移动桌面对齐的完整核对清单。

用日志和GSC怎么双源诊断状态码问题？

状态码诊断不能只看一边。GSC告诉你的是Google视角的状态码分布，服务器日志告诉你的是真实发生的请求与响应。两边对照才能找到真问题。

GSC索引报告各状态码的含义

GSC的索引覆盖报告里，状态码大致映射到这几类：

• 已抓取，未编入索引：响应200但Google决定不收，多见于低质或重复内容
• 已发现，目前未编入索引：Google知道这个URL但还没去抓
• 已重定向：响应301或302，跳到了别处
• 已重定向，但有错误：跳转链断了或目标返了4xx/5xx
• 找不到：响应404或410
• 软404：响应200但内容判定为找不到
• 服务器错误：响应5xx
• 因访问被禁止而被屏蔽：响应401或403

每一类下都能展开看具体URL列表，导出后能做后续分析。但要注意GSC的数据有2到3天的延迟，不能拿来做实时监控。

服务器日志按status_code聚合的可信信号

服务器日志（nginx access.log或apache的等价物）按status_code聚合，是最可信的状态码诊断源。它告诉你的是真实发生的请求-响应对，没有Google的判断滤镜，也没有任何延迟。

常用的聚合视角包括：

• 按UA过滤出Googlebot请求，再按status_code分桶看分布
• 按URL pattern聚合，看哪些目录的5xx集中
• 按时段聚合，看异常码的时间分布是否对应某次发版或事故
• 按referer聚合，看哪些来路触发了大量404

双源对照法：GSC上报 vs 日志真实

GSC说有X个404，日志里能不能找到Googlebot真的拿到了这X个404的响应？如果对得上，问题就在那批URL本身；如果对不上（比如GSC说500个404但日志里只看到120个），那中间可能有缓存或CDN层在做事情，影响了Google看到的状态。

诊断时第一步永远是双源对照，发现量级对不上时直接顺着差异找原因，往往能逮到一些没人注意的中间层bug。具体GSC各报告的精读方法和反推页面问题的诊断流程，可以参考Google抓取问题75%来自两个URL错误？按成因诊断这篇。

抽样诊断流程：先找量级最大的异常码

面对一个全是问题的站，怎么排诊断优先级？常用流程是：

1. 把日志按Googlebot UA过滤，按status_code分桶
2. 对每个非2xx桶，按URL pattern聚合，找量级最大的几类
3. 对量级最大的几类，抽样人工核查，定位根因
4. 按估算的SEO影响（抓取预算占比、索引代价、权重传导损失）排修复优先级
5. 修完一类，回到日志看分布是否真的变了，避免修了没生效

状态码使用上的常见错配场景有哪些？

下面这张误用矩阵是这些年汇总的状态码错配最常见场景，每一行都对应过真实的客户案例：

看这张表的时候要意识到：每一个错配都不是单点问题。301用错可能掉权重，但配合canonical又用错就是双重信号冲突；503不带Retry-After是单点问题，但配上长时间事故就是索引覆盖率长期不可逆。做技术SEO审计的最后一步，永远是把所有状态码错配按“修复杠杆”排序，先修代价最大的几类。

状态码和抓取预算的关系到底怎么算？

大站做技术SEO，最关心的一个指标就是抓取预算。状态码直接影响抓取预算的消耗效率，这个连接比很多人想象的要紧。

200消耗全字节，304几乎零字节

Googlebot抓一个返回200的页面，要下载完整HTML（平均10到200KB），还可能要附加抓CSS、JS、图片（虽然Googlebot不每次都抓全资源，但渲染时要抓）。一个返回304的页面，响应体几乎为零，只有几百字节的响应头。

这就意味着：一个支持304的站，每天的抓取预算可以覆盖到的URL数量，比不支持304的站多2到3倍。对内容更新不频繁但需要保持索引覆盖的站（资讯、电商、文档），这个杠杆几乎是免费的。

4xx和5xx也消耗预算，但浪费

很多人以为404、410、5xx不消耗抓取预算，因为响应体小。错。Googlebot抓任何URL都要：建立连接、发送请求、接收响应、解析响应。这一整轮算一次预算消耗，状态码不影响这次消耗。

区别在于：200带来的是内容可索引、可排名的价值；4xx、5xx带来的是垃圾URL继续浪费预算的代价。一个站如果4xx占比超过10%（见过有人占到35%的），抓取预算就有相当一部分在反复抓那些根本不会被收的URL。

把抓取预算还给重要页面的实战

有个客户是百万级商品站，做诊断时发现日志里30%的Googlebot请求落在200重复软404上。处理路径是：先用canonical收编近30%的重复URL、把明确的软404改成410、把孤儿薄页nodindex掉、清掉重定向链。三个月后Googlebot抓到的“有效URL”占比从58%涨到82%，新商品平均48小时内被收，整体非品牌词流量回升27%。这就是状态码治理释放出的实打实的抓取预算红利。

常见问题解答

问：301真的能传递接近100%的权重吗？

实测上Google早期声明保留约85%-90%，2016年后多次表态301、302、307、308传递的权重差不多，但只在跳转目标与原页主题高度一致时才稳。跳到首页或不相关页，等同把权重稀释掉。

问：502持续多久才会真正掉索引？

短时5xx不会掉，Googlebot会把抓取频率降下来过几天再来。持续24小时以上仍是5xx，部分页面会进入受影响状态；持续一周以上才开始大规模降权。带Retry-After的503比裸5xx要稳。

问：robots.txt阻止加410状态码哪个删页面更彻底？

410更彻底。robots.txt只阻止抓取不阻止索引，被阻的URL仍可能因外链留在索引里。要彻底删除必须让Googlebot能抓到且抓到410或noindex，两者不能同时上。

问：改版后301链多久能让Google把权重过完？

实测主流时间窗在30到90天，权重传导曲线先快后慢。前30天通常完成60%，剩余在3个月内慢慢补齐。链路不能断，跳数不能超过5跳，移动桌面要一致。

问：移动端302跳到m.子域会影响SEO排名吗？

302本身没问题，但移动优先索引以后Google更看主版本。建议直接做响应式或者301合并到主域，长期302会让Google继续把两端当独立URL算，权重摊在两个上。

问：ETag用什么字符串才不会和If-Modified-Since冲突？

ETag用强校验时建议用版本号加哈希组合，比如内容MD5前12位加mtime，弱校验前缀W给Last-Modified兜底。两个头是OR关系，命中其一即可304，不会冲突。

问：451状态码会让整个网站都被降权吗？

不会。451只表示当前URL因法律原因不可用，是页面级影响，Google会保留该URL在索引中但标注法律下架。但若整站长期大面积返回451，索引覆盖率与抓取频率会一起降。

问：临时下架返503超过一周以上要怎么避免索引大量丢失？

503响应必须带Retry-After头告诉Google多久后再来，且页面要明确标注维护中而非404。超过一周建议改为带预期完成日期的具体页面，并提交一份临时sitemap让Google知道哪些URL还在。