サーチコンソールの権限付与と管理方法で退職・代理店トラブルを防ぐ

サーチコンソールの権限付与を「メールアドレスを入力してクリックするだけ」と捉えている組織ほど、退職や代理店変更のタイミングで静かに損失を出しています。所有権を握るアカウントが個人Gmailのまま放置され、前任者がいなくなった瞬間、Search Consoleの画面に入れず、SEOの診断やインデックス状況の確認すらできない。代理店にオーナー権限を丸投げした結果、乗り換え時にデータへのアクセスを人質のように使われる。この種のトラブルは、設定ミスというより権限設計の不在から必然的に起きています。

多くの解説記事は「Google Search Consoleのユーザー追加方法」「所有者とユーザーの種類」といった基本情報で終わります。確かに、プロパティの[ユーザーと権限]画面を開き、メールアドレスを入力し、権限レベルを選択して追加・削除するやり方はすぐ分かるでしょう。しかし、
どのアカウントに所有権を持たせるべきか、代理店や外部コンサルにはどのレベルの権限を渡すべきか、DNSやHTMLでの所有権確認を使ってどう復旧するか、といった実務の意思決定ロジックまでは踏み込んでいません。

結果として、次のような「見えない損失」が積み上がります。

• 所有者が不在で、新しいユーザーを追加できず、SEO対策やレポート作成が数週間止まる
• テスト用アドレスで所有確認したせいで、数年後に誰もログインできなくなり、プロパティごと作り直し
• GA4やタグマネージャーとオーナーがバラバラで、サイト移転時にSearch Consoleだけ設定漏れが起こる

この記事は、こうした現場トラブルを前提に、サーチコンソールの権限付与を「クリック操作」ではなく「組織運営とリスク管理の設計」として扱います。Google公式ヘルプの仕様を起点にしつつ、所有者・委任所有者・フルユーザー・制限付きユーザーをどう分けるか、代理店との契約でどこまで渡すか、退職・外注終了のたびに何を棚卸しするかまで、具体的なフローとチェックリストに落とし込みます。

この記事を読み終える頃には、次の状態を作れます。

• 退職や代理店変更があっても、Search Consoleのデータと所有権を常に自社側でコントロールできる
• 誰がどのプロパティにどの権限を持っているか、スプレッドシートで一目で確認できる
• コンテンツ担当やCS、経営層が、必要な範囲で安全にSearch Consoleのデータを閲覧できる

このロードマップを俯瞰すると、前半と後半で得られる「武器」と「解決する課題」は次の通りです。

セクション	読者が手にする具体的な武器(実利)	解決される本質的な課題
構成の前半(全体像〜トラブル事例〜権限戦略〜早見表〜具体手順)	所有者・ユーザー・プロパティ構造の整理、権限付与/削除の正しい手順、DNSやHTMLを使った復旧パターン	「今どのアカウントが何をできるのか分からない」「権限トラブル時にどう動けばいいか分からない」状態の解消
構成の後半(古い常識の見直し〜棚卸しフロー〜チーム運営〜Q&A)	権限棚卸しの標準フローとチェックリスト、代理店との権限条項の考え方、社内での情報共有モデル	「人の異動や代理店変更のたびに混乱する」「Search Consoleがブラックボックス化する」体制上の問題の解消

サーチコンソール 権限付与をここまで分解しておけば、「とりあえず代理店に所有権を渡す」「前任者の個人アカウントに依存する」といった高リスクな運用から抜け出し、Search Consoleを本来の目的であるSEOとWebマーケティングの土台として、安心して使い続けられるようになります。

サーチコンソールの権限付与は「クリックして終わり」ではない：まず押さえるべき全体像

Search Consoleの権限付与は、ボタンを押してユーザーを追加する作業ではなく、「自社のWeb資産に誰がどこまでアクセスできるか」を決めるガバナンス設計に近い。ここを雑に扱うと、所有者退職や代理店変更のたびに、SEO対策や広告レポートが数週間止まるといった現場トラブルが起きる。

押さえるべき要素は大きく3つある。

• 権限レベル（所有者/委任所有者/フルユーザー/制限付きユーザー）

• プロパティ構造（ドメインプロパティかURLプレフィックスか）

• アカウント設計（誰のGoogleアカウントに所有権を持たせるか）

この3つをセットで設計しないと、「権限は付与できたが、後から削除できない」「一部のサイトだけ代理店を変えたいのに、全部まとめて巻き込まれる」といった事態になりやすい。

Search Consoleの権限レベルとプロパティ構造をざっくり整理（Google公式のどこまでを現場に落とすか）

Google公式ヘルプは仕様として正確だが、そのままだと現場の判断材料になりにくい。実務視点では、以下のように翻訳しておくと運用しやすい。

権限レベルと役割イメージ

種類	典型的なアカウント	できることの範囲
確認済み所有者	会社の基幹アドレス、情報システム部	プロパティの削除、他者への所有権委任、全データ閲覧・設定変更
委任所有者	Web担当マネージャー	ユーザー追加・削除、日常運用の設定変更
フルユーザー	制作会社/SEOコンサル	ほぼ全てのレポート閲覧と設定変更、ユーザー追加は不可
制限付きユーザー	外部ライター、分析のみの相手	データ閲覧のみ、一部レポート制限あり

プロパティ構造も重要だ。ドメインプロパティは「会社全体の土地」、URLプレフィックスは「その土地の一角のテナント」のようなイメージになる。

• ドメインプロパティ

  例: example.com 配下を一括で管理。グループ企業や複数サービスをまとめて見る場合に便利だが、権限を渡す相手を誤ると全サイトが丸見えになる。

• URLプレフィックス

  例: https://service.example.com/ のみ。特定サービスだけ代理店に渡したい場合や、テスト環境を分けたい場合に有効。

権限付与をする前に、「この相手にドメインごと見せるのか、このURLだけ見せるのか」を決めておくことが、後々のトラブル回避に直結する。

権限「付与」「削除」がSEO施策・データ活用に与える影響イメージ

権限操作は、単なる表示設定ではなく、日々のSEO運用とレポート精度に直撃する。特に以下の3点は、権限付与・削除のたびに必ずチェックしたい。

権限変更が影響しやすいポイント

• インデックス関連の設定

  フルユーザー以上が、インデックス登録リクエストやURL検査ツール、サイトマップ送信を行う。誤って権限を削除すると、リニューアル直後など肝心なタイミングでSearch Consoleからのインデックス促進ができなくなる。

• レポート共有と意思決定

  制限付きユーザーにしか権限を渡していないと、技術レポート（カバレッジ、ページエクスペリエンス、リンクなど）が見えず、SEO診断の精度が落ちる。代理店側が「データが不足しているので診断が甘くなる」と明言しているケースも多い。

• アラート対応のスピード

  モバイルユーザビリティの警告や手動ペナルティの通知は、所有者とユーザーにメールで届く。所有者のメールアドレスが退職者の個人アカウントのまま残っていると、会社として気づくのが数週間遅れ、その間検索結果からのアクセスが落ち続けるリスクがある。

権限を削除する時も同じだ。外部の代理店やフリーランスのユーザーを消す前に、「その人だけが持っていたノウハウやカスタムの使い方」がないかを確認せずに切断すると、翌月のレポートから重要な指標がごっそり抜けることがある。

表面的には無料ツールのユーザー管理に見えるが、実態は「会社の検索トラフィックを誰がコントロールするか」の設計作業になる。この前提をチーム内で共有しておくと、権限付与の議論が「早く相手に渡してあげて」ではなく、「どのレベルなら安全に渡せるか」という視点に変わる。

現場で本当に起きている権限トラブル3選と、復旧までのリアルな手順

所有者が退職して誰もユーザー追加できないケース（DNS・HTMLでの所有確認からの復旧手順）

よくあるのが「ログインはできるけれど、[ユーザーと権限]に入ったら自分はユーザー扱いで、所有者は退職済みの個人アドレス」というパターンです。新規ユーザー追加も削除もできません。

復旧の基本は「元の所有者に頼る」のではなく、サイト側の証明（DNS/HTML）で所有権を取り返すことです。

主な手順は次の通りです。

• 現在のプロパティ種別（ドメインプロパティかURLプレフィックスか）を確認

• 利用できるインフラを洗い出し

  • DNSのTXTレコードを編集できるか
  • WebサーバーにHTMLファイルをアップロードできるか

• Search Consoleで同じURLの新規プロパティを追加し、「所有権の確認方法」を選択

• DNSまたはHTMLファイルで所有権を確認し、自分を確認済み所有者にする

• [ユーザーと権限]から、必要なメンバーをフルユーザー／制限付きユーザーとして追加

• 不要な委任所有者・ユーザーを削除し、社内の台帳に反映

ここで詰まりやすいのが「どの部署がDNS・サーバーに触れるか分からない」点です。情報システム部やサーバー管理会社との連携を早めに依頼しないと、復旧が長期化します。

代理店に所有権を丸投げして乗り換えが遅れたケース（契約・アカウント設計の見直しポイント）

「全部お任せで」と代理店アカウントを確認済み所有者にしてしまった結果、解約時にSearch Consoleのアクセスが人質になるパターンも頻出です。

起きがちな流れは次の通りです。

• 旧代理店が、会社ドメインではないGoogleアカウントで所有権を取得

• クライアント側はユーザー（多くはフルユーザー）として追加されるだけ

• 乗り換え時に所有権の削除・権限移管を依頼しても、対応が遅れる・条件を付けられる

この状況を断ち切るには、所有権を自社の基幹アカウントに戻す設計変更が必要です。

• 自社ドメインの共通アドレス（例: webmaster@company.jp）でGoogleアカウントを作成

• そのアカウントでDNS/HTMLによる所有権確認を行い、確認済み所有者になる

• 代理店は「委任された所有者」またはフルユーザーとして追加し、契約終了時に削除できる状態にする

• 新規・更新の契約書には、以下を明文化

  • Search Consoleの確認済み所有者は常にクライアント側
  • 代理店は委任所有者またはユーザー権限にとどめる
  • 解約時に全ユーザー・委任所有者を削除すること

「オーナーは会社、代理店は合鍵を預かる立場」という整理にしておくと、乗り換え時の摩擦を最小化できます。

テスト用メールアドレスで所有確認した結果、ログイン不能になったケース（アカウントチェックと再設定の流れ）

短期検証で使ったテスト用Gmailや、担当者が個人的に作ったアドレスで確認を済ませ、その後ログイン情報が行方不明になるケースも多いです。パスワードリセットさえできないと、実質「幽霊オーナー」が居座る状態になります。

この場合も、やることはシンプルで、現在の所有者アカウントを救出しようとせず、別ルートで所有権を再取得するのが安全です。

• まず、Search Consoleの[ユーザーと権限]画面で

  • どのアドレスが所有者か
  • 自分がユーザーとして入れているか
    を確認

• 所有者アドレスがテスト用で復旧不能なら、ケース1と同様にDNS/HTMLで新たに所有権を取得

• 新しい確認済み所有者アカウントから、幽霊状態のテスト用所有者を削除

• 今後は「プロジェクト用の個人アカウントは禁止」「会社の共通アドレスのみ所有者にできる」といった社内ルールを整備

3つの典型トラブルをまとめると、次のような構造になっています。

ケース	主な原因	症状	復旧のキー操作
退職者が所有者	個人アドレスに所有権集中	ユーザー追加・削除ができない	DNS/HTMLで新規所有権確認
代理店がオーナー	契約時の設計不備	乗り換え時に交渉が長期化	自社基幹アカウントで所有権再取得＋契約条文化
テスト用メール	使い捨てアカウントで確認	ログイン不能の幽霊所有者	別アカウントで再確認し、旧所有者を削除

どのケースも、「誰のGoogleアカウントがどのレベルの権限を持っているか」を見える化し、DNSやHTMLによる所有権確認を自社側で握り直すことが、最短の出口になります。

「所有者」「委任」「ユーザー」をどう分けるか：会社と代理店の関係で考える権限戦略

Search Consoleの権限は「技術」ではなく「ガバナンス設計」の話に近い。誰が財布を握り、誰にカードを貸すかを先に決めておかないと、担当者退職や代理店変更のたびに揉める。

所有権は誰のアドレスに持たせるべきか（企業基幹アカウントと個人Gmailのリスク比較）

所有権をどのメールアドレスに紐づけるかは、後からほぼ修正不能な「土台」の選択になる。

項目	企業基幹アカウント例（webmaster@company.jp）	個人Gmail例（taro.xxx@gmail.com）
管理責任	組織に紐づくため継続性が高い	退職・異動と同時に行方不明になりやすい
引き継ぎ	情シスや管理者がアクセスを制御しやすい	パスワード不明で所有権復旧が必要になる
セキュリティ	ポリシーや2段階認証を組織で統制しやすい	セキュリティ設定が本人の意識頼み

所有権は必ず会社ドメインの「役職アドレス」に置き、個人Gmailには委任所有者またはユーザー権限だけを付ける運用に寄せると、退職トラブルのリスクが激減する。

委任所有者・フルユーザー・制限付きユーザーの役割分担モデル

所有権を土台としたうえで、日々の運用は委任所有者とユーザーでさばく。

役割	想定ポジション	主な操作範囲
確認済み所有者	情シス/インフラ責任者	プロパティ追加・削除、委任所有者の管理
委任所有者	Web/マーケ責任者	ユーザー追加削除、主要設定の変更
フルユーザー	SEO担当・技術担当	エラー修正、URL検査、インデックス登録申請
制限付きユーザー	コンテンツ担当・外部アナリスト	レポート閲覧、データダウンロードのみ

ポイントは、「日々触る人ほど権限レベルを落とす」発想を持つこと。ミス操作で最悪の事態が起きないラインを見極めて割り当てる。

代理店・外注先に渡す権限レベルの選択基準（相手との信頼関係と作業範囲から決める）

外部パートナーにどこまで権限を渡すかは、感情ではなく作業内容と契約で決める。

【作業範囲ベースの目安】

• レポート閲覧やSEO診断のみ

→ 制限付きユーザーで十分

• クロールエラー対応、リダイレクト検証、移転作業を実施

→ 期間を区切ってフルユーザー

• 代理店側が自社クライアントを再委託する構造がある

→ 委任所有者は付与せず、必ず自社側で所有権と委任所有者を保持する

【信頼・契約ベースの確認】

• 契約書に「所有権は常にサイトオーナー企業に帰属」「解約後は速やかにユーザー権限を削除」と明記する

• 複数代理店が並走する場合は、「どの代理店がどのプロパティのどの権限を持つか」を一覧表にして共有する

この線引きを事前にしておくと、「先方代理店から所有者権限を要求されたが、本当に必要か」を冷静に判断できるようになる。

【図解イメージ】サーチコンソールの権限種類と操作範囲早見表

所有者／フルユーザー／制限付きユーザーで何ができて何ができないか一覧

Google Search Consoleの権限は、ざっくり言うと「家の鍵」の強さが違うだけです。
どの鍵を誰に渡すかを間違えると、SEO対策どころかサイト運営そのものが危険になります。

プロパティごとに、権限で操作できる範囲は次のように変わります。

操作・機能	所有者(確認/委任)	フルユーザー	制限付きユーザー
検索パフォーマンス等のデータ閲覧	◯	◯	◯
インデックス登録リクエスト	◯	◯	×
URL検査の詳細情報表示	◯	◯	△(一部のみ)
手動対策・セキュリティ問題の確認	◯	◯	◯
削除ツールによるURL一時削除	◯	◯	×
サイトマップ送信・削除	◯	◯	×
リンクレポートの詳細確認	◯	◯	△(閲覧中心)
ユーザー追加・権限変更	◯	×	×
プロパティ削除	◯	×	×
所有権の移譲・委任管理	◯	×	×
設定メニュー(アドレス変更等)	◯	◯	×

ポイントは3つです。

1. 所有者だけができる操作
   ユーザー管理、所有権の委任、プロパティ削除は所有者専用です。
   ここを外部に明け渡す＝ドメイン資産の根本を預ける、という意味になります。

2. フルユーザーができる「事故りやすい操作」
   URL削除ツール、サイトマップ削除、設定メニューの一部は、誤操作で検索結果からページが消えます。
   「アクセスが急に落ちた」の裏で、ここが触られていたケースが実際に多数あります。

3. 制限付きユーザーでも十分な人は多い
   コンテンツ担当やレポート閲覧中心のメンバーは、パフォーマンスや検索クエリ、ページ別データを見られれば足りることがほとんどです。
   無理に更新系の権限を持たせる必要はありません。

よくある“全部フル権限”運用が危ない理由（セキュリティと運営体制の観点）

中小企業や個人サイトで特に多いのが、「とりあえず全員フルユーザー」「代理店にもまとめてフル権限」という運用です。
表面的には楽ですが、現場では次のようなトラブルが繰り返されています。

• 責任の所在があいまいになる

  URL削除や設定変更で検索流入が落ちても、「誰が」「いつ」触ったかを説明できない。
  社内での責任追及がグレーになり、再発防止も曖昧なまま残ります。

• 退職・契約終了後も外部アカウントが生き続ける

  一時的に依頼したフリーランスや代理店担当者のGoogleアカウントが、半年たってもフル権限のまま残っているケースがよくあります。
  連絡が取れない相手に、いつでもURL削除や設定変更ができる状態を許しているのと同じです。

• 「ちょっと試してみた」が本番サイトに直撃する

  テスト用のつもりで削除ツールやサイトマップを触り、そのまま戻し忘れるパターンもあります。
  Search Consoleは無料ツールですが、やっていることは検索インフラの制御です。
  サーバーの管理コンソールを触るのと同じレベルの慎重さが本来は必要です。

• 権限設計そのものがブラックボックス化する

  全員フル権限にしてしまうと、「このプロパティは誰がどこまで責任を持つのか」を整理するモチベーションが失われます。
  結果として、所有権やユーザーの一覧を誰も説明できない状態になり、所有者退職や代理店変更のタイミングで一気に爆発します。

安全に運用するための現実的な落としどころは、次のような分担です。

• 企業の基幹アカウントを確認済み所有者

• Web/マーケ責任者を委任所有者または一部フルユーザー

• 代理店や外部コンサルは、業務内容に応じて期間限定のフルユーザーか制限付きユーザー

• コンテンツ担当やCS、レポート閲覧だけのメンバーは制限付きユーザー

「全部フル権限」は、一瞬の手間を惜しんで、後から何倍もの復旧コストとSEOリスクを支払う設計です。
誰にどの鍵を渡すかを、プロパティごとに意識的に決めるところからが、サーチコンソール権限付与の本当のスタートラインになります。

権限付与の具体的な手順と「追加ユーザー」設定の注意点

Search Consoleの権限付与は、画面上は数クリックだが、ミスると「誤った相手にサイトの診断データを丸ごと渡す」ことになる。ここでは、現場で事故を減らしてきた手順とチェックポイントに絞って整理する。

画面メニューからの権限付与ユーザー追加手順（メールアドレス入力〜完了まで）

操作自体はシンプルだが、焦っている時ほどプロパティやメールアドレスを誤りがちなので、落ち着いて進める。

1. 権限を付与したいプロパティを選択（左上のプロパティ名をクリックして切り替え）
2. 画面左下「設定」をクリック
3. 「ユーザーと権限」をクリック
4. 右上「ユーザーを追加」をクリック
5. 相手のGoogleアカウントのメールアドレスを入力
6. 「フル」か「制限付き」を選択
7. 「追加」をクリックして完了

付与後、一覧に新しいユーザーが表示されているか、その場で必ず確認する。

付与前に必ず確認したい3つの項目（プロパティ選択・アカウント種別・業務内容）

「誰に」「どこまで」を間違えないための最低限の下準備を、付与前ルールとして固定しておく。

ポイントは次の3つ。

• プロパティ選択

  レポートを共有したいURLと、今開いているプロパティが一致しているか確認
  ドメインプロパティかURLプレフィックスかも必ず見る

• アカウント種別

  個人Gmailか、会社共有アカウントかを事前に確認
  退職・外注終了を想定し、長く使えるアドレスを優先

• 業務内容

  相手がどの作業を担当するかをメモに書き出し、「閲覧のみ」か「設定変更も必要」かを判断材料にする

この3点を整理してから、フル権限か制限付きかを決めると迷いが減る。

下記は、権限レベルと向いている担当の目安。

権限レベル	主な想定ユーザー	想定業務
フルユーザー	社内Web担当、SEO担当、技術寄りの代理店	インデックス診断、URL検査、サイト移転時の設定変更
制限付きユーザー	外注ライター、アナリスト、経営層	検索パフォーマンス閲覧、レポート作成

付与後すぐにやるべきアカウントチェック（正しい相手に届いているか／ログイン確認）

権限を追加した直後に、次の2ステップを必ずセットで行うとトラブルが激減する。

• メール到達と本人確認

  追加した相手にチャットやメールで連絡し、「GoogleからSearch Consoleの共有メールが届いているか」を確認
  メールが来ていなければ、アドレスのスペルミスや、相手のアカウント種別を再確認する

• 実際にログインしてもらう

  相手側でSearch Consoleを開いてもらい、指定したプロパティが表示されているかを画面共有やスクリーンショットで確認
  「見えているメニュー」と「触ってよい範囲」を口頭で共有しておくと、意図しない設定変更を防ぎやすい

この「付与直後の2分チェック」をルール化しておくと、「別人に渡していた」「プロパティを間違えていた」といった初歩的な事故をほぼ潰せる。

「とりあえず代理店に所有権」時代はもう終了：よくある古い常識とその矛盾

制作会社・代理店に所有権を渡す運用が生まれた背景と、現在のリスク

Search Consoleの「所有権」を代理店や制作会社のアカウントに付与しているケースはまだ多い。これは旧Search Console（旧ウェブマスターツール）時代の名残で、「技術が分かる外部に全部任せた方が早い」という発想から生まれた運用だ。

• サイト立ち上げ時に、制作会社がDNSやHTMLタグへアクセスできた

• クライアント側はGoogleアカウント運用に不慣れで、管理を任せた

• SEO対策と広告運用を丸投げし、「Search Console＝専門ツール」と見なしていた

ところが今は、この運用が長期的なリスクの塊になっている。典型的な問題を整理すると次の通り。

状況	何が起きるか	実務インパクト
代理店が確認済み所有者、会社側はユーザーのみ	解約後も代理店がプロパティを削除・設定変更できる	乗り換え時にデータ閲覧が止まり、SEO診断が数週間遅延
代理店アカウントが委任所有者を乱発	誰がどこまで権限を持っているか不明	退職者・元フリーランスがいつまでもアクセス可能
テスト環境のプロパティも代理店所有	本番移行時に権限整理されず放置	どのURLが本番か管理画面上で混乱、誤クリックの温床

所有権はドメイン資産へのマスターボタンに近い。DNSやサーバーと同じレイヤーにあるため、短期の制作プロジェクトではなく、会社の基幹アカウント（例：webmaster@会社ドメイン）で保持すべきだ。代理店に必要なのは多くの場合「フルユーザー」か、一時的な「委任所有者」であり、恒久的な所有権ではない。

「Search ConsoleはSEO担当だけのツール」という誤解（チーム全体で見るべきデータとKPI）

「Search Console＝SEO担当の作業コンソール」という前提で運用している組織も多いが、現場を見るとこの前提がボトルネックになっている。Search Consoleのレポートには、SEOだけでなく、他部署が見るべき事業KPIの“前段階データ”が詰まっている。

部署	見るべき主なレポート	そこから追うべき指標（例）
コンテンツ担当	検索パフォーマンス（クエリ・ページ）	クリック数・CTR・表示回数から「企画の当たり外れ」を判定
CS・サポート	検索クエリ、「検索結果での掲載状態」	「エラー名＋自社名」など、クレーム予兆ワードの把握
経営層	サマリー、インデックスカバレッジ	重要サービスページのインデックス率、検索流入のトレンド
広告担当	ブランドワードの自然検索の推移	指名検索の増減と広告費のバランス調整

「SEOチームだけが所有者＋フルユーザー」という設計にしてしまうと、他部署はスクリーンショットベースの“又聞きの情報”しか得られない。その結果、意思決定が遅れ、「検索結果で何が起きているか」をリアルタイムに共有できない。

現実的には、次のような分担が扱いやすい。

• 所有者：基幹アカウント（情報システム部／Web責任者）

• フルユーザー：SEO担当、テクニカル担当、主要代理店

• 制限付きユーザー：コンテンツ担当、CS、必要なマネージャー層

閲覧専用の制限付きユーザーを広めに配布し、「操作できる人」を絞ることで、事故リスクと情報共有を両立できる。

他のコンソール（GA4・タグマネ・広告管理画面）との所有者のズレが招く現場の混乱

Search Console単体で見れば問題なさそうでも、GA4、Googleタグマネージャー、Google広告と所有者アカウントの体系がバラバラになっている組織は珍しくない。

• GA4は情報システム部のGoogleアカウントがオーナー

• タグマネは制作会社の共有アカウントがオーナー

• Search ConsoleはSEO代理店の個人Gmailが確認済み所有者

この状態でサイトリニューアルやドメイン変更が走ると、「誰がどのコンソールを触れるのか」を確認するだけで数日消える。最悪なのは、どこか一つでも所有者にたどり着けず、移行設定や所有権の再確認ができないまま、検索結果だけが崩れていくパターンだ。

対策としては、権限棚卸しの際に次の観点で整理するとよい。

ツール	推奨オーナー	最低限そろえるべき状態
Search Console	会社ドメインの基幹アカウント	ドメインプロパティで確認済み所有者が社内に1つ以上
GA4	同上	プロパティの管理者ロールが複数名（属人回避）
タグマネージャー	同上	コンテナの公開権限を外部に丸投げしない
Google広告	事業側の公式アカウント	代理店は管理者権限だが、支払い情報は事業側管理

Search Consoleだけを見ていても、全体の権限設計は整わない。すべてのGoogle系コンソールの「所有者マップ」を一枚のシートで可視化するところから、古い運用の後始末が始まる。

権限設計を「一度決めて終わり」にしないための棚卸しフローとチェックリスト

Search Consoleの権限は、サーバーやDNSと同じく「インフラ権限」です。設定した瞬間がゴールではなく、担当者の異動・代理店の変更・サイトの統廃合に合わせて、継続的な棚卸しを行う前提で設計しておく必要があります。

ポイントは次の3つです。

• 何かが「終わる瞬間」（退職・契約終了）で必ず棚卸しを走らせる

• 半年に1回の定期点検で「権限の化石」を掘り起こす

• 誰が何を持っているかを、スプレッドシートで台帳管理する

以下でフローとチェックリストを具体化します。

担当者異動・退職・外注終了時の標準フロー（付与ユーザーの棚卸し作業）

人や外注が動くタイミングで、Search Consoleの権限も必ず動かします。実務で使いやすい標準フローは次の通りです。

【ステップ1：対象プロパティとアカウントの洗い出し】

• 対象サイトのプロパティ一覧を確認（ドメインプロパティ／URLプレフィックス両方）

• GA4やタグマネージャー、広告アカウントと紐付いているWebサイトかも確認

• 異動・退職する担当者がログインしていたGoogleアカウントをリスト化

【ステップ2：権限の棚卸し】

Search Consoleの「ユーザーと権限」画面で、以下を一人ずつ確認します。

• 所有者（確認済み／委任）のメールアドレス

• フルユーザー・制限付きユーザーの一覧

• 代理店・制作会社・フリーランスなど外部ユーザーの有無

【ステップ3：変更作業】

退職・契約終了が確定しているアドレスに対して、次を実施します。

• 退職者／終了した外部パートナー

  • 所有者の場合：別の会社公式アカウントで所有権を再確認したうえで、旧アドレスの所有権を削除
  • ユーザーの場合：フルユーザー／制限付きユーザー権限を削除

• 後任担当

  • 会社の基幹メール（例：web@company.jp）でユーザーを追加
  • 必要に応じて委任所有者に昇格し、日常運用を任せる

【ステップ4：記録】

• 変更内容を台帳（後述のスプレッドシート）に記録

• 人事や情報システム部の「退職チェックリスト」に“Search Console権限削除”を追加しておく

半年に一度の権限レビューで見るべきチェック項目（外部ユーザー・不要プロパティ・アクセス状況）

棚卸しを人任せにすると、3年後には誰も把握できない「ブラックボックス権限」になります。半年に一度、次の3観点でレビューします。

【1. 外部ユーザーの洗い出し】

• 代理店・制作会社・コンサル・フリーランスのメールアドレス

• 契約がすでに終了している会社／担当者が残っていないか

• 「会社名不明」「個人Gmailのみ」のユーザーがいないか

【2. 不要プロパティの整理】

• すでに閉鎖したサイトのプロパティが残っていないか

• リニューアル前の旧ドメインが複数残存していないか

• 本番／ステージング／テスト環境が混在していないか

【3. アクセス状況のチェック】

• 実際にログインされていないユーザー（半年以上アクセスなし）の存在

• フルユーザーなのに単なるレポート閲覧だけの人がいないか

• 委任所有者なのに明確な役割を持っていないアカウントがないか

レビュー観点を一覧化すると、整理しやすくなります。

チェック項目	見る場所	判断基準
外部メールアドレス	ユーザーと権限	契約継続中か／担当者在籍中か
不要プロパティ	プロパティ選択画面	閉鎖サイト・旧ドメインはアーカイブか削除
アクセス状況	社内ヒアリング・ログ	半年以上使っていなければ削除候補

スプレッドシートで管理する「誰がどの権限を持っているか」台帳の作り方

台帳がない状態は、「鍵がどこに何本あるか誰も知らない家」と同じです。スプレッドシートで、最低限次の列を持つ台帳を作っておきます。

【基本カラム構成】

• サイト名

• プロパティID／URL

• プロパティ種類（ドメイン／URLプレフィックス）

• メールアドレス

• 権限種類（確認済み所有者／委任所有者／フルユーザー／制限付き）

• 立場（自社社員・部署名／代理店名／フリーランスなど）

• 付与日

• 付与理由（レポート閲覧／テクニカルSEO対応／広告連携など）

• 予定終了日（プロジェクト終了予定日）

• 実際の終了日・削除日

• 備考（契約IDや担当窓口など）

【運用ルールのコツ】

• 新しくユーザーを追加した人が、その場で台帳に記入する

• 半年レビューのたびに「削除日」を埋めていく

• 退職・異動リストと突き合わせて、該当アカウントの列を一括チェックする

このレベルまで可視化しておくと、「所有者が誰か分からない」「代理店が勝手に残っていた」といった典型的なSearch Consoleトラブルを事前に防げます。権限付与のクリック自体は無料でも、ミスのコストは検索流入と信頼の両方で跳ね返るので、棚卸しフローと台帳をセットで仕組み化しておく価値があります。

サーチコンソール権限を活かすためのチーム運営：SEO担当だけに閉じない情報共有術

Search Consoleは「SEO担当の専用ツール」ではなく、Web運営全体の診断コンソールに近い立ち位置にある。所有権やユーザー権限の設計を誤ると、コンテンツ担当やCS、経営層が見るべきデータが届かず、検索結果の変化に会社として鈍感になる。ここでは、プロパティの権限設計を前提にしたチーム運用を整理する。

コンテンツ担当・CS・経営層にどのレベルのアクセスを渡すか

権限は「どこまで操作させるか」ではなく、「どこまで検索データを共有したいか」で決めると迷いにくい。

役割	推奨権限レベル	主な利用データ	付与時の注意点
コンテンツ担当	制限付きユーザー	クエリ別クリック数・ページ別表示回数	誤操作防止。自分の担当サイトかプロパティを必ず確認
CS・サポート	制限付きユーザー	問い合わせ急増ページと検索ワード	個人メールではなくCS共通アドレスに付与
経営層	制限付きユーザー(閲覧専用)	ブランド名の検索トレンド・主要KPIレポート	モバイルからの閲覧を想定し、見せるプロパティを絞る
テクニカル担当	フルユーザー	インデックスカバレッジ・ページエクスペリエンス	サーバー・DNS担当とアカウントを揃える

よくあるのは「共有が面倒でCSVだけメールする運用」だが、これはデータの意味を誤解させやすい。制限付きユーザーで直接コンソール画面を見てもらい、Search結果のリアルな揺れ方を体験させた方が、社内のSEOリテラシーが早く揃う。

Search Consoleのデータを使った定例ミーティングの組み立て方（KPIとSOVの見せ方）

Search Consoleを定例会議で使う際は、「何を見るか」をテンプレ化しておくと、代理店とのミーティングでも迷走しない。

【月次ミーティングの基本フロー】

1. プロパティ選択と期間確認
   ・前月 vs 前々月、前年同月を必ず指定してから話を始める

2. KPIダッシュボード共有
   ・総クリック数、表示回数、平均CTR、平均掲載順位
   ・ブランドクエリと汎用クエリを分けて比較（SOVの簡易版）

3. ページ別レポートで「勝ち負けページ」を特定
   ・クリック増減率の高いページ上位20件を一覧化
   ・コンテンツ担当に「なぜ伸びたか／落ちたか」をコメントしてもらう

4. CS・広告との連携ポイント確認
   ・問い合わせ急増ページと検索クエリをCSに共有
   ・広告出稿キーワードと自然検索クエリが被っていないかをチェック

【議事録に残すべき3項目】

・今月の検索トレンド（ユーザーの悩みの変化）
・次月対応する具体的な修正案（タイトル変更、FAQ追加など）
・権限追加・削除の要否（新メンバーや外部パートナーの参加状況）

この「権限」と「定例ミーティング」をセットで設計すると、Search Consoleが単なるSEO担当の作業画面ではなく、会社全体の無料な検索インサイトツールとして機能し始める。

よくある質問と「LINE/メールで実際に飛んできそうな相談」への回答例

「先方の代理店から所有者権限を要求されたのですが、許可しても大丈夫ですか？」への回答例

LINEで届きそうな文面
「サーチコンソールの所有権を代理店さんに付与してくれって言われました。クリックして渡していいんですか…？」

まず押さえるポイントは3つです。

• 所有者権限は「ドメイン資産の鍵」レベルで重い

• 代理店の作業内容によって必要な権限は変わる

• 契約とアカウント設計をセットで考える

判断の目安を表にまとめるとこうなります。

状況	推奨する対応	渡す権限レベル
レポート閲覧・SEO診断のみ	所有権は渡さない	制限付きユーザー
施策実行まで任せるが自社で管理したい	自社が確認済み所有者、代理店は運用担当	フルユーザー or 委任所有者
長期で全面委託＋深い信頼関係	それでも「自社所有＋委任」で運用	自社＝確認済み所有者、代理店＝委任所有者

返信テンプレ例（メールでも使える文面）

「所有者権限は、当社ドメイン全体の管理に相当するため、原則として自社アカウントで保持させていただいております。
御社には、必要な範囲で

• サイト全体のデータ閲覧

• インデックス関連の設定・URL検査

を行っていただけるよう、サーチコンソールの『フルユーザー』権限を付与する形でご対応したいと考えています。
それ以上の操作が必要な場合は、作業内容とあわせてご相談いただけますでしょうか。」

ポイントは「信頼していないから渡さない」ではなく、「会社としての運用ルール」として説明することです。
所有権を丸ごと外部アカウントに持たせると、解約後もプロパティ削除やユーザー削除が技術的には可能な状態が続きます。これが後々の乗り換えトラブルの火種になります。

「前任者の個人アドレスが所有者で、連絡が取れません。費用をかけずに何とかする方法はありますか？」への回答例

よくあるのが「前任者のGmailが確認済み所有者で、誰もユーザー追加できない」というパターンです。この場合、代理店にお金を払わなくても、自社で復旧できるケースが多くあります。

基本の手順は次の通りです。

1. 現在生きている「会社のGoogleアカウント」を1つ決める
   例：webmaster@会社ドメイン、info@会社ドメイン

2. そのアカウントでSearch Consoleにログインし、「新しく所有権を確認」する

   • DNSレコード追加方式（おすすめ）
   • HTMLファイルアップロード方式
   • 既に導入済みならGoogleアナリティクス/タグマネージャー経由

3. 新たに「確認済み所有者」になれたら、「ユーザーと権限」画面で古い個人アドレスを削除

DNSを触れるかどうかで難易度が変わります。

条件	おすすめの所有権確認方法
社内でDNSを管理している	DNSレコード追加方式
レンタルサーバーだけ触れる	HTMLファイルアップロード方式
GA4やタグマネを自社管理	それ経由の確認を優先

費用ゼロでやるコツは「社内に1人はいるインフラ寄りの担当者」と組むことです。
LINEで依頼するなら、こんな書き方が現実的です。

「Search Consoleの所有者が前任者の個人Gmailになっており、こちらでユーザー追加ができない状態です。
会社公式のGoogleアカウントで所有権を取り直したいので、DNSに指定のTXTレコードを1行だけ追加していただくことは可能でしょうか？
Googleの公式ヘルプURLと設定値はこちらです。」

この「会社公式アカウントで取り直す」さえできれば、前任者と連絡が取れなくても、プロパティの管理権は取り戻せます。

執筆者紹介

IT・Web領域の実務検証を軸に記事を制作している、株式会社アセット運営メディア「Next Wave」編集部です。危険サイトや広告挙動の実機検証記事を継続的に公開し、ネットサービス利用時のリスクと対策を整理してきました。本記事ではその検証・整理ノウハウを応用し、Search Console権限設計を「操作手順＋権限トラブルの構造」として解説しています。