如何验收
开发方交付的网站

如何使用本指南

一个已经完成的网站可能看起来很漂亮，却仍在丢失咨询、被搜索引擎屏蔽，或依赖前任服务商的账号。因此，验收对象应是您自己域名上实际运行的网站，而不只是项目演示。下文按顺序说明：打开哪个工具、输入什么、如何判断结果，以及要求开发方修复什么。

准备好需求说明、已确认的设计稿、页面清单和集成清单。记录检查的网址、日期和版本。建立表格，列出“地址／场景”“预期结果”“实际结果”“证据”“负责人”“状态”。使用四种状态：已检查、存在问题、未检查、不适用。无法登录后台应标记为“未检查”，而不是“一切正常”。

需要使用的工具

向公共工具提交普通的公开网址。含有秘密登录链接、个人数据或支付令牌的页面，应在约定的测试环境内检查。按钮名称可能因界面语言或版本更新而变化，下文提供主要操作指引。

确认网站确实已交付给您

通过 WHOIS 与注册商账号检查域名

1. 在浏览器中打开WHOIS，输入不带页面路径的域名，例如example.ru，然后执行查询。
2. 找到注册商与域名有效期。对于 .ru 域名，日期可能显示在字段paid-till中；其他域名后缀的字段名称可能不同。
3. 使用委托方的账号登录对应注册商后台。确认域名在账号中，可以续费并管理 DNS，且用于找回账号的联系方式属于负责员工。
4. 将域名持有人信息与约定的归属安排核对。WHOIS 隐藏部分信息很常见：公共查询工具不能替代对账号和文件的核查。

预期结果：明确域名持有人、下次付款日期、续费方式，以及谁能够恢复访问权限。服务商可以继续负责技术工作，但项目不应依赖一个归属不明的个人账号。

整理其他账号与权限清单

不要将密码写入公开共享的问题表。提供安全存储位置的链接与负责人姓名即可。如果平台条款限制访问权限，应说明哪些操作可由委托方独立完成，哪些需要技术支持。

检查重定向、服务器响应与证书

在 httpstatus.io 中检查四种域名形式

网站通常可以通过 HTTP 或 HTTPS、带或不带 www 的方式访问。请选择主地址，例如https://example.ru/。然后打开httpstatus.io，在输入框中粘贴以下四行，并将示例替换为自己的域名：

http://example.ru/
http://www.example.ru/
https://example.ru/
https://www.example.ru/

点击Check status。展开结果，查看状态码顺序和最终地址。主 URL 应返回200。进行永久归并时，其他地址通常使用301或308跳转到返回200的主 HTTPS 地址。再用一个内页重复检查：页面路径不应丢失。

保存报告，并向开发方提供起始 URL、完整重定向链和预期最终地址。临时302并不一定是错误，应先明确其用途。与需求不符、出现循环或丢失页面才是问题。

404 页面是否真的返回 404？

在自己的域名后添加一个确定不存在的路径，例如/proverka-priemki-ne-sushchestvuet-8472/。用浏览器打开，再使用同一工具检查。应显示清晰的提示和导航，并返回状态码404。如果页面写着“页面未找到”，但服务器返回200，就属于错误地报告成功。对于确实已删除的资源，也可以有意使用410。

使用 SSL Labs 检查 HTTPS

1. 在浏览器中打开SSL Server Test。在字段Hostname中输入域名，不包含https://或路径。
2. 如有需要，勾选Do not show the results on the boards，启动测试并等待完成。
3. 检查证书到期日期、是否匹配域名，以及证书链的信任提示。将协议方面的警告连同报告链接交给服务器管理员。

网站应能在普通浏览器中正常打开，不出现无效证书警告。还要分别检查图片、字体和脚本的加载：页面使用 HTTPS 不会自动修复仍通过 HTTP 引用的资源。SSL Labs 的评分针对 TLS 配置，而不是网站整体安全性。

检查是否屏蔽了搜索引擎

第 1 步：打开 robots.txt

在浏览器中输入https://example.com/robots.txt。找到适用于User-agent: *的规则组，以及单独针对 Googlebot 和 Yandex 的规则（如有）。以下两行会禁止对应爬虫抓取整个网站：

User-agent: *
Disallow: /

对于已上线的公开网站，这意味着需要检查设置。但不要不加区分地删除所有限制：用户后台、购物车和技术地址可能是有意屏蔽的。最终结果取决于规则组、规则及具体 URL 的组合。

在浏览器中打开Yandex Webmaster→Tools → Robots.txt analysis（robots.txt 分析），并输入网站地址。文件加载后，检查首页、服务页、文章页和其他重要 URL 是否允许抓取。如果所需页面被屏蔽，请保存其地址与触发的规则。操作流程见工具帮助文档。

第 2 步：检查页面及响应头中的 noindex

通过浏览器菜单中的“查看网页源代码”打开源码，搜索name="robots"，name="googlebot"以及noindex。需要关注的是位于<head>中的真实 meta 标签，例如：

<meta name="robots" content="noindex, nofollow">

在本篇这类文章中，单词noindex可能只是出现在教学示例中，并非正在生效的限制。还要在 httpstatus.io 的报告中查看响应头：指令也可能通过以下形式发送X-Robots-Tag: noindex。在 WordPress 中，另行检查“设置 → 阅读”及建议搜索引擎不收录网站的选项；SEO 插件也可能添加限制。

预期结果：需要被搜索收录的页面不存在误设的索引限制。Google 必须能访问页面，才能读取noindex；在 robots.txt 中禁止抓取不能替代该指令。这一区别在以下文档中有说明：Google 官方文档。

第 3 步：检查 XML 网站地图

从 robots.txt 中的以下行获取网站地图地址：Sitemap:，或向开发方询问。文件可能名为sitemap.xml，sitemap_index.xml或其他名称。打开地图；如果其中列出多个地图文件，请分别打开页面、商品和文章的地图。确认 URL 使用正式域名与主要的 HTTPS 形式，而非测试站点地址。

选取每个栏目中的 URL 并打开。地图中不应误留重定向地址、已删除页面或带 noindex 的页面。将完整列表与约定的网站清单核对：一个能打开的地图不能证明覆盖完整。在 Yandex Webmaster 中使用Tools → Sitemap validator（网站地图验证），粘贴链接并分析错误；另有官方操作指南。

第 4 步：在 Google Search Console 中检查页面

1. 在Search Console中选择已验证的网站资源。
2. 将重要页面的完整地址粘贴到顶部 URL 检查栏中。
3. 请区分索引中保存的信息与对当前页面的检查。点击测试实际网址 / Test Live URL，检查当前响应。
4. 展开抓取和索引信息。如果被禁止或加载失败，将具体原因反馈给开发方。修复后再次执行实时测试。

实时测试成功表示技术上具备进入搜索的条件，并不承诺立即收录或取得高排名。两种模式的区别见Google 帮助文档。对于 Yandex，还应使用 Webmaster 的服务器响应检查和索引报告。

查找失效链接、重复内容和标记错误

如何在 Screaming Frog 中启动抓取

1. 安装官方网站提供的 SEO Spider。将首页 URL 粘贴到字段Enter URL to spider中，然后点击Start。
2. 等待抓取结束。如果达到了免费版 500 个 URL 的上限，不要将报告视为完整报告；更大的项目需要不受该限制的工具。
3. 打开标签页Response Codes，查找 4xx 和 5xx 响应。选择有问题的 URL，并查看Inlinks，了解哪些页面链接到了它。
4. 导出结果，并向服务商提供“来源页面 → 失效链接”的对应关系。

基于链接的抓取不能保证找到所有页面：没有入站链接的“孤立页”可能被遗漏。请将导出结果与网站地图、CMS 页面清单及约定结构进行核对。如果内容由脚本生成，还需确认渲染模式。设置与限制见首次抓取指南。

应查看哪些结果

各标签页的名称与用途见SEO Spider 参考文档。自动标记只是提醒您查看页面。一个有意保留的重复页，与十个不同服务页使用相同 title，需要采取不同处理方式。

如何检查结构化数据

在浏览器中打开Rich Results Test，选择 URL 检查，粘贴地址并启动测试。展开识别到的类型和错误。该服务检查 Google 支持的富媒体搜索结果：没有符合条件的结果，并不意味着所有 Schema.org 代码都无效。

因此，还应打开Schema Markup Validator，并检查同一地址。将标题、作者、组织、图片、URL 和日期与页面内容核对。文章应配有相关插图，服务页应提供最新信息。只要代码格式正确，验证器显示通过也不会发现虚构作者或与主题无关的照片。

另外检查聊天软件中的链接预览，以及元数据og:title，og:description，og:image。如果所有文章仍使用同一张旧横幅，应配置各页面专属的图片。请注意聊天软件缓存：即使已修复，也可能暂时显示旧卡片。

文字和图片需要人工检查哪些内容

将价格、企业资料、电话、邮箱、姓名、说明文字和按钮与公司的真实信息核对。打开不同主题的页面：复用模板很容易留下其他主题的标题，或模型中不匹配的屏幕内容。汽车维修网站的手机界面不应提供按摩服务。逐一打开文档和文件链接：按钮名称正确，并不能证明链接的文件也正确。

查找 HTML 错误可以使用Nu Html Checker：提交 URL 并分析结构错误提示。开发方应评估其影响；警告数量不能代替实际的网站检查。完整的搜索设置分析属于技术 SEO 审计。

在不同屏幕上检查界面

将网站与已确认的设计稿核对：模块顺序、字体、颜色、图片和按钮文字。再检查漂亮设计稿中可能遗漏的状态：长标题、无搜索结果、展开的菜单、表单报错，以及手机键盘打开后的界面。

在 Chrome 中快速检查宽度

1. 打开页面，然后通过浏览器菜单或以下快捷键打开开发者工具 F12.
2. 点击手机和平板图标，启用设备工具栏。在Responsive模式下手动设置宽度。
3. 初步检查可采用 320、390、768 和 1440 像素。这是一组用于发现问题的实用测试宽度，不代表所有设备的通用清单。
4. 在每种宽度下滚动浏览整页，打开菜单、表格、选项卡和表单。记录 URL、宽度及问题截图。

Device Mode有助于检查响应式布局，但无法完整模拟真实手机。如果目标用户使用 Android 或 iPhone，请在实际设备上重复核心操作流程。

哪些情况属于缺陷

• 整页向侧面溢出、标题被裁切或按钮超出屏幕。宽表格可以在自己的容器中横向滚动，但不应撑宽整页。
• 未经约定，移动端隐藏了重要图片或部分文字。
• 菜单展开后无法关闭、长列表无法滚动，或无法返回页面。
• 键盘挡住输入框和按钮，且无法滚动到它们。
• 点击电话号码却拨打了其他号码、邮箱链接有误，或成功提示无法阅读。

还应使用以下按键依次访问控件 Tab。焦点应清晰可见，按钮和输入框应能访问，错误应有文字说明。将浏览器缩放到 200%，确认仍能阅读内容并完成主要操作。若约定了无障碍要求，应按单独清单逐项检查。

确认咨询确实到达收件方

“谢谢”提示只能证明显示了一条消息。表单验收要一直检查到员工开始处理咨询的位置：邮箱、CRM 或订单系统。测试前应通知负责人，避免将测试咨询当作真实客户。

逐步检查每一种表单

1. 列出不同表单：页底咨询、回电预约、弹窗、需求简报和文件上传。外观相同的表单可能使用不同的处理程序。
2. 打开对应页面。为检查来源归因，可以添加约定的测试参数：?utm_source=acceptance&utm_medium=test&utm_campaign=site_handover。
3. 填写容易识别的标记，例如“验收测试——服务表单——14:35”，并使用约定好的个人测试联系方式。每个字段填入不同内容，以便发现数据丢失。
4. 只提交一次表单，记录时间和屏幕上的结果。
5. 在收件箱中找到邮件，并检查垃圾邮件。如果应保存到 CMS，也要查找对应记录。在 CRM 中核对咨询卡片、流程、负责人、电话、备注和来源。
6. 将收到的数据与提交内容逐项核对。附件应能打开，链接应指向正确资料，广告参数应写入预定字段。

预期结果：咨询已保存，并通过约定的链路送达；字段没有丢失，员工能够判断来源。如果 CMS 中有记录但未收到邮件，这是两种不同结果：保存已成功，通知送达尚未确认。

检查错误处理与重复提交

商城、支付和用户后台

网店应检查价格、数量、折扣、配送、总金额和库存。与支付服务商约定测试模式，检查支付成功、拒付、取消、返回网站和订单状态变化。不要用随意选择的银行卡测试真实扣款。订单系统和支付系统中的标识、金额及状态应一致。

为用户后台创建两个不同角色的测试账号，检查登录、退出、访问恢复和允许执行的操作。用户不应通过打开某个 URL 查看他人的订单或文档。只使用约定的测试数据。字段传递和咨询路由问题，应与以下领域的专家共同排查：CRM 集成。

完成实际操作后检查 Metrica 目标

首先登录Yandex Metrica，使用委托方账号。核对域名和统计代码 ID，确认可以访问设置与所需报告。索取目标清单，明确什么算作咨询、电话点击、下载和购买。

如何启用调试器

1. 打开页面时添加参数?_ym_debug=2。如果 URL 已经包含问号，则添加&_ym_debug=2。
2. 执行目标操作，并打开页面底部的调试面板。
3. 在Events以及Console标签页中检查统计代码 ID 和事件，并与约定目标核对。
4. 然后在转化报告中找到目标完成记录，注意数据更新延迟及对自身访问的过滤设置。

模式_ym_debug=2适用于新版统计代码。如果面板未出现，请使用 Yandex 文档中的替代方式，通过_ym_debug=1和浏览器控制台检查。具体步骤及事件未出现的原因见官方目标检查指南。

如何判断目标配置有误

比较三种操作：打开表单、空字段时点击提交、完整填写后成功提交。如果三者都增加“收到咨询”目标，报告就高估了结果。单独设置的“按钮点击”目标可以记录点击，但应准确命名，不应把它当作已经收到的咨询。

保存测试时间、目标名称、事件截图和已找到的咨询。成功提交后刷新页面：除非逻辑明确要求，否则没有新咨询时不应再次触发事件。使用 Google Analytics 4 时，也应将调试或实时报告中的事件与实际操作核对，并将账号和权限交付给委托方。

如何使用 PageSpeed 并判断修复重点

逐个 URL 执行测试

1. 在浏览器中打开PageSpeed Insights，粘贴完整 URL 并启动分析。
2. 等待报告完成，分别查看移动设备和桌面设备两个标签页。两者的评分和测试条件不同。
3. 保存报告链接、日期、URL 和设备类型。再次测量时，注明两次测试之间做了哪些修改。
4. 先查看实际用户数据（如有），再看实验室诊断。确认实际数据对应当前 URL，还是整个站点来源。
5. 展开建议，找到具体的图片、脚本、字体或请求。将资源地址、问题说明和报告一起交给开发方。

如果验收范围包括所有页面，应建立完整 URL 清单，并为每个地址保存两种设备的报告。检查首页、一个服务页和一篇文章，可以发现模板共性问题，但不能证明其他页面的结果。

Core Web Vitals 阈值适用于按设备类型区分的实际访问数据第 75 百分位。新网站或访问量较少的网站可能没有此类数据，这不代表速度为零，也不代表自动不合格。定义和适用条件见Web Vitals 文档。

报告解读示例

另一个例子：CLS 较高，图片加载时把文字挤开。应要求通过尺寸或宽高比预留图片空间，再重新检查。如果页面响应很慢，开发方应排查服务器、缓存和应用程序。不能仅凭一个时间指标就认定是数据库或主机托管的问题。

一定要要求 100 分吗？

Lighthouse 分数来自某一次实验室测试，会受到测量条件影响。Google 在以下文档中解释了计算方法和波动性：性能评分文档。如果需求明确写了 100 分，应记录指标、设备类型和条件，再核对实际结果。不能只凭一张截图宣称“全站 100 分”。

提速后重新检查咨询提交、菜单、分析工具和手机显示。为提高分数而删除插图或停用必要的统计代码，属于功能变更，需要单独决定。无障碍、SEO 和最佳实践评分也有参考价值，但自动化测试无法覆盖全部验收要求。

通过实际恢复验证备份

要求展示最新备份的日期、内容、存储位置、频率和保留期限。对于使用数据库的网站，仅备份一个文件夹通常不够，还需要数据库、文件、上传内容及必要配置。对于建站平台，应了解平台支持的恢复方式和限制。

受控恢复测试流程

1. 选择具体的备份并记录日期，明确预期应恢复哪些内容。
2. 要求开发方在隔离的测试环境中恢复备份，不要为了测试替换正式网站。
3. 启动恢复后的副本前，停用真实支付、群发邮件、通知和其他外部操作。采用合适措施，禁止无关人员和搜索爬虫访问测试环境。
4. 打开页面并登录 CMS，检查图片和数据，使用测试收件人验证核心流程。
5. 记录恢复耗时、缺失内容和操作说明。确认即使主服务器丢失，负责人仍能取得备份。

预期结果：明确可以恢复哪个版本、需要多长时间，并且已经实际完成恢复。仅说“主机商会备份一切”而未做测试，该项仍不能确认。

交付时的基本安全检查

将 CMS 用户与负责人对应，检查不再需要的测试账号和服务商权限，明确 CMS 与扩展的更新流程。确认备份压缩包和配置文件没有通过公开链接暴露，测试数据没有进入正式项目。WordPress 提供了官方安全加固建议。

这些步骤不能代替完整的安全审计。复杂用户后台、支付和敏感数据处理，需要单独约定测试范围。备份与定期更新应在以下工作中指定负责人：技术维护。

检查您能否独立更新网站

索取操作说明，在没有开发方提示的情况下完成常见任务：创建文章草稿、添加图片和 alt、填写搜索标题、插入内部链接并预览。然后在测试记录中修改一个价格，再恢复原值。不要用公开首页来练习。

如果重要操作需要手动修改代码，这应是项目中已明确的限制，而不是交付后的意外。说明文档必须与实际后台、编辑角色和当前网站版本一致。

• 按约定范围接收源代码、设计稿、许可证和素材。
• 记录发布、回滚及依赖更新流程。
• 为域名、主机、备份和故障通知指定负责人。
• 记录支持渠道、约定响应时间和维护范围。
• 将交付内容与合同核对：技术检查清单本身并不决定付款方式、保证责任或签署文件的法律后果。

如何反馈问题并验证修复

一条反馈应描述一个可复现的问题。不要只写“网站很慢”，而应提供 URL、设备、时间和报告链接。不要只写“表单坏了”，而应说明操作步骤，以及咨询未到达的最终位置。这样开发方才能复现故障，委托方也能验证结果。

修复优先级

阻止上线：核心流程无法运行、订单丢失、缺少约定权限、他人数据被暴露，或重要页面不可用。完成验收前必须修复：错误的搜索设置、大量失效链接，以及严重的移动端缺陷。计划内改进：不影响内容或功能的小幅视觉差异。具体优先级应结合业务影响和项目要求确定。

收到“已修复”通知后，在更新版本上重复原始步骤，保存新的证据、日期和结果。对于模板共性问题，应自动检查所有受影响 URL，并手动测试不同状态。修好一个卡片不能证明整个目录都已修复。

用清单记录验收结果：已检查什么、已修复什么、还剩什么、由谁负责、截止日期。按照合同约定办理项目完成文件。

完成验收前的检查清单

检查完成后再勾选。以下勾选仅用于当前浏览，刷新后不会保留；请把结果和证据链接记录到自己的日志中。

网站验收常见问题