プロンプトとコンテキスト
多言語サイトに公開ページ、認証が必要なページ、一時的なプレビューページが存在します。チームはプレビューパスをDisallowでrobots.txtに追加し、ページにnoindexを追加した上で、すべての言語で1つのcanonical URLを使用しました。ローンチ後、プレビューURLが依然として検索結果に表示され、一部の言語ページで誤ったインデックスURLが登録されています。3つのシグナルの境界を説明し、マイグレーションと検証の計画を提案してください。
面接官がテストしているポイント
- クロール、インデックス登録、優先URLの選択を区別できているか。
- robots.txtでブロックされたクローラーはnoindexを認識できない可能性があることを理解しているか。
- HTMLのmeta robots、HTTPの
X-Robots-Tag、canonical、リダイレクト、競合を適切に処理できるか。 - 多言語、キャッシュ、ロールバック、Search Consoleのチェックを設計できるか。
最初に確認すべき明確化のための質問
- 目的はクロールのブロックですか、インデックスのブロックですか、それとも重複URLの正規化ですか？
- 検索クローラーはそのページのnoindexまたはcanonicalを検出するためにページを取得（フェッチ）する必要がありますか？
- プレビューページは認証が必要ですか？また外部リンクやサイトマップがそれらを参照する可能性はありますか？
- 各言語ページは1対1の翻訳関係にあり、独自のcanonicalとhreflangを持っていますか？
- これらのヘッダーやタグはCDN、アプリケーションサーバー、HTMLテンプレートのどこで設定されていますか？
30秒の回答フレームワーク
私はクロール、インデックス登録、正規化（カノニカル化）を分離して考えます。robots.txtはクローラーがリソースをリクエストできるかどうかを制御し、noindexはフェッチされたページがインデックスに入るかどうかを制御します。canonicalは重複またはほぼ重複するURLに対する優先度の指定であり、リダイレクトではありません。プレビューページは認証を設定するか、noindexを付与してクロール可能にする必要があります。本番環境の言語ページは自己参照のcanonicalを設定し、hreflangで相互参照させるべきです。レンダリングされたレスポンス、クローラーのアクセス、キャッシュの挙動、Search Consoleのレポートを検証します。
ステップごとの詳細な回答
ステップ1：3つの制御プレーンを定義する
サイトルートのrobots.txtは、クローラーがパスをリクエストできるかどうかを決定します。インデックス登録済みのURLを削除することはなく、外部リンク経由で検出されたURLが検索結果から確実に除外されることを保証しません。noindexは、プレビュー、検索結果、その他の非公開ページに対するページレベルのインデックス登録ディレクティブです。canonicalは、重複またはほぼ重複するコンテンツのURL選択シグナルです。
ステップ2：Disallowの背後にnoindexを隠さない
パスがDisallowされている場合、クローラーはページをフェッチしない可能性があるため、meta robotsタグやX-Robots-Tag: noindexを確認できません。noindexを認識可能にするには、クロールを許可し、HTMLまたはHTTPヘッダーでnoindexを返します。機密性の高いコンテンツには、クローラーディレクティブではなく認証または認可が必要です。マイグレーション中は、クロールブロックを解除し、再クロールとインデックスの更新を待ちます。
ステップ3：ページレベルのnoindex伝達手段を選択する
HTMLにはmeta name="robots" content="noindex,follow"を使用でき、非HTMLリソースやゲートウェイにはX-Robots-Tagを使用できます。テンプレートとレスポンスヘッダーをテストし、CDNの古いオブジェクトを無効化（パージ）します。followは、インデックスから除外したいページのリンク検出を維持できますが、アクセス制御ではないため、通常のクローラーの動作が適用されます。
ステップ4：canonicalと言語マッピングを設計する
インデックス可能な各言語ページには、一般的にステータス、スキーム、ホスト、パスが一貫した、絶対パスでアクセス可能な自己参照のcanonicalを設定する必要があります。すべての翻訳ページでデフォルト言語をcanonicalに設定しないでください。翻訳が重複として統合されてしまう可能性があります。代替バージョンにはhreflangを使用し、サイトマップ、内部リンク、canonicalで同じ正規URLセットを使用するようにします。
ステップ5：マイグレーション、リダイレクト、キャッシュを処理する
URLのマイグレーションにはサーバーサイドの恒久的なリダイレクトを使用します。古いページのcanonicalはリダイレクトの代わりにはなりません。サイトマップを送信する前に、新しいページの200レスポンス、canonical、robotsディレクティブ、hreflangを検証します。エッジ間で整合性が取れるように、URLとヘッダーによってCDNレスポンスを無効化します。ロールバックの際は、バージョンが混在して公開されないように、古いリダイレクトとインデックスポリシーを保持する必要があります。
ステップ6：観察可能な診断パスを構築する
まずrobots.txtのアクセスを確認し、次にライブのHTMLとレスポンスヘッダーを検査して、noindexとcanonicalがテンプレートと一致しているか比較します。続いてSearch Consoleのクロールとインデックスのステータス、Googleが選択したcanonical、最終クロール日時、サイトマップによる検出を検査します。監査可能性を確保するために、URL、言語、ステータス、canonical、robotsディレクティブ、キャッシュ経過時間、リリースバージョンをログに記録します。
ステップ7：受け入れテストとリグレッションテストを定義する
ページタイプごとにアサーションを作成します。プレビューはクロール可能でnoindex、本番の言語ページは200を返して自己参照canonicalを持つ、古いURLは新しいURLに301転送される、保護されたページはコンテンツを漏洩しない、などです。大文字小文字や末尾スラッシュの境界に関するrobotsルール、HTML/ヘッダーの競合、マルチエッジのキャッシュ無効化、サンプリングしたSearch Consoleの状態をテストします。
高品質な回答サンプル
各シグナルは異なる問題を解決します。robots.txtはリクエストを制御し、noindexはインデックス登録の有無を制御し、canonicalは重複の中から優先URLを提案します。プレビューページをブロックした上でnoindexを認識させることはできません。クローラーがnoindex付きでフェッチできるようにし、機密情報には認証を使用してください。本番の各言語ページは自己参照canonicalを持ち、hreflangを使用し、サイトマップと内部リンクが一致している必要があります。マイグレーションには301リダイレクトを使用し、robots、ライブレスポンス、キャッシュ、クロールログ、Search Consoleをレイヤーごとに検証します。
よくある間違い
- robots.txtを確実なインデックス削除メカニズムとして扱う。
- ページをブロックしながら、クローラーがそのnoindexを読み取ることを期待する。
- すべての言語ページでcanonicalを1つの言語に向ける。
- CDNヘッダーや古いキャッシュオブジェクトを無視して、ソースHTMLのみを確認する。
- 必要なリダイレクトやアクセス制御の代わりにcanonicalを使用する。
フォローアップの質問と回答
フォローアップ1：ブロックされたURLが検索結果に表示されることがあるのはなぜですか？
クローラーが外部リンク経由でそのURLを検出したものの、コンテンツをフェッチできない場合があります。検索エンジンは依然としてURLや限定的な情報を表示することがあります。インデックス登録をブロックするには、ページをnoindex付きでフェッチ可能にするか、認証を要求してください。
フォローアップ2：canonicalは強制的な指示ですか？
これは無視される可能性があるシグナル（ヒント）です。コンテンツ、リダイレクト、内部リンク、サイトマップ、canonicalタグは一致している必要があります。canonicalはアクセス制御や削除保証ではありません。
フォローアップ3：プレビューがリンクを通じて検出可能である必要がある場合はどうしますか？
クロールを許可し、noindexを返します。プレビューに機密性がある場合は、ログイン、署名付きURL、またはその他のアクセス制御メカニズムを使用します。機密を隠すためにrobots.txtに依存しないでください。
フォローアップ4：HTTPヘッダーとmeta robotsの競合はどのように解決しますか？
両方を単一のページポリシーソースから生成し、オリジンとエッジのレスポンスをサンプリングします。どちらのシグナルが優先されたかを推測するのではなく、実際のレスポンス、HTML、対象の検索エンジンのドキュメントを確認した上で、明示的なポリシーを1つ出力します。
フォローアップ5：多言語のcanonicalループはどのようにテストしますか？
各言語のURLをフェッチし、絶対パスでアクセス可能な自己参照canonicalを検証します。次にhreflangの相互参照と言語コードを検証し、サイトマップや内部リンクが古いホストや誤った言語を指していないことを確認します。