公開済みの記事が増えると、「読まれていない記事から消そう」という話が出る。表計算へPVを並べ、少ない順に削れば、在庫は確かに減る。だが、そのやり方では、少数の読者にとって重要な案内、検索にまだ見つかっていない記事、季節が来るまで動かない記事まで同じ列へ入ってしまう。
反対に、「過去の記事も資産だから」と全部を残すだけでは、古い制度や終了した商品、似た答えが並び続ける。読者は、どれが現在の案内か分からない。編集部も、新作をつくるたびに重複を増やす。
コンテンツ監査とは、公開済みのページ、ファイル、動画などを一覧にし、読者の用事と根拠に照らして、次の処理を決める仕事だ。[4] ゴールは記事数を減らすことではない。必要な答えへ読者が迷わず着ける状態をつくり、各ページを残す理由、直す理由、閉じる理由を説明できるようにすることにある。
本稿では、PVだけで決めない五つの証拠と、残す・更新する・統合する・履歴として残す・削除するという五つの処理を整理する。最後に、統合や削除で読者の導線を壊さない実行順まで示す。

コンテンツ監査は、低PV記事を削る作業ではない
監査の最初の成果物は、判定表ではなく在庫表である。URLとタイトルだけでなく、形式、公開日、最終更新日、担当者、添付ファイル、公開状態まで集める。GOV.UKの既存コンテンツ管理ガイドも、これらの項目を出力し、古い情報や壊れたリンクを継続的に確認するよう案内している。[2]
在庫表をつくることと、監査することは同じではない。クロールで集められるのは、何があるかという事実だ。監査ではさらに、誰のどの用事を支えるか、内容は正確か、他の記事と何が違うか、残した場合にどんな影響があるかを読む。
Digital.govの実務者対談には、アクセス解析のデータだけから在庫をつくると、PVが一度もない公開ページやPDFが漏れるという指摘がある。自動点検は、壊れたリンク、SEO、読みやすさ、アクセシビリティなどの優先順位づけには役立つ。しかし、altが存在することと、その説明が画像を正しく伝えることは別である。最終的には記事を読み、読者の必要と組織の目標を人が判断する必要がある。[5]
つまり、低PVは「詳しく見る」ための信号にはなるが、「削除する」という結論ではない。検索表示はあるのにクリックされないなら、タイトルや検索意図のずれかもしれない。内部リンクからしか届かない専門的な案内なら、少ない閲覧でも役割がある。公開直後や季節記事なら、比較期間を変える必要がある。測定漏れなら、PV自体が判断材料にならない。

Inside GOV.UKは、交通分野の7,396件を監査した経験から、全件を同時に扱わず、特定の利用者ニーズ、政策領域、人気度などで小さく分ける方がよかったと振り返っている。[6] 件数の大きさより重要なのは、比較できる単位をつくることだ。
まずURLではなく、読者の用事で束ねる
在庫表の一行ずつを上から判定すると、同じ問いへ似た答えを返すページを見落としやすい。タイトルが違っても、読者が知りたいことと読後の行動が同じなら、重複している可能性がある。逆に、同じ検索語を含んでいても、読者の状況や次の判断が違えば、別の記事として残せる。
そこで、URLを集めた後は「誰が、どんな状況で、何を終えたいか」で束ねる。たとえばオウンドメディアなら、「立ち上げ前に方針を決めたい」「公開計画を組みたい」「公開済み記事を整理したい」は、同じ大テーマに見えても別の用事である。
編集カレンダーの作り方は、公開前の企画へ日付を与える前に、読者の問い、既存記事との差分、制作条件を確認する。本稿の監査は、公開後の在庫を残す・直す・閉じる判断である。表に並べる対象は似ていても、答える問いが違う。
監査表には、少なくとも次の列を置く。
| 列 | 記録すること |
|---|---|
| 基本情報 | URL、タイトル、形式、公開日、最終更新日、公開状態 |
| 読者の用事 | 誰のどんな問いか、読後に何をできるか |
| owner | 事実を確認し、更新・終了を決める人 |
| 根拠 | 一次情報、画像権利、取材素材、確認日 |
| 利用実態 | 検索表示、クリック、内部流入、問い合わせ、読者の反応、集計期間 |
| 重複群 | 同じ問いに答える候補、固有情報、統合先候補 |
| 判断 | 処理、理由、担当、期限、移転先、再確認日 |
GOV.UKの移行ガイドは、よく使われるもの、影響の大きいもの、古いもの、重複を調べる際に、アクセス解析だけでなく、利用者調査、問い合わせ窓口、フォーラムなどを組み合わせる。[1] 表へ数字を増やすのではなく、読者がどこで迷い、何を探し、どの情報を信じたかを同じ行で読めるようにする。
ownerも欠かせない。「要更新」と書いても、誰が制度や商品情報を確かめ、誰が公開状態を決めるかがなければ、監査表は古くなる。監査した日と次回見直し日を入れ、判断を一回限りの棚卸しにしない。
五つの証拠を分けて見る
判定は、一つの合計点だけで自動化しない。評価軸ごとに証拠を残し、その後で処理を選ぶ。CONTEXT編集部では、次の五つへ分ける。

一つ目は、読者の用事である。その記事が解く問いは現在も存在するか。誰が、どの場面で、何を終えたいのか。企業が残したい話ではなく、読者が使う理由を一文で書く。
二つ目は、正確性である。事実、日付、制度、価格、人物の肩書、商品仕様、外部リンクは現行か。誤りがなくても、更新日が古く、現行情報と読み分けられなければ、読者には危険なことがある。
三つ目は、差分である。同じ読者の問いへ、より新しく、詳しく、信頼できる答えを返すページがないか。似たページがある場合は、それぞれにしかない事例、図、取材、出典を洗い出す。固有情報がなければ統合候補になる。固有情報があれば、それを統合先へ移せるかを考える。
四つ目は、利用実態である。検索表示、クリック、平均順位、内部リンク経由の閲覧、ニュースレター流入、問い合わせ、読者の反応を見る。期間と母数を記し、検索に出ていないのか、出ているが選ばれていないのか、読後に別記事へ進んでいるのかを分ける。PV一つでは、問題の場所を特定できない。
五つ目は、義務とリスクである。画像や引用の権利、個人情報、契約上の掲載期間、スポンサー表記、記録保存、訂正履歴を確かめる。読まれていなくても保存が必要なページがある。反対に、よく読まれていても、権利や重大な誤りが未解決なら公開を続けられない。
オウンドメディアの編集方針で扱った公開・修正・見送りの基準は、新規企画だけでなく、公開済み記事の再判断にも使える。ただし、監査ではURLの移転、履歴表示、内部リンクの更新まで処理へ含める。
五軸に赤・黄・緑を付けてもよいが、色だけで結論を出さない。「検索クリックが少ないため削除」ではなく、「読者の用事は別ページで満たされ、このページ固有の根拠はなく、内部流入もなく、現行情報と誤認されるため統合」のように、複数の証拠を理由へ変える。
残す・更新・統合・履歴化・削除を分ける
監査後の処理を「残す/消す」の二択にすると、必要な改善も、履歴としての価値もこぼれる。五つに分けると、判断と実装がつながる。
| 処理 | 選ぶ条件 | 実行すること |
|---|---|---|
| 残す | 用事が現行で、他と差分があり、利用されるか少数でも重要 | ownerと次回見直し日を決め、必要なら内部リンクを補う |
| 更新 | 用事は有効だが、事実、構成、見つけやすさが古い | 同じURLで本文、出典、title、description、画像を直す |
| 統合 | 同じ用事へ似た答えが複数あり、一つで答え切れる | 統合先へ固有情報を移し、内部リンクを直し、旧URLを301する |
| 履歴化 | 現行案内ではないが、過去の経緯や時点資料として価値がある | 日付と履歴表示を付け、現行ページへ案内し、通常の導線から外す |
| 削除 | 有効な用事も保存理由もなく、誤解や権利・法務上の問題が残る | 代替がなければ真正な404、内部リンクとサイトマップを外す |
GOV.UKでは、ページをwithdrawする場合はURLを残し、過去の内容であることを示す。unpublishはページを削除し、必要なら別ページへredirectする。現行の案内が必要なら、原則として既存ページの更新を検討する。[3] 企業メディアでも、終了した調査やイベントレポートを履歴として残す場合と、誤った案内を公開し続ける場合は分けるべきだ。

GSA SmartPayの事例では、560件のページ、動画、文書、図表などを監査し、重複・古い・些末な情報の統合や削減、アクセシビリティ、SEO、一貫性の改善機会を見つけた。結果として主要サイトのコンテンツ量を75%減らし、情報構造も見直した。[7]
ただし、75%を自社監査の目標にしてはいけない。それは対象サイトの利用者調査と監査から生まれた結果であって、よい監査に共通する削減率ではない。先に「半分消す」と決めると、証拠が目標へ従属する。目標は、読者の用事ごとに信頼できる答えを一つへ近づけることだ。
統合先を先につくり、古いURLを最後に閉じる
統合や削除の判断が正しくても、実行順を誤ると読者を失う。旧記事を先に非公開にしてから統合先を書き始めると、検索結果、ブックマーク、外部リンク、記事内リンクの行き先が一時的に消える。安全な順序は次の通りである。
- 統合先のURL、読者の用事、本文構成を確定し、公開できる状態にする。
- 旧記事にしかない事実、図、引用、出典を移し、重複と時点差を整理する。
- サイト内のリンク、一覧、ナビゲーションを統合先へ更新する。
- 明確な代替がある旧URLは301で統合先へ移す。代替がない削除は真正な404を返す。
- 旧URLをサイトマップや通常の一覧から外し、新旧URL、canonical、robots、構造化データを確認する。
- 公開後に検索表示、クリック、内部回遊、問い合わせを同じ期間で見直す。
Google Search Centralは、redirectとrel=canonicalを強いcanonical signal、sitemapを弱いsignalとしている。内部リンクもcanonical URLへ向けるよう勧める。[8] URLを統合しても、内部リンクが旧URLへ向いたままでは、読者も検索システムも余分な経路をたどる。
恒久的に移したなら301を使う。一方、明確な代替がないページを削除するなら、存在しないことを正しく示す404にする。[9] 関係のないページをすべてトップへ送ると、読者は探していた答えを見つけられない。削除とは、古いURLをどこかへ押し流すことではなく、その用事がどこで満たされるか、または満たされないかを明示することだ。
最初から全サイトを監査する必要はない。似た記事が増えた一つのテーマを選び、在庫を集め、読者の用事で束ねる。五つの証拠を記し、五つの処理から一つを選ぶ。統合するなら、行き先を先につくる。判断理由、owner、期限、移転先、再確認日を残す。
監査が終わった状態とは、表の全行に色が付いた状態ではない。読者が現在の答えへ進め、編集部が各ページの次の動作を説明でき、その動作が実際のURLと導線へ反映された状態である。
Sources / 参考資料
2. GOV.UK Publishing:Manage existing content
3. GOV.UK Publishing:Retire outdated content
4. Digital.gov:Content goals
5. Digital.gov:A conversation about content audits
6. Inside GOV.UK:What we learned from a large scale content audit
7. Digital.gov:Delivering on 21st Century IDEA: A case study from the GSA SmartPay team (Part 1)
8. Google Search Central:How to specify a canonical with rel=canonical and other methods
9. Google Search Central:How to get your website on Google Search