Protéger un dossier avec .htaccess : mot de passe, HTTPS et sécurité du site

Protéger un dossier avec .htaccess consiste, sur un hébergement Apache ou LiteSpeed, à ajouter une authentification par nom d’utilisateur et mot de passe, à empêcher la lecture directe du fichier .htaccess, à forcer l’utilisation de HTTPS et à limiter certains accès risqués. La méthode la plus courante est la protection de répertoire via Basic Auth, avec des mots de passe stockés dans un fichier .htpasswd. Point essentiel à retenir : Basic Auth ne chiffre pas les données à lui seul. Pour une utilisation réellement sûre, il doit toujours fonctionner avec un certificat SSL et une connexion HTTPS active. certificat SSL Hébergement Web Sécurisé

La sécurité d’un site web est souvent associée à des pare-feu complexes, à des solutions coûteuses ou à des extensions spécialisées. Pourtant, un fichier .htaccess bien configuré reste l’une des premières couches de défense les plus utiles, en particulier sur un hébergement mutualisé, un site WordPress, une application PHP sur mesure ou le site vitrine d’une petite entreprise. Avec ce fichier, vous pouvez protéger un espace d’administration par mot de passe, rediriger le trafic HTTP vers HTTPS, désactiver l’indexation des dossiers, bloquer l’accès à des fichiers sensibles, réduire le hotlinking et activer certains en-têtes de sécurité côté navigateur.

Dans ce guide, nous allons voir comment mettre en place une protection par mot de passe avec .htaccess, expliquer les commandes de sécurité les plus utilisées en conditions réelles et fournir des exemples que vous pourrez copier puis adapter à votre environnement. Les directives présentées conviennent surtout aux hébergements qui prennent en charge Apache mod_rewrite, mod_auth_basic et mod_headers. Les serveurs LiteSpeed étant largement compatibles avec Apache, la plupart de ces règles fonctionnent également sans modification. Avant toute intervention sur un site en production, sauvegardez toutefois votre fichier .htaccess et, si possible, testez les changements sur un sous-domaine ou un environnement de préproduction. Gestion de domaine Sauvegarde de site Web

Qu’est-ce qu’un fichier .htaccess et pourquoi est-il important pour la sécurité ?

.htaccess est un fichier de configuration local qui indique au serveur web comment se comporter pour un dossier donné et ses sous-dossiers. Lorsqu’il est placé à la racine du site, il influence généralement l’ensemble du site. Par exemple, un fichier .htaccess situé dans le dossier public_html contrôle les règles appliquées à la racine web de votre nom de domaine. Lorsqu’il est placé dans un sous-dossier, ses règles peuvent ne concerner que ce dossier et les chemins qui en dépendent.

Comme ce fichier permet de gérer des contrôles d’accès au niveau du serveur, certaines requêtes peuvent être bloquées avant même d’atteindre le code de l’application. Par exemple, si vous protégez un dossier admin par mot de passe, un attaquant devra passer l’authentification serveur avant d’accéder à WordPress, à votre panneau personnalisé ou à vos fichiers PHP. Cette approche réduit les tentatives de brute force et rend plus difficile l’exploitation de failles situées dans la couche applicative.

Les principaux avantages de .htaccess pour la sécurité sont les suivants :

• Définir des règles d’accès sans modifier le code de l’application.
• Protéger certains dossiers par nom d’utilisateur et mot de passe.
• Rediriger automatiquement les requêtes HTTP vers HTTPS.
• Désactiver l’affichage du contenu des répertoires et bloquer l’accès à des fichiers sensibles.
• Limiter le hotlinking afin d’éviter l’utilisation abusive de vos fichiers médias.
• Ajouter des en-têtes de sécurité pour rendre le comportement du navigateur plus sûr.
• Restreindre l’accès selon l’adresse IP, l’extension de fichier ou la méthode de requête.

Cela dit, .htaccess ne remplace pas une stratégie de sécurité complète. Il donne de très bons résultats lorsqu’il est associé à des logiciels à jour, une politique de mots de passe solide, des sauvegardes régulières, une infrastructure d’hébergement fiable, un WAF, une analyse anti-malware et un certificat SSL correctement installé. Sécurité de l'hébergement Sécurité WordPress

Logique de protection .htaccess : Basic Auth et .htpasswd

En français, on parle souvent de “chiffrer un dossier avec .htaccess” ou de “protéger un répertoire par mot de passe avec .htaccess”. En pratique, cette expression recouvre deux usages différents. Le premier consiste à demander un identifiant et un mot de passe avant d’ouvrir un dossier. Le second consiste à empêcher que le fichier .htaccess lui-même soit consultable depuis le web. Le premier usage repose sur Basic Auth ; le second sur des règles de restriction d’accès aux fichiers.

Avec Basic Auth, le fichier .htaccess contient la règle d’authentification, tandis que le fichier .htpasswd stocke les noms d’utilisateur et les mots de passe hachés. Le mot de passe ne doit jamais être conservé en clair. Sur les systèmes modernes, on utilise généralement bcrypt, Apache MD5 ou des méthodes de hachage basées sur SHA. L’approche la plus simple et la plus sûre consiste souvent à utiliser la fonction “répertoire protégé par mot de passe” ou “confidentialité du répertoire” de votre panneau d’hébergement, car ces outils placent en général le fichier .htpasswd au bon endroit et génèrent automatiquement le hash du mot de passe.

Une règle de protection par mot de passe peut ressembler à ceci :

AuthType Basic

AuthName Zone Protegee

AuthUserFile /home/utilisateur/.htpasswd

Require valid-user

Ces quatre lignes ont un rôle simple : le type d’authentification est défini sur Basic, le nom de la zone affiché par le navigateur est indiqué, le chemin serveur complet du fichier .htpasswd est fourni et seuls les utilisateurs valides sont autorisés à entrer. L’erreur la plus fréquente consiste à écrire une URL dans la ligne AuthUserFile. La bonne valeur n’est pas une adresse web, mais un chemin physique sur le serveur. Par exemple, https://exemple.com/.htpasswd est incorrect ; /home/utilisateur/.htpasswd correspond davantage au format attendu.

Où faut-il placer le fichier .htpasswd ?

Dans l’idéal, le fichier .htpasswd doit être placé en dehors de public_html. Ainsi, même en cas de mauvaise configuration du serveur, il ne pourra pas être appelé directement depuis le web. Par exemple, si votre site fonctionne dans /home/compte/public_html, il est plus sûr de placer .htpasswd dans /home/compte/.htpasswd, c’est-à-dire hors de la racine publique du site.

Côté permissions, une base de départ courante est 640 ou 644 pour .htpasswd, et 644 pour .htaccess. Certaines configurations serveur peuvent nécessiter des permissions différentes, mais les droits trop ouverts comme 777 représentent un risque de sécurité et ne doivent pas être utilisés pour ces fichiers.

Protéger un répertoire avec .htaccess, étape par étape

Les étapes ci-dessous conviennent particulièrement si vous souhaitez protéger un dossier admin, panel, test, staging, rapports ou un espace réservé à un client. Avant de commencer, téléchargez une copie de votre fichier .htaccess actuel. Un seul caractère mal placé peut provoquer une erreur 500 Internal Server Error.

1. Déterminer le dossier à protéger

Commencez par identifier précisément le répertoire à verrouiller. Si vous voulez protéger uniquement siteexemple.com/admin, vous pouvez placer le fichier .htaccess directement dans le dossier admin. Si vous souhaitez fermer temporairement tout le site et ne l’ouvrir qu’à des personnes autorisées, ajoutez plutôt la règle au fichier .htaccess situé à la racine.

2. Créer un utilisateur .htpasswd

Si votre panneau d’hébergement propose un outil de protection de répertoire par mot de passe, c’est généralement la solution la plus pratique. Si ce n’est pas le cas et que vous disposez d’un accès SSH, vous pouvez créer un utilisateur avec la commande htpasswd. La logique est la suivante : htpasswd -c /home/utilisateur/.htpasswd admin. Cette commande génère un mot de passe pour l’utilisateur admin et l’enregistre dans le fichier. Attention : lorsque vous ajoutez un nouvel utilisateur à un fichier existant, n’utilisez pas l’option -c, car elle peut recréer le fichier et écraser les utilisateurs déjà présents.

3. Ajouter la règle dans .htaccess

Dans le fichier .htaccess du dossier à protéger, ajoutez les lignes suivantes :

AuthType Basic

AuthName Panneau Administration

AuthUserFile /home/utilisateur/.htpasswd

Require valid-user

Enregistrez le fichier, puis ouvrez le dossier concerné dans votre navigateur. Si une fenêtre vous demande un nom d’utilisateur et un mot de passe, la protection est active. Si les identifiants sont corrects mais que la connexion est refusée, le chemin AuthUserFile est probablement incorrect ou les permissions du fichier .htpasswd empêchent le serveur de le lire.

4. Ne pas l’utiliser sans HTTPS

Basic Auth transmet les informations d’identification en Base64 ; ce n’est pas un chiffrement robuste. Si le trafic passe en HTTP, une personne capable d’écouter le réseau peut récupérer le nom d’utilisateur et le mot de passe. C’est pourquoi une protection .htaccess par mot de passe doit toujours être associée à une obligation HTTPS. Sur Hostragons, vous pouvez réduire ce risque en activant SSL, puis en ajoutant une règle de redirection HTTPS. installation de SSL Redirection HTTPS

Forcer HTTPS et gérer la redirection www

L’une des bases de la sécurité web consiste à rediriger tout le trafic vers HTTPS. Une fois le certificat SSL actif, vous pouvez ajouter une règle de ce type dans le fichier .htaccess situé à la racine :

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Cette règle transfère les requêtes arrivant en HTTP vers la même adresse et le même chemin en HTTPS. Le code 301 indique une redirection permanente, ce qui envoie également un signal cohérent aux moteurs de recherche. Si votre site est derrière un reverse proxy, un CDN ou un répartiteur de charge, l’état HTTPS peut toutefois être transmis via d’autres en-têtes. Dans ce cas, il vaut mieux appliquer la règle recommandée par votre hébergeur ou votre fournisseur CDN.

Le choix entre domaine avec www et sans www doit lui aussi être cohérent. Par exemple, si vous voulez envoyer tout le trafic vers la version sans www, vous pouvez utiliser une logique comme celle-ci :

RewriteEngine On

RewriteCond %{HTTP_HOST} ^www\.exemple\.com$ [NC]

RewriteRule ^(.*)$ https://exemple.com/$1 [L,R=301]

Remplacez exemple.com par votre propre nom de domaine. Si vous gérez en même temps HTTPS et www, évitez les chaînes de redirection. La configuration idéale amène l’utilisateur vers l’URL finale en une seule étape. Redirection de domaine redirection compatible SEO

Commandes .htaccess essentielles pour renforcer la sécurité d’un site

Le tableau ci-dessous résume les commandes de sécurité .htaccess les plus utilisées et les situations dans lesquelles elles sont pertinentes. Avant d’ajouter une directive, vérifiez votre configuration existante : certaines règles WordPress, Laravel ou propres à un CMS personnalisé peuvent entrer en conflit avec vos modifications.

Désactiver l’affichage du contenu des dossiers

Lorsqu’un dossier ne contient pas de fichier index.html, index.php ou autre fichier d’accueil par défaut, le serveur peut afficher la liste des fichiers qu’il contient. Cela peut exposer des sauvegardes, des images non destinées au public, des rapports temporaires ou d’anciens fichiers sources. Une directive simple permet de désactiver cette indexation :

Options -Indexes

Après l’ajout de cette ligne, les visiteurs ne peuvent plus lister le contenu du dossier. Les répertoires sans fichier index renverront généralement une réponse 403 Forbidden. Du point de vue de la sécurité, c’est le comportement recherché.

Bloquer l’accès à .htaccess et aux fichiers sensibles

Votre fichier .htaccess ne doit pas être consultable depuis le web. Apache le protège généralement par défaut, mais vous pouvez ajouter une couche de sécurité supplémentaire avec une logique de ce type :

<Files .htaccess>

Require all denied

</Files>

De la même manière, les fichiers comme .env, composer.json, composer.lock, config.php.bak, backup.sql ou database.sql doivent être fermés aux accès externes. Dans les applications Laravel, Symfony ou les développements PHP sur mesure, le fichier .env peut contenir le mot de passe de la base de données, des clés API et des paramètres SMTP. Une fuite de ce fichier peut aller jusqu’à la compromission complète du système.

Pour bloquer plusieurs fichiers ou extensions sensibles, vous pouvez appliquer une logique similaire :

<FilesMatch ^(\.env|composer\.(json|lock)|package\.json|yarn\.lock|.*\.sql|.*\.bak)$>

Require all denied

</FilesMatch>

Lorsque vous ajoutez ce type de règle, vérifiez que vous ne bloquez pas des fichiers statiques dont votre application a réellement besoin. Certains fichiers de vérification, de validation de domaine ou d’intégration peuvent être concernés par erreur, ce qui empêcherait des services tiers de fonctionner correctement.

Empêcher l’exécution de PHP dans certains dossiers

Les dossiers d’upload font partie des zones les plus ciblées par les attaquants. Si une application contrôle mal les fichiers envoyés par les utilisateurs, un fichier PHP malveillant peut être déposé dans un répertoire public. Empêcher l’exécution de PHP dans les dossiers destinés aux images, documents ou médias ajoute une barrière utile.

Vous pouvez placer un fichier .htaccess dans le dossier d’upload concerné et appliquer la logique suivante :

<FilesMatch \.php$>

Require all denied

</FilesMatch>

Cette règle bloque l’accès aux fichiers PHP dans le dossier concerné. Sur WordPress, une approche similaire est souvent utilisée dans wp-content/uploads. Elle doit toutefois être testée, car certaines extensions peuvent avoir des besoins spécifiques de traitement de fichiers.

Réduire la consommation de trafic avec le blocage du hotlinking

Le hotlinking consiste, pour d’autres sites, à afficher directement vos images ou médias depuis leurs propres pages. Vous payez alors la bande passante, tandis que le contenu est utilisé ailleurs. Cela peut augmenter la consommation de trafic et provoquer des problèmes de performance. Une règle simple de blocage du hotlinking suit cette logique :

RewriteEngine On

RewriteCond %{HTTP_REFERER} !^$

RewriteCond %{HTTP_REFERER} !^https?://(www\.)?exemple\.com [NC]

RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [F,NC]

Cette règle bloque les requêtes d’images dont le referer n’est pas vide et ne provient pas de votre nom de domaine. Toutefois, si vous utilisez Google Images, des aperçus sur les réseaux sociaux, un domaine CDN ou des sites partenaires, vous devrez peut-être les ajouter à une liste blanche. Utilisation de CDN Performance de site Web

Autoriser ou bloquer certaines adresses IP

Si vous souhaitez que votre panneau d’administration ne soit accessible que depuis l’adresse IP de votre bureau, la restriction par IP est une couche de sécurité efficace. Pour Apache 2.4 et versions supérieures, la logique de base est la suivante :

Require ip 203.0.113.10

Utilisée seule, cette règle autorise uniquement l’adresse IP indiquée. Soyez prudent si vous avez une IP dynamique : si elle change, vous pourriez vous bloquer vous-même l’accès à votre propre panneau. Pour une approche plus souple, il est souvent préférable de combiner restriction IP et protection par mot de passe.

Pour bloquer une adresse IP malveillante spécifique, vous pouvez utiliser une logique comme celle-ci :

<RequireAll>

Require all granted

Require not ip 198.51.100.25

</RequireAll>

Le blocage IP fonctionne bien contre certains abus ponctuels. En revanche, il est insuffisant face aux botnets ou aux attaques utilisant des adresses IP changeantes. Dans ces cas, un pare-feu applicatif, de la limitation de débit et des solutions de sécurité côté serveur seront plus efficaces.

En-têtes de sécurité : une protection supplémentaire côté navigateur

.htaccess ne sert pas uniquement au contrôle d’accès. Il peut aussi gérer des en-têtes de sécurité envoyés au navigateur. Si mod_headers est activé, les en-têtes ci-dessous renforcent le niveau de sécurité de base sur de nombreux sites :

Header always set X-Content-Type-Options nosniff

Header always set X-Frame-Options SAMEORIGIN

Header always set Referrer-Policy strict-origin-when-cross-origin

Header always set Permissions-Policy geolocation=(), microphone=(), camera=()

X-Content-Type-Options nosniff limite la tendance du navigateur à deviner et exécuter des types de fichiers de manière risquée. X-Frame-Options SAMEORIGIN empêche votre site d’être intégré dans une iframe depuis un autre domaine et réduit le risque de clickjacking. Referrer-Policy contrôle les informations de provenance transmises lors des redirections ou des clics vers d’autres sites. Permissions-Policy permet de restreindre l’accès à certaines fonctions du navigateur, comme la caméra, le micro ou la géolocalisation.

Content-Security-Policy, souvent abrégé CSP, est un en-tête encore plus puissant. Il doit cependant être déployé avec prudence. Une CSP trop stricte peut casser des publicités, des outils d’analyse, des modules de paiement, des widgets de chat ou des polices hébergées sur des services externes. La bonne méthode consiste à commencer en mode rapport, analyser les erreurs, puis appliquer progressivement la politique en production.

Liste de contrôle avant d’appliquer les changements

Les modifications .htaccess ont un effet immédiat. Avant d’ajouter des commandes de sécurité, suivez une courte liste de contrôle afin de réduire le risque d’interruption de service.

• Téléchargez une sauvegarde du fichier .htaccess existant sur votre ordinateur.
• Vérifiez que votre certificat SSL est actif et correctement installé.
• Ajoutez les règles de redirection une par une ; ne modifiez pas tout en même temps.
• Contrôlez les erreurs 500, 403 et 404 depuis le navigateur et les journaux d’erreurs serveur.
• Ne supprimez pas les règles de réécriture propres à WordPress, Laravel ou à votre application.
• Testez l’obligation HTTPS sur les zones protégées par mot de passe.
• Si vous utilisez un CDN, une extension de cache ou une extension de sécurité, vérifiez les conflits possibles.
• Essayez les parcours de connexion, formulaires, panier et paiement sur mobile, ordinateur et différents navigateurs.

Dans la pratique, appliquer les règles par étapes est essentiel. Ajoutez par exemple d’abord Options -Indexes et testez. Ajoutez ensuite la redirection HTTPS, puis la protection par mot de passe. Si un problème apparaît, vous saurez rapidement quelle ligne l’a provoqué.

Erreurs fréquentes et solutions

Erreur 500 Internal Server Error

Cette erreur provient souvent d’une faute de syntaxe, d’une directive non supportée ou d’un module Apache non activé. Par exemple, utiliser la directive Header alors que mod_headers n’est pas disponible peut provoquer une erreur. Pour résoudre le problème, retirez temporairement les dernières lignes ajoutées, consultez les journaux d’erreurs du serveur et vérifiez que votre environnement d’hébergement prend bien en charge le module concerné.

La fenêtre de mot de passe revient en boucle

Si la fenêtre d’authentification réapparaît alors que le nom d’utilisateur et le mot de passe sont corrects, le chemin du fichier .htpasswd peut être faux, le format de hash du mot de passe peut ne pas être supporté par le serveur ou les permissions du fichier peuvent être incorrectes. Vérifiez surtout que la ligne AuthUserFile contient bien le chemin physique complet du fichier.

La redirection HTTPS crée une boucle infinie

Sur un site placé derrière un CDN ou un proxy, le serveur d’origine peut voir la requête comme étant en HTTP, même si l’utilisateur visite le site en HTTPS. Il tente alors de rediriger encore et encore vers HTTPS. Dans ce cas, une règle tenant compte d’en-têtes comme X-Forwarded-Proto peut être nécessaire. Le mode SSL configuré dans le panneau du CDN doit également être correct, par exemple Full ou Full Strict selon le fournisseur.

Les images ou les fichiers CSS ne se chargent plus

Si les règles de hotlinking, FilesMatch ou les en-têtes de sécurité sont trop larges, elles peuvent bloquer des fichiers statiques légitimes. Ouvrez l’onglet Network des outils de développement du navigateur pour voir quel fichier est bloqué et avec quel code HTTP. Vous pourrez ensuite ajuster la règle concernée au lieu de désactiver toute la protection.

Sécurité .htaccess pour les sites WordPress

Sur WordPress, le fichier .htaccess est essentiel au fonctionnement des permaliens. Il faut donc éviter de modifier inutilement les règles générées entre BEGIN WordPress et END WordPress. En règle générale, il est plus sûr d’ajouter les règles de sécurité au-dessus ou au-dessous de ces blocs, sans toucher au cœur de la configuration WordPress.

Voici quelques mesures pratiques applicables à WordPress :

• Ajouter une protection Basic Auth sur le dossier wp-admin.
• Empêcher l’exécution de PHP dans wp-content/uploads.
• Limiter l’accès à xmlrpc.php si vous ne l’utilisez pas.
• Réduire la visibilité de readme.html et des fichiers de licence.
• Faire correspondre la redirection HTTPS avec les adresses du site configurées dans WordPress.

Pour wp-admin, combiner le mot de passe WordPress et une protection .htaccess ajoute une double couche de défense. Toutefois, certaines extensions utilisent admin-ajax.php et doivent pouvoir y accéder. Bloquer tout le dossier wp-admin sans discernement peut donc casser certaines fonctions, notamment les formulaires, les commentaires, le panier ou le paiement. Les tests sur site réel sont indispensables. Hébergement WordPress Accélération de WordPress

Conseils professionnels pour une sécurité .htaccess durable

Les administrateurs système expérimentés accordent beaucoup d’importance à l’équilibre entre sécurité et maintenabilité. Des règles très agressives peuvent sembler rassurantes à court terme, mais compliquer la maintenance à long terme. Pour chaque règle, notez son objectif, son périmètre et le résultat des tests.

• Avant un changement critique, créez une sauvegarde datée, par exemple htaccess-2026-01-15.bak.
• Évitez d’empiler des centaines de règles inutiles dans un seul fichier .htaccess.
• Les redirections 301 étant permanentes, tenez compte du cache des navigateurs et des moteurs de recherche.
• Après l’ajout d’en-têtes de sécurité, vérifiez les erreurs dans la console du navigateur.
• Dans les dossiers protégés par mot de passe, créez des utilisateurs individuels au lieu de partager un mot de passe faible.
• Fermez les dossiers test, staging et backup au niveau serveur avant même de penser au référencement.

Un autre point important est la révision régulière des règles. Une intégration utilisée aujourd’hui peut être supprimée demain, mais une exception laissée dans .htaccess peut rester oubliée pendant des mois. Un contrôle de sécurité trimestriel permet de retirer les permissions inutiles, de nettoyer les anciennes redirections et de garder une configuration lisible.

Conclusion : un petit fichier, une grande couche de protection

La protection par mot de passe avec .htaccess et les commandes destinées à renforcer la sécurité du site constituent, lorsqu’elles sont bien utilisées, une première ligne de défense efficace. Protéger des dossiers sensibles, forcer HTTPS, désactiver l’indexation des répertoires, bloquer l’accès aux fichiers critiques et activer des en-têtes de sécurité sont des mesures applicables, mesurables et utiles pour la majorité des sites web.

La sécurité .htaccess ne suffit cependant pas à elle seule. Elle doit s’inscrire dans un ensemble plus large : hébergement fiable, logiciels à jour, certificat SSL, sauvegardes régulières et politique de mots de passe robuste. En hébergeant votre site chez Hostragons, vous pouvez gérer depuis un même panneau des éléments essentiels comme SSL, l’hébergement et le nom de domaine, puis avancer étape par étape vers une configuration plus sûre. Paquets d'hébergement Web Acheter un domaine certificats SSL

Questions fréquentes

La protection .htaccess chiffre-t-elle réellement les fichiers ?

Non. Cette expression désigne le plus souvent la protection d’un dossier par nom d’utilisateur et mot de passe. Basic Auth limite l’accès, mais la transmission des données doit être sécurisée avec SSL et HTTPS.

Est-il sûr de placer le fichier .htpasswd dans public_html ?

Ce n’est pas recommandé. La meilleure pratique consiste à placer .htpasswd en dehors de public_html, dans un répertoire qui n’est pas directement accessible depuis le web. Cela réduit le risque de consultation du fichier, même en cas de mauvaise configuration.

Que faire si j’obtiens une erreur 500 après avoir modifié .htaccess ?

Supprimez d’abord les dernières lignes ajoutées ou restaurez la sauvegarde. Consultez ensuite les journaux d’erreurs du serveur. Le problème vient le plus souvent d’une faute de syntaxe, d’une directive non supportée ou d’un module Apache inactif.

Est-ce une bonne idée de protéger wp-admin avec .htaccess ?

Oui, cela peut ajouter une couche de sécurité utile. Cependant, certaines extensions ont besoin de fichiers comme admin-ajax.php. Après la mise en place, testez impérativement la connexion, les commentaires, le panier, le paiement et les formulaires.

Une redirection HTTPS nuit-elle au SEO ?

Non, une redirection 301 vers HTTPS correctement configurée n’est pas nuisible. Elle fournit au contraire une structure d’URL sûre et cohérente. L’essentiel est d’éviter les chaînes de redirection et d’aligner les liens internes sur les URL HTTPS finales.