SEO・AIO TECHNICAL RUNBOOK
サイトが検索・AIに見つからないときの技術診断
記事を増やす前に、対象URLへクローラーが到達できるか、indexabilityとcanonicalが正しいか、 本文が取得できるか、Search Consoleがどう観測しているかを順に確認します。
公開日：2026年6月25日 更新日：2026年9月20日 著者：飯田 友広（Tomohiro Iida）
最初に切り分けること
このRunbookが扱うのは、「そもそも取得・クロール・インデックスの入口が壊れていないか」です。 技術的に取得できているのに比較候補へ入らない、引用されない、問い合わせにつながらない問題は別の層です。
診断は「検索結果」ではなく、観測できる状態から始める
Googleの site: 検索は素早い補助確認には使えますが、インデックス済みURLを網羅して返すものではありません。 特定URLの状態はSearch ConsoleのURL検査で確認します。
同じ理由で、sitemapへ載っている、self-canonicalがある、robots.txtで許可されている、という一つの条件だけから 「クロールされる」「インデックスされる」「AI検索に出る」と結論づけません。
| 順序 | 確認する問い | 観測するもの | 次の判断 |
|---|---|---|---|
| 0 | site:検索に出るか | 補助確認だけに使う | 出なくても未登録と断定せず、対象URLをURL検査へ進める |
| 1 | HTTPで取得できるか | 200 / redirect / 4xx / 5xx / timeout | 200以外なら配信・redirect・サーバーを先に直す |
| 2 | クローラーが到達できるか | robots.txt、認証、WAF/CDN、bot対策、rate limit | 人間のブラウザで200でもbotだけ遮断していないか確認する |
| 3 | indexabilityとcanonicalは正しいか | noindex、X-Robots-Tag、declared canonical、Google-selected canonical | URL検査でGoogle側の判断も確認する |
| 4 | 本文を取得できるか | 初期HTML、rendered HTML、本文・見出し・主要リンク | JS実行前後で重要情報が消えていないか比較する |
| 5 | 発見経路があるか | 内部リンク、sitemap、孤立ページ、lastmod | 重要URLへ通常リンクを作り、sitemapを正確に保つ |
| 6 | Googleはどう観測しているか | URL Inspectionのcrawl/index/canonical state | 技術変更後は再取得を待ち、状態変化を別時点で確認する |
| 7 | AI検索用crawlerの入口は開いているか | OAI-SearchBot等のsearch-facing crawler access | 許可しても掲載保証ではない。取得可能性だけを確認する |
01
HTTPとredirectを確認する
最初に対象URLを直接取得します。200で本文を返すのか、301/308で別URLへ移るのか、404/410なのか、 5xxやtimeoutになるのかを分けます。ブラウザで見えていても、複数段redirectやbot向けの別応答が残っていないか確認します。
ここで記録する
- ・最終HTTP status
- ・redirect chainと最終URL
- ・Content-Type
- ・5xx / timeoutの再現有無
02
robots.txtだけでなく、認証・WAF・CDNまで確認する
crawler accessはrobots.txtだけでは決まりません。認証画面、WAF/CDNのbot mitigation、地域制限、 rate limitなどでcrawlerだけが拒否されることがあります。人間のChromeで200だったことをcrawlerの取得証拠にはしません。
OpenAI向けでは、検索用途のOAI-SearchBotと学習用途のGPTBotは別の制御対象です。 検索に出したいか、学習利用を許可するかを同じ判断にまとめないようにします。
03
noindexとcanonicalを分けて確認する
meta robotsやX-Robots-Tagにnoindexがないかを確認します。その次にdeclared canonicalを確認します。 self-canonicalがあっても、Googleが別URLをcanonicalとして選ぶ場合があります。
Google-selected canonicalはSearch ConsoleのURL検査で確認します。publisher側のHTMLだけを見て 「canonicalは正常だから問題なし」と終わらせません。
04
初期HTMLとrender後HTMLを比較する
ページの枠だけが初期HTMLにあり、本文や主要リンクがJavaScript実行後に初めて出る構成では、 crawlerごとに取得結果が変わる可能性があります。ページソースとrender後DOMを分けて確認します。
少なくとも、タイトル、主見出し、本文、主要な内部リンク、canonicalなどの診断対象がどの段階で現れるかを記録します。
05
内部リンクとsitemapを「発見経路」として見る
重要ページがsitemapにあるだけで十分とは考えません。サイト内の通常リンクから到達できるか、 関連ページから文脈付きでリンクされているかを確認します。孤立ページは人にもcrawlerにも発見されにくくなります。
sitemapはURLと更新情報を伝える手段ですが、クロールやインデックスを保証しません。lastmod は実際の重要な更新を反映し、一貫して正確に保ちます。
06
Search Console URL InspectionでGoogle側の状態を読む
対象URL単位で、クロール可否、インデックス状態、最終クロール、canonicalなどを確認します。 技術設定を直した事実と、Google側の状態が変わった事実は別々に記録します。
再クロールを依頼した後も即時反映を前提にしません。一定期間後に同じURLを再確認し、 「何を変えたか」と「検索側で何が変わったか」を混同しないようにします。
07
AI検索は「crawlerが来られるか」までを技術層で確認する
ChatGPT Search向けには、OAI-SearchBotを意図せず遮断していないかを確認します。 ただしcrawler accessが正常でも、回答への表示、順位、引用は保証されません。
技術層が正常なら、次は候補・引用・回答・行動の5段階診断へ移ります。取得可能性と推薦・引用の問題を同じ修正で扱わないことが重要です。
診断チェックリスト
- ☐対象URLのHTTP statusとredirect先を確認した
- ☐robots.txt、認証、WAF/CDN、bot対策を確認した
- ☐meta robotsとX-Robots-Tagのnoindexを確認した
- ☐declared canonicalとGoogle-selected canonicalを区別した
- ☐初期HTMLに本文・見出し・主要リンクが含まれるか確認した
- ☐重要ページへの通常の内部リンクがある
- ☐sitemapに正しいURLと重要な更新日が載っている
- ☐Search Console URL Inspectionで対象URLを確認した
- ☐AI検索用crawlerを意図せず遮断していない
- ☐技術層が正常なら、候補・引用・回答・行動の診断へ切り替えた
よくある質問
site:検索に出なければ、インデックスされていないのですか？
断定できません。Googleはsite:検索がインデックス済みURLを網羅して返すものではないと案内しています。特定URLはSearch ConsoleのURL検査で確認します。
sitemapに載せればクロール・インデックスされますか？
保証されません。sitemapはURL発見や更新情報を伝える手段ですが、送信したURLが必ずクロール・インデックスされるわけではありません。
canonicalが自分自身を指していれば問題ありませんか？
publisher側の指定としては確認できますが、Googleが別URLをcanonicalとして選ぶことがあります。Google-selected canonicalはURL検査で確認します。
OAI-SearchBotを許可すればChatGPT検索に必ず出ますか？
出る保証はありません。OpenAIはOAI-SearchBotを検索向けのcrawlerとして案内していますが、アクセス許可は取得可能性の条件であり、表示・順位・引用を保証するものではありません。
技術設定が正常なら、次は何を確認しますか？
技術層が正常なら、顧客の質問に対する候補へ入れる情報があるか、引用できる根拠があるか、回答が正しいか、サイト上で行動できるかを別の診断へ切り替えます。
この記事の著者
飯田 友広
代表取締役
Netsujo株式会社 代表取締役。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。さらに、ChatGPT・Codex・Claude Codeを状態再構築、競合回避、独立QC、Exact-head検証、停止、復旧まで含む制御ループで運用する社内AI開発基盤「Netsujo Agent OS」を設計・実運転。Netsujoとして京都ビッグデータ活用プラットフォームに参画(小規模企業会員（ベンチャー）)し、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」にも参画(2026年3月10日〜)。IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」はNetsujoとして京都府庁旧議場で主催・企画・登壇・運営(2026年7月2日／京都府 総合政策環境部 デジタル政策推進課は共催)。京都美術工芸大学・龍谷大学での講義に加え、京都高度技術研究所（ASTEM）、旅館業界、就労支援施設、Open Source Conference等で登壇実績。ITコミュニティ「みやこでIT」(connpassメンバー638名・イベント175件・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。Netsujoはソーシャル企業認証制度「S認証」の認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。
プロフィールを見るこの記事が向いている方
特定URLが検索に出ない原因を技術面から切り分けたいWeb担当者
Search ConsoleのURL検査を何と組み合わせて見るべきか整理したい方
AI検索用crawlerを意図せず遮断していないか確認したい方
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. URLは公開されているのにGoogleで見つかりません。
HTTP・indexability・canonical・内部リンク・URL Inspectionを順に確認します。
Q. AI検索用crawlerは何を許可すればよいですか？
検索用と学習用を分け、現在の目的とポリシーに合わせて確認します。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
関連するサービス
検索・生成AI時代のWeb営業基盤
技術層の先にある、発見・比較・問い合わせの断絶を診断する
公開情報と検索データを分けて観測し、実装できる変更仕様へ落とします。掲載や順位を保証するサービスではありません。