SEO访问日志分析实战：识别人类用户、搜索引擎与AI爬虫

很多站长只看访问量，却不知道这些访问来自真实读者、搜索引擎、AI检索器，还是安全扫描器。把所有请求都算作“用户”，会让跳出率、热门页面和转化数据失去参考价值；把所有带有 bot 的请求都当成搜索引擎，也会错过一部分 AI 爬虫和自动化脚本。

更实用的做法是建立一套轻量的访问日志分析方法：先正确获取客户端 IP，再根据本地 GeoIP 数据得到国家和城市，最后结合 User-Agent、访问路径和请求频率，将访问分成用户、搜索引擎爬虫、AI 爬虫、自动化脚本、安全扫描和未知客户端。这样既能帮助 SEO 诊断，也能为 GEO（生成式引擎优化）提供可验证的抓取证据。

一、先把“访问者”拆成几类

访问者分类的目标不是给每个 IP 贴上绝对标签，而是让数据足够支持决策。建议至少保留下面六类：

is_bot 这个布尔值可以用于快速筛选，但后台最好同时保存具体类型和机器人名称。这样看到一条记录时，能知道它是搜索爬虫还是普通脚本，而不是只看到一个“是/否”。

二、IP 地址必须先经过反向代理校正

网站使用 Nginx 反向代理时，Django 收到的 REMOTE_ADDR 通常是 127.0.0.1。如果直接读取这个字段，所有访问都会被误认为来自本机，国家和城市自然也无法解析。

常见的代理头有：

• X-Real-IP：由可信反向代理写入的真实客户端地址；
• X-Forwarded-For：代理链中的地址列表；
• REMOTE_ADDR：当前连接的直接来源。

应用应优先使用由自己的 Nginx 写入的 X-Real-IP，再从 X-Forwarded-For 中取代理链右侧的公网地址，并校验它是否是合法 IP。不要无条件相信客户端自己提交的第一个 X-Forwarded-For 值，否则访客可以伪造来源地址。

下面是一个只使用 Python 标准库的基础实现：

from ipaddress import ip_address


def get_client_ip(meta):
    real_ip = (meta.get('HTTP_X_REAL_IP') or '').strip()
    try:
        parsed = ip_address(real_ip)
        if not parsed.is_private:
            return str(parsed)
    except ValueError:
        pass

    forwarded = meta.get('HTTP_X_FORWARDED_FOR', '')
    for value in reversed(forwarded.split(',')):
        try:
            parsed = ip_address(value.strip())
            if not parsed.is_private:
                return str(parsed)
        except ValueError:
            continue

    return meta.get('REMOTE_ADDR') or '0.0.0.0'

完整的代理信任策略还应该限制“哪些代理可以写入这些头”。如果网站前面又接入了 CDN，就要把 CDN 的出口地址加入可信代理列表。

三、国家和城市优先使用本地 GeoIP

每次请求都调用免费的公网 IP 查询接口，会带来三个问题：请求延迟、接口限流和第三方服务不可用。访问量一高，页面响应可能被地理查询拖慢，甚至因为接口超时而丢失访问记录。

更稳定的方案是把 GeoLite2 City 等数据库放在服务器本地，并在进程启动时打开一次。查询时只需要在本地数据库中查找 IP，不产生额外网络请求。应用层可以缓存最近查询过的 IP，避免同一访客反复查找。

需要注意三点：

1. 内网地址、回环地址和保留地址没有公开地理位置，应显示为“未知”；
2. 城市级定位是近似结果，移动网络、代理和云服务器可能落到邻近城市；
3. GeoIP 数据库需要定期更新，旧数据库会降低新 IP 的命中率。

国家和城市适合用于总体趋势分析，不适合作为用户身份或精确位置证明。

四、User-Agent 能识别什么，不能识别什么

User-Agent 可以帮助识别设备、操作系统和浏览器，例如：

• Android、iPhone、iPad：手机或平板；
• Windows NT、Mac OS X、Linux：操作系统；
• Edg/、Chrome/、Firefox/、Safari/：浏览器；
• Googlebot、Baiduspider、GPTBot：已知爬虫标识。

但 User-Agent 是客户端自行提交的文本，任何脚本都可以伪装成 Chrome 或 Googlebot。因此，分类结果应该称为“识别结果”或“疑似类型”，而不是绝对结论。对重要搜索爬虫，可以结合反向 DNS、官方 IP 段和访问行为进一步验证。

识别规则也不能只匹配 bot。实际日志中还会出现 crawler、spider、CensysInspect、zgrab、curl、python-requests、httpx、Go-http-client 以及各种 AI 搜索机器人。规则最好按优先级排列：先匹配具体名称，再匹配搜索爬虫、AI 爬虫、扫描器和自动化客户端，最后把空 User-Agent 归为未知。

五、不要因为是爬虫就完全不记录

很多统计中间件会先判断 is_bot，然后直接跳过机器人请求。这会让后台看起来很干净，却无法回答最关键的 SEO 问题：新文章有没有被抓取？百度和 Bing 的请求是否来自真实爬虫？AI 检索器访问了哪些页面？

更合理的方式是：

• 排除静态文件、后台页面、健康检查和站点发现文件，减少噪声；
• 对公开内容同时记录用户和爬虫；
• 保存请求路径、时间、来源页、IP、访问者类型和机器人名称；
• 用后台筛选器分别查看用户、搜索爬虫、AI 爬虫和扫描器。

如果日志量较大，可以按天汇总，而不是删除原始记录。原始记录保留短周期，汇总数据保留长周期，通常比永久保存完整 User-Agent 更合理。

六、从日志中提取 SEO 结论

有了结构化字段后，可以按下面的顺序分析：

1. 新文章是否被抓取

发布后观察文章 URL 是否出现搜索爬虫请求。如果只有用户访问而没有爬虫访问，应检查站内链接、robots.txt、响应状态码和主动推送记录。

2. 爬虫访问到了什么页面

把爬虫路径按文章、分类、标签和静态页分组。如果大量请求集中在不存在的 URL，说明站内链接或历史 URL 还需要清理。可以结合搜索引擎爬虫技术解析与SEO实战优化指南继续排查抓取效率。

3. AI 爬虫是否能看到核心内容

GPTBot、ClaudeBot 或其他 AI 检索器访问的页面，通常会反映内容是否具备引用价值。把它们访问的页面与文章的摘要、标题、实体关系和引用来源对照起来，有助于完善 GEO 内容结构。关于这部分，可以参考GEO内容组织方法：让引用、来源与实体关系可核验。

4. 访问异常是否影响服务器

如果同一个 IP 在短时间内请求大量不存在页面，或者频繁访问登录、搜索和接口路径，就应该单独观察频率和响应状态。部署后的日志排查方法可以参考Django部署后的日志排查与性能监控；将日志与关键词、索引和流量周期对照时，可继续阅读SEO数据监控实战指南。

七、隐私与数据保留

IP 地址、User-Agent、国家城市、设备和浏览器组合起来，可能形成较强的访问特征。站点应在隐私政策中说明收集目的、字段范围、保留期限和删除方式，并限制后台访问权限。

实践中可以采用以下策略：

• 原始访问记录只保留满足排障和 SEO 分析所需的周期；
• 对外展示只使用汇总统计，不公开完整 IP 和 User-Agent；
• 仅保存分类结果和必要字段，减少长期保存原始字符串；
• 把日志分析权限限制给维护站点的管理员。

日志分析的目标是改善内容和服务质量，不应该把近似的地理位置当成用户身份判断。

常见问题

User-Agent 为空就是爬虫吗？

不一定。它通常是未知或自动化请求，但代理、隐私工具和异常客户端也可能隐藏 User-Agent。更稳妥的做法是标记为“未知客户端”，再结合 IP、路径和频率判断。

为什么同一个 IP 有时显示不同城市？

移动网络、企业代理、云服务器和 IPv4 共享都会导致 IP 归属变化。城市信息适合看趋势，不适合做精确定位。

是否应该把所有 AI 爬虫都屏蔽？

不应该一概而论。先确认它们是否遵守站点规则、是否带来异常负载，再决定限速、限制路径或保留访问。对希望获得 AI 引用的公开文章，应先保证核心内容可以被正常抓取。

访问日志和搜索引擎收录是一回事吗？

不是。日志只能证明某个请求到达过服务器，不能证明页面已经被收录。收录还需要结合搜索引擎站长平台、主动推送结果和实际检索结果判断。

结语

SEO 访问日志的价值，不在于记录越多越好，而在于每条记录都能支持一个明确的问题：谁访问了页面、从哪里来、使用什么设备、访问了什么内容，以及这次访问是否值得纳入用户统计。把 IP、GeoIP、设备解析和爬虫识别组合起来，站点才能同时看清真实读者、搜索引擎和 AI 检索器的行为。

对于 Django 站点，还可以把分类结果接入缓存、限速和告警系统，形成从访问记录到性能优化的闭环。需要进一步优化接口响应时，可以继续阅读Django API分页、缓存与数据库查询优化。