本部サイトとは別に、採用サイト、ブランドサイト、各店舗のページ、過去のキャンペーンサイトがある。担当者が変わってから「このサイトは誰が管理しているのか」と聞かれても、すぐには答えられないことがあります。見えているページを数えただけでは、更新する場所も契約先も分かりません。まず必要なのは、残すか閉じるかを即決することではなく、各サイトのURL、役割、管理先、確認できた事実を一行ずつ対応させることです。
この記事は、複数ブランドや店舗のWeb情報を管理する本部と各店の担当者に向けた、サイト単位の棚卸し方法です。「現役」「終了候補」「調査対象」の三つの状態を仮置きし、どの画面を誰が確かめるかを決めます。制作会社の切替手続き、統合する機能の選定、アクセス解析の合算は別の判断として扱います。ここで作る台帳は、それらへ進む前に対象を見失わないための資料です。
みやあじよの複数サイト・多店舗の情報管理も、見つかったURLに役割、契約・管理先、更新方法、問い合わせ先を加え、古いキャンペーンサイトを利用状況の確認なしに削除しないと説明しています。本記事では、その最初の一枚を実際に埋めるため、空欄の意味と状態の決め方まで具体化します。記載する行は架空の編集例です。実在企業の契約や利用状況を示すものではありません。
「サイト」の単位をURLと用途で決める
管理表の最初の列には、社内で呼ぶ通称だけでなく、訪問者が開くURLを書きます。同じ会社名のサイトでも、wwwの有無、別のサブドメイン、採用専用ドメイン、店舗別ページなど、入口が異なります。トップページのURLに加え、採用や予約など重要な入口が別の場所にあるなら、その代表URLも記録します。一つのサイト内の全ページを最初から行にする必要はありませんが、別の担当や契約で動くものを一行に混ぜないことが大切です。
URLの一覧は、社内の資料から始めます。現在のサイトマップ、店舗一覧、過去の広告・チラシ、社内のリンク集、管理画面のサイト一覧、契約書や請求明細に載るドメイン名を集めます。Search Consoleを利用している場合は、登録済みのプロパティも候補になります。ただし、Googleの公式ヘルプによれば、ドメインプロパティとURLプレフィックスプロパティでは含むURLの範囲が違います。管理画面の項目数をそのままサイト数とみなさず、どの公開URLに対応するかを開いて確かめます。
検索で見つからないから「存在しない」と判定するのも早計です。公開ページでも検索結果に出ない場合があり、認証が必要なサイトや一時的に表示できないサイトもあります。反対に、検索で古いページが見つかっても、現在の契約と更新担当が分かるわけではありません。見つけた経路、確認日、実際に開いたときの表示先を別欄へ残し、候補が重なれば同じ入口かどうかを調べます。URLを正規化して重複をまとめる作業と、用途が異なるページを区別する作業は両方必要です。
一行に入れる六項目と、その確認先
台帳の核は「サイト・用途・管理者・契約・更新元・状態」です。サイト欄には代表URLと、必要なら店舗やブランドの名前を入れます。用途欄には「誰が何をするために訪れるか」を短く書きます。企業案内、求人応募、商品購入、店舗予約では、残す場合に守るべき入口が違います。「ブランドサイト」だけで済ませず、問い合わせや予約など実際の行き先も添えます。
管理者欄は、肩書きが一つあれば十分という意味ではありません。内容を決める本部・店舗の担当、CMSで変更できる人、契約や権限を変更できる窓口を分けて記録します。契約欄は、ドメイン、サーバー、保守・制作など、把握している提供先と契約資料の所在を示します。費用や契約期間をこの表に全て転載する必要はありません。更新元欄には、サイトの本文を直す画面、店舗情報の共通入力欄、外部予約サービスなど、訪問者に見える情報の元を記します。パスワードは台帳へ書かず、権限の確認先と保管方法を示します。
次の表は、架空の本部が最初の確認で作る行の例です。「未確認」は空欄と違い、まだ調べる必要があることを示します。状態は公開中かどうかだけで確定せず、用途と責任者を照合してから更新します。
表は左右にスクロールして確認できます。
| サイト・代表URLの例 | 用途・主要な入口 | 管理者と契約の確認先 | 情報の更新元 | 仮の状態と次の確認 |
|---|---|---|---|---|
本部サイト／example.com |
会社案内・問い合わせ | 本部広報。契約書の所在を確認 | 本部CMS | 現役。フォーム通知先を開いて確認 |
採用サイト／recruit.example.com |
求人・応募 | 人事と制作担当。保守範囲は未確認 | 採用CMSと応募サービス | 調査対象。応募先と現行求人を確認 |
旧企画サイト／campaign.example |
配布物からの案内 | 担当者不明。ドメイン契約先を調査 | 更新元不明 | 調査対象。配布物・検索・転送先を確認 |
店舗Aページ／example.com/shop/a/ |
営業情報・予約 | 店舗責任者と本部。独立契約なし | 店舗入力欄と外部予約 | 現役。掲載時間と予約先を確認 |
架空例の最後の行は、独立ドメインではなく本部サイト内のページです。それでも、店舗が内容を確定し、予約先が外部にあるため、管理表では別の管理単位として追う価値があります。一方、契約が同じだけで別ブランドのサイトを一行へまとめると、用途や更新元の違いが見えません。行を分ける基準はサーバーの数ではなく、誰が何を更新し、どこで結果を確認するかです。
実務の表には、各行の確認日、根拠となる画面や資料、次に聞く相手も備考として添えます。「担当者がそう言っていた」と「管理画面で実際に開けた」は確認の深さが違うためです。たとえば契約先が請求書から分かった一方、管理者としてログインできる人は未確認なら、二つを分けて書きます。空欄をそれらしく埋めるより、次の調査が止まらない表になります。
「現役」「終了候補」「調査対象」を事実で分ける
現役は、担当者が「まだ使っている」と答えたサイトだけを指しません。公開画面に現在の案内があり、問い合わせ、応募、予約などの入口が実際の受付につながっているかを確認します。サイトの更新日が古くても、会社概要やサービス案内として利用中かもしれません。利用者がたどる主要なページを開き、担当者の回答と合わせて状態を記します。検索流入や計測値があれば参考にしますが、データのないサイトを未使用と断定しません。
終了候補は「閉じてよいサイト」という確定結果ではありません。用途が終わった、後継のページがある、担当者が終了を希望しているなど、検討の理由を記した状態です。閉鎖前には、古いURLを記した配布物や外部リンク、検索からの訪問、問い合わせ・応募の受付、メールとの関係を確かめます。Google検索セントラルのサイト移転資料は、URLを変える場合に旧URLと新URLの対応や転送を計画するよう説明しています。これは全ての終了候補を一律に転送する指示ではありません。各URLを訪れた人に相応しい行き先があるか、実際の用途で判断する材料です。
調査対象は、運用の事実が足りない行です。たとえばサイトは表示されるが管理者が不明、ドメインの契約先は分かるが掲載内容を決める担当がいない、転送されているが転送先を誰も管理していない、といったケースです。「古いから終了候補」と推測して振り分けず、欠けている証拠、探す資料、確認する人、期限を一緒に書きます。調査中の行を一覧から消さないことで、担当変更後も未解決の対象を追えます。
契約名義とページの責任者を混同しない
ドメインの登録者と、掲載情報を承認する人は別です。ICANNは、ドメイン名の登録者がレジストラと契約し、登録名の管理を行うことを説明しています。一方、公開される登録データから社内のコンテンツ責任者を判断できるわけではありません。契約書・請求書・レジストラの管理画面、社内担当への確認を合わせて、誰が更新や移管の依頼を出せるかを調べます。公開情報だけで名義を断定しないことも必要です。
契約欄には「会社名」だけでなく、どのサービスの契約かを短く添えます。ドメインの更新、サーバーの保守、サイト改修、予約サービスは同じ窓口とは限りません。また、制作会社が管理画面を操作できても、契約の終了や支払いを決める権限まで持つとは限りません。ここでは六つの権限領域を詳細に引き継ぐのではなく、各サイトの問い合わせ先を特定するための参照先を残します。個別の移管手順は、対象と新しい管理先が決まってから確認します。
更新元と表示先の違いにも注意します。本部サイトの店舗一覧と店舗詳細が同じ入力欄を参照する場合も、採用サイトの求人だけは別のサービスから埋め込まれる場合もあります。「本部が更新」とだけ書くと、どの画面を直し、どこまで反映するかが分かりません。代表ページを開いて現在の表示を記録し、担当者に編集画面と公開後の確認画面を見せてもらいます。外部サービスに同じ情報があるなら、自社サイトの台帳とは別の更新対象として紐付けます。
状態ごとに、次のWeb作業を一つ決める
現役の行では、訪問者が使う主要な入口を一つ選び、本文・リンク・フォームや予約先・スマートフォン表示を確認します。社内の担当者と公開画面の内容が一致しなければ、どちらの情報を正本にするかを確認し、修正依頼に進めます。全サイトに同じ検査項目を機械的に当てるより、用途ごとに「訪問者が完了させたい操作」を先に置くほうが、見落としを減らせます。
終了候補の行では、旧URLに来た人をどう案内するかを設計します。後継ページがあるなら旧ページと新ページの内容を対応させ、必要な転送、内部リンク、配布物にあるURLの変更を計画します。後継がないなら、終了の案内を残すのか、別の公式窓口へ導くのか、担当部門と決めます。ドメインやサーバーの契約を止める順序も、ページの扱いと関係します。作業前の段階で消去や解約を進めず、連絡を受ける人と変更後の確認画面を定めます。
調査対象の行では、一般向けの案内を変える前に、最小限の調査依頼を出します。「このURLのドメイン契約と更新期限」「編集できる管理画面」「公開中の問い合わせ先」のように、分からない点を分けて尋ねます。所有者が見つからないことを理由に別サイトへ同じ文章を複製すると、どちらを直すべきか一層分かりにくくなります。調査の結果、現役や終了候補に変わった日と判断者を残します。
台帳は一度完成させて終わりではありません。新しい店舗、ブランド、キャンペーンが増えるときは、公開前に代表URL、用途、内容の責任者、契約・更新元、確認画面を一行追加します。担当が異動する場合は人名だけを置き換えず、権限を持つ部署と連絡方法も確かめます。状態の変更が起きた行から、サイト一覧や関連するページを見直す運用にすれば、「誰も所有者を知らないサイト」が再び生まれるのを抑えられます。
最後に、架空の三つの問い合わせで表を読み戻します。「採用サイトの応募先を直したい」「旧企画のチラシにあるURLを開いた」「店舗Aの営業時間を変えたい」です。各行から、情報を確定する担当、編集画面、公開後に確かめる画面、契約先へ相談が必要かをたどれるでしょうか。たどれない欄は、綺麗な見出しで埋めず「未確認」と確認先を記します。表の目的は、全てを直ちに統合することではなく、次のWeb改善を対象と担当が分かる依頼に変えることです。
参考資料
- ウェブサイトまたはプラットフォームのプロパティを Search Console に追加する｜Google。ドメインとURLプレフィックスの対象範囲を確認。2026年9月23日参照。
- Information for Domain Name Registrants｜ICANN。登録者とレジストラの契約・管理の説明を確認。2026年9月23日参照。
- Site Moves and Migrations｜Google Search Central。URL変更時の対応と転送計画を確認。2026年9月23日参照。
