Un domaine, six vérités différentes : ce que voient DNS, TLS, le navigateur, Googlebot, un crawler social et un scanner de sécurité

https://example.com/artykul

et vous obtenez six réponses différentes :

• le DNS affirme que le domaine mène à deux adresses IP,
• la couche TLS voit un certificat qui ne couvre pas www,
• votre navigateur affiche une page correcte et personnalisée,
• Googlebot indexe un titre plus ancien,
• LinkedIn affiche toujours l'image précédente,
• un scanner de sécurité attribue une mauvaise note en raison d'en-têtes manquants.

Aucune de ces observations n'est nécessairement fausse.

Chaque système observe un fragment différent de la pile, utilise un cache différent, envoie un jeu d'en-têtes différent, peut se connecter depuis un emplacement différent et n'exécute pas toujours JavaScript de la même manière. La « vérité d'un site web » n'est pas un document unique. C'est un ensemble d'états visibles par différents clients.

Conclusion principale : un domaine peut fonctionner correctement dans le navigateur de son propriétaire tout en ayant un DNS erroné pour une partie des résolveurs, un certificat incorrect sur un nœud CDN, un contenu non indexable pour Googlebot, un aperçu social obsolète et une faible protection des réponses HTTP.

Cet article ne suppose pas que chaque différence est une erreur. La personnalisation, les variantes linguistiques, le cache et l'infrastructure distribuée sont normaux. Le problème commence lorsque la différence est involontaire, invisible dans le monitoring ou empêche un client donné d'atteindre la bonne version.

La documentation et le comportement des systèmes décrits ont été vérifiés le 23 juillet 2026.

Six perspectives dans un seul tableau

Observateur	Ce qu'il vérifie réellement	Ce qu'il ne connaît généralement pas	Ce qui peut modifier le résultat
DNS	le nom d'hôte, les enregistrements, la délégation, le cache, DNSSEC	le contenu HTML, le chemin d'URL, le titre de la page	le résolveur, le TTL, la région, IPv4/IPv6
TLS	l'endpoint, SNI, le certificat, SAN, la chaîne, le protocole	le contenu de la page et son SEO	l'adresse IP, le nœud CDN, la configuration de l'hôte virtuel
Navigateur	DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, cache, DOM	l'intention de l'auteur et l'état des autres clients	l'utilisateur, le viewport, la locale, le storage, le service worker
Googlebot	la disponibilité, robots, HTTP, HTML, les ressources, le rendu, canonical, noindex	le contenu nécessitant une connexion ou une interaction	mobile-first, le cache de crawl, la file de rendu, le blocage des ressources
Crawler social	l'URL, la redirection, les métadonnées, l'image d'aperçu, le cache de la plateforme	l'expérience complète de l'application	la plateforme, le cache, Open Graph, la disponibilité de l'image
Scanner de sécurité	la surface publique et les tests dans son périmètre	toute la logique métier, le code et les rôles des utilisateurs	le type de scanner, l'autorisation, le chemin, la configuration du test

« Le même domaine » ne signifie pas toujours le même test

Avant de comparer les résultats, déterminez précisément la ressource examinée :

http://example.com
https://example.com
https://www.example.com
https://example.com/
https://example.com/artykul
https://example.com/artykul?utm_source=test

Ce ne sont pas des requêtes techniquement identiques. Elles peuvent :

• passer par des redirections différentes,
• utiliser des hôtes différents,
• aboutir à un hôte virtuel différent,
• avoir des règles de cache différentes,
• pointer vers des canonicals différents,
• renvoyer des en-têtes différents,
• générer des cartes sociales distinctes.

Un audit devrait toujours consigner l'URL complète, l'heure, l'emplacement du test, le user-agent, le statut final et la chaîne de redirections.

Vérité numéro 1 : le DNS voit le nom, pas la page

Le DNS traduit un nom d'hôte en données nécessaires pour localiser un service. Dans une requête typique pour :

https://example.com/artykul?id=42

Le DNS s'intéresse au nom :

example.com

Il n'analyse pas le chemin /artykul, les paramètres ?id=42, le titre HTML ni la balise canonical. Le DNS est un système hiérarchique de noms et d'enregistrements de ressources.

Que peut voir un diagnostic DNS ?

Entre autres :

example.com.      IN A      192.0.2.10
example.com.      IN AAAA   2001:db8::10
www.example.com.  IN CNAME  edge.example.net.
example.com.      IN CAA    0 issue "letsencrypt.org"

Il peut également vérifier :

• les serveurs NS,
• l'enregistrement SOA,
• le courrier MX,
• les données TXT,
• les enregistrements HTTPS et SVCB,
• les signatures DNSSEC.

Pourquoi deux personnes peuvent-elles obtenir des réponses différentes ?

La cause la plus simple est le cache. Un résolveur peut conserver une réponse jusqu'à l'expiration du TTL. Les réponses négatives, telles que NXDOMAIN, peuvent également être mises en cache.

Les différences peuvent aussi provenir de :

• résolveurs différents,
• versions de cache divergentes,
• une infrastructure géographique ou un équilibrage de charge DNS,
• réponses distinctes pour IPv4 et IPv6,
• une migration entre opérateurs,
• serveurs faisant autorité incohérents,
• une chaîne DNSSEC endommagée.

DNSSEC authentifie l'origine et l'intégrité des données DNS, mais ne chiffre pas la requête elle-même. Un enregistrement DS erroné peut faire qu'un résolveur validant renvoie SERVFAIL, tandis qu'un résolveur sans validation affichera toujours l'adresse.

Que ne confirme pas le DNS ?

Une réponse DNS correcte ne prouve pas que :

• le serveur fonctionne,
• le port 443 est ouvert,
• le certificat est correct,
• l'application renvoie un code 200,
• la page est indexable,
• les en-têtes de sécurité sont en place.

Le DNS indique où le client doit tenter de se connecter. Il ne dit pas ce qu'il trouvera une fois connecté.

Vérité numéro 2 : le TLS voit l'identité de l'endpoint, pas le contenu de l'article

Après avoir trouvé l'adresse, le client établit une connexion avec le serveur et négocie TLS. Dans un environnement hébergeant plusieurs domaines sur une seule adresse, l'extension SNI permet au client d'indiquer le nom du serveur pour lequel il souhaite établir la connexion.

La couche TLS peut révéler, entre autres :

• les versions de protocole prises en charge,
• l'algorithme négocié,
• le certificat du serveur,
• les noms SAN,
• l'autorité de certification,
• la date de validité,
• les certificats intermédiaires,
• le résultat de la négociation ALPN, par exemple HTTP/2.

TLS 1.3 est défini dans le RFC 8446 et protège le transport des données entre le client et le serveur.

Le certificat correspond au nom, pas au contenu

Le client vérifie si le nom d'hôte correspond à l'identité inscrite dans le certificat, principalement dans subjectAltName.

Un certificat pour :

example.com

ne couvre pas nécessairement :

www.example.com
api.example.com

Un wildcard :

*.example.com

ne couvre pas automatiquement le domaine principal example.com ni le nom à plusieurs niveaux www.eu.example.com.

Pourquoi un utilisateur voit-il un certificat correct et un autre non ?

Scénarios possibles :

• A et AAAA mènent à des serveurs différents,
• un nœud CDN n'a pas reçu le nouveau certificat,
• la configuration SNI a un hôte virtuel par défaut erroné,
• le trafic d'une région donnée aboutit à une autre infrastructure,
• l'origin a un certificat différent de celui de l'edge public,
• une partie des serveurs envoie une chaîne incomplète.

C'est toujours « le même domaine » du point de vue de l'utilisateur, mais pas le même endpoint du point de vue du réseau.

Que ne sait pas le TLS ?

Un TLS correct ne prouve pas que :

• la page est sûre au niveau applicatif,
• le JavaScript est exempt de XSS,
• l'utilisateur dispose des bonnes autorisations,
• le canonical est correct,
• Google indexera le contenu,
• la carte Open Graph a une bonne image.

Le cadenas vert signifie une connexion protégée vers un nom accepté par le client. Ce n'est pas un certificat de qualité de l'ensemble de l'application.

Vérité numéro 3 : le navigateur voit le résultat du fonctionnement de tout l'environnement

Le navigateur effectue bien plus de travail qu'un simple téléchargement du HTML. Une navigation typique comprend le DNS, la connexion de transport, TLS, la requête HTTP, l'analyse du HTML, le téléchargement du CSS et du JavaScript, la construction du DOM et du CSSOM, la mise en page et le rendu des pixels.

Ce que l'utilisateur voit à l'écran peut différer du code source de la réponse.

Le source HTML, le DOM et l'écran sont trois choses différentes

Le HTML du serveur

<div id="app"></div>
<script src="/app.js"></script>

Le DOM après l'exécution du JavaScript

<div id="app">
  <h1>Raport dla zalogowanego użytkownika</h1>
</div>

L'image à l'écran

L'apparence finale dépend encore du CSS, des polices, de la taille du viewport, de la disponibilité des images, des paramètres système et des interactions de l'utilisateur.

Qu'est-ce qui personnalise la « vérité du navigateur » ?

• les cookies et la session,
• localStorage et sessionStorage,
• la langue du navigateur,
• le fuseau horaire,
• la largeur de l'écran,
• prefers-color-scheme,
• prefers-reduced-motion,
• les autorisations,
• l'expérience A/B,
• les réponses de l'API,
• l'état de connexion.

Le navigateur dispose également d'un cache HTTP privé. Une réponse enregistrée comme fraîche peut être utilisée sans nouveau téléchargement, selon les directives de cache.

Un service worker peut intercepter les requêtes et renvoyer des données depuis son propre cache ou selon une stratégie hors ligne personnalisée. Cela explique les situations où un simple rafraîchissement affiche encore l'ancienne version, tandis que le mode privé présente la nouvelle.

Pourquoi « ça marche chez moi » est-il un test faible ?

Le propriétaire du site peut avoir :

• une session d'administrateur active,
• des données en cache,
• un ancien service worker,
• accès à une API non disponible publiquement,
• une langue et une région différentes,
• des extensions qui modifient la page,
• une bannière ou un onboarding déjà passés.

Un test de navigateur devrait couvrir un profil vierge, le mode privé, un appareil mobile, IPv4, IPv6 ainsi qu'un utilisateur non connecté.

Vérité numéro 4 : Googlebot voit une page destinée au crawl, au rendu et à l'indexation

Google décrit le traitement des pages JavaScript en trois phases principales :

1. le crawl,
2. le rendu,
3. l'indexation.

Googlebot récupère l'URL, analyse la réponse et peut transmettre la page au Web Rendering Service. Google utilise une version à jour de Chrome pour le rendu, mais le résultat ne survient pas nécessairement au même moment que la première récupération.

Googlebot n'est pas un utilisateur ordinaire

Google dispose d'un Googlebot Smartphone et d'un Googlebot Desktop, et pour la plupart des sites il indexe avant tout la version mobile. La majorité des requêtes proviennent donc du crawler mobile.

Googlebot :

• ne se connecte pas à votre compte,
• n'a pas vos cookies,
• ne voit pas les données privées,
• ne se comporte pas comme un utilisateur qui exécute tous les scénarios,
• peut télécharger les ressources séparément,
• est soumis à robots.txt et aux contrôles d'indexation.

Google indique clairement qu'il ne chargera pas le contenu principal nécessitant une interaction, comme un clic, la saisie de données ou le déplacement d'un élément.

Robots.txt n'est pas la même chose que noindex

robots.txt contrôle quelles URL le crawler peut récupérer. Google souligne que ce n'est pas un mécanisme garantissant le retrait d'une URL des résultats.

Pour que noindex fonctionne, le crawler doit pouvoir récupérer la page et voir la balise ou l'en-tête. Si l'URL est en même temps bloquée dans robots.txt, Google peut ne pas voir noindex.

<meta name="robots" content="noindex">

ou :

X-Robots-Tag: noindex

Canonical est une indication, pas un ordre inconditionnel

<link rel="canonical" href="https://example.com/artykul">

Google peut choisir une version canonical différente de celle indiquée par le propriétaire, car la canonicalisation prend en compte de nombreux signaux. Google qualifie l'indication canonical de suggestion, non de règle.

Que peut voir un utilisateur, mais pas Googlebot ?

• un contenu affiché seulement après un clic sur « Afficher plus »,
• des données accessibles uniquement après connexion,
• un élément dépendant d'une API indisponible,
• un contenu chargé par un script bloqué,
• une version desktop plus riche que la version mobile,
• un composant qui ne fonctionne qu'avec des données stockées dans le navigateur.

Que peut voir Googlebot, mais pas un utilisateur ordinaire ?

Par exemple, le serveur peut renvoyer une variante différente selon son user-agent. Une simple adaptation technique n'est pas automatiquement une infraction, mais le fait de montrer délibérément au moteur de recherche un contenu fondamentalement différent de celui vu par les utilisateurs peut être considéré comme du cloaking.

La pratique la plus sûre consiste à fournir le même contenu essentiel dans la réponse initiale ou dans un rendu qui ne nécessite pas d'interaction de l'utilisateur.

Vérité numéro 5 : le crawler social construit une carte, pas l'expérience complète de la page

Lorsqu'une URL est collée dans Facebook, LinkedIn, Slack ou une autre plateforme, le système peut récupérer la page et construire un aperçu. Il ne faut pas supposer que chaque plateforme exécute une application JavaScript exactement comme le navigateur complet de l'utilisateur.

La manière la plus portable de décrire une page consiste à placer les métadonnées dans le <head> du HTML initial.

Les propriétés Open Graph de base

La spécification Open Graph définit quatre propriétés requises :

<meta property="og:title" content="Tytuł artykułu">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/article.jpg">
<meta property="og:url" content="https://example.com/artykul">

En pratique, il est utile d'ajouter :

<meta property="og:description" content="Opis artykułu">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Opis grafiki">

Meta/Facebook

Meta recommande d'utiliser les balises Open Graph afin que le crawler puisse récupérer le titre, la description et l'image d'aperçu. La documentation de Meta décrit également la récupération et la mise en cache des métadonnées lors du partage d'une URL.

Cela signifie que changer l'image sur le serveur ne modifie pas nécessairement immédiatement une carte existante. La plateforme peut encore conserver un snapshot plus ancien.

LinkedIn

LinkedIn indique que les aperçus utilisent entre autres Open Graph ou oEmbed. Une ancienne image peut provenir du cache, et le Post Inspector permet de rafraîchir les données pour les nouveaux partages.

Les publications existantes peuvent conserver l'aperçu précédent même après le rafraîchissement de l'URL.

Slack

Slack documente l'unfurling classique comme un processus dans lequel, après détection d'un lien, le système crawle la page et crée un aperçu. Les applications Slack peuvent également fournir leurs propres unfurls programmables.

C'est une distinction importante : une carte dans Slack peut être le résultat standard d'un crawl ou un objet personnalisé renvoyé par une intégration.

Pourquoi les plateformes affichent-elles des images différentes ?

• une plateforme a un cache ancien,
• une autre ne peut pas récupérer l'image,
• l'URL de l'image redirige,
• l'image a un type MIME ou un code de statut indisponible,
• plusieurs og:image ont un ordre différent,
• la page a des balises distinctes pour différentes versions linguistiques,
• le bot reçoit une variante différente via le CDN ou le pare-feu,
• les métadonnées ne sont ajoutées que par JavaScript.

Le plus sûr est de placer les balises sociales de base directement dans le HTML du serveur et de fournir des adresses HTTPS absolues.

Vérité numéro 6 : le scanner de sécurité ne voit que le périmètre qu'il est capable d'examiner

« Scanner de sécurité » peut désigner des outils très différents :

• un analyseur d'en-têtes HTTP,
• un scanner de configuration TLS,
• un DAST qui effectue des requêtes et des tests de vulnérabilité,
• un crawler d'application,
• un SAST qui analyse le code,
• un scanner de dépendances,
• un outil de test d'infrastructure.

Dans cet article, nous parlons principalement d'un scanner externe qui examine une page accessible publiquement.

Que voit un scanner d'en-têtes ?

MDN HTTP Observatory évalue avant tout les en-têtes HTTP et certaines configurations de sécurité.

Il peut vérifier, entre autres :

• CSP,
• HSTS,
• la protection contre le framing,
• X-Content-Type-Options,
• les cookies,
• la redirection vers HTTPS,
• certaines politiques cross-origin.

Cela ne signifie pas qu'il a lu le code du backend, les rôles des utilisateurs, la configuration de la base de données ou tous les endpoints de l'API.

Une note en lettre n'est pas un verdict sur toute la sécurité

La documentation d'Observatory précise que le scoring vise à signaler des mécanismes de sécurité inexploités, et que le besoin d'un en-tête particulier peut dépendre du type de site.

Une page peut obtenir un bon score d'en-têtes tout en présentant encore :

• IDOR,
• une autorisation erronée,
• une SQL Injection,
• un panneau d'administration vulnérable,
• des clés exposées,
• une logique métier permettant des abus.

La situation inverse est également possible : un simple endpoint JSON recevra une note plus faible en raison de l'absence d'en-têtes typiques d'un document HTML, même si certains d'entre eux n'ont pas la même importance pour lui.

Le DAST a un autre périmètre, mais aussi des limites

OWASP décrit les web application vulnerability scanners comme des outils qui testent les applications de l'extérieur pour détecter des vulnérabilités et des erreurs de configuration.

ZAP avertit que le scan automatique a des limites. Sans authentification configurée, il ne découvrira pas les pages situées derrière une connexion, et le spider automatique n'exécutera pas tous les parcours réalistes de l'utilisateur.

Le résultat dépend de :

• du compte et du rôle utilisés dans le test,
• des URL disponibles,
• des formulaires et des données de test,
• du périmètre des domaines,
• du user-agent,
• des limites du WAF,
• de la durée du scan,
• du fait que le scanner exécute ou non JavaScript.

Le scanner dit : « dans ce périmètre, j'ai trouvé ou non certains signaux ». Il ne dit pas : « j'ai prouvé l'absence de toutes les vulnérabilités ».

Une URL, six rapports corrects

L'exemple suivant est hypothétique, mais techniquement réaliste.

Adresse examinée :

https://example.com/raport

DNS

A:    192.0.2.10
AAAA: 2001:db8::20
TTL:  300

Conclusion : le domaine a deux endpoints possibles.

TLS via IPv4

SAN: example.com, www.example.com
TLS: 1.3
Chain: poprawny

TLS via IPv6

SAN: old.example.net
TLS: 1.2
Chain: poprawny, ale zła nazwa

Conclusion : une partie des clients n'ouvriront pas la page.

Le navigateur du propriétaire

• utilise IPv4,
• a une session active,
• le service worker renvoie la version en cache,
• affiche le rapport à jour.

Conclusion de l'utilisateur : « tout fonctionne ».

Googlebot Smartphone

• arrive par IPv6,
• ne peut pas franchir le TLS,
• ne récupère pas la page.

Conclusion SEO : le nouveau contenu n'est pas crawlé.

LinkedIn

• a un aperçu enregistré une semaine plus tôt,
• affiche l'og:image précédent.

Conclusion marketing : la carte est obsolète.

Le scanner d'en-têtes

• teste IPv4,
• récupère le document sans connexion,
• détecte l'absence de CSP et de HSTS.

Conclusion de sécurité : le transport fonctionne, mais le durcissement des réponses est incomplet.

Tous les rapports décrivent un fragment différent du système.

Matrice des symptômes

Symptôme	Perspective la plus probable	Premier test
La page ne fonctionne que pour une partie des utilisateurs	DNS, IPv6 ou TLS	dig A/AAAA, test des deux adresses
Certificat d'un autre domaine	TLS/SNI	openssl s_client -servername
Après le déploiement, l'ancienne page reste visible	cache du navigateur ou service worker	profil vierge, DevTools Application
Google affiche un ancien titre	cache de crawl/index ou canonical différent	URL Inspection, vérification du rendered HTML
La page n'est pas dans l'index	robots, noindex, erreurs de crawl	robots.txt, Search Console
Facebook ou LinkedIn affiche une ancienne image	cache du crawler social	debugger ou Post Inspector
Le scanner signale l'absence de HSTS alors que le navigateur utilise HTTPS	en-têtes de réponse	curl -I pour l'URL finale
Le score du scanner est bon, mais une fonctionnalité a une erreur d'accès	logique applicative hors du périmètre du scanner	test d'autorisation et de rôles
Le contenu mobile est plus pauvre dans Google	mobile-first et contenu différent	comparaison du rendu mobile
noindex ne fonctionne pas	URL bloquée dans robots.txt	autoriser le crawl et refaire le test

Méthodologie d'un audit complet

1. Consignez la chaîne d'URL complète

curl -IL https://example.com/artykul

Faites attention à :

• les statuts,
• le changement d'hôte,
• le passage de HTTP à HTTPS,
• l'URL finale,
• le nombre de redirections.

2. Vérifiez le DNS depuis plusieurs résolveurs

dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com CAA
dig example.com A +dnssec

Comparez les réponses du résolveur de l'opérateur, d'un résolveur public et du serveur faisant autorité.

3. Vérifiez chaque endpoint TLS

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername example.com \
  -showcerts

Répétez pour IPv6 et les autres adresses renvoyées par le DNS.

4. Vérifiez la réponse HTTP sans état utilisateur

curl -sS -D headers.txt https://example.com/artykul -o page.html

Vérifiez :

• le code de statut,
• Content-Type,
• le cache,
• CSP,
• HSTS,
• X-Robots-Tag,
• le contenu du <head>.

5. Comparez le source HTML et le DOM

Dans le navigateur, vérifiez :

• View Source,
• le panneau Elements,
• Network,
• Application,
• le service worker actif,
• le cache storage,
• les cookies.

6. Vérifiez Googlebot

Utilisez l'outil URL Inspection dans Google Search Console et comparez :

• le HTML récupéré,
• le HTML rendu,
• la capture d'écran,
• les ressources qui n'ont pas pu être chargées,
• le canonical indiqué et celui choisi par Google,
• la possibilité d'indexation.

N'identifiez pas Googlebot uniquement par son user-agent. Google recommande une vérification par reverse DNS ou par les plages IP officielles.

7. Vérifiez la carte sociale

Analysez :

<title>
<meta name="description">
<meta property="og:title">
<meta property="og:description">
<meta property="og:image">
<meta property="og:url">

Ensuite, utilisez les outils de rafraîchissement de la plateforme concernée.

8. Lancez plusieurs classes de tests de sécurité

• l'analyse des en-têtes,
• le test TLS,
• un DAST sur un environnement dédié,
• des tests d'authentification et d'autorisation,
• l'analyse des dépendances,
• la revue du code et de la configuration.

Une seule évaluation ne remplace pas les autres.

Un <head> modèle accessible à différents clients

<!doctype html>
<html lang="pl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>Jedna domena, sześć różnych prawd</title>
  <meta
    name="description"
    content="Jak DNS, TLS, przeglądarka, Googlebot, social crawler i skaner bezpieczeństwa widzą tę samą domenę."
  >

  <link
    rel="canonical"
    href="https://example.com/jedna-domena-szesc-prawd"
  >

  <meta name="robots" content="index,follow">

  <meta
    property="og:title"
    content="Jedna domena, sześć różnych prawd"
  >
  <meta property="og:type" content="article">
  <meta
    property="og:url"
    content="https://example.com/jedna-domena-szesc-prawd"
  >
  <meta
    property="og:image"
    content="https://example.com/images/six-truths-1200x630.jpg"
  >
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta
    property="og:image:alt"
    content="Schemat sześciu warstw obserwujących jedną domenę"
  >
</head>

Les métadonnées les plus importantes se trouvent dans la réponse HTML, et non seulement après le lancement de l'application.

Checklist pratique des « six vérités »

DNS

• A et AAAA mènent à des endpoints actifs.
• Tous les serveurs faisant autorité renvoient des données cohérentes.
• Le TTL est compréhensible et surveillé.
• DNSSEC passe la validation.
• www et l'apex ont le comportement voulu.
• Le test a été réalisé depuis plusieurs résolveurs et emplacements.

TLS

• Chaque adresse IP renvoie le bon certificat.
• Le SAN couvre chaque hostname utilisé.
• La chaîne est complète.
• IPv4 et IPv6 ont la même qualité de configuration.
• SNI sélectionne le bon hôte virtuel.
• Le CDN et l'origin ont un TLS correct.

Navigateur

• La page fonctionne dans un profil vierge.
• La version non connectée a été vérifiée.
• Le source HTML contient le contenu clé et les métadonnées.
• Le DOM après rendu est conforme aux attentes.
• Le service worker et le cache ne masquent pas le déploiement.
• La version mobile contient l'intégralité du contenu.
• Les erreurs de l'API sont gérées.

Googlebot

• robots.txt autorise la récupération de la page et des ressources.
• noindex est conforme à l'intention.
• Le canonical est cohérent avec les redirections et le sitemap.
• Le contenu principal ne nécessite pas de clic.
• Le rendu mobile contient le même contenu essentiel.
• URL Inspection montre un HTML et une capture d'écran corrects.
• Les ressources CSS et JS sont accessibles.

Crawler social

• Les propriétés Open Graph de base se trouvent dans le HTML initial.
• og:url pointe vers la bonne URL permanente.
• og:image est une adresse HTTPS absolue.
• L'image renvoie 200 et un MIME correct.
• Les dimensions de l'image sont déclarées.
• Chaque version linguistique a les bonnes métadonnées.
• Le cache de la plateforme a été rafraîchi après la modification.

Sécurité

• Les en-têtes de la réponse finale ont été testés.
• Le test couvre plus que la page d'accueil.
• Les endpoints après connexion ont été vérifiés.
• Les rôles des utilisateurs ont été testés séparément.
• Les résultats automatiques ont été vérifiés par un humain.
• Le DAST a été complété par SAST et l'analyse des dépendances.
• Une note faible ou élevée a été interprétée en contexte.

Outils POLPROG utiles pour un tel audit

• Inspecteur DNS et SSL affiche les enregistrements du domaine et les données du certificat.
• Open Graph Preview vérifie les métadonnées et la carte de partage.
• Inspecteur des en-têtes de sécurité analyse le durcissement des réponses HTTP.
• Santé du site combine les signaux de SEO, de performance, d'accessibilité et de sécurité.
• FlowTrace visualise le parcours depuis un événement dans le navigateur en passant par le DNS, TLS, le CDN, le backend et le rendu.

Les mythes les plus courants

« Si le site fonctionne chez moi, il fonctionne partout »

Non. Votre résolveur, votre protocole IP, votre cache, vos cookies et votre nœud CDN peuvent être différents.

« Google voit exactement la même chose que Chrome »

Google effectue le rendu des pages avec Chrome, mais Googlebot a un état différent, un user-agent mobile-first, des phases de crawl et de rendu séparées et n'exécute pas le contenu nécessitant une interaction.

« Robots.txt supprime la page de Google »

Non. Robots.txt limite le crawl. Pour contrôler l'indexation, on utilise noindex, qui doit être visible pour le crawler.

« Canonical force Google à utiliser l'URL choisie »

Non. C'est un signal important, mais Google peut choisir un autre canonical.

« J'ai changé og:image, donc la carte est déjà nouvelle »

Pas toujours. La plateforme peut utiliser une version enregistrée et nécessiter une nouvelle récupération de l'URL.

« Un A+ au scanner signifie que l'application est sûre »

Non. Cela signifie un score élevé pour un ensemble de tests précis. Cela ne prouve ni une autorisation correcte, ni une logique métier, ni la sécurité du code.

Verdict

Un domaine n'a pas un seul « visage » technique.

• Le DNS voit le nom et les enregistrements.
• Le TLS voit l'endpoint et l'identité du certificat.
• Le navigateur voit l'expérience rendue d'un utilisateur donné.
• Googlebot voit une ressource accessible au crawl, au rendu et à l'indexation.
• le crawler social voit les métadonnées nécessaires à la construction d'une carte.
• le scanner de sécurité ne voit que la surface couverte par ses tests.

Un audit mature ne demande donc pas seulement : « Le site fonctionne-t-il ? »

Il demande :

Dla kogo?
Z jakiej lokalizacji?
Po IPv4 czy IPv6?
Z jakim stanem cache?
Z jakim user-agentem?
Przed czy po wykonaniu JavaScriptu?
Z logowaniem czy bez?
W jakim zakresie testu?

Ce sont seulement les réponses à ces questions qui forment une image cohérente du système.