Search Consoleへのサイト登録と所有権確認をAPIだけで通す

Search Consoleへのサイト登録と所有権確認をAPIだけで通す

新しく作ったサイトを、Search Consoleの管理画面を一度も開かずに登録しました。所有権確認・サイト追加・サイトマップ送信を、すべてAPIへのリクエストだけで通した記録です。トークンをどこから調達したか、どこで詰まったかまで書きます。

やったこと:管理画面を開かずにSearch Consoleへ登録した

新規サイトを立ち上げたとき、通常なら Search Console にログインしてプロパティを追加し、所有権確認の手順を画面の指示どおりに進めます。今回はそれを全部やめて、APIへのリクエストだけで完結させました。

やることは大きく3つです。

  1. 所有権確認(siteVerification API)
  2. サイトの追加(webmasters API)
  3. サイトマップの送信(webmasters API)

順番も大事で、所有権が通っていないサイトは追加できないので、先に確認を済ませるという流れになります。

トークンは「既にSearch Consoleに繋がっている別サイト」から借りた

最初の関門は認証です。新規サイトには当然、Search Console 用のOAuthトークンなどありません。

そこで、すでにSearch Consoleに接続済みだった別サイトのOAuthトークンを流用しました。同じGoogleアカウントで運用しているサイトなら、トークン自体は使い回せます。

ここで確認すべきなのはスコープです。借りたトークンには、

  • siteverification の権限
  • webmasters の権限

この2つが両方付いていたので、所有権確認からサイト追加・サイトマップ送信まで、同じトークン1本で通せました。

ポイント

所有権確認は siteverification、サイト追加とサイトマップ送信は webmasters と、必要な権限が分かれています。片方しか無いトークンだと途中で止まります。借りる前にスコープを見てください。

所有権確認:トークンを取ってファイルを置く

1. 確認用のファイル名をもらう

まず siteVerification API にPOSTして、確認用ファイルの名前を発行してもらいます。

POST siteVerification/v1/token

レスポンスとしてファイル名が返ってきます。この名前はこちらで決められるものではないので、返ってきた文字列をそのまま使います。

2. 返ってきた名前でHTMLファイルを置く

受け取った名前のHTMLファイルを、対象サイトのドキュメントルート直下に配置します。ここはAPIの外側の作業なので、デプロイの仕組みに合わせて書き込みます。

3. 確認をリクエストする

ファイルを置いたら、確認方法に FILE を指定してPOSTします。

POST siteVerification/v1/webResource?verificationMethod=FILE

これで所有権確認が通りました。ブラウザは一度も開いていません。

注意

ファイルを置く前にこのリクエストを投げても通りません。「ファイル配置 → 確認リクエスト」の順序が崩れると失敗します。自動化するなら、配置が完了したことを確かめてから次に進む作りにしてください。

サイト追加とサイトマップ送信:どちらもPUTで204

サイトの追加

所有権が通ったら、webmasters API にサイトを登録します。

PUT webmasters/v3/sites/{URLエンコードしたサイトURL}

ここでの注意点は、サイトURLをURLエンコードしてパスに埋め込むことです。生のURLをそのまま繋ぐとパスが壊れます。

成功すると 204 が返ります。ボディは返ってこないので、ステータスコード204をもって成功と判定する形になります。

サイトマップの送信

サイトマップも同じくPUTです。

PUT webmasters/v3/sites/{site}/sitemaps/{sitemapURL}

これも成功時は 204。サイトURLとサイトマップURLの両方がパスに入るので、エンコード漏れが起きやすい箇所です。

実測

204
サイト追加・サイトマップ送信ともに、成功時のレスポンスはこれだけ
うまくいったこと

所有権確認 → サイト追加 → サイトマップ送信 まで、借りてきたトークン1本で最後まで通りました。新規サイト側で新たにOAuthフローを回す必要はありませんでした。

詰まった点:WP-CLIだとトークンが空になる

トークンをWordPressプラグイン経由で取り出す構成にしていたのですが、ここで一度止まりました。

CLIから実行したとき、ユーザーを明示的に設定しないとトークンが空になります。ブラウザ経由なら当然ログインユーザーが決まっていますが、CLIにはそれがありません。プラグインがユーザーに紐づけてトークンを保持している場合、誰のトークンを読むのかが決まらず、結果として空文字が返ってきます。

失敗したこと

最初、トークンが空のままAPIを叩いていて、認証周りのエラーを疑って時間を溶かしました。原因はAPI側ではなく、CLI実行時にユーザーが設定されていなかったことです。自動化スクリプトを書くときは、まず「トークンが実際に取れているか」を先に出力して確かめるべきでした。

分かっていないこと

正直に書いておきます。

  • FILE以外の確認方法(メタタグ等)でも同じ流れで通るのかは、今回試していないので分かりません。
  • 借りたトークンの有効期限や、失効したときにどう扱うのが良いかは、今回の作業では確かめていません。
  • サイトマップ送信が204で返ったあと、Googleが実際にどう処理するかまでは、この作業の範囲では追っていません。

「204が返った=APIとしてのリクエストが受理された」以上のことは、この記事では保証できません。

まとめ

  • 新規サイトのSearch Console登録は、管理画面を開かずAPIだけで完結できた
  • トークンは既にSearch Console接続済みの別サイトのものを流用。siteverification と webmasters の両方の権限が要る
  • 所有権確認は siteVerification/v1/token でファイル名を受け取り、ドキュメントルートに置いてから webResource?verificationMethod=FILE にPOST
  • サイト追加もサイトマップ送信も、webmasters API へのPUTで成功時は204。サイトURLのURLエンコードを忘れない
  • WordPressプラグインからトークンを取る場合、CLIではユーザーを明示的に設定しないとトークンが空になる
広告