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