Données structurées : le guide des résultats enrichis (2026)
SEO technique Données structurées (Schema.org) : le guide des résultats enrichis 2026 Les données structurées aident Google — et désormais les IA — à comprendre votre contenu, et peuvent afficher des résultats enrichis qui font grimper le taux de clic. Mais en 2026, les règles ont changé. Par Mickaël Sirope WP SEO Lecture 8 min Mis à jour en 2026 Sommaire C’est quoi, les données structurées ? Un seul format recommandé : le JSON-LD Les types qui comptent encore en 2026 Ce qui a changé en 2026 Données structurées et IA Comment les ajouter sans coder Questions fréquentes Les données structurées font partie de ces sujets qui semblent réservés aux développeurs, et qui pourtant changent concrètement l’allure de vos pages dans Google. Un prix affiché, des étoiles d’avis, un fil d’Ariane sous votre titre : tout cela vient d’un balisage invisible pour l’internaute, mais très lisible pour les moteurs. Voici comment ça marche, et surtout ce qui a bougé cette année. En bref Les données structurées ne sont pas un facteur de classement magique, mais elles débloquent les résultats enrichis et aident Google comme les IA à comprendre votre contenu. En 2026, certains types perdent leur affichage enrichi — mieux vaut miser sur les bons. C’est quoi, les données structurées ? Les données structurées sont un vocabulaire standard, appelé Schema.org, qui décrit explicitement le contenu d’une page : « ceci est un produit », « ceci est un article », « ceci est une entreprise avec ces horaires ». Là où un humain devine le sens en lisant, la machine, elle, a besoin qu’on le lui dise. L’objectif est double. D’abord, aider les moteurs à comprendre votre page sans ambiguïté. Ensuite, débloquer les résultats enrichis : ces éléments visuels qui enrichissent votre lien dans les résultats de recherche — étoiles de note, prix, disponibilité, fil d’Ariane, questions… Un lien enrichi occupe plus de place, inspire davantage confiance et, mécaniquement, se fait cliquer plus souvent. Autrement dit, vous ne changez pas le texte que voit l’internaute : vous ajoutez une couche de sens en coulisse. C’est l’une des briques classiques du SEO technique, au même titre que le sitemap ou le maillage. Un seul format recommandé : le JSON-LD Il existe plusieurs manières d’écrire des données structurées, mais Google en recommande une : le JSON-LD. C’est un petit bloc de code inséré dans la page, séparé de votre contenu visible. Son gros avantage : il ne se mélange pas à votre HTML de mise en page, donc il est facile à générer, à relire et à maintenir. Les deux autres formats historiques, Microdata et RDFa, fonctionnent encore mais sont plus anciens et bien moins pratiques : ils s’entremêlent directement à vos balises HTML, ce qui rend le tout fragile à maintenir. Sauf cas très particulier, vous n’avez aucune raison de les préférer aujourd’hui. La bonne nouvelle, c’est que vous n’aurez presque jamais à écrire ce JSON-LD à la main : les plugins s’en chargent. Mais savoir que c’est le format de référence vous aide à faire les bons choix de configuration. Les types qui comptent encore en 2026 Schema.org compte des centaines de types, mais tous ne déclenchent pas de résultat enrichi dans Google. En 2026, environ 31 types conservent des résultats enrichis actifs. Inutile de tout baliser : concentrez-vous sur ceux qui apportent une vraie valeur à votre page. Les plus utiles selon votre activité : Product + Offer — prix, disponibilité, note. Indispensable en e-commerce, c’est ce qui affiche un prix directement dans les résultats. Article — pour les contenus de blog et de presse, avec auteur et date. Review — les avis et notes, sous forme d’étoiles. BreadcrumbList — le fil d’Ariane, qui remplace l’URL brute par un chemin lisible. Event — dates, lieux et billetterie pour les événements. LocalBusiness — horaires, adresse, zone desservie. Crucial en référencement local, et de plus en plus utilisé par les IA pour répondre aux questions de proximité. Recipe et Video — recettes et vidéos, avec leurs affichages dédiés. Pour une boutique, le schéma Produit change la donne : c’est un chantier que nous traitons systématiquement dans nos missions de SEO WooCommerce, parce qu’un prix et une note affichés font une vraie différence de clics. Résultats enrichis Des avis, des prix, un fil d’Ariane qui font cliquer Vous voulez des résultats enrichis (avis, prix, fil d’Ariane) qui font cliquer ? On met en place le bon balisage, proprement, sans sur-optimiser. Réserver mon appel (30 min) → Sans engagement · 100% concret · en visio Ce qui a changé en 2026 C’est le point le plus important de ce guide, et celui que beaucoup de sites n’ont pas encore intégré. Google a revu en profondeur les résultats enrichis qu’il affiche. Le résultat enrichi FAQ a été officiellement supprimé en mai 2026. Le schéma FAQ n’affiche plus les questions dépliables sous votre lien. Le résultat How-To a été fortement réduit et n’apparaît plus que dans des cas limités. Le résultat Review a été restreint sur les pages non-primaires, pour limiter les abus d’avis autoproclamés. La conclusion est nette : ne misez plus sur le schéma FAQ pour obtenir un rich result. Il ne fait plus gagner de place dans les résultats. Concentrez vos efforts sur les types à forte valeur qui, eux, sont toujours affichés : Product, Article, LocalBusiness et Breadcrumb. Le schéma FAQ n’affiche plus de résultat enrichi depuis 2026 : misez sur Product, Article, LocalBusiness et Breadcrumb. Cela ne veut pas dire qu’il faut supprimer chaque balise FAQ existante en urgence, mais qu’il ne faut plus en attendre un gain de visibilité direct. Vos priorités de balisage doivent suivre ce que Google affiche réellement aujourd’hui — pas ce qui fonctionnait il y a deux ans. Données structurées et IA Le paradoxe de 2026, c’est que les données structurées perdent du terrain côté rich results… mais en gagnent côté intelligences artificielles. Un balisage Article complet, avec l’auteur et l’organisation clairement déclarés, est aujourd’hui plus utile pour être cité dans les AI Overviews
Canonical, redirections et hreflang : le guide technique 2026
SEO technique Canonical, redirections et hreflang : le guide technique (2026) Trois mécanismes qui disent à Google quelle version d’une page compter. Mal utilisés, ils diluent votre référencement ou font disparaître des pages. Voici comment les régler proprement. Par Mickaël Sirope WP SEO Lecture 8 min Mis à jour en 2026 Sommaire Le problème de départ : les URLs multiples La balise canonical, sans se tromper Les redirections : 301, 302 et pièges Le hreflang et ses règles strictes Les erreurs qui coûtent cher Questions fréquentes Canonical, redirections, hreflang : trois outils qui répondent tous à la même question, « quelle version de cette page Google doit-il compter ? ». Pris séparément, chacun est simple. C’est quand on les combine mal qu’ils se retournent contre vous : pages qui disparaissent de l’index, autorité diluée, clusters multilingues qui s’effondrent. Ce guide remet chaque mécanisme à sa place et vous donne les règles à ne jamais enfreindre. En bref La canonical désigne l’URL de référence quand plusieurs se ressemblent. La redirection 301 déplace une page pour de bon. Le hreflang sert la bonne langue au bon visiteur. Le danger vient de leurs conflits : une canonical qui contredit un hreflang casse tout le cluster. Le problème de départ : les URLs multiples Un même contenu est presque toujours accessible via plusieurs URLs sans que vous l’ayez voulu. La page d’accueil répond en http:// et en https://, avec et sans www, avec ou sans slash final. Une fiche produit se décline en dizaines d’URLs à cause des paramètres de tri, de filtre ou de tracking (?utm=, ?couleur=, ?page=). Pour un humain, c’est la même page. Pour Google, ce sont autant d’adresses distinctes. Le résultat, c’est du contenu dupliqué : Google voit plusieurs pages quasi identiques et doit deviner laquelle privilégier. S’il devine mal, il indexe la mauvaise version, disperse les signaux de popularité entre les doublons et affaiblit votre positionnement. Le rôle de la canonical, des redirections et du hreflang est justement de lever cette ambiguïté — chacun dans son contexte. La balise canonical, sans se tromper La balise rel= »canonical » indique à Google quelle URL est la version de référence parmi un groupe de pages semblables. Concrètement, vous placez dans le <head> de chaque doublon un lien pointant vers l’URL que vous voulez voir indexée. Google concentre alors ses signaux sur cette version et ignore les autres. Deux principes suffisent à éviter 90 % des erreurs. D’abord, auto-référencez toujours la page canonique : la version de référence doit pointer sa canonical vers elle-même. C’est ce qui verrouille votre intention et évite que Google choisisse une autre URL à votre place. Ensuite, ne dirigez que des pages réellement équivalentes vers une même canonical. Envoyer des pages sans rapport vers une URL de référence revient à dire à Google « ignore ces pages » — et elles disparaîtront de l’index. Les erreurs fréquentes Canonical vers une page non pertinente — Google traite le signal comme une suggestion, pas un ordre. S’il juge la cible incohérente, il l’ignore… et vous perdez le contrôle. Canonical vers une page en noindex — vous demandez à Google de compter une page que vous lui interdisez d’indexer par ailleurs. Signal contradictoire, résultat imprévisible. Canonical vers une URL redirigée — la référence pointe vers une adresse qui renvoie ailleurs. Google doit sauter d’URL en URL et finit souvent par ignorer la consigne. La canonical est un outil de consolidation, pas de suppression. Pour retirer vraiment une page, on utilise le noindex ou une redirection — sujet suivant. On sécurise Contenu dupliqué, pages qui disparaissent, migration à venir ? Contenu dupliqué, pages qui disparaissent, migration à venir ? On sécurise votre technique avant que Google ne s’en mêle. Réserver mon appel (30 min) → Sans engagement · 100% concret · en visio Les redirections : 301, 302 et pièges Une redirection envoie automatiquement visiteurs et robots d’une URL vers une autre. Deux codes comptent vraiment. La 301 est permanente : elle dit à Google « cette page a définitivement déménagé » et lui transmet l’autorité accumulée par l’ancienne URL. La 302 est temporaire : Google garde l’ancienne page en mémoire et ne transfère pas les signaux. Règle simple : si le changement est définitif, c’est une 301. Si vous utilisez une 302 par erreur pour un déménagement permanent, vous laissez l’autorité derrière vous. On redirige dans trois cas : une page supprimée qu’on renvoie vers l’équivalent le plus proche, une URL modifiée (changement de slug, réorganisation), ou une migration complète de site. Dans tous les cas, la cible doit être pertinente pour l’internaute qui arrivait sur l’ancienne. Deux pièges à éviter Le premier, ce sont les chaînes de redirections : l’URL A redirige vers B, qui redirige vers C. Chaque saut ralentit le visiteur, dilue un peu d’autorité et gaspille le budget de crawl de Google. Redirigez toujours directement vers la destination finale — A vers C, sans étape intermédiaire. Le second, c’est de tout rediriger vers la page d’accueil. C’est tentant après une refonte, mais Google le détecte comme un soft 404 : une redirection qui ne mène pas vers un contenu équivalent est traitée comme une page inexistante. Mieux vaut une vraie 404 propre qu’une redirection trompeuse vers l’accueil. Ces réglages relèvent du SEO technique et se vérifient lors d’un audit technique SEO. Une chaîne de redirections ou un renvoi massif vers l’accueil coûte plus cher qu’une 404 assumée. Le hreflang et ses règles strictes Le hreflang concerne les sites multilingues ou multi-régions. Il indique à Google quelle version d’une page servir selon la langue et le pays du visiteur — la page anglaise à un Britannique, la française à un Français. Bien posé, il évite que Google affiche la mauvaise langue dans ses résultats. Mal posé, il ne fait rien du tout, car le hreflang ne pardonne aucune approximation. Quatre règles sont non négociables : Auto-référence — chaque page doit se déclarer elle-même dans ses balises hreflang, en plus de citer ses variantes (self-referential). Réciprocité — si la
Sitemap XML et robots.txt : à quoi ça sert, comment les régler
SEO technique Sitemap XML et robots.txt : à quoi ça sert et comment les régler Ces deux petits fichiers décident de ce que Google peut explorer et de ce qu’il découvre. Mal réglés, ils rendent invisibles des pages entières. Voici comment les maîtriser. Par Mickaël Sirope WP SEO Lecture 7 min Mis à jour en 2026 Sommaire Explorer vs indexer : la distinction de base Le fichier robots.txt Le sitemap XML Les soumettre à Google Les erreurs les plus fréquentes La check-list à garder sous la main Questions fréquentes On imagine souvent que Google voit tout, tout le temps. En réalité, ce sont deux fichiers texte minuscules — le robots.txt et le sitemap XML — qui orientent ce que les moteurs explorent et découvrent sur votre site. Ils ne font pas de miracle, mais une seule ligne mal placée peut suffire à masquer des pages entières. Bonne nouvelle : une fois qu’on a compris à quoi ils servent, ils deviennent simples à régler. En bref Le robots.txt dit aux robots où ils peuvent aller ; le sitemap XML leur liste les pages qui comptent. Le premier gère l’exploration, pas l’indexation. Le second doit ne contenir que des URLs propres. Mal utilisés, ils créent plus de problèmes qu’ils n’en résolvent — c’est tout l’enjeu du SEO technique. Explorer vs indexer : la distinction de base Avant de toucher au moindre fichier, il faut poser deux mots qu’on confond tout le temps. Cette distinction, à elle seule, évite l’écrasante majorité des erreurs. Explorer (crawler), c’est l’action du robot qui découvre une URL, la visite et lit son contenu. Indexer, c’est l’étape d’après : Google décide de stocker cette page dans son index pour pouvoir l’afficher dans les résultats. Une page peut être explorée sans être indexée, et — c’est plus surprenant — indexée sans avoir été correctement explorée. Retenez cette image : le robots.txt agit sur la porte d’entrée (peut-on explorer ?), pas sur la vitrine (la page apparaît-elle dans Google ?). Confondre les deux, c’est bloquer une page en pensant la cacher… alors qu’elle reste visible. On y revient juste en dessous. Le fichier robots.txt Le robots.txt est un fichier texte placé à la racine de votre domaine (votresite.fr/robots.txt). Son rôle : guider les robots en leur indiquant les zones qu’ils peuvent ou non explorer. C’est aussi un outil pour gérer le budget de crawl — le temps que Google consacre à votre site — en l’empêchant de perdre son énergie sur des URLs inutiles (paramètres, filtres, pages techniques). Point crucial Le robots.txt empêche l’exploration, pas forcément l’indexation. Une page bloquée par un Disallow peut quand même apparaître dans Google — sans description, avec la mention « aucune information disponible ». Pour vraiment retirer une page de l’index, il faut une balise noindex, pas un Disallow. Ce paradoxe piège beaucoup de monde. Si Google découvre le lien vers une page ailleurs (dans un autre site, un sitemap, un menu), il peut l’indexer sans jamais la lire — puisqu’il n’a pas le droit d’y entrer. Résultat : une page fantôme dans les résultats, sans titre ni description. La règle à ne jamais oublier Pour désindexer une page, laissez Google l’explorer et posez une balise noindex dessus. Pour la retirer de l’exploration une fois qu’elle est déjà bien hors de l’index, le Disallow peut alors servir. L’ordre compte : bloquer et « noindexer » en même temps, c’est se tirer une balle dans le pied — Google ne verra jamais le noindex. Ne jamais bloquer le CSS et le JavaScript Une erreur classique consiste à bloquer les dossiers contenant le CSS ou le JavaScript pour « alléger » l’exploration. C’est contre-productif : Google a besoin de ces ressources pour rendre la page, c’est-à-dire l’afficher comme un vrai visiteur. S’il ne peut pas les charger, il voit une page cassée et juge mal sa qualité comme son adaptation mobile. Penser aussi aux robots des IA En 2026, Google n’est plus le seul robot à visiter votre site. Les moteurs génératifs envoient les leurs (GPTBot et consorts). Si vous voulez que votre contenu puisse être cité par les IA, veillez à ne pas les bloquer dans votre robots.txt. C’est un réflexe simple mais souvent oublié, au cœur du GEO. Diagnostic offert Un doute sur ce que Google explore vraiment sur votre site ? On vérifie ensemble votre robots.txt, votre sitemap et votre couverture d’index en 30 minutes — sans jargon, avec des actions concrètes à la clé. Réserver mon appel (30 min) → Sans engagement · 100% concret · en visio Le sitemap XML Le sitemap XML joue le rôle inverse du robots.txt : au lieu d’interdire, il invite. C’est la liste des URLs importantes de votre site, présentée dans un format que les moteurs lisent facilement. Il ne garantit pas l’indexation, mais il aide Google à découvrir vos pages plus vite, surtout sur un gros site ou un site récent au maillage encore léger. Le principe d’un bon sitemap tient en une phrase : il ne doit contenir que des URLs indexables, en 200 OK. Concrètement, on en exclut : les pages en noindex — vous demandez à Google de ne pas les afficher, inutile de les lister ici ; les URLs redirigées (301 ou 302) — c’est la destination qui doit figurer, pas l’ancienne adresse ; les pages en erreur 404 ou toute URL cassée ; les pages sans valeur SEO (pages de remerciement, panier, résultats de recherche interne, etc.). Pourquoi tant de rigueur ? Parce qu’un sitemap gonflé d’URLs non indexables envoie des signaux contradictoires. Vous dites à Google « voici mes pages importantes » puis, page après page, il tombe sur des redirections et des 404. Cela brouille sa lecture de votre site et gaspille son budget de crawl. Un sitemap propre, c’est une carte fiable ; un sitemap sale, c’est un plan raturé. Un sitemap ne sert pas à lister « tout » votre site — seulement les pages que vous voulez vraiment voir dans Google. Les soumettre à
Core Web Vitals : comprendre et optimiser LCP, INP, CLS
SEO technique Core Web Vitals : comprendre et optimiser LCP, INP et CLS (2026) Les Core Web Vitals sont des signaux de classement Google qui mesurent l’expérience réelle de vos visiteurs. Voici ce que veut dire chaque métrique, comment la mesurer et par où commencer. Par Mickaël Sirope WP SEO Lecture 7 min Mis à jour en 2026 Sommaire Que sont les Core Web Vitals ? LCP : le temps d’affichage INP : la réactivité CLS : la stabilité visuelle Comment les mesurer Les leviers universels d’optimisation Et sur WordPress ? Questions fréquentes « Vos Core Web Vitals sont dans le rouge. » Cette phrase, on l’entend souvent, mais elle ne veut rien dire tant qu’on n’a pas compris ce qui se cache derrière. Les Core Web Vitals ne sont pas un score abstrait sorti d’un outil : ils traduisent, en chiffres, ce que ressent une personne réelle quand elle ouvre votre page. Une page qui met du temps à s’afficher, un bouton qui ne répond pas, un texte qui saute pendant la lecture — voilà ce qu’ils mesurent. Ce guide vous explique chaque métrique, comment la lire, et par où commencer. En bref Trois métriques, trois questions simples : la page s’affiche-t-elle vite (LCP) ? Réagit-elle quand on clique (INP) ? Reste-t-elle stable pendant qu’elle charge (CLS) ? Google s’appuie sur les données des vrais utilisateurs, pas sur un test de labo isolé. Que sont les Core Web Vitals ? Les Core Web Vitals sont un ensemble de trois indicateurs définis par Google pour mesurer l’expérience utilisateur d’une page web. Ils font partie des signaux de classement : à contenu comparable, une page rapide et stable est mieux placée qu’une page lente et instable. Ils ne remplacent pas la pertinence ni les liens, mais ils départagent. Chaque métrique cible une dimension précise de l’expérience : le chargement (LCP), la réactivité (INP) et la stabilité visuelle (CLS). Prises ensemble, elles décrivent ce que vit un visiteur entre le moment où il clique sur votre lien et celui où il peut vraiment utiliser la page. Voyons-les une par une. LCP (Largest Contentful Paint) — le temps d’affichage Le LCP mesure le temps qu’il faut pour afficher le plus gros élément visible de la page dans la fenêtre du navigateur : le plus souvent une grande image, une vidéo ou un bloc de texte principal. C’est un bon proxy du moment où l’internaute a l’impression que « la page est chargée ». Le seuil : un bon LCP est sous 2,5 secondes. Au-delà, l’expérience se dégrade, et le visiteur risque de repartir avant même d’avoir vu votre contenu. Ce qui plombe le LCP est souvent en amont de l’affichage : un temps de réponse serveur (TTFB) trop lent. Si le serveur met une seconde à renvoyer la page, le navigateur n’a même pas commencé à dessiner l’élément principal. Vient ensuite le poids de l’élément lui-même (une image lourde et non optimisée) et la façon dont il est chargé. On y revient dans les leviers. INP (Interaction to Next Paint) — la réactivité L’INP mesure la réactivité de la page : quand l’internaute clique, tape ou touche un élément, combien de temps s’écoule avant que l’écran réponde visuellement ? Il évalue l’ensemble des interactions sur la durée de la visite, pas seulement la première. C’est un changement important : l’INP a remplacé le FID (First Input Delay) en 2024 comme Core Web Vital officielle. Le FID ne mesurait que le délai de la toute première interaction ; l’INP est plus exigeant et plus représentatif de l’expérience réelle. Le seuil : un bon INP est sous 200 millisecondes. Et c’est là que le bât blesse : l’INP est la Core Web Vital la plus souvent ratée. Environ 43% des sites échouent au seuil des 200 ms. La cause principale : un excès de JavaScript qui monopolise le fil principal du navigateur et l’empêche de répondre aux clics. 2,5 sseuil d’un bon LCP (temps d’affichage) 200 msseuil d’un bon INP (réactivité) 0,1seuil d’un bon CLS (stabilité visuelle) CLS (Cumulative Layout Shift) — la stabilité visuelle Le CLS mesure la stabilité visuelle de la page : les éléments bougent-ils de manière inattendue pendant le chargement ? Vous connaissez la sensation — vous allez cliquer sur un lien, une image se charge au-dessus, tout se décale, et vous cliquez sur le mauvais bouton. C’est exactement ce que le CLS pénalise. Le seuil : un bon CLS est sous 0,1. À la différence des deux autres, ce n’est pas une durée mais un score sans unité, qui additionne l’ampleur des décalages inattendus. La bonne nouvelle : le CLS est souvent la métrique la plus simple à corriger. La plupart des sauts viennent d’éléments dont le navigateur ne connaît pas la taille à l’avance — images sans dimensions, publicités, bannières, polices qui se substituent. Réserver l’espace à l’avance règle l’essentiel. Diagnostic offert Vos Core Web Vitals sont dans le rouge et vous ne savez pas pourquoi ? On fait le diagnostic ensemble. En 30 minutes, on identifie quelle métrique bloque, pourquoi, et les correctifs qui rapportent le plus vite. Réserver mon appel (30 min) → Sans engagement · 100% concret · en visio Comment les mesurer Avant d’optimiser, il faut mesurer correctement — et surtout comprendre qu’il existe deux types de données qui ne racontent pas la même histoire. Les données terrain (field data), issues du rapport CrUX (Chrome User Experience Report). Elles reflètent ce que vivent vos vrais utilisateurs, sur leurs vrais appareils et connexions, sur les 28 derniers jours. C’est cette donnée que Google utilise pour le classement. Les données labo (lab data), issues d’un test ponctuel dans un environnement simulé. Utiles pour diagnostiquer et reproduire un problème, mais elles ne représentent qu’une seule mesure, dans des conditions données. La distinction est cruciale : un bon score en labo n’empêche pas d’échouer sur le terrain, et inversement. Pour piloter votre SEO, c’est le terrain qui compte. Les trois outils à connaître : PageSpeed Insights — affiche
Audit technique SEO : la checklist complète (2026)
SEO technique Faire un audit technique SEO : la checklist complète (2026) Avant d’écrire le moindre contenu, votre site doit être explorable, indexable et rapide. Voici la checklist d’audit technique, phase par phase, pour repérer ce qui bloque vraiment vos positions. Par Mickaël Sirope WP SEO Lecture 8 min Mis à jour en 2026 Sommaire Pourquoi commencer par la technique Phase 1 — Crawlabilité Phase 2 — Indexation Phase 3 — Performance Phase 4 — Mobile & sécurité Phase 5 — Données structurées & signaux À quelle fréquence auditer Les outils indispensables Récap en checklist Questions fréquentes La plupart des sites qui stagnent ne stagnent pas à cause de leur contenu. Ils stagnent parce qu’une partie de leurs pages n’est pas explorée, pas indexée, ou trop lente pour rassurer Google. Un audit technique sert exactement à ça : repérer, méthodiquement, ce qui empêche vos pages d’exister aux yeux des moteurs. Voici la marche à suivre, dans le bon ordre. En bref Un audit technique se déroule en cinq phases : crawlabilité, indexation, performance, mobile & sécurité, puis données structurées. On les traite dans cet ordre : inutile d’optimiser une page que Google ne peut ni explorer ni indexer. Pourquoi commencer par la technique On a souvent le réflexe inverse : on veut « écrire du contenu qui rank » avant même de vérifier que le site est sain. C’est mettre la charrue avant les bœufs. La grande majorité des problèmes de classement ne viennent pas de textes trop courts ou mal écrits, mais d’un souci de crawl ou d’indexation : une page bloquée, une balise qui se contredit, un site trop lent que Google finit par explorer moins souvent. Être visible de Google est le préalable à tout le reste. Tant qu’une page n’est pas correctement explorée puis indexée, elle ne peut se positionner sur aucun mot-clé — quel que soit son contenu. C’est pour ça qu’un audit démarre toujours par la technique. C’est le fondement de tout notre travail de SEO technique, avant même de parler stratégie éditoriale. Phase 1 — Crawlabilité La crawlabilité, c’est la capacité de Google à parcourir votre site. Si le robot ne peut pas atteindre une page, elle n’existe pas pour lui. On vérifie donc, dans l’ordre : Un fichier robots.txt propre — il ne doit bloquer que ce qui doit l’être. Une directive trop large peut couper l’accès à des sections entières sans que vous le sachiez. Les CSS et le JS non bloqués — Google a besoin de charger ces ressources pour « voir » votre page comme un internaute. Les bloquer fausse l’analyse et peut coûter des positions. Un sitemap XML à jour — il liste les URLs à explorer en priorité et doit être soumis dans la Search Console, sans pages mortes ni redirections. Un maillage interne qui rend les pages accessibles — une page sans lien entrant est une page orpheline, difficile à découvrir pour le robot. Un budget de crawl maîtrisé — sur les gros sites, Google alloue un nombre limité de pages explorées. On évite de le gaspiller sur des pages inutiles (paramètres d’URL, filtres, doublons). C’est ici que se joue la première marche. Pour aller au fond du sujet, on détaille tout dans notre guide dédié au sitemap XML et robots.txt. Phase 2 — Indexation Une page explorée n’est pas forcément indexée. La phase 2 vérifie que Google range bien vos pages dans son index — et surtout qu’aucun signal ne l’en empêche par accident. On contrôle trois choses : les balises noindex (une page importante ne doit jamais en porter), les canonical (elles doivent pointer vers la bonne version de chaque URL), et surtout les conflits entre les deux. Un noindex et une canonical qui se contredisent est l’un des tueurs d’indexation les plus silencieux : la page envoie deux ordres opposés à Google, qui tranche rarement en votre faveur. Ce type de conflit ne déclenche aucune alerte visible — il faut aller le chercher. On finit par vérifier la couverture d’index dans la Search Console : combien de pages sont indexées, lesquelles sont exclues, et pour quel motif. C’est le juge de paix. Pour maîtriser ces balises sans vous piéger, lisez notre guide canonical et redirections. Une page peut être parfaitement écrite et rester invisible : il suffit d’un noindex oublié ou d’une canonical mal dirigée. Phase 3 — Performance Une fois que Google peut explorer et indexer vos pages, on regarde à quelle vitesse elles se chargent. La performance n’est pas un détail de confort : elle influence directement l’expérience utilisateur et fait partie des signaux de classement. Le cadre de référence, ce sont les Core Web Vitals : le LCP (temps d’affichage du contenu principal), l’INP (réactivité aux interactions) et le CLS (stabilité visuelle pendant le chargement). On mesure la vitesse générale, mais surtout les données terrain — celles issues des vrais visiteurs, plus fiables qu’un simple test en laboratoire. C’est le terrain qui décide. On traite ce sujet en profondeur, réglage par réglage, dans notre article dédié aux Core Web Vitals. Audit priorisé Envie d’un audit technique clair, priorisé et actionnable ? C’est exactement ce qu’on fait. En 30 minutes, on passe votre site au crible et on repère ce qui bloque vraiment vos positions — dans l’ordre des priorités. Réserver mon appel (30 min) → Sans engagement · 100% concret · en visio Phase 4 — Mobile & sécurité La performance réglée, on vérifie que le site tient la route là où l’essentiel du trafic se joue : sur mobile. Google applique l’indexation mobile-first, c’est-à-dire qu’il classe votre site à partir de sa version mobile, pas de la version bureau. Un contenu masqué sur téléphone, un menu cassé ou une mise en page qui saute, et ce sont vos positions qui trinquent — y compris pour les recherches faites sur ordinateur. Trois points de contrôle : Indexation mobile-first — la version mobile doit contenir le même contenu que la version bureau, sans texte tronqué ni bloc caché. HTTPS partout