Construire un fichier llms.txt pour un site WordPress multi-auteurs

curl https://exemple.fr/llms.txt — sur beaucoup de sites WordPress à publication distribuée, cette commande renvoie une erreur 404 quelques semaines à peine après l’apparition de la convention, ou pire, un fichier statique rédigé une fois puis jamais mis à jour depuis. Le problème n’est pas la notion elle-même, tout juste proposée dans les discussions autour des moteurs de réponse génératifs, mais sa maintenance sur un site où cinquante contributeurs publient sans coordination éditoriale centrale.

Rédiger ce fichier à la main fonctionne pour un blog personnel. Ça ne fonctionne plus dès que la fréquence de publication dépasse ce qu’un seul rédacteur peut suivre. La solution la plus robuste consiste à générer llms.txt automatiquement à partir de ce que WordPress sait déjà : titres, extraits, catégories, dates de mise à jour — sans dépendre d’un rédacteur qui doit se souvenir de le maintenir.

Ce que contient un llms.txt utile

Le format reste volontairement simple : un titre en Markdown, un court résumé du site, puis une liste de liens organisés par section avec une brève description de chacun. Sur un site multi-auteurs, la vraie difficulté n’est pas la syntaxe mais la sélection : il ne s’agit pas de lister toutes les URLs publiées, mais les pages qui ont une valeur de référence — guides de fond, pages piliers, documentation produit — à l’exclusion des contenus d’actualité éphémères ou des pages utilitaires.

Sur le site testé, le tri s’est fait sur deux critères combinés : les articles marqués dans une taxonomie personnalisée « contenu de référence » et les articles ayant dépassé un seuil de trafic organique sur les douze derniers mois. Aucun de ces critères n’est universel, mais tous deux évitent de générer une liste de plusieurs milliers de liens sans hiérarchie, ce qui rendrait le fichier inutile pour un moteur de réponse comme pour un humain qui l’ouvrirait par curiosité.

Génération automatique depuis les métadonnées existantes

La génération repose sur une fonction PHP déclenchée à intervalle régulier via wp_schedule_event, qui interroge les contenus via WP_Query et reconstruit le fichier statique à la racine. Voici une version simplifiée de la logique :

function wpm_generate_llms_txt() {
    $sections = array(
        'Guides techniques' => 'guide-technique',
        'Documentation produit' => 'documentation',
    );
    $output = "# Mon Site\n\n> Site de référence sur le développement WordPress.\n\n";
    foreach ( $sections as $label => $tax_slug ) {
        $output .= "## {$label}\n\n";
        $posts = get_posts( array(
            'post_type'      => 'post',
            'tax_query'      => array( array(
                'taxonomy' => 'contenu_reference',
                'field'    => 'slug',
                'terms'    => $tax_slug,
            ) ),
            'posts_per_page' => 50,
            'orderby'        => 'modified',
        ) );
        foreach ( $posts as $post ) {
            $excerpt = wp_strip_all_tags( get_the_excerpt( $post ) );
            $output .= "- [{$post->post_title}]({$permalink}): {$excerpt}\n";
        }
        $output .= "\n";
    }
    file_put_contents( ABSPATH . 'llms.txt', $output );
}
add_action( 'wpm_llms_txt_cron', 'wpm_generate_llms_txt' );

Ce squelette se complète en croisant avec le nombre de vues ou une note de qualité éditoriale si le site en tient une. L’essentiel est que le fichier ne dépende d’aucune saisie manuelle a posteriori : il se régénère depuis ce qui existe déjà dans la base.

Maintenir le fichier à jour sans cron additionnel

Sur un site à publication soutenue, attendre un cron quotidien peut laisser le fichier obsolète plusieurs heures. Une alternative consiste à déclencher la régénération directement sur save_post, avec une garde pour éviter de la lancer à chaque sauvegarde de brouillon :

• Vérifier que le statut du contenu est bien publish avant de régénérer
• Limiter la régénération à un appel par minute via un verrou stocké en transient
• Exclure les types de contenu qui ne doivent jamais apparaître dans le fichier (pages légales, brouillons de composants)

Cette approche évite la dérive la plus fréquente observée sur les sites à plusieurs auteurs : un fichier généré une fois, jamais régénéré, qui pointe vers des pages dépubliées ou qui ignore les publications récentes.

Gérer l’hétérogénéité éditoriale

Avec cinquante contributeurs sans charte commune, la qualité des extraits varie énormément : certains rédigent un post_excerpt soigné, d’autres laissent WordPress générer un extrait automatique tronqué au milieu d’une phrase. Le script de génération doit donc appliquer une limite de caractères propre et vérifier la présence d’un extrait manuel avant de se rabattre sur le contenu automatique, sous peine de produire un fichier truffé de phrases coupées qui nuit à la lisibilité pour l’humain comme pour la machine qui le consulte.

En résumé

Sur un site multi-auteurs, un llms.txt rédigé à la main est condamné à devenir obsolète en quelques semaines. La seule approche tenable consiste à le traiter comme un sous-produit automatique des métadonnées existantes, régénéré à chaque publication significative, avec des critères de sélection clairs pour ne pas transformer le fichier en simple sitemap déguisé. La rédaction éditoriale du contenu listé, elle, reste entièrement du ressort des auteurs : le script ne fait que refléter ce qui existe déjà, il ne crée aucune valeur éditoriale par lui-même.