Invalid site keyは、まず有効なサイトキーとの一致を確認するエラーです。キーの種別とドメインの点検は分け、表示が直った後のサーバー検証も省略しません。

この記事の要点
reCAPTCHA の ERROR for site owner: Invalid site key 最初に有効なサイトキーとの一致を確認。キーの種別・許可ドメインは別項目として切り分ける 対処1: reCAPTCHA 管理画面で site_key / secret_key を確認、取り違えていないか確認 対処2: 実際のホストと許可ドメインの関係を確認。親ドメインの登録はサブドメインも対象

 

エラー内容

ERROR for site owner: Invalid site key

reCAPTCHA を画面に表示しようとしたとき、reCAPTCHA ウィジェットの代わりに赤いエラーメッセージが表示されるケースです。「site owner」と書かれていても、ウィジェットのエラーはページを開いた利用者にも見えます。表示を隠したりサーバー検証を省略したりする対処ではなく、配信しているキーと実装・登録設定を確認します。

発生条件 / 原因

Google公式FAQは、この文言をサイトキーが有効でない状態として案内し、新しいキーの登録を案内しています。まず管理画面の有効なサイトキーとHTMLの値が一致するかを確認します。以下は関連する設定ミスの点検項目で、ドメイン不一致やキー種別違いが必ず同じエラー文言になる、という意味ではありません。

• site_key（サイトキー）が誤っている — キー文字列が間違っている／別のサイトのキーを貼り付けている
• reCAPTCHA管理画面の Domains 一覧に、現在表示しているドメインが登録されていない
• v2チェックボックス / v2 Invisible / v3のキー種別と実装方式を取り違えている — v2用キーで v3 のスクリプトを読み込んでいる等
• キーに対応しないAPI・JavaScriptを選んでいる。ただしClassicからCloudへ移行済みというだけで、従来連携が使えないとは限らない
• secret_key（サーバー側で使う方）を site_key 側に貼ってしまった

対処法

1. site_key の値を確認

reCAPTCHA 管理画面を開き、対象サイトの設定から サイトキー（site_key）と シークレットキー（secret_key）を確認します。

• site_key: フロントエンドの data-sitekey や grecaptcha.render で使う
• secret_key: サーバー側で検証APIを叩くときに使う

両者を取り違えていないか必ず確認します。公開HTMLのdata-sitekeyやrenderへ渡る値と、管理画面のサイトキーを比較します。ソース設定だけでなく、実際に配信されたHTML・JavaScriptの置換漏れや空文字も確認してください。キーを作り直す場合はフロントとサーバー側の対応を揃え、動作確認前に既存キーを削除しないでください。秘密鍵を公開した場合は、HTMLから除くだけでなく鍵の更新・漏えい範囲の確認が必要です。

2. Domains 一覧に現在のドメインが含まれているか

管理画面の対象サイト → 設定 → Domains に、HTMLが配信されているドメインが登録されているかを確認します。example.comを登録すると、そのサブドメインも対象になります。「サブドメインは必ず個別追加」とは限りません。www.example.comだけを登録した場合などは、許可した範囲と実際のホストを確認してください。

• localhost: 開発用にlocalhostを追加することも可能
• サブドメイン: example.com を登録すれば www.example.com 等のサブドメインも対象
• 登録形式: ドメイン欄にはホスト名を入力し、パス・ポート・クエリ・フラグメントは含めない

3. reCAPTCHA のバージョンを合わせる

バージョン	スクリプト読み込み	HTML
v2 チェックボックス	https://www.google.com/recaptcha/api.js	<div class="g-recaptcha" data-sitekey="..."></div>
v2 Invisible	https://www.google.com/recaptcha/api.js	同上 + data-size="invisible"
v3	https://www.google.com/recaptcha/api.js?render=サイトキー	不要（JSで grecaptcha.execute）

管理画面で発行されたキー種別に合うHTML/JSを使います。この表は従来のapi.js方式で、v3はJavaScript呼出しとサーバー判定が必要です。「HTML不要」はサーバー検証も不要という意味ではありません。Cloud用のenterprise.js / grecaptcha.enterpriseを使う構成へは、文字列置換だけで移行しないでください。

Google Cloud公式の移行案内では、Classicキーを移行した後もsiteverifyを使った検証を継続できると説明しています。「Cloudで管理されている＝api.jsでは使えない」と即断せず、移行元のキーと現在使っている連携方法を照合します。

4. 実装の確認例（v2）

以下は元のフロント側の構成例です。data-sitekeyは自分のサイトキーへ置換します。/submitは自分の受信処理の例示パスであり、貼り付けるだけで検証APIが実装されるわけではありません。既存フォームへ組み込む場合はformを入れ子にせず、api.jsもページ内で重複読込みしないでください。

<script src="https://www.google.com/recaptcha/api.js" async defer></script> <form action="/submit" method="POST">     <div class="g-recaptcha" data-sitekey="ここにsite_key"></div>     <button type="submit">送信</button> </form>

注意点

• site_keyはHTMLへ配置する公開識別子ですが、許可ドメイン・利用状況の管理は必要です。secret_key はサーバー専用、絶対にHTMLに出さない
• ドメイン変更時は管理画面の Domains を必ず更新する
• 本番ドメインと開発ドメインで別のキーを使い分けると安全（誤って本番キーが開発に出回るのを防げる）
• Cloudflare等のCDN経由で複数ドメインから配信している場合、利用するホストが許可ドメインとそのサブドメインの範囲に入るか確認する

設定変更後も直らないときの確認順

1. エラー全文、表示URLのホスト、使用方式（v2/v3/Enterprise API等）を記録します。秘密鍵や生トークンを問い合わせ・スクリーンショットへ含めないでください。
2. ブラウザー開発者ツールで、配信HTMLのサイトキーとscriptのURLを確認します。公開されるサイトキーと、サーバー専用の秘密鍵は別です。環境変数がビルド時置換なのか、実行時にHTMLへ出力されるのかも分けます。
3. Domainsはスキームなしのホスト形式で確認します。example.comの登録でwww.example.comも対象です。別ドメインや別TLDは同一ではありません。localhostは開発用キーに追加します。ポート違いを理由にexample.com:8080を登録する必要はありません。
4. 従来の管理画面のDomains変更は、公式説明では反映まで最大30分かかる場合があります。反映待ちと、自分のCDN・HTMLキャッシュが古いキーを出している状態は別に確認します。
5. 有効なキーとの照合、キー種別・ホスト設定を直して再表示します。エラーを消すためにドメイン検証を無条件に解除する対処は勧めません。

表示が直った後に必要な検証

ウィジェットが表示できても、送信を受けるサーバーでトークンの検証が必要です。v2のSiteVerifyではsecretとresponseを送信し、成功判定だけでなくhostnameも自分が管理する許可値と照合します。通信失敗・不正応答は成功として扱いません。トークンは2分以内・1回限りで、期限切れや再利用では再取得します。CSRF対策・入力検証・認可も別途必要です。

表示後のフォーム処理まで確認する場合は、reCAPTCHA v2のフォームとサーバー検証例を参照してください。公式テストキーは試験用で、本番での不正利用対策の代用にはしません。本稿では実キーでGoogleの画面エラーを再現したものではなく、設定説明を公式資料と照合しています。

公式資料

2026年10月確認: Invalid site key・テストキーのFAQ、許可ドメインと検証の注意、Domainsの形式と反映時間、Classic移行後の連携、サーバー検証。