ページがインデックスされない原因は、コード構造やサーバー設定に隠れている場合があります。
たとえば、クローラーが動的コンテンツを「読み取れない」場合や、パラメーター設定ミスでページが重複と判定され、インデックスから除外されることがあります。
この記事では、技術的な観点から、多くの人が見落としがちですがインデックスに直接影響する6つの実務的な問題をまとめました。

Table of Contens
Toggleページの読み込み速度が遅く、クローラーがクロールできない
たとえば、サーバーの応答時間が3秒を超えると、Googlebotはクロールを中止するか、ページの一部しかインデックスしない可能性があります。
この問題は多くのサイト管理者がユーザー体験(例:読み込みアニメーションの表示)だけに気を取られ、クローラーの「忍耐閾値」を見落とすことで発生しやすいです。
サーバー応答時間が長すぎる
問題の特定方法:Google Search Consoleの「ウェブに関する主な指標」やGTmetrixなどのツールで「TTFB(最初のバイトまでの時間)」を確認し、1.5秒を超える場合は改善が必要です。
解決方法:
- サーバーのスペック(CPU/メモリ)をアップグレードする、または高性能ホスティング(Cloudways、SiteGroundなど)に移行する。
- データベースクエリを最適化する(複雑な結合クエリを減らし、商品データテーブルにインデックスを追加する)。
- RedisやMemcachedなどのサーバーキャッシュを導入し、動的ページ生成の頻度を減らす。
最適化されていないリソースファイル
典型的な問題:
- 商品画像が圧縮されていない(例:PNGがWebPに変換されていない、解像度が2000pxを超える)。
- CSSやJSファイルが統合されておらず、数十件のHTTPリクエストが発生している。
修正手順:
- SquooshやTinyPNGで画像を圧縮し、主な画面サイズ(例:横幅1200px)に合わせる。
- WebpackやGulpでCSS/JSを結合し、ファイルリクエスト数を削減する。
- GzipやBrotli圧縮を有効にし、リソース転送サイズを減らす。
レンダリングをブロックするスクリプト
クローラーの視点:クローラーがHTMLを解析する際、非同期読み込みされていないスクリプト(例:同期読み込みのGoogle Analytics)に遭遇すると、スクリプトの実行が完了するまでレンダリングを停止します。
最適化方法:
- 不要なスクリプトには
asyncまたはdefer属性を追加する(例:)。 - チャットウィジェットやヒートマップ解析などのサードパーティツールは、ページ読み込み後に遅延実行する。
チェックツールと優先順位の推奨
セルフチェックリスト:
- PageSpeed Insights:具体的なリソース読み込み問題を特定(例:「JavaScript実行時間を短縮する」)。
- Screaming Frog:商品ページのTTFBを一括検査し、読み込み超過URLを抽出。
- Lighthouse:「チャンス」セクションで最適化提案を確認(例:未使用のCSSの削除)。
緊急最適化の優先順位:TTFBが2秒を超えるページ、1ページあたりのHTTPリクエスト数が50件を超えるページ、画像サイズが500KBを超えるリソースを優先的に対処。
参考データ:Googleの公式データによると、ページ読み込み時間が1秒から3秒に増加すると、クロール失敗率は32%上昇します。上記の最適化を行うことで、ほとんどの商品ページは2秒以内に読み込みが完了し、インデックス成功率が大幅に向上します。
robots.txtファイルで商品ディレクトリを誤ってブロック
たとえば、Disallow: /tmp/を誤ってDisallow: /product/と記述すると、クローラーは商品ページを完全にスキップし、どんなにコンテンツが優れていてもインデックスされません。
robots.txtによるブロック問題の迅速な確認
チェックツール:
- Google Search Console:「インデックス」>「ページ」レポートで、商品ページが「ブロック済み」と表示された場合、詳細をクリックしてrobots.txtによるブロック状況を確認。
- オンラインテストツール:robots.txtテストツールでURLを入力し、クローラーの視点でアクセス権を確認。
典型的なエラーの特徴:
- パスのスペルミス(例:
/produc/を/product/にすべきところで誤記)。 *ワイルドカードの過剰使用(例:Disallow: /*.jpg$で全商品画像をブロックしてしまう)。
誤ったブロックルールの修正方法
記述ガイドライン:
- パスの正確なマッチング:曖昧なブロックを避け、一時ディレクトリには
Disallow: /old-product/を使用し、Disallow: /product/は避けてください。 - クローラーの種類を区別:スパムボットのみをブロックしたい場合は、User-agentを明示する必要があります(例:
User-agent: MJ12bot)。
パラメーターの取り扱い:
- 必要なパラメーター(ページネーション
?page=2など)は許可し、Disallow: *?sort=を使って並び替えパラメーターのみをブロックします。 $記号でパラメーターの終端を明示(例:Disallow: /*?print=true$)。
緊急復旧と検証フロー
手順例:
- robots.txtファイルを修正し、誤った行をコメントアウトまたは削除(例:
# Disallow: /product/)。 - Google Search Consoleでrobots.txtの更新をリクエスト。
- 「URL検査ツール」で商品ページのクロール状況を手動で確認。
- 24時間後にインデックス状況を再確認し、未回復の場合は商品ページのサイトマップを手動で送信。
保護対策:
- バージョン管理ツール(Gitなど)でrobots.txtの変更履歴を管理し、ロールバックを容易にする。
- テスト環境でルール変更を事前に検証し、本番環境のファイルを直接変更しない。
実際のケーススタディ
誤った設定:
User-agent: *
Disallow: /
Allow: /product/
問題点:Disallow: / がサイト全体をブロックするため、後続の Allow ルールは無効化されます。
正しい修正:
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Allow: /product/
ロジック:管理画面と一時ディレクトリのみをブロックし、商品ページは明示的に許可。
商品ページの内部リンク不足問題
商品ページにサイト内からの導線(ナビゲーション、関連記事、アンカーテキストなど)がない場合、どんなに優れたコンテンツでもクローラーにインデックスされにくくなります。
このような問題は、新商品、独立した特集ページ、外部ツールで一括登録されたページに多く見られます。サイトのナビゲーション構造に適切に組み込まれていないためです。
ナビゲーション構造の欠如または設計ミス
代表的な問題:
- 商品ページがメインナビゲーションメニューやカテゴリーディレクトリに含まれていない(検索結果ページにのみ存在)。
- モバイルでハンバーガーメニューを使用し、重要な商品ページへのリンクが複数階層のサブメニュー内に隠れている。
解決策:
自己診断ツール:Screaming Frogでサイト全体をクロールし、「内部リンク数≤1」の商品ページを抽出。
最適化ステップ:
- メインナビゲーションに「人気新商品」や「おすすめカテゴリ」リンクを追加し、重要な商品一覧ページへ直接リンク。
- すべての商品ページを少なくとも1つのカテゴリーディレクトリに必ず含める(例:
/category/shoes/product-A)。
関連記事モジュールの活用不足
クローラー視点:「おすすめ商品」などの動的レコメンドコンテンツがJavaScriptで読み込まれる場合、クローラーはリンクを正しく認識できないことがあります。





