WEBサイト
「順位が落ちた」と言われた週に、公式は何を確認していたか
2026年8月の前半、SEOコミュニティの一部で「順位が落ちた」「トラフィックが減った」という声が相次いだ。こういう時、WEBディレクターが最初にやるべきことは、自分のサイトの数字を見る前に、公式が何を言っているかを確認することだ。
Google の公式情報源は2つある。Search Status Dashboard（コアアップデート等の確定発表を掲載）と、Search Central Blog（詳細な解説を掲載）だ。この記事を書いている時点で、両方を確認した。
- Search Status Dashboard：8月分の confirmed（確定）アップデートは0件
- 直近の confirmed は 2026年6月24〜26日のスパムアップデート。それ以降、8月に入るまで新しい確定発表はない
- Search Central Blog：8月分の投稿も0件
つまり、少なくとも公式が「これをやりました」と名乗り出ているものは、今のところ何もない。これは「何も起きていない」ことの証明ではない。Google は日常的に無数の小さな調整をアルゴリズムに加えており、そのすべてに confirmed のラベルを付けるわけではないからだ。しかし「大規模なコアアップデートが発表された」という前提で自分のサイトを疑い始めるのは、少なくとも今の時点では早い。
では、何が起きていたのか（二次情報として）
公式の確認がゼロでも、SEOコミュニティの体感が嘘というわけではない。2026年8月6日に公開された業界メディアの報告によれば、8月1日から6日にかけて、順位変動やトラフィック減少の報告が SEO コミュニティで多数上がっていたという。
ただし、ここで注意が必要だ。この報告は一次情報ではない。Google 自身が変動を認めたわけではなく、サードパーティの順位追跡ツールが変動を検知している、という状態が報告されているに過ぎない。記事の中では、この状態を指して「third-party tracking tools のみが変動を示している」という趣旨の記述がある。つまり「公式には確認されていないが、複数の外部ツールが揃って変動を検知している」という、確定と噂の中間にあるステータスだ。
この記事では、具体的な被害の数値（「◯%減った」といった個別の報告）については、一次記事を直接検証できていないため使わない。「多くの人が変動を報告している」という体感の広がりと、「Google が何かを確定発表した」という事実は、別のものとして扱う。これがこの記事の出発点になる。
自分のサイトで測るなら、どこを見るか
公式発表がなく、体感だけがコミュニティに広がっている時、WEBディレクターがまずやるべきなのは、順位ツールの数字を眺めて一喜一憂することではない。自分のサイトに、実際に何が起きているかを確認することだ。順位の変動には、アルゴリズム側の要因と、自分のサイト側の要因の両方があり得る。切り分けないまま「コアアップデートだ」と結論づけると、本当は自分側に原因がある問題を見逃す。
1. クローラーが来ているか（サーバーログ）
順位が落ちる前に、まずクロール頻度が落ちていないかを確認する。access log から Googlebot の User-Agent を含む行を抽出し、日次の件数を数える。ただし User-Agent は名乗るだけなら誰でも書ける。逆引き（reverse DNS）で `Googlebot.com` に解決するかまで確認しないと、偽装した相手を Googlebot として数えてしまう。当サイトでは以前、正規クローラーを IP で検証する実装について書いた（archives/93）。UA だけを信用しないことが、この確認の前提になる。
2. クローラーに 403 / 5xx を返していないか
クロール頻度の低下が、Google 側の判断ではなく、自分のサーバーが正規クローラーを弾いていることが原因、というケースは珍しくない。WAF・IP制限・レート制限などを追加した直後は特に疑うべき箇所だ。当サイトでも、AI botsのブロック設定について過去に書いたことがある（archives/86）。設定を変えた日と、クロール数が変化した日を突き合わせるだけで、多くの誤検知は防げる。
3. 単日ではなく、7日移動平均で見る
クロール数にも順位変動にも曜日の影響がある。1日だけの数字で「激減した」と判断するのは早計だ。次の章で、当サイトの実測データを使ってこの点を具体的に示す。
自分のサイトのクロール状況・エラー率・インデックス状況を毎日確認する仕組みがまだ無い場合は、まず Search Console の「クロール統計情報」と「ページのインデックス登録」の2画面を毎朝チェックする習慣から始めるといい。当サイトの無料AI対応診断ツール（こちら）でも、自分のサイトが主要クローラーに正しく応答しているかの簡易確認ができる。
当サイトの実測 — Googlebotは7日平均27.0件に対して約1/4になったが、止めているのは自分ではない
ここからは、当サイト自身のログを使って、上で挙げた3つの確認ポイントを実演する。
当サイトは 2026年8月7日 13:13 JST に、.htaccess へ日本国内 IP レンジ + 正規クローラーの公式 IP レンジのみを許可する制限を投入した。日本の APNIC 割当 CIDR 3,142 件と、Google・Bing・OpenAI・Anthropic・Perplexity・Apple・Amazon・Meta・CCBot の9ベンダー（各ベンダーが配布する公式 IP レンジのソースファイルは、複数系統に分かれているものを含めて計16）分の IP レンジを合わせた許可リストで、値の総数は 6,070。User-Agent による例外は一切設けていない（理由は次の見出しで書く）。
この変更の前後で、Googlebot（IP を 66.249.* 系の公式レンジに限定して集計）が実際に 200 を取得した日次件数は次の通りだ。
| 日付 | Googlebot 200件数 | 備考 |
|---|---|---|
| 8/1 | 36 | 制限投入前 |
| 8/2（日） | 3 | 制限投入前・曜日要因の前例 |
| 8/3 | 32 | 制限投入前 |
| 8/4 | 45 | 制限投入前 |
| 8/5 | 34 | 制限投入前 |
| 8/6 | 18 | 制限投入前 |
| 8/7 | 21 | 制限投入日（13:13〜） |
| 8/8 | 7 | 制限投入後 |
| 8/9 | 8 | 制限投入後・記録時点で日中まで（部分日） |
7日平均は約27.0件。8/8・8/9 は明らかに低い水準にある。ここだけを見ると「制限をかけたせいで Google に嫌われた」と早合点しそうになる。だが、確認すべきはそこではない。同じ期間、Google 系クローラーへの 403（アクセス拒否）の件数は 0件だ。つまり、こちらが正規の Googlebot を弾いているわけではない。
この7日平均は、公開前の監査で一度訂正した数字だ。当初は User-Agent ベース（偽装 Googlebot を含む母数、8/1〜8/7 の合計237件÷7≒33.9件）で算出しており、上の表の9日分の実測値（IP を 66.249.* 系の公式レンジに限定した母数）とは別の母数を比較していた。偽装を排除するために入れた制限の効果を、偽装込みの平均線と比べていたことになる。母数を表と揃えると、8/1〜8/7 の合計189件÷7＝27.0件になる。
むしろ、この制限は別のところで効いている。制限投入前の 8/1〜8/7 の期間、Googlebot を名乗りながら公式 IP レンジに属さない「偽装 Googlebot」が 200 を取得していた件数は、日ごとに 13, 3, 11, 9, 6, 9, 20 と推移していた。制限投入後の 8/8・8/9 は、いずれも 0件だ。
UA を偽装したアクセスの実例も見つかっている。142.147.242.187 は "Googlebot" を名乗るが逆引き結果に PTR レコードが無く、113.173.204.225 は "ClaudeBot" を名乗るが逆引き先は static.vnpt.vn（Google/Anthropic とは無関係のプロバイダ）だった。正規のクローラーは、UAだけで判定すると必ずこうした偽装に紛れる。だから今回の制限では UA による例外を一切作らなかった。1つ例外を作れば、そこが偽装の入口になる。
ただし、日曜のデータで判断してはいけない
ここまでの数字を見て、「じゃあ制限は成功だったんだな」とすぐに結論づけるのも、実は早い。理由は2つある。
1つ目は曜日の影響だ。表の中の 8/2（日）は、制限を投入する5日も前の時点で、すでに 3件という低い数字を記録している。つまり1桁台の低い数字は、今回が初めてではない。もし 8/8・8/9 の低さだけを見て「制限が原因だ」と即断していたら、8/2 という前例を見落としたことになる。7日移動平均のような複数日の比較なしに、単日の数字だけで因果関係を語るのは危険だ。
2つ目は、8/8・8/9 のデータそのものに別の要因が混入している可能性がある、という点だ。それを次の章で正直に書く。
self-proof：この記事を書いている当サイトが、測る装置を2日止めていた
ここまで「自分の数字を測れ」と読者に勧めてきた。だが、その当サイト自身が、直近2日間、測る装置を正常に動かせていなかった。ここを隠さずに書く。
当サイトは毎朝、サイト内の記事がインデックスされているかを自動で確認するレポートを走らせている。直近3日間の結果は次の通りだ。
- 8/6：
Blog inspection done: 117/121 indexed.— 正常 - 8/7：
Blog inspection done: 64/121—Error: fetch failed（IP制限を投入した当日） - 8/8：
Blog inspection done: 7/121—Error: fetch failed
bot を止めた効果を測るための装置が、止めた翌日から止まっていた。これでは、上の章で示した「効果があった」という主張自体、どこまで信用してよいのか怪しくなる。
調べる前に、まず確認すべきことがあった。Error: fetch failed は今回が初めてではない。ログを遡ると、7/25（70/114 indexed）・8/3（19/120 indexed、8/7 の 64/121 より悪い数字）・8/4（結果自体が記録されないほどの完全失敗）でも同じエラーが出ている。今回の 8/7・8/8 を含めても、記録されている4回の失敗のうち3回は、bot 制限を投入するより前に起きていた。本文で Googlebot の件数を見るときは 8/2 という前例を確認したのに、自分の監視装置の異常については、同じ確認を怠っていた。制限だけが原因だと決めつけることはできない。実際に何が起きていたのかを調べた。
原因①：応答時間が悪化していた（ただし断定はできない）
IP制限を投入した後、記事1本あたりの応答時間を測ったところ、平均で約0.90秒かかっていた。対照として、静的ファイルである robots.txt への応答時間は約0.025秒。121本の記事を巡回するレポートは、単純計算で 85〜170秒かかることになり、制限投入後の8/7・8/8については、この応答時間が寄与した可能性がある。
ただし、この 0.90秒という数字が、今回追加した許可リスト（6,070件）の評価コストによるものなのか、それとも PHP 側の処理時間によるものなのかは、まだ切り分けられていない。ここは「原因が特定できた」と書けるところまで進んでいない。
原因②：無関係だが重なっていた既存ルール
調べる過程で、もう1つの要因が見つかった。当サイトには、User-Agent が空のリクエストを 403 で弾くルールが存在していた（今回の変更とは無関係）。設定ファイルのバックアップを確認したところ、このルールは少なくとも2026年3月19日の時点で既に存在しており、.htaccess 内にある「2026-04-20 追加」というコメントは、同じルールの隣に書かれた攻撃ツール検知用 UA リストに Amazonbot を追加した日を指すものだった（その Amazonbot は 2026年8月7日に、誤ってブロックしていたことが分かって除外済み）。当サイトのレポート生成に使っている Node.js の https.request は、デフォルトでは User-Agent ヘッダーを送らない。実際に検証したところ、UA を付けたリクエストは 200、UA を空にしたリクエストは 403、UA に node という文字列だけを入れたリクエストは 200 だった。陽性対照として Googlebot の UA を使うと 200、陰性対照として sqlmap（攻撃ツールの典型的な UA）を使うと 403 になることも確認済みだ。
つまり、レポート自体が、自分自身のサーバーに「UAの無いbot」として弾かれていた可能性がある。これが原因①とどちらがどれだけ効いているかは、まだ分かっていない。ただし、同じ UA 空ルールの下で、3/19 以降 141 日のうち 136 日はレポートが成功していた。したがって原因②は、今回の変化を単独で説明する引き金にはならない。
この記事は「順位や数字を騒ぐ前に、自分のデータで測れ」という話を書いている。その記事を書いている当サイトが、測る装置を2日間、正常に動かせていなかった。これは恥ずかしい話だが、隠さずに書く方が読者にとって価値があると判断した。
まとめ — 明日できること3つ
- 順位変動の噂を見たら、まず Search Status Dashboard で confirmed の有無を確認する。ゼロなら、コミュニティの体感と公式発表は別物として扱う。✅ 当サイト実施済
- 自分のサイトのクローラーログを、単日ではなく直近7日の平均で見る。1日だけの低い数字は、曜日の影響である可能性を先に疑う。✅ 当サイト実施済
- WAF・IP制限・bot対策などのアクセス制御を追加したら、その直後に「自分自身の監視ツール」がまだ正しく動いているかを、実際にリクエストを送って確認する。効果を測る装置を止めたまま「効果があった」と言わない。🔧 当サイト原因切り分け中
公式の発表がないまま、コミュニティの体感だけが広がる週は、これからも来る。そのたびに順位ツールの画面を睨む前に、自分のサーバーが今日、誰にどんな応答を返しているかを見る。それが、明日からできる一番確実なことだ。
関連 archives（連載軸として読む）
- archives/120「『2027年に半減』の土台は、7.1%の1点だった ── AI検索の数字から「仮定」を分離する3つの手順」 ── 直系の続編。「仮定と実測を混同しない」という同じ骨を、今回は変動騒ぎと自サイトの実測で実演した。
- archives/93「Cloudflareが『検証』の定義を変えた日 — Search/Agent/Training 三分類の刷新と、37体allowの次の一手」 ── 正規クローラーをIPで検証する実装について書いた記事。今回の偽装Googlebot発見の前提になっている。
- archives/86「Cloudflareのデフォルト『AI bots ブロック』があなたのGEOを殺している — robots.txt無関係のインフラ層ブロックと、WEBディレクターが今すぐ確認すべき3つの設定」 ── AI botsのブロック設定について書いた記事。今回の.htaccess変更の背景にある考え方。
- archives/115「llms.txt を置いて51日、正直に答え合わせ第2弾 ── Google が『効かない』と言った以上に、他の AI も読みに来ていなかった」 ── 「自分のサイトで測る」の実弾その1。llms.txtへの実アクセスをログで測った記録。
- archives/116「1サイトの実測は仮説、2サイトの一致は事実 ── llms.txtを8言語サイトでも測ったら、AIクローラーが1件も来ていなかった」 ── 「自分のサイトで測る」の実弾その2。1サイトの実測を2サイト目でも突き合わせた記録。
