2025年の新ルール：XMLサイトマップを送信してもインデックスされない理由｜知っておくべき3つの原因

あなたのウェブサイトはXMLサイトマップ（Sitemap）を提出したのに、数週間、あるいは数ヶ月経ってもGoogleで「site:あなたのドメイン.com」を検索すると、表示されるページ数が非常に少ないですか？

慌てないでください、これはよくあることです。

Google公式のデータによると、新しく提出されたURLが発見されて最終的にインデックスされるまでには、通常数日から数週間かかります。

実際、Search Consoleのバックエンドレポートによると、60％以上のウェブサイト所有者が、サイトマップを初めて提出した後に「検出されたがインデックスされていない」URLが多いという問題に直面しています。

多数のケース分析により、Googleがインデックスしない主な障害は、3つの具体的かつ対処可能な問題に集約されることが判明しています：

あなたのサイトマップはGoogleに「読めない」か、使われていません

Search Consoleのデータによると、サイトマップを提出したサイトの平均5件に1件は「取得できません（Couldn’t Fetch）」というエラーが発生しています。

これは何を意味するのでしょうか？Googleのクローラーがあなたが提出した「目録」を開けず、または途中で読み込みが止まったことを意味します。

さらに悪いことに、サイトマップが「正常に処理されました」と表示されても、中にあるリンクの半分以上が「行き止まり」（404エラー）か「間違った道」（リダイレクト）かもしれません。

サイトマップのアクセス性

核心問題： あなたがサイトマップのURL（例えば yoursite.com/sitemap.xml）を提出しましたが、Googlebotがこのアドレスにアクセスしようとしたときに、サーバーがまったくアクセスを許可しません！

実際の発生例とデータ：

• 404 Not Found： Search Consoleのサイトマップレポートに「取得できません」と直接表示されます。このケースは提出エラーの約25〜30％を占めます。よくある原因は、ファイルパスの誤り（大文字・小文字の区別）、ファイルの削除、サイトリニューアル後のパス未更新、サーバー設定ミスなどです。
• 500 Internal Server Error / 503 Service Unavailable： サーバーがダウンしていたり内部エラーが発生している場合。Googleは再試行しますが、サーバーが頻繁に不安定だとサイトマップの処理状況は長期間エラーが続きます。繰り返しの取得失敗はGoogleがサイトの全体的な「健全性」を判断する際に悪影響を及ぼします。
• アクセス権限の問題： サイトマップファイルがログイン必須やIPホワイトリスト制限のあるディレクトリに置かれている場合。Googleクローラーは「匿名訪問者」なのでアクセスできません。

どうやって確認する？

• 最も簡単なのは、ブラウザで提出したサイトマップURLを直接開いてみることです。 XMLコンテンツが正常に表示されますか？
• Search Console > サイトマップレポート： 提出したサイトマップの状態が「成功」か「取得できません」か確認してください。後者の場合、具体的なエラー情報（404？500？権限エラー？）が表示されることが多いです。

今すぐやるべきこと：

• 提出したサイトマップのURLが100％正確であることを確認してください。
• 匿名ウィンドウ（ログインなし）でもアクセスできるか確認してください。
• サーバーの安定性問題を解決してください。500エラーが出る場合は技術担当者にサーバーログの調査を依頼しましょう。

コンテンツの有効性

核心問題： サイトマップに載っているURLが死んだリンクやリダイレクトページである場合、Googleクローラーはリソースを無駄にし、有効なコンテンツを得られません。

よくある問題とデータ： Search Consoleのサイトマップレポートで、「送信されたURL」欄の隣に「エラー」や「警告」のあるURL数がはっきりと表示されます。

多くのサイトで、この「エラー率」は簡単に50％を超え、時には80％に達することもあります！ 主な種類は以下の通りです：

• 404 Not Found： 最も一般的！ ページが削除されたのにサイトマップが更新されていない、製品が販売終了したのにURLが削除されていない、URLパラメータのバージョン違い、タイプミスなど。Googleクローラーが無駄に巡回します。このエラーは優先度が高いです。
• 301/302 リダイレクト： サイトマップに古いURL Aがあり、そのURLが新しいURL Bにリダイレクトされます。
  • 問題点は？ GoogleはURL Aを追加でクロールしないと新しいURL Bを知ることができません。
  • Googleはサイトマップに直接最終目的地のURL Bを入れることを望んでいます。こうすることでクロール予算をより効率的に使えます。
  • この種のエラーが多いと、サイト全体の重要ページのクロールとインデックス速度が遅くなります。
• ログイン必須・アクセス制限ページ： 会員センター、注文履歴、管理画面のURLが誤ってサイトマップに入っている場合。Googleは訪問者としてこれらを見ることができないため、役に立ちません。

どうやって確認する？

• Search Consoleのサイトマップレポートのエラー詳細をしっかりチェックしよう！ どのURLでどんなエラー（404、リダイレクトなど）があるか具体的に教えてくれます。
• Screaming Frogなどのクロールツールを使って、定期的にサイトマップ内のURLをスキャンし、ステータスコードを確認しよう。特に200以外のステータスコードには注意！

今すぐやるべきこと：

• サイトマップを定期的に整理しよう！ 404が返るURLやログインが必要なページは全部削除しよう。
• サイトマップ内のURLは最終的な正しいURLを指すようにしよう！ 全てのURLは直接200 OKを返すこと。もしリダイレクトがあるなら、サイトマップを更新して最終的なURLに変えておこう。
• 関係ないURLや無効なURLは入れないで！ Googleにインデックスしてほしい、ユーザーに見せたい実質的なコンテンツがある公開ページだけ入れよう。

フォーマットのルール

問題の本質： サイトマップファイル自体がXMLの文法やサイトマップのプロトコルに合っていないと、Googleのパーサー（汚い字を読むようなもの）が URL情報を正しく読み取れなくなります。

よくあるエラー：

• XML文法エラー：
  • タグが閉じていない： 例えば https://... が で閉じられていない。
  • 不正な文字： URL内の & は & にエスケープされていなければなりません。特定の特殊文字は必ずエスケープが必要です。
  • エンコードの問題： ファイルの文字エンコード（UTF-8やShift_JISなど）が宣言と合っていなかったり、一貫性がないと、日本語などの特殊文字が文字化けします。
• プロトコル構造のエラー：
  • や といった必要なルートタグが欠けている。
  • 必須タグが欠けていたり順序が間違っている：各 エントリーには （場所タグ）が必須です。 また、オプションのタグ（, , ）を使う場合は正しい位置に入れる必要があります。
  • サイトマップのプロトコルでサポートされていないタグや属性を使っている。

どれくらい影響があるの？ たとえ 0.5%のエラー率（1000件中5件のエラー）でも、サイトマップ全体が 「部分的なエラー」または完全に無効と判断されることがあり、中のURLが正常に読み取れなくなります！Googleのログには解析エラーが特定の行で止まったとよく出ます。

どうやってチェックする？

• 専門のサイトマップ検証ツールを使う： 例えば XML Validator（オンラインで検索）や、検索エンジン公式ツール（Google Search ConsoleのURL検査ツールは単一URLには有効ですが、サイトマップ全体の検証には限界があります）。
• サンプルを手動でチェックする： VSCodeなどのテキストエディタでサイトマップファイルを開き、タグがきちんと閉じられているか、特殊文字が適切にエスケープされているかを確認しましょう。特に最近追加・変更したURLを重点的にチェック。エディタがXML文法エラーを警告してくれることもあります。

今すぐやるべきこと：

• 信頼できるサイトマップ生成ツールやプラグインを使う（SEOプラグインやCMS内蔵機能、専用ジェネレーターなど）。手書きは避けましょう。
• 生成後は必ず検証ツールでフォーマットをチェックする。
• 手動で編集する場合はXML文法とサイトマッププロトコルを厳守する。

ファイルが大きすぎないか？

重要なポイント： Googleは明確に制限しています：1つのサイトマップファイルは最大50MB（非圧縮時）または50,000 URLまで（先に到達した方が適用されます）。これを超えるとファイルは無視されたり、一部だけ処理されたりします。

実際の経験から：

• ECサイトや大量のコンテンツを持つフォーラム・メディアサイトはこの制限を超えやすいです。
• 多くのCMSプラグインはデフォルトで大きすぎるサイトマップを生成することがあるので、分割が必要な場合があります。
• ファイルサイズが制限内でも、数万URLの巨大なサイトマップは小分けしたものより処理効率が悪く、Googleの処理に時間がかかります。

どうやって確認する？​​

• ファイルのプロパティを確認：サイズは50MBを超えていますか？
• ツールやスクリプトを使ってファイル内のURLの数を集計。5万件以上ありますか？

今すぐやるべきこと：​​

• ​​大規模サイトは必ずインデックスサイトマップを使うこと！​​
  • メインのインデックスファイル（例：sitemap_index.xml）を作成し、URLを直接入れるのではなく、個々の小さなサイトマップファイルのパス（例：sitemap-posts.xml、sitemap-products.xml）を一覧にします。
  • ​​このインデックスファイル（sitemap_index.xml）をGoogle Search Consoleに提出してください。​​
• 記事、商品、カテゴリなど、URLの種類ごとに別々の小さいサイトマップに分ける。
• 各小さいサイトマップファイルのサイズとURL数が制限内に収まっていることを確認する。

インデックスサイトマップ

よくある問題点：​​ インデックスサイトマップ（sitemap_index.xml）は提出したけど、そこに記載されている小さいサイトマップ（sitemap1.xml、sitemap2.xmlなど）に問題がある（パスの間違い、アクセス不可、フォーマットエラーなど）。目次はあるけど、実際のページが見つからないか壊れているような状態です。

よくあるミス：​​

• インデックスファイルに記載されている小さいサイトマップのパスが相対パス（例：<loc>/sitemap1.xml</loc>）になっているが、必ず完全な絶対URL（例：<loc>https://www.yoursite.com/sitemap1.xml</loc>）にしなければならない。
• 小さいサイトマップ自体に前述のような問題（404、500、フォーマットミス、サイズオーバーなど）がある。

影響：​​ インデックスが指す小さいサイトマップに問題があると、Googleがその中のURLをクロールできず、サイトマップ提出が意味をなさなくなります。

どうやって確認する？​​

• Search Consoleでインデックスサイトマップを提出後、ステータスを確認する。処理は成功しているのに、「検出されたURL」の数がすべての小さいサイトマップにあるはずのURL数よりかなり少ない場合は、小さいサイトマップに問題がある可能性が高い。
• ​​インデックスサイトマップの詳細レポートを開くと、中に含まれる各小さいサイトマップの状態が表示されます。​​一つずつチェックしてエラーを確認しましょう。

今すぐやるべきこと：​​

• インデックスファイルに書かれているすべての小さいサイトマップのURLが完全な絶対URLであることを確認する。
• インデックスに記載された各小さいサイトマップファイルが正常（アクセス可能、リンク切れなし、フォーマット正しい、サイズ制限内）であることを確認する。

Googleのクローラーがあなたのページをそもそも「見れていない」場合

サイトマップは正常に提出できているのに、Search Consoleの「カバレッジ」レポートでページのステータスが「検出されたがインデックス未登録」や「クロール済みだが現在インデックス未登録」となっている場合。

原因はたいていここにあります：​​Googlebotがページの中身を正常にアクセスできていない​​。

これは決して大げさではありません — 実際にクライアントのケースを分析すると、​​インデックス問題の40%以上はクロール段階で止まっている​​のです。

robots.txtがクローラーをブロックしていないか？

よくある問題点：​​ robots.txt はサイト入口の警備マニュアルのようなものです。一行の間違った Disallow: 指令でGooglebot（Googlebot）をサイト全体や重要なディレクトリから締め出してしまうことがあります。アドレスは知っていても「立ち入り禁止」になってしまうわけです。

よくある誤設定＆警告サイン：​​

• ​​サイト全体をブロックしてしまう大事故：​​ Disallow: /（スラッシュ一つだけ）。これは私たちがサイトをチェックするときに最もよく見かける致命的なミスの一つで、テスト設定のまま放置されたり、誤操作で設定されたりしています。​​Search Consoleのカバレッジレポートで多数のURLが「ブロックされた」と表示されたり、そもそもURLが現れない場合はこれが最有力候補です。​​
• ​​重要なリソースやディレクトリがブロックされている場合：​​
• CSS/JSパスをブロック：Disallow: /static/ または Disallow: /assets/。検索エンジンのクローラーはスタイルがなく、レイアウトが崩れたり、重要な機能が欠けているページを見てしまい、品質が低いと判断してインデックスを諦めることがあります。
• 商品や記事のカテゴリをブロック：Disallow: /category/、Disallow: /products/。クローラーがこれらの重要なコンテンツ領域に入れないため、多くのページがあっても発見されません。

確認はとても簡単です！

ブラウザで https://あなたのドメイン/robots.txt にアクセスし、各行の指示をよく確認してください。

Search Console の robots.txt テストツール：

1. robots.txt の内容を入力するか、ファイルパスをアップロードします。
2. Googlebot を指定してテストします。
3. ホームページや商品ページ、記事ページなどの重要なURLをいくつか入力します。
4. 結果が 「許可」（Allowed） かどうかを確認してください。もし 「ブロック」（Blocked） と表示されたら、該当する Disallow ルールをすぐに見つけて修正しましょう！

今すぐやるべきこと：

• Disallow: ルールを緊急点検： サイト全体（/）や重要なコンテンツやリソースフォルダが誤ってブロックされていないかを確認します。
• 精密なブロック、ワイルドカードの乱用を避ける： 管理画面やプライバシーポリシーのドラフトページ、検索結果ページなど、実際にブロックが必要なパスだけを指定しましょう。パラメータ付きURLについては、まずは rel="canonical" や Search Console の URLパラメータ設定で管理することを優先してください。
• テスト後に公開： robots.txt を編集したら、必ず Search Console のテストツールで重要ページの「許可」状態を確認し、問題がなければ公開しましょう。

ページの技術的な読み込み失敗や非常に遅い場合

根本的な問題： Googlebot が訪問しても、サーバーが応答しない（クラッシュ）、遅すぎる（タイムアウト）、あるいはページは表示されるが中身が空（レンダリング失敗）で、実質的なコンテンツが取得できません。

実際のクロール失敗の兆候と関連データ：

• 5xx サーバーエラー（503、500、504）： これは Google の クロールログでよく見られます。特に 503（サービス利用不可）はサーバーの一時的な過負荷やメンテナンスを示します。連続するクロール失敗は Google がクロールの優先度を下げる原因になります。 トラフィックが多いサイトやホスティング資源が不足している場合に発生しやすいです。
• 接続タイムアウト/読み込みタイムアウト： クローラーがリクエストしてから30秒以内（時にはそれより短い時間）に完全なレスポンスを受け取れない場合です。サーバー設定の問題（PHPプロセスの停止など）、遅いDBクエリ、リソースファイルの読み込み遅延が原因のことがあります。Search Console の「ページエクスペリエンス」やログ解析で遅いページやエラー率を確認できます。
• 4xx クライアントエラー（404を除く）： 例えば 429（リクエスト過多） はサーバーのクロール制限やレートリミットが作動し、Googlebot を拒否していることを意味します。 これらのIPレンジをホワイトリストに入れる必要があります。
• JavaScriptレンダリングが「空白ページ」になる： サイトがJSに大きく依存している場合、GooglebotがJSの実行待ちで タイムアウトしたり、JSエラーでレンダリングに失敗し、中身のほとんどないHTMLの枠だけを見てしまいます。

すぐにやるべきこと：

• ホームページ／コアナビゲーションの内部リンク強化： ホームページの目立つ場所に、重要なコンテンツ入口（新しい記事、人気商品、主要カテゴリー）を標準のHTMLリンクで表示してください。すべての重要なリンクをインタラクティブな要素の背後に隠さないようにしましょう。
• 明確なサイト階層構造の構築：
  • ホーム > 大カテゴリー（パンくずリスト対応） > 小カテゴリー／タグ > 具体的なコンテンツページ。
  • 各階層に豊富で関連性のある内部リンクが相互に繋がっていることを確認してください。
• 「孤立ページ」に橋をかける： 関連する記事ページやカテゴリーのサイドバー、HTMLサイトマップに、重要だけれどリンクが不足している「孤立ページ」へのリンクを追加しましょう。
• JS生成のナビゲーションに注意： JavaScriptに依存したナビゲーションやページネーション、「もっと見る」などの機能には、必ずHTMLのフォールバック（例：従来のページリンク）を用意するか、コアナビゲーションのリンクが初期のHTMLソースに存在していることを保証してください（AJAXで後から読み込む形ではなく）。
• パンくずナビゲーションを活用する： ユーザーの現在位置を明確に表示し、クローラーにサイトの階層構造を知らせます。
• XMLサイトマップの作成と送信： 良い内部リンク構造の代わりにはなりませんが、クローラーが深いページを発見するために依然重要です（HTMLサイトマップが機能していることが前提）。

Googleが「価値がない」と判断するウェブページ

Google公式のデータによると、クロールはされてもインデックスされなかったページの30%以上は、コンテンツの価値不足や品質問題でフィルタリングされています。

Search Consoleの「カバレッジレポート」を詳しく見ると、「重複」、「正規ページがある代替ページ」、「低品質コンテンツ」などにマークされたURLは、ほとんどがコンテンツ自体に問題があります：

• 情報が非常に薄い
• 他サイトからコピーして新規性がない
• ユーザーが理解できないキーワードの詰め込みばかり

Googleの主な使命は、ユーザーに対して有用で独自性があり信頼できる結果を提供することです。

情報が不足し、実質的な価値がないコンテンツ

主な問題： ページに含まれる情報が非常に限られていて独創性がなく、ユーザーの実際の問題を解決できない。まるで「透明な紙」のようで、Googleのアルゴリズムはこれを「低価値コンテンツ」と判断します。

よくある「価値のないページ」タイプと警告サイン：

「プレースホルダ」ページ： 「製品はもうすぐ発売」、「カテゴリに商品なし」、「近日公開予定」などの実質的な内容がないページ。サイトマップに送信されているかもしれませんが、実は中身のない空っぽのページです。

「終点」ページ： フォーム送信後の「ありがとう」ページ（単なるテキストの感謝メッセージで、後続の案内がない）、購入完了ページ（注文番号のみで、発送追跡やFAQリンクがない）。ユーザーはすぐに離脱し、Googleは個別にインデックスする必要がないと判断します。

過度な「モジュール化」／「分割」ページ： 本来１ページで説明できる内容（例えば製品の異なる仕様）を、内容がほとんどない独立URLに分割している場合。Search Consoleでは「正規ページがある代替ページ」としてよく表示されます。

「自動生成」のゴミページ： プログラムで大量に生成され、寄せ集めで文章が意味不明なページ（スパムサイトでよく見られます）。

「ナビゲーション」ページの中身なし： ただのリンクリストやディレクトリページで、リンク同士の関係や価値を説明するテキストが全くありません。単なるリンクの飛び先ページです。

関連データポイント：

• GoogleのEEAT（経験、専門知識、権威性、信頼性）フレームワークでは、最初の「E」（経験）が欠けていることが多く、ページが有用な情報やサービス経験を示せていません。
• Search Consoleの「カバレッジレポート」では、「重複コンテンツ」、「インデックスされているが正規として選ばれていない」、「クロール済み – 現在インデックスされていない」などのステータスが表示され、詳細を見ると「低品質コンテンツ」や「ページ価値が不十分」といったメッセージが確認できます（バージョンによって異なります）。

「薄いコンテンツ」はどう判断する？

• 単純な文字数ではなく指標として： 文字数が200〜300字未満で、図表や動画、インタラクティブなツールなどの価値ある要素がないページは非常にリスクが高いです。ポイントは「情報の密度」です。
• 自分でチェックする3つの質問：
  1. このページを読んでユーザーは具体的な問題を解決したり新しいことを学べますか？ （できなければ価値なし）
  2. 他のページに依存せず、このページ単独で存在できますか？（できれば価値あり）
  3. このページのコアとなる「中身」はナビゲーションやリンク以外の実質的なコンテンツですか？（そうなら価値あり）

検証ツール：

Google Search Console > URL検査ツール： 特定のURLを入力し、「カバレッジレポート」の状態が「クロール済み」かどうかを確認してください。 「実際のURLをテスト」をクリックして、リアルタイムクロール＆レンダリングをテストしましょう！ ポイントはレンダリング後の「スクリーンショット」と「クロールHTML」に完全な主要コンテンツが含まれているかどうかを確認することです。

Search Console > コアウェブバイタル & ページエクスペリエンスレポート： 「FCP/LCPが不良」のページが多い場合は、速度が深刻な問題のあるエリアです。

サーバーログ分析：

1. User-agentにGooglebotを含むリクエストをフィルタリングします。
2. ステータスコードに注目： 5xx、429、404（予期しない404）を記録します。
3. 応答時間をチェック： Googlebotの訪問平均応答時間を集計し、3秒や5秒を超える遅いページを特定します。
4. ログモニタリングツールの利用： Googleクローラーの活動状況をより効率的に分析できます。

実際の環境での速度測定：

Google PageSpeed Insights / Lighthouse： パフォーマンススコア、コア指標の数値、具体的な最適化提案を提供し、FCP（初回コンテンツ描画）、LCP（最大コンテンツ描画）、TBT（合計ブロック時間）を厳密に評価します。

WebPageTest： さまざまな地域・デバイス・ネットワーク環境でページの完全な読み込み過程をシミュレートし、詳細なタイムラインとネットワークウォーターフォールにより、遅延の原因（特定のJS？大きな画像？外部API？）を正確に特定できます。

今すぐやるべきこと（優先順位順）：

• 5xxエラーの監視と解消： サーバーリソース（CPU、メモリ）、データベースクエリの最適化、プログラムのバグ調査。CDNやクラウドサービスを利用している場合は、そのステータスも確認しましょう。
• 429エラーの確認： サーバーが積極的に制限していないか確認。クロール制限ポリシーの調整やGooglebotのIPレンジへのホワイトリスト登録（GoogleはIPレンジを公開しています）を行いましょう。
• ページ速度の全力改善：
  • サーバー応答速度の向上： サーバー最適化、CDN活用、キャッシュ改善（Redis/Memcachedなど）。
  • リソースサイズの削減： 画像圧縮（WebP推奨）、CSS/JSの圧縮と結合、未使用コードの削除。
  • JSの読み込み最適化： 非同期読み込み、重要度の低いJSの遅延読み込み、コード分割の利用。
  • レンダリングパスの最適化： レンダリングをブロックするCSS/JSの排除、重要なCSSのインライン化。
  • リソース読み込みの向上： CDNの安定利用、dns-prefetch、重要リソースのpreload設定。
• JSレンダリングの信頼性確保： 重要コンテンツはサーバーサイドレンダリング（SSR）や静的レンダリングを検討し、クローラーが主要なHTMLを確実に取得できるようにします。クライアントサイドレンダリング（CSR）を使う場合も、クローラーのタイムアウト内でJSが正常に動くようにしましょう。

サイト構造が混乱し、クローラー効率が非常に低い

核心問題： クローラーはホームページや入口ページから入っても、サイト内のリンクが複雑な迷路のようで、重要ページへ辿り着くための有効な道筋（リンク）を見つけられません。 そのため少数のページにしかたどり着けず、深い階層の多くのページは孤立してしまいます。

問題の特徴＆影響データ：

• ホームやチャンネルページの「内部リンク密度」が低すぎる： 重要コンテンツ（新商品や良記事）に目立つ入り口リンクがありません。Googleの統計では、ホームからクリック深度が4を超えるページはクロールされる確率が大きく下がります。
• 孤立ページの氾濫： 多数のページが他のページからほぼリンクされておらず（特に通常のHTMLリンクでなくJS動的生成やサイトマップのみ）、クローラーが偶然見つける可能性がほとんどありません。
• 重要なリンクがJSやインタラクションの背後に隠れている： 複雑なメニューのクリックやJS関数の実行、検索後にしかリンクが現れず、クローラーは「クリックできません」。
• 分類・タグ・関連論理が欠如： コンテンツがうまく整理されておらず、合理的な階層ナビゲーションで関連コンテンツを全て見つけることが難しい。
• ページネーションが乱れている： 「次のページ」リンクが不明瞭、または無限スクロールでクローラーが最後まで辿り着けない。
• サイトマップがないか、構造が悪い： サイトマップがあっても（前章参照）構造が不十分で、インデックスだけの提供だとクローラーの誘導効果は限定的。

評価方法：

• Screaming Frogなどのサイトクローラーを使用：
  • ホームページからクロール開始。
  • 「内部リンク数」レポートをチェック： ホームが重要なカテゴリやコンテンツに十分なリンクを貼っているか。
  • 「リンク深度」レポート確認： 重要なコンテンツページが深さ4以上に多すぎないか。
  • 「孤立ページ」（Inlinks=1）の特定： 重要だけどリンクがほとんどないページがあるか。
• Search Consoleの「リンク」レポート確認： 「内部リンク」タブでコアターゲットページの内部リンク数をチェック。重要ページが数件以下またはなしは問題。
• JSを無効化して手動で閲覧： ブラウザでJavaScriptをオフにしてクローラー視点でサイトを確認。メニューは使えるか？主要コンテンツのリンクは見えてクリックできるか？ページネーションのボタンは機能するか？
• ページの直帰率／滞在時間を確認する：分析ツールで該当ページの直帰率が非常に高い（>90%）かつ平均滞在時間が極めて短い（<10秒）場合、ユーザー（およびGoogle）が役に立たないと判断している確実な証拠です。

今すぐやるべきこと：

• 「不要なページ」の統合または削除：過剰に分割された「空の仕様ページ」をメイン商品ページに統合する。自動生成されたゴミページや内容のないプレースホルダーページは削除するか、noindexを設定する。
• 「プロセス終了」ページの価値を向上させる：「ありがとうページ」に予想所要時間や確認ステップの説明、関連ヘルプリンクを追加する。「決済ページ」には注文追跡入口、返品・交換ポリシーリンク、FAQを追加する。
• 「ナビゲーションページ」に説明的価値を注入する：カテゴリ／リンクリストページの上部に紹介文を追加し、そのカテゴリの目的、内容、対象者を説明する。これにより価値感が一気に向上する。
• コアコンテンツページを充実させる：商品や記事ページには十分な説明や詳細、よくある質問への回答を盛り込む。

重複またはほぼ同一コンテンツの氾濫

主な問題：複数のURLがほぼ同じまたは非常に類似したコンテンツ（類似度 > 80%）を表示していること。これにより検索エンジンのリソースが浪費され、ユーザーも不満を感じる（異なるURLで同じ内容を見つけてしまう）。Googleは「代表（canonical）」として一つのURLのみをインデックスし、残りは無視する可能性がある。

主な類似タイプと影響：

パラメータ汚染（ECサイトの大きな問題）：同一商品がソートやフィルター、トラッキングパラメータによって無数のURLを生成する（例：product?color=red&size=M、product?color=red&size=M&sort=price）。SEOツールによると、ECサイトの重複コンテンツの70%はこれに起因する。

印刷ページ／PDF版：記事ページ（article.html）とその印刷版（article/print/）やPDF版（article.pdf）はほぼ同じ内容。

地域／言語の微調整失敗：異なる地域のページ（us/en/page、uk/en/page）の内容差がほとんどない。

複数カテゴリパスページ：同一の記事が複数のカテゴリに属し、異なるパスのURLができるが内容は同じ（例：/news/article.html、/tech/article.html）。

大規模コピー（サイト内／外）：文章やページ全体をコピー＆ペースト。

データ：

• Search Consoleレポートはしばしば「インデックス未選択 – 代替ページに正規ページあり」や「重複」と表示。GoogleがどのURLを代表ページに選んだかを明確に示す。
• Screaming Frogなどのクローラーツールの「コンテンツ類似度」分析レポートで、高度に類似したURLグループを大量に特定可能。

判断・自己チェック方法：

Search ConsoleのURL検査：ステータスと具体的な理由を確認。

Screaming Frogクローラー：

1. サイト全体をクロール。
2. レポート > 「コンテンツ」 > 「類似コンテンツ」レポート。
3. 類似度の閾値（例：90%）を設定し、高度に類似するURLグループを確認。

手動比較：疑わしいURL（パラメータが異なるものなど）を数件ブラウザで開き、メインコンテンツを比較。

今すぐやるべきこと（推奨順）：

• 最優先：明確な正規URLを指定する（rel=canonical）：
  • 重複の疑いがある各ページのHTMLの内に、唯一の権威あるURLを正規ページとして指定する。
  • 構文：<link rel="canonical" href="https://www.example.com/this-is-the-main-page-url/" />
  • Googleが最も推奨する方法！
• 次善策：GoogleのURLパラメータツールを利用する：
  • Google Search Console > URL検査 > URLパラメータで設定を行います。
  • sortやfilter_colorなどのパラメータがコンテンツの絞り込みや並べ替えに使われていることをGoogleに伝えます（タイプは「並べ替え」または「絞り込み」を選択）。Googleは通常これらのパラメータによる重複を無視します。
• 301リダイレクト：古い、廃止された、または明らかに主バージョンでないURLは、301永久リダイレクトで最も権威あるURLへ転送します。特にサイトリニューアル後に旧パスを廃棄する場合に有効です。
• noindexタグ：印刷用ページや特定のトラッキングパラメータページなど、クロールやインデックスを避けたい主でないバージョンのページには、ページの<head>内に<meta name="robots" content="noindex">を追加します。ただし、クローラーのアクセスを防ぐわけではありませんので、正規化タグのほうが効率的です。
• コンテンツの削除や統合：サイト内で非常に似ている、または重複している記事やページは、直接統合するか削除してください。

読みやすさが低い、意図がずれている、信頼性が低い

核心問題： コンテンツのレイアウトが乱雑で、文章が硬くてわかりにくく、キーワードを詰め込みすぎている。情報が古かったり間違っていたり、ユーザーの検索意図に合わないため、ユーザー（とGoogle）にとって読みづらく、有益な情報が見つからず、自然に収録されにくくなります。

Googleが嫌う特徴：

• 読みやすさの大問題：
  • 段落が長すぎて区切りがない： 画面全体がひとつの段落だけ。
  • 文章が混乱し不自然： 誤字脱字が多く、文法がおかしい、機械翻訳っぽい。
  • 専門用語ばかりで説明なし： 一般ユーザー向けなのに専門用語だけが並んでいる。
  • レイアウトが悪い： 見出し（H1-H6）、リスト、太字などがなく視覚的に疲れる。
• 意図のずれ（深刻！）：
  • ユーザーが「水道管の直し方」を探しているのに、ページは水道管の「商品広告」ばかり。
  • ユーザーが「AとBの比較」を探しているのに、ページはAの紹介だけ。
• 情報が古い・間違っている：
  • 法律が変わっているのに古い内容のまま。
  • 手順説明が実際の操作と合わない。
• キーワードの詰め込みすぎ： 過剰にキーワードを入れて自然さがなくなり、読みにくい。
• 広告やポップアップが目立ちすぎ： メインの内容が広告に隠されて読みにくい。

データや評価の参考ポイント：

Core Web Vitals（CWV）の間接的関連： 主に速度・応答性の指標だが、ページの読み込み遅延やインタラクションの遅れ（FID/TBT）がひどいと読者体験が悪化する。

実際のユーザー指標（RUM）： 高い直帰率とほぼゼロの滞在時間は、ユーザーがコンテンツを拒否している強いサイン。

Googleの品質評価ガイドライン： GoogleはEEAT（専門性、権威性、信頼性）を軸にした評価基準を公開。ポイントは「コンテンツはユーザーの検索意図を満たしているか？」と「信頼に足る内容か？」。これはランキングアルゴリズムではないが、本質はほぼ一致する。

コンテンツ体験の自己チェック方法：

• ターゲットユーザーになりきって質問を持ちながら読む：
  • 欲しい答えが見つかるか？
  • 読むのに苦労しないか？何度も行き来しなくていいか？
  • 広告やポップアップに邪魔されないか？
• 読みやすさのレイアウトを確認：
  • 重要な情報が最初の250字以内にあるか？（H1タイトル＋最初の段落）
  • 見出しの階層がわかりやすいか？（H2-H6の論理的なネスト）
  • 複雑な情報はリストやフローチャート、表で整理されているか？
  • 段落は3～5文程度にまとめてあるか？空行は十分か？
• 検索意図とのマッチ度をチェック：
  • ターゲットキーワードは何か？（Search Consoleの検索パフォーマンスを確認）
  • ページのメインコンテンツはそのキーワードで検索するユーザーのニーズに直接かつ十分に答えているか？
  • タイトルと最初の段落でコアな質問に明確に答えているか？
• 信頼性の審査：
  • 事実やデータは信頼できる出典があるか？（リンクを付けているか）
  • コンテンツの作成者や発信者に関連資格や背景説明があるか？（EEATの経験・専門性）
  • ページの公開日または更新日が明示されているか？内容は古くないか？

すぐにやるべきこと：

• 不自然な文を徹底的に書き直す： 普通の人が話すように自然に書く！
• 情報のフォーマットを整える： 見出しタグで階層化、リストで要点整理、表でデータ比較など。
• 意図のずれを強力に解消： Search Consoleで上位のキーワードを分析し、ページの内容がそのキーワードが示すユーザーのニーズに正確に合っているかを確認。必要なら内容の軸を変えたり、新しいページを作成。
• 定期的な更新とコンテンツ整理： 内容の鮮度を示す。古い内容は更新かアーカイブ表示、無効な内容は削除かリダイレクト。
• 広告の邪魔を弱める： 広告は数と場所を調整し、本文を隠さない。
• EEAT信号を強化（長期的に重要）：
  • 「会社概要」や「著者紹介」で資格・経歴を示す。
  • 権威ある出典を引用しリンクを貼る。
  • 最後の更新日時を明確に表示する。

インデックスは正確な設計図から始まり、スムーズな経路で育ち、価値あるコンテンツで完成する。