Webサイト運用で押さえたいレスポンス設計とクローラー対策

codexやclaude codeにより自分で作成したWebサイトの公開のハードルは大きく下がった word press等を使用しなくても簡単に自分の好きなデザインにすることが出来る。 ただ、Webサイトは公開して終わりではなく、公開してからの運用の方が長い。業務でも同様に新規開発期間より運用期間の方が長いことが多い。 そして、運用を始めると表示崩れやフォーム不具合よりも先に、レスポンスの返し方やクローラーへの見せ方でじわじわ問題が出ることがある。

たとえば次のような状態は、見た目では気づきにくいが、運用上はかなり危ない。

• 存在しないURLで200を返している
• メンテナンス中なのに通常ページ扱いでクロールされる
• ステージング環境が検索結果に出る
• 不要なパラメータ付きURLが大量にクロールされる
• エラーページなのにキャッシュされ続ける

この記事では、Webサイト運用で先に見ておきたいポイントを、HTTPレスポンスとクローラー対策の2つに分けて整理する。
アプリケーション開発というより、公開後の事故を減らすための運用観点に寄せている。

まず最初に押さえたいこと

最初に意識したいのは次の4点である。

1. ページ内容とHTTPステータスコードを一致させる
2. クロールさせるURLとさせないURLを明確に分ける
3. インデックスさせたくないページは複数の層で制御する
4. エラー系レスポンスとキャッシュの組み合わせを雑にしない

サイト運用では、ブラウザで正しく見えることと、検索エンジンや監視基盤に正しく伝わることは別問題である。 見た目が正常でも、レスポンス設計が崩れているとSEO、監視、キャッシュ、セキュリティの各面で後から効いてくる。googleアドセンスの申請等にはこの辺の設定が大きくかかわっているようだ。

1. 404 と 410 を正しく返す

まず、存在しないページで200を返す構成は避けたい。
いわゆる soft404 の状態で、ユーザーにもクローラーにも誤解を与えやすい。

典型的な問題は次の通りである。

• 削除済み記事のURLで「記事がありません」と表示しつつ200を返す
• ルーティングの都合で全URLをトップページ扱いにしてしまう
• カスタム404画面を出しているが、実際のHTTPステータスは200のまま

基本方針は次である。

• 存在しないページは404を返す
• 今後も戻さない削除済みコンテンツは410も検討する
• 代替ページが明確にある場合だけ301や308で転送する

削除した記事を全部トップページへリダイレクトするような実装は、ユーザーにも検索エンジンにも不親切である。
近い移転先がないなら、素直に404か410を返した方がよい。

2. 301 と 302 を使い分ける

次に、リダイレクトは単に飛ばせばよいわけではない。
恒久移転なのか一時的な退避なのかで、選ぶステータスが変わる。

• 恒久的なURL変更
  • 301または308
• 一時的な移動
  • 302または307

気を付けたいのは、CMS移行やURL設計変更のときに302のまま放置するケースである。
これを続けると、検索エンジン側で評価の引き継ぎが不安定になったり、古いURLが残り続けたりする。

また、リダイレクトチェーンも避けたい。

• A -> B -> C のような多段転送
• HTTPからHTTPSへ飛ばしたあと、さらに末尾スラッシュ調整で転送
• 大文字URLや末尾index.htmlの吸収がバラバラ

運用時は、最終URLに一回で到達する構成へ寄せた方がよい。

3. メンテナンスや障害時のレスポンスを誤らない

また、メンテナンス画面を出していても200を返しているケースは意外と多い。
しかし実際には、通常配信できていない状態なら503を使うべき場面がある。

特に次のようなケースは503が候補になる。

• 計画メンテナンスで一時的に停止している
• バックエンド障害で正常応答できない
• アクセス集中で意図的に退避画面を返している

このときは Retry-After ヘッダも合わせて検討したい。
クローラーやクライアントに「一時的な停止」であることを伝えやすくなる。

逆に、障害ページやメンテナンスページを長時間200で返すと、正常ページとして評価されたりキャッシュされたりして面倒になる。

4. キャッシュ系ヘッダをページ種別で分ける

レスポンス設計では、ステータスコードだけでなくキャッシュ制御も重要である。
全ページ一律のキャッシュ設定だと、公開後の修正反映やエラー時の挙動で困りやすい。

ざっくり次のように分けて考えると整理しやすい。

• 静的アセット
  • 長めにキャッシュして、ファイル名変更で更新を伝える
• 通常のHTML
  • 短めのキャッシュや再検証を前提にする
• ログイン後ページや個別ユーザー向け画面
  • 共有キャッシュを避ける
• エラーページやメンテナンスページ
  • 不必要な長期キャッシュを避ける

特に注意したいのは、CDNやリバースプロキシがエラーレスポンスを想定以上に保持するパターンである。
アプリ側では復旧していても、利用者には古い503画面が見え続けることがある。

5. robots.txt は万能ではない

クローラー対策というと、まず robots.txt を置く話が出る。
もちろん重要だが、これだけで安心するのは危ない。

robots.txt でできるのは主に次のことだ。

• クロールしてほしくないパスを伝える
• サイトマップの場所を示す

一方で、次のことは保証しない。

• URLを完全に秘匿すること
• インデックスを絶対に防ぐこと
• 悪意あるボットのアクセスを止めること

つまり、robots.txt は「行儀のよいクローラーへのお願い」であって、アクセス制御そのものではない。
管理画面、会員ページ、検証環境の防御を robots.txt に任せるべきではない。 robots.txtに記載するだけで、自作イラスト等をAIに学習させないと謳っているサイトもまれにあるため注意が必要である。

6. noindex を使う場所を整理する

検索結果に出したくないページは、meta robots や X-Robots-Tag による noindex を使う。
対象になりやすいのは次のようなページである。

• サイト内検索結果
• 重複しやすい一覧URL
• フィルタやソートで量産されるパラメータURL
• サンクスページ
• ステージングや一時公開ページ

ただし、ここでも混同しやすい点がある。

• Disallow
  • クロール抑制の指示
• noindex
  • インデックス抑制の指示

両者は役割が違う。
単に robots.txt でブロックしただけでは、外部リンクなどを起点にURLだけが検索結果へ出る余地がある。
検索結果に載せたくないなら、noindex 側の制御も考える必要がある。

7. パラメータ付きURLの増殖を放置しない

運用でかなり効いてくるのが、不要なURLバリエーションの増殖である。
たとえば次のようなURLが無制限に生成されると、クロール予算や評価分散の面で不利になりやすい。

• ?page=
• ?sort=
• ?utm_source=
• ?ref=
• 組み合わせ自由な絞り込み条件

ここで見たいのは次の点である。

• 正規URLを canonical で示せているか
• 不要なパラメータURLに内部リンクを張っていないか
• 検索結果に出したくない一覧を noindex にしているか
• サーバーやCDNのキャッシュキーが無駄に分岐していないか

分析用パラメータを付けること自体は珍しくないが、そのURLをそのまま共有導線や内部リンクへ混ぜると後で散らかりやすい。

8. ステージング環境を公開状態のまま放置しない

運用事故でかなり危険なのがこれである。
ステージングや検証環境が外部公開され、しかも検索エンジンから見える状態になっていることがある。

起こりやすい問題は次の通りである。

• 本番とほぼ同じ内容が重複ページとして見える
• 開発中UIや未公開記事が露出する
• ベーシック認証なしで管理画面やAPIが見える
• テスト用のメール送信や外部連携が誤発火する

対策は noindex だけでは弱い。
少なくとも次のいずれか、できれば複数を組み合わせたい。

• ベーシック認証
• IP制限
• VPN配下への配置
• 本番と分離した認証基盤

「検索に出さない」と「アクセスできない」は別である。
検証環境は、そもそも第三者が触れない状態を先に作るべきである。

9. クローラー向けにサイトマップと内部リンクを整える

対策というと遮断ばかりに意識が向きやすいが、正しくクロールしてほしいページへ迷わず来てもらう設計も重要である。

最低限、次は見ておきたい。

• XMLサイトマップを用意する
• 重要ページへ内部リンクで到達できるようにする
• 孤立ページを作らない
• canonicalを自己参照で安定させる
• 一覧と詳細の導線を崩さない

特に新規公開記事や深い階層のページは、サイトマップだけでなく内部リンク側でも到達性を確保した方がよい。
クローラーは存在するURLを全部自動で見つけてくれるわけではない。

10. 監視ではHTML本文だけでなくステータスも見る

最後に運用面として、監視や動作確認をブラウザ表示だけで済ませない方がよい。
レスポンス異常は、見た目よりHTTPレベルに先に出ることがある。

少なくとも次は定期的に見られると強い。

• 主要ページのHTTPステータス
• Location ヘッダの向き先
• Cache-Control など主要ヘッダ
• X-Robots-Tag や meta robots
• robots.txt とサイトマップの配信状態

「ページは開けるから大丈夫」ではなく、「何を返しているか」を見ないと、SEOや配信の問題は見落としやすい。

まとめ

Webサイト運用で気を付けたいのは、デザインや本文だけではない。
実際には、次のようなHTTPレスポンスとクローラー制御の基本がかなり重要である。

• 404、410、301、302、503を用途に応じて正しく返す
• エラーページやメンテナンスページのキャッシュを雑にしない
• robots.txt を過信せず、noindex や認証と役割を分ける
• パラメータURL、canonical、サイトマップ、内部リンクを整理する
• ステージング環境は検索除外ではなくアクセス制限で守る

公開後の運用では、「見えるか」より「どう返しているか」が効いてくる。
レスポンス設計とクローラー対策を最初に整えておくと、後からの修正コストをかなり減らせる。 もし何かWebサイトやブログを公開しようと思ったときには、一息ついてこの記事等を見ながら公開前の最終確認するのが良いのかなと思う。