用Python脚本做AI巡检周报：汇总抓取错误、索引覆盖率与核心网页指标

网站运营最怕的不是出问题，而是问题发生了两周才发现。Search Console 里的抓取错误、索引覆盖率、核心网页指标分散在三个不同面板，每周手动截图对比既费时又容易漏。下面这套做法把三块数据拉进一个脚本，由 AI 生成一段可读的运营简报，每周一早上自动发到邮箱。

数据从哪来：三条稳定取数路径

先说清楚数据源，否则脚本写得再漂亮也是空的。Search Console 的抓取统计和索引覆盖没有公开的 REST 接口，实际操作中有三条路可选。

• Search Console API：能拿到 searchanalytics 查询数据、sitemap 状态，但索引覆盖明细字段有限，适合做趋势。
• GSC 批量数据导出：在 Search Console 里点「导出」，存入 Google Cloud Storage 或直接下载 CSV，脚本读取本地文件最稳。
• PageSpeed Insights API：核心网页指标走这个接口，免费额度每天 25000 次，单 URL 调用即可拿到 LCP、INP、CLS 的实验室与实测数据。

抓取错误建议直接从 GSC 的「网页索引编制」报告导出 CSV。导出文件名带日期，脚本按文件名排序取最近两份做环比，这样连数据库都不用建。

脚本结构：采集、比对、生成三段式

第一段：采集与清洗

用 Python 的 pandas 读取导出的 CSV，统一列名后合并成一个宽表。关键字段包括：报告日期、错误类型、受影响 URL 数、已索引页面数、未索引原因分布。PageSpeed 数据用 requests 逐个调用，注意加 0.5 秒间隔避免触发限流。

import pandas as pd, requests, time

def psi(url, key):
    api = "https://www.googleapis.com/pagespeedonline/v5/runPagespeed"
    r = requests.get(api, params={"url": url, "key": key, "strategy": "mobile"})
    d = r.json()["lighthouseResult"]["audits"]
    return {"url": url, "lcp": d["largest-contentful-paint"]["numericValue"],
            "cls": d["cumulative-layout-shift"]["numericValue"]}

第二段：阈值比对

光有数字没有判断，简报就变成流水账。给每个指标设一条红线，脚本自动打标签。下面这套阈值是按中小型内容站的经验值定的，可按自己站点调整。

比对结果写入一个 dict，只保留触发预警和告警的条目。正常项不进入简报正文，避免运营者被无关信息淹没。

第三段：交给大模型写简报

把比对结果、本周与上周的差值、以及受影响的代表性 URL 拼成一段结构化 prompt，调用任意支持长文本的模型接口。prompt 里明确要求三件事：按严重程度排序、每条给出一个可执行动作、全文控制在 300 字内。

提示词里务必写明「不要复述数字，只解释变化原因和下一步动作」，否则模型很容易把表格内容原样念一遍，简报失去价值。

一周实操节奏与三个易踩的坑

建议把脚本挂到服务器 cron，每周一 7:00 跑一次，输出同时存 Markdown 和邮件正文。第一次跑之前先手动验证三轮数据，确认 CSV 列名没变、API key 有效、阈值判断方向正确。

1. 周日晚导出 GSC 两份 CSV，放入 data 目录。
2. 周一 7:00 cron 触发脚本，采集 PSI 数据并比对。
3. 7:10 生成简报，邮件推送，同时归档到周报目录。
4. 人工花 5 分钟复核告警项，决定是否当天处理。

踩坑点集中在三处。GSC 导出文件的编码偶尔是 UTF-16，pandas 读取要显式指定 encoding。PSI 接口对同一 URL 有缓存，连续调用会返回旧值，需在参数里加时间戳干扰。索引覆盖率的分母会随站点改版跳变，环比差值比绝对值更值得关注。

这套流程跑顺之后，每周花在数据整理上的时间从 1 小时压到 5 分钟，剩下的精力可以放在真正影响排名的内容更新和外链上。工具不复杂，难的是把阈值和动作固化下来，让它每周替你盯住那几条不能破的线。