Accueil > WordPress > Optimisation technique de WordPress > WordPress et HTTPS : le guide

WordPress et HTTPS : le guide

Google le rabâche depuis des mois, vous devez migrer votre site en HTTPS pour le référencement naturel et pour avoir un site sécurisé pour vos utilisateurs. Mais doit-on réellement le faire ? Et comment mettre efficacement en place cette sécurité sur WordPress ?

Découvrez le guide complet pour activer le HTTPS sur WordPress, avec en bonus à la fin la check-list complète WordPress et HTTPS !

L'HTTPS, c'est quoi ?

Commençons par quelques explications indispensables.

Définition de l'HTTPS

L'HTTPS ("HyperText Transfert Protocol Secure") est un moyen qui vise à sécuriser la connexion à un site Internet ou à une application. Si l'on simplifie le concept, on peut simplement dire qu'il s'agit d'un protocole qui chiffre les données qui transitent entre votre ordinateur et le site Internet. En d'autres termes, sur un site HTTP un pirate pourrait intercepter vos données, mais pas sur un site en HTTPS.

HTTP VS HTTPS
xx Une explication simplifiée des différences entre HTTP et HTTPS

Cela implique une chose simple : en soi, un site HTTPS n'est pas plus sécurisé qu'un autre. C'est surtout la connexion et les transferts de données qui le seront. Par exemple le stockage de vos données sur le site n'est pas plus sécurisé en HTTPS qu'en HTTP. Par contre, vous réduisez drastiquement la possibilité d'intercepter vos données en transit, c'est à dire ce que vous envoyez et recevez de n'importe quel serveur web.

Le SSL, c'est quoi ?

Pour faire de l'HTTPS, il faut un certificat SSL : c'est ce protocole de sécurité qui permet au HTTP de devenir une connexion sécurisée HTTPS. Pour cela, il faut mettre en place ce fameux certificat SSL sur son serveur afin de pouvoir activer la connexion sécurisée (attention, cela ne migre pas automatiquement le site en HTTPS, cela rend juste possible son utilisation). Une fois le certificat installé, en tapant l'URL de votre site avec HTTPS, vous devriez voir un cadenas apparaître prouvant votre connexion sécurisée :

Site sécurisé avec cadenas
Si le certificat est valide, on voit le cadenas apparaître

Il existe plusieurs types de certificats SSL plus ou moins élaborés :

  • les certificats SSL avec validation simple du domaine (certificat SSL DV). C'est souvent ceux que l'on utilise sur nos sites, et qui sont la plupart du temps largement suffisants (le plus connu est Let's Encrypt qui vous permet d'en générer facilement) ;
  • les certificats SSL avec validation de l'organisme (certificat SSL OV), souvent payants et pour lesquels ont doit prouver l'existence de l'entreprise ou de l'organisation ;
  • les certificats SSL à validation étendue (certificat SSL EV) : ils sont payants mais permettent la meilleure protection. Cela permet d'ailleurs aussi d'afficher le nom du site à côté du cadenas dans le navigateur.

Les certificats simples DV ont le vent en poupe, notamment grâce à Let's Encrypt qui permet depuis quelques années de pouvoir générer soi-même (et gratuitement) un certificat SSL DV. C'est d'ailleurs pour cette raison que désormais la plupart des hébergeurs proposent désormais la mise en place de certificats gratuits.

Certificat SSL Let's Encrypt
Les certificats SSL gratuits de Let's Encrypt

Pourquoi passer en WordPress en HTTPS ?

HTTPS et SEO

Si l'on en croit Google, le fait d'avoir un site en HTTPS serait un critère de positionnement (et ce depuis 2014 où ce signal aurait affecté environ 1% des requêtes des utilisateurs comme indiqué ici : HTTPS as a ranking signal). Ils ont ensuite réitéré à de nombreuses reprises cette affirmation. Cependant, entre les annonces de Google et la réalité, il y a souvent un gouffre. Par exemple, on nous avait annoncé un Armageddon mobile en 2017, et l'impact avait été insignifiant. A l'inverse, rien n'avait annoncé les changements de Google Panda et Google Penguin qui avaient pénalisés fortement les sites ayant des contenus "pauvres" et les sites ayant abusé des backlinks.

Selon nos tests et ceux de nombreux confrères, le HTTPS n'améliore pas le référencement naturel ! Pire encore, une mauvaise migration de votre site vers l'HTTPS peut entraîner une chute plus ou moins importante de votre référencement.

C'est d'ailleurs pour cette raison qu'on parle peu de l'HTTPS dans nos prestations d'audits SEO. Il faut donc chercher ailleurs les vraies raisons qui doivent vous pousser à basculer vers un site ayant une connexion sécurisée.

HTTPS et sécurité

Sur ce point-là, c'est simple : basculer en HTTPS améliore la sécurité lorsque l'on navigue sur un site. Même si ce n'est pas cette modification qui le protégera entièrement, c'est un plus à ne pas négliger pour vous et les internautes. Sur ce point, je ne vous apprends rien...

HTTPS et expérience utilisateur

Le ressenti des visiteurs est la vraie raison qui doit vous obliger à basculer en HTTPS. Et ceci pour différentes raisons :

  • La première est que les internautes ont de plus en plus l'habitude de naviguer et de voir des sites en HTTPS. Il est donc logique de leur proposer des sites utilisant uniquement ce protocole.
  • La seconde raison est bien plus problématique : depuis plusieurs mois déjà, les navigateurs récents comme Chrome ou Firefox affichent des messages indiquant que les sites en HTTP ne sont pas sécurisés.
Site non sécurisé en HTTP
Un exemple de site non sécurisé encore en HTTP

Vous imaginez facilement l'impact que cela peut avoir sur le ressenti de l'utilisateur, surtout pour des sites e-commerce. Malgré cela, un grand nombre de sites sont encore en HTTP. Pourtant, ce changement était annoncé depuis très longtemps, comme ici en Juin 2018 :

Attention cependant, la mise en place de l'HTTPS va dégrader l'expérience utilisateur sur un autre aspect: le temps de chargement. Le serveur doit en effet chiffrer et déchiffrer les données lorsque l'internaute se connecte, diminuant ainsi (très légèrement) la vitesse des pages

Remarque : on ne dit pas crypter mais bien chiffrer.

Les règles d'OR de l'HTTPS

Un site HTTPS doit respecter certaines règles pour l'être entièrement. Attention, gardez bien en tête que la validation HTTPS ne se fait pas au niveau d'un site en entier, mais bien URL par URL. Par exemple, la page d'accueil peut être considérée comme valide, mais pas certains articles de votre site WordPress.

Pour qu'un site soit considéré 100% HTTPS, il faudra plusieurs choses :

  • un certificat SSL valide et correctement configuré ;
  • une redirection de toutes les URL HTTP vers leur équivalent HTTPS ;
  • éviter de dépendre d'un plugin HTTPS pour WordPress ;
  • aucune ressource appelée en HTTP sur vos pages (images, polices d'écritures, scripts, fichiers CSS, etc.).

La question qui suit est simple : comment passer en HTTPS WordPress ? Suivez le guide !

WordPress et HTTPS, le guide de migration

Remarques préalables

Avant de vous lancer, gardez bien en tête qu'une migration ratée peut être mauvaise pour le référencement naturel (perte de trafic et de positionnement), ou encore être inefficace (pages pas entièrement sécurisées). Faites donc attention quand vous faites ce type de manipulations.

Ayez aussi en tête que cela peut avoir des effets de bords sur d'autres éléments. Une migration HTTPS peut ainsi très bien se dérouler, tout en empêchant de faire fonctionner d'autres outils basés sur votre WordPress ou sur votre serveur (par exemple un CRM ou encore une API qui se connecterait à votre site).

Dernier point : la méthode donnée ici est plus complexe que celle donnée sur d'autres sites, mais elle sera la plus performante et efficace pour l'utilisateur et le référencement naturel. En cas de doute sur la migration en HTTPS de votre WordPress, n’hésitez pas à nous contacter pour que l'on vous accompagne.

Contactez-nous !

Faire une sauvegarde complète de WordPress

Faire une sauvegarde complète de son site est ma toute première étape. Cela inclut :

  • tous les fichiers présents sur votre serveur. Il faudra les télécharger via un logiciel en SFTP ou FTP (ou encore en SSH). Vous aurez ainsi à télécharger :
    • les fichiers de WordPress (wp-admin, wp-includes, etc.) ;
    • vos fichiers (thème, extensions, mu-plugins, uploads, languages, etc.).
  • votre base de données, via PHPMyAdmin ou un outil équivalent.

Une fois cette sauvegarde réalisée, vérifiez qu'elle est complète et conservez-là précieusement au cas où.

Scanner son site avec un crawler

Ensuite, il faut crawler son site. L'objectif est de pouvoir lister toutes les pages et ressources du site avant sa migration. Crawler signifie utiliser un logiciel qui va parcourir l'intégralité du site actuel, un peu comme le ferait Google. Une fois en HTTPS, cette liste nous permettra de vérifier que l'on a bien redirigé correctement l'internaute et que plus aucune URL en HTTP n'existe.

Pour faire cela, vous devrez utiliser un logiciel de crawl comme :

  • Screaming Frog (payant mais excellent)
  • Xenu link Sleuth (gratuit sur PC)
  • Integrity (gratuit sur MAC)

Si vous avez la chance d'utiliser Screaming Frog, je vous conseille même de le paramétrer pour crawler les éventuels fichiers sitemaps de votre site ainsi que de crawler toute URL qui pourrait remonter dans Analytics. Ce paramétrage permet en effet de pouvoir lister les éventuelles URL orphelines (c'est à dire des pages qui existent mais qu'on ne trouve plus en naviguant de manière traditionnelle).

Lancez l'analyse du site que vous voulez migrer. Une fois le crawl terminé, sauvegardez-le sur votre ordinateur et exportez la liste complète de toutes les URL internes trouvées (contenus textes, images, PDF, fichiers CSS, etc.). Par exemple, voici la démarche à suivre avec le logiciel Screaming Frog. Vous aurez :

  • un fichier *.seospider (la sauvegarde du crawl si vous avez besoin de le rouvrir) ;
  • un fichier *.txt qui contient toutes vos URL.

Pour obtenir facilement le fichier *.txt, rien de plus simple :

  1. rendez-vous dans l'onglet "Internal" ;
  2. sélectionnez dans le tableau toute la première colonne ;
  3. ouvrez un fichier texte vide (vive le bloc-notes) ;
  4. collez le texte copié ;
  5. sauvegardez votre fichier.

On le réutilisera après la migration pour s'assurer que tout fonctionne correctement.

Obtenir un certificat SSL

Certificat gratuit ou payant ?

Honnêtement, la solution la plus simple (et qui est adaptée à un très grand nombre de sites) est de choisir un certificat SSL gratuit. Opter pour un certificat payant ne sera utile que sur des sites réellement sensibles, comme notamment les gros sites e-commerce, un site de banque ou encore des sites où l'on enregistre des données sensibles.

Dans l'interface de votre hébergeur, cherchez donc l'option pour activer le HTTPS, comme ici sur Infomaniak.

Certificat SSL d'un hébergeur
Les hébergeurs proposent facilement des certificats SSL

Sur des serveurs dédiés, il faudra demander à la personne en charge de l'infogérance d’installer ce certificat.

La durée de vie des certificats SSL

Attention, vérifiez bien que le certificat SSL choisi sera renouvelé automatiquement. Si ce n'est pas le cas, pensez à mettre en place un rappel pour ne pas oublier. Cela vous évitera d'avoir un message de ce type en se connectant à une URL HTTP :

"La connexion n’est pas sécurisée. Les propriétaires de xxx.fr ont mal configuré leur site web. Pour éviter que vos données ne soient dérobées, Firefox ne s’est pas connecté à ce site web."

Connexion non sécurisée
Un site où le certificat SSL est mal mis en place, expiré ou non présent

Vérifier l'accès aux URL HTTPS

Une fois le certificat installé, vérifiez sa mise en place en tapant n'importe quelle URL en HTTPS de votre site. Normalement, ce dernier devrait s'afficher normalement et vous devriez avoir un cadenas apparaître dans la barre d'adresse du navigateur. Si vous voyez un triangle jaune, le certificat est valide mais votre page appelle des ressources en HTTP.

Que ce soit le cas ou non, la migration est encore loin d'être terminée

Remplacer les URL de WordPress en base de données

Il faut maintenant indiquer à WordPress que la vraie URL par défaut est en HTTPS. Cela va permettre plusieurs choses :

  • rediriger une partie du trafic automatiquement ;
  • forcer l'appel aux ressources en HTTPS plutôt qu'en HTTP (à condition que les extensions et le thème soient correctement conçus).

Pour faire cela, il existe 3 solutions différentes :

  • utiliser une extension comme Really Simple SSL ;
  • modifier l'adresse dans le menu "Réglages > Général" ;
  • modifier les URL en base de données.

Soyons honnêtes, seule la troisième solution est la bonne.

Si vous optez pour l'extension (solution n°1), non seulement vous serez dépendant de cette dernière, mais cela augmentera le temps de chargement car elle devra s'initialiser constamment sur toutes vos pages. Quant à la seconde solution, elle est trop incomplète pour être efficace car elle ne modifier qu'une toute partie des URL : vous auriez encore un grand nombre de liens en HTTP dans vos contenus.

La seule solution est de faire un vrai remplacement de toutes vos URL internes HTTP. Pour cela :

  • téléchargez le script Search and Replace DB ;
  • copiez les fichiers de ce script sur votre hébergement via FTP (en renommant le dossier avant) ;
  • tapez dans votre navigateur l'adresse du script : monsite.com/nom-du-dossier ;

Search and Replace DB va automatiquement trouver les informations de votre base de données WordPress. Il suffit alors de mettre l'URL à remplacer et la nouvelle URL dans les champs "replace" et "with". Plus bas, le bouton "Dry Run" permet de simuler la modification, et le bouton "Live Run" effectuera réellement les modifications. En cliquant sur ce dernier, cela changera en base de données l'ancien texte par le nouveau, ici nos URL :

Search and Replace Database
Un script très utile pour modifier une base de données WordPress

Ce script a plusieurs atouts énormes:

  • il ne sert pas uniquement aux migrations HTTPS. Il peut être utilisé lorsque l'on veut remplacer en base de données un texte présent dans tous nos contenus, ou encore pour des changements de noms de domaines ;
  • il peut convertir le type de base données (par exemple modifier l'encodage) ;
  • il va aussi modifier les données sérialisées (et il sera donc bien plus efficace que des requêtes SQL traditionnelles pour changer nos URL HTTP).

Quelques remarques importantes avant de cliquer sur Live Run :

  • modifiez toujours des URL équivalentes : l'URL sans slash de fin vers une URL sans slash de fin, ou les deux avec, mais jamais une avec un slash final et l'autre sans !
    • Bon exemple : http://site.fr vers https://site.fr
    • Mauvais exemple : http://site.fr/ vers https://site.fr
  • profitez-en pour vérifier que les variantes du domaine n'existent pas non plus. Imaginons que votre site soit http://www.test.fr. Vous devez alors faire ces remplacements :
    • http://www.test.fr vers https://www.test.fr
    • http://test.fr vers https://www.test.fr
    • https://test.fr vers https://www.test.fr
  • pensez impérativement à supprimer tout le dossier Search and Replace DB après utilisation.

Rediriger toutes les URL HTTP vers HTTPS

A ce stade, nous avons un certificat SSL valide et WordPress qui se charge par défaut en HTTPS. Le problème, c'est qu'il faut s'assurer de rediriger l'internaute dès qu'il se connecte à la version HTTP. WordPress ne va pas forcément le faire pour vous. Si vous ne le faites pas, vous allez créer une version dupliquée de votre site ce qui impactera négativement votre référencement naturel !

Pour cette étape, c'est simple : vous devez forcer la redirection HTTP vers HTTPS au niveau du serveur lui-même. Sur Apache, il faudra ainsi modifier le fichier htaccess. Sur Nginx, il faudra modifier le fichier de configuration serveur.

Que vous vouliez avoir un WordPress en HTTPS chez OVH, 1&1 ou encore chez Infomaniak, la recommandation est la même : quel que soit le type de serveur que vous utilisez, je vous recommande fortement de regarder la documentation officielle de votre hébergeur qui très souvent vous donnera les manipulations à effectuer. Si vous ne trouvez pas, je vous conseille de regarder cette liste de codes .htaccess qui fonctionnent sur une majorité de serveurs, comme par exemple avec ce code :

RewriteEngine on
RewriteCond %25{HTTPS} !on
RewriteRule (.*) https://%25{HTTP_HOST}%25{REQUEST_URI} [L,R=301]

# Note: It%E2%80%99s also recommended to enable HTTP Strict Transport Security (HSTS)
# on your HTTPS website to help prevent man-in-the-middle attacks.
# See https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
<IfModule mod_headers.c>
    # Remove "includeSubDomains" if you don't want to enforce HSTS on all subdomains
    Header always set Strict-Transport-Security "max-age=31536000;includeSubDomains"
</IfModule>

Attention, Google conseille de mettre en place des redirections côté serveur (notamment avec le fichier htaccess). Il faut ainsi éviter de faire ces redirections 301 de l'HTTP vers l'HTTPS avec  du code PHP (donc en évitant d'utiliser une extension WordPress).

Les URL codées en dur dans WordPress

Il existe ensuite un autre cas de figure assez courant : les URL codées en dur dans les fichiers (et non pas dans la base de données). On peut les trouver dans :

  • le thème ;
  • les extensions ;
  • les mu-plugins ;
  • les fichiers de traduction ;
  • les fichiers sitemap (fichiers XML) ;
  • le fichier robots.txt

Pour les débusquer, le meilleur moyen est d'utiliser un éditeur de texte comme par exemple Sublime Text et de faire une recherche dans l'ensemble des fichiers de votre backup (sauvegarde) initial (donc sur votre ordinateur). Dans le logiciel cité, cela se situe dans le menu "Find > Find in Files". Pensez juste à exclure lors de votre recherche le dossier "cache" situé dans wp-content car il risque sinon de lister toutes les URL en cache de votre site (et qui contiennent forcément les anciennes URL).

Sublime text recherche dans fichiers multiples
Rechercher dans un ensemble de fichiers avec Sublime Text

S'il en trouve, vous devrez remplacer les mauvaises URL dans les fichiers concernés sur votre serveur en ligne. Attention, ajouter des URL en dur dans du code est une très mauvaise pratique !

Vider tous les caches

Dernière étape de la migration HTTPS de votre WordPress, il faut réinitialiser votre CMS. Voici les étapes à suivre :

  1. il faut "flusher" les permaliens, c'est à dire réinitialiser les règles de réécriture de WordPress pour être sûr qu'il prenne correctement en compte les URL HTTPS. Pour cela, rien de plus simple : il suffit de consulter la page d'administration "Réglages > Permaliens" ;
  2. si vous utilisez une extension de cache (WP Rocket, WP Super Cache, W3 Total Cache ou autre), il vous faudra vider le cache de cette dernière ;
  3. si vous utilisez un cache serveur, comme Varnish par exemple, il faudra là aussi le vider ;
  4. enfin, certains hébergeurs peuvent avoir d'autres types de cache, comme OVH qui a parfois un cache CDN. Là encore, il faudra les vider.

Après la migration HTTPS

Théoriquement à ce stade, votre site a correctement basculé en HTTPS (certificat, remplacement des URL et redirections 301). Il nous reste maintenant à vérifier que tout fonctionne bien.

Vérifier les redirections 301

Etape 1

C'est le plus important : les redirections 301 sont-elles en place ?

1er moyen de vérifier cela, tapez juste une URL en HTTP de votre site, vous devriez être redirigé en HTTPS. Mais attention, cette méthode ne permet pas de tester toutes les URL, et cela ne permet pas non plus de vérifier que le code de redirection est en 301 (code définitif, et non pas en 302 code temporaire).

Pour réellement vérifier cela, il nous faut tester TOUTES les anciennes URL (d'où le scan initial). Vous devez donc utiliser une nouvelle fois votre logiciel de crawl. Au lieu de scanner un nom de domaine, vous allez lui demander de scanner toutes les anciennes URL. Sur Screaming Frog, utilisez le menu "Mode > Liste" (dans Xenu, ce sera "File > Check URL List"). Allez chercher votre liste d'URL du tout début et lancez l'analyse. Théoriquement, toutes vos anciennes URL (en HTTP) doivent afficher un code de redirection 301 dans la colonne "Status Code" :

Crawl Screaming Frog HTTP
Un crawl des anciennes URL en HTTP d'un site

Etape 2

Vous devrez ensuite faire un second scan, cette fois-ci sur les URL du site actuel. L'objectif est de vérifier que :

  • vous n'avez plus aucune URL avec votre nom de domaine en HTTP ;
  • vous n'avez aucune ressource appelée en HTTP, que ce soit avec votre nom de domaine ou non (donc tout appel à des fichiers CSS, des images de background ou encore des polices d'écriture).

HTTPS et outils externes

Une fois vos modifications et redirections mises en place, votre travail est malheureusement encore loin d'être terminé. Il vous faudra agir sur d'autres outils et sites.

Logiciels de suivi

Si vous utilisez des outils pour suivre votre site, comme par exemple un outil de Webanalytics pour le trafic (Google Analytics notamment) ou encore un outil de suivi de positionnement (Ranks, MyPoseo, Monitorank, etc.), vous devrez aller modifier l'URL de votre site dans ces différentes solutions.

Search Console

Dans cet outil gratuit de Google pour suivre l'état de santé de votre site, vous devrez aller faire certains ajouts. Vous devrez en effet vous connecter pour créer une nouvelle propriété : la version HTTP de votre site étant considérée comme différente de la version HTTPS, il vous faut une seconde propriété. D'ailleurs, vous pourrez ainsi suivre dans les semaines qui suivent la désindexation des URL HTTP, tout en voyant apparaître les URL HTTPS en comparant les deux versions.

Sachez que vous pouvez aussi utiliser le menu "Changement d'adresse " disponible dans l'ancienne version de la Search Console à partir du menu en haut à droite :

Search Console changement d'adresse
Le menu "changement d'adresse" de la Search Console de Google

Ce dernier point n'est pas contre pas obligatoire car si vous avez bien fait votre travail avec les redirections 301, cela devrait fonctionner naturellement pour le moteur de recherche.

Local Business

Si vous possédez une fiche Local Business, vous devrez aussi penser à changer l'adresse de votre site web (et si vous n'avez pas une telle fiche, il est grand temps d'y remédier).

Profils officiels

Là encore, c'est logique : sur tous vos profils et pages officiels, vous devez penser à changer l'URL de votre site WordPress. Cela peut inclure :

  • votre page Facebook ;
  • votre compte Twitter ;
  • votre profil Linkedin ;
  • etc.

Les outils de marketing

Là encore, si vous utilisez des outils ou plateformes externes pour gérer des aspects marketing de votre site, il faut là aussi changer vos URL vers une version HTTPS. En fonction de votre activité, il peut y en avait beaucoup : affiliation, emailing, Adwords, etc.

Une fois de plus, rien d'obligatoire, mais cela reste une bonne pratique. Actuellement, les liens qui pointent vers votre site WordPress le font vers la version HTTP. Grâce aux redirections 301, vous ne perdez pas de popularité. Cependant :

  • un lien direct transmettra toujours 100% de la popularité, alors qu'une redirection 301 peut potentiellement en bloquer une petite partie ;
  • Google suivra mieux les liens directs, et cela facilitera donc son crawl et son indexation ;
  • pour l'utilisateur, un lien direct a un meilleur temps de chargement qu'un lien qui provoque une redirection 301.

Dans l'idéal, essayez donc de modifier vos backlinks pour avoir la version HTTPS incluse dedans. Bien entendu, vous ne pourrez pas le faire partout car il est impossible de tous les maîtriser, mais plus vous pourrez faire cette action, mieux ce sera.

L'administration de WordPress et l'HTTPS

Dans WordPress, sans même faire des redirections 301, vous pouvez forcer le CMS à n'avoir que des pages de connexion et d'administration en HTTPS. Pour faire cela, vous devez :

  • vous connecter à votre serveur web ;
  • trouver le fichier wp-config.php situé à la racine de votre installation ;
  • le modifier en ajoutant la ligne suivante juste avant la ligne  "/* C’est tout, ne touchez pas à ce qui suit ! */"
define('FORCE_SSL_ADMIN', true);

Tester sa migration HTTPS

Tout ce que nous venons de faire part du principe que le changement vers l'HTTPS s'est bien déroulé. Le hic, c'est que la validité n'est pas calculée sur un site entier mais bien URL par URL. Et pour rappel, il suffit qu'une page appelle une seule ressource HTTP pour que toute la page soit considérée comme invalide (cadenas avec triangle jaune).

En plus du crawl du site actuel, on peut donc utiliser ces outils en ligne qui vont tester justement cette validité :

  • WhyNoPadlock qui va tester en profondeur l'URL demandée (il est probable que vous ayez un triangle d'alerte sur la partie "protocol" : si vous avez un certificat SSL gratuit, c'est normal et ce n'est pas grave) ;
  • pour les puristes, le SSLLabs fera une analyse très approfondie et technique de votre chiffrement SSL ;
  • SSLCheck qui ira moins loin, mais qui va tester directement 200 URL en un crawl.
SSL Check pour pages HTTPS non valides
SSL Check peut crawler et trouver des pages non valides

Check-list HTTPS WordPress

Et voici le résumé d'une migration HTTPS réussie sur le CMS WordPress !

  • faire une sauvegarde complète ;
  • scanner son site avec un crawler ;
  • obtenir un certificat SSL ;
  • vérifier l'accès aux URL HTTPS ;
  • remplacer les URL de WordPress en base de données ;
  • rediriger toutes les URL HTTP vers des URL en HTTPS ;
  • corriger les URL codées en dur ;
  • vider tous les caches ;
  • vérifier les redirections 301 ;
  • changer les URL de ses outils et des backlinks ;
  • tester sa migration HTTPS ;

WordPress HTTPS check-list

Pour la partager, copiez/collez ce code ;)

<a href="https://www.seomix.fr/guide-https-et-wordpress/"><img src="https://www.seomix.fr/wp-content/uploads/2019/02/wordpress-https-check-list-seomix.jpg" alt="Check-list WordPress et HTTPS"></a>

Pour rappel, si vous avez un doute, contactez-nous pour ne pas casser votre site WordPress et votre référencement naturel.

Contactez-nous !

Daniel Roch

Expert SEO WordPress - Créateur de SeoMix et SEOKEY - Auteur de nombreux livres et conférencier

2 Commentaires

Olivier / WP Trigone Le 08 février 2019 à 13h15

Bonjour Daniel,

Merci pour ce superbe guide :)

J'ai une remarque sur la redirection via le .HTACCESS :

Sur cette ligne "RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}" je pense qu'il faudrait rajouter à la fin ceci " [L,R=301] " pour faire une redirection de type permanent (301) (vu que c'est à priori le but de ce passage en HTTPS), sinon elle sera en temporaire (302).

Ou bien indiquer le choix possible dans ton guide à la suite.

Olivier
WP Trigone

    Daniel Roch Le 08 février 2019 à 13h22

    Bien vu, je corrige ;)

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *