Lorsqu’un site répond à la fois sur HTTP et HTTPS, Yandex fait généralement de l’adresse HTTPS l’adresse principale et l’affiche dans les résultats. Cette page traite de l’exigence inverse : conserver HTTP comme adresse de classement.
Les deux méthodes
- Bloquer la version HTTPS de l’indexation avec
Disallowdans sonrobots.txt. - Rediriger les pages HTTPS vers leurs équivalents HTTP, en veillant à ce que les deux versions restent accessibles au robot.
À lire avant de le faire
Yandex expose clairement sa position : HTTPS réduit considérablement le risque d’interception des identifiants, des mots de passe et des numéros de carte, et empêche la substitution de contenu — y compris la publicité injectée dans les pages en transit. C’est le protocole recommandé, et cette page existe pour les cas où une contrainte technique le rend temporairement impossible, et non comme une alternative équivalente.
Les cas légitimes
Un certificat auquel les appareils du public cible ne font pas confiance, du matériel ou des clients intégrés incapables de négocier TLS, ou une application historique où le contenu mixte ne peut pas être résolu avant une date limite. Dans chacun de ces cas, maintenir HTTP comme principal est une solution temporaire délibérée assortie d’une date.
Le cas illégitime
Choisir HTTP parce qu’une migration HTTPS semblait coûter des positions. Cette lecture est presque toujours fausse : ce qui a changé, c’est l’adresse principale, et la migration était incomplète — les liens internes étaient toujours en HTTP, les redirections pointaient vers la page d’accueil, les fichiers robots.txt ne correspondaient pas. Rétablir le protocole relance le même changement de miroir dans la direction opposée et coûte de nouveau les mêmes semaines, sans rien réparer.
Si vous conservez HTTP comme principal
Soyez cohérent : une seule méthode, appliquée partout. Un site qui bloque HTTPS dans robots.txt tout en redirigeant HTTP vers HTTPS quelque part dans sa configuration serveur se retrouve sans aucune version indexable accessible, ce qui est un résultat nettement pire que l’un ou l’autre choix.
Comment nous l'appliquons
We have only twice recommended keeping HTTP as the primary address, both times because of client hardware that could not negotiate modern TLS, and both times with a fixed end date. When a client asks for this after an HTTPS migration appeared to hurt them, we audit the migration first — every case so far has been an incomplete move rather than a protocol problem, and reverting would have cost another month for nothing.
Services associés