[SEO] サーチコンソールの流入が突然ゼロに。技術要因を全部潰したら「サイトは無実」だった話

2026/07/18

SEO
Search Console
Next.js
Firebase Hosting

こんにちは。

今回は、自分たちのコーポレートサイトで ある日を境にSearch Consoleの検索流入が完全にゼロになった ときの、犯人探しの記録です。順位がじわじわ下がった、みたいな優しい話ではなくて、グラフが崖から落ちるみたいにストンと0に張り付くやつ。「これは何かやらかしたな…」と怪しいところを片っ端から潰していったので、その過程をそのまま残します。

先に言っておくと、この記事は「原因を特定できました!」という気持ちいいオチにはなりません。 でも「どう切り分けたか」は再現性があるはずなので、同じ状況で固まっている方の役に立てば嬉しいです。

先にオチ(正直版)

調査の結論はこうです。

  • robots / noindex / SSL / デプロイ / DNS / 環境変数 / Googleのコアアップデート——技術的に怪しいところは、全部シロだった。
  • サイトの構成は3年以上ほぼ無変更で、ずっと普通にインデックスされていた。つまり 05/01前後に変わったのは「サイト」ではなく「Googleの評価」の側
  • 症状は「クロール済み・インデックス未登録(Crawled - currently not indexed)」がサイト全体。Googleはページを取得はできているのに、載せないと判断している
  • なので最有力の仮説は「Google側の品質・信頼性の再評価で落とされた」。ただしGoogleの内部は見えないので断定はできていません
  • canonicalの欠如など「どっちにせよ直すべき整備」は見つかったので、そこは直しました。

以下、容疑者を一人ずつ潰していった順です。


症状

  • Search Consoleの「検索パフォーマンス」で、クリックもインプレッションも、ある日からピタッとゼロ
  • じわ減りではなく、特定の日(だいたい05/01)で崖のように0
  • サイトは普通に表示できる。落ちてもいないし、URLも変えていない

順位下落なら普通は徐々に減るので、崖のようにゼロというのはむしろ「技術的にサイトが検索対象から外れた」か「計測が切れた」ことを示唆します。ここで犯人探しモードに入りました。

容疑者を一人ずつ潰す

容疑者1:コード / robots / noindex / デプロイ日

robots.txt でブロックしてないか、noindex を埋め込んでいないか、流入停止日と一致するコミットが無いか。gitログを前後で洗いました。→ シロ。その日に入っていたのはCIのbot設定変更だけで、SEOに触る変更はゼロ。

「日付が一致する=原因」と飛びつきたくなりますが、中身を見たら無関係、はよくあります。ここ大事。

容疑者2:そもそもインデックスされてる?(ここに罠があった)

site: や「合同会社irori」で検索すると…普通に出てくる。「なんだ載ってるじゃん」と一瞬安心しました。

でもこれは罠でした。GSCが「表示回数ゼロ」と言っている以上、いま検索に出ているはずがない。 つまり site: や指名検索で見えていたのは古いインデックスの残像だったんです。第一者データ(GSC)と外から見える検索結果が食い違うときは、GSCを信じる。ここは自分でも一回引っかかったので戒めとして書いておきます。

容疑者3:手動による対策 / セキュリティの問題

GSCの「手動による対策」→ 問題は検出されませんでした。「セキュリティの問題」→ 問題は検出されませんでした。ペナルティでもハッキングでもない。→ シロ

容疑者4:URL検査(決定的な症状が出た)

トップページをURL検査にかけると、こう出ました。

URL検査の結果
URL が Google に登録されていません
ページのインデックス登録: クロール済み - インデックス未登録
クロールを許可?        はい
ページの取得          成功
インデックス登録を許可? はい
前回のクロール        2026/05/27

取得は成功していて、インデックス登録も許可されている。なのにGoogleは「登録しない」と判断している。 これが Crawled - currently not indexed の正体でした。ブロックではなく、Googleが自分の意思で見送っている状態。これは品質・価値まわりのシグナルであることが多いです。

容疑者5:ページレポート(剥落が確定)

「インデックス作成 → ページ」を見ると、

  • 登録済み: 0ページ / 未登録: 135ページ(理由は1本=「クロール済み・インデックス未登録」)
  • グラフが決定的で、04月末までは緑(登録済み・300ページ近く)→ 05/01あたりで緑が消えて全部グレー(未登録)に転落

つまり「もともと全体がちゃんと載っていたのに、05/01前後に丸ごと一斉に剥落した」。新規で最初から低評価、ではなく、健全だったものが落ちた、が確定しました。

容疑者6:重複ホスト × canonical不在(見つけた。でも…)

ここで一つ見つけました。Firebase Hostingは既定で複数ホストを持つので、同じ中身が3つのURLで生きていました。

ホスト 中身 canonical
corporate.irori.dev(本命) 同じHTML 無し
corporate-site-28f8a.web.app 同じHTML 無し
corporate-site-28f8a.firebaseapp.com 同じHTML 無し

og:url は入れているのに、<link rel="canonical"> がサイト全体で1つも出ていない(Next.jsは alternates.canonical を書かないとcanonicalを吐きません)。正規URLを宣言する手段がそもそも無かった。

…ただ、ここで冷静になります。canonicalは「ずっと」無かった。 05/01に壊れたわけじゃない。ずっと無かったものが、ある日突然サイトを殺す理由にはなりません。慢性的な弱点ではあるが、05/01の“引き金”ではない。ここは正直に切り分けました。

容疑者7:SSL / HTTPS

GSCの「HTTPS」レポート → 問題ありません(過去90日間問題なし)。証明書やHTTPS配信の不調でもない。→ シロ

容疑者8:デプロイ / ビルドの中身

GitHub Actionsのデプロイ履歴を確認。05/01は3本ともデプロイ成功、しかも次のデプロイは05/27まで無い。さらに、

  • package-lock.json存在し2月から不変 → 依存のドリフト無し
  • 04/30 → 05/01 のサイト生成ソースの差分は空(変わったのはbot用YAMLだけ)

05/01のデプロイは「同じソース・同じ依存で焼き直しただけ」で、出力は実質ノーチェンジ。サイト側に技術的変化なし。→ シロ

容疑者9:Googleのコアアップデート

2026年のコアアップデートは 3月(3/27〜4/8)5月(5/21〜6/2)05/01はちょうどこの2つの谷間で、どちらとも一致しません。コア更新の剥落はロールアウト中〜直後に出るので、3週間ずれた05/01を説明できない。→ (少なくとも名前付きの更新は)シロ

容疑者10:リポジトリ外の環境変数(最後の穴)

ビルド時の NEXT_PUBLIC_SITE_URL はGCS上の .env から来ます。リポジトリ外なのでgitに残らない、唯一の穴。最終更新日を見たら——

Update time: 2022-11-27
NEXT_PUBLIC_SITE_URL=https://corporate.irori.dev

2022年から一度も変更されていない。 値も正しい。→ シロ。最後の穴も閉じました。

で、犯人は?

技術容疑者は全員アリバイ成立でした。残ったのはこれです。

サイトは3年以上ずっと同じ健全な構成で普通にインデックスされていた。05/01前後に変わったのは「サイト」ではなく「Googleの評価」。Googleの継続的な品質・信頼性評価の中で、このサイトが「載せる価値が薄い」と判定され、全ページが非インデックスに落ちた。

決め手は容疑者4の 「ページの取得=成功」。Googleはアクセスできないのではなく、取得できた上で「載せない」と選んでいる。これは技術的な遮断ではなく、価値判断です。

繰り返しますが、Googleの内部は見えないので断定はしません。ただ技術要因が全部消えた今、現実的に残る線はここ、というのが正直な結論です。思い当たる弱点も書いておきます(推測込み)。

  • サブドメイン運用(apex irori.dev はWeb無効)でドメイン全体の信頼が薄い
  • 3ホスト重複 × canonical不在で重複シグナルを撒いていた
  • チュートリアル/概要系の薄めの記事が多く、E-E-A-T重視の評価に弱い
  • 外部からの被リンク・言及が少ない

無実でも、整備はする

「サイトは技術的には無実」でも、見つかった弱点は直す価値があります。まずcanonicalの整備から。ルートで metadataBase を固定し、

app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL(process.env.NEXT_PUBLIC_SITE_URL || 'https://corporate.irori.dev'),
}

各ページに自己参照canonicalを追加します。

app/page.tsx
export const metadata: Metadata = {
  // ...
  alternates: {
    canonical: '/', // metadataBase 基準で https://corporate.irori.dev に解決
  },
}

ビルド成果物で実際に出ているかは必ず目視。

$ grep -o '<link rel="canonical"[^>]*>' out/index.html
<link rel="canonical" href="https://corporate.irori.dev"/>

合わせて、.web.app / .firebaseapp.com を301で本命に集約、サイトマップの「一時的な処理エラー」を解消して再送信、GSCで「検証を開始」+主要URLのインデックス登録リクエスト、まで実施します。

正直な話(期待値)

canonicalを足したから戻る、という保証はありません。 ここまでで分かった通り、これは技術バグではなく品質・信頼性の評価の問題っぽい。だとすると本丸は、

  • apex irori.dev を正規ドメインへ昇格する検討(サブドメインは信頼が乗りにくい)
  • 薄い記事の統合・加筆、一次体験(独自性)の強化、内部リンク整備
  • 外部からの被リンク・言及づくり

…という即効性のない、地道な運用の側にあります。数週間〜数ヶ月スパンの話。経過が出たらこの記事に追記します。

次回の自分へのメモ(再発防止)

  • 崖のようにゼロはSEO要因より技術・計測要因を先に疑う。順位下落はもっとなだらか。
  • site: や指名検索で「出る」を鵜呑みにしない。古い残像のことがある。GSCの第一者データを信じる
  • URL検査の 「ページの取得:成功」+「インデックス未登録」 は、「アクセスできない」ではなく「載せる価値なしと判断された」のサイン。robots/noindexを探しても見つからないのはこのため。
  • canonicalは最初から入れる。特にFirebase Hostingみたいに既定で複数ホストを持つ環境では、canonical不在=重複製造機。
  • 「日付が一致=原因」に飛びつかない。中身を見る。

まとめ

  • 症状:05/01前後にSearch Consoleのクリック・インプレッションが崖のようにゼロ。順位下落ではない。
  • 調査:コード / robots / noindex / 手動対策 / セキュリティ / SSL / HTTPS / デプロイ / 依存 / DNS / 環境変数 / コア更新の日付——技術容疑者は全員シロ
  • 決め手:URL検査で「ページの取得:成功」なのに「クロール済み・インデックス未登録」。取得できるのに載せない=価値判断。ページレポートは登録0 / 未登録135で、04月末まで緑→05/01で一斉剥落。
  • 最有力の仮説(未確定):3年間無変更のサイトが落ちた=変わったのはGoogle側の評価。品質・信頼性の再評価による非インデックス化が濃厚。※Google内部は見えないため断定はしていません。
  • 対応:canonical+metadataBase、301集約、サイトマップ再送信、検証開始+登録リクエスト(=どの原因でも無駄にならない整備)。本丸はドメイン昇格・コンテンツ・被リンクの底上げ。

同じように「なんで急に検索から消えたの…」で頭を抱えている方は、まず GSCのURL検査の一文 を見てください。「ページの取得:成功」なのに「インデックス未登録」なら、犯人は技術ではなく品質側にいる可能性が高いです。犯人はまだ完全には挙げられていませんが、切り分けの手順が同じ悩みの方の参考になれば幸いです!経過が出たら追記します。それではまた!