Comment migrer WordPress de HTTP vers HTTPS sans perdre de SEO ?

Préparer le certificat SSL avec Let’s Encrypt

La migration vers HTTPS commence par la mise en place d’un certificat fiable. Pour la plupart des sites WordPress, Let’s Encrypt constitue un choix robuste et économique, avec des certificats DV renouvelables automatiquement via Certbot ou l’outil intégré de votre hébergeur. Avant toute action, réalisez une sauvegarde complète et planifiez un créneau de bascule afin de limiter les incohérences de cache et les erreurs perçues par les internautes et les robots.

Vérifiez que votre environnement supporte le SNI¹ si vous partagez l’adresse IP du serveur, et préférez des suites cryptographiques modernes. Un certificat ECDSA 256 bits est généralement plus performant qu’un RSA 2048, sous réserve de compatibilité côté CDN et terminators TLS. Si vous gérez plusieurs sous-domaines, un certificat SAN ou wildcard simplifiera la couverture, mais évitez d’inclure des environnements de préproduction qui pourraient fuiter dans les moteurs.

Une fois le certificat installé, testez la chaîne de certificats et la négociation TLS avec un analyseur public (par exemple Qualys SSL Labs) pour prévenir les alertes “connexion non sécurisée”. Le certificat n’impose pas à lui seul le passage en HTTPS : il prépare la couche transport. La suite de la migration consiste à basculer l’application WordPress et à maîtriser les redirections afin de préserver le SEO.

Anticipez les impacts opérationnels : invalidez ou purgez les caches serveur et plugin au moment de la bascule, vérifiez la compatibilité des extensions qui injectent des URLs absolues, et préparez un plan de repli simple (désactivation des règles de redirection et restauration des anciennes URLs) en cas d’incompatibilité critique.

Mettre à jour WordPress et forcer les 301 vers HTTPS

Commencez par mettre à jour les URLs de WordPress dans Réglages puis Adresse web du site et Adresse web de WordPress, ou définissez-les au niveau des constantes d’environnement pour éviter toute réécriture accidentelle lors d’un déploiement. Si votre base contient des liens absolus en HTTP (dans les contenus, widgets, options de thème), utilisez un outil de recherche-remplacement compatible avec les données sérialisées pour éviter de corrompre les options.

Au niveau serveur, forcez des redirections 301 de http:// vers https:// et normalisez en même temps les variantes www/non-www. L’objectif est qu’une URL source n’ait qu’un seul saut vers sa version canonique, sans 301 chain³. Filtrez également les variantes HTTP des ressources statiques (CSS, JS, médias) via les mêmes règles pour garantir une cohérence complète. Privilégiez des redirections au plus près du point d’entrée (Nginx, Apache) plutôt qu’au niveau PHP, afin de réduire la latence et d’éviter de servir même partiellement des pages en clair.

Contrôlez l’implémentation sur un échantillon d’URLs stratégiques : pages profondes, archives, taxonomies, pagination et paramètres de filtrage. Une vérification simple consiste à observer dans les outils de développement que l’URL HTTP renvoie bien un 301 unique vers la version HTTPS, et que la version HTTPS retourne un 200 sans redirection supplémentaire. Évitez les 302 temporaires qui diluent les signaux SEO.

Pensez à aligner les endpoints tiers utilisés par le site (CDN, police web, analytics, passerelles de paiement) sur HTTPS. Si vous utilisez un CDN, vérifiez que l’origine est contactée en HTTPS et que le CDN réécrit correctement les en-têtes de schéma pour éviter des comportements divergents côté cache.

Corriger le mixed content et assainir les assets

La cause principale d’avertissements de sécurité après migration est le mixed content², c’est-à-dire le chargement de ressources HTTP au sein d’une page servie en HTTPS. Outre l’impact sur la confiance, certains navigateurs bloquent purement et simplement les scripts et iframes mixtes, ce qui peut casser des fonctionnalités clés.

Pour le corriger durablement, réécrivez toutes les références absolues en HTTPS dans la base et les templates de thème. Évitez les URLs “protocol-relative” en // qui masquent des erreurs en développement mais compliquent le débogage et l’analyse SEO. Ciblez en priorité les champs d’options du thème, les shortcodes, les widgets HTML, les menus, les champs ACF et les contenus Gutenberg embarquant des iframes, vidéos et polices distantes.

Sur les ressources externes que vous ne contrôlez pas, remplacez-les par des équivalents HTTPS ou auto-hébergez les actifs critiques (polices, icônes, scripts) lorsque la licence l’autorise. Une règle CSP “upgrade-insecure-requests” peut aider à la transition, mais ne doit pas remplacer la correction des URLs à la source, surtout pour les scripts bloqués par défaut.

Après réécriture, repassez un scanner de mixed content et vérifiez le front sur les gabarits principaux, y compris la recherche, les pages d’erreur et les archives. Purgez tous les niveaux de cache et validez côté mobile. Enfin, surveillez la console navigateur durant quelques jours pour intercepter les derniers appels en HTTP résiduels, souvent introduits par des widgets tiers.

Depuis que nous corrigeons systématiquement le mixed content à la source, les alertes de sécurité ont disparu et les taux de conversion n’ont plus chuté lors des pics de trafic.

Activer HSTS et sécuriser la couche transport

Une fois les redirections et les assets assainis, activez HSTS⁴ pour indiquer au navigateur que votre domaine est exclusivement disponible en HTTPS. Cette directive protège contre les tentatives de downgrade et certaines attaques actives sur le réseau. Débutez avec un délai raisonnable (par exemple 1 à 4 semaines) le temps de vérifier que tous les sous-domaines requis répondent en HTTPS.

Lorsque l’ensemble du périmètre est prêt, renforcez la politique avec includeSubDomains et, si vous êtes certain de la couverture, envisagez le préchargement via la “HSTS preload list”. Le préchargement est un engagement fort : une erreur de périmètre peut bloquer l’accès à des sous-domaines non migrés. Assurez-vous que la messagerie, les sous-domaines d’images, d’API et les environnements nécessaires au public sont bien servis en HTTPS, avant d’allonger la durée et d’activer includeSubDomains.

Sur les architectures avec CDN ou proxy TLS, positionnez l’en-tête HSTS au plus proche du client et vérifiez qu’il n’est pas doublonné ou écrasé après un passage applicatif. Restez attentif aux environnements de test et de préproduction accessibles au public : n’activez pas HSTS sur ces domaines s’ils doivent parfois être servis en HTTP. Documentez la décision dans votre runbook de production pour pérenniser la configuration lors des mises à jour serveur.

Contrôles SEO post-migration canonical sitemaps et monitoring

Une migration HTTPS réussie se valide par des signaux SEO cohérents. Assurez-vous que les balises canonical pointent vers les URLs en HTTPS et qu’elles sont auto-référentielles sur les pages canoniques. Vérifiez également les liens alternates hreflang et les métadonnées Open Graph/Twitter Cards, qui contiennent souvent des URLs absolues.

Générez et soumettez un sitemap en HTTPS dans Google Search Console et Bing Webmaster Tools. Créez les propriétés “domaine” ou, à défaut, ajoutez la nouvelle propriété HTTPS si vous utilisiez jusqu’ici la version HTTP. Inspectez quelques URLs avec l’outil d’inspection pour confirmer l’exploration en HTTPS, l’absence de redirections superflues et la bonne découverte du sitemap. Maintenez l’ancienne propriété HTTP pendant plusieurs mois pour surveiller les erreurs d’exploration résiduelles.

Côté WordPress, vérifiez que les plug-ins SEO ne réécrivent pas involontairement les schémas d’URL. Sur les thèmes personnalisés, contrôlez la génération des liens paginés, des fils d’Ariane et des liens canonisés dans les archives de taxonomie. Uniformisez strictement le schéma d’URL pour éviter les doublons entre variantes www et non-www, avec et sans slash final, et assurez-vous que tous ces cas sont redirigés vers l’URL canonique en HTTPS.

Surveillez durant 4 à 8 semaines les métriques clés : proportion d’impressions sur la version HTTPS, évolution du nombre d’URLs valides, apparitions d’erreurs 404 et “pages avec redirection” dans les rapports de couverture. Côté analytics, vérifiez l’actualisation de l’URL par défaut de la propriété, l’absence de rupture de session lors des renvois d’HTTP vers HTTPS et l’exactitude du référent sur les pages d’atterrissage. Enfin, auditez vos principaux backlinks et, lorsque c’est possible, sollicitez la mise à jour des liens encore en HTTP depuis les partenaires prioritaires.

En synthèse, une migration vers HTTPS bien menée combine préparation du certificat, redirections nettes, élimination du contenu mixte, activation prudente d’HSTS et contrôles SEO systématiques. Le recours à Let’s Encrypt simplifie la conformité et la maintenance, mais la qualité du résultat dépend surtout de la rigueur des redirections et de la correction des références en base. En documentant chaque décision et en surveillant les signaux, vous sécurisez l’expérience utilisateur sans perdre de SEO.

1. SNI Extension TLS permettant d’héberger plusieurs certificats sur une même IP ; prise en charge large par les navigateurs modernes.
2. Mixed content Page HTTPS qui charge encore des ressources en HTTP ; source d’avertissements et de blocages côté navigateur.
3. 301 chain Enchaînement de redirections successives ; à éviter au profit d’un seul saut HTTP → HTTPS vers l’URL canonique.
4. HSTS En-tête HTTP qui ordonne l’usage exclusif de HTTPS pour un domaine, avec options includeSubDomains et préchargement.