京谷商会では18のサブドメインでナレッジベースを運営している。2026年3月、Search Consoleの「ページのインデックス登録」レポートを確認したところ、「見つかりませんでした（404）」が大量に報告されていた。調査の結果、旧WordPressサイトからの移行に伴う未処理URLが445件、サイトマッププロトコル違反の統合サイトマップ、ソフト404を引き起こすリダイレクト設定、そしてCloudflare Pages環境固有の問題が複合的に絡んでいることが判明した。
この記事では、これらの問題を実際にどう特定し、どう解決したかを原因別に解説する。Search Consoleのインデックス問題は放置するとクロールバジェットの浪費や検索順位の低下につながるため、早期の対処が重要だ。
インデックス問題の全体像を把握する
ページインデックス登録レポートの読み方
Search Consoleの「ページのインデックス登録」レポートは、Googleがサイト内の各URLをどのように認識しているかを一覧で確認できる機能だ。左側に「インデックスに登録済み」のページ数、右側に「インデックスに登録されなかった理由」が表示される。
重要なのは、「インデックスに登録されなかった理由」の中でも、対処が必要なものとそうでないものを区別することだ。たとえば「noindexタグによって除外されました」は意図的にインデックスから除外しているのであれば正常な状態であり、対処は不要だ。一方、「見つかりませんでした（404）」や「ソフト404」は、本来インデックスされるべきページに問題が起きている可能性が高く、優先的に対処すべきだ。
問題の種類と優先度の判断基準
京谷商会のケースでは、sc-domain:kyotanishokai.co.jpプロパティで563ページが検索結果に表示されている中、445件の旧WordPress URLがGoogleのインデックスに残存していた。問題を以下の優先度で分類した。
最優先で対処すべきは「見つかりませんでした（404）」と「ソフト404」だ。これらはGoogleがページの存在を期待しているにもかかわらずコンテンツを取得できない状態であり、クロールバジェットを無駄に消費する。次に対処すべきは「クロール済み — インデックス未登録」で、これはページは存在するがGoogleが価値を認めていない状態を示す。最後に「検出 — インデックス未登録」があり、これはGoogleがURLを認識しているがまだクロールしていない段階だ。
「見つかりませんでした（404）」の対処法
旧CMSから移行した場合の大量404
サイトをWordPressから別のプラットフォームに移行すると、旧URLがGoogleのインデックスに大量に残る。京谷商会の場合、seo.kyotanishokai.co.jpをWordPressからCloudflare Workers（Hono）に移行した際、/seo/whats-featured-snippets/ や /contents/landing-page-design/ といった旧URL構造が138件残存していた。同様にsenior.kyotanishokai.co.jpで175件、aojiru.kyotanishokai.co.jpで92件の旧URLが検索結果に表示されていた。
対処の第一歩は、Search Console APIの検索パフォーマンスデータを使って、旧URLの中でまだクリックやインプレッションを獲得しているものを特定することだ。京谷商会では検索パフォーマンスAPIに dimensions: ['page'] を指定して過去28日間の全ページデータを取得し、現在のサイト構造（/articles/ パス）と一致しないURLを「旧URL」として抽出した。
301リダイレクトと410 Goneの使い分け
旧URLの対処には301リダイレクトと410 Goneの2つの選択肢がある。301リダイレクトは「対応する新しいコンテンツがある場合」に、410 Goneは「コンテンツが永久に削除された場合」に使うのが正しい使い分けだ。
よくある誤りは、旧URLを全て記事一覧ページなどの汎用的なページに301リダイレクトすることだ。京谷商会でもこの方法を採用していたが、138件の異なるURLが全て /articles/（記事一覧ページ）にリダイレクトされていた。この多対1のリダイレクトは、Googleにソフト404と判定される原因になる。リダイレクト先のページの内容が元のURLの内容と一致しないため、Googleは「このリダイレクトは意味がない」と判断するのだ。
正しい対処は以下のとおりだ。
まず、旧URLと新URLの対応関係を1対1で確認する。たとえば旧URLが /seo/page-speed/ で、新サイトに /articles/core-web-vitals-guide/ という同じテーマの記事がある場合は、301リダイレクトで個別に対応させる。京谷商会では検索ボリュームやインプレッション数の高い5件について、対応する新記事への個別301リダイレクトを設定した。
次に、対応する新コンテンツがない旧URLは410 Goneを返す。404ではなく410を使う理由は、410が「このリソースは意図的に永久削除された」というシグナルをGoogleに送るためだ。Googleの公式ドキュメントによれば、410は404と同等に扱われるが、「再クロールの頻度を下げる」効果が期待できる。
実践：445件の旧WordPress URLを一括処理した手順
京谷商会では以下の手順で445件の旧URLを処理した。
Search Console APIのsearchAnalytics/queryエンドポイントに startDate と endDate を過去12ヶ月に設定し、dimensions: ['page'] で全ページのパフォーマンスデータを取得した。次に各URLを正規表現でフィルタリングし、現在のサイト構造（/articles/、/glossary/、/team/ 等）に一致しないものを旧URLとして分類した。さらに旧URLをサブドメインごとに集計し、インプレッション数の多いものから対処優先度を決定した。
Cloudflare Workers（Hono）のミドルウェアで、個別リダイレクト対象5件はパスごとに301を設定し、残りの旧パスパターン（/seo/*、/contents/*、/wordpress/*）は一括で410 Goneを返すように実装した。この実装ではHonoの app.use('*', ...) ミドルウェアでパスマッチングを行い、既存の正規ルート（/articles/:slug/ など）より前に評価されるようにしている。
ソフト404を根絶する
ソフト404が発生するメカニズム
ソフト404とは、HTTPステータスコードとしては200（正常）を返しているが、ページの内容が実質的に「見つかりませんでした」であるとGoogleが判断するケースだ。典型的には、存在しないURLにアクセスした際にトップページや一覧ページの内容をそのまま表示する場合に発生する。
ソフト404はハード404（ステータスコード404を返す）よりもSEO上有害だ。ハード404であればGoogleは「このページは存在しない」とすぐに理解してインデックスから除外するが、ソフト404では「ページは存在するが価値のないコンテンツ」と判定され、クロールバジェットを継続的に浪費する原因になる。
多対1リダイレクトの罠
前述のとおり、京谷商会では旧WordPress URLを全て /articles/ に301リダイレクトしていたが、これはソフト404の典型的な発生パターンだ。GoogleはリダイレクトチェーンをたどってたどりつくA地点（元のページ）とB地点（リダイレクト先）が事実上同一の検索クエリに答えるかどうかを分析する。異なる138個のトピックを扱っていた旧URLが全て同じ記事一覧ページに飛ばされれば、Googleは事実上のソフト404と判定する。
この問題を解決するには、多対1のリダイレクトを全て撤廃し、個別に対応するか410 Goneを返す必要がある。修正後、Search ConsoleのURL検査ツールで代表的なURLを検査し、カバレッジの状態が「ソフト404」から「送信されたURLは見つかりませんでした（404）」に変わることを確認する。404のステータスであれば、Googleは正しく「このページは存在しない」と認識し、やがてインデックスから除外する。
Cloudflare Pages環境でのソフト404対処法
Cloudflare Pagesで静的サイトをホスティングしている場合、_worker.js 内の env.ASSETS.fetch() がSPAフォールバックとしてルートの index.html を返す挙動がある。これは単一ページアプリケーション（SPA）では正常な動作だが、静的サイトでは全ての存在しないURLに対してトップページが200で返されるため、大規模なソフト404問題を引き起こす。
京谷商会の配食サイト（haishokunofureai.com）ではこの問題が発生しており、サイトマップに317件のURLが送信されているにもかかわらず、インデックス数が0件という状態だった。原因は _worker.js の env.ASSETS.fetch(request) が、存在しないパスでもルートの index.html を200で返していたことだ。
対処として、Cloudflare Pagesの _routes.json 機能を使い、_worker.js が処理するパスを明示的に限定した。_routes.json で include に指定されたパスのみが _worker.js を通過し、それ以外のパスはPages標準のアセット配信が処理する。Pages標準の配信では、dist/ に 404.html を配置しておけば、存在しないパスに対して自動的に404ステータスとともにカスタム404ページが返される。
サイトマップの正しい構成と管理
サイトマッププロトコルの基本ルール
sitemaps.orgのプロトコル仕様は、サイトマップ内の全URLがサイトマップファイルと同じホストに存在しなければならないと定めている。つまり api.example.com/sitemap.xml に seo.example.com のURLを含めることはプロトコル違反だ。
京谷商会では api.kyotanishokai.co.jp/sitemap.xml に18のサブドメインのURLを全て含めた統合サイトマップを運用していた。sc-domain プロパティで全サブドメインの所有権が検証済みのため、GoogleはこのサイトマップをGSCのUI上では受け入れるが、各サブドメインに個別のサイトマップも登録されていたため、同じURLが2つのサイトマップに重複して存在する状態だった。
解決策は、プロトコル違反の統合サイトマップをSearch Consoleから削除し、各サブドメインの個別サイトマップのみを残すことだ。削除はSearch Console APIの DELETE /sites/{property}/sitemaps/{feedpath} エンドポイントで実行できる。
changefreq・priorityは本当に必要か
Googleの公式ドキュメントは、<changefreq> と <priority> を「無視する」と明言している。Googleのクローラーは独自のアルゴリズムでクロール頻度を決定しており、サイトマップのchangefreqの値は参考にしない。priorityも同様に無視される。
一方、<lastmod> は「一貫して正確である場合に使用する」とされている。つまり、ページを実際に更新した日付を正確に設定すれば、Googleはクロールの優先度判断に活用する可能性がある。ただし、全ページのlastmodを毎日の日付に更新するような不正確な設定を行うと、Googleはそのサイトのlastmod情報を信頼しなくなる。
京谷商会では全サイトマップからchangefreqとpriorityを削除し、記事の updated_at カラムの値をlastmodとして正確に設定する方式に統一した。
sc-domainプロパティでのサイトマップ戦略
Google Search Consoleのプロパティには「ドメインプロパティ（sc-domain）」と「URLプレフィックスプロパティ」の2種類がある。sc-domainプロパティは全サブドメイン・全プロトコルを自動的にカバーするため全体の監視に適している一方、URLプレフィックスプロパティはサブドメイン単位でのインデックスレポートが確認できるため問題の特定に適している。
京谷商会では sc-domain:kyotanishokai.co.jp を全体監視用に維持しつつ、主要サブドメインをURLプレフィックスプロパティとして追加登録する方針を採用した。これにより、sc-domainプロパティで「全体的にインデックス問題が増加している」ことを検知し、URLプレフィックスプロパティで「どのサブドメインのどのURLに問題があるか」を特定するという2段階の監視が可能になる。
サイトマップの管理についても、各サブドメインの robots.txt に自身の sitemap.xml のURLを Sitemap: ディレクティブで記述し、Googleのクローラーがサイトマップを確実に発見できるようにしている。
インデックス率を継続的に改善する運用体制
URL Inspection APIによる定期チェック
Google Search Consoleの「URL検査」はWebインターフェースから1件ずつ確認するのが基本だが、URL Inspection APIを使えばプログラムで一括検査が可能だ。京谷商会ではCloudflare Workers上にバッチ検査エンドポイントを実装し、D1データベースの全公開記事を定期的に検査している。
APIのレート制限は約2リクエスト/秒のため、600ミリ秒のインターバルを設けて順次検査する。検査結果は index_status_log テーブルに記録し、index_daily_summary テーブルに日次集計を保存する。これにより、インデックス率のトレンドを時系列で追跡できる。
週次モニタリングの仕組み
インデックス問題は一度解決すれば終わりではない。新しい記事の公開、既存記事の更新、外部サイトからのリンク変化など、インデックスの状態は常に変動する。京谷商会では週次で以下の項目を確認している。
サイトマップに含まれるURL数とインデックス済みURL数の差分をチェックし、新たにインデックスから外れたURLがあれば原因を調査する。Search Console APIの検索パフォーマンスデータでインプレッションが急落したページがないかを確認し、インデックスの喪失を早期に検知する。新規公開した記事がサイトマップに反映されているかを確認し、未反映であればサイトマップの生成ロジックを修正する。
まとめ
Search Consoleのインデックス問題は、原因を正確に特定すれば対処自体は難しくない。「見つかりませんでした（404）」は旧URLの未処理、「ソフト404」は不適切なリダイレクト設定やサーバー側のフォールバック挙動、「クロール済み — インデックス未登録」はコンテンツの品質や重複が主な原因だ。
対処のポイントは3つある。第一に、301リダイレクトは1対1の対応関係がある場合にのみ使い、対応するコンテンツがない場合は410 Goneを返す。第二に、サイトマップはプロトコル仕様に準拠し、各ホストが自身のURLのみを含むサイトマップを配信する。第三に、一度の修正で終わりにせず、週次でインデックス状況をモニタリングする仕組みを整える。
技術的なSEO改善は、1件のバグ修正で数百ページのインデックス状態が変わることがある。サイト全体のインフラを見直す視点で取り組むことが、効率的なSEO改善の鍵になる。