同じ会社の重複ページをまとめる手順

同じ会社のページが複数あると分かったら、同一法人かを確認し、情報を統合して残すURLを決め、廃止するURLから転送します。ページを一つ消すだけでは、元データの再取り込みで重複が戻ります。

最初に、二つのURLと掲載内容を並べてください。どの資料のどの記録から作られたかを確かめ、残すページへ移す情報と、古いまま残してはいけない情報を分けます。

会社名の表記ゆれや法人番号で同じ会社を見つける手順は会社名の名寄せ⁠にまとめています。ここでは、同じ会社と確認できた後の、公開ページの統合を扱います。

本当に同じ会社か

名前が同じだからといって、すぐ転送しません。会社の正式名、法人番号、所在地、公式サイトを照合します。自動判定だけで統合すると、別法人の数字が一つの会社へ付くおそれがあります。

製造業のデータなら、本店と工場の住所で別々に登録されていることがあります。支店名が付いている記録と、会社名だけの記録もあります。会社の紹介を重複して作ったのか、工場ごとの情報を意図して作ったのかを先に確認します。

同じ法人でも、工場ごとに設備を紹介するページなら、それぞれに読む理由があります。会社の紹介ページへ関係をつなぐ作業と、重複ページを廃止する作業を区別してください。

判断を保留した組は、公開URLを変えず、根拠を確認する列へ戻します。推測の転送を先に入れて、後から本文を調べる順にはしません。

残すURLをどう選ぶ？

これからも同じ会社の情報を載せ続けられるURLを選びます。名前が変わるたびに新しいURLを作る運用なら、重複の解消だけでなく、会社とURLの結び方も見直します。

選ぶときは、今どこから案内されているかを調べます。サイト内の一覧、外部資料のリンク、Search Consoleで表示されているURLを確認します。片方が古いから自動的に残す、クリックが少ないから消す、といった単独の条件では決めません。

片方のURLへ情報が集まっていて、今後も使えるなら、そこへまとめると変更箇所を減らせます。両方とも不安定な命名なら、新しいURLが必要かを検討します。ただし、統合に不要なURL変更まで一緒に増やさないようにします。

残すURLを決めたら、旧URLとの対応を一行ずつ記録します。

中身を先に統合する

旧URLから転送しても、残るページに必要な情報がなければ、読者は続きを読めません。転送を出す前に、両方の項目を比較します。

一方に残業時間、もう一方に認定情報があるなら、それぞれの出典と時点を保ったまま統合します。両方に従業員数がある場合は、数が違う理由を確認します。新しい値が別の対象範囲なら、古い値の単純な更新とは限りません。

公式サイトで示す人数が連結全体、公的データが単独法人という例なら、数字を一つに選んで意味を消さないようにします。対象が同じか分からなければ、未確認として扱います。大きい値を優先する規則は作りません。

会社ページに何を載せるかの基本は会社ページの型⁠へ進んでください。統合後も、数字ごとに出典と時点を読める形を維持します。

転送とcanonicalを分ける

Googleの重複URLの統合は、リダイレクトとrel="canonical"を、正規URLの判断に対する強いシグナルとしています。サイトマップへの掲載は弱いシグナルです。複数の方法を組み合わせると、意図したURLが検索結果に出る可能性が高まるとも書いています。

同じ文書は、既存の重複ページを廃止したいときに転送を使うと説明しています。今回のように、同じ会社の紹介を一つへまとめ、旧ページを残さないなら、301の恒久転送を使います。

両方のURLを開ける理由があるなら、内容が同じか非常によく似ていることを確認し、canonicalで代表を示す方法があります。canonicalを指定しても、旧URLを開いた訪問者は移動しません。

canonicalのコードや、Googleの選んだURLとの照合は正規URLの指定⁠にまとめています。設定を重ねて矛盾を作らず、転送先と代表URLを一致させます。

旧URLを置き去りにしない

転送元から統合後のページへ、一度で着くようにします。旧社名のURLから別の旧URLを経由して、ようやく現ページへ着く連鎖を増やしません。転送先が元へ戻る循環も確認します。

同時に、一覧やランキング、関連記事のリンクを残すURLへ直します。転送が動くからと、サイト内で旧URLを案内し続けないようにします。サイトマップも残すURLへそろえます。

構造化データや共有用のURLにも旧URLが残ることがあります。ページ本文だけでなく、会社の識別情報と一緒に点検してください。Googleの統合の説明も、サイト内では重複URLより正規URLへリンクするよう求めています。

統合先がない削除と、今回の統合は違います。適切な代わりがないのに、トップや別会社へ転送しません。削除時の応答の決め方は消したURLの扱い⁠で確認できます。

取り込みで復活させない

公開ファイルだけを消しても、元の表に重複があれば、次の取り込みで再び別ページができます。取り込み元のIDと、掲載用の会社IDを対応させます。

たとえば、資料Aの旧社名の記録と、資料Bの現社名の記録を、同じ掲載会社IDへつなぎます。元のIDは捨てません。次にどちらの記録が来ても、同じ会社の項目として処理します。

統合済みのIDを再利用して、別会社のURLを作ることも避けます。古いリンクを開いた人が、以前と無関係の会社へ着いてしまうためです。元資料の関係が変わって判断できなくなった行は、自動統合から外して確認へ戻します。

会社ページでは、元データの統合と公開URLの統合を両方行います。片方だけでは、次の取り込みか次の集計で同じ重複が表に出ます。

統合後は何を確かめる？

旧URLを直接開き、残すページへ着くかと、その会社の本文かを確認します。応答コード、最終URL、会社ID、移した項目を対応表と照らし合わせます。

次に、同じ元データで再取り込みしたとき、会社ページが二つに戻らないかを確かめます。確認用の出力で会社IDとURLの重複を数え、統合した組だけでなく、別法人まで巻き込んでいないかも見ます。

公開後のSearch Consoleでは、再取得された日時とGoogleが選んだ正規URLを確認します。公開直後の古い結果だけで、統合に失敗したとは判断しません。データ型サイト⁠の運用では、対応表と確認記録を次の担当へ渡し、同じ重複を再び作らないところまで整えます。

仕様・出典の確認日：2026年10月26日⁠。