La qualité du code et le SEO

Ce qui compte et ce qui n'a jamais compté

Le sujet traîne un grand nombre d'affirmations recopiées d'article en article. Avant d'entrer dans le détail, voici le tri, tel que je l'applique en audit.

Un HTML qui dit ce qu'il contient

Employer les balises pour ce qu'elles désignent permet au moteur de séparer le contenu principal du décor. Un document où l'article, la navigation, l'en-tête et le pied de page sont explicitement marqués se lit sans supposition, et le même travail sert aux lecteurs d'écran.

Le contenu injecté en JavaScript

C'est le point le plus coûteux de tout ce qui touche au code, et le moins visible. Google exécute le JavaScript, mais dans un second temps, avec des ressources limitées et parfois un décalage. Un contenu qui n'existe qu'après exécution peut donc être vu plus tard, partiellement, ou pas du tout si un script échoue.

La vérification prend deux minutes et vaut pour n'importe quel site.

Un résultat à zéro signifie que le texte n'est pas dans le document servi. L'outil d'inspection d'URL de la Search Console complète le diagnostic en affichant le code HTML tel que Google le voit après rendu, ainsi que les ressources qu'il n'a pas pu charger.

Les cas les plus fréquents sont les onglets dont le contenu n'est injecté qu'au clic, les avis chargés par un service tiers, les listes de produits produites après un appel réseau, et les menus entièrement construits en JavaScript, qui privent le site de ses liens internes.

Les ressources qui bloquent l'affichage

Le navigateur lit le document de haut en bas. Un fichier de style ou un script placé dans l'en-tête sans précaution interrompt le rendu jusqu'à son téléchargement et son exécution. Sur une connexion mobile ordinaire, chaque ressource de ce type ajoute des centaines de millisecondes avant le premier pixel.

• Les scripts se déclarent en defer quand leur ordre compte, en async quand ils sont indépendants. Les deux libèrent l'analyse du document.
• Les feuilles de style bloquent par nature. La réponse consiste à placer en ligne le strict nécessaire à ce qui s'affiche d'emblée, et à charger le reste ensuite.
• Les polices peuvent masquer le texte le temps de leur chargement. La déclaration font-display: swap affiche immédiatement une police de secours, et un préchargement évite le saut visuel qui suit.

L'effet se mesure sur le LCP et sur le premier rendu, détaillés sur la page vitesse d'affichage.

Les erreurs qui coûtent réellement

Ce que les données structurées donnent encore

Le balisage décrit le contenu dans un format que le moteur lit sans interprétation. Son intérêt a changé de nature ces dernières années, et il faut le savoir avant d'y investir du temps.

Depuis août 2023, les questions-réponses enrichies sont réservées aux sites gouvernementaux et de santé reconnus, et les affichages de type mode d'emploi ont été retirés. Le balisage FAQPage reste utile pour décrire la page, mais il ne rapporte plus de place supplémentaire dans les résultats pour un site ordinaire.

Accessibilité et référencement avancent ensemble

Les deux disciplines demandent les mêmes choses pour des raisons différentes. Un texte alternatif décrit l'image à qui ne la voit pas et à qui ne peut pas l'interpréter. Une structure de titres cohérente sert la navigation au lecteur d'écran et la compréhension du plan. Un menu utilisable au clavier repose sur de vrais liens, donc sur des liens que le moteur suit.

Cette convergence a une conséquence pratique, puisque le budget consacré à l'accessibilité n'est jamais perdu pour le référencement, ce qui aide à le faire accepter.

Les outils de contrôle

• Inspection d'URL dans la Search Console, pour voir le HTML rendu et les ressources bloquées. C'est le seul outil qui montre ce que Google a réellement obtenu.
• Test des résultats enrichis, pour valider un balisage avant sa mise en ligne.
• PageSpeed Insights et Lighthouse, pour les ressources bloquantes et le détail des mesures de performance.
• Screaming Frog, pour repérer à l'échelle du site les canoniques incohérentes, les titres manquants et les liens cassés.
• L'onglet de couverture de Chrome, qui indique la part de CSS et de JavaScript réellement utilisée sur une page, souvent inférieure au tiers.
• Le validateur du W3C, à lire comme une liste d'alertes à trier, jamais comme une note à faire monter.

Dans un audit technique, ces vérifications passent avant l'analyse du contenu. Une page que le moteur lit mal ne se corrige pas par la rédaction.

Questions fréquentes

Le HTML sémantique change-t-il quelque chose au référencement ?

Indirectement, et c'est déjà beaucoup. Aucune balise ne fait monter une page, mais un document où le contenu principal, la navigation et les éléments secondaires sont identifiés permet au moteur de distinguer ce qui compte du décor. Sur un gabarit entièrement construit en div, cette distinction devient une supposition.

Plusieurs H1 sur une même page, est-ce un problème ?

Non pour Google, qui a indiqué à plusieurs reprises savoir traiter des pages à plusieurs H1. Le problème est ailleurs. Une page avec quatre titres de premier niveau annonce quatre sujets principaux, ce qui trahit généralement un plan mal construit. Un seul H1 reste la meilleure habitude, pour la clarté du document et pour les lecteurs d'écran.

Faut-il corriger toutes les erreurs du validateur W3C ?

Non. La conformité au validateur n'est pas un critère de classement, et la plupart des sites bien positionnés affichent des dizaines d'avertissements. Les erreurs à corriger sont celles qui cassent quelque chose : une balise non fermée qui avale le reste du contenu, un attribut dupliqué, un balisage structuré invalide, un élément qui empêche l'affichage sur mobile.

Les données structurées FAQ affichent-elles encore des résultats enrichis ?

Plus pour la grande majorité des sites. Depuis août 2023, Google réserve l'affichage des FAQ enrichies aux sites gouvernementaux et de santé reconnus, et les résultats enrichis de type mode d'emploi ont été retirés dans la foulée. Le balisage garde son intérêt pour la compréhension de la page, mais il ne faut plus en attendre un gain d'affichage.