古いブログ記事を消すか残すかで迷うと、残すほうに倒れやすいです。消すのは怖いですからね。ただ、誰にも読まれず、今の自分も勧めたくない記事がずっと残っているなら、一回ちゃんと見たほうがいいです。
削除判断は、いきなり消す話ではありません。先に残す理由を探します。検索から読まれている。内部リンクの受け皿になっている。今は検索流入がなくても、自分の経験が入っている。このどれかがあれば、私はすぐには消しません。
消す前に、まず残す理由を探します
古い記事を見ると、最初に「消すかどうか」を考えがちです。でも、その順番だと怖くなって終わります。先に見るのは、残す理由です。Search Consoleで内容に関連する検索語から表示されている。別記事から自然にリンクされている。昔の作業ログとして自分の経験が残っている。こういう記事には、まだ役目があります。
逆に、残す理由が「もったいない」だけなら危ないです。書いた時間は確かにもったいない。でも、読者は書いた時間を読みに来ていません。今読んで役に立つか、別の記事へ自然につながるか、残すことでサイトの説明が増えるか。このどれかで見ます。
似た記事があるなら統合を見ます
どれもない記事は、次に統合できないかを見ます。たとえば「SEOとは」と「SEO対策とは」が別々に薄くあるなら、片方へ寄せたほうが読みやすいです。似た記事が2本ある状態は、書き手側では管理しやすく見えても、読者側では選ぶ手間になります。
統合するときは、検索意図が近い記事を選びます。タイトルの言葉が似ていても、読者の用事が違うなら統合しません。「SEOタイトルの付け方」と「記事タイトルとは」は近く見えますが、前者は直し方、後者は意味を知りたい記事です。ここを混ぜると、残した記事の入口がぼやけます。
統合先へ移すものを決めます
統合は、古い記事をまるごと貼り付ける作業ではありません。残す記事に移すのは、古い記事にしかない経験、具体例、注意点です。定義や一般論をそのまま移すと、残す記事まで重くなります。古い記事の中で、今読んでも使える部分だけを移します。
ここで全部移したくなるなら、まだ整理できていません。残す記事の読者が必要とするものだけ移します。たとえば、古い記事に「設定画面で迷った場所」が書いてあるなら残す価値があります。反対に「SEOでは質が大切です」のような一般論は、移さなくていいです。
本当に消すのは、読者に出したくない記事です
削除候補にするのは、今の読者にそのまま出せず、更新しても救えない記事です。古い手順でも、今の画面に合わせて直せるなら更新します。近い記事へ経験や具体例を移したほうが分かりやすいなら統合します。誤解を直せず、適切な統合先もないときに、初めて削除候補です。
たとえば、終了したサービスの手順をそのまま残している記事。今は使えない画面を、現在の手順のように説明している記事。昔の自分の理解が浅く、今なら勧めない方法を書いている記事。こういうものは、残す理由を探すより、読者へ出し続けるリスクを見たほうがいいです。
消す前にリンクを見ます
削除候補にした記事でも、すぐ消しません。内部リンクが集まっているなら、先にリンク先を変えます。内容を移した明確な代替ページがあるなら301リダイレクトで案内します。代替先がないのにトップページへ飛ばすのは、読者の用事を別の場所へすり替えるだけです。その場合は404または410を返します。これはGoogleのクロールエラー対応でも示されている分け方です。
リンクを見ずに消すと、別の記事の中に古い穴が残ります。「詳しくはこちら」と書いてあるのに、飛んだ先がなくなる。これは読者にも自分にも面倒です。削除は掃除に見えますが、リンクの付け替えまでやって初めて掃除になります。
削除候補のメモには、感情ではなく理由を書きます。「古いから」では足りません。「現行画面と違う」「統合先に同じ説明がある」「読者に今は使えない手順を渡す」のように書きます。ここまで書けると、後から見返したときに削除判断を戻すかどうかも考えやすいです。
削除候補にする前に、順番を固定します
1本だけ開いて、読者にとって有効な残す理由をひとつ書けるか見てください。書けるなら残す。書けなくても、今の読者に合わせて修復できるなら更新する。修復より、近い記事へ経験や具体例を移すほうが分かりやすければ統合する。統合先もなく、誤解を直せないなら、そこで初めて削除候補にします。
最後に、削除ボタンを押す前の確認です。その記事を残す理由はない。修復できない。読者が同じ用事を済ませられる統合先もない。この3つがそろったら削除候補にします。修復できるなら、リライトのタイミングから見直せます。4つの選択肢を見渡すなら、古い記事の判断順へ戻れます。
コメント