昨年書いた記事の検索流入が減ると、同じテーマで新しい記事を書くべきか迷います。一方、既存記事を直すと検索順位が下がるのでは、と心配になることもあります。しかし、記事の古さだけでは、どちらが有利か決められません。
既存記事が答えていた質問が今も同じなら、まず修正を検討し、読者が解決したいことが変わったなら、新しい記事を検討します。私は公開日より先に、「この記事を読んだ後、読者は何ができるべきか」を1文で書きます。その文が同じなら、新しいURLをもう1つ作る理由が十分にあるかを、改めて考えます。
1. 維持・修正・統合・新規作成の4つに分ける
「新しく書く」と「修正する」だけで考えると、そのままでよい記事まで変えがちです。まず既存記事を4つの状態に分けてみてください。次の表はGoogleのランキングの算定式ではなく、コンテンツ編集のための判断基準です。
| 選択 | 判断基準 | 説明用の例 |
|---|---|---|
| 維持 | 質問と答えが今も有効で、明確な不足がない | 製品の単位換算の方法と計算例 |
| 修正 | 中心の質問は同じだが、画面・手順・条件・根拠が変わった | メニューが変わったツールの使い方 |
| 統合 | 複数の記事が同じ質問に答え、それぞれ固有の情報が散らばっている | 2記事に分かれている同じ退会手順 |
| 新規作成 | 読者の目的や適用対象が違い、別の説明が必要 | アカウントの作成方法と、複数社員の権限設計 |
1つのテーマに複数の記事があること自体は、問題ではありません。「議事録の書き方」と「会議で決まったことを追跡する方法」は関連しますが、読む目的は違います。前者を読んだ人がすぐ後者を必要とするなら、リンクでつなげられます。同じ単語が多いかより、読後の行動が違うかを見る方が的確です。
2. 検索語より、読者が終えたい作業を比較する
例えば、既存記事に「ニュースレターのUTMを作る方法」があるとします。新しい候補は「2026年版・ニュースレターのUTM設定方法」です。年が変わっただけで読者がしたいことは同じ、必要な設定もほぼ同じなら、既存記事を直す方が自然です。一方、「ニュースレターからの流入は見えるのに、購入が計測されない理由」は、リンク作成後の測定の問題なので、別記事にできます。
迷うときは、既存記事のタイトルを隠して、最初の段落、見出し、例、最後に促す行動を読んでみてください。新しい記事の目次と大半が重なるなら、本当に違う質問を扱っているかを疑う必要があります。タイトルの言葉だけ変えても本文が同じになる記事なら、読者が2本とも読む理由は弱くなります。
Search Consoleにデータがあれば、そのページがどんな検索語で表示されるかも確認します。コメント、問い合わせ、社内で繰り返される質問も手掛かりです。ただし、検索語が1つ見つかったからといって、別記事を作る必要はありません。短い1段落で答えられるなら、既存記事に加えた方が読者にとって便利な場合もあります。
3. 修正は、読者の作業が止まる箇所から始める
修正は、表現を整えたり分量を増やしたりするだけではありません。読者が記事どおりに操作したとき、今の画面で同じ結果を得られるかを先に確認します。ツールの使い方なら、メニューの場所、アカウントの条件、無料・有料の範囲、保存後の確認方法を調べます。製品説明なら、機能や対応範囲が現在も正しいかを見ます。
架空の下書きが「設定で接続ボタンを押せば完了です」で終わっているとします。読者が成功したか確認できないなら、「接続状態の画面で対象アカウント名を確認し、テスト項目が1つ正常に表示されるかを確かめる」といった段階が必要です。具体的なメニュー名は、実際のツールで確認したものを書きます。このように不足する手順を補う修正は、単なる言い換えとは違います。
私は修正項目を、事実の誤り、説明の不足、読みにくい構造に分けます。誤った機能説明を直す方が、接続詞の変更より先です。中心となる答えが導入の後ろに埋もれていれば、順番も変えます。十分に説明されている部分を、むやみに長くはしません。Googleのユーザーを第一に考えたコンテンツのガイドも、読者が目的を達成するのに十分な助けを得られるかを確認し、実質的な変更なしに日付だけを変える方法を避けるよう促しています。
4. 似た記事をまとめる前に、それぞれ固有の役割を確認する
タイトルが似ているからといって、閲覧数の少ない記事を削除しないでください。一方は初心者向けの始め方、もう一方はすでに運用している人のエラー解決かもしれません。後者の流入が少なくても、業務上重要な質問に答えているなら、残す理由があります。
統合候補の2記事を並べ、共通の答えと、それぞれにしかない内容を印で区別します。実際の手順は同じで、違いが古い画面だけなら統合できます。一方、異なる料金プランや製品バージョンの説明なら、1記事に混ぜることで読者が自分の条件を誤解しないかも確認する必要があります。
Googleの正規URLのガイドは、重複または非常によく似たページの代表URLを伝える方法を説明しています。「テーマが少し似ていれば、必ず1記事にまとめる」という意味ではありません。統合は、読者がより十分な答えを得られるときに選びます。クリックが少ない記事を消せばサイト全体の順位が上がる、といった一律のルールにはしません。
統合する記事を決めたら、残すURLと内容の基準も記します。流入だけでなく、既存の共有リンク、説明の充実度、今後も扱うテーマを見てください。本文をそのままつなぐと、導入の重複や条件の食い違いが残りがちです。共通の説明は1回にし、それぞれの固有の例を適切な位置へ移します。その後、元の2記事を知る読者が、どちらのURLから来ても必要な答えにたどり着けるかを確認します。
5. 本文の修正とURLの変更は、別々に判断する
同じ質問への記事を直すなら、既存URLの維持を基本として考えられます。タイトルの表現を変えたからといって、URLまで変える必要はありません。読者が保存したリンクや、ほかの記事からのリンクが同じ説明につながり続ける方が、管理もしやすくなります。
2記事を1つにまとめて元のURLを1つなくすなら、そのURLの移動先まで決める必要があります。単にトップページへ送らず、記事を代替する関連ページを選びます。恒久的に移動する場合は、Googleのリダイレクトガイドに沿って、301や308などの恒久リダイレクトを検討できます。使っているプラットフォームでの設定方法は、別途確認してください。
通常の修正では、公開日と更新日も区別します。最初の公開記録を残し、実質的に変更した日を更新日として示すと、読者は記事の履歴を理解しやすくなります。「料金と画面例を現行の内容に更新」といった短い記録も役立ちます。画面と構造化データの両方に日付を示す場合、内容を一致させる必要があることは、Googleの日付表示ガイドで確認できます。
年ごとの記録自体が重要な記事は例外です。昨年のイベント報告や特定年の調査結果を今年の内容で上書きすると、過去の記録を探す読者が混乱します。元の時点の記録として残し、新しい調査やイベントの記事を別に作って、互いをつなぐ方が適しています。
6. 修正前の問いと、修正後の確認基準を残す
作業前に、URL、中心の質問、問題点、修正範囲、確認する結果を書いておいてください。例えば「登録案内の画面が変わり、手順3を実行できない。実際の画面へ差し替え、別の担当者が最初から完了できるかを確認する」なら、検証基準が明確です。検索クリックが増えていなくても、案内の正確さはすぐに確認できます。
対象が多い場合は、全記事を同じ日に見ようとせず、誤った情報が残る記事と、よく共有される記事から一覧を作ります。単に古い順より、読者が誤った判断をしたり、作業を中断したりする可能性が高い順が有用です。次の確認日と担当者も記録すると、同じ問題が起きた際に最初から調べ直す負担を減らせます。
検索成果は、別の時間軸で見ます。修正版が正常に開くか、関連する内部リンクや必要な設定が保たれているかを確認した後、検索語、クリック、読者の次の行動を観察します。Googleの再クロールのリクエストガイドによると、依頼しても直ちに検索へ反映されたり、必ずインデックス登録されたりするわけではありません。同じURLへのリクエストを繰り返しても、処理は速くなりません。
1日、2日のクリック変化で成功・失敗を決めず、もともとの流入規模とテーマの季節性を踏まえて比較期間を定めます。複数の修正を同時に行ったなら、どれか1つの効果とは断定しにくいことも記録してください。次の編集会議では「今週は新規記事を何本作ったか」に加え、「既存記事で読者がつまずいていた問題を何か1つ解決できたか」も見てはどうでしょうか。新規作成と修正は、その問題を解決するための選択肢です。