Search Console 里那串 404，我用 gcloud 脚本扫了三小时

上周接了个外包小单，客户是个卖手工皮具的独立站，之前外包团队跑路，丢给我一句「SEO 后台一堆报错，你看看」。我打开 Search Console，索引覆盖里 404 那栏挂了 1800 多条，点进去一条条看，全是 /product/xxx?from=old 这种带旧参数的老链接。

问题是客户站上个月刚换过域名结构，老路径在新站里根本不存在，这些 404 是搜索引擎还抱着旧索引没放。手工在「网址移除」里一条条提交是不可能的，1800 条能点到明年。

我先用 Search Console 的「网址检查」和 API 混合的办法。Search Console API 本身不直接给 404 列表，但可以走 URL Inspection 的批量检查。我先在 Cloud Shell 里把站点验证的凭据挂上，然后跑了个最笨的脚本：

gcloud auth application-default login
gcloud config set project my-gsc-scraper

from googleapiclient.discovery import build

svc = build('searchconsole', 'v1')
site = 'sc-domain:example.com'
# 分页拉站点地图里所有已知 URL
resp = svc.sitemaps().list(siteUrl=site).execute()
for sm in resp.get('sitemap', []):
    print(sm['path'], sm.get('lastDownloaded'))

这一步只拿到 sitemap 清单，拿不到 404 明细。真正的 404 列表藏在 Coverage 报告里，而那个报告没有公开 API。我绕了一圈，最后用「把 404 前缀聚合成通配规则」的思路：Search Console 的移除工具支持按前缀提交，我手动把 1800 条按 /product/、/old-blog/、/?from= 聚成 7 个前缀，再逐个提交临时移除。

为什么这样取舍：一条条提交精确但不可持续，前缀提交粗但能一天内压掉 90% 的噪音。代价是前缀可能误伤新站里同前缀的正常页面——我提交前把 /product/ 下的新链接在新站爬了一遍，确认新站商品页全是 /shop/ 开头，才敢按 /product/ 提交。

失效的地方也很明显：临时移除只保 6 个月，到期搜索引擎要是还没重新抓，404 会原样回来；而且前缀移除对参数型 URL 无效，?from=old 这类得单独处理。我第一版就栽在这，提交完 /product/ 前缀以为万事大吉，结果一周后带参数的旧链接又冒出来一百多条。后来改成在 nginx 层把 ?from=old 301 到新商品页，才算堵住源头。

现在剩下的是 200 多条既没前缀规律、新站也没对应页面的死链，只能等它自然掉。你们遇到这种「老站迁移留下的长尾 404」，是硬等搜索引擎自己清，还是会在边缘层直接 410 掉？我有点拿不准 410 和 301 混用会不会反而拖慢收录。