WordPress网站上线前，要用正式域名、未登录访客的身份，检查访问、搜索设置和业务路径。对于获取询盘的企业站，完成标准可以定得很具体：采购者能找到产品、看清信息、提交需求，业务邮箱收到完整内容并能回复；网站发生问题时，也有人能恢复。
检查不能只停在首页截图。测试域名上的配置、邮件服务和访问限制，在切换到正式环境后可能不同。下面按切换前、正式访问、搜索与询盘、上线后四个阶段展开，明确到哪里看、出现什么结果，以及哪些问题需要挡住推广。
切换前，先准备正式地址与可恢复的版本
确定最终使用的完整地址，例如https://example.com。域名尚未定好，先完成网站域名的选择，不要一边验收一边更换地址。example.com只是本文示例，后面的步骤应换成自己的正式站。
保留切换前的网站文件、数据库和关键设置，确认备份能取回、谁负责恢复。如果是从旧主机迁到新主机，不要在刚修改DNS时就立即关闭旧环境；不同访问者可能暂时走到不同环境，切换后的询盘或订单也可能产生新数据。
DNS改动只调整需要的记录。网站解析与企业邮箱常在同一个DNS区域里，迁移网站时误删MX或邮件验证记录，可能让网站正常打开而邮箱停止收件。先保存当前记录，按新主机要求修改对应网站记录；不确定用途的记录，应先确认所属服务。
有交易或持续收集表单数据的网站，还要安排切换期间的数据处理：是否短暂停止编辑，旧环境新增记录怎样取回，回滚时怎样避免覆盖新数据。备份时间早于新订单产生时间，直接全站恢复就可能回退这些记录。具体恢复方法可以接着看WordPress备份与恢复。
正式域名能打开，还要检查跳转与HTTPS
打开未登录窗口，直接输入正式地址，查看是否进入正确网站，地址有没有跳回临时域名，证书是否有效。再测试http、https以及采用和未采用www的入口，确认它们收敛到你选定的正式版本，没有来回循环。
在WordPress“设置 → 常规”里，WordPress地址与站点地址应符合真实安装结构。根目录安装中两者通常一致；核心文件位于子目录时可能不同，不能为了看起来整齐就改成一样。官方迁移文档说明了这些地址与迁移场景的关系。
如果正式站页面仍引用临时域名，先确定引用发生在哪里：导航、图片、构建器模板、表单设置或缓存各有可能。修改时采用适合当前工具的迁移办法，并保留备份。构建器和插件可能保存结构化数据，不要直接用不了解数据格式的全库字符串替换。
HTTPS也不只看地址栏有没有https。打开Chrome开发者工具的Security相关面板，检查证书和不安全内容；图片、脚本等仍从http加载时，应回到资源来源处理。Chrome安全面板文档提供了查看连接与混合内容的方法。若错误来自固定写在模板里的旧资源，反复重新签发证书不会解决它。
搜索设置要查页面输出，不能只看一个勾选框
先在“设置 → 阅读”确认静态首页和文章页选择正确。两者承担不同任务，不能选成同一页面；保存后从正式域名重新打开验证。WordPress阅读设置说明也包含搜索可见性设置。
对于准备公开获取搜索流量的正式站，检查是否误留“建议搜索引擎不索引本站点”。这个选项不是密码保护；测试站有私密内容时，应使用访问控制。取消勾选后，还要看实际页面有没有其他来源的限制。
在源代码与响应头里分别找noindex
打开一个应该公开索引的产品页，使用“查看网页源代码”，搜索noindex或name="robots"。下面是一个需要查明来源的示例，不是让你加到网页中的代码：
<meta name="robots" content="noindex, follow">
这表示页面包含禁止索引的指令。若只在个别产品页出现，先查对应页面的SEO设置；若某类页面都出现，查该类型的默认规则或共享模板；全站都有时，再查全局设置。修改后清理相关缓存，重新检查前台源代码。
另一处在HTTP响应头。打开开发者工具Network，重新载入页面，选中当前HTML文档请求，在Response Headers里搜索X-Robots-Tag。如果看到X-Robots-Tag: noindex，来源可能是服务器、主机或其他输出规则，不能仅靠修改正文解决。Google的noindex文档说明了HTML与响应头两种实现。
至少分别检查首页、一个产品详情、一个产品分类和一篇文章。它们可能使用不同模板，首页没有noindex不能代表所有页面都正常。
robots.txt与noindex不是同一项开关
访问站点根目录的robots.txt，查看是否误留针对整个正式站的禁止抓取规则，例如开发期使用的Disallow: /。对公开内容，应按实际需要解除误加的限制。
robots.txt控制抓取，noindex控制索引；如果Google无法抓取页面，也可能无法读取页面里的noindex。因此不能把两者看成任选一种的“隐私保护”，更不能用robots.txt里的noindex写法代替支持的实现。这里验收的是你是否误挡了正式内容，不是保证取消限制后立即收录。
canonical、站点地图和旧网址也要对应正式页面
继续查看源代码中的rel="canonical"。对于应该独立作为正式版本的页面，确认它没有指向测试域名、错误产品或首页。canonical的具体选择应符合页面关系；不要为了“集中权重”把所有产品都指向首页。Google规范化文档将canonical作为规范网址信号，不能把它当成随意替代真实内容关系的标签。
打开站点正在使用的XML站点地图，从中抽查几条产品、文章和栏目URL。它们应使用正式域名，并指向你希望被发现的有效页面。地图里不应还批量保留测试网址、已经删除的页面或明显不打算公开的内容。站点地图文档说明了构建与提交方法，但提交成功不等于所有URL一定被索引。
若这是旧站改版，还需要一份旧URL与新URL的对应表。优先覆盖旧导航入口、有外链或搜索访问的页面，以及客户常用地址。内容确实搬到新位置时，设置对应跳转；不要把所有旧页面统一跳到首页，让访客重新找。Google网站迁移文档提供了网址映射与重定向的指导。
对几个重要旧地址，实际访问并查看最终落点。页面视觉显示“找不到”，HTTP却返回200，也值得记录；目标已经有效，却绕了多次跳转，同样应简化。上线验收需要的是一条可用的路径，不只是一份看起来很完整的重定向清单。
用一位采购者的任务，检查内容和导航
假设这是一个工具类B2B网站，验收任务是：从首页找到某类工具，进入产品A，查看规格，下载目录，提交询盘。这个场景是自拟的，你可以替换成自己的核心业务。
直接点击页面上的菜单和按钮，不要把目标URL复制到地址栏后就算通过。菜单可能没有链接、移动端下拉可能被遮住，按钮也可能指向临时域名；这些只有沿真实操作路径才容易发现。
到产品页后，核对标题与型号、图片、规格和可提供的服务。下载按钮承诺目录，就应该打开正确文件；没有目录时，先调整文案与入口，而不是放一个空链接。关于交期、认证、库存和服务范围的占位文字，需要业务方核实，不能为了填满版面写成确定承诺。
还要检查文章与产品之间的下一步是否合理。采购者读完规格说明，应该能找到相关产品或咨询入口；进入分类后，应有清楚的下一级内容。空白栏目、没有实际内容的标签页和重复入口，应在推广前处理或暂时从导航移除。
表单测试要走到收件和回复
给测试询盘加一个唯一标记，例如“上线验收-工具A-01”，记录页面、时间、设备和测试邮箱。填写所有必需字段，测试附件或选项功能，再观察提交后的反馈。
然后检查三处：表单系统是否保存了应保存的数据，发送服务是否正常处理，实际业务邮箱是否收到完整信息。不是所有表单都会默认保存记录，因此要先知道当前工具的工作方式。WordPress的wp_mail文档明确说明，函数返回成功并不自动代表收件人已收到邮件。
| 观察结果 | 先检查什么 | 什么时候算通过 |
|---|---|---|
| 点击提交没有反馈 | 必填校验、脚本、验证码、提交接口 | 用户得到明确结果，成功或错误都有可理解提示 |
| 提示成功，但发送记录异常 | 表单收件配置与邮件发送服务 | 对应标记的邮件被正常处理 |
| 发送服务显示成功，邮箱没收到 | 收件地址、垃圾箱、邮箱规则与投递记录 | 实际业务邮箱收到完整字段 |
| 邮件收到了，回复却发到错误地址 | Reply-To与表单邮箱字段映射 | 点击回复后，目标是测试填写的联系邮箱 |
最后真的回一封测试邮件，确认回复能够到达测试邮箱。只有收件没有回复检查，仍可能漏掉字段映射问题。若多个产品系列分配给不同业务员，每条分流规则都要测；普通页面共用同一表单时可以抽样，但不能跳过不同收件逻辑。
测试后清楚标记或清理自己的测试记录，避免被业务人员当成真实客户。若当前网站依赖CRM或自动化转发，还要检查目的系统是否收到，而不是邮件这一站通过就结束。
手机、加载与统计各有自己的验收结果
电脑和手机都走一遍采购任务。手机重点观察菜单层级、长标题、规格表横向查看、输入框、验证码和底部浮动按钮。表单输入时键盘出现，提交按钮是否仍可到达；目录弹窗打开后能否关闭，也应实际操作。
性能方面不要求为了上线把实验室分数做到100，但关键内容不能迟迟不显示，菜单与表单不能明显卡住。用真实图片和完整内容测试，不能沿用空白模板时的分数。需要定位具体慢因，可以按WordPress速度优化继续处理。
统计与同意状态另行核对
访问统计要确认属于正式站的正确数据流。启用适当调试后，可以用GA4 DebugView检查事件是否随测试操作出现。页面浏览、按钮点击、提交成功和业务收到询盘是不同事件，不能用一个点击就算完成业务转化。
如果配置了同意管理，也要分别检查适用状态下的行为。隐私和数据使用说明应反映网站实际收集与使用的信息，不能把别人的政策换个名称就当完成。这里检查配置与业务是否一致，不提供所有地区通用的法律文本。
一张结果表，判断哪些问题挡住上线
下面继续使用前面的工具站情境。它是一份演练记录，不是本站已测结果：
| 检查项 | 假设看到的结果 | 处理与复测 |
|---|---|---|
| 正式首页 | HTTPS正常，打开的是新站 | 保存通过时间，再测核心模板 |
| 产品A | 正文有noindex，首页没有 | 查产品级SEO规则，清缓存后复查源代码 |
| 产品B目录 | 按钮仍到测试域名 | 改按钮实际链接，电脑手机重新点击 |
| 产品A询盘 | 邮件收到，但回复到系统发件邮箱 | 改Reply-To字段映射，重提并回复 |
| 旧产品URL | 跳到无关首页 | 建立对应目标或合理处理失效页面 |
| 次要装饰图 | 可压缩，但不影响主要阅读与提交 | 安排后续优化，记录负责人 |
产品页误留noindex、目录按钮错链和询盘回复地址错误，应在对应页面推广前处理。某个关键入口失败，不能被十项字体、间距检查通过抵消。没有实际测到的结果，也应写“待测”，不要写“应该正常”。
正式网站可以分阶段开放内容完整、功能可用的部分。尚未准备好的产品、空白分类和未确认服务，不应作为广告或导航的承接终点。这样既不用等待所有未来内容全部完成，也不会把未完成页面推给访客。
上线当天交接什么，之后复查什么
交接记录至少包含正式地址、域名与主机的管理责任人、网站管理员、关键表单收件人、备份位置和恢复负责人。共享表里记录入口与责任归属即可，不直接填写密码；协作者应使用适合其工作的权限。
把通过的业务路径、测试时间与未解决问题放在同一份记录里。上线后再次从未登录状态检查正式地址，关注核心页面错误、邮件接收和实际业务反馈；Search Console中的发现与索引情况需要后续观察，不能在上线当天用“尚未收录”直接判断网站失效。
每次修改主题、导航、表单、缓存或域名配置后，复测受影响的路径。原来的检查表可以继续使用，只需明确本次变更与结果。旧环境何时退役，要以新站的功能和数据确认作为依据；出现故障回退时，先处理切换后新增的询盘或订单，避免为了恢复页面丢掉业务数据。
常见问题
测试域名已经验收，正式域名还需要再测吗？
需要。DNS、HTTPS、缓存、搜索限制、第三方密钥和邮件配置都可能随环境改变。至少重新验证正式访问、重要模板、手机操作及真实收件回复，不能直接照搬预览结果。
取消“不索引”之后，为什么产品页仍有noindex？
限制可能来自页面SEO设置、内容类型默认规则、模板或HTTP响应头，也可能仍在缓存中。先查看该产品页实际输出，确认是HTML还是响应头，再回对应控制源修改。取消总开关不代表其他规则自动消失。
全部文章和产品没准备好，可以先上线吗？
可以先开放内容完整、路径可用的部分。未完成页面不要占据正式导航或推广入口，页面上的规格、交期和服务承诺必须有依据。后续内容按计划补充，而不是先用空页占位接流量。
提交站点地图后，是不是上线SEO就完成了？
不是。站点地图帮助搜索引擎发现网址，不能保证收录或排名。上线前还要确认访问、抓取、页面指令与规范网址合理；上线后继续观察重要页面的发现和索引，并持续完善内容与内链。