不動産ブログの重複記事を救う7ステップ｜削除・統合・全面改稿の判断基準

「同じテーマの記事を公開してしまった。新しい記事を追加すべきか、既存記事を直すべきか」

不動産ブログを継続していると、こうした判断に迷う場面が増えてきます。とくに「空室対策」「収益物件」「不動産投資」などは検索意図が重なりやすく、記事を増やすだけでは成果につながりません。

結論からいうと、同じ読者の同じ悩みに答える記事がすでにあるなら、まず検討すべきは既存記事の全面改稿です。一方、対象読者、判断内容、読後の行動が明確に異なるなら、新規記事として分ける価値があります。

この記事では、不動産ブログの重複記事を「削除」「統合」「全面改稿」「新規作成」のどれに振り分けるべきか、実務で使える7つのステップに分けて解説します。

最終的には、次の3点を記録した改稿台帳を作ることが目標です。

1. 残すURL
2. 統合または廃止するURL
3. 判断根拠となる検索データと検索意図

まず理解したい「技術的な重複」と「検索意図の競合」の違い

重複コンテンツを扱う際は、技術的な重複と、記事同士の検索意図の競合を分けて考える必要があります。

URLだけが異なる技術的な重複

ほぼ同じ内容を、複数のURLで表示できる状態です。

• HTTP版とHTTPS版
• パラメータ付きURL
• PC版とモバイル版
• 印刷用ページ
• 同じ記事を複製したページ

Googleは、サイト内に一部の重複ページがあること自体をスパム違反とはしていません。ただし、同じ内容のURLが複数ある場合は、その中から代表となる「正規URL」を選択します。

管理者側から希望する正規URLを伝える主な方法は、次の3つです。

Googleは、リダイレクトとrel="canonical"を強いシグナル、サイトマップへの記載を弱いシグナルと説明しています。ただし、いずれも命令ではなく、最終的な正規URLはGoogleが判断します。

出典：Google Search Central「rel=“canonical” などを利用して正規 URL を指定する方法」

内容と検索意図が似ている記事同士の競合

もう一つ注意したいのが、別の記事でありながら、同じ読者の同じ疑問に答えている状態です。

たとえば、次の2記事は競合する可能性があります。

• 「賃貸物件の空室を減らす10の方法」
• 「大家が今すぐできる空室対策」

タイトルが違っていても、対象読者、悩み、結論、読後の行動がほぼ同じなら、検索エンジンだけでなく読者も「どちらを読めばよいのか」を判断できません。

ただし、順位変動や複数URLの表示だけで競合と断定するのは危険です。季節性、検索需要、端末、地域、競合サイトの更新、Google側の変化なども影響するため、検索データと記事内容の両方を確認します。

ステップ1：既存記事と新規案を一覧にする

最初に、感覚ではなく表で比較します。

最低限、次の項目をスプレッドシートへ記録してください。

タイトルやキーワードが似ているだけでは、統合の根拠として不十分です。

各記事について、次の文章を1文で完成させます。

この記事は、【対象読者】が【悩み】を解決し、読後に【判断または行動】できるようにする記事である。

2記事の文章がほぼ同じになった場合は、統合または全面改稿の有力候補です。

ステップ2：Search Consoleで競合の兆候を調べる

Google Search Consoleの「検索結果」レポートを開き、次の順番で確認します。

1. 日付を「過去3か月」に設定する
2. 「クエリ」タブを開く
3. 対象キーワードを選択する
4. 「ページ」タブへ切り替える
5. 同じクエリで表示されたURLを確認する
6. クリック数、表示回数、CTR、平均掲載順位を記録する
7. 「比較」から直前の期間または前年同期と比べる
8. CSVまたはGoogleスプレッドシートへ書き出す

Googleの検索パフォーマンスレポートでは、クリック数、表示回数、CTR、平均掲載順位を確認できます。また、検索結果は検索した時間、場所、端末、ユーザーの履歴などで変わるため、自分で検索した順位とSearch Consoleの値が一致するとは限りません。

出典：Search Console ヘルプ「検索パフォーマンス レポート」

改稿や統合を検討する兆候

同じクエリに対して複数のURLが表示されていても、それだけで問題とは限りません。次の状態が複数当てはまる場合に、統合や改稿を検討します。

• 表示されるURLが期間ごとに入れ替わる
• どちらの記事も十分なクリックを獲得できていない
• 2記事の対象読者、悩み、結論がほぼ同じ
• 内部リンクでどちらを優先すべきか決められない
• 一方の記事が古く、独自情報も少ない
• 問い合わせや資料請求への導線が重複している
• 被リンクや内部リンクの評価が複数URLへ分散している

視覚証拠として残すもの

改稿前の状態を後から検証できるよう、次の証拠を保存します。

• Search Consoleの期間設定が見える画面
• クエリ別・ページ別の比較画面
• エクスポートしたCSV
• 改稿前の記事全文またはPDF
• 内部リンク元の一覧
• 正規URLを確認できるURL検査結果

スクリーンショットには取得日、対象期間、フィルタ条件が分かるようにします。数値だけを転記すると条件が失われ、再検証できなくなるためです。

ステップ3：「改稿・統合・新規作成」を決める

判断は、次の4つの選択肢に分けます。

既存記事を全面改稿する

次の条件に該当する場合は、既存URLを残して内容を更新します。

• 新規案と既存記事の検索意図が同じ
• 既存記事に検索流入や被リンクがある
• URLやテーマに大きな問題がない
• 情報不足や古さが主な課題である
• 独自データや事例を追加できる

2記事を統合する

次の条件なら、内容の強いページへ一本化します。

• 2記事の対象読者と結論がほぼ同じ
• 両方とも情報量が少ない
• 一方にしかない有用な事例やデータがある
• 読者が2記事を読む必要性を説明できない
• 内部リンクや被リンクが分散している

統合後は、不要になったURLから残すURLへ恒久的なリダイレクトを設定します。内部リンク、サイトマップ、canonicalも同じURLを指すように統一してください。

新規記事として分ける

対象読者や最終判断が異なる場合は、別記事として公開できます。

たとえば、同じ不動産データ活用でも、次の2記事は役割が異なります。

「扱うキーワードやデータが違う」だけでは不十分です。対象読者、判断内容、読後の行動まで分けます。

削除する

次の条件を満たし、統合できる有用な情報もない場合は、削除を検討します。

• 検索流入がほとんどない
• 被リンクがない
• 内容が古く、更新する価値が低い
• サイトの現在の事業や読者層と関係がない
• 他の記事へ移すべき独自情報がない

削除後に代替ページがある場合は、そのページへリダイレクトします。関連性の低いページへ機械的にリダイレクトするのは避けてください。

判断記録の例

ステップ4：既存記事に一次情報を追加する

全面改稿で最も重要なのは、文字数ではありません。そのサイトでしか確認できない情報を増やすことです。

追加候補には、次のようなものがあります。

• 実際に使用した調査条件
• データの取得日時
• 対象エリアと物件数
• 除外したデータと理由
• 作業時間
• 成功件数と失敗件数
• エラーログ
• 改稿前後の検索データ
• 判断が外れた事例
• 手作業と自動化の所要時間比較
• 管理画面や現地確認のスクリーンショット
• 担当者が判断を変更した理由

Googleも、有用なコンテンツを自己評価する観点として、独自の情報、レポート、研究、分析、明確な情報源などを挙げています。

出典：Google Search Central「有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成」

実行ログの記録形式

以下は書式の例です。数値は仮のサンプルではなく、必ず実在する記録へ置き換えてください。

実行日時：
担当者：
対象エリア：
対象データ：
取得件数：
正常処理件数：
除外件数：
除外理由：
処理時間：
照合件数：
照合方法：
不一致件数：
判明した限界：
証拠ファイルの保存場所：

数字には必ず分母と条件を付ける

「精度98％」「作業時間を半減」といった数字だけでは、再現性を判断できません。

最低でも、次の情報をセットで示します。

• 母数
• 対象期間
• 対象エリア
• 除外条件
• 計算式
• 比較対象
• 誰が確認したか
• 不一致をどう扱ったか

たとえば「50件を照合し、48件が一致したため一致率96％」と書けば、読者は検証規模と計算方法を確認できます。

ステップ5：読者が実行できる本文へ書き換える

初心者向けの記事では、操作手順だけでなく、各工程の完了条件を示します。

「競合記事を確認する」だけでは、何をもって完了なのか分かりません。次のように具体化します。

1. Search Consoleで対象クエリを選ぶ
2. 表示URLをCSVへ書き出す
3. URLごとにクリック数、表示回数、CTRを記録する
4. 各記事の対象読者と結論を1文で書く
5. 同じ結論の記事に印を付ける
6. 残すURLと統合する内容を決める
7. 判断日と担当者を記録する

完了条件は、次の3点が一つの表にまとまっていることです。

• 残すURL
• 統合対象
• リダイレクト対象

見出しは検索者が知りたい順番に並べる

キーワードを繰り返すだけでは、記事の価値は高まりません。検索者が判断しやすい順番で構成します。

H1：主題＋読者が得られる結果
導入：悩み、結論、この記事で分かること
H2：前提知識
H2：判断基準
H2：具体的な手順
H2：一次情報または事例
H2：失敗例と対策
H2：効果測定
H2：限界と注意点
H2：次に取る行動

専門家向けの確認項目も用意する

• 出典と取得日を確認できるか
• 調査条件と除外条件が明記されているか
• 成功例だけでなく失敗例も示しているか
• 不動産価格、利回り、法令を断定しすぎていないか
• AI生成文に未検証の数値や制度説明が混ざっていないか
• 著者や監修者の経験を確認できるか
• 更新日だけでなく、更新内容が記録されているか
• 読者が次に取る行動が明確か

ステップ6：リダイレクト・canonical・内部リンクを整える

本文を統合しただけでは、作業は完了していません。検索エンジンと読者が同じURLへ到達できるよう、技術設定もそろえます。

統合時のチェックリスト

• 旧URLから残すURLへ恒久的なリダイレクトを設定した
• 残すページのcanonicalが自己参照になっている
• 旧URLを指す内部リンクを残すURLへ変更した
• XMLサイトマップから旧URLを外した
• パンくずリストを更新した
• 構造化データ内のURLを更新した
• OGPや共有用URLを確認した
• URL検査でGoogleが選択した正規URLを確認した
• リダイレクトループや多段転送がないことを確認した
• 旧URLの被リンクを可能な範囲で把握した

canonicalを統合の代わりに使わない

記事を廃止して完全に一本化する場合は、原則としてリダイレクトを使います。

rel="canonical"は、類似ページを残す必要がある場合に代表URLを示す仕組みです。内容や目的が異なる記事へcanonicalを向けても、適切に処理されるとは限りません。

また、次のような矛盾を作らないようにします。

• リダイレクト先とcanonical先が異なる
• サイトマップに旧URLが残っている
• 内部リンクが旧URLを参照している
• 正規ページから旧URLへリンクしている

ステップ7：公開後のKPIを同じ条件で測定する

改稿は公開して終わりではありません。公開前の数値を保存し、同じ条件で比較します。

最低限記録するKPI

• クリック数
• 表示回数
• CTR
• 平均掲載順位
• 表示された対象クエリ数
• 自然検索からの閲覧数
• 問い合わせや資料請求などのコンバージョン
• 表示されるURLの安定性
• 記事内リンクのクリック数

初期の確認時期は、公開後7日、28日、90日を目安にします。ただし、検索需要が少ないテーマでは28日でも判断材料が足りません。

比較条件をそろえる

比較時には、次の条件を可能な限り統一します。

• 比較期間の日数
• 曜日の構成
• 検索タイプ
• 国とデバイス
• ブランドクエリの扱い
• 季節性
• 大型連休や繁忙期
• 広告やSNS施策の有無

変化別の確認ポイント

「順位が上がらなければ失敗」と単純化してはいけません。表示されるクエリが増えた結果、平均掲載順位が下がることもあります。クリック数、表示回数、コンバージョンを合わせて判断してください。

よくある失敗と対策

記事を統合したのに旧URLを残している

内容を移しただけでは、旧ページへ読者や検索エンジンが到達する状態が続きます。

対策： 旧URLから残すURLへリダイレクトし、内部リンクとサイトマップも更新します。

タイトルだけ変更して全面改稿と呼んでいる

検索意図への回答、一次情報、手順が変わらなければ、読者にとっての価値はほとんど増えません。

対策： 「何を追加したか」「どの疑問を解決できるようになったか」を改稿前後で比較します。

独自データを載せたが検証方法がない

件数や成功率だけを示しても、対象範囲や除外条件が不明では再現できません。

対策： 取得日、対象、母数、除外条件、計算式、照合方法をセットで記載します。

成功事例しか掲載していない

成功例だけでは、その方法が使えない条件や失敗時の損失を判断できません。

対策： 判断が外れた事例、検出できなかったデータ、適用できない物件種別も記録します。

すべての記事を1ページへまとめる

統合しすぎると、異なる読者の目的が混在し、必要な情報を探しにくくなります。

対策： 対象読者、判断内容、読後の行動のいずれかが明確に異なる場合は、別記事として役割を持たせます。

「重複記事はすべて削除すべき」という考え方への反論

似た記事が複数あるからといって、必ず削除すべきとは限りません。

「大家向けの空室改善」と「不動産会社向けの募集業務改善」は、同じデータを扱っていても目的が異なります。また、「概要を知りたい人」と「実際に設定したい人」では、必要な情報量や読後の行動も違います。

重要なのは、各記事の存在理由を1文で説明できることです。

説明できない場合は統合候補です。説明できる場合は、タイトル、導入、見出し、内部リンクで違いが伝わるようにします。

この方法の限界

Search Consoleのデータだけで、記事同士の競合や改稿効果を完全に証明することはできません。

• 検索需要や競合状況も同時に変化する
• 表示回数が少ないクエリでは判断が安定しない
• すべての検索クエリがレポートへ表示されるとは限らない
• 順位や表示URLは地域、端末、時期などで変わる
• 改稿と同時に内部リンクやサイト構成を変えると、要因を分離しにくい
• 検索流入が増えても、問い合わせの質が上がるとは限らない

そのため、改稿前のデータ、変更内容、公開日、技術設定を記録し、単一の指標ではなく複数のKPIで判断します。

まとめ：新規記事を書く前に、既存記事の役割を確認する

重複コンテンツ対策で最初に行うべきことは、記事を削除することでも、canonicalを設定することでもありません。

まず、既存記事と新規案について、次の3点を比較します。

1. 誰が読む記事か
2. どの悩みを解決するか
3. 読後に何を判断・実行できるか

3点が同じなら、既存記事の全面改稿または統合を優先します。異なるなら、新規記事として役割を分けます。

統合する場合は、本文だけでなく、リダイレクト、canonical、内部リンク、サイトマップまで確認してください。また、一次情報を追加するときは、見栄えのよい数値を作るのではなく、取得条件、母数、除外条件、失敗例、視覚証拠を残します。

最初の一歩は、公開済み記事のURLを一覧にし、Search Consoleから過去3か月分のクエリ別・ページ別データを書き出すことです。

まずは競合が疑われる2記事だけを選び、次の1文を書いてみてください。

この記事は、【対象読者】が【悩み】を解決し、読後に【判断または行動】できるようにする記事である。

2記事の答えが同じなら、次に書くべきものは新規記事ではなく、既存記事の改稿計画です。