ホームページが検索に出ない｜公開後の原因切り分け6手順【実測】

ホームページを公開して数日〜数週間経つのに、社名やサービス名で検索しても自社のページが出てこない。制作会社に聞いても「そのうち出ます」と言われて終わり——という相談は珍しくありません。

結論から言うと、まず切り分けるべきは「Googleに登録（インデックス）されていない」のか「登録はされているが順位が低い」のかの2つだけです。前者はほぼ技術的な設定ミスかクロールの問題で、原因は数時間で特定できます。後者はコンテンツの問題で、対処もかかる時間もまったく別物です。この2つを混ぜたまま「SEO対策」を始めると、直すべきでない場所を直し続けることになります。

この記事では、Search Consoleを使った6手順の切り分けフローと、Mihataが自社サイト（mihata.jp・サイトマップ登録URL867件）で実際に踏んだインデックス配管のトラブルを、実測値つきで公開します。

検索に出ない原因は大きく2種類しかない

Googleの検索結果にページが表示されるには、①Googlebotがページを見つけてクロールする、②インデックスに登録する、③クエリに対して十分な順位で表示される、の3段階を通る必要があります。「検索に出ない」という症状は、このどこで止まっているかで対処が変わります。

まずは社名や電話番号など、ほぼ自社しか該当しないはずの固有名詞で検索してみてください。それでも出ないなら、SEOの話ではなくインデックスの話です。逆に社名では出るのに問い合わせが増えないという段階であれば、原因は別のところにあります。その場合はAIで作ったホームページで集客できない理由と改善策のほうが状況に近いはずです。

原因を切り分ける6手順

上から順に実行してください。途中で原因が見つかった時点で止めて構いません。

手順1: site:検索であたりをつける（確定診断には使わない）

Googleの検索窓に site:自社ドメイン と入力すると、そのドメイン配下でインデックスされているページがおおまかに確認できます。1件も出なければ、サイト全体が登録されていない可能性が高い状態です。

ただしこれは目安にすぎません。Googleは公式ドキュメントで、site:演算子は指定したプレフィックス配下のインデックス済みURLをすべて返すわけではないと明記しています。site:の件数を「インデックス数」として扱うのは誤りで、増減に一喜一憂しても意味がありません。確定診断は次の手順で行います。

手順2: Search ConsoleのURL検査で確定させる

Google Search Consoleを導入し、出てこないページのURLを「URL検査」に入力します。ここで返ってくる文言が、そのままトラブルの正体です。

なおURL検査には「公開URLをテスト」というライブテストがありますが、これは今この瞬間のページを取得するもので、Googleが実際に保持しているインデックス版とは別物です。noindexを外した直後などは、ライブテストは正常でもインデックス側は古いままという食い違いが起きます。判断はインデックス側の表示で行ってください。

手順3: サイトマップが「送信されているか」ではなく「取得されているか」を見る

ここが実務でいちばん見落とされます。サイトマップは送信しただけでは意味がなく、Googleが定期的に取得（フェッチ）し続けている必要があります。Search Consoleの「サイトマップ」画面で、送信日ではなく最終読み込み日を見てください。ここが何週間も止まっていたら、新しいページの発見が遅れます。

あわせて、サイトマップに書く lastmod の扱いも確認してください。Googleは公式に「lastmodの値は、それが一貫して検証可能なかたちで正確である場合に使用する」としています。裏を返せば、実際には更新していないのに毎回現在時刻が入るような実装だと、値そのものが信用されなくなります。ちなみに changefreq と priority については、Googleは「無視する」と明記しています。

手順4: noindexとrobots.txtを確認する

公開作業でもっとも多い事故が、開発中にかけていた検索避けの外し忘れです。WordPressなら「設定 → 表示設定 → 検索エンジンがサイトをインデックスしないようにする」のチェック、Next.jsなどの実装ならmetaタグの robots 指定、サーバー側なら X-Robots-Tag ヘッダーを確認します。

robots.txt でブロックしている場合も注意が必要です。Googleは「インデックス登録を防ぎたいならnoindexを使うべきで、robots.txtだけではインデックス登録は防げない」と説明しています。逆に、noindexを効かせたいページをrobots.txtでブロックしてしまうと、Googleはページを読めないためnoindexにも気づけません。この2つは目的が違うので、混ぜないでください。

手順5: canonicalの向き先を確認する

canonicalタグは「このページの正規URLはこれです」という宣言です。テンプレートの実装ミスで全ページのcanonicalがトップページを指していると、個別ページはすべて「代替ページ」として扱われ、検索結果には出てきません。www有無・httpとhttps・末尾スラッシュの表記ゆれも同じ問題を起こします。

手順6: クロール配分（クロールバジェット）を疑う

ここまでで異常がなければ、残るのはクロールの配分です。Googleはクロールの需要を決める要素として、サイトの想定インベントリ、URLの人気度、そして古さ（staleness／変更を拾うために再クロールする頻度）を挙げています。また、サイトの応答が遅くなったり5xxエラーや429を返すとクロール上限が下がる、とも明記しています。

ただし前提として、Googleがクロールバジェットの検討を勧めているのは「100万ページ以上で内容が週1回程度変わるサイト」「1万ページ以上で内容が毎日大きく変わるサイト」、そして「検出 - インデックス未登録」のURLが多いサイトです。数十ページの企業サイトでいきなりクロールバジェットを疑うのは、たいてい遠回りになります。

Mihataの自社サイトで実際に起きたこと

ここからは一般論ではなく、Mihataが自社サイト（mihata.jp）で実際に計測した内容です。他社サイトにそのまま当てはまる法則ではありませんが、「教科書どおりに設定していても止まることがある」という具体例として役に立つはずです。

サイトマップが31日間フェッチされていなかった

Search ConsoleのAPIでサイトマップの状態を確認したところ、メインの sitemap.xml の最終読み込み日が7月15日で止まったまま、8月中旬まで約31日間まったく取得されていませんでした。エラーも警告も0件で、画面上は正常に見えていました。

重要なのは、同じサーバー上の sitemap-images.xml は同じ期間ずっと正常に取得され続けていたことです。つまりサーバー障害でもDNSの問題でもありません。片方だけが取得されなくなっていました。

再送信したら10秒後に取得された

サイトマップを再送信したところ、送信から10秒後に取得されました（送信 19:08:06 → 取得 19:08:16／UTC）。「重いから諦められていた」「サーバーが遅かった」という説明では、この10秒は説明できません。

実測に整合する説明は別にあります。当時の実装では、サイトマップ内の全URLの lastmod に生成時刻が入っており、毎回すべてのURLが「たった今更新された」ことになっていました。前述のとおりGoogleはlastmodを「一貫して検証可能に正確な場合に使う」としています。全件が毎回同じ値で動くサイトマップは、更新情報として何の手がかりにもなりません。取得コストの問題ではなく、取得しても得られる情報がゼロだと判断されたと考えるほうが、10秒でフェッチされた事実と噛み合います。これはあくまで自社の実測から導いた解釈であり、Googleが公式に説明している挙動ではありません。

同じサイト内で、即日登録される記事と4日放置される記事が同居する

mihata.jpでは、公開直後にインデックスされる記事と、4日経ってもURL検査で「Googleに認識されていません」のままの記事が、同じ日に公開した中で同居します。テンプレートも内部リンクの本数も同じです。クロールの配分はバッチごとに大きく振れるもので、1本のページだけを見て「このページに問題がある」と判断すると読み違えます。判断は必ず複数本・数日単位のまとまりで行ってください。

効かなかった対処: 内部リンクの追加

「検出 - インデックス未登録」のままのURLに対して、既存記事から内部リンクを追加する対照実験を行いましたが、それが再クロールのトリガーになった様子は確認できませんでした。内部リンクはサイト構造の理解や回遊にとっては重要ですが、止まっているクロールを動かすための即効薬ではないというのが自社での結論です。効いたのはサイトマップ側の手当てのほうでした。

私たちはホームページ制作もサービスとして行っており、こうしたインデックスまわりの配管は公開時の標準作業に含めています。記事の途中で恐縮ですが、公開したのに検索に出ないという状態を自力で切り分けるのが難しければ、参考までにご覧いただけたら嬉しいです。

公開前に潰しておけば起きない項目

ここまでの原因の大半は、公開のタイミングで確認しておけば発生しません。新規公開やリニューアルの直前であれば、次の項目を制作会社との確認事項にしてください。最短2週間でホームページを公開する手順でも、この確認は公開前工程として組み込んでいます。

• 検索避け（noindex・robots.txt のDisallow）が本番環境から外れているか
• canonicalが各ページ自身の正規URLを指しているか
• www有無・httpsへのリダイレクトが1本に統一されているか
• sitemap.xml が生成され、Search Consoleに送信されているか
• sitemap.xml の lastmod が、実際の更新日時を反映しているか（毎回現在時刻になっていないか）
• Search Console と Analytics が本番ドメインで計測を開始しているか

公開後の継続的なチェック項目については、コーポレートサイトのSEO対策チェックポイントにまとめています。

制作会社に直してもらう場合、何にお金がかかるのか

「検索に出ない」の修正費用は、症状ではなく作業内容で決まります。見積もりを取るときは、金額だけでなく「どこまでやるか」を次の区分で確認してください。

工数はMihataでの実務感覚であり、既存の実装や運用体制によって変わります。ここで注意していただきたいのは、最後の「コンテンツ側の改善」だけは性質が違うことです。上の3つは直せば終わる作業ですが、コンテンツの問題は月額の保守や運用の話になります。この2つを1つの見積もりに混ぜて出してくる場合は、内訳を分けて出し直してもらうほうが判断しやすくなります。

また、保守契約を結んでいるのに「検索に出ない」が放置されている場合は、契約範囲にインデックス状態の監視が入っていない可能性があります。サーバー保守とSEO保守は別物なので、契約書の役務範囲を一度確認してみてください。

まとめ

「公開したのに検索に出ない」は、ほとんどの場合SEOの問題ではなくインデックスの問題です。順序としては、①社名で出るかを見て種類を判別し、②URL検査で確定させ、③サイトマップの最終読み込み日を見て、④noindexとrobots.txt、⑤canonical、⑥クロール配分の順に潰していけば、原因はたいてい途中で見つかります。

そして、正しく設定していても止まることはあります。Mihata自身、サイトマップが31日間取得されないまま画面上は「エラー0件」で見えていました。だからこそ、公開して終わりにせず、Search Consoleを定期的に見る運用のほうが結局は近道になります。切り分けの途中で行き詰まったら、状況をお伝えいただければ一緒に見ます。