Multi-Location Website & Uptime Monitoring with Proxies

An uptime monitor that pings your homepage from one server tells you one thing: that server can reach your site. It says nothing about the customer in Germany who gets a challenge page, or the visitor in Brazil whose CDN edge is returning errors. If you sell or rank in several countries, checking availability and content from those countries is part of SEO monitoring, and it catches problems a single probe never sees.

This guide covers what single-location checks miss, what to test in each market, why the source IP matters, and a small script you can run on a schedule.

What single-location uptime checks miss

A green status page from one probe can hide all of these:

• Regional CDN failures. A CDN answers from the edge nearest the visitor. One edge can fail or serve stale errors while the others are fine.
• Geo redirects that break. A rule that sends French visitors to /fr/ can loop, point to a page that no longer exists, or send a country to the wrong store.
• Country-wide blocks by your own security rules. A firewall or bot rule tightened after an attack can start challenging every visitor from a region.
• DNS and routing problems. Geo DNS can send one market to an origin that is down, and some local resolvers keep old records long after you changed them.
• The wrong content. The page loads, but with the wrong currency, a missing consent banner, the wrong language or an empty price block.

None of these show up as “down” from your monitoring server. All of them cost you visitors, sales and, if Googlebot meets them too, rankings.

What to check in each market

Treat each country as its own site. For every check, record:

1. Status code and final URL after redirects. A 200 at the wrong URL is a failure.
2. Response time, to spot a market that is slow before it is down.
3. A content marker, such as a string that only appears on the correct local version: the currency symbol, a local phone number or a translated heading.
4. Signs of a block, such as a challenge page title, a CAPTCHA form or a 403 from your own CDN.
5. Which edge answered, from headers like cf-ray, x-amz-cf-pop or x-served-by, so you know where to look when a region fails.

Start with the pages that make money: homepage, a top category, a product page and the start of checkout. Add search and login if your users depend on them.

Why the source IP matters

Most commercial uptime services run their probes from data centers in a few dozen cities. That is good for “is the server up”, but it is not how your customers arrive. CDNs and bot rules often treat data center addresses differently from home connections, so a probe can be waved through while real visitors are challenged, or blocked while visitors are fine.

Checks through residential proxies in the target country close that gap. The request comes from a home connection in that market, so geo DNS, your CDN and your security rules handle it the way they handle a customer there. You can also go down to a city when a market is large, for example checking from several regions of the United States rather than one.

Keep the roles apart: use residential checks to see what each market is served and whether it works, and use your data center monitor or real-user data for exact response times, since a proxied request has an extra hop.

A small multi-location checker

This script checks a list of URLs from several countries, follows redirects and looks for a content marker. Replace USERNAME and PASSWORD with your proxy credentials.

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))

Run it from cron or your CI scheduler, write each line to a log or a small database, and alert on failures. Two habits make the results trustworthy:

• Confirm before alerting. When a check fails, repeat it once with a new IP from the same country. Alert only if the second check fails too.
• Alert on patterns, not single lines. Three failures in a row in one country is an incident. One timeout in a week is noise.

Turning checks into a routine

1. Pick your markets from Search Console and analytics: the countries that bring traffic and revenue, plus the ones you are growing.
2. Set intervals by value. Every few minutes for checkout in your top markets, hourly for the rest.
3. Check after every deploy and CDN change, from every market, not only from the office.
4. Review weekly which countries fail most, and why.

If a market is up but slow, our guide to testing website speed from different countries covers how to find the cause. If you suspect that some regions are served different content on purpose, the method in detecting SEO cloaking from multiple locations uses the same per-country requests.

The bottom line

Uptime is local. A site can be up for your monitor and down for a whole country. Check your money pages from each market you care about, look at status, final URL, content and block signs, confirm failures from a second IP, and you will hear about regional problems before your customers tell you.