WordPress排名：网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f3673c1426ed.html
📄
WordPress排名：网站迁移应准备哪些记录
迁移WordPress网站前，最该先准备的不是压缩包，而是一份可交接的记录清单：谁在什么时候改过什么、哪些设置影响搜索引擎可见性、迁移后如何逐项验证。多人协作时，这份清单能减少“我以为你改过”的返工，也能让排名波动出现后快速定位原因。
准备阶段：先记录会影响排名的站点状态
迁移前一周，先把当前状态固定下来，作为之后对比的基线。重点记录以下内容：
- 固定链接结构：在WordPress后台“设置—固定链接”中记录当前使用的结构，例如
/%postname%/。迁移后若结构变化，旧链接容易失效。 - 已收录页面的URL清单：从站点地图或搜索控制台导出主要页面地址，标注哪些是流量入口页、哪些是转化页。
- robots.txt内容：逐行记录当前规则，特别是是否屏蔽了某些目录。迁移后若误加屏蔽，页面可能无法被抓取。
- 重定向规则：记录服务器或插件中已有的301跳转，包括来源地址和目标地址。
- 标题与描述模板：如果使用了SEO插件统一生成标题、描述，记录模板逻辑，避免迁移后全部重置。
- 站点地图地址：记录当前提交给搜索引擎的站点地图路径，迁移后需要重新确认可访问。
这一步的关键判断是：凡是“迁移后可能被重置”的设置，都要有文字或截图记录。多人协作时，建议把记录放在共享文档中，并注明负责人和更新时间。
实施阶段：记录每一次变更，而不是只记录结果
迁移过程中，最容易丢失的是操作顺序。建议按时间线记录：
- 谁在什么时间导入了数据库，导入了哪个版本。
- 是否更换了域名、服务器或HTTPS证书。
- 是否修改了
wp-config.php中的站点地址。 - 是否批量替换了数据库中的旧域名。
- 是否启用了新的缓存、安全或SEO插件。
假设一个场景：迁移后某栏目页排名下降。如果记录显示该栏目在迁移时被批量替换了URL，且没有补301跳转，就能较快判断问题方向；如果没有任何记录，只能逐项猜测。这里的判断依据是“变更记录是否足以还原操作路径”，而不是“是否记得改过”。
验证阶段：用检查项确认迁移没有破坏可见性
迁移完成后，不要只看首页是否能打开。按下面清单逐项验证，并记录结果：
- 旧URL访问时是否返回301到新URL，而不是404或302。
- 新URL是否返回200状态码。
- robots.txt是否仍允许抓取，是否误屏蔽了整站。
- 站点地图是否可访问，且包含新域名下的地址。
- 页面标题、描述、规范地址是否指向新域名。
- 内部链接是否仍指向旧域名，若存在，记录数量和处理方式。
验证结果要写成“已确认”或“待处理”，不要只写“应该没问题”。多人协作时，每个检查项最好有一个人签字确认，避免交接模糊。
维护阶段：迁移后持续记录排名相关变化
迁移后的两到四周，记录搜索控制台中的抓取错误、索引状态和主要页面的展现变化。这里要注意：排名波动可能来自迁移、内容更新、竞争对手变化或搜索引擎重新评估，不能只凭一次下降就断定是迁移导致。记录的作用是提供对比依据。
如果发现旧URL仍被访问，优先补301跳转；如果发现新页面未被收录，先检查robots.txt和站点地图，再检查页面是否有规范地址冲突。维护记录应包含日期、现象、已做操作和下次检查时间。
最关键的一步：把记录变成可交接的检查表
准备记录不是写日记，而是形成一张迁移检查表。表中至少包含：项目、迁移前状态、迁移后状态、负责人、验证结果。多人协作时，这张表就是交付凭证。没有它，返工往往发生在“谁改过固定链接”“谁提交过站点地图”这类问题上。
下一步：在迁移开始前，先建好这张检查表，并把固定链接、robots.txt、站点地图和重定向规则四项填完，再执行迁移。
