站群文章发出去就不管了收录率跌到15%才发现GSC和百度站长平台的API其实能自动统计每天发了多少篇收了多少带来了多少：90%的人没配过的发布统计自动化方案

做过站群的人都有一个共同的经历：内容发出去了，剩下的全靠"感觉"。今天发了30篇，明天发了50篇，月底一看，发了多少篇自己都记不清。更别说这些文章里有多少被收录了、有多少带来了流量、哪些站的内容策略需要调整。多数人是在排名掉了或者流量腰斩之后，才回头翻后台数据找原因，而那个时候已经晚了至少两周。

问题不在于没有数据。Google Search Console和百度搜索资源平台每天都有完整的收录、点击、展现数据。问题在于：10个站的时候你可以手动登录后台一个一个看，30个站的时候就变成了体力活，50个站以上基本等于没有数据——因为你根本不可能每天花几个小时去翻后台。所以大部分站群的发布统计停留在"发了多少篇"这一层，后面那三层——收录了多少、带来了多少点击、内容质量和策略要不要调整——全靠猜。

一、先把"发布了多少"这个基础数据自动化

发布量统计是四层里最简单的一层，也是唯一一层可以不依赖搜索引擎数据、靠自己的系统就能搞定。如果你用WordPress做站群，WP的REST API自带文章计数接口。如果你的站群用的是自建系统或者多套CMS混用，需要做一层简单的数据汇总。

WP站群最简单的方式：每个站部署一个统计端点，然后用一个中心化脚本定时拉取。WP的 /wp-json/wp/v2/posts 接口可以按日期范围查询文章数。以下是一个多站发布量统计的Python脚本框架：

import requestsimport csvfrom datetime import datetime, timedeltasites = {"site-a": {"url": "https://site-a.com", "key": "xxx"},"site-b": {"url": "https://site-b.com", "key": "xxx"},}today = datetime.now().strftime("%Y-%m-%d")yesterday = (datetime.now() - timedelta(days=1)).strftime("%Y-%m-%d")results = []for name, cfg in sites.items():api = f"{cfg['url']}/wp-json/wp/v2/posts"params = {"after": f"{yesterday}T00:00:00","before": f"{yesterday}T23:59:59","per_page": 100}headers = {"Authorization": f"Bearer {cfg['key']}"}resp = requests.get(api, params=params, headers=headers)total = int(resp.headers.get("X-WP-Total", 0))results.append({"site": name, "date": yesterday, "published": total})with open("publish_stats.csv", "w", newline="", encoding="utf-8-sig") as f:writer = csv.DictWriter(f, fieldnames=["site","date","published"])writer.writeheader()writer.writerows(results)print(f"统计完成，{len(results)} 个站点数据已写入")

如果你不是WP站群，用的是UC建站这种HTML直出的系统，发布量的统计方式略有不同。HTML直出系统一般有自己的内容管理后台，文章发布时会生成对应的HTML页面并记录在数据库中。直接从数据库的posts表按日期和站点ID聚合查询就行，比调API更快。而且HTML直出的页面不依赖PHP渲染，搜索引擎爬取效率更高，这也是后面收录率统计能更准确的基础。

二、收录率统计才是真正有技术含量的那一步

发布量统计谁都能做，加个计数器就行。收录率统计难在：Google和百度的数据都在各自的站长平台里，而且这两个平台的数据都不太方便批量导出。Google Search Console的数据导出上限是1000行，百度搜索资源平台的索引量页面连导出按钮都没有，只能截图。

先说Google侧。GSC提供了两种获取收录数据的API：Search Analytics API（查搜索表现数据，包括点击、展现、排名）和URL Inspection API（查单个URL的索引状态）。做收录率统计，两个都要用。

Search Analytics API 的一个关键用法：按页面维度查询，然后统计"有展现"的URL数量。在GSC里，一个页面有搜索展现基本意味着它已经被收录了（极少数例外是某些查询触发了未被收录的页面，但概率很低）。所以 有展现的URL数量 / 已发布的URL数量 ≈ 收录率。虽然这个"收录率"不是100%精确——因为有些页面被收录了但还没获得任何搜索展现——但对于站群级别的统计来说，这个近似值已经足够用了。

from googleapiclient.discovery import buildfrom google.oauth2 import service_accountSCOPES = ["https://www.googleapis.com/auth/webmasters.readonly"]creds = service_account.Credentials.from_service_account_file("service_account.json", scopes=SCOPES)service = build("searchconsole", "v1", credentials=creds)request = {"startDate": "2026-07-25","endDate": "2026-08-01","dimensions": ["page"],"rowLimit": 5000}response = service.searchanalytics().query(siteUrl="https://example.com",body=request).execute()indexed_pages = len(response.get("rows", []))print(f"过去7天有展现的页面数: {indexed_pages}")

URL Inspection API 更精细，但受2000次/天的配额限制。对于站群场景，不能用它逐条检查所有URL。正确用法是分层抽样：核心页面（比如每个站的前50篇文章）每天扫一次；新发布的内容连续扫3-7天跟踪收录速度；长尾内容每周轮询一次。如果某个站的核心页面突然出现大量"已抓取但未索引"状态，说明内容质量或网站权威度出了问题。

三、百度侧的统计：不能只看Google那套

如果你的站群面向的是百度流量，那百度搜索资源平台的数据必须纳入统计。但百度的开放程度和Google压根不在一个量级：GSC有完善的REST API，百度的索引量页面连导出CSV的功能都没有。做百度侧的批量统计，要绕一些弯。

百度搜索资源平台提供了"普通收录"的API推送接口，每个站点有一个独立的token。但这个API只负责"推送URL"，不负责"返回收录状态"。推送成功了不代表收录了。要查收录状态，目前唯一可靠的方式是通过百度站长平台的"索引量"页面手动查看——这显然不支持批量统计。

实际操作中，百度侧的收录统计更适合用"趋势监控"而不是"精确计数"。每周记录一次各站的site:结果和第三方工具数据，画一条收录趋势线。如果某条线连续三周往下走，说明那个站的内容策略或技术状态出了问题。具体的收录数量可以不那么精确，但趋势方向必须是准的。

还有一个数据来源是百度搜索资源平台的"抓取频次"报表。这个报表可以导出CSV，而且不需要API。每个站的抓取频次变化直接反映了百度对站点的信任度：抓取频次在涨，说明百度觉得你的站内容更新及时、有价值，收录率通常也会跟着涨。反之，抓取频次持续下降，收录率几乎不可能提升。

四、从"收录了多少"到"收录了什么"：点击量统计才见真章

收录量高不等于流量高。一个站收录了5000篇文章，但每篇文章每天只有0.1次点击，总流量500/天。另一个站只收录了800篇文章，但每篇每天2次点击，总流量1600/天。前者内容数量多但质量差，后者内容精但命中率高。只看收录量不看点击量，你会得出"A站比B站强"的错误结论。

GSC的Search Analytics API可以按页面维度拉点击量数据。拉下来之后做三件事：第一，计算单篇文章的平均点击量（总点击 / 有展现的URL数）；第二，按点击量对页面排序，找出点击量前20%的页面贡献了多少流量——通常你会发现前20%的页面贡献了80%的流量，这是正常的帕累托分布；第三，标记"有收录但零点击"的页面，这些是内容方向需要调整的信号。

做站群点击量统计的时候，还有一个维度经常被忽略：新内容和老内容的点击贡献比。每个月拉一份报表：本月新增的点击量中，有多少来自最近30天发布的新文章，有多少来自30天以前的老文章。如果老文章贡献了70%以上的新增点击，说明你的内容有持续的长尾价值，这是站群质量高的标志。如果新文章贡献了绝大部分点击，说明内容缺乏长尾效应——收录后短期有流量，过两周就没人搜了。这种情况通常是因为关键词太窄、太时效性，或者内容太浅。

五、把四个数据层串成一张看板

前面拆开讲了四个数据层的统计方法：发布量（自建系统查）、收录率（GSC API + 百度替代方式）、点击量（GSC Search Analytics API）、效率比（点击量 / 发布量 / 收录量交叉计算）。分开看每层都有工具，但真正的价值在于把它们串成一张表，一眼看到哪个站的哪个环节出了问题。

一张好的站群统计看板，至少应该包含以下列：站点名称、本周发布量、本周发布量环比、累计发布量、收录量（Google）、收录率（Google）、收录量（百度）、收录率（百度）、本周点击量、本周点击量环比、单篇平均点击、零点击页面占比。12列，30个站，一张A3纸能打印下来。

看上面这个示例表格：site-01的问题是百度收录率只有41%，但Google收录率72%——说明不是内容本身的问题，更可能是百度推送没做到位或者百度对那个站的信任度不够。site-03收录率很高，但单篇点击只有0.3，零点击页面占比47%——收录了但没人点，关键词策略有问题，发的文章命中的都是没人搜的长尾词。

做这个看板，技术上需要三块拼起来：发布量从自己的CMS数据库取、Google收录率和点击量从GSC API取、百度收录率从第三方工具或抓取频次报表推算。如果你不想从头写这套管线，UC建站系统本身带了一个多站统一看板——索引量、排名、流量、异常预警都在一个界面里，不需要每个站单独登录GSC和百度站长平台。30个站的数据汇总，手动操作要半天，系统拉数据只需要一次刷新。

六、异常告警比统计数据更有价值

有了看板，下一步就是设置告警。数据放在看板上你不一定会看——这是人性。但告警是被动触发的，不处理会一直提醒。站群发布统计的告警应该覆盖以下几类场景：

发布中断告警。某个站连续48小时没有新文章发布。原因通常是内容生成API挂了、关键词库耗尽了、或者定时任务被意外停掉了。这个告警最基础，也最容易实现——一个定时脚本检查数据库里每个站的最新文章发布时间就行。

收录率骤降告警。某个站的Google收录率单周下降超过15%，或者百度收录率连续两周下降超过10%。收录率骤降通常意味着网站出现了技术问题：robots.txt被改错了、服务器返回了大量5xx错误、sitemap失效了、或者是搜索引擎对内容质量做了重新评估。不管是哪种情况，早发现早处理。

内容效率告警。某个站的新内容零点击率超过40%。零点击意味着收录了但没带来流量，要么是关键词太窄，要么是标题写得让人不想点。这种情况不需要紧急处理，但需要列入内容策略调整的待办清单。

排名骤变告警。GSC Search Analytics API可以按查询维度拉排名数据。如果某个站的核心关键词平均排名一周内掉了超过5位，可能是被竞争对手挤下去了或者内容时效性衰减了。排名变化往往比流量变化早1-2周出现——流量还没掉，但排名已经在掉了，这是最佳的干预窗口。

七、从手工翻后台到系统化统计，效率差了不止10倍

回过头来看整个发布统计的链路：从CMS取发布量→GSC API拉收录和点击→百度侧通过第三方或脚本补充→四层数据汇总到看板→设置异常告警。这条链路对单站来说没必要——登录一次GSC后台、打开百度站长平台看看索引量，五分钟搞定。但对10个以上的站点来说，手工做这些事的边际成本是指数级上升的。

10个站的时候，每周花2小时翻后台做统计还能接受。30个站的时候，同样的工作需要6-8小时，基本占了一整个工作日。50个站以上，手工统计已经不是时间问题，而是可行性问题——你不可能记住每个站的上周数据来和本周做对比，最后就是凭感觉判断"这个站还行""那个站不太行"。

做站群的人经常讨论"内容质量""外链策略""关键词布局"，但很少讨论"我怎么知道这些策略起没起作用"。发布统计工具解决的就是这个"反馈回路"的问题：策略调整→数据反馈→再调整。没有数据反馈的策略调整，本质上是在赌博。

最后说一个容易忽略的点：统计数据本身也需要定期校准。GSC的API偶尔会返回不完整的数据（Google服务端限流、认证token过期等），百度侧的第三方工具数据也有误差。每个月抽一天时间，随机选3-5个站，手动登录GSC和百度站长平台，把手工查到的数据和系统自动统计的数据做个交叉验证。偏差超过15%的，排查是API调用的问题还是数据源本身的问题。这套统计系统的准确性取决于你有多久没校准它。