Erreur « was loaded over HTTPS but requested an insecure stylesheet » sur WordPress : causes et solutions

Sommaire de l'article

Introduction

Si vous avez déj à rencontré l’erreur « The page was loaded over HTTPS, but requested an insecure stylesheet » sur votre site WordPress, vous savez à quel point elle peutêtre déroutante et frustrante. Ce message indique qu’un fichier CSS (feuille de style) est chargé via une URL non sécurisée en HTTP alors que la page, elle, est servie en HTTPS. Il s’agit d’un cas typique de contenu mixte.

Cette incompatibilité a plusieurs conséquences possibles :

le navigateur peut bloquer complètement la feuille de style, entraînant un affichage cassé du site ;
un avertissement de sécurité peut apparaître dans la barre d’adresse, faisant fuir les visiteurs ;
les moteurs de recherche peuvent considérer le site comme moins sûr, ce qui peut nuire à votre référencement naturel ;
d’éventuels risques de sécurité accrus (interception ou modification de ressources non chiffrées).

Dans cet article, nous allons expliquer en détail ce qu’est cette erreur de contenu mixte, pourquoi elle apparaît spécifiquement pour les feuilles de style sur WordPress, et surtout comment la corriger définitivement à l’aide de méthodes fiables etéprouvées.

Concepts clés à connaître

Pour résoudre efficacement l’erreur « insecure stylesheet WordPress », il est essentiel de comprendre quelques notions fondamentales liées à la sécurité web et à la configuration de WordPress.

HTTPS vs HTTP

HTTP (Hypertext Transfer Protocol) est le protocole historique utilisé pour transférer les pages web entre un serveur et un navigateur. Il ne chiffre pas les données : toute information transmise (mots de passe, formulaires, cookies de session, etc.) peut potentiellementêtre interceptée.

HTTPS (Hypertext Transfer Protocol Secure) est la version sécurisée d’HTTP. Elle ajoute une couche de chiffrement via un certificat SSL/TLS, ce qui permet :

de chiffrer les donnéeséchangées entre le navigateur et le serveur ;
d’authentifier le serveur (le visiteur sait à qui il parle) ;
de garantir l’intégrité des données (elles ne peuvent pasêtre modifiées en cours de route sansêtre détectées).

Les navigateurs modernes affichent généralement un cadenas dans la barre d’adresse lorsque la page est correctement servie en HTTPS et que toutes les ressources intégrées respectentégalement ce protocole.

CSS (Cascading Style Sheets)

Les feuilles de style CSS définissent l’apparence visuelle de votre site : couleurs, typographies, positionnement deséléments, mise en page responsive, etc. Sur WordPress, elles sont généralement chargées à partir de fichiers situés dans :

le thème actuel (par exemple /wp-content/themes/nom-du-theme/style.css) ;
les plugins installés (fichiers CSS propres à chaque extension) ;
un CDN ou un sous-domaine statique (par exemple https://static.example.com/style.css).

Lorsqu’une feuille de style est appelée via une URL en http:// alors que la page est en https://, le navigateur considère cette ressource comme non sécurisée et déclenche un avertissement de contenu mixte.

Mixed Content (contenu mixte)

Le contenu mixte apparaît lorsqu’une page chargée en HTTPS inclut une ou plusieurs ressources via HTTP :

feuilles de style CSS ;
scripts JavaScript ;
images, vidéos, iframes ;
polices de caractères, fichiers de fonts, etc.

On distingue souvent :

contenu mixte passif (images, vidéos) : parfois seulement signalé comme « non entièrement sécurisé » ;
contenu mixte actif (scripts, feuilles de style, iframes) : fréquemment bloqué par défaut car il peut impacter le comportement de la page.

Une feuille de style chargée en HTTP alors que la page est en HTTPS est considérée comme du contenu mixte actif : le navigateur peut donc décider de la bloquer totalement.

Certificat SSL/TLS

Un certificat SSL/TLS est un fichier numérique installé sur le serveur, permettant de chiffrer leséchanges entre le navigateur et votre site. Il est indispensable pour utiliser HTTPS. Dans WordPress, la simple installation du certificat ne suffit pas : les URL du site et les liens internes doiventégalementêtre correctement configurés pour utiliser https://.

Pourquoi cette erreur apparaît sur WordPress

Lorsque votre site WordPress utilise HTTPS mais que certaines feuilles de style CSS sont encore chargées via HTTP, vous obtenez un message du type :

Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure stylesheet 'http://example.com/wp-content/themes/mon-theme/style.css'.

Cette situation affaiblit la sécurité globale du site, peut faire disparaître le cadenas dans la barre d’adresse et réduire la confiance des utilisateurs. Elle peutégalement avoir un effet négatif sur le classement SEO, car les moteurs de recherche valorisent de plus en plus les sites entièrement sécurisés.

Principales causes de l’erreur « insecure stylesheet » sur WordPress

Pour corriger durablement cette erreur, il est crucial d’identifier d’abord son origine. Sur WordPress, les causes les plus fréquentes sont les suivantes.

1. Migration HTTP → HTTPS incomplète

Le scénario classique est le suivant :

vous avez installé un certificat SSL sur votre hébergement ;
vous avez activé l’option « forcer HTTPS » dans votre panneau d’hébergement ou via un plugin ;
mais certaines anciennes URL en HTTP restent présentes dans la base de données ou dans les fichiers de votre thème / plugins.

Par exemple, votre site charge encore une feuille de style via http://example.com/wp-content/themes/mon-theme/style.css au lieu de https://example.com/wp-content/themes/mon-theme/style.css.

2. Thèmes ou plugins mal codés (URLs absolues en HTTP)

Certains thèmes ou plugins appellent leurs ressources avec des URLs absolues en HTTP plutôt qu’en HTTPS ou en URLs relatives. Exemples :

utilisation de fonctions PHP qui « forcent » http:// dans les chemins des styles ou scripts.

Si le thème ou le plugin n’est pas régulièrement mis à jour, ces liens en HTTP peuvent persister longtemps après le passage du site en HTTPS.

3. Widgets, constructeurs de pages et shortcodes

Les page builders (Elementor, WPBakery, etc.), les widgets personnalisés ou certains shortcodes peuvent contenir des liens absolus en HTTP intégrés directement dans le contenu. Lorsqu’ils pointent vers des CSS hébergés sur un sous-domaine ou un domaine externe non sécurisé, ils génèrentégalement du contenu mixte.

4. Ressources externes non sécurisées

Il arrive qu’un site WordPress charge des feuilles de style hébergées sur :

un CDN (Content Delivery Network) ;
un domaine tiers (bibliothèques CSS, frameworks, polices, etc.) ;
un sous-domaine non configuré en HTTPS.

Si ces ressources externes ne sont disponibles qu’en HTTP, le navigateur les considère comme insecure stylesheet, même si votre propre domaine principal est parfaitement configuré en HTTPS.

5. Mauvaise configuration des URLs WordPress

Dans le tableau de bord WordPress, les champs :

Adresse web de WordPress (URL) ;
Adresse web du site (URL)

doivent impérativementêtre renseignés en https:// après la mise en place du certificat SSL. Si ces champs restent en http://, WordPress continuera à générer des liens internes en HTTP, y compris pour les feuilles de style.

Bonnes pratiques pouréviter l’erreur « insecure stylesheet »

Pour prévenir et corriger l’erreur « was loaded over HTTPS but requested an insecure stylesheet » sur WordPress, il est recommandé d’appliquer une série de bonnes pratiques techniques.

1. Identifier précisément toutes les ressources non sécurisées

La premièreétape consiste à détecter toutes les feuilles de style (et autres ressources) encore chargées en HTTP. Pour cela, vous pouvez utiliser :

Les outils de développement du navigateur (Chrome, Firefox, Edge) :
- ouvrez la console (généralement F12) ;
- allez dans l’onglet « Console » ou « Réseau » ;
- recherchez les avertissements de type Mixed Content ou insecure stylesheet.
Why No Padlock? : un service en ligne ou une extension de navigateur qui analyse une page donnée et liste les ressources non sécurisées chargées en HTTP.
Screaming Frog SEO Spider : un outil d’audit technique qui peut repérer les liens en HTTP dans le code source de vos pages.

Ces outils vous indiqueront les URLs précises des fichiers CSS problématiques et la page depuis laquelle ils sont appelés, ce qui permet de cibler vos corrections.

2. Mettre à jour les URLs du site en HTTPS

Assurez-vous que la configuration de base de votre site WordPress est correcte :

dans le tableau de bord, allez dans Réglages > Général ;
vérifiez que les champs Adresse web de WordPress (URL) et Adresse web du site (URL) commencent bien par https:// ;
si nécessaire, remplacez http://votre-site.com par https://votre-site.com ;
enregistrez les modifications.

Cetteétape est indispensable pour que WordPress génère automatiquement ses liens internes (y compris ceux des styles et scripts) en HTTPS.

3. Remplacer les liens HTTP par leurséquivalents HTTPS

Une fois les ressources non sécurisées identifiées, remplacez systématiquement leurs URLs en http:// par des URLs en https://. Par exemple :

remplacez http://example.com/styles.css par https://example.com/styles.css ;
vérifiez que toutes les images, scripts, polices et feuilles de style utilisentégalement le protocole HTTPS.

Sur un petit site, cette opération peutêtre effectuée manuellement dans :

les articles et pages (éditeur de blocs ouéditeur classique) ;
les widgets ;
les fichiers du thème enfant (par exemple header.php, functions.php) ;
les réglages des plugins qui permettent de saisir des URLs personnalisées.

Sur un site plus volumineux, vous pouvez utiliser un plugin de recherche-remplacement dans la base de données pour convertir en masse toutes les anciennes URLs HTTP en HTTPS. Veillez toutefois à effectuer une sauvegarde complète de votre site avant ce type d’opération.

4. Utiliser des URLs relatives lorsque c’est pertinent

Dans certains cas, l’utilisation d’URLs relatives peut simplifier la gestion des liens et prévenir les erreurs de protocole. Par exemple, au lieu d’écrire :

vous pouvez recourir à une URL relative au domaine :

Ainsi, c’est la configuration globale du site (HTTP ou HTTPS) qui détermine le protocole utilisé. Cette approche doit cependantêtre maniée avec précaution et de préférence via le thème enfant, afin de ne pas perdre vos modifications lors des mises à jour.

5. Héberger les fichiers CSS sur un domaine sécurisé

Si vous hébergez vos fichiers CSS sur un sous-domaine ou un CDN, assurez-vous que :

le certificat SSL est correctement installé sur ce sous-domaine ou ce CDN ;
les URLs des feuilles de style pointent vers https:// et non http:// ;
toutes les configurations de cache ou de CDN respectent bien le HTTPS (redirections, règles de cache, etc.).

Un CDN mal configuré peutêtre à l’origine de nombreux avertissements de contenu mixte sur un site WordPress.

6. Choisir des thèmes et plugins de qualité

Pour limiter les risques d’erreurs « insecure stylesheet », privilégiez des thèmes et plugins régulièrement mis à jour, codés selon les bonnes pratiques WordPress. Vérifiez notamment que :

les feuilles de style sont chargées via les fonctions natives (wp_enqueue_style) ;
les URLs ne sont pas codées en dur avec http:// ;
les développeurs prennent explicitement en charge le HTTPS.

En cas de doute, vous pouvez consulter la documentation ou le support du thème / plugin pour vérifier sa compatibilité HTTPS.

Outils et plugins utiles pour corriger le contenu mixte sur WordPress

Pour gagner du temps et fiabiliser la correction des erreurs « was loaded over HTTPS but requested an insecure stylesheet », il est possible d’utiliser des plugins spécialisés et divers outils d’analyse.

Plugins de correction automatique de contenu mixte

Plusieurs extensions WordPress sont conçues pour détecter et corriger automatiquement les ressources non sécurisées :

Really Simple SSL :
- détecte automatiquement la présence d’un certificat SSL sur votre site ;
- force le chargement du site en HTTPS ;
- corrige de nombreuses références HTTP dans le contenu et les scripts.
SSL Insecure Content Fixer :
- cible spécifiquement les problèmes de contenu mixte (images, scripts, feuilles de style) ;
- propose plusieurs niveaux de correction (simple, contenu, widgets, capture totale, etc.) ;
- permet de résoudre les erreurs « insecure stylesheet » sans modifier manuellement chaque fichier.

Ces plugins analysent le contenu généré par WordPress et réécrivent les URLs en HTTPS lorsque c’est possible. Ils constituent souvent la solution la plus rapide pour les utilisateurs non techniques.

Outils d’audit et de diagnostic

En complément, plusieurs outils permettent de vérifier la bonne mise en place du HTTPS et d’identifier les ressources problématiques :

Google Search Console :
- signale certains problèmes de sécurité et de compatibilité ;
- permet de vérifier que les versions HTTPS de vos URLs sont correctement indexées.
Screaming Frog SEO Spider :
- scanne l’ensemble de votre site ;
- permet de filtrer les URLs contenant http:// ;
- aide à repérer les liens et ressources non sécurisés.
Why No Padlock? :
- analyse une URL spécifique ;
- liste leséléments qui empêchent l’affichage du cadenas (dont les stylesheets en HTTP).

Méthodes techniques avancées pour sécuriser définitivement le chargement des stylesheets

Pour rendre la correction plus robuste et pérenne, vous pouvez mettre en place quelques réglages techniques supplémentaires au niveau du serveur ou de la configuration WordPress.

1. Forcer la redirection HTTP → HTTPS via .htaccess (Apache)

Si votre site est hébergé sur un serveur Apache, vous pouvez ajouter une règle de réécriture dans le fichier .htaccess à la racine de votre installation WordPress afin de forcer toutes les requêtes HTTP àêtre redirigées vers HTTPS.

Une fois cette redirection en place, même si un lien en HTTP subsiste, le serveur renverra automatiquement l’utilisateur vers la version HTTPS. Cela ne remplace pas le nettoyage des URLs dans la base de données, mais réduit considérablement l’impact des oublis.

2. Utiliser une directive de politique de sécurité (CSP)

Sur certains serveurs, il est possible d’ajouter une directive de type :

Content-Security-Policy: upgrade-insecure-requests

Cette politique demande au navigateur de tenter de convertir automatiquement les requêtes HTTP en HTTPS lorsque c’est réalisable. Cette mesure ne corrigera pas tous les cas (notamment si la ressource n’existe pas en HTTPS), mais elle peut aider à réduire le nombre d’avertissements de contenu mixte, y compris pour les feuilles de style.

3. Nettoyer la base de données WordPress

Pouréradiquer les anciennes références en HTTP, il peutêtre nécessaire de réaliser un remplacement massif dans la base de données :

cherchez toutes les occurrences de http://votre-site.com ;
remplacez-les par https://votre-site.com.

Cela inclut :

les contenus des articles et pages ;
les métadonnées des plugins ;
les options stockées en base (réglages de thème, widgets, etc.).

Cette opération doitêtre réalisée avec prudence, idéalement par une personne expérimentée ou après une sauvegarde complète, afin d’éviter toute corruption de données.

Impact de l’erreur « insecure stylesheet » sur l’expérience utilisateur et le SEO

Au-del à de la simple dimension technique, l’erreur « was loaded over HTTPS but requested an insecure stylesheet » a un impact réel sur l’expérience de vos visiteurs et sur la performance globale de votre site.

1. Affichage cassé et perte de crédibilité

Si le navigateur bloque la feuille de style incriminée, votre site peut se retrouver :

sans mise en forme CSS (texte brut, éléments désalignés) ;
avec un design partiel (certains blocs correctement stylés, d’autres non) ;
avec des menus ou des formulaires difficilement utilisables sur mobile.

Un visiteur qui arrive sur une page au design cassé est beaucoup plus susceptible de quitter le site immédiatement, ce qui augmente le taux de rebond et nuit indirectement au référencement.

2. Avertissements de sécurité dans le navigateur

En présence de contenu mixte, certains navigateurs affichent :

un cadenas barré ou grisé ;
un message d’avertissement dans la console de sécurité ;
une indication « Connexion non totalement sécurisée ».

Ces signaux peuvent dissuader les utilisateurs de remplir un formulaire de contact, de s’abonner à une newsletter ou de finaliser un achat sur une boutique en ligne.

3. Effets sur le référencement naturel

Les moteurs de recherche tiennent compte de la sécurité des sites dans leurs critères de classement. Un site dont le HTTPS est mal implémenté et qui présente de nombreux avertissements de contenu mixte peutêtre considéré comme :

moins fiable ;
moins respectueux de la confidentialité des utilisateurs ;
moins conforme aux bonnes pratiques techniques.

Corriger définitivement les erreurs « insecure stylesheet » contribue donc non seulement à sécuriser votre site, mais aussi à optimiser sa visibilité dans les résultats de recherche.

Étapes pratiques : comment corriger l’erreur sur votre site WordPress

Voici un récapitulatif opérationnel des actions à mener pour résoudre l’erreur « was loaded over HTTPS but requested an insecure stylesheet » sur WordPress.

Étape 1 : Vérifier la configuration HTTPS de base

Assurez-vous que votre certificat SSL/TLS est valide et correctement installé sur votre hébergement.
Dans Réglages > Général, vérifiez que les URLs de WordPress et du site commencent par https://.
Si votre hébergeur le propose, activez l’option de redirection automatique HTTP → HTTPS.

Étape 2 : Identifier les feuilles de style non sécurisées

Ouvrez votre site dans un navigateur récent (Chrome, Firefox, Edge).
Accédez aux outils de développement (F12), puis à la console.
Rechargez la page et recherchez les messages Mixed Content: The page at 'https://…' was loaded over HTTPS, but requested an insecure stylesheet 'http://…'.
Notez précisément les URLs des stylesheets incriminés et les fichiers ou pages qui les appellent.

Étape 3 : Corriger les liens au niveau du thème et des plugins

Si la ressource vient du thème, utilisez un thème enfant pour modifier en toute sécurité les fichiers concernés (par exemple functions.php, header.php) et remplacez les URLs en HTTP par HTTPS ou par des URLs relatives.
Si la ressource vient d’un plugin, vérifiez dans ses réglages s’il est possible de corriger l’URL. Si ce n’est pas le cas, envisagez :
- de mettre à jour le plugin ;
- de contacter l’éditeur ;
- de chercher une alternative compatible HTTPS si le problème persiste.

Étape 4 : Nettoyer la base de données (si nécessaire)

Identifiez les anciennes URLs en http://votre-site.com qui pourraient encoreêtre stockées dans vos contenus.
Effectuez une sauvegarde complète de la base de données.
Procédez à un remplacement contrôlé des anciennes URLs HTTP par leurséquivalents HTTPS.

Étape 5 : Utiliser un plugin de correction de contenu mixte

Installez et activez un plugin dédié à la gestion du HTTPS (par exemple un plugin de correction de contenu mixte ou de gestion SSL).
Configurez-le pour qu’il détecte et corrige les ressources chargées en HTTP (scripts, stylesheets, médias).
Testez plusieurs niveaux de correction si l’extension le propose, en veillant à l’impact sur les performances.

Étape 6 : Tester, purger les caches et valider

Videz le cache de votre navigateur.
Si vous utilisez un plugin de cache ou un CDN, purgezégalement leurs caches.
Rechargez plusieurs pages de votre site, en particulier celles qui posaient problème.
Vérifiez dans la console du navigateur que les avertissements de contenu mixte ont disparu.

Bonnes pratiques à long terme pour un WordPress 100 % HTTPS

Une fois l’erreur corrigée, quelques habitudes simples permettent d’éviter qu’elle ne réapparaisse à l’avenir.

1. Toujours utiliser des URLs en HTTPS

Lors de l’ajout de nouvelles images, scripts, feuilles de style, iframes ou ressources externes, veillez systématiquement à utiliser https:// dans vos liens, lorsque le serveur distant le permet.

2. Tenir à jour thèmes, plugins et WordPress

Les mises à jour régulières de WordPress, des thèmes et des plugins incluent souvent des corrections liées à la sécurité et à la gestion du HTTPS. Unécosystème à jour réduit fortement la probabilité de rencontrer des erreurs « insecure stylesheet » dûes à du code obsolète.

3. Surveiller régulièrement l’état de sécurité du site

Planifiez périodiquement :

un passage dans les outils de développement du navigateur pour vérifier l’absence d’avertissements de contenu mixte ;
un scan avec un outil d’audit technique pour repérer de nouvelles URLs en HTTP ;
une vérification de la validité du certificat SSL/TLS et de sa date d’expiration.

4. Documenter les procédures internes

Si plusieurs personnes interviennent sur votre site (rédacteurs, intégrateurs, développeurs), il est utile de documenter quelques règles simples :

ne jamais coller d’URL en http:// vers une ressource qui existe en https:// ;
privilégier l’ajout de CSS via les méthodes standard de WordPress plutôt que par des scripts externes en HTTP ;
vérifier l’apparitionéventuelle d’avertissements de sécurité après chaque ajout de plugin ou de thème.

Conclusion

L’erreur « was loaded over HTTPS but requested an insecure stylesheet » sur WordPress est un symptôme typique de contenu mixte : une page sécurisée tente de charger une feuille de style via HTTP. Même si ce problème peut sembler purement technique, il impacte directement la sécurité perçue de votre site, son apparence visuelle et, à terme, ses performances SEO.

En comprenant les concepts de base (HTTPS, SSL/TLS, contenu mixte), en identifiant précisément les ressources en cause, puis en appliquant des corrections durables (mise à jour des URLs, configuration correcte de WordPress, redirections au niveau serveur, plugins adaptés), vous pouvezéliminer définitivement ces avertissements et offrir à vos visiteurs une expérience fiable, cohérente et sécurisée sur l’ensemble de votre site WordPress.