「来なかった人」を見るために
アクセス解析は「来た人」しか教えてくれません。
検索結果に出たのに押されなかった、そもそも検索結果に出ていない——こうした「来なかった人」の情報は、GA4には一切残りません。それを見るための道具がGoogle Search Consoleです。今回はその導入と、所有権の確認方法を選ぶまでの判断を記録します。
Search ConsoleとGA4の役割の違い、ドメインプロパティとURLプレフィックスの選び分け、5つある所有権確認方法のうちどれを選んだか。そして、確認コードをコードに直接書かなかった理由。
GA4では見えないもの
まず、2つの道具が何を見ているのかを整理します。境界を勘違いすると、片方に無いものを延々と探すことになります。
| Googleアナリティクス | Search Console | |
|---|---|---|
| 見る対象 | サイトに来た後の行動 | サイトに来る前の状況 |
| データの出どころ | サイトに埋めたタグ | Googleの検索システム |
| 分かること | 閲覧ページ、滞在、遷移、流入元 | 検索語、表示回数、順位、クリック率 |
| 分からないこと | どんな言葉で探されたか | サイト内で何をしたか |
この違いがはっきり出るのが検索語です。GA4は「Google検索から来た」ことは分かりますが、何と入力して来たのかは教えてくれません。プライバシー保護のため、検索エンジン側が渡していないからです。
Search Consoleは検索エンジン側の記録なので、そこが見えます。さらにクリックされなかった表示も数えられています。これがGA4には原理的に存在しない情報です。
ある記事が検索結果に100回出て、クリックが2回だとします。GA4に残るのは「2」だけです。Search Consoleを見ると「100回出ている」と分かるので、内容ではなくタイトルの問題だと切り分けられます。逆に表示が0なら、書き方以前に見つけられていません。直す場所がまったく変わります。
プロパティの種類を選ぶ
登録の最初に、2種類のどちらかを選ばされます。
| ドメイン | URL プレフィックス | |
|---|---|---|
| 対象 | すべてのサブドメイン、http/https両方 | 入力したアドレスの配下だけ |
| 確認方法 | DNSの設定のみ | 5種類から選べる |
| 向いている場面 | サブドメインをまとめて見たい | 特定の1サイトだけ見たい |
今回はURLプレフィックスを選び、https://www.kisaku.site/ を登録しました。
理由は2つあります。ひとつは、このサイトには cms.kisaku.site/wp/ というWordPress用のサブドメインがあり、そこは検索結果に出したくないからです。ドメインプロパティにすると、見せたくない側の数字まで一緒に入ってきます。
もうひとつは、確認方法の選択肢です。ドメインプロパティはDNSレコードの追加が必須で、ドメイン管理会社の画面での作業になります。設定を間違えるとサイト全体が見えなくなる場所なので、必要のない作業は入れたくありませんでした。
URLプレフィックスでは、https://kisaku.site/ と https://www.kisaku.site/ は別のプロパティです。転送を設定していても自動では統合されません。登録するのは転送先——つまり実際に表示されるほうです。ここを間違えると、いつまでもデータが0のままになります。
所有権の確認方法
URLを入力すると、そのサイトが自分のものだと証明するよう求められます。方法は5つ提示されました。
| 方法 | やること | 今回の判断 |
|---|---|---|
| HTMLファイル | 指定のファイルをサイト直下に置く | × |
| HTMLタグ | metaタグを head に入れる |
採用 |
| Googleアナリティクス | GA4のタグが入っていれば通る | × |
| Googleタグマネージャー | GTMのタグが入っていれば通る | × |
| DNSレコード | ドメイン設定にTXTを追加 | × |
HTMLファイル方式を外したのは、Next.jsで public に置くこと自体はできるものの、この1ファイルが何のためにあるのか、後から見て分からなくなるからです。ファイル名は意味を持たない英数字の羅列で、消しても当面は気づきません。そして消すと所有権が外れます。
GA4やGTMを使う方式も外しました。一見いちばん楽ですが、計測を止めた瞬間に所有権の確認も外れます。将来「GTMをやめて直接タグを貼ろう」と判断したとき、Search Consoleまで巻き込まれます。関係のないもの同士を依存させない、という判断です。
DNSは前述のとおり、影響範囲が大きすぎるので今回は使いませんでした。
残ったHTMLタグ方式を選んでいます。head に1行入るだけで、これはNext.jsが正式に対応している範囲です。
確認コードを直接書かなかった理由
提示されるのはこういう1行です。
<meta name="google-site-verification" content="（英数字の文字列）" />これを layout.tsx にそのまま書いても動きます。しかし、環境変数から読む形にしました。
export const metadata: Metadata = {
metadataBase: new URL("https://www.kisaku.site"),
// ...
verification: {
google: process.env.NEXT_PUBLIC_GOOGLE_SITE_VERIFICATION,
},
};Next.jsには verification という専用の項目が用意されていて、値を渡すと head にmetaタグを出力してくれます。手書きでタグを差し込む必要はありません。
環境変数にした理由は、値が未設定なら何も出力されないからです。コードを先にデプロイしておいて、確認コードを取得してから設定を足せます。実際、今回はコードのほうが先にできていました。
もうひとつ、この値がサイトの機能に関係ないものだという点も理由です。動作には一切影響しないので、コードの中に混ざっていると「何のための文字列か」を毎回思い出すことになります。設定として外に置けば、設定であることが見た目で分かります。
NEXT_PUBLIC_ が付いた環境変数は、ビルド時にコードへ埋め込まれ、誰でも見られる状態になります。この確認コードはもともとHTMLに出力するためのものなので、それで問題ありません。逆に言えば、秘密にすべき値をこの接頭辞で扱ってはいけません。接頭辞が「公開してよい」という宣言になっています。
登録しただけでは確認されない
metaタグがまだ本番に出ていないので、この時点でのプロパティは未確認の状態です。
手順としてはこうなります。
1. Search Consoleでプロパティを追加し、確認コードを控える
2. Vercelの環境変数に確認コードを登録する
3. 再デプロイする（環境変数の追加だけでは反映されない）
4. Search Consoleに戻って「確認」を押すNEXT_PUBLIC_ の値はビルド時にコードへ埋め込まれます。管理画面で追加しても、その後にビルドし直さなければ、出力されるHTMLは前のままです。「設定したのに反映されない」の大半はこれです。
確認が通ったあとは、サイトマップの送信が次の作業になります。sitemap.xml をまだ用意していないので、これは別のタスクとして残しました。
今回の学び
まず、2つの道具は「来た後」と「来る前」で分かれているということ。GA4だけを見ていると、記事が読まれない理由を内容の問題だと考えがちです。実際には検索結果に出ていないだけかもしれません。直す場所を間違えないために、両方が要ります。
次に、楽な確認方法ほど、他のものに依存していること。GA4やGTMを使う方式は一瞬で終わりますが、計測をやめた瞬間に所有権も外れます。関係のないもの同士を結びつけない——遠回りに見えても、独立させておくほうが後で自由が利きます。
そして、設定はコードの外に置くと、設定に見えること。確認コードを直接書いても動きますが、コードの中に混ざると意味を思い出す手間が毎回かかります。環境変数にしておけば、それが「あとで変わりうる値」だと見た目で分かります。