リニューアルの見積もりを減らすため、閲覧数の少ない記事から削除候補にする。作業としては分かりやすい方法ですが、その記事を営業が商談後に案内していたり、サポート担当が説明に使っていたりすると、必要な情報まで失うことがあります。反対に、よく読まれていても、現在は受けていない条件を案内している記事は、そのまま残せません。
残すかどうかを決めるには、記事の利用目的、外部からの入口、情報が今も有効かを分けて確認します。この記事では、改修範囲を決める経営者・Web担当者に向け、記事ごとの判断台帳と、統合するときに残す説明の選び方を整理します。アクセス数の一律の基準や、削除による順位改善を示すものではありません。
閲覧数は確認の順番に使い、削除の結論にしない
記事一覧を閲覧数の順に並べると、調べる対象を選びやすくなります。ただし、少ない理由は一つではありません。対象となる質問が限定されている、特定の時期だけ使われる、サイト内で見つけにくい、計測できていないなど、内容の必要性とは別の事情も考えられます。数字だけで理由を確定せず、次に何を確かめるかを決める材料にします。
集計するときは、期間と指標名を台帳に添えます。閲覧回数、訪れた人の数、検索結果からのクリック数を、すべて「アクセス」と呼んで比較しないようにしてください。新しく公開した記事と長く公開している記事では、同じ集計期間でも読まれる機会が違います。公開日や計測を始めた時期も確認します。
Search Consoleの公式説明では、検索パフォーマンスのクリック数は、Google検索の結果からサイトをクリックした回数です。これが少ないことだけでは、営業メールや社内の案内で使われていないとは判断できません。指標の対象範囲を踏まえ、検索の記録と業務での利用を別々に調べる必要があります。Search Consoleの検索パフォーマンスの説明
季節に関係する記事なら、その時期を含む期間で確認します。短い期間しか記録がない場合は、その制限を残してください。数字が取れなかった欄をゼロで埋めると、「利用がない」と「未確認」が混ざります。削除を急ぐより、確認できた範囲を明らかにした方が、後から判断を説明できます。
記事が多いときは、問い合わせ時に案内するもの、古い条件が残っているもの、統合候補があるものから確認すると進めやすくなります。件数を減らすことだけを目標にせず、必要な回答を残し、更新する範囲を決める作業として扱います。
担当者には「必要ですか」より、使う場面を聞く
営業やサポートへ記事一覧を渡し、「残したい記事に印を付けてください」と聞くだけでは、念のため全部残すという答えになりがちです。誰に、どの質問への回答として、どの部分を案内しているかを聞くと、残すべき説明が具体的になります。
例えば、納品後の問い合わせへ送っている記事なら、担当者に最近の使い方を説明してもらいます。記事全体を読んでもらうのか、特定の見出しを見てもらうのか、添付資料を渡すための入口なのかで、必要な部分が変わります。顧客の氏名や相談内容の実データを制作台帳へ載せず、利用場面と案内箇所を要約して記録します。
一人の担当者が「使っている」と答えたときも、現行の対応に合っているかは別に確かめます。便利だから送っているだけで、本文の一部は口頭で訂正しているかもしれません。毎回補足している説明があるなら、残す理由と同時に、書き直す理由も見つかります。
検索以外の入口も確認します。営業資料のQRコード、取引先からのリンク、メールの定型文、製品の案内書などにURLが載っていれば、リニューアル後もその説明へ到達できるかを考える必要があります。単に「外部リンクあり」と書かず、どの資料や案内から来た人が、何を確認しようとしているかまで記録します。
印刷物などすぐに直せない入口は、台帳で分かるようにします。記事の本文を整理することと、案内済みのURLを消すことは同じ判断ではありません。内容を移す場合には、旧入口から必要な回答へ届く方法を、制作側と合わせて検討します。
記事が答える質問と、本文の現在性を分けて読む
次に、各記事が答えている質問を一文で書きます。「会社紹介」「お役立ち情報」という分類名だけでは、何を引き継ぐべきかが分かりません。「相談前にどの資料を用意するか」「納品後にどこへ連絡するか」のように、読者が知りたいことに置き換えます。
その質問が今も必要なら、古い記事にも残す役割があります。ただし、役割があることと、文章をそのまま移してよいことは別です。受付方法、対象サービス、連絡先、手順、写真の説明などを読み、現在の案内に合う部分と確認が必要な部分を分けます。
更新日が古いだけで終了にしない一方、更新日が新しいだけで正しいとも判断しません。日付だけを変更した履歴や、本文の一部だけを直した記事も考えられます。根拠資料と内容を確認する担当者を決め、どの記述が現在の条件と合わないかを具体的に残します。
終了した催しの記事など、過去の記録として意味がある場合もあります。現在申し込める案内と誤認されないよう、終了の事実と対象時期が分かるかを確認します。記録として公開し続ける必要があるか、社内保管で足りるかは別に判断します。記録を保存することが、そのまま現行サイトでの公開を意味するわけではありません。
読まれている記事に誤った条件があれば、入口があるからといって現状維持にはしません。必要な質問への回答は残し、誤解につながる部分を修正する案を検討します。移行作業まで時間が空く場合には、現行ページで先に直す箇所も切り分け、制作の完了待ちで古い案内を続けないようにします。
四つの記事を、判断理由まで含めた台帳にする
以下は、架空のB社が四つの記事を整理する設計例です。URLは説明用の識別子で、実在するページや実測データではありません。閲覧の多寡は判断場面を示す設定であり、削除基準となる数値は置いていません。
| 記事・利用目的 | 入口と現在性の確認 | 処理案と残す説明 | 担当が確かめること |
|---|---|---|---|
| A：納品後の連絡案内／articles/a/ | 閲覧は少ない設定。サポートが案内中。連絡先の現行性を確認 | 残して更新。連絡前に整理する事項を維持 | サポート責任者が案内箇所と窓口を確認 |
| B：見積もり準備／articles/b/ | 検索からの入口がある設定。一部に旧受付条件が残る | 更新して統合先候補にする。必要資料の説明を残す | 営業責任者が現行条件とCから引き継ぐ内容を確認 |
| C：相談前の資料／articles/c/ | Bと同じ質問への回答が中心。独自の説明があるか確認 | Bへの統合候補。相違点を照合してから確定 | 原稿担当が残す節と統合後の掲載箇所を示す |
| D：過去のお知らせ／articles/d/ | 現在の業務用途と外部入口が未確認 | 保留。使われていないとはまだ判断しない | 広報担当が関係部署へ確認し、再判断日を決める |
台帳には、元URLを一件ずつ残します。表では読みやすさのために項目をまとめていますが、実作業では利用目的、参照元、現在性、処理案、根拠、担当、判断日を別々に記録しても構いません。推測で入れた内容には印を付け、担当者の確認結果と混ぜないようにします。
Aは閲覧が少なくても、サポートの回答を支える役割があります。Bは検索入口があっても、古い条件を修正する必要があります。この二つを比べると、閲覧順だけでは「残す・直す」の判断ができないことが分かります。残す理由と修正点の両方が、一つの記事に存在してよいのです。
CをBへまとめる案も、題名が似ているだけでは決めません。BとCが同じ読者の同じ質問へ答えているか、相談の前後など段階が違わないかを確認します。違う質問に答える記事なら、別々に残して相互に案内する方が適切な場合があります。
Dのような未確認記事は、台帳から外すのではなく、保留として残します。「誰も必要と言わなかった」ことと、必要な部署へ確認したうえで用途が見つからなかったことは違います。確認した相手と結果が分かれば、後から同じ調査を繰り返す負担も減らせます。
統合は、残す説明の行き先を決めてから確定する
記事を統合するときは、移動先のURLを一つ選ぶ前に、引き継ぐ回答を確かめます。元記事の見出しごとに、残す説明、更新して残す説明、役割が重なる説明、終了した説明を分けます。全文をつなぎ合わせると、同じ前置きや結論が重なり、読む順番が分かりにくくなることがあります。
BとCの例なら、必要資料の一覧はBにあり、資料がそろわない場合の相談方法だけがCにある、という違いが見つかるかもしれません。この場合、Bへまとめるとしても、CのURLを転送するだけでは足りません。資料不足の相談方法を新しい本文のどこへ置くかを決め、読者が答えを失わないことを確認します。これは説明用の仮定であり、実際には両記事を読んで判断します。
統合後の構成案には、元の見出しと移行先の見出しを対応させます。説明を削る場合は、重複、条件終了、別ページで回答などの理由を添えます。担当者が文章の完成版を確認するときにも、重要な例外条件や補足が落ちていないかを追いやすくなります。
Googleのサイト移転の案内は、内容をまとめたページへの転送と、関連性の低いトップページへの一括転送を区別しています。記事整理でも、元の入口から訪れた人が求める説明を、新しい場所で読めるかを先に考えます。転送の設定方法だけでなく、移行先に何を引き継ぐかを決めることが出発点です。Googleのサイト移転に関する案内
統合が決まった後は、元URL、新しい掲載先、残す内容、公開の順番を制作担当へ渡します。元記事を先に消してから新しい本文を書くのではなく、読める受け皿ができたことを確認して切り替えます。具体的なURLの扱いや転送の検査は、サイトの構成に合わせて別途設計します。
保留を解消し、記事整理の結果を改修範囲へ渡す
保留は確認を続けるための状態です。理由を「不明」だけにせず、「営業資料への掲載を確認中」「終了後も参照する説明があるか確認中」のように書きます。回答する担当と再判断の日を決め、返答がない記事を自動的に終了へ変えない運用にします。
確認が取れたら、処理案と確定した判断を分けて記録します。制作会社が出した統合案を、事業責任者が確認済みの決定として扱わないようにしてください。公開を終了する場合は、現行案内として残す理由がないか、必要な情報を別の場所へ引き継げているか、外部入口への対応が決まっているかを確かめます。
終了候補の記事の原稿や画像を、いきなり作業フォルダから消す必要はありません。移行判断の記録として、必要な範囲を保管するかを決めます。契約や社内規程に基づく保存が関わる場合は、管理担当へ確認します。記事の整理担当だけで、公開終了と原本の廃棄を同時に決めないようにします。
制作会社へ渡す台帳には、残す記事の数だけでなく、更新する本文、統合先へ追加する節、確認待ちの対象を示します。「記事を半分にしたい」という依頼より、どの回答を残すために何を編集するかが分かる方が、原稿作業と画面改修の範囲を見積もりやすくなります。
最後は、よく使う案内元から実際にたどって確認します。サポートの定型文からAの連絡案内を読めるか、Cで答えていた資料不足の相談方法を統合先で見つけられるか、といった利用場面で確かめます。新しい記事一覧が整ったことに加えて、残すと決めた回答が使える場所にあることを、リニューアルの確認項目にしてください。
参照資料：Google検索セントラル「サイトを移転する方法」、Search Console「検索パフォーマンス レポート：概要と基本設定」。2026年9月21日確認。実際の解析データは未取得です。
