为了离线秒开给全站上了 PWA 与 Service Worker，搜索收录与快照却彻底崩盘？排查离线页投毒全站快照、sw.js 强缓存成僵尸与爬虫沙箱拦截我踩过的几个深坑

AI 摘要由 AI 生成

为提升用户体验，作者在全站实施PWA和Service Worker，实现离线秒开，却发现搜索收录和快照严重受损。通过排查发现，Service Worker在搜索引擎沙箱中触发一系列连锁反应，导致抓取频次和权重下降。文章深入分析问题根源，并提出了解决策略。

上个月折腾博客的移动端体验，看着 Lighthouse 跑分里 PWA 那一项始终飘灰，心里总觉得差点意思。按照官方文档的推荐，我给全站接了一套标准的 Service Worker 离线缓存，心想既能实现断网可读，又能让常客在弱网下实现毫秒级打开，顺手还能多赚点性能分。

上线跑了两天，手机端滑动确实顺滑如丝，秒开的感觉让人相当上头。

然而好景不长。到了例行核对站长平台数据的日子，打开 Google Search Console 和百度站长平台的抓取监控，我的后背瞬间凉了半截：全站索引量从高位出现直角下坠，几个长期排在第一页的硬核长尾词几乎在一夜之间跌出前五十。用 URL 检查工具调出搜索引擎抓取到的渲染快照，屏幕上赫然显示着一行灰色提示语：

“当前网络连接异常，系统已自动切入离线模式。”

从首页到几百篇技术长文，快照里的正文、代码高亮、内链和结构化标记无一幸免，全被这页离线兜底占位符抹得干干净净。搜索引擎把这批页面判定为内容重复且毫无价值的空壳，抓取频次与权重随之雪崩。

一个本意为了提升弱网鲁棒性的前端功能，硬生生把源站的 SEO 推进了火葬场。把线上事故排查完后，我把这次 Service Worker 在搜索引擎抓取沙箱里触发的一连串连锁反应梳理了一遍，特别是几个隐藏极深的工程细节。

Workbox 导航兜底策略把爬虫带进了离线沟里

很多人对搜索引擎爬虫的理解还停留在“只抓纯 HTML 字符串”的阶段。实际上，不管是 Googlebot 的 Evergreen Chromium 还是各大现代搜素引擎的渲染集群，早就在无头浏览器环境里执行真实的客户端 JavaScript 代码了。

既然执行 JS，很多爬虫沙箱便会按部就班地解析页面底部的脚本，顺便把 navigator.serviceWorker.register('/sw.js') 给执行了。

问题就出在这里。为了实现所谓的离线容灾，我用 Workbox 配置了一套典型的 NavigationRoute 兜底逻辑：

import { registerRoute, NavigationRoute } from 'workbox-routing';
import { NetworkFirst } from 'workbox-strategies';

// 当网络超时或异常时，把页面导航重定向到离线提示页
const navigationHandler = async (params) => {
  try {
    return await new NetworkFirst({
      networkTimeoutSeconds: 3,
      cacheName: 'pages-cache',
    }).handle(params);
  } catch (error) {
    return caches.match('/offline.html');
  }
};

registerRoute(new NavigationRoute(navigationHandler));

逻辑在本地开发时测得很舒服：拔掉网线，页面立刻降级到 /offline.html，既友好又健壮。

但是在爬虫沙箱的并发抓取场景下，这套策略直接酿成灾难。

爬虫沙箱为了防范恶意脚本拖垮渲染集群，对单个页面脚本执行以及子资源拉取设置了极其严苛的资源配额与超时阈值。当多个蜘蛛 IP 高频抓取内页时，爬虫沙箱的虚拟网络栈往往会限制并发连接，甚至把渲染等待时间压缩到极限。

一旦内页网络请求在沙箱内稍有迟滞触发了 networkTimeoutSeconds: 3，或者沙箱直接切断了二次发起的数据通道，Workbox 的 catch 块就会立刻被击穿，继而返回那张预先缓存好的 /offline.html。

更致命的地方在于 HTTP 响应状态码。Service Worker 拦截了网络请求并从 CacheStorage 中吐出 /offline.html 时，返回的 HTTP 状态码默认是 200。

在搜索引擎眼里，这个行为的含义是：你这个 URL 正常返回了内容，且正文就是“当前网络连接异常”。当爬虫连续抓取了几十个不同 URL，得到的全是一模一样的 200 响应与重复文本，算法直接触发了质量拦截，把整批页面归类到低质克隆页，快照彻底被投毒。

Nginx 把 sw.js 强缓存了 30 天，紧急修补成了刻舟求剑

发现快照异常后，我的第一反应是立刻改代码：把 navigationHandler 里的离线兜底逻辑砍掉，让请求在网络出错时直接穿透抛出原生错误，绝不返回假冒的 200 离线页。

前端构建完成，打包上传，CDN 刷新一气呵成。

然而过了整整两天，无论是用无痕沙箱复测还是观察新抓取的快照，旧的 Service Worker 依然像鬼魅一样牢牢霸占着拦截层，离线页依然在源源不断地吐给客户端。

我跑去终端里用 curl 查了一下入口脚本的响应头：

curl -I https://www.llbbs.cn/sw.js

终端打印出的结果让我倒吸一口凉气：

HTTP/2 200
server: nginx
content-type: application/javascript
cache-control: public, max-age=2592000
last-modified: Thu, 15 Oct 2026 08:12:00 GMT

原来在 Nginx 之前的通用静态资源规则中，有人为了图省事，写了一句通配的正则表达式：

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, max-age=2592000";
    access_log off;
}

根目录下的 sw.js 毫无悬念地命中了这条规则，被 Nginx 强行打上了整整 30 天的强缓存标记。

虽然 W3C 规范后来针对 Service Worker 脚本做过补充说明（要求浏览器即使命中 HTTP 缓存，最长 24 小时也必须向源站发起一次更新检查），但现实环境极其残酷：很多基于老旧 Chromium 内核封装的无头渲染抓取器、部分移动端内置 WebView 以及国内定制浏览器，只要看到 max-age=2592000，就真的踏踏实实一个月不去向源站请求新版本的 sw.js。

源站代码改得再勤快，只要客户端本地的 sw.js 不发起字节级对比，旧逻辑就会一直拦截导航请求。

要彻底杜绝 Service Worker 被死死冻住，Nginx 必须把根路径脚本和依赖清单显式剥离出来，强制所有代理节点与客户端永不缓存：

# 必须放在通用 .js 匹配之前，确保精准命中
location = /sw.js {
    expires -1;
    add_header Cache-Control "no-cache, no-store, must-revalidate";
    add_header Pragma "no-cache";
    add_header Service-Worker-Allowed "/";
    access_log /var/log/nginx/sw_access.log combined;
}

# 如果用了 Workbox 的 precache 清单文件，也必须禁绝强缓存
location ~* ^/workbox-.*\.js$ {
    expires -1;
    add_header Cache-Control "no-cache, no-store, must-revalidate";
}

只有给 sw.js 加上 no-cache, no-store, must-revalidate，客户端在生命周期轮询时才能真正感知到脚本字节的变化，进而触发新 Worker 的安装与接管。

Stale-While-Revalidate 让文章收录停留在远古幽灵版本

排查过程中我还发现了另一个隐蔽的 SEO 灾难：HTML 文档缓存策略的误用。

很多人在写 Service Worker 时，喜欢把静态资源那套 StaleWhileRevalidate 顺手套在文章页面上：

import { registerRoute } from 'workbox-routing';
import { StaleWhileRevalidate } from 'workbox-strategies';

// 致命写法：对页面主文档使用过时再验证
registerRoute(
  ({ request }) => request.destination === 'document',
  new StaleWhileRevalidate({
    cacheName: 'document-cache',
  })
);

这个策略的运作机制是：一旦本地 CacheStorage 存在历史缓存，立即把旧缓存返回给页面，同时在后台异步向源站发起请求刷新缓存。

对于普通读者来说，这种方式确实能带来肉眼可见的秒开感。但对于搜索引擎爬虫来说，这简直就是一场灾难。

第一，元数据更新永远落后一个版本。当我修改了一篇文章的标题、修正了错漏的 Canonical 标签或微调了文章内的锚文本，爬虫进入页面时，Service Worker 毫不客气地先把 CacheStorage 里上个月的旧 HTML 丢了过去。爬虫提取到旧快照后就退出了沙箱，后台异步发起的网络更新就算拉到了最新内容，也根本没有机会再喂给已经结束渲染周期的爬虫。

第二，破坏状态码语义，死链永远洗不掉。当我在后台把某篇旧文章彻底删除（源站正常返回 410 Gone 或 404 Not Found），或者修改了 Slug 做了 301 永久重定向时，Service Worker 依然在客户端拦截层直接把旧文章页面按 200 成功响应吐出。

爬虫因此坚信这个 URL 依然存活，持续保留着收录和死链索引；直到几个月后由于缓存过期或其他偶发原因突然拿到 404，往往会遭遇一次性大规模死链惩罚。

对于任何具有 SEO 诉求的内容站点，根文档（document）绝不能使用 StaleWhileRevalidate。即便一定要做客户端缓存，也必须坚持 NetworkFirst，并且在网络不可达时宁可让错误暴露出来，也绝不要把过期内容伪装成新鲜页面交出。

爬虫根本不需要离线：给蜘蛛精准短路与紧急自毁机制

经历了一整套排查之后，我意识到一个最核心的认知误区：

搜索引擎爬虫爬取站点的核心诉求是抓取最新公开数据与内链网状关系，它既不会在地铁里无信号阅读你的文章，也不会需要后台定时同步或者桌面推送通知。让爬虫去执行 Service Worker 的安装与拦截，纯粹是百害而无一利。

最稳妥的工程解法，是在整个生命周期的前端与接入层彻底把爬虫屏蔽在 Service Worker 体系之外。

1. 前端注册入口做蜘蛛短路

不要无脑执行 navigator.serviceWorker.register()。在入口脚本里，预先对常见的搜索引擎 User-Agent 进行特征扫描：

(function () {
  if (!('serviceWorker' in navigator)) return;

  // 匹配常见主流搜索引擎与社交平台抓取爬虫
  const spiderPattern = /Baiduspider|Googlebot|bingbot|Sogou web spider|360Spider|Bytespider|YandexBot|DuckDuckBot|Twitterbot|facebookexternalhit/i;

  if (spiderPattern.test(navigator.userAgent)) {
    // 爬虫直接跳过，保留最纯粹的原生网络通信
    return;
  }

  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js', { scope: '/' })
      .catch((err) => {
        console.error('Service Worker registration skipped or failed:', err);
      });
  });
})();

2. Nginx 反向代理层把关

光靠前端 JS 判断还不够严密。有些爬虫在沙箱初始化阶段可能不会完全展开 UA 细节，但在向反向代理层索取资源时，HTTP 请求头里的 User-Agent 是板上钉钉的。

在 Nginx 层对合规爬虫请求 /sw.js 做熔断拦截：

# 识别合规蜘蛛
map $http_user_agent $is_search_spider {
    default 0;
    ~*(Baiduspider|Googlebot|bingbot|Bytespider|360Spider|Sogou) 1;
}

server {
    listen 443 ssl http2;
    server_name www.llbbs.cn;

    location = /sw.js {
        # 爬虫请求 sw.js 直接返回 204 无内容，阻止安装
        if ($is_search_spider) {
            return 204;
        }

        expires -1;
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        add_header Service-Worker-Allowed "/";
    }
}

当爬虫看到 204 No Content 时，无头浏览器会安静地放弃 Service Worker 注册，整个渲染流程回退到最干净、最可靠的原生服务端响应模式。

3. 线上失控时的紧急自毁开关（Kill Switch）

如果线上已经被有缺陷的 Service Worker 深度污染，大量客户端和缓存沙箱依然在顽固地拦截页面，单靠改源站业务代码已经无法救场。此时需要立刻部署一段自毁版 sw.js：

// self-destruct sw.js
self.addEventListener('install', () => {
  // 强行跳过等待，立即接管
  self.skipWaiting();
});

self.addEventListener('activate', (event) => {
  event.waitUntil(
    // 1. 清空所有现存的 CacheStorage
    caches.keys().then((keys) => {
      return Promise.all(keys.map((key) => caches.delete(key)));
    }).then(() => {
      // 2. 释放当前域下所有客户端的控制权
      return self.clients.claim();
    }).then(() => {
      // 3. 注销自身
      return self.registration.unregister();
    })
  );
});

// 所有拦截全部直通网络，不留任何痕迹
self.addEventListener('fetch', (event) => {
  event.respondWith(fetch(event.request));
});

把这份代码部署到源站的 /sw.js 路径，并在 Nginx 确保无缓存。任何访问到该脚本的客户端都会自动执行三连操作：强行激活 -> 抹除本地全部旧文件缓存 -> 彻底注销自身。

把爬虫熔断规则上线，再用自毁脚本把旧缓存彻底清洗完毕之后，我在各站长工具后台对关键页面逐一提交了重新抓取诊断。

看着新生成的快照里终于重新刷出完整首屏 HTML、结构化数据和内链网格，整个站点的索引曲线才算开始缓慢爬升修复。

前端新技术在提升终端体验上确实诱人，但凡是涉及网络代理层、缓存劫持层与客户端状态驻留的技术，一旦上线就必须把它放在搜索引擎爬虫的严苛视角下反复审视。很多时候，对爬虫而言，不加任何自作聪明拦截的原生响应，往往才是最安全、最经得起考验的解法。