Si Perplexity vous cite, ce n’est souvent pas parce que votre article est le meilleur, mais parce qu’au moment où l’utilisateur pose sa question, votre page apparaît comme la source la plus récente dont l’actualité peut être immédiatement vérifiée. Sur Perplexity, la fraîcheur du contenu n’est pas un simple bonus de classement : c’est un seuil d’accès à la liste des sources candidates. Vous pouvez avoir publié une excellente analyse deux ans plus tôt ; si la page semble ancienne et abandonnée, le modèle l’écartera pour toute question sensible à l’actualité, au profit d’un contenu moins bon mais plus récent, dont les réponses serveur sont plus explicites.
Où Perplexity lit-il vos signaux de fraîcheur ?
Commençons par distinguer deux mécanismes. Perplexity gère son propre index, mais peut aussi explorer des pages web à la volée lorsqu’un utilisateur pose une question. Son robot PerplexityBot sert à construire l’index, tandis qu’un autre agent utilisateur, Perplexity-User, consulte la page afin d’en confirmer le contenu au moment de répondre. Les signaux de fraîcheur sont donc lus à deux moments : lors de l’indexation et lors de la formulation de la réponse. Dans les deux cas, l’indication de la dernière mise à jour doit être cohérente et crédible. Les requêtes très sensibles au temps — prix, versions, réglementations ou chiffres annuels — sont particulièrement concernées. Le modèle privilégiera les pages récemment mises à jour lorsque cette évolution est étayée par des signaux vérifiables.
- En-têtes de réponse HTTP : Last-Modified et ETag permettent au robot d’effectuer des requêtes conditionnelles pour déterminer si la page a changé depuis sa dernière exploration.
- lastmod dans sitemap.xml : indique au robot quelles URL méritent d’être revisitées en priorité.
- Données structurées de la page : les propriétés dateModified et datePublished de Article/BlogPosting permettent au modèle d’identifier les dates de mise à jour et de publication déclarées.
- Date visible sur la page : une mention « Dernière mise à jour » placée au début ou à la fin de l’article est lisible aussi bien par les internautes que par les modèles.
- Actualité intrinsèque du contenu : l’année, le numéro de version et les chiffres les plus récents cités dans l’article doivent correspondre à la date de mise à jour déclarée.
Commencez par corriger les signaux de fraîcheur côté serveur
La plupart des équipes concentrent tous leurs efforts sur le contenu, tout en laissant le serveur renvoyer un en-tête Last-Modified erroné ou absent. C’est à la fois la faille la plus courante et l’une des plus faciles à corriger. La bonne pratique consiste à actualiser Last-Modified chaque fois que le contenu réel de la page change, et à conserver sa valeur précédente tant qu’aucune modification n’a eu lieu. Associé à ETag, qui sert d’empreinte du contenu, cet en-tête permet au robot d’envoyer des requêtes conditionnelles avec If-Modified-Since ou If-None-Match. Si la page n’a pas changé, le serveur répond 304 Not Modified sans retransmettre tout le HTML ; dans le cas contraire, il renvoie un code 200 avec le nouveau contenu. Or de nombreux sites reposant sur des frameworks front-end ou des CDN répondent par défaut 200 à chaque requête, tandis que Last-Modified correspond à l’heure du déploiement. Chaque page donne alors l’impression de venir d’être modifiée, sans qu’aucun changement réel soit détectable : les signaux se contredisent.
Pourquoi les requêtes conditionnelles influencent-elles la fréquence d’exploration ?
Chaque site dispose implicitement d’un budget d’exploration : le robot ne peut pas revenir sans limite. Lorsqu’un serveur peut rapidement signaler l’absence de changement avec une réponse 304, les ressources économisées peuvent être consacrées aux pages réellement mises à jour, ce qui raccourcit leur délai de réexploration. À l’inverse, si le robot doit télécharger la page entière à chaque passage sans pouvoir identifier une date de mise à jour fiable, il finit par considérer les signaux du site comme peu crédibles et espace ses visites. Lors de nos audits GEO, nous constatons fréquemment qu’une fois cette couche corrigée, les pages stratégiques sont réexplorées à des intervalles nettement plus courts.
Le lastmod du sitemap doit refléter la réalité
Le lastmod du sitemap joue un rôle important dans la hiérarchisation des URL par les robots, mais il n’est utile que s’il est exact. Une erreur courante consiste à attribuer la date du jour au lastmod de toutes les URL à chaque déploiement du site. Cela revient à annoncer au robot que l’intégralité du site change quotidiennement. Il constatera rapidement que les contenus n’ont pas évolué, et la crédibilité de tout le sitemap diminuera — y compris celle des pages réellement actualisées. La bonne méthode consiste à calculer, page par page, la date de modification effective du contenu de chaque URL, plutôt qu’à appliquer automatiquement l’heure du build. N’incluez que les URL qui méritent véritablement une nouvelle visite ; évitez de diluer le signal avec des pages de pagination, d’onglets ou de paramètres.
dateModified doit correspondre à la date visible sur la page
La propriété dateModified des données structurées, l’en-tête HTTP Last-Modified, le lastmod du sitemap et la mention visible « Dernière mise à jour » doivent tous renvoyer à la même modification. S’ils se contredisent — le schéma indique aujourd’hui, la page affiche l’année précédente et l’en-tête serveur donne encore une autre date — le modèle ne reçoit que du bruit et adopte, par prudence, une lecture méfiante de vos déclarations de fraîcheur. En pratique, centralisez la date de mise à jour dans une source unique, par exemple l’horodatage de modification réel enregistré dans le système de gestion de contenu, puis utilisez cette donnée pour générer les quatre signaux. Vous éviterez ainsi toute divergence. datePublished conserve la date de publication initiale ; dateModified indique la dernière modification substantielle. Les deux sont nécessaires.
Fréquence de mise à jour : concentrez vos efforts sur les pages qui se périment
Toutes les pages n’ont pas besoin d’être mises à jour fréquemment. Imposer une refonte régulière de tout le site ne ferait que disperser vos ressources de maintenance. Commencez par distinguer deux catégories de contenus. La première regroupe les pages périssables : tarifs, comparatifs de produits, listes d’intégrations, tendances annuelles, réglementations et versions. La seconde rassemble les contenus plus pérennes, comme les définitions et les explications de principes. Planifiez un cycle de vérification régulier pour les pages périssables, actualisez-les dès que l’information change et synchronisez les quatre signaux temporels. Pour les pages pérennes, n’intervenez qu’en cas d’ajout substantiel. Le bon critère n’est pas le calendrier, mais l’existence d’une évolution réelle du contenu. Modifier un seul mot tout en rafraîchissant la date ne trompera pas le modèle et ne renforcera pas sa confiance.
La fraîcheur ne se résume pas à la fréquence des changements. Elle dépend de leur justification et de la concordance des quatre signaux. Le robot accorde sa confiance à un rythme de maintenance prévisible, pas à des modifications fréquentes mais sans substance.— Tenten GEO
Réexploration : vous ne pouvez pas donner d’ordre à Perplexity, mais vous pouvez augmenter vos chances
- Vérifiez que robots.txt ne bloque ni PerplexityBot ni Perplexity-User. Les deux doivent être autorisés, faute de quoi tous les efforts suivants seront vains.
- Après la mise à jour d’une page stratégique, actualisez simultanément son en-tête Last-Modified, son lastmod dans le sitemap et sa propriété dateModified afin que les trois signaux concordent.
- Réduisez le temps de réponse du serveur et renvoyez correctement un code 304 pour les pages inchangées, afin de réserver le budget d’exploration aux pages actualisées.
- Ajoutez, depuis une page à fort trafic et fréquemment explorée, un lien interne vers la page récemment mise à jour. La fréquence de visite de la première accélérera la découverte de la seconde.
- Après la mise à jour, créez de nouveaux points de découverte sur d’autres canaux — vos newsletters, vos communautés ou des pages externes qui vous citent — afin d’augmenter les chances d’une exploration rapide.
Il ne s’agit pas de flatter un algorithme, mais de permettre à Perplexity de détecter rapidement et correctement chaque mise à jour réelle. Sur la plupart des sites, le problème ne tient pas à la qualité insuffisante des contenus : des signaux de fraîcheur contradictoires conduisent plutôt Perplexity à ignorer de bonnes pages parce qu’il les croit anciennes. Pour repérer les incohérences entre Last-Modified, le sitemap, les données structurées et les dates visibles de votre site, réservez un diagnostic GEO de 30 minutes (/contact). Nous vous montrerons directement les écarts de signal susceptibles d’amener Perplexity à écarter vos pages.
