ランディングページがインデックスされない：マーケティングとキャンペーンページのインデックスを修正
丁寧に作成されたランディングページがオーガニック検索に表示されません。なぜマーケティングページが特にGoogleのインデックスに苦戦するのか、コンバージョンデザインとクロール可能性の対立を解消する方法を発見しましょう。
このガイドの内容
ランディングページは、ウェブサイトで最も慎重に設計されたページであることが多いですが、インデックスさせるのが最も難しいページです。中心的な緊張関係は、コンバージョン最適化がクロール可能性と直接対立するということです。
削除されたナビゲーションは、それらを孤立ページに変えます。JavaScript重視の要素はGoogleにレンダリングされないかもしれません。サブドメインのホスティングは権威を断片化します。A/Bテストのバリアントは重複コンテンツを生み出します。そしてキャンペーンチームは、オーガニック検索をほとんど考慮せず、基本的なSEO要素を完全にスキップします。
本ガイドでは、コンバージョンパフォーマンスを維持しながらこれらのランディングページのインデックスブロッカーを修正する方法を示し、有料キャンペーンが終了した後もページがオーガニックトラフィックを生み出すようにします。
孤立ページ問題：ランディングページにクロールパスがない理由
ランディングページがインデックスされない最も基本的な理由は、それらが孤立ページであることです。孤立ページとは、ウェブサイトの他のページから内部リンクを受け取らないページです。Googleはすでに知っているページからリンクをたどることでページを発見します。サイトのどのページもランディングページにリンクしていない場合、Googleはそれを見つけるクロールパスがありません。
ランディングページは偶然ではなく、設計上孤立します。コンバージョン率最適化のベストプラクティスは、訪問者を望ましいアクションに集中させるために、ランディングページからサイト全体のナビゲーションを削除することを推奨しています。ヘッダーナビゲーション、フッターリンク、サイドバーを削除すると、ランディングページもサイトの内部リンクグラフから削除されます。ページはまだサーバー上に存在し、URLからアクセスできますが、ウェブサイトのどこからもそれを指していません。
この問題は、ランディングページがサブドメインまたはサードパーティプラットフォームに存在する場合に増幅されます。Unbounce、Instapage、または同様のプラットフォームで構築され、go.yourdomain.comのようなサブドメインから提供されるランディングページは、メインドメインのクロールグラフから完全に切り離されています。メインドメインが強力な権威と定期的なGoogleクロールを持っていても、Googleはクロール発見の目的でサブドメインを別のエンティティとして扱うため、サブドメインはゼロから始まります。
修正はコンバージョンの目標とクロール可能性のバランスを取る必要があります。ランディングページに完全なサイトナビゲーションを戻す必要はありません。代わりに、メインサイトの関連コンテンツからランディングページへのターゲットを絞った内部リンクを作成します。ランディングページが特定の商品またはサービスに関するものである場合、トピックを議論する関連商品ページ、サービスページ、またはブログ投稿からリンクを追加します。これらの文脈リンクは、ランディングページ自体のコンバージョンに焦点を当てたデザインを乱すことなく、Googleにクロールパスを提供します。
さらに、ランディングページのURLをXMLサイトマップに含めます。サイトマップは内部リンクを必要としない代替の発見チャネルを提供します。サイトマップへの含有だけでは、Googleがランディングページのクロールを優先するのに十分ではないかもしれませんが、他のシグナルと組み合わせてページをGoogleのクロールキューに入れるのに機能します。
サブドメインのランディングページの場合、Google Search Consoleでサブドメインを別途検証し、それのために別のサイトマップを送信します。メインドメインとサブドメインの間でクロスリンクを構築するには、メインサイトからランディングページへの少なくとも1つのリンクと、ランディングページからメインサイトに戻る最小限のフッターリンクを含めます。これにより、2つのプロパティ間にクロールブリッジが確立されます。
A/Bテストと重複ランディングページバージョン
A/Bテストはランディングページの最適化に不可欠ですが、それが作成する複数のページバージョンは深刻なインデックス問題をもたらします。異なる見出し、レイアウト、またはオファーをテストするためにランディングページの2つまたは3つのバージョンを作成すると、各バージョンが独自のURLに存在する可能性があります。Googleは実質的に類似したコンテンツを持つ複数のURLに遭遇し、どれをインデックスするか決定する必要があります。
最も一般的なA/Bテストのセットアップとそのインデックスへの影響は次のように機能します。同じURLで異なるコンテンツを提供するサーバーサイドのA/BテストはGoogleには見えず、インデックスの問題を引き起こしません。Googleは1つのURLと、クロール中に受け取ったコンテンツのバージョンを認識します。ページ読み込み後にJavaScriptを使用してコンテンツを入れ替えるクライアントサイドA/Bテストも、Googleが通常デフォルトバージョンをレンダリングするため、一般的に問題ありません。各バリアント（/landing-page-v1、/landing-page-v2）に異なるURLを使用するURLベースのA/Bテストは、本物の重複コンテンツの問題を生み出します。
URLベースのA/Bテストには、すべてのテストバリアントに、主要なバージョンを指すcanonicalタグを実装します。これにより、Googleに正規URLのみをインデックスし、他のバージョンを重複として扱うよう指示します。テストが終了したら、勝った変種に301リダイレクトで負けた変種をリダイレクトします。期限切れのテストバリアントをそれ自身のURLに残さないでください。時間とともに薄い重複ページとして蓄積されるからです。
URLパラメーター（/landing-page?variant=b）を使用するA/Bテストプラットフォームの場合、パラメーターなしのクリーンURLを指すようにcanonicalタグを構成します。Search Consoleのrobots.txtまたはURLパラメーター設定が、バリアントパラメーターがクロール目的で無視されるべきであることを示すようにしてください。
もっと微妙な問題は、マーケティングチームが正式なA/Bテストの外でも、異なるメッセージングアプローチで同じオーディエンスをターゲットにする複数のランディングページを作成し、すべてのバージョンを同時にライブにしたままにする場合に発生します。わずかに異なるコピーを持つ同じ商品に関する3つのランディングページは、事実上重複コンテンツです。Googleは通常1つだけをインデックスし、他を無視します。1つを主要なランディングページとして指定し、他にそれを指すcanonicalタグを追加するか、各ページが本当に異なる検索クエリをターゲットにするように差別化してください。
UTMパラメーターとURL追跡の汚染
マーケティングランディングページは、UTMパラメーターを含む追跡リンクの最も一般的な宛先です。すべての広告キャンペーン、メールブラスト、ソーシャルメディア投稿、パートナーリンクが、ランディングページURLにutm_source、utm_medium、utm_campaign、その他の追跡パラメーターを追加する可能性があります。これらのパラメーターはユーザーには見えず、アナリティクスの帰属に不可欠ですが、Googleの目には独自のURLを作成します。
ユニークなUTMパラメーターを持つ10のマーケティングチャネルを通じて宣伝された単一のランディングページは、Googleがクロールして評価しようとする可能性のある10の異なるURLを生成します。それぞれが同じコンテンツを含み、重複コンテンツシグナルを生み出します。集約すると、すべてのランディングページにわたるUTMパラメーターURLは、クロールバジェットを浪費する数百の重複URLを生成する可能性があります。
修正は単純ですが、一貫した実装が必要です。すべてのランディングページに、パラメーターなしのクリーンURLを指す自己参照canonicalタグを追加します。canonicalタグは、追加されたパラメーターに関係なく、常にむき出しのURL（https://yourdomain.com/landing-page）を参照する必要があります。これにより、Googleにすべてのパラメーターバリエーションが同じページであり、クリーンなURLのみがインデックスされるべきであることを伝えます。
さらに、Google Search ConsoleのURLパラメーター処理を構成して、UTMパラメーターがページコンテンツを変更しないことをGoogleに通知します。Googleは多くの場合これを独自に正しく処理しますが、明示的な構成は曖昧さを取り除きます。Search Consoleで、レガシーツールセクションに移動し、各UTMパラメーターを「ページコンテンツに影響しない」に構成します。
最も堅牢なソリューションのために、サーバーレベルでUTMパラメーター処理を実装します。Webサーバーまたは CDN を構成して、ページが読み込まれる前にURLからUTMパラメーターを取り除き、クリーンバージョンにリダイレクトします。これは、Googleがパラメーター化されたURLにまったく遭遇しないことを意味します。CloudflareのようなモダンなCDNプロバイダーは、特定のパラメーターを自動的に取り除くことができるエッジレベルのURL書き換えルールを提供します。サーバーサイドの取り除きが実現できない場合、アナリティクスのためにキャプチャした後にURLバーからUTMパラメーターを削除するクライアントサイドJavaScriptは、レンダリングに対して同様の効果を達成しますが、Googleはまだパラメーター化されたURLを最初にクロールする可能性があります。
JavaScript重視のランディングページのレンダリング問題
マーケティングランディングページは、他のページタイプよりもJavaScript重視である傾向があります。価格計算ツール、ROI見積もりツール、商品コンフィギュレーター、アニメーションスクロール効果、動画背景、チャットボットなどのインタラクティブな要素はすべてJavaScriptに依存しています。多くのランディングページビルダーは、ページ全体を単一ページのJavaScriptアプリケーションとして作成し、ページ全体のコンテンツがクライアントサイドでレンダリングされます。
GoogleはJavaScriptを実行できますが、初期HTMLクロールから数時間または数日後にページを処理する可能性のある遅延レンダリングキューでそれを行います。初期クロール中、GoogleはJavaScriptが実行される前の生のHTMLのみを認識します。ランディングページのHTMLがロードスピナーとJavaScriptバンドルを含むほぼ空のシェルである場合、Googleのページの第一印象はコンテンツがないことです。この初期評価は、インデックスを遅延または阻止する可能性があります。
ランディングページのJavaScriptレンダリング問題を診断するには、Google Search ConsoleのURL検査ツールを使用します。ランディングページのURLを入力し、「公開URLをテスト」をクリックします。2つを比較します。Googleが受け取った生のHTML（「詳細情報」セクションで表示）とレンダリングされたページのスクリーンショットです。スクリーンショットが完全なランディングページを示しているが、生のHTMLがほとんど空である場合、コンテンツはJavaScriptレンダリングに依存しています。
最も効果的な修正は、サーバーサイドレンダリングまたはプリレンダリングです。ランディングページがJavaScriptフレームワークで構築されている場合、完全なHTMLをサーバーでレンダリングし、完全に形成された状態でブラウザ（とGoogle）に送信するようにサーバーを構成します。クライアントサイドのみのページを生成するランディングページビルダーの場合、プラットフォームがサーバーレンダリングまたはプリレンダリングのオプションを提供しているか確認します。多くの最新のランディングページプラットフォームは、SEOの懸念に対処するために特にこの機能を追加しました。
サーバーサイドレンダリングが不可能な場合は、動的レンダリングを実装します。この手法は、googlebotがページをリクエストしたときを検出し、通常のユーザーにJavaScriptバージョンを提供しながら、クローラーにプリレンダリングされた静的HTMLバージョンを提供します。Googleは、完全なサーバーサイドレンダリングを実装できないサイトの許容できる慣行として動的レンダリングを認めています。PuppeteerやRendertronのようなツールは、プリレンダリングプロセスを自動化できます。
少なくとも、ランディングページの主要な見出し、主要な価値提案テキスト、コール・トゥ・アクションが、JavaScriptによって注入されるのではなく、初期HTMLレスポンスに含まれていることを確認してください。これらの重要なコンテンツ要素は、計算機やコンフィギュレーターのようなインタラクティブな機能が後で読み込まれる場合でも、Googleに見えるべきです。
サブドメインランディングページと権威の断片化
多くの組織は、組織的、技術的、またはプラットフォーム上の理由で、メインウェブサイトから分離して保つために、サブドメインにランディングページをホストします。マーケティングチームは、ランディングページにgo.yourdomain.com、pages.yourdomain.com、またはlp.yourdomain.comを使用する場合があり、メインサイトはwww.yourdomain.comまたはyourdomain.comに存在します。このサブドメイン分離は、インデックスに直接影響する権威の断片化を生み出します。
Googleはサブドメインを半独立したエンティティとして扱います。サブドメインと親ドメインの間には権威の関連性がいくつかありますが、サブドメインはメインドメインの完全なクロールバジェット、バックリンク権威、または品質シグナルを自動的に継承しません。独自の外部バックリンクがないサブドメインは、まったく新しいドメインと同様に、Googleから非常に限られたクロール割り当てで開始します。
これは、メインドメインに優れた権威と定期的なGoogleクロールがあっても、サブドメインのランディングページが完全に新しいウェブサイトと同じ遅い発見プロセスにとらわれる可能性があることを意味します。Googleはサブドメインがクロールに値することを独立して判断する必要があり、それには独自の発見シグナル、権威シグナル、品質評価のセットが必要です。
SEOにとって推奨されるアプローチは、サブドメインではなくメインドメインのサブディレクトリ（yourdomain.com/landing/またはyourdomain.com/lp/）としてランディングページをホストすることです。サブディレクトリのページは自動的にメインドメインのクロールバジェットと権威を継承し、インデックスが大幅に容易になります。ランディングページプラットフォームがカスタムドメイン構成をサポートしている場合は、メインドメインのサブディレクトリでページを提供するように構成します。
プラットフォームの制約のためにサブドメインホスティングが避けられない場合、権威の断片化を緩和するためにこれらの手順を実行します。Google Search Consoleでサブドメインを別のプロパティとして検証し、独自のサイトマップを送信します。メインドメインとサブドメインの間にクロスリンクを構築します。少なくとも一部の外部バックリンクが、メインドメインだけでなくサブドメインに直接ポイントするようにします。サブドメインのクロール統計を独立して監視し、時間の経過に伴うGoogleのクロール投資を追跡します。
ステップバイステップガイド
すべてのランディングページと現在のインデックスステータスを特定する
サブドメイン、サードパーティプラットフォーム、レガシーキャンペーンのものを含む、サイト上のすべてのランディングページの包括的なインベントリを作成します。各ランディングページについて、Googleで正確なURLを検索するか、Google Search ConsoleのURL検査ツールを使用してインデックスステータスを確認します。各ページを、インデックス済み、クロール済みだがインデックス未登録、検出されたがクロールされていない、またはSearch Consoleで見つからないと分類します。ページが現在アクティブ（キャンペーンからまだトラフィックを受信している）か休眠中（キャンペーン終了したがページはまだ稼働中）かも記録します。このインベントリは、インデックス問題の範囲を明らかにし、修正の優先順位付けに役立ちます。
孤立ページと不足している内部リンクを確認する
インデックスされていない各ランディングページについて、サイトの他のページからそれにポイントする内部リンクの数を判断します。クロールツールからサイトの内部リンクレポートを表示するか、サイトのコンテンツでランディングページのURLを検索して手動で確認します。ランディングページに内部リンクがゼロの場合、それは孤立しており、Googleが通常のサイト探索を通じてそれを発見するクロールパスがありません。各孤立ランディングページに、メインサイトの関連ページから文脈リンクを追加します。ランディングページと同じトピックを議論するブログ投稿、サービスページ、リソースページは、理想的なリンクソースです。追加の発見チャネルとして、ランディングページをXMLサイトマップに含めてください。
A/Bテストの重複バージョンを監査し修正する
互いのバリエーションであるすべてのランディングページのURLをリストします（A/Bテストバリアント、地域バージョン、季節バージョン）。類似ページの各セットについて、1つを正規バージョンとして指定します。すべてのバリアントURLに、正規バージョンを指すcanonicalタグを追加します。終了したA/Bテストの場合、勝った方に負けたバリアントを301リダイレクトします。まだ実行中のA/Bテストの場合、テストプラットフォームが別々のURLではなくサーバーサイドまたはJavaScriptベースのコンテンツスワッピングを使用していることを確認します。別々のURLが必要な場合、canonicalタグが不可欠です。もう使用されていない放棄されたテストページを削除またはリダイレクトしてください。
UTMパラメーター処理のためのcanonicalタグを実装する
すべてのランディングページに、クリーンなURL（UTMまたは追跡パラメーターなし）を指す自己参照canonicalタグがあることを確認します。各ランディングページのHTMLソースでcanonicalタグを確認します。canonicalタグがパラメーターを含むか、間違ったURLを指している場合は修正します。サードパーティプラットフォーム上のランディングページの場合、canonicalタグの構成についてプラットフォームのSEO設定を確認します。ランディングページURLにさまざまなUTMパラメーターを追加し、ブラウザのアドレスバーのパラメーターに関係なく、HTMLソースのcanonicalタグがクリーンURLを指していることを確認することでテストしてください。
インタラクティブなランディングページのJavaScriptレンダリングをテストする
JavaScript重視のインタラクティブ性を使用する各ランディングページについて、URL検査ツールの「公開URLをテスト」機能を使用してGoogleが見るものをテストします。レンダリングされたスクリーンショットとHTMLソースを確認します。メインの見出し、価値提案、お客様の声、または機能の説明が生のHTMLにない場合、Googleの最初のクロールパスはコンテンツのないページを認識します。これらのページにサーバーサイドレンダリングまたはプリレンダリングを実装します。それが実現不可能な場合、少なくとも主要なテキストコンテンツ（見出し、サブ見出し、主要なセールスポイント）を、JavaScriptを介して注入するのではなく、静的HTMLテンプレートに移動してください。
サブドメインの権威問題に対処する
ランディングページがサブドメインにある場合、Google Search Consoleで各サブドメインを別途検証し、サブドメイン固有のサイトマップを送信します。メインドメインからサブドメインランディングページへの内部リンクを追加し、その逆も同様です。サブドメインプロパティのクロール統計を確認して、Googleがアクティブにクロールしているかを確認します。可能であれば、優先度の高いランディングページをサブドメインからメインドメインのサブディレクトリパスに移行します。サブドメインに残る必要があるページについては、独立した権威を高めるために、サブドメインURLに直接ポイントする外部参照（ソーシャルプロフィール、ディレクトリリスト、パートナーリンク）を構築してください。
最適化されたランディングページを高速インデックスのために送信する
構造的、重複、レンダリングの問題を解決した後、ランディングページをインデックスのために送信します。今後のローンチのためにGoogleのインデックスに入る必要がある時間的に敏感なキャンペーンページの場合、Googleの自然なクロールサイクルを待つのではなく、即時の一括送信のためにIndexBoltを使用してください。常緑のランディングページの場合、Google Search ConsoleのURL検査ツールを通じて送信し、次の週にわたってインデックスの進捗を監視します。送信後48時間にインデックスステータスをチェックし、インデックスされないままのページをトラブルシューティングするカレンダーリマインダーを設定してください。
よくある問題と解決方法
ランディングページプラットフォームがデフォルトでnoindexタグを生成する
原因： 一部のランディングページビルダー（Unbounce、Leadpages、Instapage）には、下書きまたはテストページが誤ってインデックスされないように、ページにnoindexタグを追加するデフォルトのSEO設定があります。デフォルト設定を変更したことがない場合、公開されたページにはまだnoindexディレクティブが含まれている可能性があります。一部のプラットフォームは、ページが本番使用を目的としていても、デフォルトのサブドメイン（yourpage.platform.com）のページにnoindexを追加します。
解決方法： ランディングページビルダーのダッシュボードで各ページのSEOまたはインデックス設定を確認します。「検索エンジンの可視性」、「SEO」、または「インデックス」というラベルのオプションを探します。設定がインデックスを許可するように構成されていることを確認します。次に、ページのHTMLソースを表示し、「noindex」を検索して設定変更が反映されたことを確認します。カスタムドメインを使用している場合、プラットフォームがデフォルトの動作としてカスタムドメインページにnoindexを追加していないことを確認してください。
ランディングページのコンテンツがメインサイトのページと同一
原因： マーケティングチームは、メインサイトの既存のサービスページ、商品ページ、またはaboutページのコンテンツを複製するランディングページを作成することがあります。Googleは同じコンテンツを持つ2つのURLに遭遇し、より多くの権威を持つもの（通常はメインサイトページ）をインデックスし、ランディングページをスキップします。これは、ランディングページが既存のページをコピーし、テキストコンテンツを変更せずに小さなレイアウト変更のみを行うことで作成される場合に特に一般的です。
解決方法： ランディングページのコンテンツをメインサイトのページと差別化します。ランディングページには、対応するメインサイトのページとは異なる、ユニークな見出し、特定のキャンペーンオーディエンスに合わせたユニークなコピー、異なる構造要素（お客様の声、ソーシャルプルーフ、オファー）が必要です。コンテンツが類似している必要がある場合、メインページをランクインさせたい場合はメインサイトページを指すcanonicalタグをランディングページに使用するか、ランディングページが優先インデックスターゲットの場合はその逆を使用します。
キャンペーン終了後にキャンペーンランディングページがGoogleから削除される
原因： 有料キャンペーンが終了すると、ランディングページはトラフィックの受信を停止します。時間の経過とともに、Googleはトラフィック、バックリンク、内部リンクを受け取らないページのインデックスを解除する可能性があります。ページはまだサーバー上で稼働していますが、Googleは品質メンテナンスの一環としてインデックスから削除します。これは、特定の時間期間中にのみ関連するプロモーションランディングページに特に一般的です。
解決方法： キャンペーン終了後も関連性が残る常緑のランディングページの場合、Googleのクロールサイクルに保つために、メインサイトからそれらへの内部リンクを維持します。コンテンツを新鮮に保つために定期的に更新します。本当に時間制限のあるプロモーション（ブラックフライデー、季節セール）の場合、プロモーションの次回開催に合わせてページを更新するか、キャンペーン中にランディングページが蓄積したリンクエクイティを保持するために、関連する常緑ページに301リダイレクトしてください。
サードパーティプラットフォーム上のランディングページがドメイン権威を継承しない
原因： 外部プラットフォームでホストされているランディングページ（プラットフォームのCNAMEを介したgo.yourdomain.comまたはyouraccount.platform.com）は、メインドメインの検索権威を継承しません。カスタムサブドメインを使用しても、サブドメインにはほぼゼロから始まる独自の独立した権威プロファイルがあります。サブドメインへのGoogleのクロール投資は、親ドメインの権威ではなく、独自の権威に比例します。
解決方法： 可能であれば、重要なランディングページをサブディレクトリページとしてメインドメインに移行します。プラットフォーム移行が実現不可能な場合、メインサイトからリンクし、ソーシャルプロフィールやディレクトリリストに含め、サブドメインに独自のSearch Console検証とサイトマップがあることを確認することで、サブドメインの権威を独立して構築します。優先度の高いランディングページの場合、サブドメインのオーガニッククロールレートが改善するのを待つのではなく、即時のインデックスのためにIndexBolt経由でURLを送信してください。
プロのヒント
よくある質問
PPCランディングページをオーガニック検索用にインデックスさせる試みすらすべきですか？+
はい。高パフォーマンスのPPCランディングページは、オーガニック需要のあるキーワードもターゲットにしていることがよくあります。それをインデックスさせると、有料と並んで無料のオーガニックトラフィックが生成され、獲得単価が削減されます。例外：薄いページ（フォームと見出しだけ）またはメインサイトページを複製するコンテンツです。それらの場合、コンテンツを充実させるか、メインページにcanonicalタグを追加してください。
ランディングページからナビゲーションを削除するとSEOに悪影響を与えますか？+
内部リンク構造からページを削除することで発見可能性に悪影響を与えますが、完全なナビゲーションなしでこれを緩和できます。関連するコンテンツページから文脈リンクを追加し、ページをサイトマップに含め、最小限のフッターリンクを追加してください。1つまたは2つの内部リンクパスとサイトマップエントリは、インデックスには十分です。
異なるトラフィックソースに対して異なるコンテンツを持つランディングページをどのように処理しますか？+
デフォルトバージョン（リファラル情報なし）に最も強力なコンテンツが含まれていることを確認してください。それがGoogleが見るものだからです。サーバーサイドのリファラーベースのロジックではなく、ページ読み込み後にDOMを変更するJavaScriptベースのパーソナライゼーションを使用してください。Googleのクローラーは広告プラットフォームのリファラーヘッダーを送信しません。URL検査ツールでテストして確認してください。
異なるUTMパラメーターを持つ複数の広告キャンペーンに同じランディングページを使用できますか？+
はい、そしてこれが推奨されます。異なるUTMパラメーターを持つ1つの正規URLは、すべての権威を集約します。canonicalタグは常にパラメーターなしのクリーンURLを指す必要があります。アナリティクスプラットフォームは、パラメーターが取り除かれる前にUTMをキャプチャします。コンテンツが本当に異なる場合を除き、キャンペーンごとに別々のランディングページURLを避けてください。
私のランディングページにはフォームがありますが、テキストコンテンツがほとんどありません。Googleがそれをインデックスするのに十分ですか？+
おそらくいいえ。Googleがページを理解し評価するには十分なテキストが必要です。フォームの周りにサポートコンテンツを追加します。送信後に何が起こるかを説明し、利点をリストし、ソーシャルプルーフ（お客様の声、ロゴ、統計）を含め、簡単なFAQを追加します。**300〜500語**のユニークなテキストを目指してください。フォームとインタラクティブな要素は、Googleの視点からはコンテンツではありません。
古い、期限切れのキャンペーンランディングページがクロールバジェットを浪費するのをどのように防ぎますか？+
四半期ごとの監査を実行します。各休眠ページについて、決定します。アクティブなページに301リダイレクト、コンテンツの更新、または410 Goneを返します。リダイレクトされたURLをサイトマップから削除します。オーガニックトラフィックのためにライブを保持するページは、価値を提供する必要があります（現在の価格、新鮮なお客様の声、期限切れのオファーなし）。