Installer un certificat ne termine pas une migration HTTPS. WordPress peut encore produire des liens HTTP, le navigateur peut bloquer des ressources mixtes, plusieurs couches peuvent ajouter des redirections contradictoires et les moteurs peuvent rencontrer deux versions d’une même page.
Une migration HTTPS WordPress réussie relie certificat valide, URL applicatives, remplacement compatible des anciennes adresses, redirection permanente, ressources sécurisées, canoniques, sitemap et surveillance du renouvellement. Le but n’est pas d’afficher un cadenas sur l’accueil : chaque parcours doit rester fonctionnel sous une seule version publique.
Sommaire
La réponse courte
Inventoriez les noms de domaine et sous-domaines réellement servis. Faites émettre un certificat qui les couvre et vérifiez HTTPS avant d’ajouter une redirection. Sauvegardez le site, basculez les adresses WordPress vers https://, traitez les références internes avec une méthode compatible avec les données sérialisées, puis redirigez chaque URL HTTP vers son équivalent HTTPS.
Testez pages, médias, administration, connexion, formulaires, paiement et services externes. Vérifiez que les canoniques et le sitemap utilisent HTTPS, que la version HTTP ne crée pas de boucle et que le certificat se renouvelle automatiquement avec une alerte d’échec.
Google recommande HTTPS pour la sécurité des visiteurs et du site dans ses principes techniques pour la recherche. Cette recommandation ne transforme pas HTTPS en garantie de classement ou de sécurité totale.
Principes qui restent valables
Le chiffrement protège la connexion entre le navigateur et la destination authentifiée par le certificat. Il ne corrige pas une extension vulnérable, un mot de passe réutilisé, une sauvegarde absente ou un formulaire mal conçu.
Les autorités ACME et les panneaux automatisent davantage l’émission et le renouvellement. Cette facilité ne supprime pas les prérequis : le nom doit être validable, le DNS doit pointer correctement et la politique CAA ne doit pas empêcher l’autorité prévue.
Une migration HTTPS WordPress reste aussi un changement d’URL. http://exemple et https://exemple sont deux adresses distinctes tant que redirections et signaux canoniques ne les unifient pas.
Inventorier les noms à protéger
Listez le domaine canonique, sa variante avec ou sans www, les sous-domaines publics et les domaines secondaires qui redirigent. Ne demandez pas un certificat pour un ancien nom abandonné sans vérifier son DNS et son utilité.
Choisissez la version canonique avant la mise en œuvre. Si le site doit répondre sans www, la variante avec www peut toujours nécessiter un certificat afin de recevoir la connexion HTTPS puis rediriger proprement.
Conservez cet inventaire en privé. Il ne doit pas inclure dans un article les noms internes, l’adresse du panneau, le serveur, les comptes ou la topologie.
Émettre le certificat avant de forcer HTTPS
La documentation DirectAdmin sur ACME pour les domaines explique que l’émission et le renouvellement automatiques peuvent être disponibles au niveau utilisateur lorsque la fonction est activée.
Avant la demande :
- confirmez que chaque nom sélectionné pointe vers la destination attendue ;
- vérifiez les enregistrements CAA lorsqu’ils existent ;
- retirez de la demande les sous-domaines obsolètes ;
- assurez l’accessibilité de la méthode de validation ;
- utilisez le fournisseur ACME configuré sans publier ses secrets.
Après émission, ouvrez chaque nom couvert en HTTPS et inspectez le certificat dans le navigateur. Une coche dans le panneau n’est pas une validation de l’ensemble du parcours.
Sauvegarder et préparer le retour
Sauvegardez base et fichiers dans le même état. Notez les réglages d’URL, redirections, cache et proxy qui vont changer. Préparez une méthode de retour si l’administration devient inaccessible ou si les ressources critiques échouent.
Ne supprimez pas immédiatement l’ancienne configuration après la bascule. Gardez-la le temps de vérifier que le certificat, les redirections et les tâches fonctionnent, sans maintenir deux sites acceptant des écritures différentes.
La procédure restaurer une sauvegarde WordPress détaille le test de reprise qui doit précéder les modifications importantes.
Mettre à jour les adresses WordPress
WordPress distingue l’adresse où se trouvent les fichiers du cœur et l’adresse publique du site. Le guide officiel Migrating WordPress décrit ces réglages et précise qu’ils doivent inclure le schéma https://.
Changez les valeurs selon l’architecture réelle, dans une fenêtre contrôlée. Une valeur forcée dans la configuration peut rendre le champ non modifiable dans l’administration ; documentez la source de vérité au lieu de définir le même réglage à plusieurs endroits.
Testez immédiatement l’accueil, l’administration et la connexion. Si une redirection empêche l’accès, annulez le dernier changement selon le plan au lieu d’ajouter une nouvelle règle au hasard.
Remplacer les anciennes références en sécurité
Les contenus, métadonnées, widgets, réglages d’extensions et champs personnalisés peuvent contenir des URL absolues HTTP. Un remplacement de texte brut dans la base peut corrompre les données sérialisées.
Utilisez un outil WordPress compatible comme `wp search-replace`, commencez par une simulation et sauvegardez l’export. Limitez l’opération aux tables prévues et excluez les URL externes qui ne doivent pas changer.
Certaines références vivent hors de la base : feuilles de style, JavaScript, modèles, webhooks ou outils externes. Recherchez-les séparément. Ne remplacez pas aveuglément toutes les occurrences de http.
Éliminer le contenu mixte
Une page HTTPS devient mixte lorsqu’elle charge une image, une police, un script, une feuille de style ou une iframe par HTTP. Le navigateur peut bloquer la ressource active ou afficher un avertissement.
Inspectez un échantillon représentatif : accueil, article ancien, archive, formulaire, page de connexion et parcours commercial. Corrigez la source de l’URL plutôt que de masquer l’avertissement. Pour une ressource externe, vérifiez qu’une version HTTPS officielle existe ; sinon, remplacez ou retirez la dépendance.
Purge cache, CDN et navigateur après correction. Une ancienne copie HTML peut continuer à référencer HTTP même lorsque la base est propre.
Construire une seule redirection permanente
La redirection HTTP vers HTTPS peut être gérée par le serveur, le panneau, un proxy ou WordPress. Choisissez une couche principale. Plusieurs règles ignorant ce que la précédente a déjà fait créent des chaînes ou des boucles.
Chaque ancienne URL doit aller directement vers son équivalent HTTPS final, avec la version canonique du domaine. Conservez le chemin et les paramètres utiles. Testez :
- HTTP avec et sans
www; - HTTPS avec la variante non canonique ;
- une page profonde ;
- un média ;
- une URL avec paramètre pertinent ;
- une page inexistante qui doit rester une vraie 404.
Google traite HTTP vers HTTPS comme une migration d’URL et demande de vérifier les redirections, sitemap et règles d’indexation dans son guide de migration.
Aligner canoniques, sitemap et liens internes
Les pages HTTPS doivent déclarer leur propre adresse canonique lorsque le site utilise une canonical auto-référente. Le sitemap ne doit plus lister HTTP. Les liens internes, données structurées, hreflang, images sociales et flux doivent pointer vers la version finale.
Google indique que HTTPS, redirections, sitemap et rel="canonical" contribuent au choix d’une URL représentative. Évitez de donner des signaux contradictoires, par exemple une page HTTPS qui déclare HTTP comme canonique.
Vérifiez les propriétés et rapports pertinents dans Search Console. L’indexation n’est jamais garantie et le traitement prend le temps nécessaire au recrawl.
Protéger cookies, formulaires et intégrations
Testez connexion, déconnexion, récupération de mot de passe et maintien de session. Les cookies sensibles doivent être transmis dans un contexte sécurisé selon le fonctionnement de l’application. Une configuration de proxy incorrecte peut faire croire à WordPress que la requête reste HTTP et provoquer une boucle.
Vérifiez les URL de retour de paiement, webhooks, OAuth, API et outils d’analyse dans leurs systèmes propriétaires. Utilisez des modes de test et ne publiez aucune clé ou URL secrète.
Soumettez un formulaire et confirmez la réception. Une page de succès n’est pas la preuve que l’e-mail ou le webhook est arrivé.
Traiter HSTS avec prudence
HSTS indique au navigateur de n’utiliser que HTTPS pendant une durée donnée. Cette protection devient utile lorsque tous les noms concernés sont prêts, que le renouvellement est fiable et que le retour HTTP n’est plus nécessaire.
Ne copiez pas une directive incluant tous les sous-domaines sans les inventorier. Un sous-domaine ancien ou géré ailleurs peut devenir inaccessible. La précharge HSTS est un engagement supplémentaire qui demande une préparation et une procédure de retrait distinctes.
Activez d’abord HTTPS et les redirections, observez leur stabilité, puis décidez HSTS selon le périmètre réel.
Surveiller le renouvellement
Un certificat automatique peut échouer après une modification DNS, une politique CAA, un domaine expiré ou une restriction de validation. Configurez une alerte vers un destinataire actif avant l’expiration.
Testez la visibilité du statut et la procédure d’intervention. Ne dépendez pas d’une seule boîte ou d’une seule personne. L’audit annuel doit confirmer domaines, contacts et renouvellements, mais la surveillance d’expiration doit être continue.
Checklist HTTPS WordPress
- [ ] Les noms publics et la version canonique sont inventoriés.
- [ ] Le DNS permet la validation prévue.
- [ ] Le certificat couvre chaque nom servi.
- [ ] HTTPS fonctionne avant toute redirection forcée.
- [ ] Base et fichiers sont sauvegardés dans un état cohérent.
- [ ] Les adresses WordPress utilisent HTTPS à leur source de vérité.
- [ ] Les remplacements respectent les données sérialisées.
- [ ] Images, scripts, styles, polices et iframes ne créent pas de contenu mixte.
- [ ] Une seule couche principale gère la redirection.
- [ ] Chaque variante mène directement à l’URL finale.
- [ ] Canoniques, sitemap, liens internes et schema utilisent HTTPS.
- [ ] Connexion, sessions, formulaires et intégrations sont testés.
- [ ] CDN et caches sont purgés puis vérifiés.
- [ ] HSTS n’est activé qu’après inventaire et stabilisation.
- [ ] Le renouvellement possède une alerte et un responsable.
- [ ] Aucune donnée d’infrastructure n’est publiée.
Points clés à retenir
HTTPS est un système cohérent, pas un certificat isolé. La confiance vient du nom couvert, du chiffrement, d’une URL canonique, d’une redirection simple et d’un renouvellement surveillé.
Pour une migration HTTPS WordPress, vérifiez d’abord le certificat, sauvegardez, mettez à jour l’application et ses références, corrigez le contenu mixte, puis alignez redirections et SEO. Testez les parcours réels avant de considérer la bascule terminée.
La migration WordPress checklist complète ce guide lorsqu’HTTPS accompagne un déplacement plus large.