Actuellement s'occuper de 3 sites. J'ai changé l'un d'entre eux en HTTPS car c'est du commerce électronique, mais j'ai vu une énorme baisse de trafic organique depuis sa mise en œuvre. Passé d'environ 800 impressions à 400.
Une quelconque idée du pourquoi?
Très préoccupant car je m'attendais à ce qu'il s'améliore si quelque chose!
J'ai mis en place des redirections 301 pour mener à travers les anciennes pages vers http://www.example.com/product1
irait à https://www.example.com/product1
J'ai également configuré un compte webmaster distinct pour la version HTTPs, car notre intégration ne fonctionnait pas bien avec Google Merchant Center. Les données circulent correctement, sans savoir pourquoi/si cela causerait un conflit.
Très confus!
Je soutiens HTTPS sur mes sites Web depuis environ deux ans maintenant, mais je commence tout juste à expérimenter les versions HTTPS dans les moteurs de recherche. Pour mes sites, la version HTTP était toujours canonique (à l’aide de balises reliques canoniques link rel), mais je permettais aux utilisateurs de naviguer vers HTTP ou HTTPS.
Le 18 mars, j'ai changé cela pour l'un de mes sites. J'ai fait de HTTPS le canonique, mais j'autorise toujours les utilisateurs à utiliser HTTP. Jusqu'à présent, il semble y avoir une légère baisse.
Le site HTTP est sorti des résultats de la recherche au cours d'une semaine.
Le site HTTPS est apparu dans les résultats de la recherche, mais il ne génère pas autant d'impressions que le site HTTP.
N'oubliez pas que ces graphiques mesurent différentes périodes. Le site HTTP affichait en moyenne environ 225 impressions par semaine. Le site HTTPS génère environ 178 impressions par semaine.
Je prévois de continuer à surveiller ce site pendant quelques mois, mais pour le moment, j'hésite à déployer le protocole HTTPS pour les moteurs de recherche sur mes sites plus importants, car il semble que le fait de passer à Google intégralement peut poser problème.
Après l'avoir laissé fonctionner pendant un mois, le trafic est redevenu tel qu'il était avant la migration HTTPS:
En 2018, j'ai déplacé tous mes sites sur HTTPS. Mon plus grand site a été le dernier à être déplacé et j'ai trouvé un moyen de le faire sans perdre de trafic. Je suggérerais maintenant la procédure suivante pour passer de HTTP à HTTPS:
Donc, vous supportez tout le chiffrement Edge, vous avez un A + sur Qualys, c'est génial. Mais avez-vous vérifié dans vos analyses si XP utilisateurs, plus précisément à l'aide de IE ou de Chrome? Ce n’est un secret pour personne que XP est un chien qui meurt lentement lors de la connexion à des sites modernisés. Ce n’est également un secret pour personne que IE et Chrome sur XP (ou même l'ancienne version de Android navigateur) sont très limités à ce qu'ils peut faire avec SSL.
Voici quelques exemples de situations pouvant entraîner une réduction du trafic HTTPS:
Vous n'avez pas configuré GWT, les outils d'analyse et les autres services pour que le changement HTTPS soit correctement visualisé et qu'il ne soit pas abandonné. Faux positif, c'est l'erreur la plus courante.
Vous exécutez un serveur multi-locataire et comptez sur l'indicateur de nom de serveur (SNI) pour servir vos certificats. Les anciens navigateurs IE et Android ne se connecteront pas. Les robots pourraient ne pas comprendre ce que c'est.
En raison de tous les exploits de cet été, vous avez désactivé la prise en charge de SSL2/3 et optez uniquement pour TLS. Les navigateurs marginaux ou non mis à jour peuvent échouer.
Vous vouliez activer le secret de transfert pour obtenir des clés uniques lors des poignées de main. Heck le rendre "robuste" secret avant. Très vieux IE sur XP demandera "WTF est-ce que" et prob échouera.
Vous ne soutenez que les plus malins et vous avez évincé les anciens. Cloudflare en est un excellent exemple. Grâce à ECDHE, ni IE ni Chrome ne pourront se connecter sous XP. Dans ce cas, vous devez utiliser Firefox, qui, souvent, XP utilisateurs (personnes âgées, collèges indiens, centres d'appels d'entreprise) ne savent pas comment, ou ne sont pas autorisés à installer.
Vous avez un verrou jaune sur trop de pages. Cela rend les gens effrayés et ils s'enfuient sur un site réellement sécurisé (verrou vert). Vous pouvez essayer de modifier cela par la HSTS ci-dessous (cache l’actif au lieu de verrouiller brisé), mais vous risquez alors de perdre le site au lieu de simplement verrouiller.
Vous appliquez HSTS et XP utilisateurs pourraient ne pas être en mesure de l'utiliser. De plus, si HSTS bloque une source non sécurisée, elle la supprime complètement de la page. Il existe peut-être un élément critique bloqué (tel qu'un élément de contenu chargé avec script/AJAX) et vous ne pouvez même pas vous rendre compte qu'il a disparu.
Vous avez implémenté un CSP, mais il se peut que XP utilisateurs ne puissent pas l'utiliser ou que son erreur soit à l'origine d'un problème similaire au contenu bloqué par HSTS ci-dessus. Votre verrou a l’air vert; vous ne vous rendrez peut-être même pas compte que tous vos styles en ligne sont désactivés. Par conséquent, un script critique tel que l’ajout au panier est cassé ou bloqué.
Autres causes possibles:
Certains moteurs de recherche, annuaires, scanners, etc. ne peuvent pas analyser votre site avec une telle sécurité. Exemple, BingBot n’a commencé à comprendre SNI et [P] FS que récemment (janvier 2015). Il existe des TONNES de répertoires et de choses qui ne comprennent tout simplement pas comment analyser votre site SSL - exemple avec seobook.com. S'il y a des erreurs, ils peuvent supprimer votre lien retour, même si c'est leur faute pour ne pas mettre à jour leur schéma CURL merdique.
Vous avez eu une tonne de trafic de badbots, mais maintenant ils restent à l'écart pour la même raison: ils courent sous XP, utilisent le wrapper IE6, CURL merdique, incapable d'explorer, incapable de spammer. Ou peut-être sont-ils un analyseur d’exploit, ils voient HTTPS et ils partent immédiatement. Ne sous-estimez pas la quantité de trafic des badbots, son énorme.
Vous avez un certificat SSL dans les royaumes de coucher du soleil RSA128 et certains navigateurs affichent les avertissements que vous utilisez un cryptage faible. Le navigateur peut toujours leur permettre de se connecter, mais il activera l'indicateur "quelque chose qui ne va pas" dans la barre d'adresse. Essayez votre site avec tous les navigateurs les plus récents.
SSL est implémenté, mais médiocre, incohérent et les commutateurs sont trop lents. C'est une erreur de jugement assez commune: les gens pensent que vous pouvez simplement rediriger avec htaccess, définir un canonique et être prêt à partir. Qu'en est-il de tous vos actifs, tels que les menus dynamiques, les sources d'images, etc.? Qu'en est-il de vos générateurs d'aliments? Qu'en est-il de tout ce que votre plate-forme fait d'autre? Assurez-vous que votre plate-forme affiche au moins CHAQUE lien/src au format HTTPS ou une URL relative au moins ... sinon les bots seront confus et/ou doublés, ce qui provoquera une augmentation des poignées de main, des redirections et des décalages (en raison du nombre de pages ).
Trop de redirections enchaînées. Google déteste les redirections quand ils enchaînent 2-3. Donc, si vous utilisez 301 SSL, cela en mange un dès le départ. Si vous redirigez en mode WWW, c’est un autre. Si vous redirigez ensuite vers un nouveau contenu, c’est un autre. S'il y a quelque chose entre les deux, vous jouez avec le feu. Vérifiez la marque des 3 minutes de cette vidéo: https://www.youtube.com/watch?v=r1lVPrYoBkA
Google ment de manière flagrante sur le signal de classement de SSL et cela n’a en fait aucune incidence. Toutes mes cartes sont dans ce pari.
HTTPS n'envoie pas l'en-tête du référent. Ce trafic sera donc regroupé avec le trafic "direct".
J'ai changé trois de mes sites Web de http à https et tous ces créneaux sont complètement différents. Les redirections 301 et les outils Google pour les webmasters changent de site et même tous les liens internes qui ont été publiés en utilisant http dans l'URL ont été changés en https pendant la nuit.
Les nouvelles pages https ont commencé à apparaître dans serps en quelques jours et toutes les pages http ont été gérées en quelques mois et toutes les pages sont apparues avec https. Le trafic meurt pendant quelques semaines, puis se rétablit au bout d'un mois environ, mais même après une attente de 5 mois, le trafic ne parvint jamais à un niveau record au moment de la modification. Au total, une baisse de plus de 40% par rapport à la version http après 5 mois d'attente.
J'ai changé ce site en http et redirigé toutes les pages https vers http. Il a fallu environ un mois pour que le trafic atteigne les niveaux d'origine.
Leçon apprise: Google ment au sujet de l’amélioration du classement pour les pages SSL. Je ne vends rien et je n'ai pas de transactions financières ni d'informations personnelles qui changent de main sur l'un de mes sites Web, je n'ai donc pas besoin de SSL.
J'imagine (de loin) que les "robots" et les "spammeurs" n'aiment pas les https car ils drainent davantage de ressources, aussi rampent-ils et visitent-ils http.
Temps pour une mise à jour!
Le problème n'est pas résolu à 100%. Toutefois, après avoir mis à jour le plan du site et le fichier robots.txt pour garantir qu'ils pointaient tous vers HTTPS, le trafic représente maintenant environ 85% de ce qu'il était.
Il semble remonter progressivement et une des raisons de la baisse du trafic/des recherches est due à la demande saisonnière. Je pense donc que le problème est résolu pour le moment, bien que je ne sois certainement pas pressé de changer de site à l'avenir en HTTPS, là où ce n'est pas nécessaire ...
HTTPS n'améliore en rien le trafic. C'est un protocole sécurisé et rien d'autre. Pas différent, sinon, de HTTP. Si vous souhaitez que Google combine les résultats pour http et https, vous devez le faire dans les outils pour les webmasters ET, mieux, rediriger votre trafic http vers https. Ensuite, vos totaux seront additionnés au lieu d'être suivis séparément.
Vous voudrez peut-être tester si votre serveur Web est configuré correctement pour servir HTTPS. S'il n'est pas configuré correctement, il est possible que les navigateurs envoient une page d'avertissement aux utilisateurs et que ceux-ci décident de ne pas visiter votre site.
Des outils tels que celui de Qualys SSL Labs peuvent vous dire s'il y a un problème. Viser une note