サーチコンソールのプロパティの分け方｜複数サイトの登録設計

サーチコンソールに複数のサイトを登録するときの分け方は、ほぼ一択です。ドメインごとに「ドメインプロパティ」を1つ作って全体を束ね、そのうえで分けて見たい場所だけ「URLプレフィックスプロパティ」を足します。逆にしてはいけません。

この記事は、自社サイトのほかにブランドサイトやオウンドメディアを持っていて、サーチコンソールの登録をどう分ければいいか決めきれていない方に向けています。読み終わる頃には、自社の構成に合った登録パターンと、DNSでの所有権確認の手順、つまずいたときの戻し方まで決められる状態を目指します。

なお、この記事はプロパティの設計と登録に絞ります。登録後に毎日どの画面を見るかはサーチコンソールの使い方｜初心者が最初に見る4つの画面で解説しているので、登録が済んでいる方はそちらから読んでください。

Contents / 目次

1. 複数サイトの登録は、ドメインプロパティが起点
2. サイト構成別の、プロパティ設計パターン
3. サーチコンソール登録の、5ステップ
4. 登録設計を整えたあとに、見えてくるもの
5. 登録でつまずく、5つの分岐点
6. ドメインプロパティの、届かないところ
7. サーチコンソールの登録に関する、よくある質問
8. まず、今日の5分でできること

複数サイトの登録は、ドメインプロパティが起点

結論から言うと、サーチコンソールの登録は「1ドメイン＝1ドメインプロパティ」で始めます。ドメインプロパティとは、example.com という所有ドメインの配下をまるごと1つのプロパティとして扱う登録方式のことです。

ドメインプロパティには、次の3つが1つのプロパティに集約されます。

• www ありとなし
• http と https
• blog.example.com のようなサブドメイン

数字が散らばらないので、サイト全体の状態を1画面で把握できます。集約される範囲の正式な定義は変更されることがあるので、登録前にサーチコンソールの登録画面とSearch Console ヘルプで最新の記載を確認してください。

一方のURLプレフィックスプロパティは、指定したURLの先頭が一致するページだけを対象にする登録方式です。どこまでが対象範囲になるかは、登録画面とSearch Console ヘルプにプロパティの種類ごとの説明があるので、登録前に必ず目を通してください。

ここを取り違えると、あとから過去データを取り戻せません。サーチコンソールは登録した日以降のデータしか蓄積しないためです。登録が3か月遅れれば、その3か月分は永久に見られません。

2つのプロパティの、違いが出る場所

違いを一覧にすると次のとおりです。判断に効くのは「所有権の確認方法」と「サブドメインを含むかどうか」の2行です。使える確認方法は変わることがあり、最新の一覧は実際の登録画面にその場で表示されるので、そちらでも確認してください。

比較する点	ドメインプロパティ	URLプレフィックスプロパティ
登録するときの入力	example.com（プロトコルなし）	https://example.com/blog/ のようにURLで指定
所有権の確認方法	登録画面に表示される方法から選ぶ（DNSレコードが基本）	登録画面に表示される方法から選ぶ（DNSレコード以外も選べる）
www ありなし	両方まとめて含む	登録したほうだけ
http と https	両方まとめて含む	登録したほうだけ
サブドメイン	すべて含む	含まない（別途登録が必要）
向いている場面	サイト全体の把握、複数サイトの一元管理	特定ディレクトリの分析、DNSを触れない場合の代替

判断の分かれ目。DNSレコードを自社で追加できるならドメインプロパティ、触れないならURLプレフィックスです。技術的な優劣ではなく、DNSを誰が握っているかという社内事情で決まります。

GA4のプロパティとは、別物の考え方

ここでよく混乱が起きます。GA4（Googleアナリティクス4）にも「プロパティ」という言葉が出てくるからです。名前は同じでも、分ける単位の考え方はまったく違います。

GA4のプロパティは、計測データをためる入れ物です。1つのプロパティの中に「データストリーム」を複数作って、ウェブサイトとアプリを1か所にまとめられます。事業やサービス単位でまとめるのが基本です。

サーチコンソールのプロパティは、所有権を確認したURLの範囲そのものです。範囲の外は入りませんし、別ドメインを1つのプロパティにまとめることもできません。GA4は「まとめる」発想、サーチコンソールは「所有範囲を宣言する」発想と覚えておくと、設計を間違えにくくなります。

数字が合わない理由も含めた両者の使い分けは、サーチコンソールとGA4の違い｜数値が合わない理由と使い分けで詳しく整理しています。

この章の結論。ドメインプロパティを軸に据えると決めた時点で、あとは「DNSを触れるか」と「どこを分けて見たいか」の2点だけを考えればよくなります。

サイト構成別の、プロパティ設計パターン

自社の構成に当てはめて設計するなら、次の表から選ぶのが早道です。どのパターンでも共通しているのは、ドメインプロパティを必ず1つ作るという点です。

サイトの構成	登録するプロパティ	そう分ける理由
コーポレートサイト1つだけ	ドメインプロパティ1つ	分ける必要がない。将来サブドメインを足しても自動で含まれる
本体サイト＋サブディレクトリのブログ（example.com/blog/）	ドメインプロパティ1つ＋ブログのURLプレフィックス1つ	ブログの成果だけを切り出して報告したい場面が必ず来るため
本体サイト＋サブドメインのメディア（blog.example.com）	ドメインプロパティ1つ＋サブドメインのURLプレフィックス1つ	ドメインプロパティに含まれるが、単体で数字を追うには別枠が要る
本体サイト＋別ドメインのブランドサイト	ドメインプロパティを2つ	ドメインが違えば所有権も別。1つにまとめる方法は存在しない
多言語サイト（/ja/ と /en/）	ドメインプロパティ1つ＋言語ごとのURLプレフィックス	言語ごとに検索クエリの傾向がまったく違い、混ざると読めない
ECサイトと採用サイトが別サブドメイン	ドメインプロパティ1つ＋用途別にURLプレフィックス	見る担当者と目的が違うため、権限も分けて渡せる

サブドメインにするかサブディレクトリにするかで迷っている段階なら、登録設計より先にそちらを決めてください。判断材料はサブディレクトリとサブドメインの違いと選び方の判断ポイントにまとめています。

分けすぎない、という基準

URLプレフィックスは無料でいくつでも作れるので、つい細かく分けたくなります。ただし分けた数だけ確認の手間が増えます。追加してよいかどうかは、次の3つのどれかに当てはまるときだけと決めておくと、増えすぎません。

• 報告単位が違う：そのセクションだけを取り出して、社内や取引先に定期的に報告している
• 担当者が違う：そのセクションを別の担当者や制作会社が更新していて、権限を絞って渡したい
• 検索の目的が違う：採用サイトと商品サイトのように、来訪者の検索意図がまるごと違う

逆に「なんとなく細かく見たいから」で分けるのはおすすめしません。プロパティを増やさずに済む用事なら、まずは検索パフォーマンスの画面で絞り込みを試してください。使えるフィルタの種類は、実際の検索パフォーマンス画面で確認できます。

この章の結論。プロパティを追加する理由が「報告」「担当者」「検索意図」のどれにも当たらないなら、まず絞り込みで足りないかを確かめてください。

サーチコンソール登録の、5ステップ

ここからは実際の登録手順です。ドメインプロパティの追加を軸に、DNSでの所有権確認から権限の割り当てまでを5つのステップに分けます。DNSの反映待ちがあるので、当日中に終わらせたいなら時間に余裕がある日に着手してください。

なお、サーチコンソールの画面上のボタン名やメニューの位置は更新されることがあります。押す場所の最新の名称は、Search Console ヘルプで確認しながら進めてください。ここでは「何を・どの順で・どんな値を入れるか」を具体的に書きます。

ステップ1　登録前に決める、3つの前提

画面を開く前に決めておくことが3つあります。ここを飛ばすと、あとで作り直しになります。

1. どのGoogleアカウントで所有者になるか。個人のGmailではなく、退職や担当替えで消えない会社のアカウント（Google Workspaceの共有アカウントなど）にします。これが一番あとから直しにくい部分です。
2. DNSを誰が管理しているか。ログイン情報の在り処を先に確認します。預け先として多いのは、ドメイン登録業者の管理画面、レンタルサーバーの管理画面、制作会社の預かりの3つです。分からない場合は、ドメインの契約書か請求メールをたどるのが早いです。
3. ドメインプロパティ以外に、どのURLプレフィックスを作るか。前章の3つの基準に照らして、最初から作るものを紙に書き出しておきます。あとから足すと、その期間のデータが欠けます。

ステップ2　ドメインプロパティの追加とDNS確認

サーチコンソールでプロパティを追加するとき、ドメインプロパティ側の入力欄には https:// や www. を付けず、example.com の形だけを入れます。入力形式は登録画面にも表示されるので、迷ったらその案内に従ってください。

入力すると、DNSに追加するTXTレコードの値が表示されます。この値をコピーして、ドメインを管理している画面（お名前.com、ムームードメイン、エックスサーバー、さくらのレンタルサーバなど、契約先のDNS設定画面）に貼り付けます。設定する値は次のとおりです。

項目	入れる値	補足
レコードの種類	TXT	A や CNAME と間違えない
ホスト名（名前）	空欄、または @	サービスによっては example.com とドメイン名そのものを入れる形式
値（コンテンツ）	サーチコンソールの画面に表示された文字列をそのまま	前後に余計な空白や引用符を入れない
TTL	初期値のまま	触る必要はない

既存のTXTレコードを書き換えないでください。メール認証に使うSPFレコード（v=spf1 で始まるもの）などが同じTXTに入っていることがあります。上書きするとメールが届かなくなります。必ず「新しいレコードを追加」の操作で足してください。

保存したら、サーチコンソールの画面に戻って確認を実行します。すぐに通らないことのほうが多いので、通らなくても慌てなくて大丈夫です。DNSの変更が各地のDNSサーバーに行き渡るまでに時間がかかるためで、待ち時間は設定したTTLやDNSサービスによって変わります。反映の目安は、契約しているDNSサービスの案内で確認してください。

サイトの数が増えて所有権確認を毎回手作業でやるのが負担になってきた場合は、Googleが所有権確認の仕組みをAPIとして公開しています。開発者向けの内容ですが、Google Site Verification API のスタートガイドに概要が載っています。

ステップ3　反映の確認と、通らないときの戻し方

確認が通らないときは、サーチコンソールの画面を何度も押す前に、DNSに値が乗っているかを自分で見てください。Macのターミナルなら次のコマンドで確認できます。

# Mac／Linux のターミナルで実行する
# ［example.com］を自社のドメインに置き換える
dig TXT example.com +short

# 出力の中に、サーチコンソールの画面に表示された文字列と同じ行があればDNSには反映済み。
# 何も出ない、または古い値しか出ない場合は、まだ反映されていないか、
# 保存先のDNSサーバーが実際に使われているものと違う可能性があります。

Windowsのコマンドプロンプトを使う場合は次のとおりです。

REM Windows のコマンドプロンプトで実行する
REM ［example.com］を自社のドメインに置き換える
nslookup -type=TXT example.com

値が出ているのにサーチコンソール側で通らない場合、原因はだいたい次の3つに絞られます。

• 貼り付けミス：値の前後に空白や改行、引用符が混ざっている。一度削除して貼り直す
• ネームサーバーの不一致：ドメイン業者の管理画面でTXTを足したが、実際のネームサーバーはレンタルサーバー側を向いている。ネームサーバーの向き先を確認し、実際に使われているほうに足す
• 反映待ち：単純に時間が足りていない。上のコマンドで値が出るのを待ってから再実行する

値が出ていないなら、まだDNS側の問題です。サーチコンソールの画面を押し続けても状況は変わりません。

ステップ4　URLプレフィックスの追加判断

ドメインプロパティが通ったら、ステップ1で書き出したURLプレフィックスを追加します。入力するURLは、実際にブラウザのアドレスバーに出る形と1文字ずつ合わせてください。

とくに末尾のスラッシュと、www の有無です。https://example.com/blog/ で登録したプロパティは、https://www.example.com/blog/ のページを含みません。どちらが実際に表示されるURLなのかは、自社サイトをブラウザで開いてアドレスバーを見れば分かります。

www ありなしや http と https がサイト内で混在している疑いがあるなら、プロパティを足す前にそちらの統一を済ませてください。手順はURL正規化の統一手順｜wwwありなしとhttpsをまとめて集約するにまとめています。

URLプレフィックスの所有権確認は、DNS以外の方法も使えます。選べる方法は登録画面に表示されるので、すでにサイトに入れているツールで済むものがあればそれが早いです。ただし、確認に使ったタグを消すと所有権も外れる点は、あとの失敗例で詳しく触れます。

ステップ5　サイトマップ送信と、権限の割り当て

プロパティが揃ったら、それぞれにサイトマップを送信します。WordPressなら、多くの場合は次のようなURLで公開されています。

https://example.com/sitemap.xml
https://example.com/wp-sitemap.xml       ← WordPress 本体が生成する場合
https://example.com/sitemap_index.xml    ← 一部のSEOプラグインが生成する場合

# どれが有効かは、ブラウザで直接開いて確認する。
# 404 が出るURLを送信しても意味がありません。

サイトマップの送信先は、そのサイトマップに載っているURLを含むプロパティを選んでください。範囲を絞ったプロパティには、その範囲のサイトマップを送るか、そもそもサイトマップ送信はドメインプロパティ側に集約するのが確実です。サイトマップの置き場所と対象範囲のルールは、Googleのサイトマップの作成と送信で確認できます。

最後に権限を割り当てます。権限の種類と、それぞれでできることは、サーチコンソールの設定画面とSearch Console ヘルプで確認してください。制作会社や外部の運用担当に渡すときは、まず権限の狭いものから始めて、足りなければ広げるのが安全です。オーナー権限は、渡した相手が他のユーザーを追加・削除できてしまうので、社内の管理者だけに留めます。

渡し方と、担当が変わったときの外し方はサーチコンソールの権限付与｜制作会社への渡し方と退職時の削除で手順化しています。

登録直後にやる、確認チェックリスト

登録した当日と、2週間後に見る項目を分けておくと、抜けが出ません。当日にデータが0件でも異常ではないからです。

登録した当日に確認すること

• プロパティ一覧：作ったプロパティが全部並んでいるか。入力ミスで意図しないURLのプロパティができていないか
• 所有権の状態：すべて「確認済み」になっているか
• サイトマップ：送信したサイトマップのステータスが「取得できませんでした」になっていないか
• オーナーの棚卸し：ユーザー一覧に、身に覚えのないアカウントが残っていないか（サイトを引き継いだ場合に前任者や旧制作会社が残っていることがあります）
• URL検査：トップページを1件だけ検査して、インデックス登録の状態を見ておく

2週間後に確認すること

• 検索パフォーマンス：クリック数と表示回数が計上され始めているか
• ページのインデックス登録：「未登録」のページ数が公開ページ数に対して不自然に多くないか
• プロパティ間の整合：ドメインプロパティの数字が、各URLプレフィックスの合計以上になっているか（下回っていたら、どこかの登録範囲が間違っています）

「未登録」の中身の読み方と直し方はサーチコンソールで除外を確認する手順｜未登録の直し方で解説しています。

この章の結論。登録作業そのものより、DNSの向き先と権限の持ち主を先に押さえるほうが重要です。この2つさえ自社側にあれば、あとの設定は何度でもやり直せます。

登録設計を整えたあとに、見えてくるもの

プロパティ設計を整えて得られるものは、順位が上がることではありません。判断に使えるデータが、あとから取り戻せない形で貯まり始めることです。ここが効果の本体です。

サーチコンソールの検索パフォーマンスのデータには保持期間が決まっており、それより前は見られません。最新の保持期間はSearch Console ヘルプで確認してください。いずれにせよ、登録していなかった期間のデータは遡って発生しません。今日登録すれば、来年の同じ月に「前年同月との比較」ができます。今日登録しなければ、来年その比較はできません。

設計が整っているサイトに共通しているのは、次のような状態です。

• 数字を足し算しなくていい：ドメインプロパティを開けば全体が出る。www 有無で4つのプロパティを行き来して電卓を叩く作業が消える
• 異常にすぐ気づく：全体の表示回数が落ちたとき、どのセクションが落ちたのかをフィルタで数分以内に絞り込める
• 報告の準備が軽くなる：全体の数字が1つのプロパティに集まっているので、レポートを作るときに見に行く先が1か所で済む。プロパティが散っていると、そのぶん確認と集計の手数が増える

サイト数が増えたときの、手間の増え方

サイトごとに別々のGoogleアカウントで管理していると、数字を見るたびにアカウントを切り替える手間が発生します。この切り替えは、管理サイトが増えるほど比例して増えます。1アカウントに集約してドメインプロパティで束ねると、切り替えそのものがなくなります。

どれくらいの手間になるかは、確認の頻度や見る項目によって大きく変わります。自社で判断するなら、1サイトの数字を確認するのに実際に何分かかっているかを一度計測して、サイト数を掛けてみてください。その合計が許容できない大きさになった時点が、設計を整えるタイミングです。

流入の経路では、プロパティを分けられない

サーチコンソールのプロパティは、所有権を確認したURLの範囲で区切るものです。どの検索経由で来たかという切り口では区切れません。

つまり、AI経由の流入を分けて見たいという理由でプロパティを分けても、目的は達成できません。プロパティを分ける軸は、流入の経路ではなく、サイトの管理単位です。ここを勘違いすると、意味のないプロパティが増えるだけになります。

どの検索機能の表示・クリックがレポートに計上されるかは変更されることがあります。最新の扱いはSearch Console ヘルプで確認してください。表示回数は増えているのにクリック数が伸びない、という見え方をしたときも、プロパティを増やして原因を切り分けようとするのではなく、クエリ単位でCTRを見る方向に手を動かしてください。

この章の結論。登録設計の効果は「今すぐ順位が上がる」ことではなく、「1年後に比較できるデータが手元にある」ことです。だから、迷っている時間がそのまま損失になります。

登録でつまずく、5つの分岐点

ここからは、実際に現場でよく見る失敗です。どれも設定を直せば回復しますが、失われたデータは戻らないので、早めに気づけるかどうかがすべてです。

www有無とhttpsで、4分割された数字

いちばん多いのがこれです。URLプレフィックスで登録するときに、http://example.com/、http://www.example.com/、https://example.com/、https://www.example.com/ の4つを全部作ってしまうパターンです。

こうなると、実際に表示されているURLのプロパティにしかデータが入りません。残り3つは空のまま並び続けます。担当者は毎回「どれが本物か」を思い出しながら開くことになり、引き継ぎのたびに間違ったプロパティを見る人が出ます。

防ぎ方。ドメインプロパティを1つ作って、そちらを見る癖をつけます。空の3つは削除して構いません。ただし、DNSに入れたTXTレコードは触らないでください。所有権の確認に使っているレコードなので、消す前に必ず、どの記述が確認に使われていて、消したときに何が起きるかを確認してください。

制作会社のアカウントだけの、所有権

サイトを作ってもらったときに、制作会社が自社のGoogleアカウントで所有権確認をして、そのまま運用しているケースです。閲覧権限はもらっているので、日常的には困りません。

問題が出るのは契約が終わるときです。オーナーが相手側にしかないと、こちらから権限を付け替えることも、相手のアクセスを外すこともできません。DNSのTXTレコードが相手の値だった場合、それを消すと所有権の確認にも影響します。

防ぎ方。自社のGoogleアカウントで、自社が発行したTXTレコードを使って、独立して所有権確認をしておきます。複数のオーナーがいる場合の扱いは、サーチコンソールの設定画面とSearch Console ヘルプで確認してください。契約終了時は、まず自社の確認が済んでいることを画面で確かめてから、相手のユーザー権限を外し、相手が入れたTXTレコードを削除します。この順番を逆にしないでください。

リニューアルで消える、確認用タグ

URLプレフィックスプロパティを、サイト側に置いた記述（HTMLファイルやタグなど）で所有権確認していた場合に起きます。サイトをリニューアルしてテーマを入れ替えたり、タグ管理を整理したりすると、確認に使っていた記述が消えます。

消えると所有権の確認が外れ、そのプロパティのデータが見られなくなります。しかも、レポートを作ろうとした月末になって初めて気づくことがほとんどです。

防ぎ方。リニューアルの作業リストに「所有権確認の方法と、その記述の場所」を1行入れておきます。可能なら、URLプレフィックスプロパティの確認方法もDNSに寄せておくと、サイト側を触っても外れません。リニューアル全体の引き継ぎ手順はサイトリニューアルのSEO引き継ぎ手順｜301と公開後72時間の確認にまとめています。

どこにも出てこない、サブドメインのデータ

本体サイトを https://www.example.com/ のURLプレフィックスだけで登録していて、オウンドメディアを blog.example.com のサブドメインで運営している場合に起きます。ブログのデータは、どのプロパティにも表示されません。

「メディアを立ち上げたのに数字が出ない」と相談を受けて画面を見ると、原因がこれだった、というのは珍しくありません。ブログ側は順調に伸びていて、ただ計測されていないだけ、という状況です。

防ぎ方。ドメインプロパティを1つ作れば、サブドメインは自動的に全部入ります。そのうえで、メディア単体の数字を追いたいならサブドメインのURLプレフィックスも足します。新しいサブドメインを立ち上げるたびに登録が必要になるURLプレフィックスと違い、ドメインプロパティは足し忘れが構造的に起きません。

範囲外のプロパティに送った、サイトマップ

ブログ用に https://example.com/blog/ のURLプレフィックスプロパティを作り、そこにサイト全体の sitemap.xml を送ってしまうケースです。プロパティの範囲外のURLが大半を占めるため、サイトマップのレポートに出る数字が想定と食い違います。

この状態で「インデックスされていないページが多い」と誤診し、robots.txt や noindex を触りに行くと、余計な事故が起きます。触るべきでない設定を触ってしまうためです。

防ぎ方。サイトマップの送信先はドメインプロパティに一本化します。URLプレフィックスのプロパティは、あくまで「見るための窓」と割り切って、送信系の操作はしないと運用ルールに書いてしまうのが確実です。

この章の結論。5つの失敗は形が違うだけで、原因はどれも「所有権の持ち主」と「プロパティの範囲」の取り違えです。この2つを紙に書き出せる状態なら、まず事故は起きません。

ドメインプロパティの、届かないところ

ここまでドメインプロパティを勧めてきましたが、万能ではありません。実際に運用すると出てくる不便と、その妥協点を率直に書きます。ここを知らずに導入すると「思ったのと違う」となります。

DNSを触れない会社は、意外と多い

ドメインプロパティの所有権確認はDNSレコードで行います。ここが最大の制約です。私たちがご相談を受ける中小企業でも、DNSにすぐ手が届かない状況はよくあります。よくあるのは次のような状況です。

• 管理画面のIDが分からない：何年も前にドメインを取ってもらったきり、ログイン情報を引き継いでいない
• 社外・部門外が握っている：親会社の情報システム部門が管理していて、変更の申請に時間がかかる
• 名義が他社のまま：契約が終わった制作会社の名義でドメインが登録されている

現実的な妥協点。DNSにすぐ手が届かないなら、まずURLプレフィックスプロパティで登録して計測を始めてください。データが貯まらない期間を作るほうが損です。そのうえで、ドメインの管理権限を自社に戻す作業を、別の課題として並行して進めます。ドメインプロパティはあとから追加でき、追加してもURLプレフィックス側のプロパティはそのまま残ります。

全体が見える代わりに、細部が埋もれる

ドメインプロパティは全部が混ざります。これは長所であると同時に短所です。

たとえば採用サイトの検索クエリと商品サイトの検索クエリが同じ一覧に並びます。規模が大きいサイトでは、見たいセクションのクエリが上位に埋もれて、一覧の手前のほうに出てこないことがあります。

毎回フィルタをかければ見られますが、その操作を毎週やるのは地味に負担です。だからこそ、報告単位や担当者が分かれているセクションには、あえてURLプレフィックスを作る価値があります。「ドメインプロパティだけで済ませる」という原理主義は、かえって手間を増やします。

プロパティを増やすと、権限管理が増える

見落とされがちなコストがこれです。プロパティを1つ増やすと、そのプロパティのユーザー一覧も1つ増えます。5プロパティあれば、退職者が出たときに確認する場所が5か所になります。

プロパティ設計の話は「どう分けるか」に集中しがちですが、実務では分けた数だけ棚卸しの手間が増えることを勘定に入れてください。半年に一度、次のような台帳を更新するだけで、事故はかなり減ります。

【プロパティ台帳のテンプレート】社内共有のスプレッドシートなどに置く

プロパティ名 | 種類 | 所有権の確認方法 | オーナー | 閲覧を渡している相手 | 最終棚卸し日
------------|------|----------------|---------|-------------------|------------
example.com | ドメイン | DNS TXT（自社発行） | 会社アカウント | 制作会社A（制限付き） | 2026-08-29
https://example.com/blog/ | URLプレフィックス | サイト側のタグ | 会社アカウント | 広報部B（フル） | 2026-08-29

※「所有権の確認方法」の列が、この台帳の心臓部です。
※ ここが分からなくなると、リニューアル時に何を消してはいけないか判断できなくなります。

AIに任せられるのは、確認と読み解きまで

DNSレコードの追加や所有権の確認は、AIには代われません。管理画面のログイン情報を扱う作業だからです。

AIに渡せるのは、画面から書き出したデータのほうです。たとえば検索パフォーマンスをCSVで書き出し、上の台帳と一緒に渡して「プロパティ間で数字が食い違っている箇所を挙げてください」「表示回数の多い順に、クリック率が低いクエリを並べてください」と頼む形なら、確認の下ごしらえとして使えます。渡すときは、対象期間と、どのプロパティのデータかを本文に書き添えてください。

出てきた結果は、必ず元の画面と突き合わせて確かめます。挙げられたクエリやページを1件ずつ検索パフォーマンスで絞り込み、同じ数字が出るかを見るだけで十分です。

そのうえで、AIが出した仮説をそのまま施策にしないでください。判断に必要な社内の事情（そのページを今は伸ばさない、といった前提）はデータに出てこないためです。

この章の結論。ドメインプロパティは「全体を落とさない」ための仕組みであって、「細かく見る」ための仕組みではありません。細かく見たい場所には、手間を承知でプロパティを足してください。

サーチコンソールの登録に関する、よくある質問

まず、今日の5分でできること

この記事を読み終えたら、サーチコンソールを開いてプロパティの一覧を見てください。その中にドメインプロパティ（URLではなく example.com の形で表示されているもの）が1つでもあるかどうか。これを確認するだけで、自社の設計が整っているかどうかが分かります。無ければ、DNSの管理画面がどこにあるかを調べるところから始めます。

登録が済んで、次は何の画面をどう読むかという段階に進む方は、サーチコンソールの使い方｜初心者が最初に見る4つの画面へ進んでください。

プロパティの構成が入り組んでいて、どこから触ればいいか判断しづらい場合や、ドメインの管理権限が社外にあって動けない場合は、状況を整理するところからお手伝いできます。「何が分からないのかも整理できていない」という段階で大丈夫なので、気軽に相談してみてください。現状のプロパティ一覧を見せていただければ、どこから手を付けるべきかはその場でお伝えできます。

登録したあと、どの数字を見て何から直すかを決めるところは、検索の数字を毎月見る定額制マーケティング支援でお引き受けしています。