Erreur 403 Forbidden WordPress après une mise à jour : comment la corriger pas à pas

Tu viens de mettre à jour WordPress, un plugin ou ton thème, et tu tombes sur « 403 Forbidden » ? Respire : ton site n'a pas disparu. Une erreur 403 forbidden sur WordPress après une mise à jour signifie simplement que le site existe toujours, mais que le serveur refuse d'afficher la page.

C'est un grand classique : la mise à jour a modifié un fichier de configuration, changé une permission ou réveillé un module de sécurité trop zélé. Dans ce guide, on traque la cause du plus simple au plus avancé : cache du navigateur, plugins via FTP, .htaccess, permissions, fichier index.php, puis hébergeur si le blocage vient du serveur.

À la fin de cet article, tu sauras corriger l'erreur 403 forbidden WordPress après mise à jour dans la grande majorité des cas — et reconnaître le moment où il vaut mieux passer le relais à ton hébergeur.

L'erreur 403 Forbidden sur WordPress, c'est quoi exactement ?

Le code 403 fait partie des codes de statut HTTP : c'est le serveur web (Apache, Nginx ou LiteSpeed chez la plupart des hébergeurs comme OVH, o2switch, Hostinger, Ionos ou PlanetHoster) qui répond « forbidden », c'est-à-dire « interdit ». Le message « Forbidden — You don't have permission to access this resource » signifie : la ressource existe, mais tu n'as pas l'autorisation de la voir.

Ne confonds pas avec ses cousines : la 404 signifie que la page n'existe pas, la 500 signale un plantage interne du serveur. La 403, elle, est une histoire d'autorisations : le serveur a décidé de te barrer la route. C'est pour ça qu'elle surgit si souvent après une mise à jour : quelque chose a changé dans les règles d'accès.

Observe où l'erreur apparaît : uniquement sur wp-admin ou wp-login.php alors que le site public fonctionne ? Vise un plugin de sécurité ou le .htaccess. Tout le site est bloqué ? Penche pour un .htaccess corrompu, des permissions modifiées ou une protection de l'hébergeur (mod_security, pare-feu).

Action concrète : note quelles pages affichent la 403 : tout le site, seulement l'administration, ou un dossier précis comme wp-content/uploads. Cette simple observation t'évitera la moitié des fausses pistes.

Les causes probables après une mise à jour

Une mise à jour peut réécrire des fichiers de configuration, réinitialiser des permissions et déclencher des modules de sécurité. Voici les coupables habituels, par ordre de probabilité.

1. Un fichier .htaccess corrompu. Le suspect numéro un. WordPress et plusieurs plugins (sécurité, cache, redirection) écrivent des règles dans ce fichier caché à la racine. Après une mise à jour, des règles contradictoires peuvent bloquer tout le site.

2. Des permissions de fichiers modifiées. Chaque fichier et dossier possède des permissions (lecture, écriture, exécution). Une mise à jour, une restauration ou une migration peut les dérégler, et le serveur refuse alors de servir les fichiers.

3. Un plugin de sécurité trop zélé. Wordfence, iThemes Security, All In One WP Security ou Sucuri peuvent bloquer ton wp-admin après une mise à jour, surtout si ton adresse IP a changé ou si une règle de « hardening » s'est réactivée.

4. Une protection anti-hotlink ou une règle serveur. Une protection contre le hotlink mal configurée peut bloquer tes propres images avec une 403. De même, le module mod_security d'Apache peut prendre une requête légitime de l'administration pour une attaque et la bloquer.

5. Un fichier index.php manquant ou un problème de propriété. Si le index.php de la racine a disparu pendant la mise à jour, le serveur tente d'afficher le contenu du dossier — interdit, d'où la 403. De même, si les fichiers appartiennent au mauvais utilisateur système (classique après migration), le serveur refuse de les servir.

Critère de diagnostic : erreur limitée à wp-admin ou wp-login.php → vise les plugins de sécurité et le .htaccess. Erreur sur tout le site → vise le .htaccess, les permissions et mod_security. Erreur sur un seul dossier (par exemple les images) → vise la protection hotlink et les permissions de ce dossier.

Solution 1 : vider le cache et tester en navigation privée

On commence par le plus simple, aussi le plus sous-estimé : ton navigateur garde peut-être en cache une ancienne version de la page, ou un cookie de session corrompu. Avant de toucher au serveur, élimine cette hypothèse en deux minutes.

Ouvre une fenêtre de navigation privée (Ctrl+Shift+N sur Chrome, Ctrl+Shift+P sur Firefox) et teste ton site puis wp-admin. Si ça fonctionne, le problème vient de ton navigateur : vide le cache et les cookies, puis reconnecte-toi.

Pense aussi à ton CDN : Cloudflare peut servir une page 403 en cache même après résolution côté serveur. Purge le cache depuis ton tableau de bord Cloudflare, et vide le cache de ton plugin de cache une fois l'accès rétabli.

Action concrète : navigation privée OK ? Vide le cache du navigateur et du CDN. Erreur persistante ? Le problème est côté serveur : passe à la solution 2.

Solution 2 : désactiver les plugins via FTP

Sans accès à wp-admin, impossible de désactiver les plugins depuis l'interface. La méthode hunter : passer par FTP avec FileZilla, ou par le gestionnaire de fichiers de ton hébergeur (cPanel, Plesk).

Connecte-toi avec tes identifiants FTP (dans ton espace client OVH, o2switch, Hostinger…), ouvre wp-content et renomme le dossier plugins en plugins_desactive. Ne le supprime pas : le renommage désactive tout d'un coup, sans perdre réglages ni données.

Retourne ensuite sur ton site : si l'erreur 403 a disparu, tu tiens ton coupable — c'est bien un plugin. Pour l'identifier, restaure le nom plugins puis renomme les sous-dossiers un par un — en commençant par les plugins de sécurité et le dernier mis à jour — en testant le site à chaque fois. Même logique que pour l'erreur 500 après l'activation d'un plugin : on isole le fautif par élimination.

Si c'est un plugin de sécurité, ne le réactive pas aveuglément : vérifie ses réglages de « hardening », ajoute ton IP à la liste blanche, puis réactive-le.

Action concrète : site OK sans plugins ? Réactive-les un par un, puis mets à jour ou remplace le fautif. Erreur persistante ? Passe à la solution 3.

Solution 3 : régénérer le fichier .htaccess

Le .htaccess (fichier caché, note le point devant) contient les règles d'accès de ton site sur Apache et LiteSpeed. Une mise à jour peut y laisser des règles corrompues : c'est l'une des causes les plus fréquentes de 403 après mise à jour.

Via FTP, va à la racine du site (où se trouvent wp-config.php, wp-admin, wp-content). Active l'affichage des fichiers cachés si besoin, télécharge le .htaccess par sécurité, puis renomme-le en .htaccess_sauvegarde.

Teste ton site : s'il s'affiche, le .htaccess était corrompu. Génères-en un propre : dans wp-admin, va dans Réglages, Permaliens, et clique sur « Enregistrer les modifications » sans rien changer. WordPress recrée un .htaccess sain.

Si l'ancien fichier contenait des règles personnalisées (redirections, anti-hotlink, cache), réintroduis-les une par une en testant à chaque fois.

Action concrète : site accessible après renommage ? Régénère les permaliens. Erreur persistante ? Passe à la solution 4.

Solution 4 : vérifier et corriger les permissions

Les permissions définissent qui peut lire, écrire ou exécuter chaque fichier. Pour WordPress : 644 pour les fichiers, 755 pour les dossiers, 600 ou 640 pour wp-config.php (il contient tes mots de passe de base de données).

Dans FileZilla : clic droit, « Permissions du fichier », vérifie les valeurs. Pour corriger en masse, applique 755 aux dossiers puis 644 aux fichiers. Dans cPanel, la manipulation est similaire (clic droit, « Change Permissions »).

En SSH, depuis la racine du site : find . -type d -exec chmod 755 {} \; pour les dossiers, find . -type f -exec chmod 644 {} \; pour les fichiers, puis chmod 600 wp-config.php.

Action concrète : après correction, vide le cache et recharge. 403 persistante avec de bonnes permissions ? Vois la propriété des fichiers et le serveur : solutions 5 et 6.

Solution 5 : vérifier index.php et la propriété des fichiers

Deux vérifications rapides qui règlent les cas restants. D'abord, assure-toi que index.php est présent à la racine : une mise à jour interrompue peut l'avoir supprimé, et le serveur répond alors 403. Si le fichier manque, récupère-le depuis une archive officielle de WordPress (même version) et envoie-le par FTP.

Ensuite, la propriété des fichiers : sur un serveur, chaque fichier appartient à un « propriétaire » système. Après une migration ou une restauration, les fichiers peuvent appartenir au mauvais utilisateur système, et le serveur refuse de les servir malgré de bonnes permissions. En SSH, ls -la montre le propriétaire ; s'il ne correspond pas à l'utilisateur du serveur web (souvent www-data), ton hébergeur devra corriger avec chown.

Jette aussi un œil aux logs d'erreurs (section « Errors » de cPanel ou fichier error_log) : la cause exacte s'y trouve souvent (« client denied by server configuration », « permission denied »). C'est de l'or en barre pour le support.

Action concrète : index.php présent, propriétaire correct, et 403 persistante ? Le blocage est au niveau serveur : solution 6.

Solution 6 : contacter l'hébergeur (mod_security, pare-feu)

Cache, plugins, .htaccess, permissions, propriété : tout est en ordre et la 403 persiste ? Le blocage se joue au niveau du serveur, et seul ton hébergeur peut intervenir. Les deux responsables habituels : mod_security et le pare-feu applicatif.

Mod_security analyse les requêtes Apache et bloque celles qui ressemblent à des attaques. Après une mise à jour, des requêtes légitimes de l'administration peuvent déclencher une fausse alerte et recevoir une 403. Ton hébergeur peut vérifier ses logs et mettre la règle fautive en liste blanche.

Certains hébergeurs appliquent aussi un pare-feu applicatif (WAF) qui bloque wp-admin après un pic de requêtes lié à la mise à jour. Ouvre un ticket avec des infos précises : URL exacte en 403, heure du début du problème, solutions déjà testées, extrait du log d'erreurs.

Si ton site affiche aussi des lenteurs inhabituelles en parallèle, sache qu'un serveur surchargé et un blocage 403 ont parfois la même origine : mentionne-le dans ton ticket au support.

Action concrète : ouvre un ticket avec ton diagnostic complet. Un support qui reçoit un diagnostic propre répond bien plus vite qu'à un simple « mon site ne marche plus ».

Quand demander de l'aide

La 403 résiste à tout ? Ton hébergeur est prioritaire si : tout le site est bloqué malgré plugins désactivés et .htaccess régénéré, les logs mentionnent mod_security, ou les fichiers appartiennent au mauvais utilisateur. Tu n'as pas la main sur ces éléments.

Un développeur WordPress est utile si : la 403 n'apparaît que sur des pages personnalisées, elle a suivi l'installation d'un thème ou plugin sur mesure, ou ton functions.php contient du code personnalisé. Là, le problème est dans le code, pas dans le serveur.

Prépare ces infos avant de demander de l'aide : versions de WordPress et PHP, hébergeur, plugins, ce qui a été mis à jour juste avant, solutions testées. Et si c'est une page blanche plutôt qu'une 403 franche, vois notre guide sur la page blanche WordPress après mise à jour couvre ce cas voisin.

Action concrète : hébergeur pour le serveur (mod_security, propriété des fichiers, pare-feu), développeur pour le code personnalisé. Avec un diagnostic propre, tu obtiens une solution en heures, pas en jours.