Les commentaires HTML pour optimiser le SEO de votre site
Un commentaire HTML n'améliore pas le référencement. Il n'est pas indexé, il ne transmet aucun signal sémantique, et des mots-clés glissés entre <!-- et --> ne produisent strictement rien. La question utile est donc l'inverse, dans quels cas un commentaire peut nuire, et ce qu'il faut vérifier dans le code source d'un site avant de conclure qu'il est propre.
À retenir
- Les moteurs lisent les commentaires mais ne les indexent pas, et n'en tirent aucun signal de classement.
- Un commentaire mal fermé fait disparaître tout le contenu qui le suit, jusqu'au prochain
-->. C'est le seul cas où l'incidence sur le référencement est réelle et immédiate. - Un commentaire placé avant la déclaration
<!DOCTYPE html>bascule certains navigateurs en mode de compatibilité et casse la mise en page. - Le vrai risque tient à ce qu'on y laisse, chemins internes, versions de composants, notes de développement.
Un commentaire n'entre pas dans l'index
Un commentaire est une portion de source que le navigateur ne rend pas. Il reste intégralement visible pour qui affiche le code source ou récupère la page en ligne de commande. Les robots d'indexation le téléchargent comme le reste du document, puis l'écartent lors de l'analyse du contenu.
<!-- Bloc de navigation secondaire, ne pas supprimer, utilisé par le fil d'Ariane -->
Ce commentaire aide un développeur qui reprendra le fichier dans deux ans. Il ne pèse ni pour ni contre dans les résultats de recherche. Le débat sur son influence en référencement est clos depuis longtemps, et les tests qui le reprennent périodiquement aboutissent tous au même résultat.
Les deux cas où un commentaire casse réellement une page
Le commentaire non fermé. Un <!-- sans --> correspondant fait disparaître tout ce qui suit, jusqu'à la fin du document ou jusqu'au prochain marqueur de fermeture. Le rendu affiche une page tronquée, et l'indexation porte sur un contenu amputé. Le cas se produit typiquement quand un rédacteur commente un bloc dans un éditeur visuel et qu'un caractère est perdu au passage. Le symptôme est net, la page se vide à partir d'un certain point sans erreur serveur.
Le commentaire avant le doctype. La déclaration <!DOCTYPE html> doit être la première chose du document. Un commentaire, une ligne vide ou un caractère invisible placé avant fait basculer certains navigateurs en mode de compatibilité, avec des règles de mise en page héritées des années 2000. La page s'affiche de travers sans que rien dans la feuille de style l'explique.
Un troisième cas mérite mention, celui du double tiret à l'intérieur d'un commentaire. La séquence -- au milieu d'un commentaire est invalide et le comportement des analyseurs varie. Écrire une plage de dates ou une ligne de séparation faite de tirets dans un commentaire suffit à provoquer des rendus imprévisibles.
Le code source trahit la pile technique
Le vrai sujet n'est pas le référencement mais la discrétion. Tout ce qui figure en commentaire est lisible par un concurrent en trois secondes. Les extensions de gestion de contenu, les outils de cache et les constructeurs de pages laissent des traces qui identifient précisément la pile technique.
- Des numéros de version d'extensions, qui permettent de chercher directement les vulnérabilités connues correspondantes.
- Des chemins de fichiers internes, qui révèlent l'arborescence du serveur.
- Des notes de développement, du type « contournement en attendant la correction côté API », qui indiquent où le site est fragile.
- Des blocs entiers commentés, anciennes offres, anciens tarifs, pages de test, encore présents dans le document livré.
Identifiants et mots de passe, même provisoires, clés d'interface de programmation, jetons d'accès, adresses d'environnements de préproduction, descriptions de la structure de la base de données, mentions de failles connues et non corrigées. Ces éléments sont accessibles à tout visiteur, et les outils de collecte automatisée les indexent bien avant qu'un développeur pense à les retirer.
Vérifier ce que votre site expose
- Récupérer la page telle qu'elle est livrée Un clic droit puis « afficher le code source » suffit sur une page simple. Pour un contrôle systématique, une requête en ligne de commande avec
curlet une recherche des occurrences de<!--donnent la liste complète en une opération. - Chercher les mots sensibles Les termes
todo,fixme,password,api,staging,debugetversionremontent la quasi-totalité des fuites involontaires. - Repérer les blocs commentés volumineux Un ancien tarif ou une ancienne mention légale laissés en commentaire n'ont plus d'existence juridique, mais ils restent lisibles et peuvent servir d'argument à un client mécontent.
- Vérifier le premier caractère du document Le doctype doit ouvrir la page, sans espace ni commentaire avant lui. Un validateur HTML signale ce défaut immédiatement.
Minifier plutôt que renoncer aux commentaires
La bonne pratique consiste à commenter généreusement dans les sources et à supprimer les commentaires à la génération. Les outils de compilation le font en une option, et les gestionnaires de contenu disposent tous d'une extension d'optimisation qui inclut cette étape. Le développeur garde sa documentation, le visiteur reçoit un document allégé.
L'effet sur les performances reste modeste. Un commentaire pèse quelques dizaines d'octets, cinquante commentaires quelques kilooctets, à comparer aux centaines de kilooctets d'images non compressées ou de scripts tiers qui bloquent le rendu. La minification du HTML vaut pour la propreté et la discrétion davantage que pour le chronomètre.
Un détail compte au moment de configurer la minification. Certains outils tiers utilisent des commentaires comme marqueurs fonctionnels, notamment les systèmes de cache par blocs et quelques mécanismes de personnalisation côté serveur. Une suppression aveugle casse alors une fonctionnalité sans message d'erreur. Les configurations sérieuses prévoient une liste de commentaires à conserver.
Les commentaires du langage serveur, en PHP, dans un moteur de gabarits ou dans un composant JavaScript compilé, sont traités avant la génération du document final. Ils ne sortent pas dans la page livrée, ne posent aucun problème de confidentialité et n'ajoutent aucun octet au transfert. C'est là qu'il faut écrire la documentation technique, pas dans le HTML.
Les éléments du source qui pèsent réellement
À vouloir régler le sort des commentaires, on passe à côté des éléments du même document qui, eux, pèsent réellement.
| Élément du source | Effet sur le référencement | Erreur fréquente |
|---|---|---|
| Commentaire HTML | Aucun | Croire qu'y placer des mots-clés sert à quelque chose |
| Balise title | Fort | Titre dupliqué sur des pages différentes |
| Lien canonique | Fort | Canonique pointant vers la page d'accueil sur tout un site |
| Directive robots | Décisif | Un noindex oublié après une mise en préproduction |
| Données structurées | Modéré, sur l'affichage | Balisage désynchronisé du contenu visible |
| Attribut hreflang | Fort en multilingue | Déclarations non réciproques entre versions |
La ligne la plus dangereuse d'un document reste une directive noindex restée en place après une mise en ligne. Elle occupe une balise, ne se voit pas à l'écran, et vide un site des résultats de recherche en quelques semaines. C'est le contrôle à faire en premier, bien avant de compter les commentaires.
Questions fréquentes
Google lit-il les commentaires HTML ?
Il les télécharge avec le reste du document, puis les écarte de l'analyse du contenu. Aucun mot placé dans un commentaire n'entre dans l'index ni ne participe au classement. La seule conséquence indirecte concerne le volume transféré, négligeable dans presque tous les cas.
Un excès de commentaires peut-il pénaliser un site ?
Il n'existe pas de sanction liée aux commentaires. L'effet éventuel passerait par le poids du document et les signaux de performance mesurés côté utilisateur, délai d'affichage du plus grand élément, réactivité aux interactions, stabilité visuelle. Il faudrait un volume de commentaires très inhabituel pour que cette contribution devienne mesurable, alors que les images et les scripts tiers pèsent des ordres de grandeur au-dessus.
Faut-il supprimer les commentaires en production ?
C'est préférable, moins pour la vitesse que pour ce qu'ils révèlent. La minification s'active en une option dans les outils de compilation comme dans les extensions d'optimisation des gestionnaires de contenu. Pensez à conserver les commentaires qui servent de marqueurs à un système de cache ou de personnalisation, sous peine de casser une fonctionnalité silencieusement.
Un bloc commenté est-il vraiment invisible pour un visiteur ?
Invisible à l'écran, parfaitement lisible dans le code source, et récupérable par n'importe quel outil d'aspiration. Commenter un ancien tarif ou une ancienne mention légale ne les retire donc pas du site au sens juridique. Ces blocs se suppriment, ils ne se commentent pas.
