古い記事は消すべき？公開日ではなく有用性で仕分ける

公開から3年たった記事が100本たまっている。古いまま置いておくと、サイト全体が引っぱられるのではないか——一括削除に手が伸びる前に、先に結論を書きます。Googleの公式ブログが「取り除かれれば時間とともに改善しうる」と書いている対象は、有用でないコンテンツです。 公開日の古さではありません。

だから、並べ替える軸を変えます。公開日の昇順ではなく、「そのページを何のために作ったか」で並べる。公式が自己評価の観点として挙げているのは、そちら側だからです。

まず、その公式ブログの一文を読みます。取り除くことに触れた文には、条件が2つ付いています。

「取り除けば改善しうる」と書かれた一文の条件

Google 検索セントラルのブログ記事「What creators should know about Google's August 2022 helpful content update」の要約部分に、次の記述があります。

This update, which uses a site-wide signal to identify unhelpful or low-value content（このアップデートは、有用でない、または価値の低いコンテンツを識別するために、サイト全体のシグナルを使います）

サイト全体のシグナル。1ページだけの話として閉じない仕組みだと書かれています。続きはこうです。

Sites identified with large quantities of unhelpful content may see ranking changes, but this can improve over time if unhelpful content is removed.（有用でないコンテンツが大量にあると判定されたサイトは、順位の変化が見られることがあります。ただし、有用でないコンテンツが取り除かれれば、これは時間とともに改善しうる）

「取り除く（removed）」の対象として書かれているのは、有用でないコンテンツです。そして条件が2つ付いています。**大量に（large quantities）**あること。**有用でない（unhelpful）**こと。

ここが仕分けの出発点になります。古い記事が10本あって、それぞれ読者の質問に答えているなら、この文が言っている状況とは形が違います。逆に、去年公開したばかりの記事が80本あって、その大半が同じ話の言い換えなら、公開日が新しくても条件のほうには近づきます。

同じ要約に、避けるべき進め方として「extensive automation（広範な自動化）」や「summarizing without adding value（価値を足さない要約）」が挙げられています。作った量ではなく、作り方と中身が見られている、という書かれ方です。

「有用でない」を自分で測るための観点

とはいえ、「有用でない」は感覚では決められません。判定の手がかりは、Google 検索セントラルの「有用で信頼性の高い、ユーザー第一のコンテンツの作成」にあります。自己評価のしかたとして、次の観点が挙げられています。

assessing its originality, completeness, and value, and consider external feedback（独自性、網羅性、価値を評価し、外部からのフィードバックも考慮する）

独自性、網羅性、価値。この3つは、そのまま棚卸しの採点項目に使えます。さらに、もう一段踏み込んだ観点が続きます。

Focus on who created the content, how it was produced, including any automation or AI usage, and most importantly, why it was created.（誰がそのコンテンツを作ったか、どのように作られたか——自動化やAIの利用を含む——、そして最も重要なのは、なぜ作られたかに注目する）

最も重要（most importantly）と書かれているのは、なぜ作られたかです。同じページには、Googleの自動化されたランキングシステムは、検索エンジンでの順位を操作することを目的に作られたコンテンツではなく、ユーザーの役に立つように作られた有用で信頼できる情報を優先するよう設計されている、という趣旨の説明もあります。

つまり、並べ替えの第一軸は「作った理由」です。「順位を取るため」に作ったページは、公開日が新しくても仕分けの対象に上がります。「読者の特定の困りごとを解くため」に作ったページは、公開日が5年前でも残る側に来ることがあります。公開日は、この軸の代わりにはなりません。

公開日ではなく「なぜ作ったか」で並べ替える6ステップ

100本を3時間で通せる粒度にしてあります。表計算ソフトに1シート作って、上から順に埋めていきます。

1. URLと公開日を一覧にする。 ここではまだ並べ替えません。公開日は「いつの情報が載っているか」を思い出すための手がかりとして持っておくだけで、判定には使わない列にします。
2. 1行で「なぜ作ったか」を書く。 当時の企画意図を、書ける範囲で言葉にします。書けないページ、あるいは「◯◯というキーワードで上位を取るため」としか書けないページには、その時点で印を付けます。ここが一番時間を食いますが、後の判定はほぼこの列で決まります。
3. 独自性・網羅性・価値の3点に○×を付ける。 独自性は「他所を読めば済む話しか書いていないか」、網羅性は「読者がこのページのあとに別のサイトで調べ直すか」、価値は「読み終わって行動が変わるか」で見ます。3点とも×なら、直す候補ではなく外す候補です。
4. 同じ話をしている行をまとめる。 「大量に」という条件に当たるのは、たいてい単体で薄いページではなく、同じ話が形を変えて何本もある状態です。同じ答えを返す行をグループにして、グループごとの本数を数えます。数が出て初めて、片付けの規模が見えます。
5. 残す・直す・外すの3択に振り分ける。 次節の判定表を使います。この時点では、まだ何も削除しません。
6. 「外す」の行だけ、消し方を選ぶ。 恒久的に検索結果から外したいのか、中身を差し替えて生かすのか。手段は後述しますが、選択肢によって作業も反映のされ方も変わります。

工程を分けている理由は、ステップ2とステップ5を同じ日に一気にやると、判断が「面倒だから消す」に寄るからです。理由を書く日と、決める日を分けます。

記事3本に通してみる

実際に3本を通します。仮に、自社のオウンドメディアに次の記事があるとします。

1本目「請求書の書き方【2021年版】」（公開2021年3月）。 ステップ2の「なぜ作ったか」は、「取引先から毎月同じ質問が来るので、送る先の資料として作った」。理由が明確です。ステップ3では、独自性○（自社の記入例が載っている）、網羅性○、価値○。公開日は5年前ですが、判定は残す。ただし年号の表記と法令まわりの記述だけ、確認が要ります。

2本目「経費精算とは？意味と基本を解説」（公開2023年8月）。 理由の欄には「関連キーワードで上位を取るため」としか書けませんでした。ステップ3は、独自性×（一般的な定義の説明のみ）、網羅性△、価値×。ステップ4で、同じような入門解説が他に9本あることが分かりました。公開日は3年前で、100本のうちでは新しいほうです。それでも判定は外す側。9本まとめて1本にできるなら、そちらが優先されます。

3本目「クラウド会計ソフト比較」（公開2020年11月）。 理由は「導入検討中の読者に選び方を渡すため」。独自性○（自社での検証結果が入っている）、網羅性×（比較対象が当時の3製品のまま止まっている）、価値△。判定は直す。ここで消してしまうと、独自性の部分——検証結果——まで一緒に消えます。

3本並べると、公開日の順番（2020年→2021年→2023年）と、判定の順番がまったく一致していないことが見えます。並べ替えの軸を公開日から作った理由へ移すのは、このズレを消すためです。

残す・直す・外すの判定表

ステップ5で使う表です。左から順に見て、最初に当てはまった行を採用します。

2本目の記事は5行目に当たりました。ただし同時に4行目にも当たっています——同じ入門解説が10本あるからです。この場合は上の行が先に来るので、まず4行目の「1本に寄せる」を実行し、寄せきれなかった9本を外す側に送る、という順序になります。表を上から見るのは、この順序を毎回同じにするためです。

3本目は2行目です。独自性のある検証結果が残っているうちは、外す側には来ません。

「外す」を選んだときの手段

ここからは消し方の話です。Google 検索セントラルの「Google から情報を削除する」に、手段が整理されています。

use the Removals tool for temporary, quick removals within a day. For permanent removal, remove or update the content, password-protect the page, or add a noindex tag, avoiding robots.txt. Protect all URL variations.（1日以内の一時的で素早い削除には削除ツールを使う。恒久的な削除には、コンテンツを削除または更新する、ページをパスワード保護する、または noindex タグを追加する。robots.txt は避ける。すべてのURLのバリエーションを対象にする）

読み取れることが3つあります。

ひとつめ。削除ツール（Search Console の「削除」）は、1日以内の一時的で素早い削除のための道具として説明されています。棚卸しで100本を片付ける用途とは、置かれている文脈が違います。

ふたつめ。恒久的に外すときの選択肢は3つ。コンテンツを削除または更新する／パスワード保護する／noindex タグを追加する。「更新する」がこの並びに入っているのが要点です。外すと決めたページでも、中身を差し替えて生かす道が同じ列にあります。

みっつめ。robots.txt は避ける、と書かれています。塞げば消えると考えて robots.txt に書き足すのは、ここで案内されている手段ではありません。

そして「すべてのURLのバリエーションを対象にする」。これが抜けやすいところです。削除ツールのヘルプには、対象URLの一致について次の例が挙げられています。

So http://m.example.com/mypage does not match（したがって http://m.example.com/mypage は一致しません）

同じ記事に別のアドレスからも届く形になっているなら、そちらも一緒に処理する必要があります。

大量に消す前に確認する4点

片付けを実行する日の直前に見るところです。

1. 404 を返す形になっているか。 削除ツールのヘルプには「To clean up cruft, like old pages return 404（不要物の片付け、たとえば古いページには 404 を返す）」と書かれています。片付けの手段としてここで案内されているのは、ツールではなく 404 のほうです。
2. 空のページや「削除しました」だけのページを返していないか。 「HTTP ステータス コードが Google 検索に与える影響」に、コンテンツが Google 検索にとってエラーを示す場合——空のページやエラーメッセージ——Search Console は soft 404 エラーを表示する、と書かれています。削除したつもりで、中身のないページを普通に配信している状態がこれに当たることがあります。
3. クロールの頻度を心配して手を止めていないか。 同じページに、429 を除く 4xx のステータスコードはクロール率に影響しない（have no effect on crawl rate）と書かれています。心配の対象がクロール頻度なら、ここは根拠になります。ただし書かれているのはクロール率についてであって、順位の話ではありません。
4. 急ぎの理由が「検索結果の説明文を消したい」ではないか。 削除ツールには、検索結果のスニペット（説明文）を消す機能も説明されています。次にインデックスされるまでのあいだ説明文が消え、再びインデックスされたときには新しい内容から生成される、という書かれ方です。誤った説明文がいま表示されている、という状況ならこちらが近い手段になります。

3番目は、実際にはブレーキとして効きます。「404 を大量に出すとクローラーに嫌われるのでは」という心配で棚卸しが止まることが少なくないためです。

片付けたあとに見るもの

外した効果は、消した直後の数字には出ません。公式ブログの一文も「over time（時間とともに）」という言い方でした。改善しうる、という書かれ方であって、外せば必ずそうなると保証されているわけではありません。

見る対象を1つに絞るなら、消したページの数ではなく、残したページの検索での表示回数です。有用でないコンテンツを取り除くことが効いているなら、その変化は残したページ側に出るはずだからです。ただし、順位や検索需要そのものの変動も同時に起きるので、上下の原因を1つに決めつけないでおきます。

そして、棚卸しは1回で終わりにしないほうが結局は速くなります。100本を一度に仕分けるより、四半期ごとに新しく増えた分だけステップ2の「なぜ作ったか」を書いておくほうが、次の棚卸しで一番時間を食う列がすでに埋まっているからです。

どの記事から手を入れるかで迷ったときは、既存記事のリライトはどこから？優先順位のつけ方も参考にしてください。削除後に Search Console へ並ぶ 404 の扱いは、404エラーは放置していい？対処が要るURLだけ選び分けるでまとめています。