Google Search Console（以下GSC）のURL削除ツールを自動化しようとして、多くのエンジニアが挫折します。なぜSeleniumやPuppeteerなどの強力なツールを使っても、この単純に見える「URLを貼ってボタンを押す」作業がこれほどまでに難しいのか。
1. Googleが仕掛ける「isTrusted」の壁
最大の理由は、Googleがブラウザのネイティブイベントを厳格に監視していることです。
JavaScriptの .value = "URL" というコードで値を書き込んでも、GSCの「次へ」ボタンは青くなりません。これは、Googleのスクリプトが「キーボードから直接入力されたか（isTrusted: true）」というイベントをトリガーにバリデーション（検証）を行っているためです。
自動化の末路: スクリプトで値を流し込んでも、画面上は「空欄」とみなされ、物理的に「次へ」が押せない状態になります。
複雑な回避策: 擬似的にキーボード入力をシミュレートする処理が必要になりますが、これもGoogleの高度なBot検知によって阻まれることが多々あります。
2. 難読化されたDOMと非同期処理
GSCのHTML構造は、人間が読むことを想定していない「難読化」が施されています。
動的なID: ボタンや入力欄の id や class 名は、ページをリロードするたびに変わる、あるいは非常に複雑な文字列（例：jsname="YPqjbf"）になっています。
非同期のダイアログ: 「新しいリクエスト」ボタンを押してから入力欄が出現するまで、わずかなアニメーションや通信が発生します。全自動Botはこの「待ち時間」が100msズレるだけで空振りし、エラーで停止します。
3. 「メッセージ」による成否判定の難しさ
全自動化する場合、「正しく送信されたか」を確認しなければなりませんが、GSCは結果をページ遷移ではなく、画面下部の「スナックバー（一時的な通知）」で知らせます。
この通知が出るタイミングは通信状況に左右されます。Botが次の作業を急ぎすぎると、前の処理が重複エラー（409 Error）を起こしていることに気づかず、リストがズタズタになるリスクがあります。
4. メンテナンス・コストの逆転現象
Googleは予告なしにUI（ユーザーインターフェース）を変更します。
2,000件のURLを処理するために3日かけて「完璧なBot」を作っても、翌日にGoogleがボタンの配置を変えれば、そのBotはゴミクズ同然になります。「自動化を維持するコスト」が「手作業の苦労」を上回ってしまうのが、GSC自動化の最大の罠です。
GSCのURL削除でお悩みなら是非ご相談ください。
