Glossaire de Google Search Console et du SEO

Clics

Un clic est compté lorsqu’un internaute clique sur un résultat dans la Recherche Google, Discover ou Google News qui le mène vers une page hors de Google.

Les clics qui gardent l’internaute dans Google, comme une reformulation de requête qui lance une nouvelle recherche, ne sont pas comptés. Cliquer sur un résultat, revenir en arrière puis cliquer de nouveau sur le même lien compte pour un seul clic ; cliquer sur un lien différent compte à nouveau. Les données de clics sont attribuées à l’URL canonique choisie par Google, pas nécessairement à l’URL sur laquelle l’internaute a atterri. Les clics de la Search Console et les sessions GA4 mesurent des choses différentes et coïncident rarement, voir clics GSC et sessions GA4.

Dans GSC Magic: La vue d’ensemble du tableau de bord affiche les clics quotidiens et une carte Top requêtes/pages avec l’évolution des clics par rapport à la période précédente.

Voir aussi: Impressions, CTR (taux de clics), Session (GA4), URL canonique

CTR (taux de clics)

Le CTR est le nombre de clics divisé par le nombre d’impressions, exprimé en pourcentage pour l’ensemble du site ou pour une seule requête, page, pays ou appareil.

Le CTR dépend fortement de la position et du type de résultat affiché : comparez-le entre requêtes ou pages de position similaire plutôt qu’à un objectif unique. Il dépend aussi de l’agrégation : lorsque plusieurs de vos pages apparaissent pour une même requête, le CTR groupé par propriété est généralement plus élevé que le CTR groupé par page, car la propriété totalise une impression et conserve le clic. Si les impressions restent stables mais que les clics baissent, Google suggère de vérifier si votre titre et votre extrait décrivent toujours bien la page.

Dans GSC Magic: report_ctr_outliers liste les pages dont le CTR est inférieur à la moitié du CTR médian de votre site à la même position.

Voir aussi: Clics, Impressions, CTR atypique (page à faible CTR), Position moyenne

Sources: support.google.com, support.google.com, developers.google.com

Position moyenne

La position moyenne est la moyenne de la meilleure position qu’ont occupée votre site ou votre page dans les résultats de la Recherche Google, calculée uniquement pour les recherches qui ont produit une impression.

Si une requête affiche votre site aux positions 2, 4 et 6 et une autre aux positions 3, 5 et 9, la Search Console retient 2 et 3 et affiche une moyenne de 2,5. Chaque élément de résultat occupe une position : tous les liens d’un panneau de connaissances ou d’un AI Overview partagent la position de cet élément, et les annonces n’occupent aucune position. Un résultat jamais vu, par exemple en page 3, n’enregistre aucune position : c’est pourquoi certaines cellules affichent un tiret. La position est calculée uniquement pour la Recherche Google, pas pour Discover ni Google News, et votre propre recherche peut afficher un classement différent, car les résultats dépendent de la localisation et de l’historique. Google conseille de suivre l’évolution dans le temps plutôt que de lire une valeur isolée.

Dans GSC Magic: report_quick_wins utilise la position moyenne pour repérer les couples requête/page classés entre la position 4 et la position 20 avec beaucoup d’impressions.

Voir aussi: Impressions, Mots-clés à portée de tir (gains rapides), AI Overviews et AI Mode, Core update (mise à jour majeure)

Requête

Une requête est un terme de recherche qui a conduit votre site à apparaître dans les résultats Google ; l’onglet Requêtes du rapport Performances regroupe les clics et les impressions par requête.

Le tableau Requêtes n’est jamais complet. Certaines requêtes sont masquées pour des raisons de confidentialité (requêtes anonymisées) et, en raison de limites internes, la Search Console ne stocke et n’affiche que les lignes les plus importantes. Les filtres de requête ne tiennent pas compte de la casse. Pour le type de recherche Web : multimodal, qui couvre les recherches par image comme Google Lens, aucune requête textuelle n’est disponible : la dimension est donc absente. Pour en savoir plus, voir pourquoi la Search Console masque certaines requêtes.

Dans GSC Magic: gsc_query_analytics renvoie jusqu’à 25 000 lignes de requêtes par appel via l’API Search Analytics.

Voir aussi: Requêtes anonymisées, Limite de 1 000 lignes, Requêtes de marque et hors marque, Page (dimension)

Page (dimension)

La dimension Page regroupe les données de Performances par URL vers laquelle pointait un résultat de recherche après les redirections, généralement attribuée à l’URL canonique de la page.

Lorsqu’un internaute clique sur une URL en doublon, la Search Console attribue le clic à l’URL canonique choisie par Google, que vous pouvez vérifier dans l’outil d’inspection d’URL. Choisir l’onglet Pages fait passer l’agrégation du tableau de la propriété à la page : chaque URL affichée pour une requête obtient donc sa propre impression. Le graphique reste agrégé par propriété, ce qui explique le plus souvent l’écart entre le total du tableau et celui du graphique.

Voir aussi: URL canonique, Inspection d’URL, Requête, Impressions

Apparence dans les résultats

L’apparence dans les résultats est une dimension du rapport Performances qui regroupe les données selon le type de résultat ou de fonctionnalité dans lequel votre page est apparue, par exemple les extraits d’avis, les vidéos ou les fiches produit.

Le filtre ne liste que les types pour lesquels votre site a enregistré des impressions. Le regroupement par apparence dans les résultats agrège le tableau par page. Les clics sont attribués à une URL, pas à une URL plus une fonctionnalité : un nombre de clics filtré peut donc inclure des clics sur un lien simple vers la même page. Certains types plus anciens, comme les résultats enrichis FAQ et How-to, sont indiqués par Google comme obsolètes.

Dans GSC Magic: gsc_query_analytics peut regrouper ou filtrer les données de performances par apparence dans les résultats.

Voir aussi: Données structurées et résultats enrichis, Type de recherche, Page (dimension)

Sources: support.google.com

Type de recherche

Le type de recherche est le filtre du rapport Performances qui sépare le trafic venu des recherches Web (textuelles ou multimodales), Images, Vidéos et Google News dans la Recherche Google.

Web : textuel couvre les requêtes saisies dans la barre de recherche classique ; Web : multimodal couvre les recherches effectuées avec des images, y compris Google Lens, Circle to Search et la recherche d’images de Chrome. Images, Vidéos et Google News couvrent les onglets correspondants. Discover et Google News disposent de leurs propres rapports de performances. Google recommande d’analyser les types de recherche séparément lorsqu’on enquête sur une baisse, et la limite de lignes de l’API s’applique par type de recherche.

Voir aussi: Apparence dans les résultats, Limite de 1 000 lignes, Core update (mise à jour majeure)

Pays et appareil

Dans le rapport Performances, Pays regroupe les données selon l’origine de la recherche et Appareil selon ordinateur, mobile ou tablette.

Ces deux dimensions sont agrégées par propriété. Google indique que les requêtes sans la dimension requête ou page, comme les pays, les appareils et l’apparence dans les résultats, sont affichées et exportées dans leur intégralité : elles ne sont donc pas concernées par la limite quotidienne de lignes. Comparer ordinateur et mobile peut afficher un tiret pour la position lorsqu’une page n’a eu aucune impression sur l’un des appareils.

Dans GSC Magic: gsc_query_analytics accepte les pays et les appareils comme dimensions et comme filtres.

Voir aussi: Limite de 1 000 lignes, Position moyenne, Requête

Fraîcheur des données et données préliminaires

La fraîcheur des données est le délai avant que la Search Console n’affiche les données de performances ; les chiffres les plus récents peuvent être préliminaires, encore en cours de collecte, et sont tracés en pointillés.

La vue sur 24 heures montre les dernières 24 heures disponibles avec quelques heures de décalage, en points horaires et dans le fuseau horaire de votre navigateur. Les autres vues utilisent l’heure du Pacifique et affichent par défaut des journées complètes. Dans l’API Search Analytics, dataState « final » (valeur par défaut) ne renvoie que les données finalisées, tandis que « all » inclut les données fraîches et « hourly_all » ajoute la ventilation horaire. Le guide de l’API de Google précise que les données sont généralement disponibles au bout de 2 à 3 jours.

Dans GSC Magic: La synchronisation hébergée actualise les quatre derniers jours toutes les six heures, car Google révise les chiffres récents.

Voir aussi: Conservation des données sur 16 mois, Clics, Impressions

Sources: support.google.com, developers.google.com, developers.google.com, developers.google.com

Requêtes anonymisées

Les requêtes anonymisées sont des recherches que la Search Console laisse hors de ses tableaux pour protéger la vie privée, parce qu’elles n’ont pas été saisies par plus de quelques dizaines d’internautes sur deux à trois mois.

Elles comptent toutefois dans les totaux du graphique, sauf si vous appliquez un filtre de requête : la somme des lignes du tableau est donc généralement inférieure au total. Les filtres les écartent entièrement : les requêtes contenant un mot plus les requêtes ne contenant pas ce mot totalisent moins que le total non filtré. Voir pourquoi la Search Console masque certaines requêtes de recherche.

Dans GSC Magic: GSC Magic interroge la même API Search Analytics : il ne peut pas non plus retrouver les requêtes anonymisées.

Voir aussi: Requête, Limite de 1 000 lignes, Requêtes de marque et hors marque

Limite de 1 000 lignes

L’interface de la Search Console affiche et exporte au maximum 1 000 lignes par tableau ; l’API Search Analytics renvoie jusqu’à 25 000 lignes par appel, avec pagination.

Google indique que le plafond de l’API est de 50 000 lignes par jour, par site et par type de recherche, un maximum qui peut ne pas être atteint dans tous les cas. L’API renvoie 1 000 lignes par défaut ; rowLimit la porte à 25 000 et startRow permet de parcourir le reste page par page. Les requêtes sans dimension requête ou page renvoient toutes les données. Pour la liste de requêtes la plus complète, Google renvoie vers l’export en masse vers BigQuery. Détails dans la limite de 1 000 lignes expliquée et le guide de l’API Search Console.

Dans GSC Magic: gsc_query_analytics demande jusqu’à 25 000 lignes par requête : un agent IA travaille donc avec bien plus que les 1 000 lignes de l’interface.

Voir aussi: Requête, Requêtes anonymisées, Conservation des données sur 16 mois, Type de recherche

Sources: developers.google.com, developers.google.com, support.google.com

Conservation des données sur 16 mois

Le rapport Performances de la Search Console couvre les 16 derniers mois ; les jours plus anciens disparaissent, sauf si vous copiez les données ailleurs via l’API ou l’export en masse.

Seize mois suffisent pour comparer une baisse récente avec les mêmes semaines un an plus tôt, le contrôle que Google suggère pour la saisonnalité. Pour des comparaisons plus longues, Google suggère de récupérer les données avec l’API Search Analytics ou l’export en masse et de les stocker dans vos propres systèmes. Voir 3 façons de conserver les données Search Console au-delà de 16 mois et comment GSC Magic conserve l’historique.

Dans GSC Magic: Pro et Agency récupèrent jusqu’à 16 mois lors d’un passage à un plan supérieur et ne purgent jamais l’historique stocké ; Free conserve 14 jours.

Voir aussi: Saisonnalité, Limite de 1 000 lignes, Déclin de contenu

Exploration et indexation

Exploration et Googlebot

L’exploration est la façon dont Google découvre et télécharge les pages ; Googlebot est le robot d’exploration de la Recherche Google, avec une version pour smartphone et une version pour ordinateur.

Google découvre les nouvelles URL principalement grâce aux liens des pages qu’il connaît déjà et grâce aux plans de site, puis il les récupère et exécute le JavaScript avec une version récente de Chrome. Comme Google indexe en priorité la version mobile de la plupart des sites, la majorité des requêtes viennent de Googlebot Smartphone. Pour la Recherche Google, Googlebot récupère les 2 premiers Mo d’un type de fichier pris en charge (64 Mo pour les PDF). Bloquer l’exploration avec robots.txt n’empêche pas une URL d’apparaître dans les résultats ; utilisez noindex pour cela. Le rapport Statistiques d’exploration indique le nombre de requêtes, les codes de réponse et les problèmes de disponibilité. Google n’accepte pas de paiement pour explorer un site plus souvent.

Dans GSC Magic: GSC Magic n’explore pas votre site : il lit les données d’inspection d’URL fournies par Google ainsi que les statistiques et problèmes d’exploration de Bing.

Voir aussi: Indexation, Budget d’exploration, robots.txt, Plan de site XML

Sources: developers.google.com, developers.google.com, support.google.com

Indexation

L’indexation est l’étape où Google analyse une page explorée et l’enregistre dans l’index Google ; seules les pages indexées peuvent apparaître dans la Recherche Google.

La Recherche Google fonctionne en trois étapes : exploration, indexation et diffusion des résultats, et toutes les pages ne franchissent pas chaque étape. Google ne garantit pas d’indexer une page, même si elle respecte les règles de base de la recherche. Le rapport Indexation des pages explique pourquoi des URL ne sont pas indexées, par exemple « Explorée, actuellement non indexée » (explorée, peut-être indexée plus tard, inutile de la resoumettre) ou « Découverte, actuellement non indexée » (trouvée, mais l’exploration a été reprogrammée pour éviter de surcharger le site). Voir Search Console : pages non indexées, causes et correctifs.

Dans GSC Magic: report_index_health lit les URL de vos plans de site, les inspecte avec l’API URL Inspection et les regroupe par état de couverture.

Voir aussi: Exploration et Googlebot, Inspection d’URL, noindex, URL canonique

Budget d’exploration

Le budget d’exploration est l’ensemble des URL que Google peut et veut explorer sur un site, déterminé par deux facteurs : la limite de capacité d’exploration et la demande d’exploration.

La limite de capacité d’exploration évite que Googlebot surcharge votre serveur ; la demande d’exploration dépend de la taille du site, de la fréquence de mise à jour, de la qualité des pages et de leur pertinence. Chaque nom d’hôte a son propre budget d’exploration. Google précise que son guide du budget d’exploration s’adresse surtout aux très grands sites (environ 1 million de pages ou plus modifiées chaque semaine), aux sites comptant 10 000 pages ou plus modifiées chaque jour, ou aux sites avec de nombreuses URL en « Découverte, actuellement non indexée ». Si les nouvelles pages sont explorées le jour de leur publication, le budget d’exploration n’est pas votre problème.

Voir aussi: Exploration et Googlebot, Plan de site XML, Indexation

URL canonique

Une URL canonique est l’URL que Google retient comme la plus représentative d’un ensemble de pages en doublon ; c’est la version généralement affichée dans les résultats de recherche.

Les doublons viennent des versions HTTP et HTTPS, des URL mobile et ordinateur, des paramètres de tri et de filtre, ou des variantes régionales. Vous pouvez exprimer une préférence avec rel="canonical", des redirections et des plans de site, mais Google la traite comme une indication, pas comme une règle, et peut choisir une autre URL. La Search Console attribue les clics et les impressions à la canonique. Comparez la canonique déclarée par l’utilisateur et celle choisie par Google dans l’outil d’inspection d’URL.

Dans GSC Magic: gsc_inspect_url renvoie à la fois la canonique déclarée et celle choisie par Google pour une URL.

Voir aussi: Redirection (301 et 302), Page (dimension), Inspection d’URL, hreflang

Sources: developers.google.com, developers.google.com

noindex

noindex est une règle, définie par une balise meta robots ou un en-tête HTTP X-Robots-Tag, qui demande à Google de retirer une page de ses résultats de recherche.

Google doit explorer la page pour voir la règle : la page ne doit donc pas être bloquée par robots.txt, sinon elle peut encore apparaître dans les résultats si d’autres pages la lient. Google ne prend pas en charge noindex dans robots.txt. Après l’ajout de la règle, une page reste dans les résultats tant que Google ne la réexplore pas, ce qui peut prendre des mois pour les pages secondaires. Si robots.txt bloque la page, l’inspection d’URL indique que l’indexation est autorisée, car Google ne peut pas voir la règle noindex.

Dans GSC Magic: gsc_inspect_url et report_index_health indiquent quand Google a trouvé une règle noindex sur une URL.

Voir aussi: robots.txt, Indexation, Inspection d’URL

robots.txt

robots.txt est un fichier à la racine d’un site qui indique aux robots d’exploration quelles URL ils peuvent consulter ; il contrôle l’exploration, pas l’indexation d’une page.

Google le décrit comme un moyen de gérer le trafic des robots et d’éviter de surcharger votre serveur. Une page bloquée par robots.txt peut encore être indexée sans description si d’autres pages la lient : utilisez noindex ou une protection par mot de passe pour tenir une page hors de Google. Ne bloquez pas les fichiers CSS ou JavaScript dont Google a besoin pour comprendre la page.

Dans GSC Magic: Le tableau de bord lance un audit rapide robots.txt et plan de site pour chaque site.

Voir aussi: noindex, Exploration et Googlebot, Plan de site XML

Plan de site XML

Un plan de site XML est un fichier qui liste les pages, images, vidéos et autres fichiers de votre site afin que les moteurs de recherche les trouvent et les explorent plus efficacement.

Un plan de site peut aussi porter la date de dernière modification et les versions linguistiques alternatives. Il aide la découverte mais ne garantit ni l’exploration ni l’indexation. Google indique que les petits sites bien maillés (environ 500 pages ou moins) n’en ont peut-être pas besoin, tandis que les sites grands, récents ou riches en médias en profitent le plus. Pour de nombreuses URL nouvelles ou modifiées, Google recommande de soumettre un plan de site plutôt que de demander l’indexation URL par URL. Voir plan de site soumis mais pages non indexées.

Dans GSC Magic: gsc_list_sitemaps affiche l’état et les erreurs, gsc_submit_sitemap en soumet un (Pro et Agency), et bing_submit_sitemap l’envoie à Bing.

Voir aussi: Exploration et Googlebot, Indexation, robots.txt, IndexNow

Inspection d’URL

L’inspection d’URL est l’outil de la Search Console qui montre la version indexée d’une URL par Google, pourquoi elle est ou n’est pas indexée, et qui permet de tester une page en direct.

Il indique l’état d’indexation, la canonique choisie par Google, la dernière exploration, les données structurées détectées et une capture d’écran de la page rendue. Le test en direct vérifie si une page semble indexable, mais ne peut pas prédire quelle URL Google traitera comme canonique. L’API URL Inspection ne renvoie que la version indexée, n’a pas de test en direct et autorise 2 000 inspections par site et par jour. Voir comment inspecter 500 URL avec l’API.

Dans GSC Magic: gsc_inspect_url inspecte une URL et gsc_inspect_urls_batch en inspecte jusqu’à 500 en un seul appel, dans le quota de Google.

Voir aussi: Demande d’indexation, Indexation, URL canonique, Soft 404

Sources: support.google.com, developers.google.com, developers.google.com

Demande d’indexation

La demande d’indexation est un bouton de l’outil d’inspection d’URL qui demande à Google d’explorer une seule URL ; elle ne garantit pas que la page sera indexée.

Vous devez être propriétaire ou utilisateur complet de la propriété. Les demandes individuelles sont soumises à un quota, et demander plusieurs fois la même URL ne la fera pas explorer plus vite. L’exploration peut prendre de quelques jours à quelques semaines. Pour de nombreuses URL, Google recommande plutôt de soumettre un plan de site. L’API Indexing de Google, distincte, est officiellement limitée aux pages balisées JobPosting ou BroadcastEvent. Voir IndexNow ou l’API Indexing de Google.

Dans GSC Magic: L’outil facultatif gsc_request_indexing utilise l’API Indexing de Google, que Google ne prend en charge que pour les pages JobPosting et BroadcastEvent.

Voir aussi: Inspection d’URL, Plan de site XML, IndexNow, Indexation

Sources: developers.google.com, developers.google.com

Soft 404

Un soft 404 est une page qui renvoie un code de succès 200 mais ressemble à une erreur ou à une page vide pour Google, qui la signale et ne l’indexe pas.

Google recommande de renvoyer un code 404 pour les pages qui n’existent vraiment pas, et d’ajouter des informations aux pages qui doivent rester afin qu’elles ne ressemblent pas à des erreurs. Pour voir ce que Google voit, lancez un test en direct dans l’inspection d’URL et ouvrez la capture d’écran de la page rendue.

Voir aussi: Inspection d’URL, Indexation, Redirection (301 et 302)

Redirection (301 et 302)

Une redirection envoie les visiteurs et les robots d’une URL vers une autre ; une 301 est permanente et signale que la cible doit être la canonique, une 302 est temporaire.

Avec les redirections permanentes (301, 308, meta refresh instantanée), Google affiche généralement l’URL cible dans les résultats. Avec les temporaires (302, 303, 307), Google suit la redirection mais ne l’utilise pas comme signal de canonisation : l’URL source peut donc rester dans les résultats. Les redirections côté serveur sont les plus fiables ; les robots de Google suivent jusqu’à 10 sauts par défaut. La Search Console attribue les clics à l’URL finale, après les redirections.

Voir aussi: URL canonique, Soft 404, Page (dimension)

Sources: developers.google.com, developers.google.com

hreflang

hreflang est une annotation qui indique à Google quelles pages sont des versions linguistiques ou régionales d’un même contenu, pour qu’il montre la bonne aux internautes.

Vous pouvez la déclarer dans des balises link HTML, des en-têtes HTTP ou le plan de site ; les trois méthodes sont équivalentes. Chaque version doit se lister elle-même et lister toutes les autres versions, avec des URL absolues. Google n’utilise pas hreflang pour détecter la langue d’une page. Les pages dans la même langue pour des régions différentes sont des doublons : Google recommande donc de combiner hreflang et canonisation.

Voir aussi: URL canonique, Plan de site XML, Pays et appareil

Sources: developers.google.com, developers.google.com

Données structurées et résultats enrichis

Les données structurées sont un format normalisé, qui utilise surtout le vocabulaire schema.org et s’écrit souvent en JSON-LD, qui décrit le contenu d’une page à Google et peut la rendre éligible aux résultats enrichis.

Les résultats enrichis sont des résultats de recherche à l’affichage amélioré, comme les étoiles d’avis, les détails d’une recette ou les prix de produits. Une page doit réunir toutes les propriétés obligatoires pour être éligible, et un balisage qui enfreint les consignes de Google sur les données structurées peut la rendre inéligible. Google suggère de tester le balisage avec le test des résultats enrichis pendant le développement, puis de surveiller les rapports de résultats enrichis dans la Search Console après la mise en production. Les types de résultats enrichis apparaissent aussi dans la dimension apparence dans les résultats.

Dans GSC Magic: gsc_inspect_url indique les résultats enrichis que Google a détectés sur une URL.

Voir aussi: Apparence dans les résultats, Inspection d’URL, CTR (taux de clics)

Voir aussi: LCP (Largest Contentful Paint, affichage du plus grand contenu), INP (Interaction to Next Paint, délai de réponse aux interactions), CLS (Cumulative Layout Shift, décalage cumulé de mise en page), CrUX (Chrome UX Report)

Core Web Vitals et vitesse des pages

Core Web Vitals

Les Core Web Vitals sont trois indicateurs Google de l’expérience réelle des internautes : Largest Contentful Paint (chargement), Interaction to Next Paint (réactivité) et Cumulative Layout Shift (stabilité visuelle).

Les seuils considérés comme bons sont un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1, mesurés au 75e percentile des chargements de page, séparément pour mobile et ordinateur. Une page est conforme lorsque les trois respectent la cible. Google indique que de bons Core Web Vitals vont dans le sens de ce que récompensent ses systèmes de classement principaux, dans le cadre de l’expérience de la page. Le rapport Core Web Vitals de la Search Console montre les performances de vos pages.

Dans GSC Magic: cwv_get_origin, cwv_get_url et cwv_history lisent les Core Web Vitals des internautes réels, et le tableau de bord affiche une carte Core Web Vitals par site.

Sources: web.dev, developers.google.com

LCP (Largest Contentful Paint, affichage du plus grand contenu)

Le LCP mesure le chargement : le temps avant l’affichage de la plus grande image, du plus grand bloc de texte ou de la plus grande vidéo dans la zone visible. Un bon LCP est de 2,5 secondes ou moins.

Le LCP est mesuré à partir du moment où l’internaute a ouvert la page : il inclut donc le temps de réponse du serveur, les redirections et l’établissement de la connexion. Utilisez le 75e percentile des chargements de page, séparé entre mobile et ordinateur, pour juger si la plupart des visiteurs vivent une bonne expérience.

Dans GSC Magic: Les outils cwv renvoient le LCP au 75e percentile avec la part de chargements bons, à améliorer et mauvais.

Voir aussi: Core Web Vitals, INP (Interaction to Next Paint, délai de réponse aux interactions), CLS (Cumulative Layout Shift, décalage cumulé de mise en page), PageSpeed Insights et Lighthouse

Sources: web.dev

INP (Interaction to Next Paint, délai de réponse aux interactions)

L’INP mesure la réactivité : le temps que met la page à répondre visiblement aux clics, aux appuis et aux pressions de touche. Un bon INP est de 200 millisecondes ou moins, mauvais au-delà de 500.

L’INP observe la latence de toutes les interactions pendant une visite et signale à peu près la plus lente, en ignorant les valeurs aberrantes. Il remplace le First Input Delay (FID), qui ne mesurait que le délai d’entrée de la première interaction. Les longues tâches JavaScript sur le thread principal sont une cause fréquente d’INP mauvais.

Voir aussi: Core Web Vitals, LCP (Largest Contentful Paint, affichage du plus grand contenu), CLS (Cumulative Layout Shift, décalage cumulé de mise en page)

Sources: web.dev

CLS (Cumulative Layout Shift, décalage cumulé de mise en page)

Le CLS mesure la stabilité visuelle : la plus grande rafale de décalages de mise en page inattendus pendant la vie d’une page. Un bon CLS est de 0,1 ou moins, mauvais au-delà de 0,25.

Un décalage de mise en page se produit lorsqu’un élément visible se déplace entre deux images rendues sans intervention de l’internaute, par exemple quand une image sans dimensions définies ou une publicité tardive pousse le texte vers le bas. Les décalages séparés de moins d’une seconde sont regroupés dans une fenêtre de session, et la plus grande fenêtre constitue le score CLS.

Voir aussi: Core Web Vitals, LCP (Largest Contentful Paint, affichage du plus grand contenu), INP (Interaction to Next Paint, délai de réponse aux interactions)

Sources: web.dev

CrUX (Chrome UX Report)

CrUX est le jeu de données public de Google sur la façon dont les internautes réels vivent les sites avec Chrome, et la source de données terrain des Core Web Vitals dans les outils de Google.

Les origines et les pages ne sont incluses que si elles sont publiquement découvrables et comptent assez de visiteurs pour un échantillon statistiquement significatif : beaucoup de pages à faible trafic n’ont donc aucune donnée. La Recherche Google utilise CrUX pour nourrir le facteur de classement lié à l’expérience de la page. PageSpeed Insights affiche CrUX comme données terrain et se rabat sur les données au niveau de l’origine lorsqu’une page a trop peu d’échantillons.

Dans GSC Magic: Les outils cwv interrogent CrUX pour une origine ou une URL ; les pages sans trafic Chrome suffisant ne renvoient aucune donnée.

Voir aussi: Core Web Vitals, PageSpeed Insights et Lighthouse, LCP (Largest Contentful Paint, affichage du plus grand contenu)

Sources: developer.chrome.com

PageSpeed Insights et Lighthouse

PageSpeed Insights remonte les données CrUX des internautes réels d’une page et lance Lighthouse, un outil open source qui audite les performances, l’accessibilité, les bonnes pratiques et le SEO en laboratoire simulé.

Les données terrain montrent ce que les visiteurs réels ont vécu au fil du temps ; les données de laboratoire de Lighthouse proviennent d’une exécution contrôlée unique, utile pour le débogage mais qui peut manquer des goulots d’étranglement réels. L’évaluation Core Web Vitals de PSI s’appuie sur les données terrain : une page ou une origine est conforme lorsque le 75e percentile du LCP, de l’INP et du CLS est Bon. Lighthouse s’exécute aussi dans les DevTools de Chrome, en ligne de commande ou comme module Node.

Dans GSC Magic: psi_run_audit lance Lighthouse via PageSpeed Insights, et la carte Core Web Vitals du tableau de bord peut démarrer un audit.

Voir aussi: CrUX (Chrome UX Report), Core Web Vitals, LCP (Largest Contentful Paint, affichage du plus grand contenu)

Sources: developers.google.com, developer.chrome.com

Analyse SEO

Mots-clés à portée de tir (gains rapides)

Les mots-clés à portée de tir sont des requêtes où une page se classe déjà juste en dehors des premiers résultats, souvent entre les positions 4 et 20, avec assez d’impressions pour gagner des clics.

C’est un terme de pratique SEO, pas une métrique de la Search Console. La méthode habituelle : filtrer le rapport Performances par requête et par page, garder les lignes dont la position moyenne est juste sous le haut du classement et dont les impressions comptent, puis améliorer la page existante plutôt que d’en écrire une nouvelle. Rappelez-vous que la position moyenne est une moyenne : vérifiez la tendance. Voir comment trouver les mots-clés à portée de tir et 7 gains rapides en SEO.

Dans GSC Magic: report_quick_wins renvoie les couples requête/page en positions 4 à 20 avec beaucoup d’impressions, triés par clics supplémentaires potentiels.

Voir aussi: Position moyenne, Impressions, CTR atypique (page à faible CTR)

Sources: support.google.com

Cannibalisation de mots-clés

La cannibalisation de mots-clés se produit lorsque deux pages ou plus de votre site rivalisent pour la même requête, en se partageant les impressions et les clics au lieu qu’une seule page se classe bien.

C’est un terme de pratique SEO, pas un terme de Google. Dans la Search Console, elle apparaît comme une requête dont les impressions se répartissent sur plusieurs URL, parfois en échangeant leurs places au fil du temps. Tous les chevauchements ne sont pas un problème : des intentions différentes peuvent mériter des pages différentes, et les requêtes de marque affichent souvent de nombreuses URL. Les correctifs courants sont la fusion des pages avec une redirection 301, la différenciation de leur intention ou l’ajustement des liens internes. Voir la cannibalisation de mots-clés dans la Search Console.

Dans GSC Magic: report_cannibalization liste les requêtes où deux de vos pages ou plus obtiennent chacune une part significative des impressions.

Voir aussi: Requête, Page (dimension), URL canonique, Redirection (301 et 302)

Sources: support.google.com

Déclin de contenu

Le déclin de contenu est une baisse progressive et durable des clics organiques d’une page sur plusieurs mois, par opposition à une chute soudaine due à un problème technique ou à une mise à jour.

C’est un terme de pratique SEO. Les causes typiques sont des informations obsolètes, des pages concurrentes plus récentes ou un intérêt de recherche qui se déplace. Comparer plusieurs périodes consécutives distingue une érosion régulière d’une mauvaise semaine ; vérifier les mêmes mois un an plus tôt écarte la saisonnalité. Voir comment détecter un déclin de contenu.

Dans GSC Magic: report_content_decay liste les pages dont les clics ont baissé dans chacune des trois dernières fenêtres (28 jours chacune par défaut).

Voir aussi: Saisonnalité, Conservation des données sur 16 mois, Core update (mise à jour majeure)

CTR atypique (page à faible CTR)

Un CTR atypique est une page ou une requête dont le taux de clics est nettement inférieur à celui des autres résultats de votre site à la même position.

Comme le CTR baisse avec la position, un faible CTR n’a de sens que comparé à position similaire. Les cas atypiques ont souvent un titre ou un extrait qui ne correspond pas à la requête, ou subissent la concurrence d’un résultat enrichi ou d’un AI Overview sur la même page de résultats. Google suggère de revoir le titre et l’extrait lorsque les impressions tiennent mais que les clics baissent. Voir les mots-clés à faible CTR dans la Search Console.

Dans GSC Magic: report_ctr_outliers signale les pages dont le CTR est inférieur à la moitié du CTR médian de votre site à la même position.

Voir aussi: CTR (taux de clics), Position moyenne, Mots-clés à portée de tir (gains rapides)

Requêtes de marque et hors marque

Les requêtes de marque contiennent le nom de votre marque, ses fautes de frappe ou vos produits propres ; les requêtes hors marque sont toutes les autres recherches qui affichent votre site.

Les requêtes de marque se classent généralement plus haut et obtiennent plus de clics, tandis que les requêtes hors marque montrent comment de nouvelles personnes vous trouvent. La Search Console propose un filtre de requêtes de marque dans le rapport Performances, classées par un système assisté par IA plutôt que par une liste de mots-clés. Google indique qu’il n’est disponible que pour les propriétés de premier niveau comptant assez de requêtes et d’impressions, et qu’il peut mal classer certaines requêtes.

Dans GSC Magic: report_brand_split sépare les requêtes selon les termes de marque que vous fournissez et renvoie les clics, les impressions et la part de clics de chaque groupe.

Voir aussi: Requête, CTR (taux de clics), Requêtes anonymisées

Saisonnalité

La saisonnalité est une hausse ou une baisse récurrente de la demande de recherche au même moment chaque année, comme les fêtes, qui modifie le trafic sans aucun changement de classement.

Le guide de Google sur les baisses de trafic suggère de régler le rapport Performances sur les 16 derniers mois pour voir si une baisse se répète chaque année, et de vérifier les principales requêtes dans Google Trends pour voir si la demande a baissé sur tout le web. Si les impressions ont chuté alors que la position tenait, la demande est la cause probable. Voir saisonnalité ou vraie perte de classement.

Dans GSC Magic: Comme Pro et Agency conservent l’historique stocké au-delà de 16 mois, les agents peuvent comparer la même période sur plus d’un an.

Voir aussi: Conservation des données sur 16 mois, Déclin de contenu, Core update (mise à jour majeure)

Core update (mise à jour majeure)

Une core update est une modification importante et large des systèmes de classement de Google, décidée plusieurs fois par an et annoncée sur la liste des mises à jour du classement de la Recherche Google.

Les core updates ne ciblent pas des sites précis. Google recommande d’attendre la fin du déploiement, puis de comparer une semaine complète après avec une semaine avant son début. Une petite baisse, par exemple de la position 2 à la position 4, n’exige aucune action radicale ; une baisse importante et durable appelle une évaluation honnête de l’utilité de tout le site. Google note que certains effets apparaissent en quelques jours, d’autres en plusieurs mois. Voir la checklist de baisse de trafic organique.

Dans GSC Magic: report_traffic_drops compare une période avec la précédente et liste les pages ou requêtes qui ont perdu ou gagné le plus de clics.

Voir aussi: Position moyenne, Saisonnalité, Type de recherche

Sources: developers.google.com, developers.google.com

Bing et IndexNow

Bing Webmaster Tools

Bing Webmaster Tools est l’équivalent de Search Console chez Microsoft : performances de recherche, données d’exploration et d’indexation, soumission d’URL et recherche de mots-clés pour Bing.

Son API donne un accès programmatique aux statistiques de trafic et de classement, aux détails des liens et des mots-clés, aux statistiques d’exploration et à la soumission d’URL et de plans de site. Le rapport Search Performance affiche 16 mois d’historique. AI Performance, lancé en préversion publique en février 2026, montre la fréquence à laquelle vos pages sont citées dans Microsoft Copilot et dans les réponses générées par l’IA de Bing. Voir le guide de l’API Bing Webmaster Tools et Bing Webmaster Tools dans GSC Magic.

Dans GSC Magic: Avec votre clé API Bing, GSC Magic ajoute des outils Bing pour les statistiques de requêtes et de pages, les données d’exploration, la recherche de mots-clés et la soumission d’URL, plus report_google_vs_bing.

Voir aussi: IndexNow, GEO (generative engine optimization), Plan de site XML

Sources: learn.microsoft.com, blogs.bing.com, blogs.bing.com

IndexNow

IndexNow est un protocole ouvert qui permet à un site de prévenir instantanément les moteurs de recherche participants, dont Bing, Naver, Seznam.cz, Yandex et Yep, qu’une URL a été ajoutée, mise à jour ou supprimée.

Vous hébergez un fichier de clé sur votre site pour prouver la propriété, puis vous envoyez une URL ou un lot à un point de terminaison IndexNow ; une soumission est partagée avec tous les moteurs participants. Une réponse HTTP 200 signifie seulement que l’URL a été reçue, pas qu’elle sera indexée. Google ne figure pas parmi les moteurs participants. Voir comment configurer IndexNow avec un agent IA.

Dans GSC Magic: indexnow_generate_key crée une clé et indexnow_submit envoie jusqu’à 10 000 URL par appel (Pro et Agency, avec votre clé IndexNow).

Voir aussi: Bing Webmaster Tools, Demande d’indexation, Plan de site XML

Sources: indexnow.org, indexnow.org, indexnow.org

Google Analytics 4

Session (GA4)

Dans Google Analytics 4, une session est une période pendant laquelle un internaute interagit avec votre site ou votre application ; sur le web, elle se termine après 30 minutes d’inactivité par défaut.

Une session démarre lorsque quelqu’un ouvre l’application ou affiche une page alors qu’aucune session n’est active, et GA4 enregistre un événement session_start. Il n’y a pas de durée maximale, et le délai peut être modifié dans les paramètres du flux de données. Les sessions ne sont pas la même chose que les clics de la Search Console, voir pourquoi les chiffres ne concordent pas et GA4 dans GSC Magic.

Dans GSC Magic: ga_run_report interroge les sessions GA4 en lecture seule, par n’importe quelle dimension comme la page de destination ou la source de session.

Voir aussi: Clics, Événement clé (GA4), Trafic de référence (Referral), Trafic des assistants IA

Sources: support.google.com

Événement clé (GA4)

Un événement clé est un événement GA4 que vous marquez comme important pour votre activité, comme un achat ou une inscription ; les événements clés s’appelaient auparavant conversions dans Analytics.

Tout événement collecté peut être marqué comme événement clé. Google réserve désormais le terme « conversion » aux actions mesurées pour les campagnes et les enchères Google Ads : les nombres de conversions et d’événements clés peuvent donc différer.

Dans GSC Magic: ga_list_key_events liste les événements clés configurés sur une propriété GA4.

Voir aussi: Session (GA4), Trafic de référence (Referral)

Sources: support.google.com

Trafic de référence (Referral)

Dans GA4, Referral est le canal par défaut des visiteurs qui arrivent par des liens non publicitaires situés sur d’autres sites ou applications, comme des blogs ou des sites d’actualité.

GA4 affecte les sessions aux canaux par défaut à partir de la source et du support. Les résultats de la recherche organique, y compris les AI Overviews et AI Mode de Google, vont dans Organic Search, et les assistants IA reconnus disposent de leur propre canal AI Assistant. Direct couvre les visites depuis un lien enregistré ou une URL saisie à la main.

Voir aussi: Trafic des assistants IA, Session (GA4), Événement clé (GA4)

Sources: support.google.com

Trafic des assistants IA

Le trafic des assistants IA est constitué des visites venant de liens dans des assistants conversationnels comme ChatGPT, Gemini, Claude ou Copilot, que GA4 regroupe dans son canal AI Assistant lorsqu’il reconnaît le référent.

Depuis mai 2026, GA4 définit le support ai-assistant et le canal AI Assistant lorsque le référent correspond à un assistant reconnu ; le canal exclut les AI Overviews et AI Mode de Google, qui comptent comme Organic Search. Le canal dépend du référent : les visites d’assistants qui arrivent sans référent n’y sont donc pas comptées. Le trafic n’est pas la même chose que les citations. Voir suivre le trafic de ChatGPT et Perplexity dans GA4.

Dans GSC Magic: Le tableau de bord compte les sessions GA4 issues de sources d’assistants IA comme ChatGPT, Perplexity, Claude et Gemini ; il mesure des visites, pas des citations.

Voir aussi: Trafic de référence (Referral), Session (GA4), GEO (generative engine optimization), AI Overviews et AI Mode