« Le lien suivi est expiré » : erreur WordPress et solutions

Le lien suivi est expiré.

En anglais : The link you followed has expired.

Vous venez de valider un formulaire de l’administration (enregistrer un réglage, envoyer un thème ou une extension, supprimer un contenu) et WordPress affiche une page d’erreur très courte, dont l’onglet du navigateur porte le titre « Une erreur s’est produite. », avec ce texte : « Le lien suivi est expiré. » Parfois, un lien « Veuillez réessayer. » est proposé. L’erreur apparaît dans l’administration, plus rarement sur le site public, et renvoie un code HTTP 403.

Malgré son libellé, aucun lien n’a vraiment « expiré » dans la plupart des cas. WordPress indique simplement que la requête n’est pas accompagnée d’un nonce valide, c’est-à-dire du jeton de sécurité qui prouve que l’action vient bien de votre session. Deux scénarios dominent : la page est restée ouverte trop longtemps, ou la requête est arrivée vide parce que le fichier envoyé dépassait les limites du serveur.

Ce que signifie cette erreur

Les formulaires et les liens d’action de l’administration contiennent un nonce, généré par wp_create_nonce(). Il est calculé à partir d’une « période » de temps, du nom de l’action, de votre identifiant utilisateur et du jeton de votre session (wp_get_session_token()), puis haché avec les clés de sécurité du site (NONCE_KEY et NONCE_SALT de wp-config.php).

Au traitement, check_admin_referer() (wp-includes/pluggable.php) appelle wp_verify_nonce(). Un nonce est accepté s’il a été généré il y a moins de 12 heures, ou entre 12 et 24 heures : sa durée de vie nominale est de 24 heures (filtre nonce_life, valeur par défaut DAY_IN_SECONDS), découpée en deux demi-périodes. Si la vérification échoue, la fonction wp_nonce_ays() (wp-includes/functions.php) affiche le message « Le lien suivi est expiré. », suivi d’un lien « Veuillez réessayer. » quand un référent est connu, avec le code 403.

Pour les actions asynchrones (admin-ajax), check_ajax_referer() répond simplement -1 avec le code 403. Dans l’éditeur de blocs, qui passe par l’API REST, l’équivalent est l’erreur rest_cookie_invalid_nonce : « La vérification du cookie a échoué ».

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Le formulaire était ouvert depuis plusieurs heures ou une nuit	Nonce de plus de 12 à 24 heures	Rechargez la page et recommencez aussitôt
L’erreur survient en envoyant un thème, une extension ou un média	Fichier plus gros que post_max_size : $_POST arrive vide, donc sans nonce	Taille du fichier, post_max_size, upload_max_filesize, client_max_body_size
Vous avez été déconnecté, ou changé de mot de passe, entre l’ouverture et l’envoi	Session détruite : le jeton de session du nonce n’existe plus	Se reconnecter, puis rouvrir le formulaire
L’erreur revient sur une page d’administration rechargée	Cache de page ou de navigateur qui sert un formulaire ancien	Exclusion de /wp-admin/ du cache, navigation privée
Le problème apparaît sur plusieurs actions, après une migration ou un changement de clés	Clés de sécurité modifiées, horloge du serveur décalée, cookies non retrouvés	wp-config.php, heure du serveur, fiche sur les cookies

Les causes les plus fréquentes

1. Une page d’administration laissée ouverte dans un onglet pendant plus de 12 à 24 heures avant l’envoi du formulaire.
2. Un fichier téléversé plus gros que la limite post_max_size de PHP : PHP ignore alors le corps de la requête, le nonce disparaît et WordPress affiche cette erreur au lieu d’un message de taille.
3. Une session expirée ou détruite : déconnexion, changement de mot de passe, session révoquée depuis un autre appareil.
4. Un cache de page, un CDN ou une extension d’optimisation qui sert une page d’administration ou un formulaire contenant un ancien nonce.
5. Un changement des clés de sécurité de wp-config.php : tous les nonces émis avant sont invalidés.
6. Une extension, un pare-feu applicatif ou un proxy qui supprime ou modifie des paramètres de requête.

Solutions pas à pas

1. Recharger la page et recommencer

C’est la solution de loin la plus fréquente. Revenez à la page d’origine, rechargez-la avec Ctrl+F5 pour obtenir un nouveau nonce, et renouvelez l’action sans attendre. Si WordPress vous a redirigé vers la connexion, reconnectez-vous d’abord. Notre article sur la fenêtre de validité réelle de wp_verify_nonce explique pourquoi la durée varie entre 12 et 24 heures.

2. Vérifier la taille du fichier envoyé

Si l’erreur apparaît en envoyant un thème ou une extension au format ZIP, comparez la taille du fichier aux limites de PHP. Dans l’administration, Médias > Ajouter affiche la taille maximale autorisée. En ligne de commande :

php -i | grep -E "^(post_max_size|upload_max_filesize|memory_limit)"
# ou, si PHP-FPM utilise un autre fichier de configuration :
wp eval 'echo ini_get("post_max_size"), " / ", ini_get("upload_max_filesize");'

Relevez post_max_size : il doit être au moins égal à upload_max_filesize, et supérieur à la taille du fichier. Pour les augmenter, éditez php.ini ou .user.ini à la racine du site :

upload_max_filesize = 64M
post_max_size = 64M

Sous Apache avec mod_php, vous pouvez utiliser php_value dans .htaccess. Sous nginx, ajoutez aussi la limite du serveur web, sans quoi la requête est refusée avant PHP :

# bloc http, server ou location de nginx
client_max_body_size 64M;

Rechargez PHP-FPM et nginx, puis recommencez. Les quatre réglages en cause sont détaillés dans l’article « Le fichier dépasse la taille maximale » et dans la fiche fichier trop volumineux.

3. Installer sans passer par le formulaire

Plutôt que de relever des limites pour un seul fichier, installez par un autre canal. Avec WP-CLI, depuis le dossier du site :

wp plugin install /chemin/vers/mon-extension.zip --activate
wp theme install /chemin/vers/mon-theme.zip

Ou envoyez le dossier décompressé par SFTP dans wp-content/plugins ou wp-content/themes, puis activez-le depuis l’administration.

4. Exclure l’administration des caches

Si l’erreur revient sur des pages rechargées, videz le cache du navigateur et testez en navigation privée. Vérifiez que votre extension de cache, votre CDN et votre cache serveur n’interceptent ni /wp-admin/ ni admin-ajax.php ni wp-login.php. Purgez ensuite tous les caches. Un cache qui sert à un visiteur une page générée pour un autre est un défaut plus large, décrit dans l’article sur le cache de page qui sert du contenu au mauvais visiteur.

5. Contrôler l’horloge du serveur et les cookies

Les nonces dépendent de l’heure du serveur. Vérifiez qu’elle est correcte :

date -u
timedatectl status    # sur un serveur systemd : « System clock synchronized: yes »

Si la connexion à l’administration est elle-même instable, ou si vous êtes régulièrement déconnecté, reportez-vous à la fiche cookies bloqués à la connexion. Notez qu’un nonce est lié à la session : un cookie de session non retrouvé suffit à faire échouer toutes les vérifications.

6. Allonger la durée de vie des nonces (cas particuliers)

Pour un usage où les formulaires restent ouverts très longtemps, vous pouvez allonger la durée de vie via le filtre nonce_life, dans une extension utilitaire (mu-plugin) :

<?php
add_filter( 'nonce_life', function () {
    return 2 * DAY_IN_SECONDS;
} );

C’est un compromis de sécurité : un nonce plus durable reste exploitable plus longtemps en cas de fuite. Réservez-le à des cas précis, et sachez que cette durée est aussi découpée en deux demi-périodes.

Prévenir l’erreur

• Rechargez une page d’administration restée ouverte longtemps avant d’y enregistrer quoi que ce soit.
• Alignez post_max_size, upload_max_filesize et client_max_body_size sur les plus gros fichiers que vous envoyez réellement.
• Préférez WP-CLI ou SFTP pour installer de gros thèmes et extensions.
• Excluez /wp-admin/, admin-ajax.php et wp-login.php de tous les niveaux de cache.
• Gardez l’horloge du serveur synchronisée (NTP) et ne changez les clés de sécurité qu’en connaissance de cause : cela déconnecte tout le monde.

FAQ