記事執筆者：認定SEOコンサルタント 三田健司
「サーバー会社のセキュリティ設定を強化したら、なぜか検索順位が下がった気がする」というご相談を、ここ数年で何度も受けてきました。原因を追いかけていくと、セキュリティ設定がGoogleのクローラーを部分的に弾いていた、というケースが実際にあります。
2026年8月上旬、GoogleのGary Illyes氏が、Googleのクローラーが送るHTTPリクエストについて興味深い説明を公開しました。GoogleはGETとPOSTだけでなく、HEAD・OPTIONS・PUT・PATCH・DELETEといったリクエストも送っている、という内容です。
一見すると技術者向けのマニアックな話に思えます。しかし中小企業のサイト運営では、レンタルサーバーのWAFやセキュリティプラグインが「GETとPOST以外は全部拒否」という設定になっていることが珍しくありません。
この記事では、Googleが送るHTTPメソッドの実態と、それを遮断してしまったときにサイトで何が起きるのかを、Google公式ドキュメントの記述と合わせて整理します。自社サイトを確認する具体的な手順まで、専門用語をかみくだいて解説します。
GooglebotはGETとPOSTだけを送っているわけではない
Google担当者が明かした「1.5%未満」という数字
2026年8月上旬、GoogleのGary Illyes氏がLinkedInで、「Googleのクローラーは、GETとPOST以外のHTTPリクエストも送るのか」という質問に答えました。回答は「送っている」というものでした。
同氏によれば、HEAD・OPTIONS・PUT・PATCH・DELETEを合わせても、Googleの全クローラーが送るリクエスト総数の1.5%未満にとどまります。つまり圧倒的多数はGETであり、例外的に他のメソッドが混ざる、という構図です。
この情報はSearch Engine Roundtableをはじめとする海外のSEOメディアでも取り上げられ、2026年8月7日付で報じられています。数字の出どころはGoogleの担当者本人の発言であり、推測ではありません。
HTTPメソッドとは何か｜専門用語をかみくだく
HTTPメソッドとは、ブラウザやクローラーがサーバーに対して「何をしてほしいか」を伝える合図のようなものです。宅配便でいえば「荷物を届けてください」「中身を確認させてください」といった依頼の種類にあたります。
GETは「そのページの中身をください」という最も基本的な依頼です。POSTは「この情報を送ります」という依頼で、お問い合わせフォームの送信などで使われます。
HEADは「中身は要らないので、ページの情報だけ教えてください」という軽い確認です。OPTIONSは「このURLに対してどんな依頼ができますか」という問い合わせで、外部サービスとデータをやり取りするときに使われます。
PUT・PATCH・DELETEは、本来は「データを書き換える・消す」ための依頼です。名前だけ見ると物騒に感じますが、後述するとおりGoogleがサイトのデータを書き換えようとしているわけではありません。
なぜこの話が中小企業に関係するのか
多くのレンタルサーバーやセキュリティ製品には、「使わないHTTPメソッドは拒否する」という考え方の設定が用意されています。攻撃の入口を減らすという意味では、極めてまっとうな発想です。
ただし、その設定が強すぎると、Googleがページを正しく読み取るための通信までまとめて遮断してしまうことがあります。セキュリティを上げたつもりが、検索エンジンから見たサイトの姿を壊してしまうという状況です。
筆者はこれまでWeb制作とSEOの現場に10年以上携わり、延べ1,000件以上のサイトに関わってきました。その経験のなかでも、サーバー側の設定が原因の不具合は「気づきにくく、気づけば一瞬で直る」典型例です。
なぜGoogleがGET以外のリクエストを送るのか
原因はページ内のJavaScript
Illyes氏は、これらのリクエストが発生する理由についても触れています。ページに組み込まれたJavaScriptがそうした通信を始めているように見える、という趣旨の見方を示しています。
この説明を踏まえると、Googleが独自の判断でPUTやDELETEを送っているというより、リクエストの出どころはそのサイト自身のJavaScriptだと考えるのが自然です。なお、これはGoogleの担当者個人の見解として示されたもので、公式ドキュメントに明記された仕様ではありません。
近年のサイトは、外部のAPIや予約システム、チャットツールなどをJavaScriptで呼び出すことが増えました。その過程でOPTIONSリクエストが発生するのは、技術的にはごく自然な挙動です。
レンダリングという工程を理解する
Googleがページを検索結果に載せるまでには、大きく分けてクロール・レンダリング・インデックスという3つの工程があります。クロールはページを取りに行く工程、レンダリングはブラウザと同じようにページを組み立てる工程です。
レンダリングの段階では、GoogleはChromeに近い仕組みでJavaScriptを実行します。そのため、ブラウザで起きる通信は原則としてGoogle側でも起きると考えるのが自然です。
逆にいえば、レンダリング時の通信が失敗すると、Googleが最終的に見るページは「本来の姿とは違うページ」になります。ここが今回の話の実務的な要点です。
Googleがサイトのデータを消すわけではない
DELETEやPUTという言葉から、「Googleが勝手に投稿を消してしまうのでは」と心配される方がいます。今回の説明を素直に読む限り、そのような話ではありません。
これらのリクエストは、あくまでページ内のJavaScriptが呼び出した先に向かって送られるものです。多くの場合、そもそもサーバー側が受け付けずにエラーを返して終わります。
また、Googleのクローラーは会員限定ページなどログインが必要な領域には入れません。過度に心配する必要はありませんが、意図しない通信が発生していないかを一度確認しておく価値はあります。
中小企業サイトでよくある「HTTPメソッド制限」の設定
レンタルサーバーのWAFが自動で弾いている
WAFとは、Webサイトへの攻撃を自動で防ぐ仕組みのことです。国内の主要なレンタルサーバーでは、管理画面のスイッチひとつでWAFを有効にできるようになっています。
WAFのルールは日々更新され、疑わしい通信を機械的に遮断します。その判定基準のなかに、GETとPOST以外のメソッドを一律で拒否するルールが含まれていることがあります。
やっかいなのは、この遮断がサイトの表示画面には出てこない点です。人がブラウザで見る分には何も問題がないため、担当者が気づく機会がほとんどありません。
セキュリティプラグインの初期設定
WordPressのセキュリティプラグインにも、同様の機能を持つものがあります。「使用しないHTTPメソッドをブロックする」といった項目が、初期状態で有効になっている場合があります。
加えて、WordPressのREST APIを丸ごと無効化する設定を入れているサイトも見かけます。REST APIは記事データをやり取りする仕組みで、外部連携やブロックエディタの一部機能が依存しています。
これらは「攻撃を減らす」という点では効果があります。一方で、テーマやプラグインが内部で使っている通信まで巻き込むと、表示崩れや機能停止につながることがあります。
CDN・リバースプロキシ側の制限
表示速度を上げるためにCDNを導入しているサイトでは、サーバーより手前の段階で通信が処理されます。CDNの管理画面にも、メソッドやボットに関する制御ルールが用意されています。
設定した本人以外には見えにくい層なので、原因調査が長引きやすい部分です。サーバー・CDN・プラグインのどこで止まっているのかを、切り分けて確認する姿勢が欠かせません。
制限そのものは悪ではない
誤解のないように書き添えますが、HTTPメソッドを絞ること自体は正しいセキュリティ対策です。使っていない入口を閉じておくのは、基本に忠実な考え方といえます。
問題になるのは、自社サイトが実際に何を使っているかを把握しないまま、一律で閉じてしまうケースです。大切なのは「閉じるか開くか」ではなく「何を閉じたかを把握しているか」です。
メソッドを遮断すると検索順位に何が起きるのか
レンダリングが途中で止まる
最も影響が出やすいのは、JavaScriptで本文や商品情報を読み込んでいるページです。必要な通信が遮断されると、Googleが組み立てたページには中身が入りません。
結果として、テンプレートの枠だけが残った「空っぽのページ」として評価される可能性があります。担当者がブラウザで見れば正常なだけに、発見が遅れがちです。
逆に、本文がHTMLに直接書かれているサイトであれば影響はほとんどありません。WordPressで通常の投稿を書いている中小企業サイトの多くは、この安全側に入ります。
403や405が大量に出るとどうなるか
403は「アクセスを拒否した」という応答、405は「その依頼の種類は受け付けていない」という応答です。どちらもクライアント側のエラーを示す4xxに分類されます。
ページ本体が403を返している場合、影響は深刻です。Google公式ドキュメントは、4xxを返すURLの内容は使われず、既にインデックスされていたURLは削除されると明記しています。
一方、JavaScriptが呼び出す補助的なURLだけが405を返している場合は、影響はそのページの表示内容にとどまります。どのURLがエラーを返しているのかを見極めることが、対処の第一歩です。
影響が出やすいサイト・出にくいサイト
影響が出やすいのは、予約システムや在庫情報を外部サービスから読み込んでいるサイトです。求人情報や店舗一覧を別システムから取得している場合も同様です。
反対に、静的なHTMLとして本文が出力されているコーポレートサイトやブログは、ほとんど影響を受けません。まずは自社がどちらに近いかを把握すれば、優先度の判断ができます。
Google公式が示すHTTPステータスコードの扱い
4xxはインデックスから消える（429を除く）
Googleのクロール関連ドキュメントには、ステータスコードごとの扱いが表にまとめられています。4xxについては、429を除くすべてが同じ扱いになると書かれています。
具体的には、クローラーが次の処理工程に対して「そのコンテンツは存在しない」と伝えます。すでにインデックスされていたURLは、検索結果から削除されます。
さらに、そのURLへのクロール頻度は徐々に下がっていくと説明されています。誤って403を返し続けると、復旧後の再評価にも時間がかかることになります。
401・403でクロール制限をしてはいけない
同じドキュメントには、クロール速度を落とす目的で401や403を使わないように、という注意書きがあります。429を除く4xxはクロール速度に影響しないためです。
サーバー負荷を下げたいときの正しい方法として、Googleは429や5xxを返す方法を案内しています。負荷対策のつもりで403を返すと、負荷は減らずインデックスだけが失われかねません。
WAFが自動的に403を返す設定になっている場合、この落とし穴に近い状態が起こり得ます。「拒否の仕方」にも適切なやり方がある、という点は覚えておきたいところです。
5xxと429はクロール速度を落とすサイン
500・502・503といった5xxと、429はサーバー過負荷のサインとして扱われます。Googleはこれを受け取ると、一時的にクロールの速度を落とします。
インデックス済みのURLはしばらく保持されますが、状態が続けば最終的には削除されます。サーバーが2xxを返すようになれば、クロール速度は段階的に戻ると説明されています。
なお、2xxが返っていれば必ずインデックスされるわけではない点にも、公式ドキュメントは触れています。正常応答は出発点であって、保証ではありません。
自社サイトを確認する5つの手順
手順1｜Search Consoleのページレポートを見る
まずはSearch Consoleの「ページ」レポートを開きます。ここには、インデックスされなかったURLとその理由が一覧で表示されます。
注目したいのは「アクセス拒否（403）により block されました」や「その他の4xxの問題によりブロックされました」といった項目です。ここに公開中のページが並んでいたら、サーバー側の設定を疑う価値があります。
件数が数件なら過去の残骸である可能性もあります。数十件以上が同時期に増えている場合は、設定変更のタイミングと突き合わせてみてください。
手順2｜URL検査でレンダリング結果を確認する
次に、Search Consoleの上部にある検索窓に自社ページのURLを入れて「URL検査」を実行します。表示後に「公開URLをテスト」を押すと、Googleが今その場でページを取得します。
テスト結果の画面では、スクリーンショットとHTML、そして「ページのリソース」を確認できます。ここで読み込みに失敗したファイルが並んでいれば、その原因を追いかけます。
ブラウザで見た画面とスクリーンショットが大きく違う場合は、レンダリングに問題が起きている可能性が高い状態です。この画面はエンジニアでなくても読めるので、まず見てほしいポイントです。
手順3｜サーバーのアクセスログを確認してもらう
より確実なのは、サーバーのアクセスログを見ることです。ログにはリクエストの種類と応答コードが記録されているため、何がどう拒否されたかが分かります。
ログの取得や読み解きは制作会社やサーバー会社に依頼するのが現実的です。自社で無理に触る必要はなく、依頼の仕方さえ分かっていれば十分です。
手順4｜制作会社・サーバー会社への確認文例
専門用語で説明する必要はありません。次のような文面をそのまま送れば、担当者には十分伝わります。
「当社サイトについて、WAFやセキュリティ設定でGETとPOST以外のHTTPメソッド（HEAD・OPTIONSなど）を拒否している設定があるかご確認ください。あわせて、Googlebotからのアクセスに403や405を返している記録がないかもお願いします。」
この一文で、確認すべき範囲がはっきりします。「順位が下がった気がする」という相談よりも、具体的な設問のほうが解決は早く進みます。
手順5｜修正後の再確認を忘れない
設定を直したら、もう一度URL検査で「公開URLをテスト」を実行します。ここで正常なスクリーンショットが取得できれば、ひとまず復旧と判断できます。
ただし検索結果への反映には時間差があります。再クロールと再評価には数日から数週間かかることがあり、期間を確約することはできません。
WordPressサイトでの具体的な対処と判断基準
セキュリティプラグインの設定を見直す
まずは導入済みのセキュリティプラグインの設定画面を開き、HTTPメソッドやREST APIに関する項目を探します。該当する設定があれば、有効にした時期をメモしておきます。
設定を変える前に、必ずバックアップを取ってください。プラグインの設定変更は表示に直結するため、戻せる状態を作ってから作業するのが鉄則です。
変更は一度にひとつずつ行い、そのつど表示を確認します。まとめて変えると、どれが効いたのか分からなくなります。
.htaccessに書かれた制限を確認する
サーバーによっては、.htaccessというファイルにメソッド制限が書かれていることがあります。過去の制作会社が入れた記述が、そのまま残っている場合もあります。
このファイルは書き換えを誤るとサイト全体が表示できなくなります。自社で編集せず、必ず制作会社かサーバー会社に依頼してください。
JavaScript依存度を下げるという根本対策
今回の話は、突き詰めると「JavaScriptに頼りすぎたページほど壊れやすい」という構造の問題です。大事な情報ほど、HTMLに直接書き出しておくのが安全です。
サービス内容・料金・所在地・電話番号といった中核の情報は、スクリプトに頼らず出力する設計にしておきます。これはAI検索に引用されやすくする観点からも有効です。
WordPressで通常どおり記事を書いている場合、本文はHTMLとして出力されます。この点で、WordPressは中小企業にとって扱いやすい選択肢だといえます。
セキュリティと検索性のバランスをどう取るか
結論としては、セキュリティ設定を緩める必要はありません。必要なのは、閉じている入口を把握し、サイトが実際に使っている通信だけは通すことです。
判断に迷ったら、まず影響範囲の小さいところから確認していきます。手を動かす前に現状を把握するほうが、結果的に早く解決します。
よくある質問（FAQ）
HEADやOPTIONSを拒否すると必ず順位が下がりますか？
必ず下がるとは言えません。本文がHTMLに直接書かれているサイトであれば、影響はほとんど出ないと考えられます。
一方、JavaScriptで本文や商品情報を読み込んでいるページでは、内容が正しく認識されない可能性があります。まずは自社サイトの作り方を確認するところから始めてください。
1.5%未満なら気にしなくてよいのでは？
割合としては小さい数字です。ただしその1.5%が、自社の重要ページのレンダリングに関わっている可能性は否定できません。
全体の比率ではなく、自社サイトで実際に何が起きているかで判断するのが正しい向き合い方です。確認自体は無料でできるので、一度見ておく価値はあります。
WAFはオフにしたほうがよいのでしょうか？
推奨しません。WAFは不正アクセスや改ざんを防ぐ重要な仕組みで、オフにすればリスクが上がります。
目指すべきは、必要な通信だけを個別に許可する調整です。除外設定の方法はサーバーごとに異なるため、契約先のサポートに確認してください。
403エラーはどれくらいで検索結果から消えますか？
明確な日数は公表されていません。Googleの説明では、4xxを返すURLはインデックスから削除され、クロール頻度も徐々に下がるとされています。
復旧後も、再クロールと再評価には時間がかかります。期間を確約することはできませんので、早めに気づいて早めに直すことが最善の対策です。
サーバー負荷が心配なときは何を返せばよいですか？
Googleは、クロール速度を落としたい場合に429や5xxを返す方法を案内しています。401や403を負荷対策に使わないよう、公式ドキュメントで明確に注意されています。
ただし5xxを返し続ければ、いずれインデックスからも外れます。恒久的な対策としては、サーバーの増強やキャッシュの活用を検討するほうが確実です。
法務や契約に関わる部分はどう考えればよいですか？
サーバー契約やセキュリティ製品の利用条件は、契約内容によって扱いが異なります。責任範囲の解釈が必要な場面では、弁護士など専門家にご相談ください。
技術的な確認と契約上の確認は別物です。設定変更を依頼する際は、作業範囲と費用を書面で残しておくと安心です。
まとめ｜GooglebotのHTTPメソッドと中小企業の対策
Googleのクローラーは、GETとPOST以外にHEAD・OPTIONS・PUT・PATCH・DELETEも送っています。Googleの担当者によれば、その割合は全リクエストの1.5%未満です。
これらのリクエストを出しているのは、Googleではなくページ内のJavaScriptです。レンダリングの過程で、ブラウザと同じ通信が再現されているにすぎません。
問題になるのは、WAFやセキュリティプラグインが必要な通信まで一律に遮断してしまう場合です。JavaScriptに依存したページほど、影響が表に出やすくなります。
Google公式ドキュメントは、429を除く4xxを返すURLはインデックスから削除されると明記しています。クロール制限の目的で401や403を使わないようにという注意も添えられています。
今日できる一歩として、Search Consoleの「ページ」レポートを開き、403や4xxでブロックされたURLがないかを確認してみてください。ここに公開中のページが並んでいないかを見るだけでも、状況はかなり見えてきます。
サイトの技術的なSEOのご相談はアクセス・リンクへ
株式会社アクセス・リンクは、栃木県下野市を拠点に、SEOコンサルティングとホームページ制作を行っています。代表の三田健司は全日本SEO協会の認定SEOコンサルタントとして、日々Googleの公式情報を追いながら支援にあたっています。
「順位が下がった原因が分からない」「サーバー設定が検索に影響していないか確認したい」といったご相談も承っています。技術的な調査から改善提案まで、経営者やWeb担当者にわかる言葉でご説明します。
ご相談はお問い合わせフォームから承っております。現状のサイトを見たうえでの具体的なアドバイスをご希望の方も、お気軽にご連絡ください。
記事執筆・株式会社アクセス・リンク 代表取締役
Webサイト制作歴10年以上の経験を元にSEOコンサルティングを行い、延べ1,000件以上のサポート実績を誇ります。個人事業主や中小企業向けのホームページ制作やSEOコンサルティングを得意としています。
（社）全日本SEO協会 認定SEOコンサルタント
コメント