Contenu mixte WordPress en HTTPS : repérer et corriger
Le certificat est installé, mais le cadenas ne s'affiche pas : une seule ressource chargée en http:// suffit. Comment la repérer, la corriger à la source et vérifier que l'avertissement ne revient pas.
Guides & ressources Par Romain D. Publié le
- Durée
- 30 min
- Niveau
- Intermédiaire
- Lecture
- 10 min

Un certificat installé, un site en https:// et pourtant un cadenas barré. Il suffit d’une seule ressource chargée en http:// pour que le navigateur signale la page. Ce défaut a un nom, le contenu mixte, et sur WordPress il vient souvent d’adresses écrites avant le passage en HTTPS. Voici comment le repérer, le corriger à la source et vérifier qu’il ne revient pas.
- Contenu mixte : une page en HTTPS qui charge au moins une ressource en HTTP, c’est la définition de MDN, la documentation de référence des navigateurs.
- Images, audio et vidéo sont remontés automatiquement en HTTPS par les navigateurs. Scripts, feuilles de style, iframes et polices sont bloqués, d’où des pages cassées ou mises en forme de travers.
- WordPress réécrit les adresses à l’affichage depuis la version 5.7, mais seulement dans le contenu, les extraits, les widgets texte et le CSS additionnel. Rien n’est modifié en base.
- La console du navigateur donne l’adresse exacte de chaque ressource fautive. Corrigez-la à la source, en base, dans le thème ou dans l’extension concernée.
- Une redirection vers HTTPS ne suffit pas : elle change l’adresse de la page, pas celles de ses ressources.
Qu’est-ce que le contenu mixte, et pourquoi le cadenas disparaît ?
Le contenu mixte apparaît quand une page servie en HTTPS charge des ressources en HTTP : images, scripts, feuilles de style ou iframes. Le navigateur juge la page à moitié protégée et le dit. Le certificat n’est pas en cause, et c’est l’hébergeur qui l’installe.
Ce que le navigateur fait dépend du type de ressource, d’après la documentation de MDN.
| Traitement | Ressources concernées | Effet visible sur votre site |
|---|---|---|
| Mise à niveau automatique vers HTTPS | Images (attribut src), audio, vidéo, images de fond en CSS | La ressource s’affiche, mais le navigateur l’a corrigée pour vous, ce qui masque le défaut |
| Blocage pur et simple | Scripts, feuilles de style, iframes, polices web, requêtes fetch et XMLHttpRequest, images en srcset ou picture | Mise en page cassée, bouton ou formulaire inactif, image manquante |
Retenez la ligne du bas : les images responsives que WordPress génère passent par srcset, elles peuvent donc être bloquées alors que l’image classique est corrigée. Vérifiez donc aussi les images, pas seulement les scripts.
Source : documentation MDN sur le contenu mixte.
Comment repérer les ressources en http:// ?
Ouvrez la console du navigateur sur la page fautive : elle liste chaque ressource en HTTP avec son adresse complète. Cette adresse dit déjà d’où vient le problème, et c’est elle qui décide de la correction.
- Ouvrez la page en
https://. Notez si le navigateur affiche un cadenas, une mention « non sécurisé » ou une icône barrée. Testez plusieurs pages, la page d’accueil, un article, une page et un formulaire, car le défaut peut ne venir que d’un gabarit. - Ouvrez les outils de développement. Sous Chrome, le raccourci est Ctrl + Maj + I sous Windows, Cmd + Option + I sous Mac. Ouvrez l’onglet Console : les navigateurs y affichent leurs avertissements, d’après MDN.
- Relevez chaque adresse en
http://. Notez le dossier ou le domaine :/wp-content/uploads/désigne un média,/wp-content/themes/le thème,/wp-content/plugins/une extension, un domaine étranger une ressource externe. - Cherchez aussi dans le code source. Affichez le code de la page, puis cherchez
http://avec la fonction de recherche du navigateur. Vous trouvez ce que la console ne signale pas, par exemple un lien qui n’est pas une ressource chargée.
L’adresse relevée indique où corriger. Le tableau ci-dessous classe les sources les plus courantes.
| Adresse relevée | Où elle est écrite | Où corriger |
|---|---|---|
/wp-content/uploads/ | Dans le contenu d’un article ou d’une page, insérée avant le passage en HTTPS | En base de données, par un remplacement global |
| Le domaine du site lui-même, sur toutes les pages | Dans les deux adresses de Réglages, Général | Réglages, Général, ou wp-config.php si les constantes sont définies |
/wp-content/themes/ | Dans le thème, par exemple un logo ou une feuille de style codés en dur | Réglages du thème, ou son éditeur si l’adresse est dans le code |
/wp-content/plugins/ | Dans les réglages d’une extension, d’un constructeur de pages ou d’un curseur d’images | Réglages de l’extension, et remplacement global dans toutes les tables |
| Un domaine externe | Un script, une police, une iframe ou une vidéo intégrés à la main | Remplacer par la version HTTPS du service, ou retirer la ressource |
Corriger le contenu mixte à la source, dans la base de données
Pour corriger un contenu mixte durablement, remplacez les adresses http:// par https:// dans la base de données, après une sauvegarde. Les étapes suivent l’ordre qui évite de refaire le travail.
- Sauvegardez le site. Un remplacement global touche toute la base. La méthode complète, fichiers et base, est dans notre guide sur la sauvegarde d’un site WordPress.
- Vérifiez les deux adresses du site. Dans Réglages, Général, les champs « Adresse WordPress (URL) » et « Adresse du site (URL) » doivent commencer par
https://. Si vous venez de déplacer le site, la procédure est détaillée dans notre guide pour migrer un site WordPress local en ligne. - Remplacez les adresses dans le contenu. Utilisez WP-CLI ou l’extension Better Search Replace, décrits juste après. Lancez toujours une simulation avant la modification réelle.
- Videz les caches. Une extension de cache ou un CDN peut continuer à servir l’ancienne version de la page, avec ses adresses en HTTP.
- Rechargez la page et rouvrez la console. Elle ne doit plus signaler de ressource en HTTP. Testez une page par type de gabarit.
Avec WP-CLI, en ligne de commande
La commande suivante remplace l’adresse en HTTP par celle en HTTPS. Remplacez example.fr par votre domaine. L’option --dry-run n’enregistre rien et affiche le nombre de remplacements prévus.
wp search-replace 'http://example.fr' 'https://example.fr' --skip-columns=guid --dry-run
Si le rapport est cohérent, relancez la même commande sans --dry-run. D’après la documentation de WP-CLI, la commande gère les données sérialisées, et l’option --skip-columns=guid évite de toucher à la colonne des identifiants, que WordPress demande de laisser intacte.
Avec Better Search Replace, sans ligne de commande
L’extension s’ouvre dans Outils, Better Search Replace. Saisissez l’adresse en HTTP dans le champ de recherche et celle en HTTPS dans « Replace with », sélectionnez toutes les tables, laissez la simulation cochée, puis lancez. Si les chiffres sont cohérents, décochez la simulation et relancez. Sa fiche officielle propose cette simulation et précise qu’une mauvaise saisie peut abîmer la base, d’où la sauvegarde de la première étape.
Sélectionner toutes les tables compte : les constructeurs de pages et les extensions rangent aussi leurs adresses dans la base, hors des articles.
Ce que WordPress corrige déjà tout seul, et ce qu’il laisse
Depuis WordPress 5.7, le passage à HTTPS se fait en partie sans intervention. L’état HTTPS de Santé du site, dans le menu Outils, propose un bouton qui bascule les deux adresses du site vers HTTPS d’un seul clic quand l’hébergement le permet. Il ne s’affiche que si l’environnement gère déjà HTTPS.
Le bouton ne modifie pas vos articles. WordPress réécrit les adresses non sécurisées au moment de l’affichage, sur le contenu, les extraits, les widgets texte et le CSS additionnel, d’après l’équipe du noyau. Le fichier du thème, les réglages d’une extension et les ressources externes restent hors de son périmètre.
Cette réécriture suppose que l’adresse du site et celle de WordPress aient le même domaine, et les constantes WP_HOME ou WP_SITEURL dans wp-config.php bloquent le bouton. L’équipe du noyau précise que la migration en un clic ne couvre pas les configurations où les deux adresses diffèrent.
Un site qui affiche « www » d’un côté et pas de l’autre est donc un cas à vérifier.
Pourquoi l’avertissement revient après la correction ?
Quand la console signale encore une ressource après un remplacement global, cherchez dans cette liste avant de relancer quoi que ce soit.
- Le cache sert une page enregistrée avant la correction. Videz le cache de l’extension, du CDN et du navigateur, puis rechargez.
- Une ressource externe n’existe pas en HTTPS. Le service ne la propose qu’en HTTP : remplacez-la par un équivalent ou retirez-la, aucun réglage chez vous ne la réparera.
- Une adresse codée en dur dans le thème ou une extension reste en HTTP, parce qu’elle n’est pas dans la base. Cherchez une option dans les réglages, sinon signalez-le à l’auteur. Modifier le fichier d’une extension à la main ne tient pas, la prochaine mise à jour l’écrase.
- Un nom de domaine différent, avec ou sans « www », a échappé au remplacement, qui ne vise que l’adresse saisie. Relancez-le pour la seconde variante.
- Une ressource appelée par son adresse IP. MDN indique que les navigateurs bloquent ces requêtes au lieu de les mettre à niveau.
Rediriger tout le trafic de http:// vers https://
La redirection et la correction du contenu mixte sont deux réglages distincts. La première envoie le visiteur de l’adresse en HTTP vers celle en HTTPS. La seconde corrige les adresses écrites dans la page. Vous avez besoin des deux.
Sur un hébergement qui lit le fichier .htaccess, la documentation d’Hostinger propose d’ajouter ces lignes en bas du fichier, à la racine du site. Chez un hébergeur sans .htaccess, la redirection se règle dans l’espace client ou avec l’assistance.
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
La documentation d’Hostinger ajoute une ligne qui envoie l’en-tête Content-Security-Policy avec la valeur upgrade-insecure-requests. Cet en-tête demande au navigateur de remonter lui-même toutes les requêtes en HTTP, d’après MDN. Servez-vous-en comme d’un dépannage, pas comme d’une correction : une ressource qui n’existe pas en HTTPS ne se chargera pas, et la bonne adresse reste à écrire dans le site.
Extension ou remplacement en base, quelle méthode choisir ?
Corrigez en base d’abord, et gardez l’extension pour les ressources que la base ne contient pas. Voici les options les plus citées, avec ce que leur fiche officielle annonce.
| Méthode | Ce qu’elle fait | Limite annoncée | Quand l’utiliser |
|---|---|---|---|
| Remplacement en base (WP-CLI, Better Search Replace) | Réécrit les adresses enregistrées, simulation possible | Ne touche pas aux fichiers du thème ni aux ressources externes | Toujours en premier |
| SSL Insecure Content Fixer | Corrige l’affichage à la volée, avec cinq niveaux (Simple, Content, Widgets, Capture, Capture All), plus de 100 000 installations actives | Ne modifie pas les adresses enregistrées | Quand des adresses échappent à la base, comme une extension qui les génère |
| Really Simple Security (ex Really Simple SSL) | Redirection 301, plus de 3 millions d’installations actives | La fiche place le « Mixed Content Scan & Fixer » dans la version Pro | Pour la redirection, sans compter sur la version gratuite pour le contenu mixte |
En-tête upgrade-insecure-requests | Demande au navigateur de remonter les requêtes en HTTP | Échoue si la ressource n’existe pas en HTTPS | En dépannage, le temps de corriger |
Ce tableau tranche sur une idée : une extension masque l’adresse fautive à l’affichage, le remplacement en base la supprime. Plusieurs tutoriels recommandent encore Really Simple SSL pour corriger le contenu mixte, vérifiez donc ce que la version gratuite inclut avant de l’installer pour cela.
Sources : fiches de SSL Insecure Content Fixer, Really Simple Security et Better Search Replace sur wordpress.org.
Questions fréquentes
Pourquoi l’avertissement n’apparaît-il que sur certaines pages ?
Parce que la ressource fautive n’est présente que dans ces pages, dans un article, un gabarit ou un widget donné. La console ne liste que les ressources de la page ouverte, il faut donc la consulter page par page ou par type de gabarit.
Contenu mixte ou erreur de certificat, comment les distinguer ?
Une erreur de certificat bloque l’accès au site avec un écran d’avertissement, et se règle chez l’hébergeur qui émet le certificat. Le contenu mixte laisse la page s’ouvrir, avec un cadenas barré ou une mention « non sécurisé », et se règle dans le site.
Faut-il écrire les adresses des images en relatif ?
MDN accepte les deux : une adresse en https:// ou une adresse relative, qui reprend le protocole de la page. Dans tous les cas, évitez d’écrire http:// en dur.
Que refaire après un déménagement du site ?
Contrôlez les deux adresses de Réglages, Général, puis relancez un remplacement des anciennes adresses dans la base. Le guide pour migrer un site WordPress détaille ce remplacement, y compris pour les données sérialisées.
Notre verdict
Pour régler un contenu mixte WordPress en HTTPS, procédez dans cet ordre : sauvegarde, remplacement des adresses en base avec simulation, vidage des caches, puis contrôle dans la console. Le remplacement en base règle les cas où les adresses viennent d’articles écrits avant le certificat.
Gardez une extension pour les adresses que la base ne contient pas, et l’en-tête upgrade-insecure-requests comme dépannage seulement. Ne vous arrêtez pas à la redirection : sans correction des adresses, le cadenas reste barré.



