Le site refuse de vous laisser téléverser un thème parce que le fichier est trop volumineux. Les moteurs de recherche indexent des pages d'administration qui ne devraient pas apparaître dans les résultats. Les logs serveur montrent des tentatives d'accès à wp-config.php depuis des IP inconnues. Trois problèmes, une seule solution: le fichier .htaccess déjà présent à la racine de votre site WordPress.

Vous l'avez probablement aperçu lors de la configuration des permaliens. Mais les capacités de .htaccess vont bien au-delà: il contrôle les accès, la sécurité, les redirections et les limites de téléversement au niveau du serveur. Et contrairement aux extensions de sécurité, il n'ajoute aucune charge à PHP.

Voici quatre scénarios pratiques auxquels tout administrateur WordPress est confronté. Chacun inclut un code prêt à l'emploi, une explication et des indications sur l'endroit exact où l'insérer. Le code est écrit pour Apache 2.4 (la version actuelle en 2026), mais chaque extrait inclut un bloc de compatibilité pour Apache 2.2 afin que vous n'ayez pas à vous demander s'il fonctionnera sur votre hébergement.

💡 Aperçu rapide:

• Augmenter les limites de téléversement de fichiers via .htaccess et .user.ini pour PHP-FPM.
• Bloquer l'indexation par les moteurs de recherche au niveau du serveur.
• Désactiver la navigation dans les répertoires avec une seule ligne.
• Protéger wp-config.php contre l'accès direct en utilisant la syntaxe moderne d'Apache 2.4.

1. Augmenter la taille maximale de téléversement de fichier

Vous essayez d'installer un thème ou une extension, et WordPress affiche une erreur: «Le fichier téléversé dépasse la directive upload_max_filesize de php.ini.» La limite par défaut sur de nombreux hébergements est de 2 Mo ou 8 Mo, et votre archive de thème ne passe pas.

Vous ne pouvez pas modifier php.ini sur un hébergement mutualisé. Mais si Apache fonctionne avec le module mod_php, vous pouvez augmenter la limite directement depuis .htaccess. Ouvrez le fichier à la racine de votre site (via FTP ou le gestionnaire de fichiers de votre hébergement) et ajoutez ceci à la fin:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

La première directive définit la taille maximale de la requête POST, la seconde définit la taille maximale pour un seul fichier téléversé. Les deux valeurs doivent correspondre, ou post_max_size doit être légèrement supérieure.

Vérifiez le résultat: allez dans le panneau d'administration WordPress, Médias → Ajouter. La limite actuelle s'affichera en bas.

Important: si votre hébergeur utilise PHP-FPM (ce qui est le cas de la plupart en 2026), les directives php_value dans .htaccess ne fonctionneront pas. Pour vérifier: Outils → Santé du site → Infos → Serveur. Cherchez FPM dans la ligne «Architecture du serveur». Pour ce type d'hébergement, modifiez la limite via un fichier .user.ini à la racine du site:

1
post_max_size = 100M
2
upload_max_filesize = 100M

Le format est similaire à php.ini, avec des signes égal au lieu de php_value. Les modifications s'appliquent instantanément sans redémarrage du serveur. S'il n'y a pas de fichier .user.ini à la racine, créez-en un.

2. Bloquer l'indexation par les moteurs de recherche

La situation: un site de test sur un sous-domaine, une copie de staging ou une page d'atterrissage qui ne devrait pas apparaître dans les résultats de Google ou Yandex. Un simple robots.txt avec Disallow: / peut être ignoré par les moteurs de recherche: c'est une recommandation, pas une interdiction.

La méthode infaillible consiste à bloquer les robots au niveau du serveur. L'approche classique utilisant SetEnvIfNoCase fonctionne dans Apache 2.4 via le module de compatibilité mod_access_compat, mais elle est considérée comme dépréciée. La méthode moderne redirige les robots avec un User-Agent vide via mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Voici ce qui se passe: RewriteCond vérifie le User-Agent de chaque requête. Lorsqu'il détecte les mots-clés bot, spider, crawler ou scanner (insensible à la casse grâce au drapeau [NC]), le serveur renvoie 403 Forbidden (le drapeau [F]).

Quatre motifs suffisent pour bloquer tous les principaux moteurs de recherche: Googlebot, YandexBot, Bingbot, Yahoo Slurp et des dizaines d'autres moins connus. Lister chaque robot individuellement est inutile: Google seul a plusieurs dizaines de variations de User-Agent pour différents services (recherche, images, vidéo, AdsBot).

Vous voulez bloquer uniquement Yandex tout en laissant Google tranquille? Affinez le motif:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

Le symbole ^ signifie «début de la chaîne». Sans lui, la règle attraperait également les robots qui ont yandex quelque part au milieu de leur User-Agent.

Important: si WordPress utilise déjà mod_rewrite pour les permaliens, le bloc RewriteEngine On existe déjà dans .htaccess. Ne le dupliquez pas; ajoutez simplement les nouvelles RewriteCond et RewriteRule après les règles WordPress existantes mais avant la balise fermante </IfModule>.

Après avoir effectué les modifications, vérifiez l'absence d'erreurs dans .htaccess: une faute de frappe dans les directives fera tomber le site avec une erreur 500. Vous pouvez vérifier la syntaxe avec un validateur en ligne ou la commande apachectl configtest (non disponible sur tous les hébergements). Avant toute modification, téléchargez toujours une sauvegarde de votre .htaccess actuel.

3. Désactiver la navigation dans les répertoires

Allez sur votre site à /wp-content/uploads/. Si au lieu d'une erreur 403 vous voyez une liste de fichiers, la navigation dans les répertoires est activée. C'est une faille de sécurité: n'importe qui peut étudier la structure de vos dossiers, trouver une extension vulnérable ou lire un document PDF téléversé.

Cela se désactive avec une seule ligne dans .htaccess:

1
Options -Indexes

Ajoutez-la au début du fichier, avant les règles WordPress. Désormais, lorsque quelqu'un essaie d'ouvrir un répertoire sans fichier d'index, le serveur renverra 403 Forbidden.

Sur la plupart des hébergements modernes, cette option est activée par défaut, mais vérifiez quand même, surtout si le site a été déplacé entre serveurs ou si vous travaillez avec un VPS où Apache a été configuré manuellement.

4. Protéger wp-config.php contre l'accès direct

wp-config.php est le fichier WordPress le plus important. Il contient les clés de sécurité, le préfixe de table et les identifiants de base de données: le nom de la base, l'utilisateur, le mot de passe et l'hôte.

Le fichier lui-même est écrit en PHP et renvoie une page blanche lorsqu'il est ouvert directement dans un navigateur car le moteur WordPress ne l'exécute pas. Mais si le traitement PHP est temporairement désactivé sur le serveur (panne de configuration, mise à jour de module), le contenu de wp-config.php pourrait être servi en texte brut. Avec le mot de passe de la base de données.

Nous bloquons l'accès via .htaccess. La plupart des articles sur Internet proposent une syntaxe Apache 2.2 obsolète qui ne fonctionne pas sous Apache 2.4.6 et supérieur. Voici la version moderne avec compatibilité ascendante:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

Le bloc IfModule vérifie la présence du module mod_authz_core (introduit dans Apache 2.4.6). Si le module est absent, la syntaxe Apache 2.2 s'applique. S'il est présent, la directive moderne Require all denied est utilisée. Un seul bloc de code fonctionne sur les deux versions d'Apache.

Après avoir ajouté les règles, toute requête de navigateur vers wp-config.php recevra 403 Forbidden, même si le gestionnaire PHP ne fonctionne pas. WordPress accède au fichier directement via le système de fichiers, donc la règle n'affecte pas le fonctionnement du site.

La même approche s'applique à tout fichier confidentiel: remplacez wp-config.php par le nom de fichier dont vous avez besoin, comme phpinfo.php ou .env.

⁉️🤔 Foire aux questions

Puis-je me passer complètement du.htaccess** dans WordPress?**

Oui, si votre site fonctionne sous Nginx au lieu d'Apache. Nginx ne prend pas en charge .htaccess; toutes les règles sont définies dans la configuration du serveur (nginx.conf ou un fichier dans sites-available/). Sur l'hébergement mutualisé, c'est presque toujours Apache, et .htaccess est disponible. Sur un VPS avec Nginx, les règles sont déplacées dans la section server {}: la syntaxe est différente, mais la logique est la même. Par exemple, l'équivalent Nginx de Options -Indexes est autoindex off;.

Que dois-je faire si le site plante avec une erreur 500 après avoir modifié.htaccess?

Restaurez immédiatement la sauvegarde de .htaccess que vous avez faite avant la modification (vous en avez bien fait une, n'est-ce pas?). Connectez-vous via FTP, supprimez le .htaccess modifié et téléversez l'original sauvegardé. Le site reviendra instantanément. Une erreur 500 après modification de .htaccess est presque toujours causée par une faute de frappe dans une directive ou une construction que votre version d'Apache ne prend pas en charge.

Pourquoi php_value dans.htaccess ne fonctionne-t-il pas sur mon hébergement?

Très probablement, votre hébergeur utilise PHP-FPM au lieu de mod_php. Vérifiez: Outils → Santé du site → Infos → Serveur. Si FPM apparaît dans la ligne «Architecture du serveur», php_value dans .htaccess est ignoré. Utilisez un fichier .user.ini à la racine du site (voir section 1) ou contactez le support de votre hébergement. Sur un VPS, les limites sont modifiées dans le pool PHP-FPM (www.conf), mais cela nécessite un accès à la configuration du serveur.

Comment vérifier que.htaccess fonctionne réellement?

Le test le plus simple est la règle de la section 3 (Options -Indexes). Visitez /wp-content/uploads/ avant et après l'avoir ajoutée. Y avait-il une liste de fichiers avant, et maintenant une erreur 403? Le fichier fonctionne. Une autre méthode: ajoutez une ligne avec une erreur de syntaxe délibérée à .htaccess et ouvrez le site. Une erreur 500 confirme qu'Apache lit .htaccess. Supprimez la ligne de test immédiatement après la vérification.

Est-il sûr d'utiliser le code de cet article sur un site en production?

Oui, tous les extraits fournis ont été testés sur Apache 2.4 (la version actuelle en 2026) et incluent des blocs de compatibilité pour Apache 2.2. La seule exigence obligatoire: avant toute modification de .htaccess, téléchargez la version actuelle du fichier sur votre ordinateur. Cette opération de cinq secondes vous fait gagner des heures de récupération en cas de faute de frappe. Et ne modifiez pas .htaccess via des extensions; utilisez uniquement FTP ou le gestionnaire de fichiers de votre hébergement: une extension pourrait ajouter de l'échappement qui casse la syntaxe.

En quoi l'approche de protection de wp-config.php dans cet article diffère-t-elle de ce que d'autres sites écrivent?

La plupart des articles copient la syntaxe Apache 2.2: Order allow,deny et Deny from all. Ces directives appartiennent au module mod_access_compat, qui est déprécié dans Apache 2.4 et peut être désactivé sur les serveurs modernes. Notre extrait utilise Require all denied du module mod_authz_core, qui est la norme actuelle pour Apache 2.4.6 et supérieur. En même temps, le bloc <IfModule> maintient la fonctionnalité sur les anciens serveurs.

Ce qu'il faut ajouter à votre configuration.htaccess dès maintenant

Le fichier .htaccess est compact mais puissant. Parmi les quatre techniques décrites, deux comblent des vulnérabilités avec un effort minimal: désactiver la navigation dans les répertoires et protéger wp-config.php. C'est une ligne et un bloc de code que vous pouvez ajouter dès maintenant, et ils n'affectent pas le fonctionnement du site.

Augmenter la limite de téléversement aide chaque fois que WordPress refuse de téléverser un thème ou une extension. Et bloquer l'indexation au niveau du serveur est la dernière ligne de défense pour les sites privés et de test.

Conservez une sauvegarde de .htaccess avant chaque modification. Une erreur de syntaxe fait tomber le site instantanément, et cela se corrige tout aussi instantanément si vous avez une copie sous la main. Avec cette règle à l'esprit, .htaccess passe d'un fichier intimidant à un outil de travail.