Dois-je refuser l'exploration de HTTP après avoir migré vers HTTPS?
Je migre mon site Web bien indexé de HTTP à HTTPS uniquement.
Étapes prévues:
- Toutes les pages HTML canoniques à devenir HTTPS maintenant
- Toutes les pages HTTP seront redirigées vers HTTPS avec la même URL.
- Tous les sitemaps auront des URL HTTPS
- Tous les liens sur les pages HTML seront HTTPS
Problème 1:
Actuellement, robots.txt au niveau HTTPS, interdit tout, car nous ne voulions pas que le robot analyse les pages HTTPS.
Quelle devrait être notre approche maintenant: Autoriser https maintenant pour tous les liens est évident.
Mais qu’en est-il de l’autorisation/du refus de HTTP (comme s’il n’explorait pas HTTP, comment savoir si rien de nouveau ne s’est produit, seul HTTP a été migré vers HTTPS)? Bien que 301 l'indique, il ne le fera que lorsque le robot d'exploration ouvre la même page avec HTTP.
Problème 2:
Si, dans le plan du site, j'ajoute tous les liens HTTPS, la même question que ci-dessus m'est posée. Crawler commencera à explorer les liens https et à les indexer. Mais nous voulons qu'il sache qu'il s'agit de la même version HTTP et que nous transmettons le classement.
Donc, idéalement, pendant un certain temps, jusqu'à ce que tous nos liens soient indexés avec HTTPS, devrions-nous avoir à la fois HTTP et HTTPS dans les sitemaps?
Selon la compréhension actuelle, voici le plan:
Si Google arrête d'explorer http, il ne passera pas le classement. Donc, je prévois d’autoriser http et https selon les robots.
Mais je ne sais pas comment ils vont l'explorer car sur notre serveur Web, nous redirigeons tous les liens http vers https. Donc, même s’il explore la racine de mon site, dites http://www.example.com , il sera éventuellement redirigé vers https://www.example.com où il le fera. trouver tous les liens https et suivra donc.
Essayez peut-être également d’explorer les liens déjà indexés (tous les liens http) et constaterez qu’ils sont redirigés, mais cela dépend du comportement et de la fréquence du robot. Dans l'intervalle de temps entre la compréhension des robots d'exploration de la version 301 et de la version https, cette analyse créera également un problème de contenu en double et affectera donc notre classement.
Si vous redressez 301 le trafic HTTP vers HTTPS, vous avez déjà franchi la plus grande étape. Tous les liens vers des pages HTTP seront redirigés vers la page HTTPS appropriée, et les moteurs de recherche suivront de la même manière que les utilisateurs réels. Tant que votre sitemap fait référence à la version HTTPS, tout devrait bien se passer.
En ce qui concerne les bits plus niggly, je suggère également de vérifier les éléments suivants:
Plan du site
Vous avez mentionné la mise à jour, mais certaines personnes utilisent des plugins pour le régénérer régulièrement. Assurez-vous que le script que vous utilisez ne remplace pas accidentellement HTTPS par HTTP par un processus automatisé.
Canonicals
Si vous avez des liens canoniques en place sur votre site, assurez-vous qu'ils pointent vers HTTPS. Si vous utilisez un plugin WordPress, il se peut que la nouvelle "Adresse du site" ne soit pas automatiquement sélectionnée. Vérifiez donc plus précisément vos plugins SEO. Si vous avez un site personnalisé, vérifiez simplement le protocole que vous incluez.
Robots.txt
La version HTTP de votre robots.txt ne sera même plus lisible si elle est redirigée vers la version HTTPS. Assurez-vous simplement que la version que vous utilisez sur HTTPS ne bloque pas les pages que vous souhaitez explorer.
Liens internes
Les liens vers des pages de votre site doivent toujours utiliser HTTPS maintenant. Il peut être facile de vérifier les menus globaux, mais vérifier les liens de page devient plus difficile. phpMyAdmin a une facilité de recherche décente pour en trouver, donc si vous avez cette recherche de http://www.example.com et la mise à jour à partir de là. Les autres outils de base de données doivent avoir des installations similaires. WordPress a des plugins qui vous permettent même de faire des recherches/remplacements sur place.
Liens externes
Vous ne pourrez pas contrôler tous les liens externes entrant dans votre site Web. (oh comme c'est gentil) mais vous avez probablement le contrôle de plus que vous ne le réalisez. Mettez à jour tous vos profils de réseaux sociaux (Facebook/Twitter/& c.) Pour renvoyer à la version HTTPS de votre site Web. Vérifiez également les liens des signatures de courriers électroniques, juste pour couvrir vos bases.
HSTS
HTTP Strict Transport Security est un moyen d’informer les navigateurs de uniquement utiliser HTTPS lors du retour sur votre site Web. Même si un utilisateur clique sur un lien HTTP, s'il connaît votre stratégie HSTS, son navigateur demandera automatiquement la version HTTPS sans avoir à attendre une redirection. Vous pouvez même soumettre votre site Web à une "liste préchargée STS" afin que les navigateurs soient préchargés avec votre domaine et demandent automatiquement des ressources via HTTPS par défaut. Ajoutez un en-tête Strict-Transport-Security: max-age=10886400; includeSubDomains; preload et soumettez-le à https://hstspreload.appspot.com/ ou lisez https://www.owasp.org/index.php/HTTP_Strict_Transport_Security pour plus d'informations.
Issue 1
Non, il n'y a aucun avantage à bloquer l'analyse de HTTP, donc aucune raison de le faire. De plus, et ceci est un peu spéculatif, cela peut interférer avec le flux de valeur des liens externes faisant référence à vos anciennes versions HTTP.
Issue 2
Encore une fois, aucun avantage en cela. Les redirections 301 feront en sorte de transmettre de la valeur aux nouvelles URL.
Non. Effectuez simplement un décalage: http à https. Je ne connais pas votre modèle commercial, mais en fonction de l'autorité de votre site Web, le classement de Google entraînera une perturbation considérable. Un équilibre sera établi avec Google dans les 4 semaines, à condition que vous ayez repris les anciennes pages aux nouvelles. La réponse simple est de ne pas bloquer un lien intermédiaire de http.