SEO : référencement naturel et performance

La première chose à faire est de lire ce que Google écrit lui-même, parce que ce texte est la reference et qu'il commence par une phrase qui surprend : « Il n'y a pas de secrets ici qui classeraient automatiquement votre site en premier ».

Ce que cela ne veut pas dire

Cela ne veut pas dire que le SEO est sans effet. Cela veut dire qu'il n'existe aucun ensemble de manipulations qui garantissent une position, et qu'un prestataire qui promet le contraire vend soit de l'inexperience, soit un résultat qu'il ne pourra pas reproduire sur votre site.

Ce que la documentation appelle Search Essentials

Google distingue deux niveaux, et la distinction est la base de tout le cours :

• Les Search Essentials : la liste de ce qui rend une page éligible à apparaître dans les résultats. Elle est courte, vérifiable, et ne change pas d'un audit à l'autre.
• L'optimisation : tout ce qui va au-delà et qui améliore la façon dont la page est comprise et présentée. C'est utile, c'est incertain, et c'est là que se joue la concurrence.

Le debug d'un SEO commence toujours par la première couche. Un site qui ne respecte pas un Essential ne se corrige pas par de l'optimisation.

La phrase à retenir de tout le cours

Le SEO ne se mesure pas en position, il se mesure en traffic qualifié et en conversions. La position est un intermédiaire qu'on ne contrôle pas complètement ; le trafic utile est ce qui compte, et il dépend autant de la qualité de la page que de sa visibilité.

1. La technique — le site est-il accessible et compris ?

C'est le levier qui conditionne les deux autres. Tant que Googlebot ne parcourt pas la page, ou ne reçoit pas le bon code de réponse, ou n'y trouve pas le contenu, rien de ce qui suit ne compte. C'est aussi le levier le plus mécanique : les défauts se voient dans des outils.

2. Le contenu — la page répond-elle à une recherche réelle ?

Le contenu est le deuxième levier, et il est le plus sous-estimé. Une page qui répond précisément à une question réelle attracts des liens, et les liens sont le signal le plus durable. Une page écrite « pour le référencement » produit un texte que personne ne lit et que personne ne cite.

3. L'autorité — d'autres sites parlent-ils de vous ?

Le troisième levier est externe. Il se travaille par le contenu de qualité, par les relations, par les citations. Aucun «technique » ne le remplace, et c'est le levier où l'effort est le plus long à se voir.

L'ordre n'est pas négociable

L'erreur classique est d'investir sur le contenu d'un site dont le robot est bloqué, ou dont les pages renvoient une erreur. Le travail est alors perdu : il n'était pas visible. On n'optimise pas un contenu qu'on ne sait pas atteindre. Tout audit commence donc par la technique, même si ce n'est pas le sujet qui intéresse.

La hiérarchie de consultation

1. Le site est-il crawlable et indexable ? robots.txt, codes de réponse, Canonique, sitemap.
2. La page est-elle comprise ? titre, description, structure des titres, contenu textuel réel dans le HTML.
3. La page est-elle pertinente ? pour la recherche qu'elle vise.
4. La page est-elle jugée digne d'être citée ? autorité, liens, rapidité, expérience.

Chaque niveau suppose le précédent vérifié. C'est la structure du cours et la structure d'un audit.

Sans mesure, un travail SEO est une suite de convincing opinions. Les outils donnent quatre chiffres principaux, et chacun a une limite qu'il faut connaître avant de s'en servir.

Les impressions

Nombre de fois où la page est affichée dans les résultats. C'est la mesure de la visibilité, pas du succès. Une page peut avoir un million d'impressions et zéro clic : elle est alors mal écrite, ou son titre est mauvais, ou elle répond à une recherche que personne ne tape.

Les clics

Nombre de fois où la page a été cliquée depuis les résultats. C'est le taux de clic (CTR) qui relie les deux : impressions et clics. Un CTR bas à impressions élevées est un signal clair — le titre ou la description ne donnent pas envie, ou la page ne correspond pas à ce que l'utilisateur cherchait.

La position moyenne

La position moyenne est la métrique la plus regarde et la plus trompeuse. Elle ne dit pas à quelle position la page est le plus souvent affichée. Une position moyenne de 6 peut signifier « toujours en 4 » ou « 3 une fois sur dix et 25 le reste du temps ». Et une position 1 sur une requête que personne ne tape ne vaut rien. C'est une moyenne, donc elle mélange le trafic important avec le trafic marginal.

Ce qu'aucun de ces chiffres ne dit

• Si le visiteur trouvé est la bonne personne.
• Si la page a obtenu une action — inscription, demande, achat.
• Ce que le visiteur a fait après être arrivé.

Un trafic de dix mille visites sur une page qui ne propose rien est moins utile que cent visites sur une page qui répond à une question et propose une suite. C'est pourquoi le suivi des conversions est indissociable du suivi SEO.

La délai entre l'action et la mesure

Les rapports ont du retard, et il est long : plusieurs semaines, parfois plusieurs mois. Une correction publiée aujourd'hui peut n'apparaître dans les chiffres que dans un à deux mois. C'est la raison pour laquelle il faut changer une chose à la fois et noter la date : sinon on ne saura jamais ce qui a produit l'effet.

Un audit qui porte sur « le site » ne produit rien d'utilisable. Avant de commencer, trois décisions.

Quelles pages comptent ?

Toutes les pages n'ont pas la même valeur et ne demandent pas le même travail. Un site de formation a des pages de catalogue, des pages de cours, des pages de parcours, des pages d'inscription. Elles n'ont ni les mêmes competition, ni les mêmes intentions, ni les mêmes contraintes. L'audit se priorise sur les pages qui portent l'activité, pas sur celles qui sont faciles à corriger.

Quel moteur ?

Google n'est pas seul, mais il domine en volume. Les règles/indexations de Bing et de Google diffèrent, notamment sur le rythme d'exploration et sur le traitement du JavaScript. Pour un travail sérieux, on vérifie au moins Google, et on ne suppose pas que les autres suivent.

Quel niveau d'accès ?

La distinction qui change tout, et que les modules suivants ignorent volontairement :

• Le rendu. Google exécute du JavaScript, mais moins vite et moins complètement qu'un navigateur. Une page dont le contenu n'apparaît que dans le DOM après exécution est plus difficile à indexer, parfois pas indexée. Le HTML rendu dans la source est ce qui compte ; le reste est un surcoût de traitement.
• L'accès aux données. Search Console donne les impressions, les requêtes, les pages Truly indexées. C'est la seule source qui dit ce que Google a réellement vu. Sans elle, on devine.

L'audit commence par la liste des pages à surveiller

Avant tout outil, on note dix à vingt URL qui comptent, avec leur requête cible et leur indicateur de succès. Cet inventaire est ce qui transforme un rapport en plan de travail : sans lui, on corrige ce qu'on trouve, pas ce qui compte.

Google ne « lit » pas un site page par page comme un navigateur. Le processus comporte des étapes distinctes, et un échec à l'une d'elles passe inaperçu tant que les autres semblent fonctionner.

Les étapes

1. Découvrir. Trouver les URLs : liens internes, sitemaps, liens externes. Une page absente des trois est découverte quand même, mais tardivement.
2. Explorer. Récupérer la page. Le code de réponse HTTP décide de la suite : 200 = indexable, 3xx = redirection à suivre, 4xx = erreur à corriger, 5xx = erreur serveur, à traiter comme urgente.
3. Rendre. Exécuter le JavaScript nécessaire pour voir la page finale. Cette étape est optionnelle et coûteuse : Google peut indexer le HTML initial, pas le DOM obtenu après exécution.
4. Indexer. Décider ce qui est conservé. Un contenu dupliqué, un contenu jugé peu utile, une page en noindex sortent de l'index.

Pourquoi une page peut être en ligne et invisible

Le cas le plus fréquent en audit est celui d'une page qui répond 200, dont le contenu est dans le HTML, et qui n'apparaît nulle part. Les raisons, dans l'ordre de fréquence :

• Elle n'est liée depuis aucune page crawlable — un lien généré en JavaScript, ou une page orpheline.
• Elle porte un noindex, souvent hérité d'un gabarit ou d'une variable de requête.
• Son contenu n'apparaît qu'après exécution JavaScript, et le rendu n'a pas eu lieu.
• Elle est bloquée par robots.txt : Google ne l'explore pas, mais peut l'indexer sans l'explorer (voir plus bas).
• Elle est canonisée vers une autre URL, et c'est cette autre URL qui est indexée.

Ces cinq causes se diagnostiquent avec l'outil d'inspection d'URL, qui affiche l'état de l'indexation et la page rendue telle que Google la voit.

La documentation de Google est catégorique, et la formulation est à retenir parce qu'elle est contre-intuitive : « N'utilisez pas robots.txt comme mécanisme pour empêcher l'indexation d'une page. »

Ce que robots.txt fait

• Gérer le trafic d'exploration — limiter ou interdire l'accès à des zones sans valeur, sur un site très sollicité.
• Empêcher l'exploration de pages dupliquées ou de paramètres d'URL qui génèrent des millions de combinaisons.

Ce qu'il ne fait pas

• Il ne protège rien. Les instructions robots.txt sont publiques et ne sont pas une mesure de sécurité. Le seul moyen de protéger une ressource est l'authentification.
• Il n'empêche pas l'indexation. Une page bloquée peut quand même apparaître dans les résultats, avec une URL et sans aucune description. Elle est même promulguée sans son texte : c'est le pire des deux mondes.
• Il ne dépose pas la page. Pour retirer une page de l'index, la méthode est noindex — mais elle suppose que le robot puisse explorer la page pour y lire le noindex. D'où la règle contre-intuitive : on autorise l'exploration et on pose noindex.

Les deux tests à faire systématiquement

1. Lire le robots.txt réel, pas supposé. Y chercher les Disallow qui bloquent des pages à indexer, et vérifier que les sitemaps sont bien déclarés.
2. Vérifier les codes de réponse des pages et des ressources : une feuille de style en 403 casse le rendu et le moteur ne voit pas la mise en page.

L'erreur qui coûte le plus cher

Disallow: / sur un site en production. Symptôme : le site fonctionne, les visiteurs voient tout, et le trafic organique tombe à zéro en quelques semaines. C'est l'erreur la plus grave possible et elle est fréquente, parce qu'elle est parfois appliquée « pour tester » puis oubliée, ou laissée par un staging.

La duplication n'est pas interdite par Google, et la documentation le précise : c'est un problème d'expérience et de gaspillage d'exploration, pas une faute. Mais mal traitée, elle disperse les signaux.

Les duplications légitimes

Elles sont dues à l'architecture, pas à une erreur : une page accessible par plusieurs chemins (avec et sans .html, avec et sans barre finale), une version imprimable, une version AMP, des variantes de langue. Pour elles, une rel="canonical" qui désigne la version de référence suffit.

Les duplications à supprimer

Celles qui n'apportent rien : des pages « quasi identiques » générées pour chaque combinaison de filtres, des pages de résultats de recherche internes indexées, des paramètres d'URL de tracking. Elles se traitent par une redirection 301 vers la version propre, ou par le blocage de l'exploration des paramètres dans robots.txt.

Canonical vers soi-même : une erreur d'implémentation

La règle qui surprend le plus : une page doit se déclarer canonique à elle-même. Le moteur a besoin de l'indice de confiance — il n'en déduit pas qu'une page est canonique, il le lit. Une page sans canonique sur un site qui en a partout ailleurs envoie un signal de duplication involontaire.

Canonique et redirection : ne pas se contredire

Si une page redirige en 301 vers une autre, elle ne doit pas aussi se déclarer canonique vers cette autre : les deux signaux se contredisent et le moteur choisit au hasard. De même, le canonique ne doit pas pointer vers une page en noindex : le résultat est une page indexée qui ne peut pas l'être.

La documentation est claire : « Google ne limitera pas l'exploration aux seules pages listées dans vos sitemaps, mais il priorisera l'exploration de ces pages. » Le sitemap est donc une aide à la priorisation, pas une contrainte.

Ce qu'un sitemap apporte réellement

• Il dit quelle version de l'URL est la bonne, ce qui est utile quand les URLs paramètres sont nombreuses.
• Il donne une date de modification, qui sert à explorer plus souvent ce qui change.
• Il fournit les URLs de contenus non textuels — images, vidéos — que le moteur ne découvrirait pas autrement.
• Sur un site dont le contenu change vite, il accélère la découverte des nouveautés.

Ce qu'il ne fait pas

• Il n'indexe rien. Une page listée dans un sitemap mais marquée noindex, ou bloquée par robots.txt, ne sera pas indexée.
• Il ne compense pas un maillage interne absent. Si une page n'est liée nulle part, elle reste isolée.

Les règles de forme

• Une seule URL canonique par page, avec le protocole et le domaine de production — un sitemap filled d'URLs en http, en www ou avec des paramètres disperse les signaux.
• Pas d'URL non canonique, pas d'URL en redirection, pas d'URL en 404.
• Déclaré dans robots.txt par une ligne Sitemap:, et soumis dans Search Console.
• Généré, jamais écrit à la main : un sitemap manuel finit toujours désynchronisé.

Le point de vigilance sur ce site

Le contrôleur de sitemaps de ce projet génère ses URL à la volée, et il a un garde-fou documenté : quand la région d'une ville est inconnue, il saute la ville au lieu de produire une URL contenant -region-inconnue. Une URL de ce type est un 404 dans un sitemap, c'est-à-dire une instruction contradictoire envoyée au moteur. C'est le genre de détail qui se voit dans un audit et qui ne se voit pas sur la page.

Le titre et la meta description sont le seul contenu du site que le moteur montre avant la visite. Tout le reste est lu par personne tant que le clic n'a pas eu lieu. Ce sont donc les deux éléments au meilleur rapport effort/résultat de toute la page.

Le titre

• Il doit décrire la page, pas le site. « Cours de développement web » plutôt que « Bienvenue sur notre site ».
• Il doit être unique. Deux pages au même titre, c'est une duplication que le moteur doit trancher.
• Il est tronqué dans les résultats selon la largeur de l'appareil. Google n'impose pas de limite écrite, mais au-delà d'une certaine longueur la fin est coupée : ce qui compte doit être au début.
• Il est prioritaire sur tous les autres signaux de la page, y compris les balises h1 et les données structurees.

La meta description

• Elle n'utilise pas directement comme critère de classement, mais elle détermine le taux de clic : c'est de la conversion, pas du positionnement.
• Elle doit être unique par page. La duplication de descriptions est un défaut très courant et facile à détecter en audit.
• Si elle est absente, Google la compose à partir du contenu de la page — et le résultat est souvent moins bon qu'une description écrite.
• Elle doit décrire la page et donner une raison de cliquer : elle contient l'extrait affiché sous le lien.

Le piège du gabarit unique

La cause n°1 des titres et descriptions dupliqués dans une application : un gabarit unique qui ne prend pas le contenu de la page. Le remède n'est pas de mettre des descriptions différentes au hasard, mais de faire dépendre le titre et la description de la ressource affichée, avec un repli explicite pour les cas où la donnée est absente. C'est un travail de développement, pas de rédaction.

Le contrôle qui prend une minute

Afficher une liste de dix pages du site et comparer leurs titres. Si deux se ressemblent, le défaut existe. Cet audit prend une heure pour un site de cent pages et trouve presque toujours quelque chose.

Les balises d'en-tête servent deux publics : l'humain qui lit la page et le moteur qui en déduit le sujet et les parties. La documentation est formelle sur ce point : une hiérarchie correcte aide à comprendre de quoi parle la page et où.

La règle, et ses trois limites

Un seul h1 décrivant le sujet de la page, des h2 pour les sections, des h3 pour les sous-sections, sans saut de niveau. Les trois limites :

• Le h1 ne doit pas être un logotype. Il décrit la page, pas la marque.
• Un même niveau ne doit pas servir à deux choses différentes. Deux h2 qui introduisent des sections distinctes, oui ; un h2 pour un titre visuel et un autre pour une sous-titre, non.
• Un h6 isolé signale une hiérarchie cassée plus qu'un niveau de profondeur.

Le HTML sémantique avant le style

La documentation des développeurs est explicite : « utilisez le HTML sémantique ». Un moteur sait qu'un article est un article, qu'une nav est une navigation, qu'une table est un tableau de données. Une div n'est rien : elle peut tout être, donc ne dit rien. Le sémantique n'est pas un style, c'est une information.

Les listes, la structure, et le texte hors DOM

• Une suite d'éléments est une ul, pas des paragraphes. Le moteur y voit une énumération, ce qui confirme la structure de la page.
• Un contenu généré par la propriété CSS content n'est pas dans le DOM, donc Google l'ignore. Le texte généré en JavaScript après chargement finit par être indexé, mais coûte plus cher à obtenir.
• Le contenu textuel doit être dans le HTML initial. C'est la règle la plus rentable du module : elle transforme une page lente et invisible en page simple et comprise.

Le contenu est le levier le plus lent et le plus durable. Le module ne dit pas « écrivez plus » : il dit « écrivez pour une question précise », parce que c'est ce qui distingue une page qui est trouvée d'une page qui est citée.

Partir de la question, pas du mot-clé

Le réflexe ancien — choisir un mot-clé et le répéter — est dépassé. Le réflexe utile est inverse : quelle question une personne pose-t-elle réellement ? Une page qui commence par répondre à cette question, de façon complète et vérifiable, satisfait ce que le moteur cherche à faire depuis des années : rendre la meilleure réponse disponible.

Les traits d'une page citée

• Elle répond complètement, pas prometteusement. Une page de 300 mots sur un sujet où l'on peut en écrire 2 000 ne fait pas référence.
• Elle est vérifiable. Les sources citées, les dates, les méthodes. Une page sans source ne se cite pas.
• Elle est à jour, et le dit. Une page de 2019 qui parle d'un outil modifié en 2023 est un signal négatif.
• Elle est utile hors contexte. Le lecteur y trouve la réponse complète sans avoir à naviguer.

La duplication interne, maîtrisée

La même idée exprimée sur trois pages n'est pas une catastrophe : c'est un problème si les trois se font concurrence sur la même requête. Deux solutions propres : faire des trois versions un contenu unique (une page longue, plusieurs entrées), ou assumer la spécialisation — une page par intention distincte, avec un contenu réellement différent.

Le contenu généré

Les moteurs ont accès à des textes produits en masse. Ils ne les récompensent pas et peuvent les considérer comme du spam. Le critère n'est pas « est-ce une machine qui a écrit » mais « est-ce que ce texte apporte quelque chose qu'un lecteur ne trouverait pas ailleurs ». Un texte générique reformulé dix fois n'apporte rien, quelle que soit la main qui l'a écrit.

Le texte d'un lien est l'un des rares éléments qui décrit une cible au moteur. Il dit ce qu'est la page liée, et il est donc un signal de pertinence.

Les sept règles du texte de lien

1. Descriptif. « En savoir plus » n'apprend rien. « Comprendre les Core Web Vitals » apprend.
2. Unique par cible. Cent liens « en savoir plus » vers cent pages détruisent le signal.
3. Concordant avec la cible. Un lien « tarifs » qui mène vers une page de contact est un lien trompeur : il perd l'utilisateur et il perd le signal.
4. Sans couleur seule. Un lien dans le texte doit être distingué sans dépendre de la couleur — question d'accessibilité autant que de lisibilité.
5. Absents de navigation. Les liens de navigation répétés sur toutes les pages indiquent la structure du site ; les liens de contenu indiquent les sujets.
6. Absents des images sans texte alternatif. Un lien sur une image n'a de valeur que si son alt est pertinent — même exigence que pour l'accessibilité.
7. nofollow sur demande explicite seulement. C'est un signal fort, à ne pas distribuer.

Le maillage interne : la profondeur vaut mieux que le nombre

Une page importante doit être atteignable en trois clics maximum depuis la page d'accueil. Au-delà, elle est rarement explorée comme il faut et son poids est dilué. Le test se fait à la main, en comptant : c'est long, et c'est la seule méthode fiable.

Les liens morts : un coût silencieux

Un lien vers une 404 est une promesse non tenue envers l'utilisateur, et un gaspillage pour le moteur. Le lien interne cassé est le plus fréquent, parce qu'il arrive quand une page est renommée ou supprimée. Le contrôle consiste à exporter tous les liens internes et à tester leurs codes de réponse — un travail d'outillage, à faire une fois et à rejouer à chaque livraison.

Le point le plus rentable du cours, parce qu'il change une page lente et invisible en page simple et comprise — sans toucher au design.

Deux chemins, deux réalités

Le moteur fonctionne en deux temps : il récupère le HTML, puis il peut exécuter le JavaScript pour obtenir le rendu final. Entre les deux, il y a un délai, un coût, et des cas où le rendu n'a pas lieu.

• Contenu dans le HTML initial — le moteur l'indexe directement. C'est le cas le plus simple et le plus fiable.
• Contenu injecté après exécution — le moteur peut le voir, mais il faut qu'il exécute le script, qu'il attende, et qu'il réussisse. Toute erreur JavaScript peut empêcher le contenu d'apparaître.

Ce que la documentation en dit exactement

Google Search Central indique que le moteur « n'indexe pas le contenu qui nécessite des greffons (Java ou Silverlight), ni le contenu rendu dans un canvas », et recommande d'utiliser du HTML sémantique. Le canvas est le cas limite à retenir : un texte dessiné dans un canvas n'existe pas pour un moteur, même s'il est parfaitement lisible pour un humain. C'est aussi un problème d'accessibilité, ce qui en fait un de ces défauts qui se corrigent une fois pour deux usages.

Le test en une minute

1. Afficher la source de la page (view-source, ou le terminal), pas la page rendue.
2. Chercher le texte principal dans cette source.
3. Si le texte n'y est pas, le moteur devra exécuter du JavaScript pour le voir. Ce n'est pas interdit, c'est plus lent et plus fragile.

Pour un site dont le contenu est du texte, du premier bloc : il doit être dans le HTML initial. Cette règle simple élimine la majorité des problèmes d'indexation d'applications modernes.

Le contenu hors DOM

Deux cas distincts qu'on confond souvent : le texte produit par la propriété CSS content n'est jamais dans le DOM et n'est donc pas vu ; le texte inséré par JavaScript finit dans le DOM, mais tard. Le premier est à supprimer ; le second est à réduire.

Les liens : même règle

Un lien dont le href est renseigné en JavaScript est un lien que le moteur ne voit pas au moment de l'exploration. Les liens doivent être dans le HTML initial, comme le texte.

Les Core Web Vitals sont un signal de qualité d'expérience. Ils ne sont pas un facteur de classement dominant — c'est un point que les commentateurs de SEO minimisent. Ils sont un facteur réel, faible pondéré, et ils sont aussi un bon indicateur de ce que vit l'utilisateur.

Les trois mesures et leurs seuils

Mesure	Ce qu'elle mesure	Bon	À améliorer	Mauvais
LCP	Chargement : affichage du plus grand élément visible	≤ 2,5 s	2,5 – 4 s	> 4 s
INP	Réactivité : délai avant le prochain affichage après une interaction	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	Stabilité visuelle : déplacements cumulés	≤ 0,1	0,1 – 0,25	> 0,25

Les quatre détails qui font la différence

1. Le 75ᵉ percentile, pas la moyenne. C'est la règle qu'on oublie. Google retient la valeur telle qu'elle est experienced par 75 % des visites. Une médiane flatteuse peut masquer 25 % de visites catastrophiques — et ce sont ces visites-là qui font partir l'utilisateur.
2. Des données de terrain, pas de laboratoire. Les rapports CrUX agrègent les mesures réelles des utilisateurs sur 28 jours glissants. Un score obtenu sur un simulateur est un diagnostic, jamais un résultat.
3. Mobile et desktop sont évalués séparément. Un même groupe d'URL peut être « bon » sur mobile et « mauvais » sur desktop. Les rapports séparent les deux.
4. INP remplace FID depuis mars 2024. Un cours qui cite encore FID décrit un outil qui n'existe plus. Les seuils sont inchangés depuis.

Où trouver la mesure qui compte

• Search Console — le rapport Core Web Vitals, en données de terrain, groupé par URL. C'est la source qui compte, parce qu'elle est celle que Google utilise.
• PageSpeed Insights — données de terrain quand elles existent, laboratoire sinon.
• Lighthouse et DevTools — laboratoire uniquement. Utiles pour diagnostiquer une régression, jamais pour conclure.

Ce que ces mesures corrigent d'habitude

• LCP : image principale non optimisée, ressource bloquante, absence de dimensions sur les images, rendu qui attend une requête.
• INP : tâches longues dans le fil principal, trop de JavaScript tiers, gestionnaires d'événements coûteux. C'est la mesure qui casse le plus de sites depuis 2024.
• CLS : images et bannières sans dimensions réservées, contenu inséré au-dessus de ce qui existe, polices qui décalent la mise en page.

La règle de budget

Une image sans width et height (ou sans aspect-ratio) ne peut pas réserver sa place, donc tout ce qui suit se décale quand elle arrive. Le CLS se corrige en une ligne par image. C'est le rapport effort/résultat le plus élevé de tout le cours, et il concerne aussi bien le SEO que le confort de lecture et l'accessibilité.

Les données structurées (JSON-LD dans le code) permettent de décrire le sens d'une page : ce qu'est un cours, un auteur, une organisation, un avis. Elles peuvent aussi rendre la page éligible à des affichages enrichis dans les résultats.

L'avertissement que la documentation insiste sur

Google précise que les données structurées ne doivent contenir que du contenu visible sur la page, et que masquer une information pour la crawler est une pratique trompeuse susceptible d'entraîner une action manuelle. Autrement dit : le balisage décrit la page, il ne la complète pas. Un cours déclaré dans le JSON-LD mais invisible pour l'utilisateur est une déclaration fausse.

Ce qui a du sens pour un site de formation

• Organization — nom, URL, logo, contacts. Stable, peu de risque, utile sur toutes les pages.
• Course — la nature du contenu, avec nom, description et fournisseur. Le type existe, mais Google ne l'exploite pas toujours dans les résultats enrichis.
• BreadcrumbList — le fil d'Ariane. C'est le balisage dont l'effet visuel est le plus fiable, parce qu'il peut remplacer un fil d'Ariane purement visuel.
• FAQPage — pour les questions fréquentes affichées sur la page. À noter : l'affichage enrichi de questions est plus rare qu'il y a quelques années, et le balisage reste pertinent pour la compréhension.

L'erreur classique : le balisage qui ne correspond pas à la page

Un même Course réutilisé sur toutes les pages de cours d'un site, avec le même nom et la même description. C'est du balisage mensonger : il décrit un contenu qui n'est pas celui de la page. Le test : chaque valeur du JSON-LD doit pouvoir être retrouvée ailleurs sur la page.

Comment vérifier

Deux vérifications, dans cet ordre : valider le balisage avec l'outil de test des résultats enrichis, puis comparer le balisage au contenu affiché. La seconde est la seule qui serve à quelque chose, et c'est celle que personne ne fait.

Mobile d'abord, pas mobile en plus

La documentation des développeurs liste en tête de ses exigences : le site doit être sécurisé, rapide, accessible et fonctionner sur tous les appareils. Ce n'est pas une recommandation de confort, c'est un prérequis d'éligibilité au Search Essentials.

Le responsive design n'est pas l'adaptation automatique

Un site en user-scalable=no ou avec une taille de police trop petite sur mobile est un défaut d'accessibilité qui devient un défaut SEO, parce que les deux partagent la même cause : on a supposé l'appareil plutôt que de concevoir pour l'incertitude de la taille.

HTTPS : le prérequis que plus personne ne discute

Un site servi en HTTP affiche un avertissement dans le navigateur et perd la confiance. Le signal est aussi technique : les liens internes doivent tous pointer vers la même version du site, HTTPS, sinon chaque lien est une redirection, et une redirection par lien est une penalisation de performance.

L'internationalisation : le piège des URLs

• Une langue par URL, déclarée par hreflang, et cohérente avec la langue réellement servie. Une URL qui annonce une langue et sert une autre est une erreur d'indexation.
• Une seule version par langue par page, sinon les versions se font concurrence entre elles.
• Les versions linguistiques ne se déclare pas canoniques les unes vers les autres : ce sont des pages distinctes, pas des doublons.