Surveillance de site web et d'uptime depuis plusieurs pays avec des proxys

Un moniteur d’uptime qui interroge votre page d’accueil depuis un serveur vous apprend une seule chose : ce serveur arrive à joindre votre site. Il ne dit rien du client en Allemagne qui reçoit une page de challenge, ni du visiteur au Brésil dont l’edge CDN renvoie des erreurs. Si vous vendez ou vous positionnez dans plusieurs pays, vérifier la disponibilité et le contenu depuis ces pays fait partie du monitoring SEO, et cela détecte des problèmes qu’une sonde unique ne voit jamais.

Ce guide présente ce que les vérifications depuis un seul point ne voient pas, ce qu’il faut tester sur chaque marché, pourquoi l’IP source compte, et un petit script à exécuter selon un planning.

Ce que les checks d’uptime depuis un seul point ne voient pas

Une page de statut verte depuis une seule sonde peut masquer tout ceci :

• Pannes CDN régionales. Un CDN répond depuis l’edge le plus proche du visiteur. Un edge peut tomber ou servir des erreurs en cache pendant que les autres fonctionnent.
• Redirections géographiques cassées. Une règle qui envoie les visiteurs français vers /fr/ peut boucler, pointer vers une page qui n’existe plus ou envoyer un pays vers la mauvaise boutique.
• Blocages de pays entiers par vos propres règles de sécurité. Une règle de pare-feu ou anti-bots durcie après une attaque peut se mettre à défier tous les visiteurs d’une région.
• Problèmes de DNS et de routage. Le geo DNS peut envoyer un marché vers une origine en panne, et certains résolveurs locaux gardent d’anciens enregistrements longtemps après votre changement.
• Le mauvais contenu. La page se charge, mais avec la mauvaise devise, sans bannière de consentement, dans la mauvaise langue ou avec un bloc de prix vide.

Rien de tout cela n’apparaît comme « en panne » sur votre serveur de surveillance. Tout cela vous coûte des visites, des ventes et, si Googlebot le rencontre aussi, des positions.

Quoi vérifier sur chaque marché

Traitez chaque pays comme un site à part entière. À chaque vérification, enregistrez :

1. Le code de statut et l’URL finale après redirections. Un 200 sur la mauvaise URL est un échec.
2. Le temps de réponse, pour repérer un marché qui ralentit avant de tomber.
3. Un marqueur de contenu, par exemple une chaîne qui n’apparaît que sur la bonne version locale : le symbole de la devise, un numéro de téléphone local ou un titre traduit.
4. Les signes de blocage, comme le titre d’une page de challenge, un formulaire CAPTCHA ou un 403 de votre propre CDN.
5. L’edge qui a répondu, à partir d’en-têtes comme cf-ray, x-amz-cf-pop ou x-served-by, pour savoir où chercher quand une région tombe.

Commencez par les pages qui rapportent : l’accueil, une catégorie phare, une fiche produit et le début du checkout. Ajoutez la recherche et la connexion si vos utilisateurs en dépendent.

Pourquoi l’IP source compte

La plupart des services commerciaux d’uptime font tourner leurs sondes depuis des data centers dans quelques dizaines de villes. C’est suffisant pour savoir si le serveur est en ligne, mais ce n’est pas ainsi qu’arrivent vos clients. Les CDN et les règles anti-bots traitent souvent les adresses de data center différemment des connexions domestiques : une sonde peut passer sans encombre pendant que les vrais visiteurs sont mis au défi, ou être bloquée alors que les visiteurs n’ont aucun problème.

Les vérifications via des proxys résidentiels dans le pays cible comblent cet écart. La requête part d’une connexion domestique sur ce marché, donc le geo DNS, votre CDN et vos règles de sécurité la traitent comme un client local. Sur les grands marchés, vous pouvez descendre au niveau de la ville, par exemple en vérifiant depuis plusieurs régions des États-Unis plutôt que depuis une seule.

Gardez les rôles séparés : utilisez les vérifications résidentielles pour voir ce que reçoit chaque marché et si cela fonctionne, et votre moniteur de data center ou les données d’utilisateurs réels pour les temps de réponse exacts, car une requête passant par un proxy comporte un saut supplémentaire.

Un petit vérificateur multi-emplacements

Ce script vérifie une liste d’URL depuis plusieurs pays, suit les redirections et cherche un marqueur de contenu. Remplacez USERNAME et PASSWORD par vos identifiants de proxy.

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

Lancez-le avec cron ou le planificateur de votre CI, écrivez chaque ligne dans un journal ou une petite base de données, et alertez en cas d’échec. Deux habitudes rendent les résultats fiables :

• Confirmer avant d’alerter. Quand une vérification échoue, relancez-la une fois avec une nouvelle IP du même pays. N’alertez que si la seconde échoue aussi.
• Alerter sur des tendances, pas sur des lignes isolées. Trois échecs d’affilée dans un pays, c’est un incident. Un timeout par semaine, c’est du bruit.

Faire des vérifications une routine

1. Choisissez vos marchés à partir de Search Console et de vos analytics : les pays qui apportent du trafic et du chiffre d’affaires, plus ceux où vous voulez croître.
2. Fixez les intervalles selon la valeur. Toutes les quelques minutes pour le checkout sur vos marchés principaux, toutes les heures pour le reste.
3. Vérifiez après chaque déploiement et chaque changement de CDN, depuis tous les marchés, pas seulement depuis le bureau.
4. Faites un point chaque semaine sur les pays qui échouent le plus, et pourquoi.

Si un marché est en ligne mais lent, notre guide pour tester la vitesse d’un site depuis plusieurs pays explique comment trouver la cause. Si vous soupçonnez que certaines régions reçoivent volontairement un autre contenu, la méthode pour détecter le cloaking SEO depuis plusieurs emplacements repose sur les mêmes requêtes par pays.

En résumé

L’uptime est local. Un site peut être en ligne pour votre moniteur et en panne pour tout un pays. Vérifiez vos pages clés depuis chaque marché qui compte pour vous, regardez le statut, l’URL finale, le contenu et les signes de blocage, confirmez les échecs avec une deuxième IP, et vous apprendrez les problèmes régionaux avant que vos clients ne vous les signalent.