WebリニューアルでAIO/SEOを落とさない内部リンク・構造化データ・リダイレクト設計と1ページ完結再設計の方法を解説

AIOが前提となる現在、流入減少の要因は従来以上に見えにくくなっています。AI検索の影響と、リニューアル時の設計ミスが混同されやすいからです。もっとも、リニューアル後に流入が落ちる主因そのものは、以前から大きく変わっていません。典型例は、URL変更の設計ミス、リダイレクト漏れ、内部リンクの崩れ、構造化データの消失、統廃合判断の誤りです。

GoogleはAI機能について、追加の特別な最適化は不要で、従来のSEOの基本が引き続き有効だと説明しています。だからこそ、リニューアルで優先すべきは見た目の刷新ではなく、検索評価の土台を損なわないことです。

実務上は、ページを細かく分割して回遊だけに頼るより、比較・条件・FAQなどの判断材料を一つのページに十分に持たせたほうが機能しやすい場面が増えています。これはGoogleの追加要件というより、検索体験の変化を踏まえた設計上の判断です。

本記事では、担当者がそのまま実務に落とし込めるように、棚卸し表、URL設計、内部リンク、構造化データ、公開前後の確認項目までを整理します。

まず押さえておきたいのは、流入減の多くがデザイン変更そのものではなく、「評価の引き継ぎ不足」によって起こるという点です。リダイレクト、canonical、meta robots、内部リンク、構造化データ、HTTPステータスのいずれかに不備があると、移行直後に影響が出やすくなります。

・旧URLの評価を新URLに引き継げていない（301リダイレクト漏れ・誤設定）
・内部リンクやパンくずが崩れ、重要ページへ到達しにくくなっている
・統廃合によって、検索意図に応えていた情報が失われている
・公開直前の noindex / canonical / nosnippet 設定確認が漏れている
・構造化データを未実装のまま公開している、または本文と整合していない
・ハブページ→詳細記事→LP の導線が切れている
・資料請求フォームや計測タグが正しく動作していない

特にAIO対応で
「関連記事を整理した」
「ページを統合した」
という判断自体が問題なのではありません。問題は、統合先のページから比較・条件・FAQといった判断材料が抜け落ちることです。ページ数を減らしても、意思決定に必要な情報まで減らしてしまえば、評価も成果も落ちます。

リニューアルの成否は、着手前の棚卸しでほぼ決まります。まずは表形式で現状を可視化してください。頭の中だけで整理すると、残す・削る・統合する判断が属人化し、後から理由を説明できなくなります。

・現URL
・ページ種別（コラム／サービスLP／導入事例／会社情報 など）
・想定検索意図・狙いキーワード
・月間自然検索流入
・CV種別と件数（資料請求／問い合わせ／デモ申込 など）
・ページの役割（誰が、何を判断するためのページか）
・対応方針（存続／統合／削除／リライト）
・新URL
・リダイレクト方針（301／302／なし）
・備考（移行後に追加すべき要素：FAQ、比較表、内部リンク など）

流入が少ないページでも、比較検討の途中で効いているページは少なくありません。PVだけで削除を判断せず、「誰の、どの判断を支えているか」を備考に残しておくことが重要です。

URL設計は、公開時点だけでなく、公開後の運用まで見据えて決めるべきです。URL変更を伴う移行では、正確なURLマッピング、適切なリダイレクト、canonical確認が重要になります。

・不要なURL変更はできるだけ避ける
・カテゴリ単位で命名規則を統一する
・日本語URLを使うかどうかを先に決める
・階層を深くしすぎない
・旧URLの意味やトピックを新URLでも引き継ぐ
・ハブページ／詳細記事／LP の役割が分かる構造にする
・一時的なキャンペーン名を恒久URLに持ち込まない

よくある失敗は、タイトルだけを新しく見せながら、URLは別カテゴリへ移してしまうことです。これでは、ユーザーにも検索エンジンにも文脈が伝わりにくくなります。

リダイレクト表は、旧URLの評価を新URLへ引き継ぐための設計書です。作成すること自体が目的ではなく、公開前に本番相当環境で検証できる状態まで落とし込んでおく必要があります。

・旧URL
・新URL
・種別（301 / 302）
・対応者
・確認日
・備考（統合先、削除理由、代替ページの有無）
・旧URLごとに1行で管理する
・未定URLを空欄のまま放置しない
・削除ページは理由を残す
・公開前に本番想定で確認する

リダイレクト表は、作ることが目的ではありません。公開直前に「どこからどこへ転送するのか分からない」状態を防ぐための基盤です。

AI機能に表示されるための特別な追加要件はありません。だからこそ、ページ数を増やすこと自体よりも、技術要件を満たしたうえで、どのページに情報を集約し、ユーザーが判断しやすい形で提示するかが重要です。

実務上は、検索意図が近いページを整理し、比較・条件・FAQを備えた判断ページへ再編したほうが、運用と評価の両面で扱いやすいケースが少なくありません

統廃合の判断基準は、次のように整理すると実務で使いやすくなります。

残す
・流入またはCVに寄与している
・検索意図が明確である
・他ページと役割が重複していない

統合する
・テーマと検索意図が近い
・更新が止まっている
・情報が薄い、または分散しすぎている
・1本にまとめたほうが比較表やFAQを配置しやすい

削除する
・流入もCVもなく、明確な代替ページがある
・期間限定キャンペーンで役割を終えている
・現在の事業方針と整合しない

統合時は、単純に文章を寄せ集めるのでは不十分です。少なくとも、次の要素まで含めて再設計してください。

・対象／対象外
・比較表
・FAQ
・次に読むべき深掘り記事へのリンク

つまり、統合先を「1ページ完結型の判断ページ」として作り直す意識が必要です。

リニューアルでは、URL変更そのもの以上に、内部リンクの更新漏れによって評価と回遊が落ちることがあります。Googleはリンクをページ発見と関連性判断のシグナルとして利用しており、AI機能でも内部リンクによって重要コンテンツを見つけやすくすることが推奨されています。

公開前には、次の点を確認してください。

・ハブページ→詳細記事→LP の導線があるか
・パンくずが正しい階層になっているか
・フッターサイトマップが新構成に合っているか
・関連記事が旧URLのまま残っていないか
・アンカーテキストが抽象的すぎないか
・目安として、主要LPへ3クリック以内で到達できるか

内部リンクは、検索評価とユーザー導線の両方に関わります。後回しにせず、URL設計やナビゲーション設計と同じ優先度で扱うべきです。

公開前には、デザイン確認だけで終わらせず、検索評価に関わる設定を代表URLで実地確認する必要があります。サイト移行時には、redirect、canonical、robots制御、構造化データ、sitemap の整合性確認が重要です。

・主要ページのHTTPステータスが想定どおりか（200 / 301 / 404）
・旧→新リダイレクトが全件反映されているか
・canonical が新URLを指しているか
・noindex / nosnippet / data-nosnippet の設定が意図どおりか
・XML sitemap が新構成を反映しているか
・robots.txt やCDN設定、認証設定でクロールを妨げていないか
・構造化データを Rich Results Test で検証したか
・計測タグ、CVポイント、フォーム送信が正常に動作するか

テンプレート単位の確認だけで終えず、主要LP、記事、カテゴリ、会社情報など、代表URLを実機で確認することが重要です。公開前に URL Inspection と Rich Results Test を使っておくと、移行後の初動確認もしやすくなります。

リニューアル時は本文の移行に意識が向きやすく、構造化データが抜け落ちがちです。Googleは構造化データをページ理解に利用しており、AI機能でも「構造化データは可視テキストと一致していること」が重要だと明記しています。

特に確認したいのは次の4つです。

・Organization
・BreadcrumbList
・Article / BlogPosting
・FAQPage（適用条件に合致する場合のみ）

Organization は主にトップページや会社情報ページ、BreadcrumbList はサイト階層、Article は記事テンプレートの意味づけに関わります。なお、FAQPage は現行のGoogleドキュメントでは適用対象が限定されており、一般的なサイトで一律に推奨できるものではありません。FAQ本文そのものは有効でも、FAQPage マークアップの可否は対象条件を確認したうえで判断すべきです。

見落としやすいのは、次のようなケースです。

・パンくずを見た目だけ再現し、BreadcrumbList が抜けている
・記事テンプレート変更により Article が外れている
・FAQをアコーディオン表示にしたが、HTML上で内容が十分に読めない
・本文と異なる内容を構造化データに記述している

見た目を再現するだけでは不十分です。「何のページか」「サイト内でどの位置にあるか」という意味づけまで、移行対象に含めてください。

公開後は、AIOだけを切り分けて見るより、主要LP単位で「Web検索全体」の変化を追うほうが実務的です。Googleは、AI機能経由の露出も Search Console の「Web」検索タイプに含まれると説明しています。また、404や5xxはクロールとインデックスに直接影響します。

確認したい項目は次のとおりです。

・主要LPの表示回数
・主要LPのクリック数
・掲載クエリの変化
・CTRの変化
・Search Console でのインデックス状況
・資料請求フォーム到達数
・CTAクリック数
・404 / 5xx の発生有無
・リダイレクト漏れの有無

この段階では、流入だけでなく、「どのページで比較・検討が進んだか」「CV導線が正常に機能しているか」まで合わせて確認してください。AIO時代ほど、ページ単位の役割と成果を切り分けて見ることが重要になります。

後から認識齟齬で揉めないよう、次の項目は要件として明文化しておくべきです。

・旧サイトのURL棚卸しを実施すること
・旧→新の301リダイレクト表を作成・納品すること
・主要LPの内部リンクおよびパンくず設計を担保すること
・構造化データの再実装範囲を定義すること
・noindex / nosnippet / canonical / sitemap の確認手順を提示すること
・公開後の404 / 5xx 監視体制を定めること
・受け皿LP（比較・条件・FAQを含む）の整備範囲を明確にすること
・公開後1週間の確認項目と担当者を明記すること
・ナビ、リンク、パンくず、サイトマップをどこまで自動追随できるか明記すること
・大量ページ移行時の自動化手段（CSV取込、コンバーター、RPA など）を確認すること

社内説明では、「今回のリニューアルはデザイン刷新にとどまらず、AIO/SEO流入を維持しながら資料請求につなげるための移行設計を含む」と整理すると、目的が伝わりやすくなります。