志睿源官网｜收录优化第二轮：产品页与栏目页服务端渲染 上线记录

零、结论

上一轮把文章页修好了；这一轮把产品详情页和栏目详情页也修好了 —— 共 23 个页面从「机器看到的空壳」变成完整内容页。全站 101 条地址现在：

先纠正我上一份报告的一个错估：当时写「约 50 个地址仍是空壳」，是按模板类型推的，没有实测。实测下来是 23 个（11 个产品详情 + 12 个栏目详情），剩下的 70 篇文章上一轮已经做完。也就是说这件事的成本比我估的低得多，所以这一轮直接做掉了，不再留给你决策。

---

一、这一轮做了什么

1. 产品详情页（11 个）

改前：源码里 6 636 字节、可见文字 179 字、没有一级标题、11 个页面标题全是同一句「产品详情」。机器打开就是一张写着「产品详情」的白纸。

现在服务端直接输出：产品名作为一级标题、一句话定位、解决什么问题、核心能力、适用场景、详细说明正文、相关文章、进展记录、产品信息、开源仓库链接、其他产品链接。

2. 栏目详情页（12 个）

改前：源码里 10 161 字节、可见文字 376 字 —— 这 376 字全是导航和页脚，正文零；12 个页面标题全是「栏目详情」；页面上还留着「加载中…」。

现在服务端直接填好：栏目标题、状态、一句话、摘要、侧栏事实、进展记录、相关文章、过程记录。

栏目页的模板本来留了具名插槽（标题、摘要、侧栏、时间轴、文章区各有容器），所以这一处是「填格子」，不是重排版 —— 风险比产品页还低。

3. 站点地图补「最后修改时间」

上一轮只有文章带日期，栏目页和产品页没有。没有日期的地址，抓取方给的抓取优先级最低。

现在栏目页与产品页的日期取自它名下最新一篇文章的发布日期 —— 这两个页面的内容确实由文章构成，日期是真的，不是凑一个。

4. 后台保存后缓存立即失效（消除「刚发完看不到」）

页面正文现在走服务端缓存（最多 5 分钟）。原先的坑：你在后台点保存，再刷新看到的还是旧稿，很容易误判成保存失败。

现在后台所有内容改动（文章、产品、栏目、进展的新增/修改/删除）都会立刻清空缓存。做实测量化：清空后首次取页 0.278 秒（重建），再次取 0.006 秒（命中），差 47 倍 —— 说明缓存确实在工作，也确实被清掉了。

为什么是「整体清空」而不是「只清这一篇」：改标题会连带影响所属栏目页、产品页和站点地图，逐个追踪必然漏。缓存上限只有 300 条，整体清空的代价可以忽略。

5. 顺手修的两个小瑕疵

• 分享卡片标题原来带着「· 志睿源」后缀（页面标题该带，分享卡片不需要，平台自己会加站名）。现已分开：页面标题带站名，分享卡片只留内容标题。
• 两组同标题撞车：产品「nagent」与栏目「nagent」、产品「showtext.js」与栏目「showtext.js」标题完全一样，但两个地址内容不同。现在栏目页标题多一段「进展与文章」以示区分。

---

二、上线前后对照（实测，非估算）

几个具体页面：

• product.html?code=nagent → 14 719 字节，「nagent · 志睿源」，一级标题 1 个，规范地址 1 个，结构化数据 1 份，分享图 1 张
• track.html?code=info-gap（拉平信息差）→ 28 969 字节，可见 3 781 字
• track.html?code=mdreader（MD 阅读器鸿蒙版）→ 29 515 字节，可见 3 688 字

不存在的地址

---

三、全站体检（101 条地址，逐条实取）

体检脚本已存到服务器 node/zry/tools/seo_baseline_audit.py，以后想复查收录基线，跑一次就出这张表。

---

四、改动文件与回滚

前端一个文件都没动（模板、样式、脚本全未修改），所以这一轮不需要重算静态资源版本号 —— 浏览器缓存不会造成「改了没反应」。

备份：服务器 /data/_bak/seo2_20261023_092106/（4 个服务端文件 + 站点配置原件）。回滚＝解包覆盖 → 重启应用 → 重载配置。

回滚时注意：站点配置里的限流区名（zry_page2）不要改回旧名 —— 上一轮踩过，改了会整次重载静默失败。

---

五、验证做到了哪一步（如实说明）

• 单元测试 71 项断言全过（文章页 25 项 + 产品页/栏目页/地图 46 项），覆盖：标题/描述/规范地址/结构化数据/一级标题唯一/骨架屏替换/相关文章与进展进源码/两类 404/数据库故障降级/地图日期。
• 线上逐页实取核对：101 条地址全量体检、四类探测请求、两个 404 用例、8 个接口回归。
• 缓存清理：已验证函数可调用、缓存确实被清空（用取页耗时证明），但「后台点保存后页面立刻变」这条完整链路没有做实机点击测试（需要登录后台改真实内容）。下次你在后台改一篇文章就能顺手确认 —— 若发现刷新后仍是旧稿，告诉我，我改成在数据层直接判断。

---

六、还剩三件事

① 微信真机分享卡片：5 分钟自查（只读，不改任何东西）

把一篇文章发到文件传输助手，看卡片：有没有图、标题对不对、描述是不是正文开头。

这一步是闸门：微信卡片不读网页里的分享标签，只认公众号接口授权（配安全域名 + 签名服务 + 官方脚本，3–4 小时）。我不凭推导投工。

② 百度 / 必应站点验证 + 地图提交（0.5 小时，需你的账号）

站点根目录现在没有任何验证文件。不提交，站点地图就只是个静态文件。

③ 剩 9 个地址要不要收尾（我的建议：只做 1 个）

• 博客列表页（254 字，唯一还偏薄的页面）：它是 70 篇文章的列表入口，现在整页靠脚本渲染，抓取者看不到文章链接。建议补 —— 半小时，给抓取者一条通往全部文章的直路。
• 8 个静态页（首页、在做什么、产品、服务、关于、联系、下载、博客之外的）缺规范地址与结构化数据：单地址页面，补的收益很低，建议不动。

另外仍是你的决定：41 篇行业情报日报是否要进站点地图（现在关着，改一个常量就能开）。

---

七、观察点

1. 见效周期以周计：这一轮改的是「机器能不能读懂」，不是「排名能不能上去」。看两个数就够 —— 地图的抓取状态、被收录的地址条数。
2. 缓存窗口 5 分钟：后台保存已主动清缓存，正常不会看到旧稿；但浏览器自己还有 60 秒缓存，连续刷新同一条地址时可能命中，不是故障。
3. 情报日报开关：现在不进地图（41 篇占已发布内容三分之一，采集类重复度高，全量推送有拉低整站质量评级的风险）。
4. 其他搜索引擎未放行：神马、头条、360 的来源地址段没加，它们来抓仍会被限流挡。这三家目前不是重点渠道，真要做时一次改两处（放行地址段 + 机器人识别规则）。