换主题之后排名掉下来，多数情况不是新主题不如旧主题，是旧主题输出的东西新主题没输出。标题的生成逻辑、结构化数据的类型、集合内产品路径的处理方式，全都写在主题文件里，换主题等于把这整层替换掉，没被搬过去的部分会静默消失，页面上看不出任何异常。改版要做的事情，是先把这些看不见的输出列成清单。
改前先冻结一份快照
冻结的意思是把改版前的状态存成能逐条比对的东西，不是凭记忆回忆。下面这几项缺一项，验收时就少一个判断依据。
没有基线，改完无法比对（光算 · 示意图）
| 冻结项 | 从哪儿取 | 验收时用来判断 |
|---|---|---|
| 页面类型与 URL 形态 | 全站抓一份 URL 清单 | 改版后是否出现新形态或丢页 |
| 模板级元信息 | 几类代表页面的源码头部 | 标题、描述、canonical 是否还在 |
| 结构化数据 | 页面里的标注片段 | 产品、面包屑等类型是否漏输出 |
| 内链入口 | 导航、面包屑、相关产品、文章互链 | 抓取路径是否被切断 |
| 图片与资源地址 | 图片地址与文件名 | 图片是否被换了文件名或尺寸 |
抓全站 URL 清单不需要专业工具。站点的 sitemap 就是产品、集合、页面、博客四类条目的现成来源，但它覆盖不到集合内路径和参数形态，这两部分要在页面上实际点一遍，把带参数的地址记下来。
清单里的 URL 形态要覆盖完全：产品在集合里的路径、分页、排序与筛选参数都算形态。这些地方最容易在换主题时被简化掉，而它们恰好是搜索引擎已经处理过的入口，重建的成本比保留高得多。
换主题最容易丢的三类东西
第一类是模板级元信息。平台对搜索结果条目的说明提到，标题来自页面标题、描述通常取自页面内容，主题在后台设置之上还会按页面类型做条件输出。新主题如果只覆盖了产品页与首页，博客文章和集合页的标题生成就会退回默认状态，改版前后对比那一栏就能看出来。
第二类是结构化数据。平台说明里写明主题自带结构化数据，产品页会包含价格、库存、评价相关内容，官方支持的主题与主题商店里的主题都默认带这项能力。换主题后要确认三类输出是否还在：产品、面包屑、组织信息。产品结构化数据的官方说明把两种取向分了开，不能直接下单的产品页用 Product snippets，可以直接购买的产品页用 merchant listings，字段要求的差别就在这里；面包屑标注的价值是让搜索引擎理解页面层级，前提是页面上确实存在对应的导航路径，标注和真实导航不一致时它帮不上忙。
第三类是被主题覆盖的 URL 处理。站内搜索、排序和筛选这类功能会产生内容相同但 URL 不同的页面，canonicalization 文档把这种情况归为站内功能造成的重复，并明确说明用 canonical 表明偏好只是提示，Google 可能选择另一个页面作为代表页。旧主题里那段判断逻辑没搬过去，站点就退回平台默认状态，平台能兜住一部分，兜不住主题特有路径。同一产品在集合内外的两种路径与排序、筛选的状态处理都属于这一类，改版时按这两篇的检查点各过一遍。
把主题和内容分开看，问题范围会小一半
主题负责渲染，内容存在后台。换主题不改产品标题、描述和价格，但会改变这些内容被呈现的条件：原来正文里那段规格表可能来自元字段渲染，新主题没接这个字段，内容还在后台，页面上却没了。排查时先确认这一点，能少走很多弯路，不至于把内容问题当代码问题查。
它们通常不在页面上直接可见（光算 · 示意图）
对应的做法是改版前列出所有依赖主题渲染的后台数据，元字段、产品选项、集合描述、博客文章摘要各算一类，改完逐个页面对照。这类内容的消失不会报错，也没有日志，只能靠比对发现。
改版前要定下来的三件事
第一件是导航结构动不动。导航是抓取路径的主干，改版时顺手重做导航很常见，但链接目标一旦从集合页换成筛选参数，抓取入口就变了，主题可访问性检查里键盘导航那几项，改版时也常常被一起改坏。
第二件是图片文件名会不会变。主题经常对图片地址做格式转换，文件名和尺寸参数变化本身不致命，但新主题如果输出了不同的地址形态，就要确认旧地址是否仍可访问。
第三件是结构化数据由谁输出。平台说明里主题自带的标注和应用注入的标注可能并存，改版前先分清页面上的标注来自哪一侧，否则新主题里会出现重复标注，或者两边都以为对方会补上。
改后按这个顺序验收
- 抓取是否放行：根目录的 robots.txt 能正常打开，店铺不在密码保护状态。
- 索引入口是否完整：sitemap 索引与产品、集合、博客子表都能访问。提交成功只说明提交成功，说明不了收录结果，平台文档也说爬取与索引需要时间且不作保证。
- canonical 是否正确：抽产品页、集合页、文章页各若干，看是否自指、是否指向同语言同地区的版本。
- 条目标题是否回来了：拿冻结的源码头部跟新页面逐个比，重点看集合页、文章页、静态页，这三类最容易被漏掉。
- 结构化数据是否还在：先看源码里标了什么，再看结果报告认了什么，两件事不是一回事，报告与真实展示之间的差距要单独核。
- 内链是否连通：导航、面包屑、相关产品、文章到产品的链接都能爬到，锚文本指向的还是原来那类页面。
- 404 与重定向：把冻结的 URL 清单跑一遍，新增的 404 当天处理，不要攒到下周。
七项里前两项不通过，后面的检查都没有意义，抓取被挡住的站点看收录数据只会得出错误结论。顺序固定下来以后可以写成一张表，每次改版照着跑，比临时想检查项可靠得多。
分批发布，别一次全站切
一次全站切换的问题不是风险大，是出问题之后定位不了。先切影响面小的模板，比如博客文章和静态页面，观察抓取与条目标题；确认无异常再切集合页；产品页与首页放最后。这样任何一个环节出问题，范围都是明确的，回滚的代价也小。
旧主题的副本别在切换成功之后就删。回滚的成本远低于在问题里找原因的成本，而旧主题文件是唯一的对照物。主题演示数据不能当验收标准，演示内容的数量与结构和真实目录经常不一样，尤其是集合与产品的实际规模。
改版期间的数据不要连着比
上线后的表现数据不能直接和改版前连成一条线看，抓取与重新处理需要时间。有用的做法是分开看两类信号：抓取和索引层面的信号来得快，新地址是否被发现、404 是否增加、条目标题是否恢复，这些几天内就有迹象；排名与点击层面的信号来得慢，把它和索引信号混在一起看，很容易得出改版有效的结论。
把改版日期在数据里标出来，后面复盘时有依据。如果一次改版同时动了主题和内容，两边的效果就再也分不开了，这也是分批发布的另一个理由。
边界：改版解决不了的事
没有哪个主题天然比另一个更利于排名，改版能做的是不丢东西，做不到让排名上升。排名变化还与内容质量、外链、竞争程度有关，把改版当成一次提升排名的手段，很容易在几周后得出错误结论，然后把下一次改版也做错。
平台负责的部分不要重复劳动：sitemap 自动生成并在新增内容时自动更新，主题默认输出结构化数据，这两件事都不需要做，也不要在迁移过程中弄丢。导航与大型菜单这类结构在改版时经常被重新设计，链接目标有没有变、能不能被爬取，属于验收清单第 6 条要覆盖的内容。
还有一处容易忽略：换主题带走的是主题文件，应用重新注入的脚本会跟着新主题再进来一次。非主题输出的那部分要单独核对，特别是评论、推荐、弹窗这类组件带来的标注，它们可能在同一页上重复输出同一类结构化数据。
还有一处需要自己核实：旧主题文件里那些不再被引用的自定义模块会留在文件列表里，不生效也不影响前台，但留着会让下一次排查变慢，清理时机自己定。
改版验收之后才是常规节奏的开始：持续的技术检查、内容更新、外链建设。光算的谷歌 SEO 服务做的是这一段，改版通常是它开始之前的准备工作。主题目录各部分的职责决定了动手时要打开哪些文件，认清结构再改，比事后排查省事得多。