皆さんこんにちは！「マーケティングの達人へ！」零株式会社のメルマガ運用担当です！
SEOというと、新しい記事を書く、キーワードを調べる、タイトルを改善する、被リンクを獲得するといった「これからアクセスを増やす施策」に目が向きがちです。しかし、その前に確認しておきたいことがあります。すでに検索から来てくれているお客さんを、サイトの中で行き止まりにしていないかということです。
例えば、欲しい商品の名前で検索して、メーカーやECサイトの商品ページを開いたとします。ところが、そこには「この商品は現在ご利用いただけません」という表示。販売が終了したのかと思ってサイト内を探してみると、同じ商品が別のページで普通に販売されていた。商品がなくなったのではなく、URLが変わっただけなのに、古いURLから新しいURLへの案内がなかった。そんな状態を想像してみてください。
これでは、商品を見つけてもらうところまでは成功しているのに、購入できるページまで届けられていません。お客さんが自力で探し直してくれればよいものの、そこまでしてくれることを前提にしたサイト設計は避けたいところです。
今回は、このような「URL変更による取りこぼし」を発見し、修正するためのノウハウを解説します。ECサイトの商品ページだけでなく、サービスページ、記事、導入事例など、URLを変更する可能性のあるページに応用できる考え方です。
この記事の要点：なくなったページではなく、「行き先があるのに案内していないページ」を探す
今回の施策で探したいのは、単に404になっているURLではありません。同じ商品やコンテンツが別のURLで存在するにもかかわらず、古いURLにアクセスした人を適切なページへ案内できていない状態です。
Googleも、ページが移動した場合は新しい場所へリダイレクトし、削除されて代替ページがない場合は404または410を返す、という対応を示しています。404をすべてなくすのではなく、そのページの状況に合った処理を行うことが基本です。（出典：Google Search Consoleヘルプ「404エラー」、Google 検索セントラル「URLの変更を伴うサイト移転」）
作業の流れは、Search Consoleで候補を見つけ、検索実績と現在のページ状態を照合し、適切な移転先があるものを301リダイレクトでつなぎ、転送先の内容まで確認することです。その後、Googleによる新しいURLの認識と、検索流入・購入・問い合わせの変化を観察します。
ただし、「過去3か月にクリックがあったから、今も売上を失っている」「301を設定したから、検索順位が必ず戻る」といった断定はできません。調査対象の抽出、現在の不具合の確認、修正後の効果測定は、分けて考えましょう。
なぜ新しい記事を書く前に、古いURLを確認する価値があるのか
集客できない問題と、集客した人を受け止められない問題は違う
新しい記事を書く施策は、まだ接点のない人に見つけてもらうための取り組みです。一方、今回のURL修正は、すでに接点を持てた人が目的を果たせるようにする取り組みです。
例えば、「商品Aを購入したい」と考えて検索した人が、商品Aのページをクリックしたのに、利用できないという表示しか見られなかったとします。このケースでは、検索キーワードの選定や記事の文字数を見直す前に、「その人が商品Aを買える場所へ到達できるか」を確認するほうが筋が通っています。
もちろん、その訪問者が必ず購入するわけではありません。しかし、購入するかどうかを判断できるページにさえ届かない状態と、価格や仕様を確認して購入を検討できる状態は、明確に異なります。
検索流入を増やすことと、検索流入を成果につなげることは、同じではありません。 この二つを一緒に考えると、「アクセスが足りないから記事を増やそう」という判断ばかりになり、すでに発生している取りこぼしを見逃してしまいます。
「404の数」よりも、「どのページで何が止まっているか」を見る
調査の成果を「404を何件減らしたか」だけで評価するのも適切ではありません。存在する必要がないURLを、無理に別のページへ転送して件数を減らしても、利用者の問題が解決するとは限らないからです。
Googleも、正しく404を返している不要なURLの多くは、修正する必要がないと説明しています。つまり、404があること自体を、サイト全体の問題と捉える必要はありません。（出典：Google Search Consoleヘルプ「404エラー」「ページ インデックス登録レポート」）
例えば、誰にも利用されていない誤入力URLを100件処理するより、主力商品の旧URLを1件直すほうが、事業にとって重要な場合があります。作業量ではなく、「どの需要を受け止められるようになったか」で考えることが大切です。
最初に整理したい、404・ソフト404・在庫切れの違い
「利用できません」と表示されていても、404とは限らない
ブラウザに表示される文章と、サーバーが返すHTTPステータスコードは別のものです。HTTPステータスコードとは、ページへのアクセスに対して、サーバーが通信上の結果を伝えるための番号です。
ページに「見つかりません」と表示されていても、通信上は正常な応答を意味する200を返していることがあります。Googleは、実際にはエラーページであるのに200を返しているような状態を、ソフト404として扱う場合があります。反対に、200で応答しているというだけで、インデックス登録が保証されるわけでもありません。（出典：Google 検索セントラル「HTTPステータスコード、ネットワークエラー、DNSエラーがGoogle検索に与える影響」）
つまり、確認するべきことは二つあります。通信上は何を返しているか。そして、利用者には何が見えているか。 片方だけでは、正しく診断できません。
対応は、そのURLで提供すべき内容から決める
対応を判断するときは、すべてのURLを同じ方法で処理せず、状況を分けて考えます。
同じ商品・同じ内容が、別のURLへ移動した場合
旧URLから、正しい新URLへ恒久的にリダイレクトします。今回の記事で、優先的に見つけて修正したいのは、この状態です。商品や情報は残っているのに、古い入口から到達できなくなっているため、入口と移転先をつなぎ直します。
一時的に在庫がないものの、商品情報は提供できる場合
商品ページを維持し、在庫状況を正確に伝えることを基本に考えます。購入できないことと、ページが存在しないことは同じではありません。Googleも、一時的に販売できない場合にサイトや商品情報を維持し、在庫状況に合わせて構造化データやMerchant Centerの情報を更新する方法を案内しています。（出典：Google 検索セントラル「オンライン ビジネスの一時停止」）
ページを削除し、同等の代替ページもない場合
404または410を返します。行き先が存在しないのに、無関係なページへ転送して見かけ上のエラーを減らす必要はありません。
本来は存在するページが、実装不具合で表示できない場合
不具合を修正して、適切な内容を表示させます。公開設定やデータの読み込みに問題があるだけなら、別のページへ転送するのではなく、元のページを正常に戻すべきケースがあります。
本文のない「見つかりません」画面が、200を返している場合
内容を復旧すべきなのか、適切な移転先へ転送すべきなのか、本当に削除済みなので404を返すべきなのかを判断します。200を返しているという理由だけで、正常なページとは判断しません。
これらは、Googleが示すページ移転・削除・ソフト404への対応を、実際の運用で判断しやすいように整理したものです。（出典：Google 検索セントラル「URLの変更を伴うサイト移転」、Google Search Consoleヘルプ「ページ インデックス登録レポート」）
特に注意したいのは、「在庫切れと書いてある200ページは全部おかしい」という判断をしないことです。商品説明、仕様、レビューなどを読めるページと、商品情報が消えて定型的なエラー文だけになったページは、分けて扱う必要があります。
販売終了品についても、取扱説明書や仕様確認などの目的で情報を残す判断はあり得ます。その場合は、「現在も購入できる商品」のように見せるのではなく、販売終了を明示したうえで、何のためのページとして残すのかを設計しましょう。
手順1：Search Consoleで、修正候補となるURLを集める
「見つかりませんでした（404）」と「ソフト404」を確認する
まず、Google Search Consoleで対象サイトのプロパティを開き、［インデックス登録］→［ページ］から、ページ インデックス登録レポートを確認します。「ページがインデックスに登録されなかった理由」にある［見つかりませんでした（404）］を開き、URL一覧をエクスポートします。［ソフト404］がある場合は、こちらも別に確認してください。（出典：Google Search Consoleヘルプ「ページ インデックス登録レポート」）
ここで作るのは、あくまで「調査候補の一覧」です。レポートに載っているからといって、すべてをリダイレクトするわけではありません。
管理用の一覧には、旧URLだけでなく、確認日、現在のHTTPステータス、画面の表示内容、想定される商品名やページ名、移転先候補、対応方針、実装日を残せるようにしておくと、その後の判断が整理しやすくなります。
特に、Googleが最後に確認した状態と、いま実際に公開されている状態は一致するとは限らない点に注意してください。URL検査の通常の結果は、現在のページをその場で確認した結果ではなく、Googleが保存している情報です。現在の状態を調べる場合は、実際のアクセスや［公開URLをテスト］を使って確認します。（出典：Google Search Consoleヘルプ「URL検査ツール」）
エクスポートできた一覧が、サイト内の全件とは限らない
Search Consoleの一覧には上限があります。ページ インデックス登録レポートのURL例は最大1,000件で、1,000件未満であっても、その状態に該当するすべてのURLが表示されるとは限りません。（出典：Google Search Consoleヘルプ「ページ インデックス登録レポート」）
また、通常のレポートからのエクスポートでは、一覧データの出力に1,000行の制限があります。大規模サイトで、エクスポートしたデータだけを使って「問題をすべて洗い出せた」と判断するのは避けましょう。（出典：Google Search Consoleヘルプ「レポートデータをエクスポートする」）
商品数やページ数が多い場合は、CMSから取得したURL一覧、過去のURL変更記録、サイト内を巡回した結果なども調査対象に加える設計にします。最初から完全な一覧を作れなくても、まず重要なページの問題を発見し、対応範囲を広げていく進め方で構いません。
手順2：検索実績と照合し、優先して確認するURLを絞る
まずは直近3か月の「ページ別データ」を使う
次に、Search Consoleの［検索パフォーマンス］→［検索結果］を開きます。期間を直近3か月に設定し、［ページ］タブでURL別のクリック数や表示回数を確認して、データをエクスポートします。Search Consoleでは、期間や検索タイプを変更し、ページなどの単位で実績を確認できます。（出典：Google Search Consoleヘルプ「検索パフォーマンス レポート」）
そのデータを、先ほど作った404・ソフト404の候補一覧と、URLをキーにして照合します。ここで知りたいのは、「問題がありそうなURLのうち、検索で利用されていたのはどれか」です。
URLを照合するときは、元の文字列も残しておきましょう。末尾のスラッシュやパラメータなどを、意味を確認せずに削除してまとめてしまうと、調査対象を取り違えるおそれがあります。同じページとして扱ってよいかを確認してから整理するほうが安全です。
3か月のクリック実績は、「今も404に流入している証拠」ではない
ここが、今回の作業で最も誤解しやすいポイントです。
仮に、ある旧URLに直近3か月で300クリックがあったとします。しかし、そのURLが404になったのは昨日かもしれません。300クリックのほとんどは、ページが正常だった時期のものだった可能性があります。
反対に、以前から404だったとしても、現在はすでに検索からほとんど流入していないかもしれません。したがって、「現在404であること」と「過去3か月にクリックがあること」を組み合わせただけでは、現在進行形の取りこぼしを証明できません。
3か月のデータで広めに候補を拾ったら、直近7日や28日など、より短い期間でも確認します。URL変更日や障害の発生日が分かるなら、その日以降の実績を調べるほうが、問題との関係を判断しやすくなります。
なお、Search Consoleの最新データには暫定値が含まれることもあるため、レポートの更新状況も確認しましょう。（出典：Google Search Consoleヘルプ「検索パフォーマンス レポート」）
さらに取得可能であれば、アクセスログ上の旧URLへのリクエストと応答コードも確認します。その際は、検索エンジンなどのクローラーによるアクセスと、利用者によるアクセスを混同しないようにします。
クリックがゼロでも、すぐに「修正不要」とは決めない
もう一つ注意したいのが、Search Consoleの検索実績は、原則としてGoogleが選んだ正規URLに集計されることです。利用者が実際にアクセスしたURLと、クリック数が計上されるURLが異なる場合があります。そのため、特定のURLにクリックが記録されていないことだけで、アクセスがないとは断定できません。（出典：Google Search Consoleヘルプ「検索パフォーマンス レポート」の正規URLへのデータ集計に関する説明）
また、今回の調査対象は検索流入ですが、古いURLがメール、SNS、外部サイト、ブックマークなどに残っている可能性も検討したいところです。検索実績が少なくても、重要な案内先として使われていたURLなら、別途確認する価値があります。
作業の優先順位としては、まず「現在の不具合が確認でき、最近も利用されていて、正しい移転先が明確なURL」から着手します。続いて、検索での表示実績があるものや、過去に重要な商品・サービスの入口だったものを確認していくと、判断しやすくなります。
逆方向の調査も入れると、見落としを減らせる
404の一覧から検索実績を調べるだけでなく、検索流入の多いページから現在の表示内容を確認する、という逆方向の調査も組み合わせましょう。
HTTPステータスが200であっても、実際には商品データが読み込まれず、エラー文だけになっているケースは調査対象です。Googleも、データベース接続やJavaScriptなどの問題により、内容のないページやソフト404が発生し得ると説明しています。（出典：Google 検索セントラル「クロールエラーのトラブルシューティング」）
重要な検索流入ページを実際に開く作業は、404一覧の確認とは別の役割を持っています。
エラーとして報告されたページだけを見るのではなく、お客さんが実際に来ているページが正常に機能しているかを見る。 この視点を持っておくと、数値の確認だけで調査を終えずに済みます。
手順3：正しい移転先を特定し、必要なURLだけ301でつなぐ
商品名だけでなく、型番や商品IDまで確認する
旧URLが商品ページだった場合、まずサイト内検索や商品管理画面で、同じ商品が現在も存在するかを調べます。商品名だけでは似た商品を取り違えることがあるため、型番、商品ID、SKUなど、同一商品と判断できる情報も確認しましょう。
例えば、「ランニングシューズA」という商品名だけで探すと、旧モデルと新モデル、メンズとウィメンズ、色違いの商品が混ざるかもしれません。ここで必要なのは、「何か買えるページ」ではなく、旧ページを探していた人にとって、適切な行き先です。
BtoBサイトでも考え方は同じです。サービス名が変更されたなら、実質的に同じサービスの新ページを探します。複数の記事を統合したなら、旧記事の内容が引き継がれた統合先を確認します。ただし、「近いキーワードが入っている」というだけで別内容のページへ転送するのは避けましょう。
恒久的なURL変更には、恒久的なリダイレクトを使う
同じページが恒久的に新しいURLへ移った場合、Googleは可能な限りサーバー側の恒久的なリダイレクトを使うことを推奨しています。代表的なのが301で、308も恒久的な移転を示します。302などの一時的なリダイレクトとは、用途を分けて考えます。（出典：Google 検索セントラル「リダイレクトとGoogle検索」）
目指す構造は、シンプルです。
旧URL → 301リダイレクト → 同じ商品の正常な新ページ
設定は、利用しているCMSのリダイレクト管理機能や、サーバー側の設定などで行います。実装方法は環境によって異なるため、担当者へ依頼する場合も、「404を直してください」だけでなく、旧URLと新URLの対応関係を渡すことが重要です。
なお、本来はURLを変える必要がなく、単なる公開設定やルーティングの不具合で旧ページが表示できなくなっているだけなら、元のURLで内容を復旧するほうが適切な場合もあります。すべての問題を「新しいURLを作って転送する」という方法で処理しないようにしましょう。
トップページへの一括転送は、解決とは限らない
商品ページを探して来た人を、トップページへ戻してしまう。サービスの詳細を探して来た人を、関係の薄い一覧ページへ送ってしまう。これでは、通信上の404を避けられても、利用者には探し直しを求めることになります。
Googleも、多数の旧URLを関連性の低い一つのURLへ転送することを避けるよう案内しています。このような転送はソフト404と見なされる場合があります。一方で、内容を実際に統合した場合は、複数の旧ページを統合先へ転送することが認められています。（出典：Google 検索セントラル「URLの変更を伴うサイト移転」）
後継商品についても、「後継だから必ず転送する」と機械的に決める必要はありません。旧モデルの仕様を確認したい人まで新モデルへ送ってしまうと、目的を満たせない可能性があります。
旧情報を残して後継商品へのリンクを設けるのか、実質的な置き換え先へ転送するのかを、検索意図とページの役割から判断しましょう。
手順4：リダイレクトの応答と、到着先の内容を両方確認する
基本形は「旧URLから1回の転送で、正常な新ページへ」
設定後は、修正したすべての旧URLを再確認します。例えば、HTTPステータスの確認サービスである「httpstatus.io」では、複数URLのHTTPステータス、レスポンスヘッダー、リダイレクトの経路などを確認できます。（出典：httpstatus.io公式サイト）
確認のイメージは、次のようになります。
目指す状態：旧URL［301］→ 正しい新URL［200］
旧URLから直接、意図した新ページへ到達できています。まずはこの状態を基本に考えます。ただし、後述するように、200が返っていることだけで確認を終えないようにします。
見直したい状態：旧URL［301］→ 中間URL［301］→ 新URL［200］
途中で別のURLを経由してから新ページへ到達しています。このようなリダイレクトの連鎖は、整理できるなら最終的な新URLへ直接つなぐ構造に変更します。
問題が残っている状態：旧URL［301］→ 存在しないURL［404］
リダイレクト先も存在していません。転送設定を登録できたことと、問題を解消できたことは別です。新URLの誤りや、そのページの公開状態を確認します。
表示内容の確認が必要な状態：旧URL［301］→ 新URL［200］だが、本文はエラー表示
通信上は成功しているように見えても、利用者は目的の情報を得られていません。転送先の表示内容まで確認する必要があります。
複数回のリダイレクトがあるからといって、必ず検索評価を失うわけではありません。ただし、Googleは転送を連鎖させず、最終的な行き先へ直接転送することを推奨しています。設定を整理できるなら、途中のURLを経由しない構造を目指しましょう。（出典：Google 検索セントラル「URLの変更を伴うサイト移転」）
200が返っていても、商品が正しく表示されるとは限らない
HTTPステータスの確認が終わったら、実際にブラウザでもページを開きます。
商品名、画像、価格、仕様などが意図した内容になっているか。販売中の商品なら、商品選択やカート投入まで進めるか。サービスページなら、問い合わせへの案内が機能しているか。転送先が正常なレスポンスを返すことと、利用者が目的を果たせることは、別々に確認します。
表示がJavaScriptなどに依存しているページでは、自分のブラウザで見えたことだけでなく、Googleがどのように内容を認識しているかも確認対象です。Search Consoleの公開URLテストでは、レンダリングされたページのスクリーンショットなどを調べられます。（出典：Google Search Consoleヘルプ「URL検査ツール」）
ただし、実際に一時的な在庫切れで、商品情報と在庫状況を正しく伝えているページは、それだけで不具合とは判断しません。直すべきなのは、実態と表示、または目的のページへの案内が食い違っている状態です。
手順5：新URLの認識を確認し、修正後の変化を追う
新URLをURL検査で確認する
リダイレクト先の新URLを、Search ConsoleのURL検査に入力します。公開URLテストで取得やインデックス登録を妨げる問題を確認し、必要に応じてインデックス登録をリクエストします。
少数のURLにはURL検査、多数のURLにはサイトマップという使い分けが基本です。ただし、リクエストは検索結果への掲載や即時反映を保証するものではありません。同じURLを繰り返し送信しても、クロールが早くなるわけではないとGoogleは説明しています。（出典：Google 検索セントラル「GoogleにURLの再クロールをリクエストする」）
また、新URLを送信したことと、旧URLの移転処理が確認されたことは同じではありません。旧URLの転送確認と、新URLのインデックス登録状況の確認は、別の作業として記録しておきましょう。
「2〜4週間」は確認の区切りであって、完了の保証ではない
運用上は、修正後2〜4週間を最初の観測期間として設定すると、日々の変動だけで判断せずに済みます。ただし、これは確認スケジュールの提案であり、その期間内に必ず順位や流入が回復するという意味ではありません。
Googleは、再クロールには数日から数週間かかる場合があり、リクエストしても検索結果への表示が保証されないとしています。（出典：Google 検索セントラル「GoogleにURLの再クロールをリクエストする」）
修正後は、技術的な確認、検索での変化、事業成果の変化を分けて見ます。
技術的には、旧URLから正しいページへ転送されることを確認します。検索では、旧URLと新URLのクリック数、表示回数、対象クエリの変化を追います。そして事業成果として、適切な商品閲覧、購入、問い合わせなどにつながっているかを確認します。
「設定が正しい」「Googleが移転を認識した」「売上が増えた」は、同じ意味ではありません。 この三つを分けて報告すると、何が完了していて、何を引き続き観察すべきかが明確になります。
「旧URLの表示回数が減り、新URLが増えた」だけで、評価の完全移転とは断定しない
旧URLの表示回数が減って新URLが増えれば、移転が進んでいることと整合する動きです。しかし、それだけで「検索評価が100％引き継がれた」と証明できるわけではありません。
Search Consoleのデータは原則として正規URLに集計されるため、集計先の変化を含めて解釈する必要があります。（出典：同上）
判断するときは、旧URLと新URLをそれぞれ見るだけでなく、同じ商品・コンテンツのまとまりとして合計クリック数を確認します。主要な検索クエリをそろえ、比較する期間や曜日の条件もできるだけ合わせましょう。検索需要が違う期間を比較しているのか、URL修正によって変化したのかを、分けて考えるためです。
「古いURLの数字が消えたから失敗」「新しいURLの数字が増えたから完全成功」と、片方だけで判断しないことが重要です。
修正を完了させるには、内部リンクやサイトマップも更新する
リダイレクトを設定した後は、サイト内からのリンクも新URLへ変更します。メニュー、カテゴリ一覧、関連記事、商品紹介記事など、自分たちで修正できる案内先を、いつまでも旧URLのままにしないようにしましょう。
あわせて、サイトマップとcanonicalの設定も確認します。canonicalは、重複するページなどについて、正規として扱ってほしいURLを示すための指定です。新ページを作ったのに、指定が旧URLのままになっていないかを確認します。
GoogleのECサイト向けガイドでも、内部リンク、サイトマップ、canonicalでURLの使い方をそろえることが推奨されています。（出典：Google 検索セントラル「eコマースサイトのURL構造を設計する」）
実務上は、広告、配信予定のメール、SNSプロフィールなど、これから利用するリンクも新URLへそろえると整理しやすくなります。リダイレクトは、修正できない過去のリンクから来た人を受け止めるために残し、自分たちで更新できる導線は直接つなぎ直す、と考えると分かりやすいでしょう。
また、検索結果が新URLに切り替わったように見えても、すぐにリダイレクトを削除しないことが大切です。Googleは、移転時のリダイレクトを一般的に1年以上保持し、利用者の観点からは無期限の維持も検討するよう案内しています。（出典：Google 検索セントラル「URLの変更を伴うサイト移転」）
最初の1時間で取り組むなら、「全件修正」より「重要な数件を確実に」
この作業は、小さく始められるのが利点です。ただし、サイト規模、権限、CMSの機能、社内承認の有無によって、実装まで進められる範囲は異なります。最初の1時間は、サイト全体の完全修正ではなく、重要なURLの問題を特定し、修正または実装依頼まで進めるための作業枠として考えましょう。
作業配分の一例としては、次のような進め方が考えられます。
最初の10分は、調査に使うデータを集めます。
404・ソフト404の候補と、検索パフォーマンスを取得します。この段階では、すべてを修正しようとせず、まず調べる対象を用意することに集中します。
次の15分は、検索実績と現在のページ状態を照合します。
最近のクリックや表示回数があるURLを確認し、実際に開いて、現在も問題があるかを調べます。過去のエラー記録と現在の不具合を混同せず、優先して対応する候補を絞ります。
次の15分は、正しい移転先と対応方針を決めます。
同一商品・同一内容の新ページを探します。単なるURL変更なのか、一時的な在庫切れなのか、代替のない削除なのかを判断し、それぞれに適した対応を決めます。
次の15分は、実装または実装依頼に使います。
承認済みで自分が設定できるURLは修正します。開発担当者や制作会社への依頼が必要なら、旧URLと新URLの対応関係、希望する処理、確認してほしい内容をまとめて渡します。
最後の5分は、確認と記録に使います。
実装したものについて、旧URLから意図したページへ到達できるかを確認します。未対応項目と、修正後の変化を確認する日も記録しておきます。
ここで大切なのは、リダイレクトを大量に登録することではありません。正しい移転先が分からないURLまで、時間内に無理やり処理しないことです。
例えば、5件を調べて3件は明確な移転、1件は一時的な欠品、1件は代替のない削除だったとします。この場合、すべてを301にするのではなく、それぞれ異なる判断をすることが、調査の成果です。
再発防止には、URL変更を「公開作業」ではなく「移転作業」として扱う
今回のような問題を繰り返さないために、運用ルールとしておすすめしたいのは、URL変更の完了条件を決めることです。
「新しいページを公開したら完了」ではなく、「旧URLの扱いを決め、新URLとの対応を確認し、必要な転送とリンク更新を行い、実際にアクセスして確認したら完了」と定義します。
記事担当者、商品登録担当者、制作会社、開発担当者の誰がURLを変えても、旧URLをどう扱うかの判断が抜けないようにするためです。URL変更の申請や作業記録に、旧URL、新URL、変更理由、転送の有無、確認結果を残すだけでも、後から状況を追いやすくなります。
例えば、商品情報の更新時にページを作り直す運用があるなら、新ページの公開だけで作業を終了しないようにします。記事を統合する運用があるなら、統合元のURLをどのように扱ったかまで記録します。
新しいページを作ることと、古いページから来た人を受け止めることを、ひとまとまりの作業にする。 これが、今回の問題を運用面から減らすための考え方です。
また、定期的な確認では、404の件数だけを見るのではなく、主要な検索流入ページが正常に機能しているかも確認しましょう。エラー一覧を眺めることと、お客さんがたどる導線を確認することは、役割が違います。
まとめ：検索から来たお客さんに、もう一度探し直させない
SEOで新しいアクセスを獲得することは大切です。しかし、すでに商品やサービスを探して来てくれている人がいるなら、その人が目的のページにたどり着ける状態を整えることも、同じくらい大切です。
今回の施策は、すべての404を消すための作業ではありません。移動したページには適切な案内を設け、一時的な在庫切れには正確な情報を表示し、本当に削除したページには正しい応答を返す。そのうえで、検索実績だけでなく、実際の到着先と利用者の行動まで確認する取り組みです。
新しいお客さんを呼び込む前に、来てくれたお客さんを迷わせていないかを確認する。
検索順位を上げるための次の施策を考えるとき、古いURLと重要な流入ページの点検も、同じ検討項目に入れてみてください。増やすべきなのは、アクセスの数字だけではありません。目的の商品や情報に、きちんとたどり着けるお客さんの数です。
