Guillaume Orsal

llms.txt : un standard de documentation pour l'usage des contenus par les modèles d'IA

Guillaume Orsal — 2025-12-30T14:03:07Z

llms.txt est un standard émergent qui permet d'indiquer aux modèles d'IA comment les contenus d'un site web peuvent être utilisés. Cette page détaille le rôle du fichier llms.txt, son fonctionnement, ses principaux cas d'usage, ainsi que ses implications pour l'IA générative, le droit d'auteur et la notion de consentement des données.

Faut-il mettre en place un fichier llms.txt sur son site ? À quoi sert-il vraiment, et est-ce que les IA le respectent ? Tour d'horizon concret de ce standard émergent, entre bonnes pratiques, limites réelles et usages possibles.

TL ;DR

llms.txt est un fichier texte placé à la racine d'un site web (/llms.txt) permettant de documenter, de façon déclarative, les conditions d'utilisation de ses contenus par des modèles d'IA (LLMs). Ce standard émergent vise à améliorer la transparence entre créateurs de contenu et développeurs d'IA, sans mécanisme technique contraignant. Il permet notamment d'autoriser l'entraînement des modèles tout en en fixant les limites (usage commercial, attribution, données sensibles). Il s'inscrit dans la continuité des standards du web ouvert comme robots.txt ou Humans.txt.

Introduction : llms.txt, un standard émergent pour l'ère de l'IA générative

Avec la généralisation des modèles de langage de grande taille (Large Language Models, ou LLMs), une question devient centrale : comment les créateurs de contenu peuvent-ils indiquer aux systèmes d'IA les conditions d'utilisation de leurs données ?

Le fichier llms.txt est une proposition de standard visant à répondre à ce besoin. Il permet à un site web de documenter, de manière lisible par des agents automatisés, ses préférences concernant l'utilisation de ses contenus par des modèles d'IA.

L'objectif n'est pas d'imposer un mécanisme technique de contrôle, mais de fournir un cadre déclaratif, simple et décentralisé, que les développeurs d'IA peuvent choisir de respecter.

Contexte : pourquoi llms.txt a émergé

L'explosion des LLMs et des données d'entraînement

Depuis 2023, avec la démocratisation de modèles comme ChatGPT, les LLMs sont entraînés sur des volumes massifs de données issues du web public.

Concrètement, cela signifie que des contenus peuvent être réutilisés pour entraîner des modèles sans que leurs auteurs aient forcément été informés, ni même qu'ils aient eu l'occasion d'exprimer une position sur cet usage.

Ce flou pose un problème assez basique : il n'existe pas vraiment de moyen standard pour dire ce qui est acceptable ou non. Côté créateurs, difficile d'indiquer des conditions d'utilisation claires. Et côté développeurs, tout aussi difficile de savoir sur quelles bases ils peuvent s'appuyer pour utiliser ces contenus.

L'insuffisance des outils existants

robots.txt permet de réguler l'exploration des pages par des moteurs de recherche, mais ne s'applique pas explicitement aux usages liés à l'entraînement des modèles d'IA. Les balises offrent une granularité limitée et ne couvrent pas les cas d'usage spécifiques aux LLMs.

llms.txt propose une approche complémentaire : un fichier placé à la racine du site (/llms.txt), destiné à être consulté par des agents IA pour comprendre les règles d'usage déclarées par le propriétaire du contenu.

Qu'est-ce que llms.txt et comment l'utiliser

Le fichier llms.txt est un document texte simple, accessible publiquement, qui permet de documenter les politiques d'utilisation des contenus d'un site par des systèmes d'IA et des LLMs.

Il ne constitue ni une obligation légale, ni une barrière technique, mais un mécanisme de transparence destiné à faciliter le respect des préférences exprimées par les créateurs.

Ce que permet concrètement llms.txt

Contrairement à une idée assez répandue, llms.txt ne sert pas uniquement à interdire l'entraînement.

Son intérêt est justement de permettre des positions plus nuancées. On peut très bien autoriser l'entraînement des modèles, tout en encadrant les usages qui en sont faits ensuite. Par exemple, accepter un usage dans un cadre de recherche ou d'indexation, mais refuser une exploitation commerciale directe ou une intégration dans un modèle propriétaire.

De la même manière, il devient possible de poser des conditions d'attribution explicites, ou d'exclure certaines catégories de données, notamment lorsqu'elles sont personnelles ou sensibles.

Selon les cas, on peut aussi aller plus loin et définir des règles différentes en fonction des acteurs ou des types de modèles, même si ce point reste encore assez informel aujourd'hui.

Structure recommandée (exemple indicatif)

Le format suivant est une proposition illustrative, inspirée de mises en œuvre réelles. Il ne s'agit pas d'une spécification officielle et peut évoluer.

# llms.txt – AI usage policy (example)
 
 [Preferences]
 Allow-LLM-Training: true
 Allow-Document-Indexing: true
 Allow-LLM-Scraping: true
 Allow-Embedded-LLM-Training: false
 
 [Restrictions]
 Content-Restrictions: commercial-use-restriction, copyright-sensitive
 Sensitive-Data: excluded
 
 [Rules]
 GPT-4: allow-training, allow-indexing
 Claude: allow-training, allow-indexing
 OpenSource-Models: allow-training
 
 [Attribution-Requirements]
 Citation-Required: true
 Attribution-Format: Author, Date, URL
 
 [Contact]
 Email: contact@example.com
 
 [Last-Updated]
 Date: 2026-01-04
 Version: 1.1

Explication des principaux champs

Les principaux champs utilisés restent assez simples à comprendre, même sans spécification formelle :

Allow-LLM-Training : autorise l'utilisation du contenu pour l'entraînement des modèles d'IA
Allow-Embedded-LLM-Training : interdit l'intégration directe du contenu dans des modèles propriétaires fermés
Allow-Document-Indexing : autorise l'usage pour des systèmes de récupération de documents (RAG)
Sensitive-Data : exclut explicitement toute donnée personnelle ou sensible
Rules : permet de définir des règles spécifiques par acteur ou type de modèle
Citation-Required : rend l'attribution obligatoire pour tout usage

L'ensemble reste volontairement simple, l'objectif étant d'être lisible plutôt qu'exhaustif.

Pourquoi implémenter llms.txt

Pour les créateurs de contenu

Pour un créateur de contenu, l'intérêt de llms.txt est surtout de pouvoir reprendre la main sur quelque chose qui, jusqu'ici, restait implicite.

On peut autoriser l'entraînement sans pour autant accepter tous les usages derrière. Cela permet par exemple de poser des limites sur l'exploitation commerciale, de clarifier les conditions d'attribution, ou simplement d'exprimer une position sur la manière dont ses contenus peuvent être réutilisés.

Au-delà de l'aspect juridique, il y a aussi une logique de transparence. Formaliser ces règles, même de manière déclarative, revient à rendre explicite ce qui ne l'était pas.

Pour les développeurs d'IA

Côté développeurs, l'intérêt est différent mais complémentaire.

Disposer d'un fichier llms.txt permet d'identifier plus facilement les contenus qui peuvent être utilisés, et dans quelles conditions. Dans un contexte où les questions de droit d'auteur et de responsabilité sont de plus en plus présentes, ce type d'information devient utile pour cadrer les pratiques.

Cela ouvre aussi la voie à des processus plus traçables, où les sources et les conditions d'utilisation ne sont plus complètement implicites.

Bonnes pratiques

Dans la pratique, l'enjeu principal est d'éviter toute ambiguïté.

Un llms.txt efficace est d'abord un fichier explicite et cohérent. Il doit distinguer clairement les différents usages — entraînement, indexation, intégration — sans introduire de contradictions.

Lorsque le contenu est amené à être réutilisé, il est généralement pertinent de préciser les attentes en matière d'attribution. De la même manière, les données sensibles devraient être exclues sans ambiguïté.

Enfin, comme pour les autres fichiers de ce type, il est utile de maintenir le document à jour et de l'inscrire dans un ensemble plus large, aux côtés de robots.txt, Humans.txt ou security.txt.

Implémentation technique

Création du fichier

Créer un fichier texte nommé llms.txt à la racine du site (/llms.txt).

Vérification de l'accessibilité

curl -I https://www.example.com/llms.txt
 # Doit retourner : 200 OK

Lien optionnel depuis le site

Ou via un lien visible :

Politique d'utilisation IA (llms.txt)

Adoption et perspectives

llms.txt reste aujourd'hui un standard émergent, apparu autour de 2023–2024, et dont l'adoption est encore assez hétérogène.

Il n'existe pas, à ce stade, de reconnaissance formelle par un organisme de standardisation. Pour autant, la dynamique n'est pas nouvelle : on retrouve un schéma assez proche de celui de robots.txt à ses débuts, avec une adoption progressive portée par les usages, avant une éventuelle normalisation.

Dans le même temps, les évolutions réglementaires, notamment en Europe avec l'AI Act, pourraient renforcer l'intérêt de ce type de mécanisme déclaratif. Sans forcément le rendre obligatoire, elles contribuent à installer l'idée qu'une certaine transparence sur l'usage des données devient nécessaire.

Limitations et considérations

llms.txt présente aujourd'hui des limites qu'il vaut mieux avoir en tête dès le départ.

D'abord, son respect repose entièrement sur la bonne volonté des acteurs qui choisissent de le consulter. Il n'existe aucun mécanisme technique permettant de s'assurer qu'un agent s'y conforme réellement.

Ensuite, le fichier ne prévoit pas de système d'authentification. En pratique, il est donc impossible de distinguer de manière fiable les différents types d'agents ou de vérifier leur identité.

Enfin, la granularité reste assez limitée. Les règles s'appliquent globalement au site, sans possibilité fine de définir des politiques différentes selon les pages ou les sections.

Ces limites n'enlèvent pas tout intérêt au fichier, mais elles rappellent qu'il s'agit avant tout d'un outil de transparence, et non d'un dispositif de contrôle.

Conclusion : une ouverture encadrée plutôt qu'un refus global

llms.txt n'est pas un outil de blocage, mais un moyen d'exprimer clairement des conditions d'utilisation raisonnées.

Il permet d'autoriser l'entraînement des modèles d'IA tout en en fixant les limites : attribution, respect du droit d'auteur, exclusion des données sensibles et refus de certaines intégrations propriétaires.

À l'image de robots.txt ou Humans.txt, llms.txt s'inscrit dans la tradition du web ouvert : un écosystème fondé sur des conventions partagées, la transparence et la responsabilité.

Ressources et références

Site officiel llmstxt.org

Voir aussi

Humans.txt

Obfuscation d'email : CSS vs JavaScript, amélioration des performances SEO (LCP, CLS)

Guillaume Orsal — 2025-12-06T17:20:00Z

Lors d'une analyse de performance web, un JavaScript chargé uniquement pour l'obfuscation d'une adresse email a été identifié comme inutile. Cet article présente une alternative basée sur du CSS pur, puis une solution côté serveur permettant d'améliorer les performances SEO (LCP, CLS) tout en préservant l'expérience utilisateur, notamment sur mobile.

Pourquoi l'obfuscation d'email pose un problème de performance

L'obfuscation d'email, qui désigne les techniques utilisées pour rendre une adresse moins directement exploitable par des robots tout en restant lisible pour un humain, est une problématique ancienne du web. Historiquement, elle a souvent été traitée via du JavaScript chargé au runtime pour reconstruire une adresse ou un lien mailto:.

Même si ce type de script n'a pas toujours un impact mesurable immédiat sur les Core Web Vitals, il alourdit la page en ajoutant une ressource non essentielle. Il complexifie le rendu côté client, introduit des dépendances évitables et peut dégrader marginalement le LCP sur des pages simples. À cela s'ajoute un effet sur la lisibilité du code, ce qui nuit à long terme à la maintenabilité.

Dans une démarche d'optimisation SEO moderne, chaque ressource doit justifier sa présence.

Rappel : Core Web Vitals et performance perçue

Les Core Web Vitals sont un ensemble d'indicateurs définis par Google pour évaluer la qualité de l'expérience utilisateur réelle. Ils ne mesurent pas uniquement la rapidité brute, mais la perception du chargement et la stabilité de l'interface.

Le LCP (Largest Contentful Paint) reflète la vitesse d'affichage du contenu principal.

Le CLS (Cumulative Layout Shift) mesure la stabilité visuelle de la page.

Un script JavaScript non essentiel peut retarder légèrement le rendu initial ou provoquer des recalculs inutiles.

Même lorsqu'un script n'entraîne pas de dégradation mesurable immédiate, sa suppression simplifie la chaîne de rendu et améliore la performance perçue, en particulier sur mobile. Ces principes s'inscrivent dans les recommandations de Google pour favoriser des pages rapides, stables et adaptées à l'indexation mobile-first.

Réduire le JavaScript pour améliorer le SEO technique

La performance web ne se résume pas à un score PageSpeed. Elle repose sur plusieurs principes clés : limiter le JavaScript non essentiel, réduire le travail du navigateur, stabiliser l'affichage pour éviter les décalages visuels (CLS) et améliorer la performance perçue, notamment sur mobile.

Supprimer un script inutile est souvent l'une des optimisations les plus simples et les plus efficaces.

Obfuscation d'email sans JavaScript : approche CSS

Il est possible d'afficher une adresse email sans qu'elle soit directement exploitable dans le code source, en utilisant uniquement du HTML et du CSS, sans JavaScript côté client.

La technique consiste à découper l'email dans des attributs data-*. Le CSS se charge ensuite de masquer le placeholder, et de reconstituer le contenu visible à partir des attributs. Ainsi, il n'y a plus de code côté client qui réalise le masquage de l'information.

Structure HTML

L'email est découpé en deux parties stockées dans des attributs data-*.

Il n'apparaît jamais directement sous forme exploitable dans le HTML.

L'application de la classe de style masque le contenu initial et reconstruit l'affichage via le CSS.

Le texte présent dans le reste dans le DOM mais n'est plus visible.

 data-email-user="guillaume"
 data-email-domain="orsal.net">
 [email protected]

Feuille de style CSS

/* Masque le contenu initial du bloc */
 .protected-email {
 font-size: 0;
 }
 
 /* Reconstruit visuellement l'email à partir des attributs data-* */
 .protected-email::before {
 font-size: 14px;
 content: attr(data-email-user) "@" attr(data-email-domain);
 }

Le choix de font-size: 0 masque le texte sans modifier la structure du DOM ni provoquer de recalcul de layout.

Bénéfices en termes de performance et de référencement

Cette solution présente plusieurs avantages du point de vue SEO et performance.

Il n'y a aucun JavaScript à charger ou exécuter, l'impact est donc nul sur le LCP et le CLS, le rendu est immédiat sans recalcul.

La compatibilité est maximale avec les navigateurs et la lecture reste possible par les moteurs de recherche.

Enfin, elle continue d'offrir une protection suffisante contre les collectes automatisées basiques des robots et s'inscrit dans une logique de sobriété et d'optimisation structurelle du front-end.

Limite fonctionnelle : l'expérience utilisateur sur mobile

Cette approche purement CSS présente toutefois une limite : l'adresse email affichée n'est pas cliquable.

Sur desktop, cela peut être acceptable. Sur mobile, l'utilisateur s'attend à ce qu'un email soit interactif et ouvre son client de messagerie.

Une optimisation technique ne doit pas se faire au détriment de l'expérience utilisateur.

Rétablir l'UX sans JavaScript : redirection côté serveur

Pour concilier performance, UX et protection minimale contre les bots, une solution consiste à utiliser une redirection côté serveur vers un lien mailto:.

L'email n'est jamais exposé sous forme de lien dans le HTML, et aucune logique JavaScript n'est ajoutée.

Script de redirection contact.php

 // Désactivation explicite du cache HTTP
 header('Cache-Control: no-cache, no-store, must-revalidate');
 header('Pragma: no-cache');
 header('Expires: 0');
 
 // Redirection vers le mailto
 header('Location: mailto:email@example.com?subject=contact');
 exit;
 ?>

Les en-têtes HTTP désactivant le cache sont essentiels. Une redirection mise en cache par un navigateur, un proxy ou un CDN pourrait conserver un comportement obsolète, ignorer une évolution future ou introduire des effets de bord difficiles à diagnostiquer.

Le script ne prend volontairement aucun paramètre utilisateur afin de limiter les risques d'abus, de détournement, ou d'envoi involontaire vers un point d'entrée exploitable.

Utilisation côté HTML

L'email masqué est ensuite encapsulé dans un lien pointant vers le script de redirection.


 
 [email protected]

Le lien est marqué en nofollow car l'objectif est uniquement l'action utilisateur, pas le référencement du script.

Conclusion

Cette approche supprime une dépendance JavaScript inutile, ce qui contribue à préserver des indicateurs tels que le LCP et le CLS. L'interactivité attendue sur mobile est également préservée, tout comme la limitation de l'exposition de l'adresse email. Le code obtenu est simple, maintenable et élégant.

L'optimisation des performances web et du référencement repose parfois sur des choix simples et structurants.

Réduire le JavaScript non essentiel en exploitant les capacités du CSS aura permis ici d'améliorer à la fois le SEO technique et la performance perçue, sans modifier l'expérience utilisateur.

Audit SEO : détecter les pages avec une balise noindex via script automatisé

Guillaume Orsal — 2024-12-08T14:05:07Z

En examinant la Google Search Console d'un site récemment, j'ai remarqué que certaines pages étaient non indexées à cause d'une balise noindex. Ces balises sont des balises meta . Comme je ne savais pas exactement quelles pages étaient concernées, j'ai décidé de créer un script simple pour parcourir le site et identifier toutes les pages contenant cette balise.

Dans cet article, je partage avec vous ce script et explique comment l'utiliser pour détecter les pages avec une balise noindex. Cela peut vous être utile si, comme moi, vous souhaitez corriger ce type de problème pour améliorer l'indexation de votre site par les moteurs de recherche.

Introduction : identifier les barrières d'indexation

La balise noindex est un élément clé de la gestion du SEO. Elle signale aux moteurs de recherche que certaines pages ne doivent pas être indexées, ce qui peut impacter significativement votre visibilité organique si utilisée à mauvais escient. Lors d'audits SEO, il est courant de découvrir des balises noindex involontaires ou mal configurées qui nuisent à l'indexation de pages stratégiques.

Cet article présente une approche automatisée pour parcourir un site et identifier toutes les pages contenant une balise noindex. Cette technique est indispensable pour diagnostiquer les problèmes d'indexation signalés dans la Google Search Console et évaluer si chaque balise noindex est justifiée.

Comprendre la balise noindex et ses impacts

La balise noindex est une directive du protocole robots placée dans la section d'une page HTML. Elle se présente sous la forme :

Ou de manière plus complète :

Impact sur l'indexation : Une page avec noindex est indexée temporairement par Google (pour vérifier la balise), puis supprimée des résultats de recherche après quelques semaines. Ce processus peut causer des fluctuations dans votre classement et votre couverture indexée.

Quand noindex est justifiée :
Pages de test ou développement
Contenus en double (variantes de filtre, paramètres d'URL)
Pages archivées ou dépréciées intentionnellement
Pages avec contenu sensible non destiné au public

Quand noindex pose problème :
Appliquée accidentellement à des pages stratégiques
Pré-configurée sur un thème ou un CMS
Résultant de migrations mal gérées
Présente dans une feuille de style CSS appliquée globalement

Diagnostic : automatiser la détection noindex

Plutôt que d'inspecter manuellement chaque page, un script d'audit permet un diagnostic rapide et complet. Voici un script shell Linux qui télécharge votre site et identifie toutes les pages avec noindex.

Script de détection noindex complet

#!/bin/bash
 
 # ============================================
 # Script d'audit SEO : détection des balises noindex
 # Utilisation : ./script.sh https://www.exemple.com [PROFONDEUR]
 # ============================================
 
 # Vérifier si une URL a été fournie
 if [ -z "$1" ]; then
 echo "Usage: $0  [PROFONDEUR]"
 echo "Exemple : $0 https://www.exemple.com 3"
 exit 1
 fi
 
 SITE_URL="$1"
 DEPTH=${2:-2} # Profondeur par défaut : 2
 OUTPUT_DIR="site_scan_$(date +%s)"
 NOINDEX_FILE="noindex_pages_$(date +%Y%m%d_%H%M%S).txt"
 
 # Créer un répertoire temporaire pour stocker les pages
 mkdir -p "$OUTPUT_DIR"
 echo "[*] Création du répertoire : $OUTPUT_DIR"
 echo "[*] Profondeur de parcours : $DEPTH"
 
 # Télécharger le site avec wget
 # --mirror : mode miroir (télécharge récursivement)
 # --convert-links : convertit les liens pour navigation locale
 # --adjust-extension : ajoute .html si nécessaire
 # --page-requisites : télécharge les ressources (CSS, JS, images)
 # --no-parent : n'explore pas les répertoires parents
 # --level : limite la profondeur de récursion
 echo "[*] Téléchargement du site en cours..."
 wget --mirror \
 --convert-links \
 --adjust-extension \
 --page-requisites \
 --no-parent \
 --level="$DEPTH" \
 "$SITE_URL" \
 -P "$OUTPUT_DIR" \
 --quiet
 
 # Rechercher les pages contenant la balise noindex
 echo "[*] Analyse des pages pour détecter noindex..."
 find "$OUTPUT_DIR" -type f -name "*.html" | while read -r file; do
 # Regex expliquée :
 # ]* : ouverture de la balise meta (accepte tous les attributs)
 # name="robots" : recherche l'attribut name avec la valeur robots
 # [^>]* : accepte d'autres attributs (ex: http-equiv)
 # content="[^"]*noindex : vérifie que noindex est dans l'attribut content
 
 if grep -qi ']*name="robots"[^>]*content="[^"]*noindex' "$file"; then
 echo "Page avec noindex trouvée : $file"
 echo "$file" >> "$NOINDEX_FILE"
 fi
 done
 
 # Afficher les résultats
 echo ""
 echo "[*] Résultats :"
 if [ -f "$NOINDEX_FILE" ]; then
 count=$(wc -l < "$NOINDEX_FILE")
 echo "⚠️ $count page(s) contenant une balise noindex détectée(s)"
 echo "📄 Fichier de résultats : $NOINDEX_FILE"
 echo ""
 echo "=== PAGES AVEC NOINDEX ==="
 cat "$NOINDEX_FILE"
 else
 echo "✓ Aucune balise noindex n'a été trouvée."
 fi

Utilisation du script

1. Rendre le script exécutable

chmod +x script_noindex.sh

2. Lancer l'audit

Avec une profondeur par défaut (2 niveaux) :

./script_noindex.sh https://www.exemple.com

Avec une profondeur personnalisée (ex : 4 niveaux pour un gros site) :

./script_noindex.sh https://www.exemple.com 4

3. Consulter les résultats

Le script génère un fichier noindex_pages_YYYYMMDD_HHMMSS.txt contenant la liste des pages affectées. Ouvrez ce fichier pour identifier les problèmes.

Interprétation des résultats et diagnostic

Cas 1 : Pages intentionnellement en noindex Si vous trouvez des pages avec noindex que vous aviez volontairement marquées, c'est normal. Vérifiez simplement que chacune de ces pages mérite réellement cette balise.

Cas 2 : Pages stratégiques affectées Si le script détecte noindex sur des pages que vous souhaitez indexer :
Vérifiez la source du problème : CMS, thème, configuration serveur, ou erreur humaine
Supprimez ou modifiez la balise en noindex, nofollow vers index, follow ou supprimez-la complètement
Forcez une exploration Google en soumettant l'URL via la Search Console

Cas 3 : Aucune balise noindex détectée Excellent ! Mais assurez-vous que le site était complet. Vérifiez la profondeur utilisée et augmentez-la si certaines sections ne sont pas explorées.

Limitations et considérations importantes

Respect de robots.txt : Le script wget respecte le fichier robots.txt de votre site. Si des pages sont bloquées par robots.txt, elles ne seront pas téléchargées. Modifiez la commande wget avec —execute robots=off si vous voulez ignorer robots.txt (à utiliser avec prudence).

Sites très volumineux : Pour les sites avec des milliers de pages, augmenter la profondeur peut être très long. Envisagez de limiter le domaine ou d'utiliser des crawleurs SEO professionnels comme Screaming Frog pour les audits complets.

Pages dynamiques : Ce script capture le HTML statique. Les pages générées en JavaScript côté client ne seront pas correctement analysées. Pour les sites single-page application (SPA), utilisez des outils comme Puppeteer ou Playwright.

Authentification requise : Si votre site demande une authentification, le script ne peut pas y accéder. Vous devrez ajuster wget pour fournir des identifiants ou tester manuellement.

Bonnes pratiques pour la gestion de noindex

1. Documentez vos décisions : Maintenez un registre des pages intentionnellement en noindex et des raisons sous-jacentes 2. Auditez régulièrement : Relancez ce script trimestriellement pour détecter toute dégradation 3. Validez en Search Console : Utilisez l'onglet « Couverture » pour croiser les résultats et identifier les pages non indexées pour d'autres raisons 4. Privilégiez disallow dans robots.txt : Pour les pages vraiment privées, robots.txt est plus approprié que noindex 5. Testez avant déploiement : Utilisez une branche de staging pour valider vos changements avant production

Conclusion

La détection automatisée des balises noindex est une étape critique d'un audit SEO complet. Ce script vous permet d'identifier rapidement les problèmes d'indexation et de prendre les mesures correctives nécessaires. En combinant cet outil avec la Search Console et une bonne compréhension des impacts, vous pouvez optimiser considérablement votre couverture indexée et votre visibilité organique.

L'important est de maintenir un équilibre : bloquer intentionnellement ce qui doit l'être, tout en assurant que vos pages stratégiques restent pleinement accessibles aux moteurs de recherche.

SERP, SPIP, breadcrumb et SEO

Guillaume Orsal — 2018-04-24T12:48:43Z

Vous avez peut-être déjà remarqué que les SERP de Google ont souvent un affichage différent. Les SERP, pour Search Engine Result Page, ce sont les pages résultats d'un moteur de recherche.

La variation qui m'intéresse ici est la ligne qui contient traditionnellement l'url de la page, la petite ligne verte. Parfois, elle se présente sous la forme d'un fil d'ariane, qui reprend le fil d'ariane présent sur la page. Je trouve cela plus parlant pour la personne qui fait une recherche, alors voyons comment mettre ça en place. [sommaire]

Web sémantique & schema.org

Bon, aujourd'hui il y a des projets de voiture autonome sans pilote plutôt bien avancés. Mais voilà, un moteur de recherche n'arrive pas encore à détecter et lire tout seul le fil d'ariane et il va falloir l'aider. Pour cela on va utiliser le Web sémantique. Nous allons ajouter des balises dans les pages Web qui vont donner du sens au contenu en ajoutant des meta informations qui permettent aux moteurs de recherche de mieux comprendre le contenu des pages Web.

Il existe plusieurs systèmes de balises comme microformats ou Dublin core, mais je vais utiliser schema.org car il me semble être mieux reconnu par Google. D'ailleurs c'est celui qu'ils utilisent dans leurs exemples.

Ces différents systèmes ne sont pas incompatibles entre eux, bien au contraire, je vous invite à tous les utiliser sur vos pages Web pour améliorer votre référencement. Ils permettent de représenter de manière structurée plein de types d'information. Cela dépasse le cadre de cet article, et nous allons nous focaliser sur les BreadcrumbList. « Breadcrumb trail » c'est le terme anglais pour désigner le fil d'Ariane sur les pages Web.

Prenons un exemple

Voici un exemple de fil d'ariane :

Accueil > SEO > Web sémantique > SERP, SPIP et breadcrumb

Schema.org définit donc une structure pour les breadcrumb, c'est à dire une liste et une hiérarchie d'information qui permet de définir un fil d'Ariane et ses éléments. Pour faire simple, je vais me limiter ici aux champs obligatoires ou les plus pertinents : le nom, l'url et la position. En explorant le site de schema.org, vous pourrez découvrir tout ce qu'il est possible de paramétrer.

Les éléments de mon exemple se définissent alors ainsi :

nom	url	position
Accueil	https://www.orsal.fr/	1
SEO	https://www.orsal.fr/seo/	2
Web sémantique	https://www.orsal.fr/seo/web-semantique/	3
SERP, SPIP et breadcrumb	https://www.orsal.fr/seo/web-semant...	4

Il va falloir transformer la gestion du fil d'Ariane en place sur un site SPIP pour obtenir une liste avec les informations ajoutées. Initialement le code HTML pour mon fil d'Ariane ressemble à cela :


 Accueil >
 SEO >
 Web sémantique >
 SERP, SPIP et breadcrumb

L'objectif est de transformer la génération du bloc dans le squelette SPIP pour obtenir ce type de bloc :


 
 
 
 Accueil
 
 
 

 
  > 
 
 SEO
 
 
 

 
  > 
 
 Web sémantique
 
 
 

 
  > 
 
 
 SERP, SPIP et breadcrumb

Il s'agit d'une liste de liens. Voici comment la lire.

Les données structurées schema.org sont les propriétés itemprop, itemscope et itemtype :

itemscope indique que le bloc html courant correspond à un bloc schema.org
itemtype permet de préciser le type du bloc schema.org courant
itemprop définit une propriété du bloc courant

C'est récursif, un bloc peut se retrouver l'enfant d'un autre.

Ainsi le bloc

BreadcrumbList

à un itemListElement enfant de la BreadcrumbList, de type ListItem. C'est pas clair ? Relisez doucement le source HTML, ça va venir.

En plaçant la propriété item sur la balise , cela permet de définir une propriété de type url. J'ai ajouté un bloc , juste pour porter la propriété name. Enfin pour la position, comme je n'avais pas d'élément où l'insérer, j'ai directement ajouté un bloc , qui ne s'affichera donc pas, mais sera bien présent dans le code.

Google et les données structurées

La liste des champs/propriétés possibles sont disponibles sur le site de schema.org.

Une liste plus synthétique des champs recommandés ou obligatoires, sont disponibles dans les directives pour les données structurées définies par Google.

En utilisant des données structurées sur votre site, vous améliorez la compréhension de votre site par les moteurs de recherche, donc vous en améliorez le référencement, et vous bénéficiez parfois d'un affichage optimisé (rich snippet) dans les résultats de recherche, comme l'affichage des notes sur des produits, ou les éléments d'une recette.

Outil indispensable lorsque vous travaillez les données structurées, Google propose un analyseur de code source qui vous montre le résultat de la détection par le moteur de recherche des balises sémantiques, pour tester vos données structurées.

Il vous indiquera également les erreurs que vous auriez pu commettre dans l'enchaînement des blocs. Utilisez-le pour débugger vos balises.

Pas de jaloux, les données structurées fonctionnent également chez Microsoft Bing et Yandex, entre autres.

SPIP et les données structurées

L'objectif est d'intégrer ceci à un site SPIP. J'ai fait la modification sur les pages article et rubrique pour lesquelles je voyais un intérêt à avoir un fil d'Ariane.

Pour cela, j'ai copié les fichiers article.html et rubrique.html que j'ai trouvés dans le répertoire de mon thème actuel, vers le répertoire squelette/contenu/ du site, pour surcharger les squelettes.

J'ai ensuite rechercher et remplacer le bloc hiérarchie présent dans les fichiers. Voici le morceau de squelette qui permet de générer le fil d'Ariane avec les méta données.
[(#REM) Fil d'Ariane ] <:accueil_site:> > [(#TITRE|couper{80})] [ > (#TITRE|couper{80}) ]
Le bloc
1. qui le constitue correspond à un niveau hiérarchique.
  
  Le premier élément
2. correspond à la page d'accueil. La position du premier élément doit être égale à 1.
  
  Ensuite on entre dans une boucle sur la hiérarchie des rubriques entre l'accueil du site et la page courante. Pour chaque niveau, on retrouve un bloc
3. . La position est calculée sur la balise SPIP #COMPTEUR_BOUCLE qui nous donne le numéro d'itération. On ajoute 1, avec le filtre plus {1} car le premier c'est la page d'accueil.
  
  A partir de SPIP 3.0, il existe la balise #PROFONDEUR qui indique la profondeur d'une rubrique, mais la numérotation commence à 0, et la position attendue pour le premier élément est 1. Donc je préfère garder mon système de comptage sur la boucle qui fonctionne pour toutes les versions de SPIP.
  
  Enfin, pour le dernier élément du fil d'Ariane, il s'agit de la page actuellement visitée, j'ai utilisé un lien vers la page courante pour ajouter du maillage interne important en SEO. J'ai placé le code dans le bloc optionnel, entre la balise fermante et la balise fermante , pour que la balise #TOTAL_BOUCLE contienne le nombre d'éléments trouvés dans la hiérarchie. Cela va permettre de calculer la position du dernier élément, via le filtre plus {2}.
  
  De plus ce bloc est entre crochet pour que les balises et filtres soient remplacés et calculés lors de la génération de la page.
  
  Une fois que vous avez apporté la modification sur les deux squelettes, il n'y a plus qu'à recalculer la page et vider le cache, et enfin attendre que les moteurs de recherche fassent la mise à jour.
  
  CSS & fil d'ariane
  
  Si tout s'est bien passé, vous devez obtenir une liste ordonnée qui correspond à votre fil d'Ariane. Mais pour l'instant les éléments sont les uns en dessous des autres, avec une numérotation.
  
  Pour modifier cela, j'ai utilisé un peu de CSS, dans le fichier squelette/perso.css pour surcharger le style de mon thème.
  
  #hierarchie li { list-style-type: none; margin-left: 0; display: inline; }
  
  Cela correspond à :
  - list-style-type permet de masquer la numérotation
  - margin-left permet de supprimer le décalage de la numérotation
  - display permet d'afficher chaque élément du fil d'Ariane sur la même ligne à la suite
  Pensez à rafraîchir le cache pour vérifier les modifications.
  
  Pour aller plus loin
  
  N'oubliez pas de tester le résultats de vos modifications avec l'outil de Google, pour vérifier qu'il détecte bien tous vos champs. Vous découvrirez au passage peut-être d'autres balises déjà présentes sur la page.
  
  Le champ des possibles avec les données structurées est immense et reconnu par tous les moteurs de recherche. N'hésitez pas à en abuser sur vos pages.

Sitemap avec images pour SPIP

Guillaume Orsal — 2014-11-09T14:20:00Z

Le sitemap par défaut de SPIP contient peu d'information. Les plugins de sitemap que j'ai trouver ne proposaient pas l'intégration des images dans le sitemap.

Pour améliorer le référencement naturel de mes sites SPIP, j'ai donc cherché à intégrer les images puisque Google fait la distinction lors de son intégration.

Petit rappel sur les sitemaps

Pour ceux qui ne sauraient pas ce qu'est un sitemap, il s'agit un fichier standardisé qui permet aux moteurs de recherche d'obtenir la liste du contenu de votre site : pages, images et vidéos.

Vous trouverez plus d'explication sur la structure de ce fichier directement sur le site sitemaps.org.

Le fichier sitemap joue un rôle important dans la qualité du référencement d'un site web. Il faut donc s'assurer que le fichier soit présent, correctement construit, et enfin, il faut indiquer sa présence aux moteurs de recherches, par exemple, en utilisant Google Webmaster Tools.

Images sous Google Webmaster Tools


Intégration des sitemaps dans Google Webmaster Tools: Intégration des images dans les sitemaps sous l'interface de Google Webmaster Tools

L'outil d'aide au référencement de Google, fait justement la distinction entre les pages web et les images qu'il a indexé, comme indiqué sur l'image ci-dessus.

Il est intéressant d'indexer également les images, car c'est un moyen d'améliorer la longue traîne. En ayant plus d'éléments référencés, cela augmente les possibilités d'arriver sur votre site, donc à terme les visites.

Vérifier l'indexation des images

Pour voir si Google indexe vos images, rien de plus simple. Une petite requête avancée via la recherche d'images en utilisant le paramètre inurl: suivi de l'url de votre site, vous donnera une idée de ce qui est pris en compte.

Exemple : inurl:www.orsal.fr

Dans mon cas, au moment de la rédaction de cet article, ce n'était pas brillant, aucun résultat, et ce, malgré que le site soit plutôt bien référencé dans la recherche Web.

Aucune image ne correspond à votre recherche (inurl :www.orsal.fr).

Mon site utilise SPIP, un outil de gestion de contenu. Pour optimiser l'affichage des pages, l'outil utilise un système de cache. Les liens vers les images à l'intérieur des pages pointent donc vers le répertoire du cache. Or ce répertoire est bloqué aux moteurs de recherche via le fichier robots.txt qui n'indexent donc pas les images.

Je pouvais donc débloquer l'accès, mais à chaque rafraîchissement du cache, les liens vers les images auraient changé. Le référencement serait à chaque fois perdu et cela aurait généré de nombreuses erreurs 404.

L'autre solution était de comprendre comment fonctionne la génération des sitemaps sous SPIP pour intégrer directement les liens vers le fichier image et non vers le cache.

SPIP et les sitemaps

Le sitemap par défaut, contient la liste des articles, la fréquence de modification pour le sommaire, et la date de dernière modification pour les articles qui ont moins de 24h. Pourtant le standard autorise bien d'autres informations, notamment les images.

Un plugin pour SPIP existe, Sitemap-Google, avec de bonnes idées, notamment pour la gestion de la priorité en utilisant la popularité de l'article. Le code source du plugin est d'ailleurs plus précis que ce qui est présenté dans l'article. Mais ce plugin ne gère pas les images.

Etat de l'art

Parmi les articles les plus intéressants sur le sujet que j'ai pu trouvé, une très bonne explication par Organic Web et de bonnes idées de solutions dans l'article Images, sitemaps et SPIP. Je vais reprendre leur fonction url_de_logo, mais leur solution ne fonctionne pas bien chez moi, ou pas tout à fait comme je le voudrais. Alors, je vais devoir l'adapter.

Cet article se base lui-même sur un article précédent paru sur le site Abondance. Très succinct. L'article donne juste un aperçu de ce à quoi doit ressembler le sitemap. Dans un autre article du site Abondance, toujours aussi court, Olivier Andrieu présente même l'intégration des vidéos dans les sitemaps, qui est directement tiré de l'explication sur l'intégration des différents formats par Google.

Et chez Wordpress ?

Travailler avec SPIP n'empêche pas de regarder ce qui se fait ailleurs. Comme il m'arrive aussi d'utiliser Wordpress, j'ai été impressionné par le plugin Wordpress SEO par Yoast et notamment tout ce qu'il propose en matière de génération automatique de sitemap.

L'outil génère plusieurs sitemaps en fonction du type de contenu, qui sont reliés ensemble par un index de sitemap.

Et plus intéressant encore, il propose l'intégration d'une feuille de style pour mettre en forme le sitemap et rendre sa consultation plus pratique et agréable.

Fonctions personnalisées SPIP

Pour m'aider au formatage des informations, je vais avoir besoin de filtres personnalisées. Rien de plus simple, il suffit d'éditer le fichier mes_fonctions.php du répertoire /squelettes et de lui ajouter les lignes suivantes (à l'intérieur du bloc php, donc avant le « ?> » final) :

function url_de_logo($texte) {
 ereg('src="([^"]*)"', $texte, $regs);
 return $regs[1];
 }
 
 function add_cdata($texte) {
 return "";
 }
 
 function remove_param($texte) {
 if ( $nb = strrpos( $texte, "?" ) )
 return substr( $texte, 0, $nb );
 else
 return $texte;
 }
 
 function pourcent($valeur) {
 return $valeur / 100;
 }

Sitemap images et SPIP

Tout ça me donne bien envie de développer un plugin pour SPIP qui intégrerait les bonnes idées picorées un peu partout, mais je n'ai pas le temps pour l'instant. Je vais donc me contenter de juste modifier le sitemap par défaut.

Pour surcharger le sitemap par défaut, je copie le fichier sitemap.xml.html du répertoire squelettes-dist vers le répertoire squelettes.

J'ai supprimé l'intégration des brèves car je ne les utilise pas, mais ce ne doit pas être bien compliqué de les réintégrer.

J'ai complété les champs, pour que chaque lien ait une fréquence de modification, une priorité et une date de dernière modification.

Enfin j'ai ajouté des boucles sur le logo de l'article et les images qu'il contient, avec utilisation des titres des images.

Voici le contenu de mon fichier sitemap.xml.html :

#CACHE{0}
 #HTTP_HEADER{Content-Type: text/xml; charset=utf-8}
 
 
 
 [(#URL_SITE_SPIP)]
 [(#DATE_MODIF|?{[ (#DATE_MODIF|date_iso)]})]
 hourly
 1.0
 
 
 
 
 [(#URL_RUBRIQUE|url_absolue)]
 [(#DATE|date_iso)]
 daily
 0.6
 
 
 
 
 
 [(#URL_ARTICLE|url_absolue)]
 [(#DATE_MODIF|date_iso)]
 weekly
 [(#POPULARITE|pourcent)][
 
 #URL_SITE_SPIP/(#LOGO_ARTICLE_RUBRIQUE||url_de_logo|remove_param)
 [(#TITRE|textebrut|add_cdata)]
 [(#TITRE|textebrut|add_cdata)]
 ]
 
 [(#URL_DOCUMENT|url_absolue)][
 (#TITRE|textebrut|add_cdata)][
 (#TITRE|textebrut|add_cdata)]

Pour accéder à votre sitemap, il suffit d'accéder à l'url suivante : http:///sitemap.xml

Et un petit rappel avec SPIP, lorsque vous faites des modifications, si vous souhaitez forcer le rafraîchissement du fichier, il faut utiliser l'url : http:///sitemap.xml ?var_mode=calcul

Mais le fichier sitemap ainsi produit n'est pas très digeste pour les humains que nous sommes.

XSL et visualisation du sitemap

Afin de visualiser de manière simple le contenu de votre fichier sitemap, il suffit de lui ajouter une feuille de style xsl.

Pour cela, il faut modifier le fichier de génération du sitemap sitemap.xml.html au niveau de construction de la première ligne pour qu'elle ressemble à ceci :

#HTTP_HEADER{Content-Type: text/xml; charset=utf-8}

Enfin, il faut créer un fichier sitemap.xsl dans le répertoire /squelettes/ pour mettre en forme le contenu du fichier sitemap.

Je ne vais pas expliquer la construction du fichier xsl, vous trouverez sans problème de l'aide sur Internet. Voici le contenu de la feuille de style :


  xmlns:html="http://www.w3.org/TR/REC-html40"
 xmlns:image="http://www.google.com/schemas/sitemap-image/1.1"
 xmlns:sitemap="http://www.sitemaps.org/schemas/sitemap/0.9"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 
 
 
 
 XML Sitemap
 
 
 
 
 
 XML Sitemap

 
 Generated by Guillaume Orsal, this is an XML Sitemap, meant for consumption by search engines.

 You can find more information about XML sitemaps on sitemaps.org.
 

 
 This XML Sitemap contains  URLs.
 

 












 
 
 

 odd
 








 

 odd
 





   Logo  URL  Prio  Images  Ch. Freq.  Last Mod.

Les deux fichiers dont il est question dans cet article sont en téléchargement en bas de page.

Améliorations

Il y a plein d'améliorations que l'on peut apporter à ce qui est décrit ici :

Intégration des brèves dans la boucle
Intégration des vidéos
Intégration des documents et leur vignettes
Amélioration de la visualisation, par exemple, en rendant l'image cliquable pour une visualisation en plein écran
Intégrer tout ça dans un plugin SPIP
Génération de fichiers sitemap différents selon le type de contenu, et génération d'un fichier sitemap principal
Intégration d'un lien vers le fichier sitemap.xml dans le fichier robots.txt
Faire une gestion plus fine de la priorité, peut-être en s'inspirant de ce qui est fait chez certains plugins de sitemap pour SPIP.

Mais vous avez les bases pour aller plus loin.

Bon SEO à tous

Plugin SPIP

La lecture de cet article a inspiré un développeur qui a réalisé l'implémentation d'un plugin SPIP pour les sitemap images. N'hésitez pas à aller voir son travail.

Humans.txt : créer un fichier de crédits pour vos auteurs et technologies

Guillaume Orsal — 2014-10-12T17:34:00Z

Humans.txt est un fichier texte permettant de présenter les personnes derrière un site web. Ce standard simple et ouvert met en avant les humains, leurs rôles et leurs valeurs, au-delà du code et des machines.

Note contextuelle : Cet article a été initialement publié en octobre 2014. Bien que le standard humans.txt soit moins promu aujourd'hui qu'à ses débuts, ses principes restent pertinents et constituent une bonne pratique de web standards et de reconnaissance des contributeurs. Les informations techniques ont été mises à jour pour refléter la situation actuelle.

Qu'est-ce que humans.txt et pourquoi l'utiliser

Le fichier humans.txt est un standard du web lancé en 2009 pour répondre à une question simple : comment reconnaître les personnes et technologies qui ont créé un site web ?

Contrairement aux approches classiques (page « À propos », mentions légales), humans.txt propose une solution standardisée et facilement accessible. Le projet définit lui-même sa mission : « Nous sommes des humains, pas des machines ». L'objectif est double :

Reconnaissance des contributeurs : créditer les développeurs, designers, intégrateurs, gestionnaires de contenu
Documentation technique : inventorier les technologies, standards et outils utilisés

Pourquoi mettre en place humans.txt en 2025

À l'ère du web distribué, des CMS multiples et des équipes parfois éclatées, humans.txt répond à plusieurs besoins légitimes.

Responsabilité et transparence Afficher clairement qui a créé et maintient un site respecte une certaine déontologie du web. C'est particulièrement pertinent pour les agences et freelances souhaitant assumer et valoriser leur travail.

Web standards et éthique Adhérer à des initiatives comme humans.txt montre un attachement aux bonnes pratiques du web, même si cela n'apporte aucun gain SEO direct.

Reconnaissance professionnelle Pour les développeurs et designers, humans.txt offre une visibilité discrète mais pertinente auprès d'autres professionnels qui inspectent un site ou sa documentation.

Accessibilité et documentation Un fichier texte simple est universellement lisible, pérenne et indépendant de toute plateforme, contrairement aux balises meta propriétaires ou aux solutions centralisées.

Contexte historique : les balises meta author et publisher

Avant humans.txt, Google avait mis en avant les balises rel=« author » et rel=« publisher », placées dans le des pages afin d'identifier les auteurs et, à l'époque, enrichir certains résultats de recherche.

Statut actuel Ces balises ne sont plus utilisées par Google depuis la fermeture de Google+ en 2019. Elles restent documentées mais n'ont plus d'impact SEO.

Pour évaluer la qualité d'un contenu, Google s'appuie aujourd'hui davantage sur la crédibilité globale d'un site et d'un auteur que sur des balises déclaratives. On voit souvent passer l'acronyme E-E-A-T, qui signifie Experience, Expertise, Authoritativeness, Trustworthiness : expérience, expertise, autorité et fiabilité. En pratique, cela revient à privilégier des contenus solides, sourcés, cohérents et produits par des personnes identifiables et compétentes, plutôt que de simples signaux techniques.

Structure et contenu d'un humans.txt complet

Le fichier humans.txt est un document texte simple placé à la racine du site (/humans.txt). Voici une structure couramment utilisée.

Section TEAM : les contributeurs

/* TEAM */
 Web Developer: Guillaume Orsal
 Email: contact@orsal.fr
 Site: https://www.orsal.fr
 From: Paris, France

Cette section liste les personnes ayant participé à la création, l'évolution ou la maintenance du site.

Section THANKS : remerciements

/* THANKS */
 Humans.txt: http://humanstxt.org
 SPIP CMS: https://www.spip.net
 Bootstrap: https://getbootstrap.com
 jQuery: https://jquery.com

Elle permet de remercier les projets open source, outils, services tiers ou inspirations majeures.

Section SITE : informations techniques

/* SITE */
 Last update: 2025/01/20
 Language: French
 Charset: UTF-8
 Standards: HTML5, CSS3, ES6 JavaScript
 Doctype: HTML5
 Framework: SPIP 4.x
 CMS: SPIP
 Version Control: Git
 Hosting: OVH
 Analytics: Matomo (privacy-first)

Cette section documente les technologies, standards et environnements utilisés.

Section EXTRAS : informations supplémentaires

Des sections facultatives peuvent être ajoutées selon le contexte :

/* EXTRAS */
 Coffee: Decaf
 Music: Electro
 Hiring: open source contributors welcome

Guide pratique : créer votre humans.txt

Étape 1 : Créer le fichier

Créez un fichier texte nommé humans.txt à la racine de votre site (/humans.txt). Il doit être accessible publiquement et servi avec le type MIME text/plain.

Étape 2 : Remplir les sections

Commencez par les sections essentielles (TEAM, THANKS, SITE). Chaque ligne doit être utile, claire et compréhensible.

Exemples de contenu pertinent :

Web Developer : Votre Nom
Email : contact example.com
Site : https://monsite.com
Language : French
Standards : HTML5, CSS3

Exemples à éviter :

informations personnelles excessives
données sensibles
contenu inutilement verbeux

Étape 3 : Validation et maintenance

Vérifiez l'accessibilité du fichier :

curl -I https://www.example.com/humans.txt
 # Doit retourner : 200 OK

Mettez-le à jour lors de changements d'équipe ou de technologies importantes.

Étape 4 : Lier depuis votre site (optionnel)

Lien dans le :

Ou lien visible dans le pied de page :


 Humans.txt — Qui a créé ce site ?

Bonnes pratiques et considérations

Clarté avant exhaustivité Un humans.txt concis et lisible est préférable à une liste exhaustive.

Respect de la vie privée Ne publiez que des informations acceptées par les contributeurs. Un prénom et une localisation générale suffisent souvent.

Mise à jour régulière Un fichier obsolète nuit à la crédibilité.

Cohérence d'équipe Définissez collectivement ce qui doit apparaître, notamment dans un contexte agence ou multi-intervenants.

Combinaison avec d'autres initiatives Humans.txt complète utilement robots.txt, sitemap.xml et security.txt.

Adoption et impact réel

Adoption actuelle Humans.txt est utilisé par de nombreux sites professionnels et projets open source, mais reste optionnel et non standardisé formellement.

Impact professionnel Il offre une reconnaissance discrète auprès des pairs et clients techniques.

Impact SEO Aucun impact direct sur le classement. Son intérêt est avant tout humain, documentaire et professionnel.

Ressources et exploration

Site officiel humans.txt : http://humanstxt.org
Exemples : consultez les humans.txt de sites open source ou agences
Exemple concret : humans.txt d'orsal.fr

Conclusion : une responsabilité, pas une obligation

Humans.txt n'est ni une obligation légale ni une nécessité technique. C'est une démarche volontaire qui rappelle que le web est construit par des humains et que ces contributions méritent d'être reconnues.

Pour une agence, un freelance ou un site professionnel, humans.txt représente une bonne pratique de web standards et une forme simple, discrète et efficace de reconnaissance et de branding professionnel.

Voir aussi

LLMs.txt : standard de documentation — Le fichier permettant de documenter les politiques d'utilisation des contenus par les modèles d'IA, complémentaire et opposé à humans.txt

Guillaume Orsal

llms.txt : un standard de documentation pour l'usage des contenus par les modèles d'IA

TL ;DR

Introduction : llms.txt, un standard émergent pour l'ère de l'IA générative

Contexte : pourquoi llms.txt a émergé

Qu'est-ce que llms.txt et comment l'utiliser

Ce que permet concrètement llms.txt

Structure recommandée (exemple indicatif)

Explication des principaux champs

Pourquoi implémenter llms.txt

Bonnes pratiques

Implémentation technique

Adoption et perspectives

Limitations et considérations

Conclusion : une ouverture encadrée plutôt qu'un refus global

Ressources et références

Voir aussi

Obfuscation d'email : CSS vs JavaScript, amélioration des performances SEO (LCP, CLS)

Pourquoi l'obfuscation d'email pose un problème de performance

Rappel : Core Web Vitals et performance perçue

Réduire le JavaScript pour améliorer le SEO technique

Obfuscation d'email sans JavaScript : approche CSS

Structure HTML

Feuille de style CSS

Bénéfices en termes de performance et de référencement

Limite fonctionnelle : l'expérience utilisateur sur mobile

Rétablir l'UX sans JavaScript : redirection côté serveur

Script de redirection contact.php

Utilisation côté HTML

Conclusion

Audit SEO : détecter les pages avec une balise noindex via script automatisé

Introduction : identifier les barrières d'indexation

Comprendre la balise noindex et ses impacts

Diagnostic : automatiser la détection noindex

Utilisation du script

Interprétation des résultats et diagnostic

Limitations et considérations importantes

Bonnes pratiques pour la gestion de noindex

Conclusion

SERP, SPIP, breadcrumb et SEO

Web sémantique & schema.org

Prenons un exemple

Google et les données structurées

SPIP et les données structurées

CSS & fil d'ariane

Pour aller plus loin

Sitemap avec images pour SPIP

Petit rappel sur les sitemaps

Images sous Google Webmaster Tools

Vérifier l'indexation des images

SPIP et les sitemaps

Etat de l'art

Et chez Wordpress ?

Fonctions personnalisées SPIP

Sitemap images et SPIP

XSL et visualisation du sitemap

XML Sitemap

Améliorations

Plugin SPIP

Humans.txt : créer un fichier de crédits pour vos auteurs et technologies

Qu'est-ce que humans.txt et pourquoi l'utiliser

Pourquoi mettre en place humans.txt en 2025

Contexte historique : les balises meta author et publisher

Structure et contenu d'un humans.txt complet

Guide pratique : créer votre humans.txt

Bonnes pratiques et considérations

Adoption et impact réel

Ressources et exploration

Conclusion : une responsabilité, pas une obligation

Voir aussi