1台のサーバーからトップページにpingを打つ稼働監視が教えてくれるのは、「そのサーバーからサイトに届く」という1点だけです。チャレンジページを表示されているドイツの顧客や、CDNのエッジがエラーを返しているブラジルの訪問者については何もわかりません。複数の国で販売や検索順位を狙っているなら、それらの国から可用性とコンテンツを確認することはSEOモニタリングの一部であり、単一のプローブでは決して見えない問題を捉えられます。
このガイドでは、単一拠点のチェックが見落とすこと、市場ごとにテストすべき項目、送信元IPが重要な理由、そして定期実行できる小さなスクリプトを紹介します。
単一拠点の稼働チェックが見落とすこと
1つのプローブから見た「正常」のステータスページは、次のような問題をすべて隠してしまうことがあります。
- 地域的なCDN障害。 CDNは訪問者に最も近いエッジから応答します。他のエッジが正常でも、1つのエッジだけが落ちたり、古いエラーを配信したりすることがあります。
- 壊れたジオリダイレクト。 フランスからの訪問者を
/fr/に送るルールが、ループしたり、存在しないページを指したり、国ごと間違ったストアに送ったりすることがあります。 - 自社のセキュリティルールによる国単位のブロック。 攻撃を受けて強化したファイアウォールやボット対策ルールが、ある地域のすべての訪問者にチャレンジを出し始めることがあります。
- DNSとルーティングの問題。 ジオDNSがある市場をダウンしているオリジンに送ったり、現地のリゾルバーが変更後も長く古いレコードを保持したりすることがあります。
- 誤ったコンテンツ。 ページは表示されるものの、通貨が違う、同意バナーがない、言語が違う、価格欄が空、といった状態です。
どれも監視サーバー上では「ダウン」として現れません。しかし、いずれも訪問者と売上を失い、Googlebotも同じ状況に遭遇すれば検索順位も失います。
市場ごとに確認すべき項目
各国を独立したサイトとして扱いましょう。チェックごとに次を記録します。
- ステータスコードとリダイレクト後の最終URL。 間違ったURLでの200は失敗です。
- 応答時間。 ダウンする前に遅くなっている市場を見つけるためです。
- コンテンツマーカー。 正しい現地版にだけ現れる文字列、たとえば通貨記号、現地の電話番号、翻訳された見出しなどです。
- ブロックの兆候。 チャレンジページのタイトル、CAPTCHAフォーム、自社CDNからの403などです。
- 応答したエッジ。
cf-ray、x-amz-cf-pop、x-served-byなどのヘッダーから読み取り、ある地域で障害が起きたときにどこを調べればよいかを把握します。
まずは収益につながるページから始めましょう。トップページ、主要カテゴリ、商品ページ、チェックアウトの入口です。ユーザーが頼りにしているなら、検索とログインも加えます。
送信元IPが重要な理由
商用の稼働監視サービスの多くは、数十都市のデータセンターからプローブを実行しています。「サーバーが動いているか」を知るには十分ですが、顧客の実際のアクセス経路とは異なります。CDNやボット対策ルールは、データセンターのアドレスを家庭用回線とは別に扱うことが多く、実際の訪問者がチャレンジされている間にプローブだけが素通りしたり、逆に訪問者は問題ないのにプローブだけがブロックされたりします。
対象国のレジデンシャルプロキシを経由したチェックは、この差を埋めます。リクエストはその市場の家庭用回線から送られるため、ジオDNS、CDN、セキュリティルールは現地の顧客と同じように扱います。大きな市場では都市単位まで絞り込むこともでき、たとえばアメリカなら1か所ではなく複数の地域から確認できます。
役割は分けて考えましょう。レジデンシャル経由のチェックは「各市場に何が配信され、正しく動いているか」を見るために使い、正確な応答時間はデータセンターの監視や実ユーザーデータで測ります。プロキシ経由のリクエストには中継が1つ増えるためです。
小さな複数拠点チェッカー
このスクリプトは、URLのリストを複数の国から確認し、リダイレクトをたどってコンテンツマーカーを探します。USERNAME と PASSWORD はご自身のプロキシ認証情報に置き換えてください。
import requests
USER = "USERNAME"
PASS = "PASSWORD"
GATEWAY = "p.shifter.io:443"
CHECKS = {
"de": ("https://www.example.com/", "€"),
"gb": ("https://www.example.com/", "£"),
"us": ("https://www.example.com/", "$"),
"br": ("https://www.example.com/", "R$"),
}
def check(country, url, marker):
proxy = f"http://customer-{USER}-country-{country}:{PASS}@{GATEWAY}"
try:
r = requests.get(url, proxies={"http": proxy, "https": proxy},
timeout=30, allow_redirects=True)
except requests.RequestException as e:
return country, "ERROR", str(e)[:80]
blocked = "captcha" in r.text.lower() or r.status_code in (403, 429)
ok = r.status_code == 200 and marker in r.text and not blocked
edge = r.headers.get("cf-ray") or r.headers.get("x-amz-cf-pop") or "-"
return country, "OK" if ok else "FAIL", f"{r.status_code} {r.url} edge={edge} {r.elapsed.total_seconds():.2f}s"
for country, (url, marker) in CHECKS.items():
print(*check(country, url, marker))cronやCIのスケジューラーで実行し、各行をログや小さなデータベースに書き込み、失敗時にアラートを出します。結果を信頼できるものにする習慣が2つあります。
- アラートの前に確認する。 チェックが失敗したら、同じ国の新しいIPで1回だけ再試行します。2回目も失敗した場合にのみアラートを出します。
- 単発ではなくパターンでアラートする。 1つの国で3回連続の失敗はインシデントです。週に1回のタイムアウトはノイズです。
チェックを習慣にする
- Search Consoleとアナリティクスから市場を選ぶ。 トラフィックと売上をもたらしている国と、これから伸ばしたい国です。
- 価値に応じて間隔を決める。 主要市場のチェックアウトは数分おき、それ以外は1時間おきにします。
- デプロイやCDNの変更のたびに確認する。 オフィスからだけでなく、すべての市場から確認します。
- 毎週振り返る。 どの国で失敗が多いか、その理由は何かを確認します。
市場がダウンしてはいないものの遅い場合は、各国からWebサイトの速度をテストする方法のガイドで原因の探し方を解説しています。一部の地域に意図的に別のコンテンツが配信されていると疑われる場合は、複数拠点からSEOクローキングを検出する方法が同じ国別リクエストを使います。
まとめ
稼働状況はローカルです。監視ツールにとっては正常でも、ある国全体ではダウンしていることがあります。重要な市場ごとに収益ページを確認し、ステータス、最終URL、コンテンツ、ブロックの兆候を見て、2つ目のIPで失敗を確かめましょう。そうすれば、顧客から知らされる前に地域的な問題に気づけます。