Ressources : la bibliographie commentée

Les sources primaires sur lesquelles reposent les guides publiés ici. Chacune est accompagnée de ce qu'elle apporte réellement et du moment où il faut la consulter — une liste de liens sans commentaire n'aide personne.

Pourquoi une bibliographie ? Le SEO est un domaine où la rumeur circule plus vite que la documentation. Beaucoup d'affirmations largement répétées ne reposent sur aucune source vérifiable — ou sur une source obsolète depuis des années. Citer les sources primaires permet à chacun de vérifier, et de constater quand nous nous trompons.

Documentation Google Search Central

C'est la source de référence. Elle est parfois vague — volontairement — mais elle a un avantage décisif : elle est écrite par ceux qui construisent le système. Quand elle contredit un article de blog, c'est elle qui a raison.

Comment fonctionne la recherche Google ↗

La description officielle du parcours exploration → indexation → diffusion. C'est le document qui clarifie la distinction fondamentale entre « crawlé » et « indexé », à l'origine de la moitié des erreurs de diagnostic.

À lire en premier, avant tout le reste.

Gérer le budget d'exploration des grands sites ↗

Le seul document où Google explicite les facteurs qui déterminent le rythme d'exploration. Précision utile : Google y indique que la notion ne concerne pas les sites de moins de quelques milliers d'URL — ce qui invalide une bonne part des conseils courants sur le sujet.

Quand un site dépasse quelques milliers de pages.

Google Search Essentials ↗

Les règles de base : exigences techniques, règles anti-spam et bonnes pratiques. C'est le texte qui définit formellement ce qu'est une page « doorway » et du contenu de faible valeur — utile bien au-delà du SEO, notamment pour comprendre les critères d'éligibilité publicitaire.

Avant toute génération de pages à grande échelle.

Système de contenu utile ↗

La liste de questions que Google suggère de se poser sur son propre contenu. Elle a l'air banale ; appliquée honnêtement à un site existant, elle est redoutable. C'est aussi ici qu'est formulée la notion d'expérience de première main, devenue centrale dans l'évaluation.

En audit éditorial, page par page.

Rapport sur l'indexation des pages ↗

La définition officielle de chaque motif de non-indexation. Indispensable, parce que des libellés très proches — « détectée non indexée » et « explorée non indexée » — décrivent des problèmes opposés. Notre guide de lecture de ce rapport détaille les pièges.

À chaque consultation de Search Console.

Blog officiel Google Search Central ↗

Les annonces de mises à jour d'algorithme et les changements de règles. Source primaire pour dater précisément un core update — information nécessaire pour distinguer une baisse due à un update d'une baisse due à une régression technique.

En veille, et après toute chute de trafic inexpliquée.

Standards et spécifications

Les balises et protocoles du web sont définis par des spécifications publiques. Les consulter évite de dépendre d'interprétations de seconde main.

Schema.org — hiérarchie complète des types ↗

La référence des types de données structurées. À distinguer de la documentation Google sur les résultats enrichis : Schema.org définit un vocabulaire vaste, dont Google n'exploite qu'un sous-ensemble. Les deux sont nécessaires, et les confondre conduit à baliser des choses que personne ne lit.

Pour trouver le type exact d'une entité.

Galerie des résultats enrichis Google ↗

La liste de ce que Google exploite effectivement, avec les propriétés requises et recommandées pour chaque type. C'est le document qui compte pour décider quoi implémenter en priorité.

Avant d'implémenter un balisage.

Protocole Sitemaps ↗

La spécification originale, courte et lisible. Elle précise notamment le statut réel des balises de priorité et de fréquence — largement surinterprétées alors que les moteurs les traitent au mieux comme des indications.

En cas de doute sur un champ du sitemap.

MDN — Référence HTTP ↗

La documentation de référence sur les codes de statut, les entêtes et la mise en cache. Beaucoup de problèmes présentés comme des problèmes SEO sont en réalité des problèmes HTTP : redirections mal chaînées, entêtes de cache incohérents, protocole perdu derrière un proxy.

Dès qu'un comportement dépend d'un entête.

RFC 9309 — Robots Exclusion Protocol ↗

Depuis 2022, le fichier robots.txt est un standard formel. La RFC tranche les cas limites — précédence des règles, taille maximale, comportement en cas d'erreur serveur — sur lesquels circulent beaucoup d'approximations.

Pour arbitrer un conflit de règles.

Documentation WordPress

Plugin Handbook ↗

La référence pour développer une extension : cycle de vie, hooks, sécurité, internationalisation. La section sur l'internationalisation mérite une lecture attentive — elle explique le circuit de traduction du dépôt officiel, dont l'incompréhension est la première cause d'un plugin affiché comme non traduit.

Avant de publier une extension.

Règles détaillées du dépôt de plugins ↗

Les dix-huit règles auxquelles se conforme toute extension publiée. Elles couvrent notamment la divulgation obligatoire des communications vers des services externes — point qui conditionne la conception de toute télémétrie.

Avant soumission, puis à chaque version majeure.

Performance et Core Web Vitals

web.dev — Core Web Vitals ↗

La définition des métriques, leurs seuils et leur méthode de mesure. Point souvent négligé : les seuils s'évaluent au 75e centile des visites réelles, pas sur une mesure de laboratoire isolée. Cette nuance explique l'écart fréquent entre un bon score en test et un mauvais classement en données de terrain.

Avant toute optimisation de performance.

Chrome UX Report ↗

Les données de performance réelles collectées auprès des utilisateurs de Chrome, publiques et interrogeables. C'est la source qui alimente l'évaluation des Core Web Vitals — et elle permet aussi de comparer objectivement son site à ceux de son secteur.

Pour mesurer plutôt que supposer.

Outils officiels

Test des résultats enrichis ↗

Valide un balisage tel que Googlebot le voit, rendu JavaScript compris. À préférer aux validateurs génériques : un balisage syntaxiquement correct peut être inexploitable par Google s'il manque une propriété requise.

Après toute modification de données structurées.

Validateur Schema.org ↗

Complémentaire du précédent : il valide la conformité au vocabulaire complet, indépendamment de ce que Google exploite. Utile pour un balisage destiné à d'autres consommateurs que le moteur de recherche.

Pour un balisage au-delà des besoins de Google.

PageSpeed Insights ↗

Combine une mesure de laboratoire et les données de terrain issues du Chrome UX Report. Ce sont les secondes qui comptent pour l'évaluation ; les premières servent au diagnostic. Confondre les deux conduit à optimiser un score sans améliorer l'expérience réelle.

En diagnostic, en lisant d'abord les données de terrain.

Comment nous utilisons ces sources

Trois règles encadrent l'usage des références dans nos guides, et elles expliquent pourquoi certains sujets très recherchés n'y figurent pas :

  1. La source primaire prime. Quand la documentation officielle et une pratique répandue divergent, nous suivons la documentation et signalons l'écart.
  2. Ce qui est mesuré est distingué de ce qui est supposé. Nos guides séparent explicitement ce que Google documente, ce que nous avons observé sur nos propres sites, et ce qui reste une hypothèse.
  3. Aucune affirmation chiffrée sans origine. Les chiffres cités proviennent soit d'une source officielle liée, soit de nos propres données, avec la période et le périmètre indiqués.

Ces engagements sont détaillés dans la charte éditoriale. Si vous relevez une erreur ou une source obsolète dans un guide, la page de contact est le moyen le plus direct de nous le signaler : les corrections sont appliquées et créditées.


← Lire les guides  ·  Qui écrit ces guides →