Contenu mixte WordPress : cause et correctif en 3 étapes

Le contenu mixte WordPress vient presque toujours d’adresses en http:// restées dans la base de données après le passage en HTTPS : la page est servie en HTTPS, mais une image, un script ou une feuille de style est encore appelé en HTTP, alors le navigateur barre le cadenas ou bloque le fichier. Le correctif tient en trois étapes : mettre les deux adresses du site en https:// dans Réglages → Général, remplacer http://ton-domaine.fr par https://ton-domaine.fr dans la base avec wp search-replace (ou un plugin équivalent), puis vérifier dans la console du navigateur qu’il ne reste plus rien. Le reste de cet article détaille chaque étape et les cas particuliers (Cloudflare, proxy, scripts tiers).

Contenu mixte (mixed content) : définition

Le contenu mixte (en anglais mixed content) désigne une page chargée de façon sécurisée, en HTTPS, qui utilise des ressources récupérées en HTTP ou par un autre protocole non sécurisé (MDN Web Docs). Le certificat SSL n’est pas en cause : il chiffre bien la page. Ce sont les fichiers appelés par la page qui ne passent pas par le canal chiffré.

Sur WordPress, ces adresses en http:// viennent en général de quatre endroits :

• Les contenus en base : articles, pages et widgets enregistrés avant le passage en HTTPS gardent les URL absolues de l’époque, y compris celles des images de la médiathèque.
• Les options de thèmes et de constructeurs de pages : elles stockent souvent des URL complètes, parfois sous forme de données sérialisées.
• Les scripts tiers : un ancien code de suivi, une police ou un widget collé avec un lien en http://.
• Les adresses du site elles-mêmes, si l’une des deux est encore en http:// dans les réglages.

Contenu mixte actif ou passif : bloqué ou simplement averti ?

On lit souvent « contenu mixte actif » et « contenu mixte passif ». C’est l’ancienne terminologie, que MDN signale comme dépréciée :

• Contenu mixte actif désignait les ressources capables de modifier le reste de la page (scripts, feuilles de style). Elles étaient bloquées.
• Contenu mixte passif désignait les ressources qui ne peuvent pas modifier la page (images, vidéos, audio). Elles étaient seulement signalées.

La spécification actuelle du W3C parle plutôt de contenu « upgradable » et « blockable » (MDN Web Docs, Mixed content) :

En pratique sur WordPress : une image en http:// est souvent rattrapée par le navigateur, mais un script ou une feuille de style en http:// est bloqué, et c’est là qu’une mise en page casse ou qu’un formulaire cesse de fonctionner. Point à retenir : une image appelée avec srcset ou dans une balise <picture> fait partie de la liste bloquée, pas de la liste corrigée automatiquement.

Trouver le contenu mixte avec la console du navigateur

Avant de toucher à la base, identifie précisément les fichiers en cause. MDN recommande de parcourir le site en surveillant la console des outils de développement, qui affiche un avertissement chaque fois qu’une ressource en HTTP est mise à niveau ou bloquée, avec son adresse (MDN Web Docs).

1. Ouvre la page au cadenas barré dans Chrome, Firefox ou Edge.
2. Ouvre les outils de développement (touche F12 sous Windows, ou clic droit puis « Inspecter ») et va dans l’onglet Console.
3. Recharge la page et relève les adresses signalées comme contenu mixte.
4. Range chaque adresse dans une de ces trois cases :
   • http://ton-domaine.fr/... : elle vient de ta base, le rechercher-remplacer la corrigera.
   • http://un-autre-domaine.com/... : elle vient d’un plugin, du thème ou d’un code collé à la main. Il faut trouver le réglage ou le fichier qui l’appelle.
   • Rien dans la console mais le cadenas reste barré : vide le cache (plugin, serveur, CDN) et recharge, l’ancienne version de la page est peut-être encore servie.

Teste plusieurs types de pages (accueil, article, page avec formulaire, fiche produit) : le contenu mixte se cache souvent dans un seul gabarit.

Comment corriger le contenu mixte dans WordPress

Fais une sauvegarde complète (fichiers et base de données) avant de commencer. L’étape 2 modifie la base en profondeur.

Étape 1 : passer les URL du site en https dans Réglages → Général

Dans l’administration, ouvre Réglages → Général et vérifie deux champs :

• Adresse web de WordPress (URL) : l’adresse du dossier qui contient les fichiers de WordPress ;
• Adresse web du site (URL) : l’adresse que tes visiteurs tapent pour arriver sur le site.

Les deux doivent commencer par https://. Corrige-les si besoin, puis clique sur Enregistrer les modifications. Si un champ est grisé, c’est que sa valeur est définie dans wp-config.php par les constantes WP_SITEURL et WP_HOME : il faut alors la modifier dans ce fichier (documentation WordPress, écran Réglages généraux).

define( 'WP_HOME', 'https://ton-domaine.fr' );
define( 'WP_SITEURL', 'https://ton-domaine.fr' );

Depuis WordPress 5.7, l’écran Outils → Santé du site propose un bouton pour passer le site en HTTPS quand l’hébergement le permet. Une fois la bascule faite, WordPress remplace à la volée les anciennes adresses http:// de ton domaine dans le contenu des articles, les extraits, les widgets texte et le CSS personnalisé, sans modifier la base (annonce de l’équipe WordPress, février 2021). C’est utile, mais cela ne couvre ni les options des thèmes ni les données des constructeurs de pages : l’étape 2 reste nécessaire.

Étape 2 : rechercher-remplacer les URL en http dans la base

C’est la correction principale : toutes les occurrences de http://ton-domaine.fr en base deviennent https://ton-domaine.fr. Un simple REPLACE() en SQL dans phpMyAdmin est déconseillé, car il casse les données sérialisées (des tableaux PHP enregistrés sous forme de texte, avec la longueur de chaque chaîne). Utilise un outil qui sait les traiter.

Avec WP-CLI (accès SSH), la commande officielle wp search-replace « gère intelligemment les données PHP sérialisées » et ne modifie pas les clés primaires (documentation WP-CLI). Lance d’abord un test à blanc :

wp search-replace 'http://ton-domaine.fr' 'https://ton-domaine.fr' --skip-columns=guid --dry-run

• --dry-run exécute toute l’opération et affiche le rapport, sans rien enregistrer.
• --skip-columns=guid laisse de côté la colonne guid, comme dans l’exemple de la documentation.
• Par défaut, la commande traite les tables déclarées par WordPress. --all-tables étend le remplacement à toutes les tables de la base, même sans le préfixe WordPress.

Si le nombre de remplacements annoncé te paraît cohérent, relance la même commande sans --dry-run. Pense à traiter aussi la variante http://www.ton-domaine.fr si ton site a déjà existé avec le www.

Sans accès SSH, le plugin gratuit Better Search Replace fait le même travail depuis Outils → Better Search Replace. Sa fiche annonce la prise en charge de la sérialisation sur toutes les tables, un mode test (dry run) qui indique combien de champs seront modifiés, et plus d’un million d’installations actives (fiche du plugin sur wordpress.org). Même méthode : test d’abord, remplacement ensuite, puis vide tous les caches.

Étape 3 : l’en-tête Content-Security-Policy upgrade-insecure-requests

Pour les adresses que tu ne peux pas corriger à la source (code d’un plugin, script tiers), la directive upgrade-insecure-requests de l’en-tête Content-Security-Policy demande au navigateur de traiter toutes les URL en HTTP du site comme si elles étaient en HTTPS, avant même d’envoyer la requête (MDN Web Docs, upgrade-insecure-requests) :

Content-Security-Policy: upgrade-insecure-requests;

Si tu ne peux pas ajouter d’en-tête côté serveur, la balise équivalente se place dans le <head> du thème :

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests" />

Deux limites, précisées par MDN : si la ressource n’existe pas en HTTPS, la requête échoue, sans retour au HTTP. Et les liens de navigation vers d’autres sites ne sont pas modifiés. C’est un filet de sécurité, pas un remplaçant de l’étape 2 : la base doit rester propre.

Après le correctif : rediriger tout le HTTP vers HTTPS

Une fois le contenu nettoyé, chaque adresse en http:// doit renvoyer vers sa version https:// avec une redirection permanente. La redirection 301 (Moved Permanently) désigne la réponse HTTP qui indique que la ressource a été déplacée définitivement, et les moteurs de recherche reportent alors les liens de l’ancienne URL vers la nouvelle (MDN Web Docs, 301). Les règles prêtes à copier pour Apache, Nginx et Cloudflare sont dans notre guide pour forcer le HTTPS et choisir entre www et non-www.

Contenu mixte WordPress derrière Cloudflare ou un proxy

Si ton site passe par Cloudflare, regarde le mode SSL/TLS choisi. En mode Flexible, la connexion est chiffrée entre le visiteur et Cloudflare, mais Cloudflare contacte ton serveur en HTTP. Cloudflare précise que ce mode peut provoquer des erreurs de contenu mixte, et une boucle de redirection si ton serveur redirige lui-même vers HTTPS. Il recommande alors les modes Full ou Full (strict) (documentation Cloudflare). Si la boucle est déjà là, suis notre article sur l’erreur ERR_TOO_MANY_REDIRECTS.

Derrière un proxy ou un répartiteur de charge, WordPress peut ne pas savoir que le visiteur est en HTTPS et générer des URL en http://. La documentation de WordPress donne ce code à placer dans wp-config.php (WordPress Advanced Administration, HTTPS) :

if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false )
    $_SERVER['HTTPS'] = 'on';

Récapitulatif : cause et correctif

FAQ