# « Blocked due to access forbidden » : un .htaccess trop strict bloque le CSS

> Symptôme repéré dans Search Console sur le site d'un cabinet notarial, diagnostic d'un blocage trop large et correctif au niveau du serveur.

- Auteur : Clément Hadrot
- Publié le : 2020-11-07
- Mis à jour le : 2020-11-07
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/blocked-due-to-access-forbidden-htaccess-css/

## L’essentiel

- Le rapport de couverture signale les ressources CSS et JS en erreur
- La règle Apache trop générale bloquait tout le dossier de thème
- Le correctif cible précisément les fichiers sensibles à protéger

« Blocked due to access forbidden (403) » : ce message apparaît dans le rapport de couverture de Search Console pour le site d'un cabinet notarial, sur plusieurs feuilles de style et scripts pourtant indispensables au rendu correct des pages. L'outil d'inspection d'URL confirme le problème : la capture d'écran générée par Googlebot montre une page dépouillée de toute mise en forme, alors que le même URL s'affiche normalement dans un navigateur classique.

Ce type d'écart entre le rendu visiteur et le rendu Googlebot mérite une attention immédiate, car Google indexe la page telle qu'il la voit, mise en forme comprise. Une page qui semble cassée aux yeux du robot d'exploration peut voir sa qualité perçue diminuer, même si son contenu textuel reste inchangé.

## Premier réflexe : comparer les deux rendus

L'outil d'inspection d'URL de Search Console propose un aperçu du rendu tel que Googlebot le perçoit, avec la liste des ressources chargées et celles qui ont échoué. Sur ce site, la liste des échecs pointe systématiquement vers des fichiers situés dans `/wp-content/themes/notaire-theme/assets/`, avec un code de retour HTTP 403 pour chacun.

Un code 403 signifie que le serveur a bien reçu la requête, mais refuse explicitement d'y répondre. Ce n'est ni un fichier manquant (qui renverrait un 404), ni un problème de DNS ou de certificat : la cause se situe très probablement dans une règle de configuration du serveur qui interdit l'accès à ce dossier.

## Diagnostic : une règle Apache trop large

L'examen du fichier `.htaccess` à la racine du dossier de thème révèle la règle suivante, ajoutée quelques semaines plus tôt par un précédent prestataire pour empêcher le listage du contenu du dossier `assets` :

> L'essentiel à retenir : Le rapport de couverture signale les ressources CSS et JS en erreur ; La règle Apache trop générale bloquait tout le dossier de thème ; Le correctif cible précisément les fichiers sensibles à protéger

```
<Directory "/wp-content/themes/notaire-theme/assets">
    Order deny,allow
    Deny from all
</Directory>
```

L'intention initiale était légitime : interdire l'accès direct au listage de fichiers du dossier pour éviter qu'un visiteur curieux ne parcoure son contenu. Mais la directive `Deny from all` ne fait pas la distinction entre un accès direct au dossier et une requête vers un fichier CSS ou JavaScript précis référencé par une balise `<link>` ou `<script>` : elle bloque les deux de la même manière.

## Le correctif : cibler précisément ce qu'il faut protéger

La bonne pratique consiste à interdire uniquement le listage du contenu du dossier, sans bloquer l'accès aux fichiers individuels qui y sont référencés légitimement :

```
<Directory "/wp-content/themes/notaire-theme/assets">
    Options -Indexes
</Directory>
```

La directive `Options -Indexes` empêche Apache de générer une page listant le contenu du dossier lorsqu'aucun fichier index n'est présent, ce qui répond exactement au besoin initial du prestataire, sans jamais bloquer une requête vers un fichier CSS ou JavaScript précis appelé par une page.

### Vérifier avant de republier

Une fois la modification appliquée, un test direct de l'URL du fichier CSS dans le navigateur, en navigation privée, confirme un code 200 au lieu du 403 précédent. L'outil d'inspection d'URL de Search Console, relancé sur une page concernée, affiche ensuite un rendu identique à celui d'un navigateur classique.

## Prévention : documenter chaque règle serveur

Ce type d'incident survient presque toujours de la même manière : une règle ajoutée pour un besoin légitime et ponctuel, sans documentation ni test de son effet de bord sur les ressources publiques du site. Trois habitudes limitent ce risque :

- Tester systématiquement le rendu Googlebot après toute modification du fichier `.htaccess` ou de la configuration du serveur.
- Commenter chaque règle ajoutée avec sa date et son motif, directement dans le fichier de configuration.
- Surveiller le rapport de couverture de Search Console au moins une fois par mois pour repérer rapidement toute nouvelle erreur de ce type.

## En résumé

Un code 403 sur des ressources CSS ou JavaScript dans Search Console pointe presque toujours vers une règle de serveur trop restrictive plutôt que vers un problème WordPress. L'outil d'inspection d'URL reste le point de départ le plus fiable pour confirmer le diagnostic, avant d'aller chercher la règle fautive directement dans la configuration Apache du site.