公開した記事がブラウザで読めるだけでは、GoogleがそのURLを発見し、クロールし、検索結果へ表示できる状態になったとは限りません。
Search Consoleで所有権確認が完了しても、それだけで記事のインデックス登録まで完了したわけではありません。
所有権確認、URLの発見、クロールとインデックス、検索パフォーマンスの観測は、それぞれ別の段階です。
このブログには、Search ConsoleのHTMLタグを安全に出力し、日英ページをsitemapで通知する実装がすでにあります。
設定値をどこへ入れ、公開後に何を確認するかを分ければ、画面上の「確認済み」だけを見て作業を終える事故を避けられます。
公式資料と実装は2026年7月26日に確認しました。
Search Consoleのプロパティ確認から日英sitemap、URL検査、Performance確認までの流れ*図: 所有権を確認した後、sitemapでURL群を通知し、個別URLはURL検査で状態を確かめ、検索結果の実績はPerformanceで観測する。*
所有権確認で証明できる範囲
Search Consoleの所有権確認は、そのサイトを管理できることをGoogleへ証明する手続きです。
確認済みの所有者はプロパティに対する強い権限を持ち、sitemap送信や設定管理を行えます。
しかし、HTMLタグが正しく見つかったという結果は「このページをインデックスへ登録する」という判断ではありません。
Googleは確認トークン、sitemap、各URLの取得可否、正本などを別々に処理します。
この区別がないと、確認成功の直後に検索して見つからない状態を設定失敗と誤認してしまいます。
作業の判定点は四つに分けます。
- プロパティ：どのprotocol、ホスト、パスをSearch Consoleの集計範囲にするかを決めます。
- 所有権：HTMLタグまたはDNSレコードで管理権限を証明します。
- 発見と検査：sitemapでURL群を伝え、URL検査で個別ページの状態を確認します。
- 実績：Performanceレポートで検索結果の表示とクリックを観測します。
各段階に成功条件があるため、一つの緑色表示だけで全体を判断するわけにはいきません。
URL-prefix（URL-プレフィックス）とDomainの選び方
Search ConsoleのWebサイトプロパティには、URL-プレフィックスプロパティとDomainプロパティがあります。
両者は集計範囲と所有権確認方法が異なります。
URL-プレフィックスプロパティは、protocolを含む指定プレフィックスに一致するURLだけを対象にします。
このブログなら https://kirinnoblog.work/ を登録すると、そのHTTPS ホスト配下の /ja/ と /en/ を同じプロパティで扱えます。
http:// や別のsubdomainは自動では含まれません。
HTMLタグによる所有権確認を使えるのはこちらです。
Domainプロパティは、kirinnoblog.work のようにprotocolとパスを付けずに登録し、subdomainと複数protocolをまとめます。
Domainプロパティの確認方法はDNSレコードだけです。
そのため、Domainプロパティを選んだ画面でHTMLタグを探しても表示されません。
現在のブログ実装にある google-site-verification metaタグを使う手順では、まず https://kirinnoblog.work/ のURL-プレフィックスプロパティを作成します。
DNSを管理でき、将来のsubdomainも一つに集計したい場合は、別途DomainプロパティをDNSで確認できます。
二つのプロパティを作っても検索順位が上がるわけではなく、確認範囲と分析単位が増えるだけです。
現在のNext.js実装へ確認トークンを設定する
Search ConsoleでURL-プレフィックスプロパティを追加し、所有権確認方法として「HTMLタグ」を選ぶと、次の形のタグが提示されます。
html
<meta name="google-site-verification" content="search-console-verification-token" />
管理画面へ入力するのは、content属性の値だけです。
タグ全体を貼ると、その文字列全体が新しいcontent属性へ入り、Googleが提示した値と一致しません。
記事、共有ログ、画面写真には実値を載せず、search-console-verification-tokenのようなplaceholderを使います。
このブログの管理画面には「Search Console 認証トークン」入力欄と「Search」toggleがあります。
入力欄は searchConsoleToken、toggleは searchConsoleEnabled に対応し、「設定を保存」でマーケティング設定へ保存されます。
src/lib/marketing-settings.ts の getMarketingSettings() は、実行環境の NEXT_PUBLIC_GOOGLE_SITE_VERIFICATION をフォールバックとして読みます。
本番D1に保存済みのマーケティング設定があれば、その値と有効状態がフォールバックへ重なります。
したがって、管理画面で保存する経路と環境変数で与える経路のどちらか一方を正しく管理すれば足ります。
両方を使う場合は、どちらが本番で有効かを曖昧にしないよう、保存済み設定も確認します。
src/app/layout.tsx の RootLayout は、取得した設定に応じて次の条件でmetaタグを<head>へ出します。
tsx
const marketing = await getMarketingSettings();
{marketing.searchConsoleEnabled && marketing.searchConsoleToken ? (
<meta name="google-site-verification" content={marketing.searchConsoleToken} />
) : null}
つまり、トークンが空か、searchConsoleEnabledがfalseならタグは出ません。
反対に、両方が有効なら日英ページを含む共通のroot layoutから同じ確認タグが出ます。
確認専用タグを記事本文やクライアント コンポーネントへ重ねて追加する必要はありません。
公開HTMLを確認して所有権を検証する
設定を保存したら、Search Consoleの「確認」buttonを押す前に本番の https://kirinnoblog.work/ を開きます。
ブラウザのページソースで google-site-verification を検索し、<head>内に一つだけ存在することを確認します。
管理画面の表示やローカル development サーバーではなく、プロパティとして登録した本番URLを確認することが必要です。
確認項目は次の通りです。
- homepageがログインなしで取得できます。
- metaタグの
nameは google-site-verification です。 contentにはSearch Consoleが提示した値だけが入っています。- metaタグは
<body>ではなく<head>にあります。 - URL-プレフィックスプロパティのprotocolとホストが、確認中のhomepageに一致しています。
この状態でSearch Consoleへ戻り、「確認」を実行します。
Googleは確認後もタグの存在を定期的に調べるため、確認できた直後にタグや保存済み設定を削除しません。
将来レイアウトを変更したときも、本番 HTMLにタグが残ることを回帰確認します。
確認文字列は公開HTMLから読める値であり、ログイン credentialやAPI keyとして扱うものではありません。
それでも、実トークン、email、アカウント名をtutorialへ転記する理由はないため、文書ではplaceholderに統一します。
日英URLをsitemapで送信する
所有権を確認したら、Search Consoleへこのブログのsitemapの場所を伝えます。
対象URLは https://kirinnoblog.work/sitemap.xml です。
src/app/sitemap.ts の sitemap() は getPublishedPosts() で公開記事を取得し、各記事を localizedSitemapEntries() へ渡します。
statusがpublishedのレコードだけが対象になるため、下書きのままでは記事URLはsitemapに現れません。
src/lib/locale-seo.ts の localizedSitemapEntries() は、同じslugから日本語と英語の二つのURLを生成します。
この記事を正本へ追加して公開した後に現れるべきURLは次の二つです。
https://kirinnoblog.work/ja/posts/google-search-console-nextjs-blog-setuphttps://kirinnoblog.work/en/posts/google-search-console-nextjs-blog-setup
同じヘルパーは ja-JP、en、x-default のalternate URLもsitemapへ付けます。
各言語ページのメタデータも buildLocalizedMetadata() を通じて自分自身を正本にし、相互のlanguage URLを示します。
英語版を日本語版へcanonicalizeする構成ではありません。
src/app/robots.ts も siteUrl("/sitemap.xml") を返し、crawlerへsitemapの場所を知らせます。
Search Consoleで送信する前に、ブラウザからsitemapを開き、HTTPで取得できること、XMLとして読めること、公開済みの日英URLが絶対URLで含まれることを確認します。
Search Consoleでは対象プロパティの「サイトマップ」を開き、https://kirinnoblog.work/sitemap.xml を入力して送信します。
画面の「送信」はsitemap ファイルをGoogleへアップロードする操作ではなく、公開場所を伝える操作です。
状態が「成功」になれば、Googleがsitemapを取得して読めたことを示します。
sitemapの送信は、記載した全URLのクロールやインデックス登録を保証しません。
Google公式資料も、sitemapはURLの発見を助ける一方、全項目がクロールされてインデックス登録される保証はないと明記しています。
送信後は件数を記事へ固定せず、Search Consoleの最新レポートで取得状態を確認します。
URL検査で個別ページを確認する
sitemapがURL群を伝えるのに対し、URL検査は一つの完全なURLを調べる道具です。
Search Console上部の入力欄へ日本語URLまたは英語URLを貼り付けます。
二つは別URLなので、公開直後や問題調査ではそれぞれを検査します。
URL検査には、Googleが保持するindexed バージョンの情報と、現在の公開ページを取得するlive テストがあります。
まずindexed バージョンで、GoogleがそのURLを把握しているか、前回の取得結果、indexingの可否、Googleが選んだ正本を確認します。
次に「公開URLをテスト」で現在の応答を確認し、ページ fetchが成功し、indexingを妨げる指示がないことを確かめます。
live テストは、現在のページが技術的に索引可能かを調べるもので、将来Googleが選ぶ正本を予測するものではありません。
正本の最終判断はindexed データの「Googleが選択した正本」で確認します。
このブログでは、検査対象URL自身が宣言正本になり、もう一方の言語URLはalternateになるのが意図した状態です。
新規公開または大きく更新した少数のURLでは、live テスト後に「インデックス登録をリクエスト」を使えます。
これはGoogleへ再クロールを依頼する操作であり、同じURLへ繰り返しても処理は速くなりません。
多数のURLは個別リクエストを連打せず、sitemapで通知します。
リクエスト indexingは、検索結果への即時掲載も、最終的なインデックス登録も保証しません。
Google公式資料では、クロールに数日から数週間かかる場合があり、依頼しても検索結果へ直ちに、または必ず含まれるとは限らないと説明しています。
そのため、リクエスト buttonの完了表示を索引完了として記録せず、後日URL検査で状態を見直します。
ページが検索結果に現れ始めた後は、PerformanceレポートでGoogle検索上の実績を観測します。
主要metricはクリック数、表示回数、CTR、平均掲載順位です。
平均掲載順位は、対象のサイトから表示された最上位結果の平均であり、すべての表示位置を単純平均した値ではありません。
表は検索クエリ、ページ、country、device、search appearance、dateで切り替えられます。
このブログではページ filterで /ja/ と /en/ を分けると、言語別URLの発見と流入を比較しやすくなります。
ただし、同じクエリを手元で検索した順位とレポート値が一致するとは限りません。
検索結果は時刻、場所、device、利用者の履歴によって変わるためです。
この記事には現在の索引数、クリック数、表示回数、順位を固定値として書きません。
これらは時間とfilterで変わる運用データなので、判断するときにSearch Consoleの対象期間とdimensionを明記します。
Search Consoleが測るのはGoogle検索結果での表示とクリックです。
クリック後にブログ内で何が起きたかはGoogle Analytics 4の役割なので、両者を同じ数字として比較しません。
訪問後の計測はNext.jsブログへGoogle Analytics 4を設定するで確認できます。
トラブルシューティング
最初に、登録したURL-プレフィックスと開いている本番 URLのprotocol、ホスト、パス プレフィックスを照合します。
http://のプロパティを作り、https://だけを確認している場合は一致しません。
次に、本番のページ ソースでmetaタグを確認します。
タグがなければ、管理画面の「Search」toggle、searchConsoleToken、保存結果を確認します。
環境変数をフォールバックに使う運用なら、NEXT_PUBLIC_GOOGLE_SITE_VERIFICATIONを変更した環境へデプロイされたかも確認します。
タグがあっても失敗する場合は、管理画面へタグ全体を貼っていないかを調べます。
入力欄に必要なのはcontentの値だけであり、空白を含むmeta element全体ではありません。
タグが<head>内にあり、homepageが認証なしで取得できることも確認します。
DomainプロパティにHTMLタグの選択肢がない
これは実装不良ではありません。
DomainプロパティはDNSレコードで確認する仕様です。
現在のmetaタグ経路を使うならHTTPSのURL-プレフィックスプロパティを追加し、Domain全体を扱うならDNS providerで提示されたrecordを設定します。
sitemapが取得できない
https://kirinnoblog.work/sitemap.xml をlogout状態で開き、redirect ループ、authentication、5xx レスポンスがないことを確認します。
sitemap内には同じ本番 originの完全な絶対URLが必要です。
記事が見つからない場合は、レコードのstatusがpublishedか、slugが期待値と一致するか、updatedAtが正しい日時として読めるかを確認します。
日本語URLと英語URLの片方だけを探すのではなく、両方が出力されることを確認します。
Search Consoleの「成功」は取得とparseの成功です。
個別URLの索引保証ではないため、未登録URLはURL検査へ進みます。
URLがインデックス登録されない
URL検査でindexed バージョンとlive テストを分けて読みます。
live テストではページ fetch、robotsによるcrawl可否、noindexの有無、宣言正本を確認します。
indexed バージョンではGoogleが選択した正本と、登録されなかった理由を確認します。
日英ページでは、各ページの正本が自分自身を指し、hreflang相当のalternateが相互に完全URLを指すことを確認します。
片方をもう片方のduplicateとして扱わせる正本は、このブログの意図と異なります。
修正後は少数URLだけを再テストし、必要なら一度リクエストします。
リクエストの反復やsitemapの再送信を、content品質、内部link、取得障害の修正代わりには使えません。
選択中のプロパティ、期間、search type、ページ filterを確認します。
URL-プレフィックスプロパティでは対象外のprotocolやsubdomainのデータは入りません。
公開直後の空tableだけから障害とは断定しません。
まずURL検査とsitemap レポートで取得状態を確認し、その後も固定値ではなく最新期間のデータを観測します。
手動検索で見えた一回の順位をPerformanceの平均掲載順位へ置き換えることも避けます。
確認済みだったプロパティが未確認になった
Googleはverification トークンの存在と有効性を定期的に確認します。
layout変更、設定toggleの無効化、保存トークンの削除、DNS recordの削除がなかったかを調べます。
所有者が複数いる場合は、別の所有者のトークンを上書きせず、必要に応じて複数の確認方法を維持します。
運用チェックリスト
- Search Consoleで
https://kirinnoblog.work/ のURL-プレフィックスプロパティを作ります。 - HTMLタグから
contentの値だけを管理画面へ入力し、「Search」を有効にして保存します。 - 本番 homepageの
<head>でmetaタグを確認してから所有権を検証します。 - 確認後もmetaタグを残します。
- 記事公開後に
/sitemap.xml を開き、日英の公開URLを確認します。 - Search Consoleのサイトマップへ
https://kirinnoblog.work/sitemap.xml を送信します。 - 日本語URLと英語URLを別々にURL検査し、必要な少数URLだけindexingをリクエストします。
- sitemap送信とリクエスト indexingを索引保証として扱いません。
- Performanceでは期間とdimensionを残し、変動する件数や順位を記事本文へ固定しません。
- 検索後のサイト内行動はGA4設定記事で別に確認します。
公式参考資料
