Quelques tips pour améliorer son SEO

Depuis des années que je bidouille mon blog, je me suis pas mal penché sur le SEO. Juste pour comprendre pourquoi certaines pages remontent sur Google et d’autres restent invisibles. Entre ça et l’expérience accumulée sur mes missions et en freelance, voici ce que j’ai retenu, avec les vrais seuils à connaître plutôt que des approximations.

Le contenu, ça reste la base

Avant même de sortir un outil, Google essaie surtout de répondre à une question que quelqu’un s’est posée. Donc concrètement :

Un texte qui répond vraiment à la question du titre, pas du remplissage pour faire joli.
Une structure avec des vrais titres (un seul H1, puis des H2/H3 pour découper).
Des mots-clés placés naturellement, dans le titre et l’intro, sans les répéter 15 fois comme en 2012.
Des liens internes vers d’autres articles, et des liens externes vers des sources qui tiennent la route.

L’outil à utiliser dès le début

Avant même de parler de seuils, il faut pouvoir mesurer. PageSpeed Insights reste le point de départ le plus simple : on colle une URL, il sort le LCP/INP/CLS réels ainsi qu’un audit Lighthouse complet, avec les pistes d’amélioration classées par impact.

Pour creuser en local, direct dans le navigateur (Chrome, Edge, Brave, tout ce qui tourne sous Chromium) : F12 puis l’onglet Lighthouse, le même audit que PageSpeed Insights mais sans quitter sa page. Et si besoin d’aller encore plus loin sur une lenteur précise, l’onglet Performance : on enregistre un chargement de page et on voit exactement ce qui bloque le rendu, quel script prend du temps, où passe le thread principal.

La vitesse : les Core Web Vitals

Depuis 2021, Google utilise trois métriques mesurées sur de vrais visiteurs (pas en labo) comme signal de classement. En 2026, les seuils “bons” n’ont pas bougé :

Métrique	Ça mesure quoi	Seuil “bon”
LCP (Largest Contentful Paint)	La vitesse de chargement	< 2,5 s
INP (Interaction to Next Paint)	La réactivité aux clics/taps	< 200 ms
CLS (Cumulative Layout Shift)	Les éléments qui sautent partout	< 0,1

Ces chiffres viennent du Chrome UX Report, qui remonte les mesures des vraies visites sur 28 jours glissants. Google regarde le seuil respecté par 75% de vos visiteurs, pas la moyenne : les 25% les plus lents comptent quand même dans le calcul. Donc même si ça rame chez vous en 4G dans le métro, ça compte.

Dans la vraie vie, ça veut dire :

Pour le LCP : précharger l’image ou la police principale, éviter le CSS qui bloque le rendu, faire du rendu côté serveur ou du SSG (Astro fait ça très bien).
Pour l’INP : ne pas noyer le thread principal avec du JS inutile, différer ce qui n’est pas critique au premier affichage.
Pour le CLS : toujours mettre width et height sur les images et vidéos, réserver l’espace pour les pubs ou le contenu qui charge après coup.

<img src="photo.webp" width="800" height="450" alt="Description de l'image" />

Le navigateur calcule le ratio dès la lecture du HTML et réserve l’espace avant même que l’image soit chargée : plus aucun saut de mise en page à l’affichage.

Les balises meta et l’Open Graph

Le SEO, c’est aussi ce que voient les robots et les réseaux sociaux avant même d’afficher la page :

Un <title> unique par page, avec le mot clé principal en premier.
Une <meta name="description"> qui donne vraiment envie de cliquer, entre 150 et 160 caractères.
Une balise <link rel="canonical"> pour éviter le contenu dupliqué quand la même page est accessible par plusieurs URLs.
Les balises Open Graph (og:title, og:description, og:image, og:url) pour un aperçu propre sur Discord, Slack, LinkedIn ou Facebook.
Les balises Twitter Card (twitter:card, twitter:image) pour le même rendu sur X.

<meta property="og:title" content="Titre de la page" />
<meta property="og:description" content="Description de la page" />
<meta property="og:image" content="https://exemple.com/og-image.png" />
<meta property="og:url" content="https://exemple.com/page" />
<meta property="twitter:card" content="summary_large_image" />

Pour l’image Open Graph, la taille recommandée est 1200x630 px (ratio 1.91:1) : c’est ce que Facebook, LinkedIn et X affichent le mieux sans recadrage moche. Un outil comme Meta Tags permet de prévisualiser le rendu avant publication.

Accessibilité et contraste

Un site accessible, c’est souvent un site que Google comprend mieux aussi. Les deux se recoupent plus qu’on ne le pense.

Des alt corrects sur les images, pas juste pour le SEO mais pour les lecteurs d’écran.
Une navigation qui marche entièrement au clavier, avec le focus visible.
Du HTML sémantique (<nav>, <main>, <article>) plutôt que des <div> à toutes les sauces.
Des liens explicites (éviter « cliquez ici »), compréhensibles même sans contexte autour.
Une hiérarchie de titres complète, sans saut de niveau entre H1, H2 et H3.
Des formulaires avec un vrai <label> pour chaque champ : le placeholder seul ne suffit pas, il disparaît à la saisie et n’est pas toujours lu par les lecteurs d’écran.
Des zones tactiles d’au moins 44 x 44 px pour les boutons et liens sur mobile.

Pour creuser chacun de ces points, la checklist de design-accessible.fr est une bonne référence : organisée par thème (contenu, couleurs, formulaires, navigation, conception), avec des ressources pour chaque bonne pratique.

Côté couleurs, la norme WCAG 2.1 (niveau AA) donne des ratios de contraste précis entre texte et fond :

4.5:1 pour du texte normal.
3:1 pour du texte large (≥ 18px en gras, ou ≥ 24px normal).

/* Exemple : un bon contraste, testé avant de choisir sa palette */
body {
  background-color: #ffffff;
  color: #1d1d1d; /* largement au-dessus du 4.5:1 */
}

Pour vérifier ça sans y passer trois heures, il y a le WebAIM Contrast Checker, où on colle ses deux couleurs et il vous dit direct si ça passe.

Responsive : le mobile d’abord

Google indexe en priorité la version mobile d’un site (mobile-first indexing). Concrètement :

Le contenu doit être identique entre mobile et desktop, pas une version light sur mobile.
Le viewport doit être bien configuré :

<meta name="viewport" content="width=device-width, initial-scale=1">

Les zones cliquables doivent être assez grandes pour un doigt, pas juste pour une souris.

Se faire indexer plus vite

Écrire un bon article, c’est bien, encore faut-il que Google (et les autres moteurs) le découvre rapidement. Par défaut, un moteur repasse crawler votre site à son propre rythme, parfois plusieurs jours après la publication. IndexNow permet de prévenir directement les moteurs qui le supportent (Bing, Yandex…) dès qu’une page est publiée ou modifiée, plutôt que d’attendre leur passage. J’explique comment le mettre en place dans Indexer rapidement ses pages web avec IndexNow.

Les outils que j’utilise

Pas besoin de tout payer pour commencer à voir clair :

Google Search Console (gratuit) : ce qui est indexé, les requêtes qui amènent du trafic, le rapport Core Web Vitals page par page.
web.dev (gratuit) : le site officiel de Google avec toute la doc sur les Core Web Vitals, à jour à chaque changement de seuil.
PageSpeed Insights (gratuit) : colle une URL, il vous sort le LCP/INP/CLS réels et un audit Lighthouse complet.
Lighthouse dans Chrome DevTools (gratuit, intégré) : la même chose que PageSpeed Insights mais en local, pratique en cours de dev.
WebAIM Contrast Checker (gratuit) : pour vérifier ses couleurs avant de les intégrer.
design-accessible.fr (gratuit) : checklist d’accessibilité pensée pour les designers, organisée par thème avec des ressources pour chaque bonne pratique.
Ahrefs : côté payant, c’est l’outil que j’utilise pour le suivi de positionnement, l’audit technique complet et le profil de backlinks. Il existe aussi une version gratuite (Ahrefs Webmaster Tools) une fois le site vérifié, largement suffisante pour un blog perso.
Screaming Frog SEO Spider : pour crawler tout son site et retrouver les liens cassés, les balises manquantes, etc.
Squoosh (gratuit) : compresse les images et les convertit en WebP directement dans le navigateur, sans rien installer. Un gain direct sur le LCP.

Conclusion

Rien de révolutionnaire dans cet article, mais c’est le genre de bases qu’on oublie facilement, que ce soit en étant plongé dans le code ou en laissant l’IA générer trop de choses à notre place.

Pour résumer ce qui compte vraiment : un contenu qui répond à une vraie question plutôt qu’un remplissage de mots-clés, un site rapide (LCP < 2,5 s, INP < 200 ms, CLS < 0,1) mesuré régulièrement avec PageSpeed Insights ou Lighthouse, accessible (contraste 4.5:1 minimum, navigation clavier, HTML sémantique) et pensé mobile en premier. Ajoutez à ça un site correctement indexé (IndexNow pour ne pas attendre le passage des robots) et des images compressées en WebP, et vous couvrez déjà 80% du travail.

Le reste, c’est de la régularité : republier, corriger, mesurer à nouveau. Le SEO n’est jamais un chantier fini, plutôt un entretien continu. 👍🏼