GSC 网页界面导出有两个硬限制：一次最多 1000 行，数据只保留 16 个月。想按查询加页面组合看，或者想留三年数据做对比，只能走 API。2026 年 3 月我们把三个客户站的数据全部改成 API 拉取，每周自动更新。
为什么不用界面导出
一是行数限制。一个中型站有几十万个查询页面组合，1000 行只是九牛一毛。二是维度限制，界面能导的维度组合有限，想同时看查询和落地页就得靠 API。三是时间，16 个月之后历史数据就没了，想对比去年同期得提前存下来。
还有个体力问题：每个客户每周手动导一次，一个月就是十几次重复劳动，迟早会忘。
准备工作
在 Google Cloud 里建项目，启用 Search Console API，创建一个服务账号，把服务账号邮箱加到 GSC 的站点用户里，权限给“完全”。这一套二十分钟能配完。
用服务账号比 OAuth 省事，不需要人授权，适合定时任务。代价是权限管理要谨慎，服务账号泄露等于站点数据泄露。
拉什么
四个维度组合：查询加页面、查询加国家、页面加设备、日期加查询。每个组合分别拉，别指望一次全部拿到。
日期范围建议按周拉，不要按天，按天拉请求次数多、数据还经常不完整。GSC 数据有 2 到 3 天延迟，拉最近三天基本是空的。
分页要处理，单次请求有行数上限，返回里带分页游标，循环取完为止。
存哪
我们存 SQLite，一个客户一个库，表结构固定：日期、站点、查询、页面、国家、设备、点击、曝光、排名。每周增量写入，保留全部历史。
存下来之后能做的事很多：看某个词的排名变化曲线，看某篇文章上线后多久开始有曝光，看品牌词占比的月度趋势。这些在界面里都看不到。
拉下来的数据怎么用
我们最常用的查询是：某篇文章上线 30 天后，它覆盖的查询有多少进了前 20。这个在界面里要一页页翻，在库里一条 SQL 就出来。
另一个用途是内容复盘。每季度把写过的话题拉出来，看每个词的平均排名和点击，决定下一季度加不加码。
数据留到三年之后，还能看季节性和算法更新的影响。这些分析都建立在同一张表上，不用每次重新导。
三个坑
第一，配额是每天 2.5 万行，站大、维度多的话一天就可能用完，要错开任务时间。
第二，不同维度组合的行数不能直接相加，会重复计算。查询加页面和查询加国家是两套口径，混着算总数一定错。
第三，品牌词要单独标记。我们用正则匹配品牌名，存的时候加一个字段，分析时能一键排除。
元析智能
为软件公司做 SEO 和 GEO 优化