インデックスされない原因と対処法：クロール促進でサイト評価アップ

Googleは全URLのインデックスを保証しないと明言しており¹、Search Consoleのインデックスレポートでも「クロール済み - インデックス未登録」や「検出 - インデックス未登録」が珍しくありません¹。外部の大型調査では、Ahrefsの解析で約96.5%のページがオーガニックトラフィックを獲得できていないという結果が示され²、「流入ゼロ」の多さは、発見（ディスカバリ）・クロール（ロボットがページを取得すること）・インデックス（検索用データベースに登録すること）・評価のどこかが詰まっているサインと読み替えられます。技術的な分解を怠ると、良い記事や新機能の公開を続けても検索に現れず、機会損失が膨らみます。エンジニアリングの手で再現性のある改善を積み上げることが、最短でのサイト評価向上につながると考えています。そこで本稿では、テクニカルSEOの中核であるクロールとインデックスの仕組みを因数分解し、原因の切り分けから実装、計測、運用までを開発現場の視点で具体化します。

インデックスされないのは「普通」だが、放置は損失

まず前提として、検索エンジンは全ページをインデックスしません¹。品質や重複の観点から整理しているとも言えますが、問題はビジネスに不可欠なページまで弾かれているケースです。Search Consoleの各ステータスは開発に役立つログのように読むべきです。検出されていないならディスカバリの問題、クロール済みで未登録なら品質や重複の疑い、レンダリングが必要なページで未クロールならリソースブロックやタイムアウトの可能性が高いという具合です。やるべきは、プロダクトのリリースフローにテクニカルSEOのヘルスチェック（機械可読な基準での合否判定）を組み込み、デプロイ前後で根拠をもって判定することです。TTFB（最初のバイトまでの時間）のしきい値、エラーレート、サイトマップの鮮度、内部リンクの深さといった指標を明確にし、失敗時には即時にロールバックまたは暫定対処を走らせる運用を設計します。

原因の特定：ブロック、重複、予算、レンダリング

ブロック系の凡ミスを機械的に排除する

最初に見るべきは明示的なブロックです。robots.txtの過剰なDisallow、X‑Robots‑Tagやmeta robotsのnoindex、認証ゲート、無限リダイレクト、4xxや5xxの増加は、インデックス以前にクロールを止めます³。設定は目視ではなく、HTTPレスポンスと内容を自動テストで検証します。以下のrobots.txtは検索エンジンに製品詳細を開放しつつ、無限パラメータを抑制する最小構成の例です。

# robots.txt (正しい例)
User-agent: *
Disallow: /*?session=
Disallow: /*&sort=
Allow: /product/
Sitemap: https://example.com/sitemaps/sitemap-index.xml

HTTPレベルの指示が誤っていないかは、ヘッダとHTMLの両方を確認します。cURLでの点検例では、ステータス、TTFB、X‑Robots‑Tag、キャッシュ系の情報を一度に取得します。

curl -s -I -w "\nstatus:%{http_code} ttfb:%{time_starttransfer}s\n" \
  https://example.com/product/123 | sed -n '1,20p'

metaタグとcanonical（正規URLを示すリンク要素）も衝突しないようにします。noindexとcanonicalの同居は検索エンジンに矛盾を伝えます。HTML側は次のように整理します³⁴。

<head>
  <meta name="robots" content="index,follow" />
  <link rel="canonical" href="https://example.com/product/123" />
</head>

サーバー側でドキュメント単位のX‑Robots‑Tagを誤配信していないかも点検対象です。Nginxならヘッダ付与をスコープ限定で行います³。

# Nginx: PDFのみnoindexの例
location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex, noarchive" always;
}

JavaScriptレンダリングが必要なページは、重要リソースのブロックを避けます。特に、静的HTMLの初期ペイロードに主要コンテンツを含めるプログレッシブエンハンスメントは安全な戦略です。レンダリング依存度が高い場合、LighthouseやSearch ConsoleのURL検査でタイムアウトが起きないかを測定し、初期レンダが遅延しない実装を優先します⁵。加えて、Googleはモバイル版のコンテンツを評価対象にするため（モバイルファーストインデックス）、モバイルでも同等の内容が配信されているかを確認します。

重複・品質の判断を検索エンジン視点で設計する

クロール済みなのに未登録というステータスは、同義ページの乱立や薄い内容、テンプレート比率の過多で起こります。カテゴリー、タグ、ソート、ページングが作る組み合わせ爆発は、正規化と内部リンク設計で抑え込みます。正規URLの合意をコードで明示し、派生URLは正規URLへcanonicalを一貫させます⁴。HTMLの例をもう一つ示します。

<link rel="canonical" href="https://example.com/list/shoes" />

パラメータを丸ごと禁止するとユーザー体験に支障が出る場合は、クロールしなくてよい集合だけrobots.txtで抑えます。一方で重要な集合はサイトマップに明示することで、探索を効率化できます⁷。テンプレート中心の薄いページは、実質的な独自情報や関連リンクを補い、価値の明確化を図ります。

クロール予算とサーバー健全性を数値で守る

クロール速度はサイト単位の健全性とページの需要で動的に決まります。ここでの健全性とは、レスポンスの速さと安定性です。運用しきい値の目安を例として挙げると、HTMLのTTFBは中央値で200ms前後、95パーセンタイルで500ms前後、5xxと429の合計は0.1%未満、リダイレクトチェーンは1回までが管理しやすいでしょう。サイト規模やインフラに応じて調整してください。ヘッダのETagやLast‑Modified（更新時刻を示すヘッダ）を正しく返すと、再クロールは条件付きGETで304（変更なし）になり、サーバー負荷を下げながら探索量を保てます。Nginxでの典型的な設定は次の通りです。

# Nginx: 条件付きGETとキャッシュ補助
etag on;
if_modified_since exact;
add_header Cache-Control "public, max-age=600";

重要でないURLにクロールが偏る場合は、HTTP 410で恒久的な削除を伝えると早く巡回対象から外れます¹¹。加えて、サーバーやネットワークのエラーが多発するとクロールが抑制され、インデックスからの除外につながることがあります¹⁰。

クロールを促進する実装：ディスカバリ、構造、速度、データ

サイトマップの設計と鮮度を担保する

サイトマップは検索エンジンへのTODOリストです⁷。巨大な一枚ではなく、論理的な分割が効果的です。更新頻度が高い領域は小さめのファイルに分け、必要に応じてサイズ上限にも配慮します⁸。さらにlastmod（最終更新日時）は実際の更新時刻で正確に更新し、形式上の日付や著作権表記と混同しないようにします⁹。サイトマップはSearch Consoleに登録して探索の効率を高めます⁷。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://example.com/sitemaps/products.xml</loc></sitemap>
  <sitemap><loc>https://example.com/sitemaps/articles.xml</loc></sitemap>
</sitemapindex>

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/product/123</loc>
    <lastmod>2025-08-25T12:30:00+00:00</lastmod>
  </url>
</urlset>

lastmodの機械更新は、公開処理と同一トランザクションで行い、S3配信やCDN（コンテンツ配信ネットワーク）経由でも即時整合が保たれるようにします。サイトマップのURLはrobots.txtにも記述しておけば十分で、HTTPヘッダで別途示す必要はありません。なお、一般公開ページのインデックスを強制・保証する手段は存在せず、Indexing APIはジョブ情報や一部のライブ配信など限定用途に限られます。通常のサイトでは、適切なサイトマップと内部リンク設計が基本です¹。

内部リンクグラフを浅く保ち、巡回の道筋を作る

クローラはリンクを辿ります。重要ページはトップから数クリック以内に到達できる深さに置き、ファセットや孤立ページを作らないようにします⁶。パンくず、関連記事、カテゴリーといったUI部品は、検索にとっては巡回の踏み石です。JavaScript依存のナビゲーションだけにせず、HTMLのa要素でリンクを露出させ、レンダリング前でも辿れるように設計します。構造化データは順位の魔法ではありませんが、エンティティの理解を助け、発見と評価の補助になります。ArticleのJSON‑LD例を挙げます。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "インデックスされない原因と対処法",
  "datePublished": "2025-08-30",
  "author": {"@type": "Person", "name": "高田晃太郎"},
  "mainEntityOfPage": "https://example.com/blog/indexing-causes"
}
</script>

応答速度を測り、しきい値で運用する

クロール促進のための高速化は、体感速度ではなくサーバー視点のメトリクスで運用します。TTFB、応答サイズ、圧縮率、エラーレートをデプロイごとに計測し、逸脱時はアラートを上げます。手元での一次計測にはcURLで十分です。

curl -s -o /dev/null -w "dns:%{time_namelookup} tcp:%{time_connect} ssl:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" \
  https://example.com/

動的ページのキャッシュはキャッシュキーの設計が要です。ユーザー固有のCookieがキーを分断していないか、Varyヘッダでbotに不必要な分岐を見せていないかを検査し、キャッシュヒット率を上げます。CDNのエッジでHTMLの短期キャッシュを許容できる区画を増やすと、クロールが集中しても土台が崩れません。

リダイレクトとURL正規化を負債にしない

301の多段化はクロールを無駄遣いします。HTTPとHTTPS、wwwの有無、末尾スラッシュの揺れを一度のリダイレクトで解決する正規化をサーバーで統一します。Nginxの典型例を示します。

# Nginx: 正規ホストへ一発で誘導
server {
  listen 80;
  server_name example.com;
  return 301 https://www.example.com$request_uri;
}

監視と意思決定：ログで見る、事実で動く

サーバーログでGooglebotの実像を掴む

Search Consoleだけでは遅延があります。アクセスログでクロールの実像を確認しましょう。ユーザーエージェントは偽装可能なので、逆引きDNSで正当なGooglebotを検証し（逆引き→正引きの突き合わせ）、誤検知を避けます。ログの設計は最初が肝心です。NginxではUA、レスポンス、サイズ、所要時間を含む独自フォーマットを定義し、分析基盤に流し込みます。

# Nginx: ログ拡張
log_format crawl '$remote_addr - $host "$request" $status $body_bytes_sent $request_time "$http_user_agent"';
access_log /var/log/nginx/access.log crawl;

集計では、Googlebotのヒット数、ステータス別の比率、TTFBのパーセンタイル、URL深さ別の分布を定点観測します。新規公開URLがいつ検出され、いつクロールされ、いつインデックスに入るかを、公開イベントと突き合わせて可視化すると、ボトルネックの場所が明らかになります。

エラーと品質のしきい値で自動アクションを掛ける

5xxが増えたらCDNの一時バイパスやキャッシュ強化を自動適用し、429が見えたらレート制御の対象からGooglebotを除外するなど、事前にプレイブックを定義します。静的エラーではなく、テンプレートの破損が原因ならロールバックを第一選択にします。重複が急増した場合には、サイトマップから問題領域を一時的に外し、正規化の修正を優先します。これらを手動運用に留めず、CI（継続的インテグレーション）の一環としてURLサンプルに対するヘルスチェックを組み込み、合格しないと公開できないガードレールを設けると事故が減ります。なお、サーバーやネットワークエラーが継続すると、該当URLはインデックスから除去される場合があります¹⁰¹¹。

プロダクトとSEOの共通KPIで意思決定を速くする

SEO専用のKPIだけでは、開発の優先度は上がりません。リリースから初回クロールまでの中央値、初回クロールからインデックス反映までの中央値、重要URL群の被リンクなし平均深さ、インデックスカバレッジの健全率といった指標を、プロダクトのKPIに併記します。改善のインパクトは、検索経由の売上増だけでなく、広告の依存度低下や回遊率の改善という形でも現れます。意思決定者が一瞥で価値を理解できるダッシュボードを作ることが、継続投資を支える土台になります。

まとめ：再現性のある「拾われる仕組み」を資産化する

インデックスは神頼みではありません。ブロックの排除、重複と品質の整理、サーバーの健全性維持、ディスカバリ設計、そして計測に基づく運用という地味な積み重ねが、検索に拾われる確率を現実的に高めます。今日からできることは、代表URLのHTTPヘルスチェックをCIに組み込み、サイトマップの分割とlastmodの自動更新を確実にし、ログでGooglebotの行動を見える化することです。しきい値を決めて運用に落とし込めば、改善は習慣になります。次のリリースでは、公開からの初回クロール時間を短縮できる工夫を一つだけでも入れてみませんか。小さな成功の積み重ねが、やがてサイト全体の評価を底上げし、ビジネスの速度そのものを引き上げます。

参考文献

Google Search Central. Crawling and indexing: FAQ. https://developers.google.com/search/help/crawling-index-faq
Ahrefs. Search Traffic Study: 96.55% of pages get no organic traffic. https://ahrefs.com/blog/search-traffic-study/#:~:text=96.55
Google Search Central. Robots meta tags and X-Robots-Tag HTTP headers. https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag
Google Search Central. Canonicalization. https://developers.google.com/search/docs/crawling-indexing/canonicalization
Google Search Central Blog. Building indexable Progressive Web Apps. https://developers.google.com/search/blog/2016/11/building-indexable-progressive-web-apps
Google Search Central Blog. The importance of link architecture. https://developers.google.com/search/blog/2008/10/importance-of-link-architecture
Google Search Central. Build and submit a sitemap. https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
Google Search Central. Sitemap size limits (Build and submit a sitemap). https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap#:~:text=Sitemap%20size%20limits%3A%20All%20formats
Google Search Central. lastmod should reflect real update time (Build and submit a sitemap). https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap#:~:text=,the%20copyright%20date%20is%20not
Google Search Central. HTTP status codes and network errors. https://developers.google.com/search/docs/crawling-indexing/http-network-errors
Google Search Central. How 404/410 are handled by the indexing pipeline. https://developers.google.com/search/docs/crawling-indexing/http-network-errors#:~:text=,indexing%20pipeline%20removes%20from%20the