目次
結論
自社の補助金検索サービス「カンタン補助金」は、複数の公開データ元(デジタル庁jGrants・東京都中小企業振興公社・ミラサポplus等)を横断的に取り込んでいる。この複数ソースを一意に識別するため、補助金IDには ソース名:元ID のようにコロンを含む形式を採用していた。ところが、bot(検索エンジンのクローラー)向けにスナップショットHTMLを配信するnginxのルーティングと、サイトマップ生成の両方が、IDのバリデーションにコロンを許可しない正規表現を使っていた。結果として、総数966件のうち、bot(検索エンジン)に中身のある詳細ページとして配信できていたのはわずか71件、7.3%だった。残る895件は、クローラーから見えていなかった。修正後は761件、78.8%まで回復した。(出典: 自社データベースの実件数とサイトマップ収載件数の突合調査、2026年8月14日時点)
この記事の前提
「カンタン補助金」は、bot向けには静的スナップショットHTML、人間のブラウザ向けにはSPA(クライアントサイドルーティング)という構成でページを配信している。この構成自体は、JavaScriptを実行しないGooglebot・Bingbot・GPTBot等への対応として妥当な設計だった。問題は、この2つの経路がIDの検証ロジックを別々に持っていたことにある。
何が起きたか
2026年8月14日、敵対的監査(批判的レビュー)の過程で、サイトマップに収載されている補助金詳細ページの件数が、データベース上の実件数と大きく乖離していることが発覚した。
- 補助金レコードの総数は966件
- そのうち、bot向けスナップショットとして中身のある詳細ページを返せていたのは71件のみ（残り895件は不可視）
- 残りは、nginxのルーティング regex がIDに含まれるコロンを弾くため、bot(GooglebotやGPTBot等)には「中身なし」のページが返っていた
- 人間のブラウザ経由(SPAのクライアントサイドルーティング)ではこの制限は関係なく、すべてのレコードが正常に表示されていた。開発者も含め、誰も「壊れている」と気づけない状態だった
出典: 自社データベースの実件数とサイトマップ収載件数の突合調査、2026年8月14日時点。
この状態が、Google Search Consoleの実測にはっきり表れていた。カンタン補助金のドメイン(ai-media.online)は、直近90日間の検索表示回数が34インプレッションだったのに対し、同時期に運用しているメディアサイト(ai-media.co.jp)は31,530インプレッションだった。桁が2つ以上違う。「カンタン補助金というドメインがGoogleからほぼ見えていない」ことが、この監査で確定した最重要のボトルネックだった。
なぜ気づかなかったか
原因はIDの設計そのものではなく、IDのバリデーションが経路ごとに別々に実装されていて、片方だけが古いままだったことにある。
- 複数ソースを合成するID設計(
ソース名:元ID)自体は、ID衝突を避けるための合理的な判断だった - しかし、nginxのルーティングとサイトマップ生成の正規表現は、コロンを含まない単純なID(英数字・アンダースコア・ハイフンのみ)を前提に書かれたままだった
- SPA側のクライアントサイドルーティングは、この制限を継承していなかったため、人間のブラウザでは何の異常もなく表示され続けた
- サイトは200を返し続けており、稼働監視・エラー監視のいずれにも引っかからなかった。「一部だけ表示されている」状態は、外形上「全部表示されている」状態と区別がつかない
どう直したか
- 根本原因の特定: nginx・サイトマップ生成それぞれの正規表現がコロンを拒否していることを特定し、修正した
- 品質ゲートの追加: 修正と同時に、bot向けスナップショットが実質的なコンテンツを持っているかを検証する品質ゲートを追加した(「200を返すか」ではなく「中身があるか」を見る)
- bot対応の拡張: この修正と合わせて、GooglebotとBingbotをbot判定分岐に追加した。これにより、Google検索とMicrosoft Copilotの両方の経路が、このサービスに対して初めて開通した
- 一覧ページの対応: 詳細ページだけでなく、一覧ページについてもbot向けスナップショットを新設した
- 検証: 修正後、29項目の自動検証(verify)がすべてPASSすることを確認した。修正版はIndexNowでも検索エンジンに即時通知した
余談だが、この修正のデプロイでは別の罠も踏んでいる。nginxをDockerのbind mountで動かしている構成では、設定ファイルを書き換えてもreloadが効かず、コンテナのforce-recreateが必要だった。修正が正しくても、反映のさせ方を誤ると「直したはずなのに直っていない」という二重の混乱が起きる。
同じ轍を踏まないためのチェック
複数データソースを横断的に扱うサービス、bot向けとブラウザ向けで配信経路を分けているサービスでは、次を確認することを勧める。
- IDやスラグに使う文字集合を決めたら、それを検証・ルーティングする全ての箇所(nginx・サイトマップ生成・アプリ側)で同じ正規表現を共有しているか。片方だけ古いまま、という状態が最も気づきにくい
- bot向け経路(サーバーサイドの静的配信)と人間向け経路(SPAのクライアントサイドルーティング)が別々のバリデーションを持つ設計では、bot経路だけを対象にした定期的な実データ検証を別建てで持つ
- 「サイトが200を返している」ことを稼働の証拠にしない。サイトマップの収載件数とデータベースの実件数を定期的に突合する
- Google Search Console等の表示回数・インデックス数を定点観測し、他ドメインとの桁の違いのような異常な低さを早期に検知する仕組みを持つ
- 設定ファイルを修正しても、反映方法(reloadで効くか、再作成が必要か)を疑わずに「直った」と判断しない