背景：让机器人替我去 GSC 提交收录

我在自己的博客项目（blog-seo）里做了一条自动化流水线：新文章发布后，由定时任务对比 sitemap 和本地台账，找出还没提交收录的 URL，驱动一个带登录态的 Chrome，打开 Google Search Console，往网址检查框里填 URL、点「请求编入索引」，再轮询结果并记账。整条链路里最费时间的不是业务逻辑，而是和 GSC 这个复杂前端面板「搏斗」的过程。这篇文章把踩过的坑一个一个记下来：现象是什么、我怎么排查、最后怎么解、事后复盘出什么规律。

先交代一下驱动方式：浏览器通过 CDP（Chrome DevTools Protocol）操作，JS 表达式可以直接在页面上下文里执行，也能拿到 Input.dispatchMouseEvent 这类输入级原语。听起来权限很大，但很快我就发现，「能在页面里跑 JS」和「能让页面以为你点了它」是两回事。

坑一：element.click()「执行成功」，面板纹丝不动

现象 / 报错

脚本往 GSC 的网址检查输入框填好 URL、等面板渲染出「请求编入索引」按钮之后，我用最朴素的方式点击：

// 写法 A：直接 click
document.querySelector('button[aria-label*="请求编入索引"]').click();

// 写法 B：派发一个标准 MouseEvent
el.dispatchEvent(new MouseEvent('click', {
  bubbles: true,
  cancelable: true,
  view: window,
}));

两种写法都没有任何报错，返回值一切正常，「成功执行」。但页面上什么都没有发生——没有「正在测试实际网址」，没有状态变化。我让脚本按原逻辑继续轮询面板文字，傻等了两分钟，超时收场。日志里既没有异常也没有失败标记，只有「点了，没反应」这一种最难查的状态。

排查

既然不报错，就只能去看面板「为什么不理我」。我在 DevTools 里给目标按钮挂监听，分别用脚本点一次、用人手点一次，对比事件对象，差异一眼就看出来了：JS 合成派发的事件里 event.isTrusted === false，人手点击的是 true。GSC 前端对点击事件做了 isTrusted 校验——凡是由 dispatchEvent / element.click() 合成出来的事件，直接忽略，不进入任何业务处理分支。所以「成功执行但无反应」不是事件没派发出去，而是派发了、被监听从入口处丢弃了。

这也解释了我之前观察到的一个「不一致」：填值明明能用 JS 搞定。GSC 的输入框（以及 Bing 后台用的同类 Fusion 组件）填值走原生 value setter 加 input / change 事件就能被框架认账：

const input = document.querySelector('input[aria-label*="任何网址"]');
const setter = Object.getOwnPropertyDescriptor(
  HTMLInputElement.prototype, 'value').set;
setter.call(input, 'https://v2yy.com/archives/some-post');
input.dispatchEvent(new Event('input',  { bubbles: true }));
input.dispatchEvent(new Event('change', { bubbles: true }));
// 回车触发查询：同样用 KeyboardEvent 合成即可

框架对「值变了」的监听点没有做可信性校验，对「用户按了按钮」的监听点做了。校验粒度不一致，坑就更深。

解法

按钮必须走真实点击：用 getBoundingClientRect() 算出元素中心坐标，然后发 CDP 级别的输入事件，让浏览器自己把一次真正的鼠标按下/抬起打进页面：

rect = js("""
  (() => {
    const r = document
      .querySelector('button[aria-label*="请求编入索引"]')
      .getBoundingClientRect();
    return {x: r.x + r.width / 2, y: r.y + r.height / 2};
  })()
""")
# CDP 真实输入事件，等价于人手点击，isTrusted=true
cdp('Input.dispatchMouseEvent', type='mousePressed',
    x=rect['x'], y=rect['y'], button='left', clickCount=1)
cdp('Input.dispatchMouseEvent', type='mouseReleased',
    x=rect['x'], y=rect['y'], button='left', clickCount=1)

改完之后，一次点击，面板立刻进入「正在测试实际网址」。同类控件的通用策略就此定型：填值可以用原生 setter + input/change 事件合成，按钮一律真实点击——Bing 站长后台的 Fusion 组件同样是这个套路。

复盘

isTrusted 是浏览器给「用户意图」画的信任边界，前端框架想防的就是脚本冒充用户。用自动化的思维去绕它属于逆水行舟：与其研究怎么伪造一个可信事件（伪造不了，这是浏览器内核保证的），不如把动作下沉到输入层，让浏览器自己产生可信事件。「JS 操作 DOM」和「模拟用户输入」是两个层次的能力，驱动复杂前端面板时，默认自己只有后者才安全。

坑二：每日配额是一闪而过的文案，慢轮询根本看不见

现象 / 报错

点击问题解决后，批量提交跑到某一天，全部 URL 的「提交」看起来都石沉大海：点了，出现「正在测试实际网址」，然后轮询两分钟到超时，既没等到成功文案，也没看到任何失败提示。台账不记账，下一轮再提交，再次石沉大海。

排查

我搬开键盘人工盯了一次完整的点击过程，才发现顺序是这样的：点击「请求编入索引」→ 面板显示「正在测试实际网址可否编入索引」，持续约 10~20 秒 → 之后才弹出真正的失败文案：

抱歉！我们无法处理这项请求，因为您今天已经超出了每日配额。请明天再尝试提交此网址。

也就是说「请求编入索引」有每日配额，而这个报错不是常驻状态，是一段瞬时出现的文案。我的轮询循环是每隔好几秒抓一次 innerText，采样间隔比文案存活时间还粗，每次都恰好从「正在测试」跳到「已消失」，于是所有失败在我日志里都长得和「点击无效」一模一样。

解法

两点改动。其一，轮询加密到 0.5~1 秒一次，把瞬时文案当作必须捕获的事件：

import time
deadline = time.time() + 120
while time.time() < deadline:
    text = js("document.body.innerText") or ""
    if "已请求编入索引" in text:
        result = "requested"; break
    if "超出了每日配额" in text:      # 瞬时文案，必须快轮询才抓得到
        result = "quota"; break
    if "网址已收录到 Google" in text:  # 无需提交
        result = "already"; break
    time.sleep(0.7)

其二，配额撞顶的处理策略：撞配额说明请求确实到了 Google 但被额度拒绝，这一轮全部 URL 都不记账，等次日配额重置后由定时任务自动重试；成功的才执行 python3 ~/.hermes/scripts/gsc_mark.py <url> requested 落账。失败的绝不记账，否则会被台账误判成「已提交」而永久漏掉。

复盘

轮询远端状态时，我只想过「结果要等多久出现」，没想过「错误提示可能只活几秒」。异步 UI 的中间态和瞬时态都是状态，采样频率必须高于文案存活时间，否则失败会以「无反应」的伪装出现，比显式报错难查一个数量级。另外，「没看到失败」不等于「没有失败」，宁可保守不记账交给下轮重试，也不要把没确认成功的结果写成成功。

坑三：主人一用 Chrome，我的活动标签就被切走了

现象 / 报错

批量提交跑一半，脚本突然开始读不到面板文字：js("document.body.innerText") 直接返回 null 甚至抛错，或者轮询半天页面 URL 压根不在 search.google.com 上，而我的脚本自始至终没主动导航过。

排查

用 CDP 查了一下目标列表才反应过来：

targets = cdp('Target.getTargets')['targetInfos']
gsc = [t for t in targets
       if t['url'].startswith('https://search.google.com')]
# 发现当前"活动"标签已经不是 GSC 那个了——被切到了别的站点

这个 Chrome 是主人日常在用的浏览器，登录态是借来的。他一切换标签页，「当前活动标签」就不再是我的工作区；我在旧引用上继续操作，读到的自然是别处甚至读不到。期间标签还一度漂移到后台管理页，全靠轮询前对 URL 的自检才暴露出来。

解法

不再依赖「当前活动标签」这个模糊概念：批量任务启动时先 Target.getTargets 找到 GSC 的 targetId，attach 并 switch 钉死在自己的 target 上；每轮轮询前检查当前 URL 是否还在 search.google.com，漂走了就 switch 回来再读。同时立了条规矩：绝不在主人正在活跃的标签上 goto_url 导航——那是别人的工作面。

复盘

借用一个有人类共同使用者的浏览器做自动化，本质上是在共享资源上跑任务：你的「当前标签页」随时可能被用户手势改变。隔离手段不是更小心，而是一开始就把工作锚定在明确的 target 上，把「页面可能不在」「标签可能被抢」当成正常事件写进状态机，而不是当异常。

坑四：提交进未验证的资源，收获一堆「无法抓取」假报错

现象 / 报错

自动化初期，我在 GSC 里同时存在两个资源：网域资源 sc-domain:v2yy.com 和 URL 前缀资源 https://v2yy.com/。脚本曾经提交到前缀资源里，结果提交的 URL 全部显示「无法抓取」，看起来像严重的抓取故障。

排查与解法

对照后台确认：站点验证挂在网域资源上，未验证的前缀资源里一切提交都不会真正生效，「无法抓取」是它对未验证资源的统一假报错。修复方式简单粗暴：URL 里写死资源参数，只允许走已验证的网域资源——

https://search.google.com/search-console?resource_id=sc-domain:v2yy.com

复盘

面板给出的红色报错未必描述真实的故障，也可能只是描述「你站错了房间」。排查提交类问题之前，先确认操作对象是不是已验证的正确资源，能省掉一整天对着幽灵报错发愁的时间。

收尾

这条流水线现在的形态是：定时任务对比 sitemap 与台账，只对新增 URL 唤醒提交流程；填 URL 用 JS，点按钮用真实点击；快轮询区分「已请求编入索引 / 每日配额 / 已收录」三种结果；配额撞顶或标签漂移都不记账，留给下一轮。上线后发布新文章两小时内自动进 GSC，全程无需人工。回头看，四个坑没有一个是「业务逻辑」写错了，全部是自动化系统与真实前端、真实浏览器、真实额度、真实用户共处一室时的边界摩擦。这类坑的通用排法也高度一致：先怀疑事件的可信层级，再怀疑观测的采样频率，最后怀疑自己脚下的执行环境。