网站优化效果怎么评估：百度统计、搜索资源平台与日志分析实战

网站优化后，先别急着用“访问量涨了”作结论。判断 SEO 是否有效，需要把同一个页面在可比时间段里的搜索展现、点击、入口访问和服务状态对应起来，再核对统计代码、来源识别和过滤规则有没有变化。百度统计用来观察已采集的访问行为，搜索资源平台用来观察平台提供的搜索表现，日志用来验证请求与故障；三者需要交叉检查，但数字不能直接相加。

本文针对博客和中小型内容站，给出一套按文章页面复盘的方法。与《SEO查询怎么做：收录、排名、技术信号与日志检查清单》不同，这里不重复上线检查，而是回答：优化后哪些指标值得比较、哪些变化不能归因，以及数据不足时应该怎样记录。

一、先定义“有效”，再选择指标

不同改动应该回答不同问题。修改标题，希望提升的是与搜索意图匹配的点击；优化加载速度，希望减少访问故障、改善实际体验；合并重复文章，希望让规范页面和内容主题更清楚。把所有改动都用全站 PV 衡量，很容易出现错误结论。

技术改动可以先验证“错误减少”“页面可访问”。搜索表现需要继续观察，不能因为错误消失就宣布排名提升。阅读、下载、联系等行为只有在统计工具正确配置对应事件后才可计量；当前没有这些事件时，复盘表应写“未配置”，不要用访问时长代替转化。

二、三类数据分别能证明什么

百度统计：观察入口和访问行为

百度统计的入口页面报告把入口页定义为一次访问进入网站后的第一个受访页面。对内容站来说，它比全站总浏览量更适合回答“哪篇文章带来了访问”。

需要区别：

• 浏览量（PV）：工具采集到的页面浏览次数。一个人反复刷新可以产生多次浏览。
• 访客数（UV）：按工具访客识别规则去重的结果，不等于真实人数；换设备、清除标识等会影响识别。
• 访问次数：按工具的访问划分规则统计，不能与 HTTP 请求条数互换。
• 入口页面：访问从哪个页面开始；某篇文章的全部 PV 还可能包含站内跳转和刷新。
• 跳出率、平均访问时长：需要结合工具当前定义和事件设置解读，不设全站统一的“达标线”。

用户看完一篇技术教程就离开，并不必然代表文章无效。没有持续事件或后续页面访问时，工具对停留时间的计算也可能不完整。不能把“跳出高”直接写成内容质量低。

百度搜索资源平台：观察平台实际提供的数据

登录自己验证的站点，查看账户当前可用的搜索表现、索引和抓取报告。保留报告名称、统计区间、更新时间、设备筛选和导出字段。

有页面或查询词维度时，按实际字段分析；没有就记为未知。不能把全站展现量分摊到某篇文章，也不能从索引总量推算文章点击率。平台入口、功能权限和字段可能调整，文章中的方法以账户实际能查看、导出的数据为准。

搜索点击发生在搜索结果端，百度统计访问发生在网站端，二者数值不同是正常现象。浏览器关闭过快、统计脚本被阻止、跳转过程、统计时间和去重口径，都可能造成差异；不能单凭差额就断言有人造假或流量丢失。

服务器日志：验证请求、响应和分类依据

Nginx 日志适合检查 HTTP 状态、请求路径和服务异常；应用访问记录适合补充客户端分类、来源字段和响应耗时。两层日志覆盖范围可能不同。

例如本站应用访问记录跳过后台、静态文件、媒体、robots.txt 和 sitemap.xml 等路径。被 Nginx 提前处理的请求，也不一定进入应用记录。需要判断爬虫是否请求 robots.txt 时，应查实际保留该请求的服务器日志。

日志可以说明某类客户端请求了页面，不能直接说明页面被收录，也不能证明读者完成了阅读。User-Agent 可以伪造，设备和机器人分类属于判断结果。日志中的“疑似用户请求数”不能改名为 UV 或真实读者人数。

三、本站现状：先建立基线，别把“刚装统计”当成增长

本站在 2026 年 10 月 6 日把百度统计接入公共页面，后台管理页面不加载统计代码。页面响应头目前为：

Referrer-Policy: strict-origin-when-cross-origin

本次编写时重新核对了公共基础模板、后台模板、应用访问记录和留存任务。上述内容是配置事实，不是优化效果或流量增长的证据。

这意味着：

1. 没有接入前的同口径百度统计历史数据，就不能把接入前的“没有数据”当成零访问。
2. 后台不安装统计代码，可以减少后台页面的干扰，但管理员浏览公共文章仍可能被记录。
3. 日志可以提供另一个观察来源，却不能拿日志请求数填补统计工具缺失的历史 UV。
4. 应用访问记录当前保留 30 天。跨月复盘需要在清理前保存必要的按日、按页面汇总，不能等原始记录删除后再补做对比。

因此，对本站当前最合理的判断是“采集已接入、开始建立基线”。还没有经验证的平台导出或访问趋势时，不写“优化带来百分之多少的增长”。

四、先验证采集，避免比较一个坏掉的计数器

在比较数据前，抽查首页、普通文章和专题页，确认统计脚本只安装一次。源码检查可以这样做：

curl -sS --max-time 20 https://blog.zenleak.cn/post/309/   | grep -o 'hm.baidu.com/hm.js?'   | wc -l

这个命令只验证源码中的加载地址次数。出现一次，不代表脚本已经执行或数据已经上报。还需用浏览器开发者工具检查脚本请求是否成功、是否被扩展拦截，以及百度统计后台是否收到对应访问。动态加载、页面跳转等场景需要按实际行为复核。

接下来固定过滤规则：

• 后台页面不纳入公共内容分析。
• 按统计工具可用功能记录内部测试流量的排除方法；不要假设固定 IP 一定能代表管理员。
• 日志分析排除已识别的搜索爬虫、AI 爬虫、扫描器和自动化请求，未知类型单独列出。
• 公共页面的健康检查、发布验证、管理员阅读仍需标注，不因它返回 200 就认定为自然搜索用户。
• 过滤条件改变时注明生效日期，不能把“过滤后数量下降”解释成 SEO 下降。

如果需要理解分类依据和限制，可以参考《SEO访问日志分析实战：识别人类用户、搜索引擎与AI爬虫》。

“来源被禁用”修复了哪些问题，没修复哪些问题

来源分析至少有三层信息：

本站原来的 same-origin 策略会省略跨域请求的 Referer。调整为 strict-origin-when-cross-origin 后，正常 HTTPS 跨域请求通常可以携带来源的协议、域名和端口，不会携带完整路径与查询参数；HTTPS 降级到 HTTP 时仍不发送。

这项修改控制的是本站发出的请求。访客从另一个网站进入本站时，上游页面的策略、跳转链、浏览器和客户端也会影响来源。本站无法凭一个响应头恢复过去已经丢失的 Referer，更不能恢复搜索引擎没有传来的关键词。

也不应为了获得完整来源，把全站策略改成 unsafe-url 或给页面添加含敏感信息的跟踪参数。来源未知就保留未知，比编造归因更有用。

五、按“文章 × 渠道 × 可比周期”做复盘

1. 固定分析单位

选一篇已发布文章，记录 canonical URL、主要搜索意图、本轮修改和准确时间。站内相关 URL 的归并规则也要写清楚：

• 文章 ID 地址与旧 slug 地址如何归并。
• HTTP 跳 HTTPS、缺斜杠跳带斜杠是否影响统计。
• 跟踪参数是否在报表中拆成多行。
• 新文与旧文合并后，是否需要同时观察旧地址和目标地址。

不要删除所有查询参数再合并；某些参数可能真的改变页面内容。应按网站实际 URL 设计判断。涉及重复意图和合并时，可以参考《SEO内容更新与文章合并实战》。

2. 使用长度一致、星期结构相同的完整周期

常规内容站可以从两个完整 7 天周期开始，访问稀少时延长到两个完整 28 天周期。这里的周期是组织复盘的建议，不是搜索引擎生效时间承诺。

时区统一为 Asia/Shanghai，比较完整日期，不把“今天尚未结束”与“昨天全天”放在一起。还应标注节假日、推广、邮件分享、统计安装、代码更换、服务故障和批量内容更新。

新文章没有优化前的页面数据，不能做严格的同页面前后比较。可以观察它发布后的趋势，或与意图、发布时间和渠道相近的页面作参考，同时说明页面并非同一个实验对象。

3. 对齐渠道和设备

先看自然搜索入口，再区分有条件识别的百度来源、其他搜索来源、外部引荐和来源未知。移动与桌面尽可能分别观察。

主动转发文章带来的访问上涨，不等于 SEO 生效。即使某个平台把没有来源的访问归类为“直接访问”，也只能按该平台规则称呼，不能据此断言全部来自手动输入网址。

4. 一轮集中调整一类问题

先记录假设，例如“文章开头不能直接回答用户问题，因此改写开头和对应段落”。同步记下受影响页面和观察指标。

如果同时改标题、导航、内链、统计规则和服务器性能，之后出现上涨，只能说这些改动期间观察到变化，不能声称其中某一项独立带来效果。相近但未修改的页面可以作为背景参照，也不能替代随机对照实验。

六、计算点击率时，别只报一个增长百分比

搜索点击率的基本式是：

CTR = 同一报表、同一范围的点击次数 ÷ 展现次数
指标相对变化 = (后期值 − 前期值) ÷ 前期值
CTR 百分点变化 = (后期 CTR − 前期 CTR) × 100

前期值为零时，相对增长率没有定义，写“从零出现新增”或“无法计算”。展现为零时也不计算 CTR。低基数时，把绝对数量和比例一起展示；汇总 CTR 应使用总点击除以总展现，不能简单平均每天或每个查询词的 CTR。

为方便理解，下面使用教学示例，所有数字均为假设，不是本站测量结果：

点击从 20 次到 30 次，看起来增长 50%，绝对增加仍只有 10 次；CTR 从 2% 到 2.5%，不能写成“提高了 0.5%”。这些数字也不回答变化原因，需要继续核对查询词、渠道和同期改动。

下面这段 Python 只对输入数字计算，不采集平台数据，不代表本站实测结果。四个数必须来自同一口径的前后两段报表：

def search_comparison(before_impressions, before_clicks,
                      after_impressions, after_clicks):
    values = (before_impressions, before_clicks,
              after_impressions, after_clicks)
    if any(type(value) is not int or value < 0 for value in values):
        raise ValueError("输入必须是非负整数")
    if before_clicks > before_impressions or after_clicks > after_impressions:
        raise ValueError("同一口径下点击不应大于展现，请先核对报表")

    def relative(before, after):
        return None if before == 0 else (after - before) / before

    before_ctr = (
        before_clicks / before_impressions if before_impressions else None
    )
    after_ctr = after_clicks / after_impressions if after_impressions else None
    ctr_change_pp = (
        (after_ctr - before_ctr) * 100
        if before_ctr is not None and after_ctr is not None else None
    )
    return {
        "click_difference": after_clicks - before_clicks,
        "click_change_ratio": relative(before_clicks, after_clicks),
        "impression_change_ratio": relative(
            before_impressions, after_impressions
        ),
        "before_ctr": before_ctr,
        "after_ctr": after_ctr,
        "ctr_change_percentage_points": ctr_change_pp,
    }

返回的 None 表示无法计算，不是零增长。比率字段以小数表示，需要显示为百分比时再乘 100。计算结果仍需结合查询词组成判断：新增大量低点击率查询，可能拉低整体 CTR；不能只凭整体 CTR 下降就判定改标题失败。

七、用日志验证服务和分类，不把请求数冒充读者

日志复核关注两个问题：页面是否稳定交付，以及流量变化是否混入程序请求。本站 Nginx 访问日志配置路径是 /www/wwwlogs/blog.log，其他站点以实际配置为准；截取 IP 和 User-Agent 的原始行不适合作为公开的效果报告。

对本站应用记录，可以用下面的 Django 查询得到指定页面、指定完整日期区间内的疑似用户 GET 请求数：

from datetime import datetime
from zoneinfo import ZoneInfo
from django.db.models import Count
from tracking.models import Visitor

tz = ZoneInfo("Asia/Shanghai")
start = datetime(2026, 10, 6, tzinfo=tz)
end = datetime(2026, 10, 8, tzinfo=tz)

rows = Visitor.objects.filter(
    path="/post/309/",
    timestamp__gte=start,
    timestamp__lt=end,
    request_method="GET",
    status_code=200,
    visitor_type="human",
    content_type__startswith="text/html",
)
print(rows.count())
print(list(rows.values("classification_source").annotate(
    requests=Count("id")
).order_by("classification_source")))

在项目的 Django shell 中执行，结束时间不包含在查询范围内。这段查询只读取记录，不修改数据库；区间用于演示查询方式，文章不预设输出数量。

这里的 human 是当前规则判断为浏览器样式客户端的标签。刷新、内部测试以及伪装成浏览器的自动化程序仍可能混入。IP 也不能稳定代表唯一访客，因此结果只能写“疑似用户请求”，不能写“新增真实用户”。

应用记录中的 response_time_ms 反映应用链路耗时，不能当作完整页面加载时间，也不等于 LCP 等浏览器体验指标。浏览器体验的排查可以参考《Django文章页 Core Web Vitals 实战》。

八、把结论写成证据、限制和下一步

建议每周保留下面这张记录表。缺失字段写“不可用”或“未配置”，不要填零；保留必要的按日汇总即可，不需要为复盘无限期保存个人请求记录。

几类常见现象可以这样处理：

• PV 上涨，搜索点击没涨：先看外部分享、站内浏览、自己测试和采集覆盖变化，不立即归因 SEO。
• 展现上涨，点击不涨：按查询意图、设备和可用页面维度检查；可能是更多查询获得展现，也可能标题与需求不匹配。
• 搜索点击上涨，百度统计访问不涨：核对日期、跳转、统计加载和拦截情况，不能直接说点击都是机器人。
• 日志请求上涨，来源未知也上涨：先排查自动化与来源识别，不把两者相加当成新增流量。
• 错误减少，搜索暂无变化：技术修复已得到验证，搜索表现继续观察，两项分别报告。

最终报告可以用这样的句式：“在指定时间、渠道和过滤条件下观察到哪些变化；同期存在什么干扰；当前证据支持什么判断；下轮准备验证什么。”这比“优化已经成功”更容易复核，也更方便决定下一步。

常见问题

网站优化多久能看出效果？

代码是否生效、错误是否消失可以立即核对；搜索展现、点击和用户行为需要积累样本。7 天或 28 天是比较窗口，不是保证收录或排名变化的期限。

统计安装前没有数据怎么办？

先从安装后的完整周期建立基线。已有日志可用于验证过去的服务状态和请求情况，但不能补成与百度统计等价的历史 UV。

能把搜索资源平台点击和百度统计自然搜索访问相加吗？

不能。二者描述不同环节，还可能对应同一批访问。应并列比较各自趋势，注明差异和限制。

百度主动提交成功算优化成效吗？

只算“URL 已被接口接收”的交付记录，不算收录、点击或转化。提交和后续状态应分别记录，参见《SEO发布后监控实战》。

参考资料

以下资料用于核对概念和浏览器行为，查阅日期为 2026 年 10 月 8 日。平台界面和可用字段以当前账户为准。

• 百度统计：入口页面：入口、访问行为和转化的分析对象。
• 百度统计：全部来源：来源、筛选和时间比较。
• 百度搜索资源平台：自己的站点验证与账户可用报告。
• MDN：Referrer-Policy：请求来源策略、跨域与降级行为。
• MDN：Document.referrer：进入当前页面时可获得的来源信息。