HTML sémantique : structurer le contenu correctement
Le HTML sémantique, c'est l'utilisation des balises dans leur sens prévu. Une balise <h1> pour le titre principal de la page, des <h2> pour les sections, <article> pour le contenu éditorial, <nav> pour la navigation, <footer> pour le pied de page, <main> pour le contenu principal.
Ces balises donnent des indications à Google sur la hiérarchie et la nature de chaque partie du contenu. Un site où tout est emballé dans des <div> génériques oblige le robot à deviner la structure. Un site avec un HTML sémantique correct lui facilite la tâche et améliore l'accessibilité en bonus.
| Balise HTML sémantique | Rôle | Impact SEO |
|---|---|---|
<h1> à <h6> |
Hiérarchie des titres | Signal de structure thématique fort |
<article> |
Contenu éditorial autonome | Aide Google à identifier le contenu principal |
<nav> |
Navigation principale ou secondaire | Distingue les liens de navigation du contenu |
<main> |
Contenu principal de la page | Signal d'accessibilité et de structure |
<aside> |
Contenu secondaire ou complémentaire | Pondération moindre accordée par Google |
<figure> et <figcaption> |
Image avec légende | Contexte sémantique autour de l'image |
Les balises Hn (H1 à H6) font partie du HTML sémantique. Leur hiérarchie logique aide Google à comprendre quels sujets sont principaux et lesquels sont des sous-thèmes. Un seul H1 par page, des H2 pour les sections majeures, des H3 pour les sous-sections.
Erreurs de code courantes nuisibles au SEO
| Erreur | Impact SEO | Correction |
|---|---|---|
| Plusieurs H1 sur une même page | Dilue le signal du titre principal, confusion sur le sujet central | Un seul H1, le reste en H2/H3 |
| Texte dans des images sans attribut alt | Contenu invisible pour Google, inaccessible aux lecteurs d'écran | Alt descriptif sur toutes les images de contenu |
| Liens sans texte d'ancre significatif | Google ne comprend pas la destination du lien | Ancres descriptives, jamais "cliquez ici" |
| CSS ou JS bloquants dans le <head> | Ralentit l'affichage, détériore le LCP | Defer/async sur les scripts, CSS critique inline |
| Code trop lourd (non minifié, non compressé) | Temps de chargement plus long, mauvaises métriques de performance | Minification + compression Brotli/Gzip |
| Balise canonique absente ou mal configurée | Risque de duplicate content entre URLs variantes | Canonical sur toutes les pages vers l'URL de référence |
| Images sans dimensions width/height | CLS élevé (décalage de mise en page) | Toujours déclarer width et height dans le HTML |
Ressources bloquantes : le problème le plus fréquent
Quand le navigateur charge une page, il lit le HTML de haut en bas. Si un fichier CSS ou JavaScript est chargé dans le <head> sans attribut spécial, le rendu de la page est interrompu jusqu'à ce que ce fichier soit téléchargé et exécuté. C'est ce qu'on appelle une ressource bloquante.
Les conséquences sont directes sur le LCP (Largest Contentful Paint) : l'élément principal de la page ne peut pas s'afficher tant que tous les scripts bloquants ne sont pas traités. Sur des connexions lentes (mobile 3G/4G), chaque ressource bloquante ajoute plusieurs secondes de délai.
- Pour les scripts JavaScript : ajouter
deferpour les scripts non urgents (ils chargent en parallèle et s'exécutent après le HTML) ouasyncpour les scripts indépendants (chargement en parallèle, exécution dès que disponible). - Pour le CSS : le CSS dans le head est bloquant par nature. La solution est de charger en ligne (inline) uniquement le CSS critique (ce qui s'affiche au-dessus de la ligne de flottaison) et de charger le reste de façon asynchrone.
- Pour les polices web : les polices Google Fonts peuvent bloquer l'affichage du texte. Utiliser
font-display: swappour afficher d'abord un texte avec une police système, puis basculer vers la police chargée.
Données structurées Schema.org : les opportunités manquées
Le balisage Schema.org permet de donner à Google des informations structurées sur le contenu d'une page : type de page, auteur, date, produit, avis, prix, etc. Ces informations peuvent déclencher des rich snippets dans les résultats de recherche (étoiles d'avis, prix, FAQ déroulante) qui augmentent le taux de clic.
| Type de page | Schéma recommandé | Rich snippet possible |
|---|---|---|
| Article de blog / Lexique | Article, BlogPosting | Fil d'Ariane, date de publication |
| Page produit e-commerce | Product, Offer, AggregateRating | Prix, disponibilité, étoiles |
| Page FAQ | FAQPage, Question, Answer | Questions/réponses déroulantes dans les SERP |
| Recette de cuisine | Recipe | Temps de préparation, notes, ingrédients |
| Entreprise locale | LocalBusiness | Adresse, horaires, téléphone dans les SERP |
| Événement | Event | Date, lieu, prix dans les résultats |
Code lourd et performance : l'impact direct sur les Core Web Vitals
Un code mal optimisé génère des fichiers plus lourds à télécharger. Les bonnes pratiques de base :
- Minifier les fichiers CSS et JS : supprimer les espaces, commentaires et retours à la ligne réduit la taille des fichiers de 20 à 40% sans changer leur fonctionnement.
- Activer la compression Brotli ou Gzip côté serveur : Brotli (plus récent) compresse mieux que Gzip. La compression réduit la taille des transferts de 60 à 80% sur les fichiers texte.
- Différer le chargement des scripts non critiques : attribut
deferouasyncselon le cas. - Supprimer le CSS inutilisé : beaucoup de thèmes WordPress chargent des milliers de lignes de CSS jamais utilisées. Des outils comme PurgeCSS ou l'onglet Coverage de Chrome DevTools permettent de les identifier.
- Optimiser les images : format WebP, compression adaptative, dimensions correctes, lazy loading. Les images représentent souvent 60 à 80% du poids d'une page.
Accessibilité et SEO : deux objectifs convergents
Un code accessible est presque toujours un code bien structuré pour le SEO. Les deux disciplines partagent de nombreuses bonnes pratiques.
- Textes alternatifs sur les images : indispensables pour les malvoyants et pour Google qui ne peut pas "voir" les images.
- Contraste suffisant : le ratio de contraste minimum WCAG (4,5:1) améliore la lisibilité pour tous les visiteurs.
- Navigation au clavier : un menu accessible au clavier est aussi plus facilement crawlable par Googlebot.
- Structure de titres logique : bonne pour les lecteurs d'écran, bonne pour la compréhension sémantique de Google.
- Labels sur les formulaires : accessibilité pour les utilisateurs et meilleure compréhension du contenu par les robots.
Outils pour vérifier la qualité du code
- Validateur W3C (validator.w3.org) : vérifie la conformité du HTML à la norme officielle. Les erreurs critiques peuvent gêner le rendu navigateur et l'interprétation par Google.
- Lighthouse (DevTools Chrome, touche F12 → onglet Lighthouse) : analyse les performances, l'accessibilité, les bonnes pratiques et le SEO de base. Disponible aussi via PageSpeed Insights.
- PageSpeed Insights (pagespeed.web.dev) : identifie les ressources bloquantes, les images non optimisées, les scripts à différer. Donne des données réelles CrUX et des données de laboratoire.
- Screaming Frog : crawl technique du site, détecte les erreurs de balises, les H1 manquants, les links cassés, les canonicals mal configurés.
- Coverage dans Chrome DevTools : onglet Coverage (Ctrl+Shift+P → "Coverage") montre le pourcentage de CSS et JS réellement utilisé sur une page. Utile pour identifier le code mort.
Lors d'un audit SEO technique, je commence systématiquement par ces vérifications avant d'analyser le contenu et les backlinks. Le code est la fondation : inutile de travailler sur le reste si la base est défaillante.