www, apex, IPv6 : une version du site encore sale
Vous avez nettoyé https://www, pas le domaine nu, ou l’inverse. Parfois l’IPv6 sert encore l’ancien vhost. Google, Cloudflare et un client Orange n’empruntent pas le même chemin. Il faut tester les quatre faces, pas la barre d’adresse de votre PC.
Vous avez nettoyé www, pas le domaine nu, ou l'inverse. Testez les deux, et IPv6 si l'hébergeur en a. Google et Cloudflare peuvent viser l'un ou l'autre.
Quatre façons d’arriver sur « le même » site
Pour vous, le site c’est « le site ». Pour le réseau, c’est une combinaison : nom (www ou pas), schéma (http ou https), famille d’adresse (IPv4 ou IPv6). Chacune peut viser une IP différente, un certificat différent, un dossier différent. Un nettoyage qui ne touche qu’une combinaison laisse les autres en 200 avec l’ancien HTML.
C’est banal chez les hébergeurs français : le panel crée www, l’apex (@) est ajouté plus tard, l’AAAA est cochée « pour être moderne », la redirection https est une case sur www seulement. Personne n’est malintentionné. L’attaquant, ou simplement un vieux fichier, reste sur la face oubliée.
Les dossiers que nous reprenons après un « c’est propre » échouent souvent ici : inspection Search Console sur https://www. OK, client en 4G Free sur http://domaine.fr ou sur IPv6 encore redirigé vers un kit. Voir aussi HTTP encore ouvert — le port 80 est une face de plus.
- https://www.domaine.fr
- https://domaine.fr (apex / nu)
- http:// sur les deux (doit rediriger, pas servir un autre site)
- Même chose en forçant IPv6 si un AAAA existe
www vs apex : deux vhosts, deux dossiers
www est souvent un CNAME ou un A vers le même serveur. « Souvent » n’est pas « toujours ». Un A www vers Cloudflare et un A apex vers l’IP o2switch, c’est deux origines. Vous avez nettoyé celle que vous ouvrez le matin.
Même IP, deux document roots : plus rare mais réel (une « bascule www » avortée). Les dates de fichiers ne sont pas les mêmes. Wordfence sur un dossier ne lit pas l’autre. Traitez-les comme deux sous-domaines le temps de l’inventaire.
La redirection canonique doit être une seule : tout vers https://www ou tout vers https://apex, selon ce que Search Console et vos liens internes utilisent déjà. Une redirection circulaire, ou www → nu en HTTP et nu → www en HTTPS, produit des caches absurdes et des inspections contradictoires.
IPv6 : l’A propre, l’AAAA sale
Beaucoup de box françaises (Orange, Free) et de mobiles préfèrent IPv6 quand un AAAA existe. Votre PC de bureau en IPv4, derrière le Wi-Fi fibre « tout en 4 » ou un VPN, ne voit jamais cette face. « Chez moi ça marche » est alors littéralement vrai et inutile.
L’AAAA peut pointer vers une autre machine (ancien VPS, load balancer oublié, IPv6 du voisin de compte mal attribué). Plus souvent, elle pointe vers le même serveur mais un vhost IPv6 par défaut différent — page parking, autre site, ancien WordPress. Le certificat peut même être un autre Let’s Encrypt, ce qui n’aide pas le diagnostic visuel.
S’il n’y a pas d’AAAA, ignorez IPv6. N’en ajoutez pas « pour être complet » pendant l’incident. S’il y en a un, il fait partie du périmètre, comme un hostname. Un `*` AAAA est la version IPv6 du wildcard.
Cloudflare, CDN et « ça dépend du PoP »
Un cache peut servir l’ancien HTML sur un point de présence et le nouveau sur un autre. Purge globale après nettoyage, pas seulement « cache navigateur ». Les règles de page qui ne matchent que www laissent l’apex en cache sale.
Orange et certains FAI passent par des résolveurs et des chemins qui aiment l’AAAA. Un client à Lyon et vous à Paris n’avez pas le même PoP. D’où l’intérêt de l’inspection Google et d’un test mobile, pas d’un seul screenshot desktop.
Si Cloudflare est en proxy (nuage orange), les A/AAAA publics sont ceux de Cloudflare. L’origine (o2switch, OVH) peut encore avoir un vhost IPv6 sale que Cloudflare n’atteint que sur certains réglages. Vérifiez l’origine en direct (hostname de secours de l’hébergeur) une fois, pour savoir où nettoyer.
Search Console et Safe Browsing voient une origine
Une propriété préfixe https://www. n’inspecte pas https://domaine.fr. L’alerte site trompeur peut citer l’apex. Vous déposez un réexamen sur www, Google relit l’apex, refus. Propriété domaine, ou second préfixe, le temps de l’incident.
Safe Browsing n’est pas tenu de distinguer vos vhosts internes. Un kit sur l’apex IPv6 noircit souvent le nom. Toutes les faces doivent être mortes ou propres avant le réexamen. Les URL de kit : 410, pas de redirect home.
Ads et Lighthouse « live » ont le même biais que vous si vous lancez le test depuis IPv4. Ne les prenez pas pour un feu vert unique.
Corriger : unifier, puis seulement le contenu
Faites pointer www et l’apex (A et AAAA) vers les mêmes cibles utiles, ou retirez l’AAAA si vous ne le maîtrisez pas. Un seul document root. Une seule redirection vers l’origine canonique. Puis nettoyez ce root comme d’habitude.
Si l’AAAA vise une machine que vous ne contrôlez plus : retirez l’enregistrement. C’est plus sûr qu’un « on va demander le mot de passe du vieux VPS ». Même logique qu’un CNAME staging vers une agence disparue.
Certificats : www et apex ont besoin d’être dans le SAN, ou deux certs, sinon le navigateur crie ERR_CERT pendant que Safe Browsing crie autre chose. Ne les confondez pas — certificat vs site trompeur.
Après : une origine canonique, les autres ferment
Documentez : « canonique = https://www.domaine.fr ; l’apex 301 ; pas d’AAAA » (exemple). Le prochain prestataire n’a pas à deviner. Relisez la zone après chaque « optimisation » CDN.
Surveillez trente jours les deux hôtes dans `site:` et deux inspections. Une face qui redevient 200 avec un HTML différent est une réinfection ou un cache, pas un mystère.
Si A et AAAA, www et nu, plus un CDN, plus un hébergeur, c’est déjà trop pour un dimanche soir, créez un espace. On cartographie les origines avant de toucher au thème.
Comment tester sans se raconter d’histoires
Navigation privée, téléphone en 4G (pas le Wi-Fi du bureau), clic depuis un résultat Google. Puis, si vous savez lire un DNS : comparer A et AAAA pour www et pour l’apex. L’inspection d’URL Search Console montre ce que Googlebot a choisi — souvent IPv6 s’il est annoncé.
Un écart HTML entre www et l’apex, ou entre l’inspection et votre écran, est une preuve. Gardez-le. Purgez le CDN sur les deux hôtes. Retestez http:// explicitement : tapez-le, ne vous fiez pas au navigateur qui « améliore » en https.
Ne construisez pas un labo d’attaque. Vous n’avez pas besoin de forger des paquets. Vous avez besoin de quatre URL et, si AAAA existe, d’un réseau qui l’utilise (le mobile suffit souvent). Le guide premiers gestes : constater avant de conclure.