Votre site répond soudainement « Too Many Requests » et l’API WordPress refuse même une requête légitime. Pour corriger une WordPress erreur 429, identifiez la couche qui limite les appels, respectez d’abord l’en-tête Retry-After, puis réduisez ou répartissez les requêtes. Contrôlez ensuite le pare feu, le CDN, le plugin de sécurité, le cron et le client qui interroge la REST API. Le code 429 indique une saturation ou une règle de limitation, pas une panne générale de WordPress.

La scène est classique. Une synchronisation lancée le matin fonctionne, puis chaque appel retourne 429. Relancer en boucle aggrave le blocage. La bonne méthode consiste à observer une réponse complète, à attendre le délai demandé et à remonter progressivement jusqu’au composant qui compte les requêtes.

Comprendre la WordPress erreur 429

Le statut HTTP 429 signifie que le serveur considère qu’un client a envoyé trop de requêtes pendant une période donnée. La définition vient de la RFC 6585, qui précise aussi que la réponse peut contenir Retry-After. Ce mécanisme ne définit pas un seuil universel. La limite peut être calculée par adresse IP, compte, cookie, route, ressource, clé API ou groupe de serveurs.

WordPress ne fixe pas à lui seul un nombre identique de requêtes autorisées pour tous les sites. Le 429 peut être produit par un hébergeur, un CDN, ModSecurity, LiteSpeed, une extension de sécurité, une route personnalisée ou votre propre code. Une réponse JSON contenant rest_cookie_invalid_nonce n’a pas le même diagnostic qu’une page HTML « rate limit exceeded » générée par un proxy.

Commencez par enregistrer l’URL, la méthode HTTP, l’heure, le corps de réponse et les en-têtes. Ces éléments disent souvent si le refus vient de WordPress ou d’une couche en amont.

curl -i -sS --max-time 20 https://exemple.fr/wp-json/wp/v2/posts?per_page=1

# Vérifier uniquement le statut et le délai de nouvelle tentative
curl -sS -D - -o /dev/null https://exemple.fr/wp-json/ | grep -iE 'HTTP/|retry-after|server:|cf-|x-ratelimit'

Lire Retry After avant de relancer

Lorsque Retry-After contient un nombre, il représente un délai en secondes. Lorsqu’il contient une date HTTP, attendez jusqu’à cette date. MDN documente ces deux formes et rappelle qu’elles sont utilisées avec les réponses 429 et 503. Si l’en-tête est absent, ne choisissez pas un délai nul. Appliquez un temps d’attente progressif et ajoutez une variation aléatoire pour éviter que plusieurs travailleurs repartent ensemble.

Le pire correctif est une boucle qui relance immédiatement la même URL. Elle transforme une petite pointe en blocage durable. Une stratégie fiable limite le nombre d’essais, conserve la réponse pour analyse et arrête le traitement quand le serveur demande d’attendre.

import random
import time
import requests

url = "https://exemple.fr/wp-json/wp/v2/posts"
for tentative in range(5):
    response = requests.get(url, params={"per_page": 10}, timeout=20)
    if response.status_code != 429:
        response.raise_for_status()
        data = response.json()
        break

    valeur = response.headers.get("Retry-After")
    delai = int(valeur) if valeur and valeur.isdigit() else 2 ** tentative * 5
    time.sleep(delai + random.uniform(0, 1.5))
else:
    raise RuntimeError("Limite 429 persistante")

Un client doit également respecter les limites de pagination. Demandez dix ou vingt éléments au lieu de répéter une requête par article. Utilisez les paramètres _fields pour réduire la réponse quand votre intégration ne lit que quelques propriétés.

Déterminer qui renvoie le statut 429

Testez trois chemins dans cet ordre. Appelez la page d’accueil, la racine /wp-json/, puis la route précise qui échoue. Si toutes répondent 429, suspectez le CDN, le WAF ou l’hébergeur. Si seule la REST API est limitée, inspectez le plugin de sécurité et les règles appliquées au chemin /wp-json/. Si une seule route est concernée, examinez son code ou le service qu’elle appelle.

Comparez aussi deux réseaux autorisés, sans contourner une restriction de production. Une requête depuis votre navigateur et une autre depuis le serveur peuvent recevoir des limites différentes. Notez l’adresse IP vue par le serveur, car un proxy mal configuré peut faire apparaître tous les visiteurs sous une même IP. Dans ce cas, une limite par IP pénalise tout le site dès qu’un seul client est bavard.

# Comparer les en-têtes sans envoyer de données d’écriture
curl -sS -D /tmp/headers.txt -o /tmp/body.txt https://exemple.fr/wp-json/
printf 'Statut : '; head -n 1 /tmp/headers.txt
grep -iE 'retry-after|ratelimit|server|via|cf-' /tmp/headers.txt
head -c 400 /tmp/body.txt

Les en-têtes comme X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset sont utiles lorsqu’ils existent, mais ils ne sont pas obligatoires. Leur absence ne prouve pas qu’il n’y a aucune limitation. Consultez les journaux de l’hébergeur avec l’heure exacte et l’IP source.

Inspecter le CDN, le WAF et l’hébergement

Un CDN peut appliquer une règle de limitation avant que la requête atteigne WordPress. Un WAF peut compter les appels par IP, pays, chemin ou signature de bot. LiteSpeed et ModSecurity peuvent également produire un refus qui ressemble à une erreur applicative. Une page HTML avec un identifiant de blocage, un en-tête propre au fournisseur ou un serveur différent de votre origine indique souvent cette situation.

Ne désactivez pas toutes les protections pour confirmer l’hypothèse. Demandez d’abord quel composant a généré le 429. Créez ensuite une exception étroite pour une route nécessaire, une clé d’intégration ou une IP de serveur stable. Une exception globale sur /wp-json/ retire une barrière à toutes les routes, y compris celles qui écrivent des articles ou exposent des informations privées.

Si un reverse proxy est présent, vérifiez la transmission de l’IP réelle et des en-têtes d’authentification. Une mauvaise configuration peut regrouper des milliers de visiteurs dans le même compteur. Si vous utilisez Cloudflare ou un service comparable, contrôlez les règles « rate limiting », les Workers et les règles de pare feu avant le tableau de bord WordPress.

# Exemple de réponse produite par une couche de protection
HTTP/2 429
content-type: application/json
retry-after: 60
x-ratelimit-remaining: 0

{"message":"Trop de requêtes, réessayez plus tard."}

Contrôler les plugins et les appels REST WordPress

Les extensions de sécurité peuvent limiter le login, XML RPC et la REST API. Les plugins de cache, de sauvegarde, de SEO et de synchronisation peuvent aussi lancer plusieurs tâches en parallèle. Faites l’inventaire des tâches planifiées et des intégrations qui utilisent le site. Une limite qui apparaît toutes les heures peut correspondre à un cron, tandis qu’un 429 uniquement pendant une importation indique souvent un parallélisme trop élevé.

Pour isoler un plugin, travaillez sur une copie de test ou utilisez un outil de diagnostic qui ne modifie pas l’expérience des visiteurs. Désactiver une extension de sécurité en production n’est pas une méthode de correction. Si le plugin confirme la cause, réduisez son rythme, excluez seulement une requête légitime et gardez une protection adaptée.

Une route REST personnalisée peut aussi effectuer plusieurs requêtes externes ou charger une requête lourde à chaque appel. Ajoutez une mise en cache courte pour les données publiques, validez les paramètres et refusez les demandes inutiles. Pour une route privée, authentifiez la demande et limitez le volume par utilisateur plutôt que par IP seule.

add_action('rest_api_init', function () {
    register_rest_route('mon-site/v1', '/rapport', [
        'methods'  => 'GET',
        'callback' => 'mon_lire_rapport',
        'permission_callback' => function () {
            return current_user_can('read');
        },
    ]);
});

function mon_lire_rapport() {
    $cle = 'mon_rapport_public';
    $valeur = get_transient($cle);
    if (false === $valeur) {
        $valeur = mon_calculer_rapport();
        set_transient($cle, $valeur, 60);
    }
    return rest_ensure_response($valeur);
}

Ce cache d’une minute ne remplace pas une vraie limitation. Il évite toutefois de refaire un calcul identique pour chaque visiteur. Pour des écritures, rendez l’opération idempotente avec une clé propre à la commande et ne relancez pas aveuglément un POST après un 429.

Réduire le volume des requêtes REST

La correction la plus durable se trouve souvent dans le client. Regroupez les appels, utilisez la pagination, désactivez les sondages trop fréquents et ne demandez que les champs utiles. Un tableau de bord qui interroge cinq routes toutes les secondes consomme 300 appels par minute avant même qu’un visiteur ne fasse une action.

Remplacez le polling agressif par un intervalle raisonnable, un webhook ou une file de traitement. Ajoutez un verrou pour empêcher deux processus de synchroniser le même contenu. Conservez le dernier identifiant traité afin de reprendre après une pause sans relire toute la base.

// Une seule synchronisation active par site
const attente = new Map();

async function charger(url) {
  if (attente.has(url)) return attente.get(url);
  const promesse = fetch(url, {
    headers: { Accept: 'application/json' }
  }).finally(() => attente.delete(url));
  attente.set(url, promesse);
  return promesse;
}

// Lire uniquement les champs nécessaires
const url = '/wp-json/wp/v2/posts?per_page=20&_fields=id,link,title,date';

Ajoutez de la télémétrie côté client. Enregistrez le nombre d’appels, la route, le statut, le délai et une empreinte du compte. Ne journalisez jamais un mot de passe, un nonce ou un jeton complet. Une limite devient facile à régler quand vous savez quelle intégration produit la pointe.

Différencier 429, 500, 503 et 504

Une WordPress erreur 429 dit que le rythme ou le quota est refusé. Une erreur 500 désigne une exception côté serveur. Une erreur 503 signale un service indisponible, souvent pendant une surcharge, une maintenance ou une panne de PHP. Une erreur 504 signale qu’un proxy n’a pas reçu la réponse à temps. Ces statuts peuvent se succéder, mais ils ne se corrigent pas avec la même action.

Si vous voyez d’abord 429 puis 503, ralentissez le client avant d’augmenter les ressources. Si vous voyez 504 sans 429, mesurez la durée des requêtes, PHP et la base de données. Notre guide sur WordPress erreur 503 détaille la surcharge et la maintenance. Pour un délai de proxy, consultez WordPress erreur 504.

Les erreurs réseau côté client méritent une lecture séparée. Le guide sur curl error 28 et curl error 7 aide à distinguer un refus immédiat d’un délai d’attente. Cette distinction évite de modifier le rate limiting lorsque le serveur ne répond simplement pas assez vite.

Mettre en place une stratégie de reprise fiable

Une intégration robuste applique un délai exponentiel plafonné, un peu d’aléa et un nombre maximal d’essais. Elle traite le 429 comme une information exploitable. Elle met la tâche en attente si Retry-After est présent, puis reprend sans doubler une écriture. Elle alerte seulement après plusieurs échecs, afin de ne pas transformer un ralentissement de quelques secondes en fausse alerte.

def delai_reprise(tentative, retry_after=None):
    if retry_after and retry_after.isdigit():
        return min(int(retry_after), 900)
    base = min(2 ** tentative, 300)
    return base + random.uniform(0, base * 0.2)

# Règle pratique : maximum 5 essais, puis file d’attente
# Ne jamais relancer une écriture sans identifiant idempotent

Sur un site à fort trafic, la limitation doit rester équitable. Comptez les utilisateurs ou les clés d’intégration séparément lorsque c’est possible. Protégez les routes sensibles davantage que les lectures publiques. Retournez un message utile, le délai de reprise et un identifiant de support, sans révéler la configuration interne.

Checklist de résolution en dix minutes

Reproduisez le 429 avec une seule requête. Lisez Retry-After. Vérifiez si la réponse est JSON ou HTML. Comparez la racine du site, /wp-json/ et la route fautive. Identifiez le serveur qui répond. Regardez les journaux CDN et WAF. Listez les crons et intégrations. Réduisez le parallélisme. Ajoutez une reprise progressive. Testez après le délai indiqué. Enfin, surveillez les statuts pendant plusieurs heures.

Si le problème persiste malgré un client calme, transmettez au support l’URL, l’heure UTC, l’adresse IP source, les en-têtes non sensibles et un extrait de réponse. Ne transmettez pas de cookie, mot de passe, nonce ou jeton. Une demande précise permet d’obtenir la règle responsable sans exposer votre site.

FAQ sur WordPress erreur 429

Que signifie une WordPress erreur 429 ?

Elle signifie qu’une couche du site considère que trop de requêtes ont été envoyées pendant une période donnée. Cette couche peut être WordPress, une extension, un WAF, un CDN ou l’hébergeur.

Combien de temps attendre après une erreur 429 ?

Lisez d’abord Retry-After. S’il est absent, attendez progressivement, par exemple cinq secondes puis dix secondes, sans dépasser cinq essais automatiques. Le délai réel dépend de la règle qui limite le site.

Faut-il désactiver le plugin de sécurité ?

Non. Identifiez la règle, réduisez les appels ou créez une exception étroite pour l’intégration légitime. Désactiver toute la protection laisse le site exposé et ne corrige pas le client trop bavard.

Une erreur 429 pénalise-t-elle le référencement ?

Un épisode court ne suffit généralement pas à dégrader un site. Des 429 répétés peuvent toutefois empêcher l’exploration ou le chargement des ressources. Surveillez les journaux et corrigez la cause avant qu’elle ne devienne permanente.

Quelle différence entre 429 et 503 ?

Le 429 indique une limitation du rythme ou du quota. Le 503 indique que le service est indisponible. Ils peuvent être liés à une surcharge, mais le 429 se traite d’abord en ralentissant et en répartissant les appels.

Sources et références

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.