你刚把网站迁完，结果第二天发现：首页打不开、产品页404、后台白屏……老板在群里问“到底行不行”，你盯着错误日志手心冒汗——别急，这真不是你技术不行，是迁移前少看了三张纸。
我去年帮6个客户做迁移，两个翻车翻得特别典型：一个教育类SaaS站，因为漏了.htaccess里的缓存头规则，用户反复刷新还是加载旧JS；另一个本地生活平台，新服务器没开mbstring，所有带中文标题的详情页全报500。今天这份清单，就是从这些坑里一锹一锹挖出来的。
迁移前必须备份哪3样东西？
别只备份数据库和文件。robots.txt和.htaccess这种小文件，藏的是搜索引擎怎么看你、用户怎么访问你的底层逻辑。
第一样：完整网站文件包。用FTP或SFTP把整个根目录拖下来，包括所有以.开头的隐藏文件（比如.gitignore、.user.ini）。服务器自动备份？那只是安慰剂，手动存一份到你电脑硬盘才叫落地。
第二样：数据库完整导出。用mysqldump --complete-insert，确保建表语句和数据一起出来。我见过只导了wp_posts表，忘了wp_options里存着主题设置和插件配置，迁移后整个后台风格全乱。
第三样：当前所有URL的列表。用 Screaming Frog 或 Sitebulb 爬一遍全站，导出CSV。跳过这步的人，上线后才发现“关于我们”“合作流程”这些页面根本没映射过去，404堆成山。
去年帮朋友迁一个本地装修公司的站，就因为没备份nginx.conf里的gzip压缩和图片缓存规则，上线后首屏加载慢了两倍，用户直接关掉——这种细节，不写进检查表里，真容易忘。
新服务器环境要验证5个关键点
旧环境跑得好，不代表新环境能接住。PHP差一个小版本，json_encode()就可能崩；字符集不对，中文标题秒变问号。
第一点：PHP版本和扩展是否一致。在旧服务器上跑php -v和php -m，记下版本号和扩展名；新服务器上逐条比对。重点盯mbstring（处理中文）、curl（调API）、openssl（HTTPS请求）这三个，缺一个都可能让功能静默失效。
第二点：数据库字符集是否匹配。两边都执行SHOW VARIABLES LIKE 'character_set%';，确认character_set_database和collation_database一样。常见坑是旧库用utf8mb4，新库默认latin1，一迁移，客户留言全变“????”。
第三点：文件上传大小限制。查php.ini里的upload_max_filesize和post_max_size。很多新环境默认2M，但你的后台要上传3MB的施工图？直接卡在上传按钮上。
第四点：内存限制。memory_limit别设太低。有客户把256M改成64M，结果WordPress后台编辑文章时，富文本编辑器直接白屏——不是插件冲突，是PHP进程被内存掐死了。
第五点：伪静态规则。Apache的.htaccess不能直接扔进Nginx。比如WordPress的经典规则，在Nginx里得重写成try_files $uri $uri/ /index.php?$args;，硬复制会500报错。
如何用300个URL验证迁移完整性
全站几万URL？没必要。挑300个有代表性的，覆盖关键路径就行。
打开你的Google Search Console，导出最近90天有曝光或点击的URL。从中选前100个——这些是搜索引擎正在推的页面，丢一个，流量就少一分。
再挑100个业务命脉页面：比如电商站的“立即购买”按钮所在页、知识付费站的“试听课程”页、B2B站的“免费获取方案”落地页。这些页面挂了，转化链直接断掉。
最后100个，专挑冷门但不该消失的页面：三年前的行业报告、老客户案例归档、已下架产品的历史介绍页。它们流量少，但长期404会被搜索引擎判定为“内容不可靠”，连带影响整站权重。
用 curl -I 配合 cat urls.txt | xargs -n 1 -P 10 curl -I 批量测状态码。看到404、500、302就标红，当天必须修完。有个客户用这法子，五分钟揪出所有带?utm_source=参数的URL全跳首页——因为重定向规则没配通配符。
301重定向最容易踩的3个坑
重定向不是写个“301跳转”就完事。写错一个字母，搜索引擎就当你在耍它。
第一个坑：用成了302。302是临时跳转，权重不传递。用curl -I 旧URL看返回头，必须有HTTP/2 301。有客户用Redirection插件，一直没关“临时重定向”开关，两个月后发现首页权重掉了七成。
第二个坑：忽略URL参数。/product?id=123&ref=wechat这样的链接，如果重定向规则只匹配/product，后面参数全丢，用户点进来永远看到ID=1的默认页。规则里得加(.*)捕获并透传参数。
第三个坑：重定向套娃。A→B→C→A，浏览器直接弹“ERR_TOO_MANY_REDIRECTS”。写新规则前，先在旧站用curl -L -v 旧URL跑一遍，看清当前跳了几步、终点在哪，再照着逻辑重写。
迁移后48小时内必须盯着哪些数据
上线不是终点，是观察期的开始。前48小时发现问题，回滚成本最低；拖过一周，搜索引擎已经打上“不稳定”标签。
第一个数据：服务器错误日志。tail -f /var/log/nginx/error.log或/var/log/apache2/error.log，开着终端盯。刷出一堆PHP Fatal error: Uncaught Error: Call to undefined function mb_substr()？说明扩展没装全。
第二个数据：Google Search Console的“覆盖率”报告。24小时内刷新，看“有效”页面数有没有断崖下跌。如果从8000掉到2000，大概率是robots.txt封了，或新站没提交sitemap。
第三个数据：核心页面的加载时间。用Chrome DevTools的Lighthouse跑5个关键页（首页、产品页、下单页、博客列表、联系页），重点关注“首次内容绘制（FCP）”和“可交互时间（TTI）”。比旧站慢50%以上？赶紧查CDN配置或PHP OPcache。
第四个数据：关键操作流是否走通。注册、登录、加购、下单、支付回调、邮件发送——全部手动走一遍。有客户迁移后邮件服务没切到新SMTP，用户注册收不到验证码，三天流失200+线索。
第五个数据：CDN缓存是否清空。如果你用Cloudflare、又拍云或腾讯云CDN，上线后立刻进控制台清空全部缓存，并确认“源站地址”已指向新IP。否则用户刷半天，看到的还是旧服务器吐的HTML。
迁移后排名掉了我该怎么办
排名波动很正常。搜索引擎要重新抓取、渲染、评估新服务器上的页面，快则3天，慢则两三周。
第一步：直连https://你的域名/robots.txt，确认里面没有Disallow: /。很多人迁移时把旧服务器的robots.txt直接拷过去，等于主动告诉谷歌：“别来。”
第二步：在Google Search Console里提交新的sitemap.xml。别等它自己发现，主动喂给它。如果还没生成，用RankMath、Yoast或在线sitemap生成器快速拉一个。
第三步：爬一遍新站，查内部链接。用Screaming Frog切换到“Internal Links”标签页，筛选出所有带旧域名的链接（比如http://old.com/contact）。这些链接不仅浪费爬虫预算，还可能把权重悄悄导流回旧站。
有个客户迁移后排名掉到搜不到，查了一圈发现：所有文章里的图片src还是旧域名，CDN没配好，图片全404。Google认为页面体验极差，直接降权。换完图片链接，两周后回到前三页。
今天就能做的3件事
- 打开你网站的
robots.txt，访问https://你的域名/robots.txt，确认没有Disallow: /这一行。有就删，5秒搞定。 - 打开终端（Mac/Linux）或Git Bash（Windows），输入
curl -I https://你的域名/某个老页面路径（比如/about），看返回是不是HTTP/2 200或HTTP/2 301。不是？马上去检查重定向配置。 - 登录Google Search Console，点左侧“索引”→“站点地图”，把新的
sitemap.xml地址（比如https://你的域名/sitemap.xml）粘进去，点“提交”。
这三步做完，你今晚就能睡个踏实觉。