📍 WDQWDWQD987AAAAA:216.73.216.138
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7ca169f7eef3.html
📄

重庆虚拟主机：改版或迁移时应核对什么

把站点从一台重庆虚拟主机迁到另一台，或对现有站点做改版时，真正要核对的不是“文件有没有传完”，而是域名解析、站点根目录、数据库连接、伪静态规则、HTTPS证书、抓取与索引信号这几项是否同步。任何一项漏掉，都可能出现首页正常、内页404，或页面能打开但搜索引擎仍抓旧内容的情况。下面用一个假设例子展开，再给出可直接执行的核对清单。

假设例子：一次漏改伪静态的迁移

假设某企业站原来放在重庆虚拟主机A，程序是常见CMS，使用伪静态链接。运维把文件打包上传到虚拟主机B，导入数据库，修改配置文件里的数据库地址和密码，然后切换域名解析。前台首页能打开，但点进文章列表全部404，后台也无法登录。

排查顺序应当是：

1. 先确认数据库连接。后台登录失败、页面报连接错误，通常是配置文件中的数据库主机、库名、用户名、密码没有对应新主机。
2. 再确认站点根目录。虚拟主机常把域名绑定到某个目录，文件若上传到上一级，首页可能来自旧缓存或默认页。
3. 然后确认伪静态规则。Apache环境看.htaccess是否随文件上传，Nginx环境看主机面板是否提供了对应的重写规则。规则缺失时，动态链接能开、伪静态链接404，这是很典型的信号。
4. 最后确认缓存。程序缓存、CDN缓存、浏览器缓存任一层没清，都会让修改看起来“没生效”。

这个例子里，404的原因可能是伪静态规则缺失，也可能是根目录绑定错误或文件权限问题；只有在确认动态链接可访问、而伪静态链接失败后，才能把范围缩小到重写规则。多人协作时，把“已定位的原因”和“待验证的猜测”分开记录，能减少返工。

迁移前必须固定的三份信息

多人协作最容易出问题的地方，是每个人手里的信息不一致。迁移前先把以下内容写进同一份交付文档：

• 域名与解析：当前A记录或CNAME指向哪里，TTL是多少，切换由谁执行。TTL较长时，解析生效会有延迟，不要刚改完就断言失败。
• 数据库：原库大小、字符集、表前缀，以及新主机上对应的连接信息。导入后核对文章数、用户数是否与原库一致。
• 目录与权限：站点根目录路径、需要写入权限的目录（如缓存、上传目录）。权限过松有风险，过严会导致上传和缓存失败。

改版时容易忽略的SEO核对项

改版比单纯迁移多一层风险：URL结构可能变化。需要核对的是：

• 旧链接是否做了301跳转到新链接，且跳转目标是一一对应的，不是全部跳到首页。
• 页面标题、描述、正文是否在改版中被模板覆盖或清空。
• 移动端与桌面端是否指向同一套内容，而不是两套互相竞争的地址。
• 站点地图是否更新为改版后的地址。需要注意，站点地图不保证收录，它只是提交线索。
• robots.txt是否误屏蔽了新目录。也要注意，robots.txt的抓取限制不等于可靠的索引移除，已收录页面不会因为加了屏蔽就立刻消失。
• HTTPS证书是否覆盖当前域名，混合内容是否清理。HTTPS是传输加密，不保证站点无漏洞，也不保证排名。

上线后的检查项与判断结果

上线后按下面顺序逐项验证，每项都给出可判断的结果：

1. 用无痕窗口访问首页、栏目页、详情页各一个，全部返回200，说明基本访问正常。
2. 查看页面源代码，确认标题和正文是新版本内容，说明模板和缓存已更新。
3. 用站长平台或日志查看抓取情况，确认新地址能被抓取。不同搜索引擎的支持和工具界面不同，需分别核查。
4. 抽查十条旧链接，确认301跳转指向正确的新地址，而不是404或首页。
5. 提交更新后的站点地图，并在几天后观察索引变化。收录速度不由提交动作决定，不要用固定天数承诺结果。

如果某项不通过，先判断是配置问题还是缓存问题：配置问题改完立即生效，缓存问题需要等缓存过期或手动清理。把判断依据写进交付记录，下一个人接手时就不会重复排查。

下一步

现在就把上面“迁移前三份信息”和“上线后检查项”合并成一张核对表，指定每项的责任人和验证方式，迁移或改版完成后由另一人按表复验，而不是由执行人自己确认。