保存する資料と整理対象の資料を分けた書庫
保存する資料と整理対象の資料を分けた書庫
この記事の内容
  1. 廃止したい理由と対象をそろえる
  2. 読者が必要な説明を取り出す
  3. 残す・統合する・削除するを決める
  4. 転送を設定する前に本文を完成させる
  5. 内部リンクとサイトマップを更新する
  6. 少数のURLで応答を確かめる
  7. 復元できる記録と作業量を残す
  8. 変更後の検索と問い合わせを追う

廃止したい理由と対象をそろえる

例として、三年前の料金解説、現行の料金解説、解約手順が別々にあるサイトを整理します。古い価格が誤解を招く、同じ説明が二つある、提供終了により役割がなくなった、といった理由を記事ごとに記録します。閲覧が少ないことは調査の入口にはなりますが、それだけを削除理由にしません。契約者が年に一度だけ必要とする手順もあるためです。対象URL、タイトル、現在の役割、変更理由、情報の確認担当を一覧にし、今回扱う範囲を確定させます。

読者が必要な説明を取り出す

各記事について、読者が何を決めるために開くかを一文にします。料金の比較と解約の実行は、同じ製品を扱っていても目的が違います。残す説明、確認し直す数字、役割を終えた案内を分け、出典を開いて現在の内容を確かめます。古い記事の一部に重要な例外がある場合は、その意味を理解してから移します。文章の量を足すために古い段落を丸ごと複製するのではなく、統合先の読者が次の操作を判断できる位置に書き直して配置します。

残す・統合する・削除するを決める

同じ目的に答える現行記事があり、必要な説明を移せる場合は統合を候補にします。目的が独立している記事は、題名や導線を直して残す方が適切な場合があります。提供終了の記録や過去の制度を説明する記事も、過去の情報だと明確にすれば参考資料として役立つことがあります。一方、残す説明も同等の移転先もないページは削除を検討します。どのURLもトップページへ送るのではなく、統合先で元の質問に答えられるかを実際に読んで判定します。

保管する資料と古い資料を分けた箱
保管する資料と古い資料を分けた箱

転送を設定する前に本文を完成させる

統合先では、移す説明と必要な出典を先に公開できる状態にします。その後、旧URLから対応するURLへの恒久転送を設定します。Googleは恒久転送と一時転送を別に扱うため、一時的な編集作業を恒久移転として配信しないようにします。CMS、配信サービス、プラグインのどこが転送を管理するかも決めます。古い転送をさらに新しい転送へつなぐのではなく、可能なら元URLから最終的な公開先へ直接進める対応表にします。

記事の整理で決める対応
記事の整理で決める対応
判断必要な根拠公開時の確認
改稿して残す独立した読者の目的がある本文と題名が一致
別記事へ統合同じ目的の移転先がある必要な説明を先に移す
過去の資料として残す過去情報に利用価値がある当時の情報と明示
移転先なしで削除残す情報と同等ページがない実際の削除応答を確認
変更を戻す旧本文と設定を保存してある本文・転送・リンクを照合

内部リンクとサイトマップを更新する

旧URLへリンクしている関連記事、カテゴリ、目次、資料PDF、メールの定型文を洗い出します。転送が動いていても、自分で管理できるリンクは最終URLへ直すと案内を理解しやすくなります。サイトマップには公開する代表URLを載せ、削除したURLや転送元を残さないように確認します。canonicalを設定するページは実際の公開先と整合させます。Screaming Frogなどで収集した一覧を使う場合も、取得範囲と認証の有無を記録し、ツールが見つけたリンクが全件だと決めつけないことが大切です。

転送先が正常でも、旧記事から案内していた節が統合先に存在しないことがあります。対応表にはURLだけでなく移した見出しも残し、元のリンクに付いた節への指定も確認します。統合先の題名だけが似ていて説明が足りない場合は、転送を先に増やすのではなく、必要な説明を移す作業へ戻します。

少数のURLで応答を確かめる

最初は統合して転送する記事、内容を直して残す記事、移転先なく削除する記事を一つずつ確認します。旧URLの応答、転送先、最後に表示される本文、モバイル表示を調べます。削除したURLが200で「見つかりません」と表示される場合は、本文だけでなく実際のHTTP応答を直します。ログインした管理者だけが新版を見られる状態にも注意します。対応表には想定した状態と実際の結果を別欄で残し、不一致がある行を修正してから対象を広げます。

記事を残すか統合するかを決める
記事を残すか統合するかを決める同じ目的の移転先があるか → 必要な説明を移して統合 (はい); 同じ目的の移転先があるか → 独立した利用価値があるか (いいえ); 独立した利用価値があるか → 改稿または記録として維持 (はい); 独立した利用価値があるか → 移転先なしの削除を検討 (いいえ)はいいいえはいいいえ同じ目的の移転先があるか必要な説明を移して統合独立した利用価値があるか改稿または記録として維持移転先なしの削除を検討記事を残すか統合するかを決める同じ目的の移転先があるか → 必要な説明を移して統合 (はい); 同じ目的の移転先があるか → 独立した利用価値があるか (いいえ); 独立した利用価値があるか → 改稿または記録として維持 (はい); 独立した利用価値があるか → 移転先なしの削除を検討 (いいえ)はいいいえはいいいえ同じ目的の移転先があるか必要な説明を移して統合独立した利用価値があるか改稿または記録として維持移転先なしの削除を検討

アクセスの少なさだけでは削除せず、元の読者の目的を確認します。

復元できる記録と作業量を残す

作業前に旧本文と公開設定を保存し、転送設定の変更箇所を記録します。問題があった場合に、本文だけ戻せばよいのか、公開状態と転送も戻す必要があるのかを整理します。費用は記事の確認、統合原稿の編集、設定、検証に分けて見積もります。既存のCMSと少数のURLで対応できるなら、高額な監査契約から始める必要はありません。件数が多い場合はクロールや一括設定の利用条件を確認しますが、ツールの件数枠と編集判断の作業時間は別に扱います。

変更後の検索と問い合わせを追う

公開後は対象URLの実績を同じ期間と条件で追い、統合先へ移った検索語と失われた導線を確認します。すぐに順位が上がることを完了条件にせず、まず元の目的に答えるページへ到達できる状態を確認します。削除後に必要な資料が見つからないという問い合わせが来た場合は、その用途を調べて説明を補います。対応表には実施日、確認日、未解決のURLを残します。次の整理ではこの記録を使い、一度決めた統合先を理由なく変え続けない運用にします。

参照した公式情報

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。

比較方針を読む広告について