独立站上线检查清单:发布前的域名、SSL、重定向、跟踪全检查

独立站上线不是"点一下发布",而是一组必须逐项打勾的门禁。把问题分成P0、P1、P2三级:P0项(500报错、证书过期、表单收不到)不放不出,P1项72小时内修,P2项本周内修。

独立站上线检查:发布前的五道门禁Site Launch Checklist: five pre-launch gates 站点能打开不等于可以上线 —— 漏埋的跟踪代码三个月后才会暴露A site that loads is not yet ready — missing tracking surfaces only months later 1 域名 DNS1 Domain DNS TTL提前1周降到300秒Lower TTL to 300s one week ahead www与裸域互指验证Verify www and root redirect 2 SSL HTTPS2 SSL HTTPS 证书剩余>30天 无混合内容Cert >30 days, no mixed content HSTS开启 强制跳转443HSTS on, force 443 3 重定向3 Redirects 旧URL全部301到新映射Map all old URLs to 301 无重定向链 无循环No chains, no loops 4 跟踪与表单4 Tracking and Forms GA4事件实测一次 转化已配Test GA4 event, set conversions 提交一条测试询盘确认送达邮箱Submit test inquiry to confirm delivery 5 上线后72小时观察5 First 72-hour watch GSC提交sitemap 抓404列表Submit sitemap, audit 404s 错误率>1%立即排查Error rate >1% triggers check 门禁分级:P0不放不出(500 / 证书过期 / 表单收不到) · P1上线后72小时内修 · P2本周内修Gate tiers: P0 blocks launch (50s / expired cert / dead forms) · P1 within 72h · P2 within the week 反直觉点:团队最盯500报错,真正丢半年数据的是跟踪代码漏装Counterintuitive: teams watch 500s, but missing tracking burns six months of data 清单逐项打勾,任一项P0未过,不切DNS、不公开发布Tick every item; if any P0 fails, do not cut DNS
独立站上线前五道门禁:域名、SSL、重定向、跟踪与72小时观察

独立站上线检查清单:发布前的域名、SSL、重定向、跟踪全检查

结论先行: 独立站上线不是”点一下发布”,而是一组必须逐项打勾的门禁。把问题分成P0、P1、P2三级:P0项(500报错、证书过期、表单收不到)不放不出,P1项72小时内修,P2项本周内修。一个常被忽略的事实是,团队往往盯着服务器报错,真正让后续半年无法归因的,是GA4和转化事件漏装——站点能打开,不代表数据在收。

一、为什么上线当天最容易出事故

独立站平时改一个页面,影响的是一个页面;上线当天动的是域名解析、服务器、CDN、跟踪脚本整条链路,任何一环错位都会全站可见。事故的代价不在上线那一刻,而在之后。

典型的情形是:迁移完一个WordPress站,首页能开,团队就切了公网DNS。三天后才发现产品详情页全是404,因为旧URL到新URL的301映射漏配了一整批。

这里有一个反直觉判断:上线检查里最该花时间的,不是找报错,而是验证跟踪和表单。报错会立刻被用户和监控看见,漏埋的代码却要等你看数据时才暴露。

迁移场景的系统性做法,可对照 站点重构与换域名的301交接;日常上线流程则属于 独立站技术 的范畴。

门禁等级 判定标准 处理时限 典型项
P0 阻断 全站不可用或核心转化断裂 修复前不发布 500报错、证书过期、表单收不到
P1 严重 部分功能异常但核心可用 72小时内修复 移动端错位、个别404、事件漏报
P2 一般 体验瑕疵不影响转化 本周内修复 个别图片未压缩、Alt缺失

二、域名与DNS:先降TTL,再切解析

域名这一关最常见的坑是切换太急。DNS解析有全球传播延迟,如果A记录TTL还设着3600秒,切换当天海外用户可能24小时都访问旧服务器。

正确做法是提前一周把TTL降到300秒(5分钟),让全球递归缓存快速过期。切换当天先切DNS的A记录,观察半小时再开CDN回源,避免同时动两层。

场景示例一:新站换域名,把旧域名的裸域和www都301到新域名对应路径,并在GSC分别提交两个域名的资源所有权,否则旧权重不会交接。

检查项 合格标准 常见错误
TTL值 切换前1周降至300秒 保持3600秒直接切
裸域与www 两者都能解析,统一到一个版本 裸域打不开或重复收录
DNS记录数量 核对A/CNAME/MX无多余记录 残留旧服务器记录
邮件记录 MX记录未被改动 切域名时顺带丢了邮箱

三、SSL与HTTPS:证书不是装上就行

HTTPS这一关,证书装完只是起点。要确认三件事:证书剩余有效期大于30天、全站无混合内容(图片脚本仍走http://)、http强制301到https并开启HSTS。

混合内容是高发问题。页面主体是https,但某张产品图、某个第三方统计脚本仍引用http://,浏览器会拦一半资源,控制台报红字。逐项配置可参考 独立站HTTPS配置。

场景示例二:上线后用浏览器开发者工具的Security面板逐页看,首页、产品页、博客页各抽查3个,发现一个老插件还在输出http的gravatar头像地址,换成本地头像或升级插件后红字清零。

检查项 合格线 验证方式
证书有效期 剩余>30天 浏览器地址栏锁标查看
混合内容 控制台0条红字 DevTools Security面板
http跳转 所有http URL 301到https curl -I 看状态码
HSTS 响应头含Strict-Transport-Security curl -I 看响应头

四、重定向与canonical:别让新旧内容同时被收录

如果这次上线伴随URL结构调整,旧URL必须逐条301到新对应页,不能图省事全站301到首页。全站301到首页会让Google无法判断旧内容该归到哪条新路径。

还要检查重定向链和循环:A→B→C 这种两跳以上的链会损失权重并拖慢抓取;配置错误造成的A→B→A循环会让爬虫卡住。写法细节见 301重定向策略。

另一个坑是canonical。新旧两套页面都能访问时,要在保留的那版上自引用canonical,另一版301过去,否则Google会自行猜测主版本,结果往往猜错。

URL情形 正确处理 错误做法
旧页面已合并到新页 旧URL 301到对应新页 全部301到首页
同一内容多参数URL canonical指向规范版 每个参数版本独立收录
废弃页面 返回410或301到上级分类 保留软404返回200
多语言版本 hreflang双向互指 只单向标注

五、跟踪代码与表单:最容易漏、代价最大

这是全文最想强调的一关。GA4装好不等于数据在收,必须用Tag Manager的预览模式或GA4实时报告,真实点一遍页面、真实提交一次表单,确认事件触发、转化计数。

表单要端到端测一次:填一条测试询盘,确认它落到了CRM或邮箱,而不是只在前端弹个”提交成功”。丢单最常见的原因就是SMTP或Webhook没配,前端成功、后端没到。表单可靠性可对照 询盘表单可靠性自检。

事件埋点清单至少覆盖:页面浏览、表单提交、按钮点击、PDF下载、视频播放。GA4配置方法见 独立站GA4部署。

验证项 动作 通过标准
GA4页面浏览 真实访问3个不同页面 实时报告30秒内出现
表单提交事件 真实提交1条测试询盘 转化计数+1且邮件收到
埋点一致性 GA4与GTM预览比对 两侧事件数量一致
异常过滤 排除内部IP 自家访问不进数据

六、上线后72小时观察期

公开发布不是结束。上线后先在GSC提交sitemap并请求编入索引,前72小时每天看一次:抓取了多少URL、报了多少404、移动可用性有没有错误。

监控要提前布好。可用性、证书到期、表单异常的告警阈值,建议错误率超过1%即触发通知,方法见 独立站监控体系。sitemap本身怎么写,见 XML Sitemap优化。

观察期内不要顺手做内容改动。一周内先稳定,再开始发布博客,避免把收录波动和内容更新混在一起无法归因。

时间点 动作 关注指标
发布当天 GSC提交sitemap 发现页数、抓取错误
24小时 抽查20个核心URL状态码 404/5xx比例
48小时 核对GA4数据连续性 事件量是否正常增长
72小时 错误率复盘、P1清单清零 错误率降至1%以下

FAQ 常见问题

新独立站第一次上线,最容易漏掉哪一项?
最容易漏的是跟踪代码和表单的端到端验证,而不是服务器报错。500错误会立刻被发现,GA4事件漏装或表单只弹成功提示却没送达邮箱,往往要等一两个月看数据时才暴露。上线前务必用GA4实时报告真实点一遍页面、真实提交一条测试询盘,确认计数加一且邮件或CRM收到。
换域名当天,DNS要提前做什么准备?
提前一周把A记录的TTL从默认3600秒降到300秒,让全球递归缓存快速过期。切换时先切A记录、观察半小时再开CDN回源,不要同时动两层。同时把旧域名裸域和www都301到新域名,并在GSC分别验证两个域名的资源所有权。
旧站URL全部301到首页行不行?
不行。全站301到首页会让Google无法判断旧内容对应哪条新路径,权重无法正确交接。正确做法是逐条映射:旧产品页301到对应的新产品页,旧博客文301到新文,实在没有对应页的才301到上级分类。映射表做完后用脚本逐条curl -I确认状态码是301且无重定向链。
SSL证书装好了为什么浏览器还报不安全?
多半是混合内容。页面主体是https,但某张图片、某个第三方脚本或旧插件仍引用http://地址,浏览器会拦截并标红。用DevTools的Security面板逐页检查,把残留的http资源改成本站相对路径或https,再确认http全站301到https并开启HSTS响应头。
上线后多久提交sitemap和GSC?
公开发布当天就提交sitemap并请求编入索引,不要等一周。前72小时每天看一次GSC:发现了多少URL、404有多少、移动可用性有无错误。72小时观察期内先稳住,不要顺手改内容,否则收录波动和你的改动混在一起,无法判断原因。
P0和P1怎么区分,什么情况下必须回滚?
P0是全站不可用或核心转化断裂:首页500、证书过期、所有表单提交收不到,这类不修复不发布。P1是部分功能异常但核心可用,比如个别404、移动端某屏错位,72小时内修。上线后若错误率超过1%且连续两小时不回落,或表单完全收不到询盘,应立即回滚DNS到旧版本,再定位问题。

写在最后

上线检查的价值,不在当天挡住几个500,而在三个月后你打开数据面板时,每一条数字都对得上。报错会被用户和监控顶上来,安静坏掉的只有跟踪、表单和301这三类。

落地就三步:上线前按P0、P1、P2分级逐项打勾,任何一个P0不过就不切DNS;发布当天提交sitemap并布好错误率告警;72小时内只观察不改内容,把P1清单清零。

一句可以记住的话:上线检查的敌人不是报错,是那些要等你看数据时才安静地坏掉的环节。

crater
crater Эксперт Crater

Официальный аккаунт организации · crater Crater

环形山 (Crater) — компания, которая помогает выходить на зарубежные рынки: разработка сайтов на WordPress, Google SEO и комплексный рост в GEO. Мы работаем с умными устройствами, промышленным оборудованием, SaaS и новой энергетикой.

Возможности продуктаБелая книга по методологииОтраслевые отчёты
965篇分享
78статей в базе знаний