Les définitions des concepts clés du SEO technique : crawl, indexation, serveur, performance, entités et SEO génératif. Concis, à jour, et maillé vers les guides et outils.
Un lexique orienté SEO technique, pensé pour les praticiens : chaque définition va à l'essentiel et renvoie vers le guide, l'article ou l'outil correspondant.
Sur un site de quelques centaines de pages, la question ne se pose pas. Elle devient centrale dès que Google doit arbitrer : le nombre d'URL qu'il explore dépend de ce que le serveur encaisse (crawl rate) et de l'appétit qu'il a pour le site (crawl demand). Laisser Googlebot s'épuiser sur des paramètres, des facettes ou des pages de tri, c'est autant de pages utiles découvertes trop tard.
On les confond souvent, alors que ce sont deux moments séparés. Crawler, c'est lire l'URL ; indexer, c'est décider de la garder et de la rendre éligible au classement. D'où deux situations qui déroutent : une page parfaitement crawlée que Google refuse d'indexer, et une URL bloquée dans le robots.txt qui reste pourtant affichée dans les résultats.
Posé à la racine du domaine, il dit aux robots où ils n'ont pas à aller. Attention au malentendu classique : il gouverne le crawl, pas l'indexation. Une URL interdite d'exploration peut très bien rester indexée si d'autres pages pointent vers elle. Et quand plusieurs règles se chevauchent, c'est la plus spécifique qui l'emporte, pas la première rencontrée.
La consigne d'indexation qui vit dans le head de la page : noindex pour la sortir de l'index, nofollow pour couper le jus de ses liens. Son point faible, il faut que Google puisse crawler la page pour la lire. Bloquer l'URL au robots.txt et y poser un noindex, c'est se tirer une balle dans le pied : le moteur ne verra jamais la consigne.
Même effet que la meta robots, mais servi dans l'en-tête HTTP au lieu du code de la page. L'intérêt : il s'applique à ce qui n'a pas de head, PDF, images, flux, réponses générées. C'est l'outil de prédilection pour désindexer en masse ou piloter des ressources non-HTML sans toucher au template.
Sortir une page de l'index pour de bon passe par un noindex laissé en place le temps que Google repasse. L'outil de suppression de la Search Console, lui, ne fait que masquer six mois environ, la page revient ensuite. Et le réflexe de bloquer au robots.txt est contre-productif : sans crawl, Google ne lit pas le noindex et garde la page.
Le même contenu joignable par plusieurs portes : HTTP et HTTPS, avec ou sans paramètres de tracking, préprod oubliée en ligne, pagination. Google retient une version et répartit mal les signaux entre les clones. On assainit avec du canonical, des redirections, ou un vrai contrôle de ce qui a le droit d'être indexé.
La balise rel=canonical désigne la version de référence quand un même contenu existe sous plusieurs URL. C'est un signal fort, pas un ordre : Google le suit la plupart du temps, mais garde le droit d'élire une autre canonique s'il juge le choix incohérent. Bien posée, elle regroupe les signaux sur une seule adresse.
Deux redirections qu'on ne peut pas intervertir sans conséquence. Le 301 est permanent et transmet la valeur de l'ancienne URL, c'est celui des migrations. Le 302 se dit temporaire, donc Google continue de considérer l'URL d'origine comme la bonne. Se tromper de code sur une refonte reste une des causes les plus banales de chute de trafic.
Le code à renvoyer quand le site part en maintenance : il prévient Googlebot que l'indisponibilité est passagère, surtout accompagné d'un Retry-After. Servir cette maintenance en 200 avec une page vide, ou en 404, c'est le meilleur moyen de voir des pages décrocher de l'index.
La liste des URL qu'on souhaite voir explorées, avec des indices comme le lastmod. Utile pour la découverte, en particulier sur les gros sites ou les pages mal maillées, mais il ne force jamais l'indexation. Règle d'hygiène : n'y mettre que des URL canoniques et indexables, sinon on envoie des signaux contradictoires.
Une page vers laquelle aucun lien interne ne pointe. Les robots ont du mal à la trouver, souvent repérée seulement via le sitemap, et privée de PageRank interne elle rank mal. Pour les débusquer, il faut croiser trois sources : le crawl, le sitemap et les logs.
La carte d'identité qu'un client HTTP présente, navigateur comme robot. C'est elle qui permet de reconnaître Googlebot, Googlebot-Image, Bingbot ou les crawlers d'IA type GPTBot et ClaudeBot. Elle se falsifie en une ligne, donc pour valider un vrai Googlebot on ne s'y fie pas : on vérifie l'IP par reverse DNS.
Le moment où Google exécute le JavaScript d'une page pour en voir le rendu final. L'opération coûte cher et arrive en différé, ce qui peut retarder l'indexation du contenu injecté côté client. Le pari le plus sûr reste d'avoir le contenu et les liens présents dès le HTML servi.
Tout ce que le serveur annonce avant même d'envoyer le contenu : statut, Cache-Control, X-Robots-Tag, Vary, Content-Type. Invisibles pour le visiteur, ils décident du cache, de l'indexation et de la façon dont un robot interprète la réponse. Un curl -I suffit à les lire, et beaucoup de bugs SEO se règlent à ce niveau.
Le log d'accès du serveur consigne chaque requête reçue, ligne par ligne. C'est la seule source qui montre ce que Googlebot fait vraiment : quelles URL il visite, à quelle fréquence, quels codes il reçoit. On y voit le budget gaspillé et les pages jamais crawlées, des choses qu'aucun autre outil ne révèle.
Un cache HTTP posé devant le serveur applicatif, qui sert les pages déjà calculées à toute vitesse. Excellent pour le TTFB et le budget de crawl, mais il a un revers : mal réglé, il peut servir la même variante en cache à tout le monde et masquer des comportements qu'on croyait sous contrôle.
Le fichier de config Apache qui agit répertoire par répertoire, et via mod_rewrite réécrit ou redirige les URL. Puissant, mais piégeux et coûteux à l'exécution : règles qui se marchent dessus, redirections en cascade, ordre de priorité mal compris. Un .htaccess touffu est souvent une dette technique SEO qui s'ignore.
Les mesures d'expérience perçue que Google suit : LCP pour l'affichage du plus gros élément, CLS pour la stabilité de la mise en page, INP pour la réactivité (elle a détrôné le FID en 2024). Elles se jugent sur données réelles (CrUX), pas en labo, et pèsent autant sur le classement que sur le ressenti de l'utilisateur.
L'ensemble des liens qui relient les pages d'un site entre elles. Il fait circuler le PageRank, dit à Google quelles pages comptent, et donne sa cohérence au cocon sémantique, ce cluster construit autour d'une page pilier. Un maillage travaillé pousse crawl et classement vers les pages qu'on veut mettre en avant, au lieu de les diluer.
Une entité, c'est un objet identifié sans ambiguïté (une personne, un lieu, une marque) que Google relie dans son Knowledge Graph. Le SEO sémantique ne court plus après le seul mot-clé, il cherche à faire comprendre et rattacher la bonne entité, ce que renforcent les données structurées et les liens sameAs.
Le format que Google recommande pour les données structurées Schema.org, glissé dans un script application/ld+json. Il décrit noir sur blanc ce que contient la page (un produit, un article, une FAQ, une entité), de quoi débloquer des résultats enrichis et nourrir la compréhension des moteurs comme des IA.
L'encadré de réponse que Google affiche tout en haut, au-dessus des liens classiques. On l'attrape en répondant de façon nette et cadrée à une question précise, une définition courte, une liste ou un tableau, souvent aidé par un balisage propre et une FAQ bien posée.
Generative Engine Optimization : travailler pour être cité par les moteurs génératifs et les AI Overviews, ChatGPT, Gemini, Perplexity. Ça repose sur du contenu factuel et structuré qui fait autorité, une entité claire, et un choix assumé de qui, parmi les crawlers d'IA, a le droit d'accéder au site.