Glossaire SEO technique

Budget de crawl

Sur un site de quelques centaines de pages, oublie le sujet, Google passe partout. Il devient stratégique quand le volume explose : le nombre d'URL que Googlebot explore dépend de ce que ton serveur encaisse sans ralentir (le crawl rate) et de l'envie qu'a Google de revenir (le crawl demand). Le piège classique, ce sont les facettes, les tris et les paramètres qui génèrent des millions d'URL, Googlebot s'y épuise et découvre tes vraies pages avec des semaines de retard. Ça se surveille dans les logs, pas dans la Search Console.

Guide crawl & indexation

Voir aussi Demande de crawl (crawl demand) Log serveur (access log) Paramètres d'URL & tracking Gonflement de l'index (index bloat)

Demande de crawl (crawl demand)

La moitié souvent oubliée du budget de crawl : l'appétit de Google pour tes URL. Une page populaire, souvent mise à jour et bien maillée, il veut la recrawler vite ; une page morte depuis deux ans, il l'oublie peu à peu. En pratique, la fraîcheur du contenu, les liens entrants et le trafic tirent la demande vers le haut. C'est pour ça qu'un simple ping de sitemap ne suffit jamais à faire recrawler un site entier : sans demande, Google ne se déplace pas, quoi que tu déclares.

Guide crawl & indexation

Voir aussi Budget de crawl Sitemap XML

Fichier robots.txt

Posé à la racine du domaine, il dit aux robots où ils n'ont pas à aller. Le malentendu qui coûte cher : il gouverne le crawl, pas l'indexation. Une URL en Disallow peut très bien rester affichée dans Google si d'autres pages pointent vers elle, simplement sans description. Autre subtilité que beaucoup ignorent, quand plusieurs règles matchent, Google applique la plus spécifique, pas la première rencontrée. Et un noindex posé dans une page bloquée au robots.txt ne sera jamais lu, donc jamais appliqué.

Robots.txt Checker · Guide crawl & indexation

Voir aussi Balise meta robots Désindexation User-agent (Googlebot & crawlers IA)

User-agent (Googlebot & crawlers IA)

La carte d'identité qu'un client HTTP présente, navigateur comme robot. C'est elle qui distingue Googlebot, Googlebot-Image, Bingbot ou les crawlers d'IA type GPTBot et ClaudeBot. Point capital : elle se falsifie en une ligne de commande. Donc quand tu vois « Googlebot » dans tes logs, tu ne le crois pas sur parole, tu vérifies l'IP par reverse DNS, elle doit résoudre en googlebot.com ou google.com puis re-résoudre vers la même IP. Sans ça, tu ouvres la porte aux scrapers déguisés.

Veille user agents IA

Voir aussi Log serveur (access log) Fichier robots.txt GEO (SEO génératif)

Crawl vs indexation

On les confond tout le temps, 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 les débutants : une page parfaitement crawlée que Google refuse d'indexer (jugée trop faible, ou canonicalisée ailleurs), et une URL bloquée au robots.txt qui reste pourtant affichée. Le rapport Couverture de la Search Console vit sur cette distinction, savoir la lire évite bien des fausses alertes.

Guide crawl & indexation

Voir aussi Fichier robots.txt Désindexation URL canonique (rel=canonical)

Rendu JavaScript & crawl

Le moment où Google exécute le JavaScript d'une page pour en voir le rendu final. L'opération coûte cher en ressources et arrive en différé, parfois plusieurs jours après le premier passage sur le HTML brut. Résultat, un contenu ou des liens injectés uniquement côté client peuvent rester invisibles un moment, voire passer à la trappe si le rendu échoue. Le pari le plus sûr n'a pas changé depuis des années : servir le contenu et les liens essentiels dans le HTML initial, et traiter le JS comme un bonus.

SEO technique

Voir aussi Crawl vs indexation Budget de crawl

URL orpheline

Une page vers laquelle aucun lien interne ne pointe. Les robots ont un mal fou à la trouver, souvent repérée seulement parce qu'elle traîne dans le sitemap, et comme elle ne reçoit aucun PageRank interne, elle rank au ras des pâquerettes. Pour les débusquer, aucun outil unique ne suffit : il faut croiser trois sources, le crawl du site, les URL du sitemap et les hits réels dans les logs. Ce qui apparaît dans les logs mais jamais dans le crawl, ce sont tes orphelines.

Sitemap Killer

Voir aussi Maillage interne / cocon sémantique PageRank interne Log serveur (access log)

Balise meta robots

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. Se tirer une balle dans le pied, c'est bloquer l'URL au robots.txt tout en y posant un noindex, le moteur ne verra jamais la consigne. Nuance qui compte : noindex laisse suivre les liens par défaut, il faut ajouter nofollow explicitement pour les neutraliser.

Guide crawl & indexation

Voir aussi En-tête X-Robots-Tag Fichier robots.txt Désindexation

En-tête X-Robots-Tag

Même effet que la meta robots, mais servi dans l'en-tête HTTP au lieu du code de la page. Tout l'intérêt : il s'applique à ce qui n'a pas de head, PDF, images, flux XML, 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, souvent via une règle Apache ou Nginx. Exemple concret sur ce site, les portraits qu'on ne veut pas dans Google Images sortent grâce à un X-Robots-Tag noindex posé au niveau du serveur.

Guide crawl & indexation

Voir aussi Balise meta robots En-tête HTTP Désindexation

Désindexation

Sortir une page de l'index pour de bon passe par un noindex laissé en place le temps que Google repasse la lire. L'outil de suppression de la Search Console, lui, ne fait que masquer six mois environ, la page revient ensuite si le signal de fond n'a pas bougé. Et le réflexe de bloquer au robots.txt est contre-productif, sans crawl pas de lecture du noindex, la page reste. La combinaison qui marche vraiment : suppression pour l'effet immédiat, noindex pour le durable.

Guide crawl & indexation

Voir aussi Balise meta robots En-tête X-Robots-Tag Fichier robots.txt

Soft 404

Une page qui répond 200 OK alors qu'elle ne montre aucun contenu réel : fiche produit épuisée, résultat de recherche vide, « aucun article trouvé ». Google déteste ça parce qu'il gaspille du crawl sur du vide et finit par requalifier l'URL en soft 404 dans la Search Console. La bonne réponse dépend du cas, un vrai 404 ou 410 si la page n'a plus lieu d'être, un 301 vers un équivalent pertinent s'il existe. Servir du vide en 200, jamais.

Guide crawl & indexation

Voir aussi Code HTTP 503 Gonflement de l'index (index bloat) Redirections 301 / 302

Code HTTP 503

Le code à renvoyer quand le site part en maintenance : il prévient Googlebot que l'indisponibilité est passagère, surtout accompagné d'un en-tête Retry-After qui donne une durée. Bien géré, il gèle temporairement le crawl sans abîmer l'indexation. Le drame classique, c'est la maintenance servie en 200 avec une page « on revient vite », ou pire en 404, Google prend ça pour argent comptant et commence à désindexer. Un plugin de maintenance mal configuré a déjà fait plonger plus d'un site.

Guide crawl & indexation

Voir aussi Soft 404 En-tête HTTP Redirections 301 / 302

Gonflement de l'index (index bloat)

Google a avalé des milliers d'URL sans valeur, facettes, filtres, résultats de recherche interne, pages de tag quasi vides, qui diluent la qualité perçue du site et gaspillent le budget de crawl. Symptôme typique, un rapport Couverture qui affiche dix fois plus de pages indexées que ton nombre réel de contenus. On dégonfle en combinant noindex sur les gabarits parasites, canonical là où c'est du duplicate, et robots.txt pour ce qui n'a même pas à être crawlé. Un tri chirurgical, pas un bouton magique.

Sitemap Killer

Voir aussi Budget de crawl Duplicate content Sitemap XML

Sitemap XML

La liste des URL qu'on souhaite voir explorées, avec des indices comme le lastmod. Utile pour la découverte, surtout sur un gros site ou des pages mal maillées, mais il ne force jamais l'indexation, il la facilite. Règle d'hygiène qu'on voit rarement respectée : n'y mettre que des URL canoniques, en 200 et indexables. Y laisser traîner des redirections, des 404 ou des pages en noindex, c'est envoyer des signaux contradictoires et user la confiance que Google accorde au fichier.

Sitemap Killer

Voir aussi Demande de crawl (crawl demand) URL orpheline URL canonique (rel=canonical)

Duplicate content

Le même contenu joignable par plusieurs portes : HTTP et HTTPS, avec et sans www, avec ou sans paramètres de tracking, préprod oubliée en ligne, pagination. Google retient une version, la canonique, et répartit mal les signaux entre les clones, ce qui affaiblit tout le monde. Il n'y a pas de « pénalité duplicate » à proprement parler, juste de la dilution et du budget de crawl gâché. On assainit avec du canonical, des redirections propres, ou un vrai contrôle de ce qui a le droit d'être indexé.

Guide crawl & indexation

Voir aussi URL canonique (rel=canonical) Paramètres d'URL & tracking Hreflang

URL canonique (rel=canonical)

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, canonique vers une page en noindex, vers un 404, chaînes qui se contredisent. Bien posée, elle regroupe les signaux sur une seule adresse. Le piège fréquent, c'est la canonique auto-référente générée en masse par un CMS qui pointe vers la mauvaise URL.

Guide crawl & indexation

Voir aussi Duplicate content Paramètres d'URL & tracking Crawl vs indexation

Redirections 301 / 302

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 et des changements d'URL définitifs. Le 302 se dit temporaire, donc Google continue de considérer l'URL d'origine comme la bonne et n'y transfère pas les signaux. Se tromper de code sur une refonte reste une des causes les plus banales de chute de trafic. Et méfiance avec les chaînes de redirections, chaque saut dilue un peu et coûte du crawl.

Migrations SEO

Voir aussi Soft 404 Duplicate content Code HTTP 503

Paramètres d'URL & tracking

Les ?utm_source, ?fbclid, ?sort=prix et compagnie. Chaque paramètre crée techniquement une URL distincte, donc autant de portes vers le même contenu, du duplicate à la pelle et du budget de crawl pulvérisé sur les gros catalogues. Google en gère une partie tout seul, mais mieux vaut ne pas s'en remettre à lui : canonical vers l'URL propre, cohérence du maillage (ne jamais lier en interne avec des paramètres de tracking) et, pour le crawl, un robots.txt qui coupe les combinaisons inutiles. L'ancien outil de gestion des paramètres, lui, a disparu.

Catégorisation d'URL

Voir aussi Duplicate content URL canonique (rel=canonical) Budget de crawl

Pagination

Les séquences page 2, page 3 d'un listing ou d'un blog. Google a abandonné le support de rel=prev/next en 2019, donc chaque page de la série est traitée comme une URL autonome. L'erreur à éviter, c'est de canonicaliser toutes les pages vers la première : Google perd alors l'accès aux liens profonds des pages suivantes. La bonne approche reste simple, des pages paginées indexables, autonomes, bien maillées entre elles, et une page 1 qui n'essaie pas de tout absorber.

Guide crawl & indexation

Voir aussi URL canonique (rel=canonical) Maillage interne / cocon sémantique URL orpheline

Hreflang

L'annotation qui dit à Google quelle version linguistique ou régionale servir à qui, fr-FR, fr-BE, en-US. Ce n'est ni une redirection ni un signal de ranking, juste un aiguillage entre versions équivalentes, qui évite au passage que Google prenne tes traductions pour du duplicate. C'est aussi une des choses les plus casse-figure du SEO technique : les annotations doivent être réciproques (si A pointe vers B, B doit pointer vers A), inclure une balise x-default, et rester cohérentes sur des milliers d'URL. Une erreur et tout le cluster est ignoré.

SEO international

Voir aussi Duplicate content URL canonique (rel=canonical)

En-tête HTTP

Tout ce que le serveur annonce avant même d'envoyer le contenu : le code de 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 simple curl -I les révèle, et une bonne partie des bugs SEO se règlent à ce niveau, pas dans le HTML : un mauvais Cache-Control qui fige une variante, un Vary absent, un 200 là où il faudrait un 404. Apprendre à les lire fait gagner des heures.

SEO technique

Voir aussi En-tête X-Robots-Tag Varnish (reverse-proxy cache) Code HTTP 503

Analyse de logs SEO

Croiser les lignes du log serveur pour reconstituer le comportement réel des robots, plutôt que de le deviner. C'est là qu'on voit combien de fois Googlebot passe, sur quelles URL il concentre son budget, quels codes il rencontre, et quelles pages stratégiques il n'a jamais visitées. Aucun crawler tiers ni la Search Console ne donnent cette vérité terrain. Sur un gros site, une analyse de logs révèle presque toujours des surprises, du budget englouti dans des paramètres, des sections importantes ignorées, des 404 en boucle. L'outil le plus sous-utilisé du SEO technique.

SEO technique

Voir aussi Log serveur (access log) Budget de crawl User-agent (Googlebot & crawlers IA)

Log serveur (access log)

Le fichier où le serveur consigne chaque requête reçue, ligne par ligne : IP, date, URL, code HTTP, user-agent. C'est la matière première de l'analyse de logs et la seule source qui ne ment pas sur ce que fait Googlebot. Un access log Apache ou Nginx grossit vite, d'où l'intérêt de le traiter en flux ou de l'isoler par bot. Réflexe de terrain : filtrer sur le user-agent Googlebot après avoir vérifié les IP, pour ne pas polluer l'analyse avec des faux Googlebot.

SEO technique

Voir aussi Analyse de logs SEO User-agent (Googlebot & crawlers IA) Budget de crawl

Varnish (reverse-proxy cache)

Un cache HTTP posé devant le serveur applicatif, qui sert les pages déjà calculées à toute vitesse. Excellent pour le TTFB et donc pour le budget de crawl, puisque Googlebot obtient ses réponses sans solliciter PHP à chaque fois. Le revers, c'est qu'un Varnish mal réglé peut servir la même variante en cache à tout le monde et masquer des comportements qu'on croyait sous contrôle : un cookie ignoré, un Vary manquant, une redirection figée pour des heures. Quand une modif « ne se voit pas » en prod, regarde le cache avant de douter du code.

Web performance

Voir aussi TTFB (Time To First Byte) En-tête HTTP Core Web Vitals

.htaccess / mod_rewrite

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, puisqu'Apache le relit à chaque requête. Les classiques qui font mal : des règles qui se marchent dessus, des redirections en cascade, un ordre de priorité mal compris, un RewriteRule trop gourmand. Un .htaccess qui a grossi par sédimentation sur dix ans est souvent une dette technique SEO qui s'ignore, avec des redirections mortes que plus personne n'ose toucher.

Htaccess Cleaner

Voir aussi Redirections 301 / 302 En-tête HTTP

TTFB (Time To First Byte)

Le délai entre la requête et le premier octet renvoyé par le serveur. Il mesure surtout la réactivité côté serveur, traitement, base de données, cache, avant même que le navigateur commence à afficher quoi que ce soit. Un TTFB élevé plombe mécaniquement le LCP et, à grande échelle, peut réduire la vitesse de crawl que Google t'accorde. C'est le premier levier à travailler avant de micro-optimiser le front : cache serveur, requêtes SQL, hébergement. Un bon reverse-proxy fait souvent des miracles ici.

Web performance · CrUX History Explorer

Voir aussi Varnish (reverse-proxy cache) Core Web Vitals Budget de crawl

Core Web Vitals

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é aux interactions (elle a détrôné le FID en mars 2024). Elles se jugent sur données réelles d'utilisateurs, le rapport CrUX, pas en labo, ce qui explique l'écart fréquent avec un score Lighthouse flatteur. Signal de ranking réel mais modeste, à ne pas fétichiser : un bon contenu lent battra toujours un mauvais contenu rapide. Le vrai enjeu reste l'utilisateur.

CrUX History Explorer · Web performance

Voir aussi TTFB (Time To First Byte) Varnish (reverse-proxy cache)

Maillage interne / cocon sémantique

L'ensemble des liens qui relient les pages d'un site entre elles. Il fait trois choses à la fois : il fait circuler le PageRank, il dit à Google quelles pages comptent (par le nombre et la position des liens reçus), et il structure la sémantique en cocons autour des pages piliers. Un maillage travaillé pousse crawl et classement vers les pages qu'on veut mettre en avant, au lieu de les diluer sur des mentions légales et des archives. Le levier le plus rentable du SEO on-site, parce qu'il ne dépend que de toi.

SEO technique

Voir aussi PageRank interne URL orpheline Cannibalisation

PageRank interne

La popularité que tes pages se transmettent entre elles par les liens internes, indépendamment des backlinks. Chaque page reçoit un capital et le répartit vers celles qu'elle pointe, donc plus une page importante te lie, plus elle te transmet de jus. En pratique, ça veut dire rapprocher les pages stratégiques de la home en nombre de clics, éviter de gaspiller des liens vers des pages sans enjeu, et sortir les URL importantes de l'orphelinat. Le maillage n'est pas qu'une affaire de navigation, c'est de la distribution de puissance.

SEO technique

Voir aussi Maillage interne / cocon sémantique URL orpheline

Entité

Un objet identifié sans ambiguïté, une personne, une marque, un lieu, un concept, 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é, parce qu'un moteur qui « sait » que tu parles d'Aymeric Bouillat le consultant, et pas d'un homonyme, sert de bien meilleurs résultats. On consolide une entité avec des données structurées, des mentions cohérentes et des liens sameAs vers les profils de référence. C'est aussi la base du SEO à l'ère des IA.

KG Entity Audit

Voir aussi Knowledge Graph Données structurées (JSON-LD / Schema.org) GEO (SEO génératif)

Knowledge Graph

La base de connaissances de Google : un immense réseau d'entités et de relations entre elles, qui a fondé quoi, qui travaille où, quel lieu appartient à quel pays. C'est ce qui alimente les panneaux de connaissance à droite des résultats et, de plus en plus, la compréhension de tes contenus. Y figurer, ou au moins être compris comme une entité claire, renforce ta crédibilité aux yeux du moteur. On y travaille via des sources faisant autorité, du balisage cohérent et des signaux d'identité qui convergent. Difficile à forcer, précieux à obtenir.

KG Entity Audit

Voir aussi Entité Données structurées (JSON-LD / Schema.org) E-E-A-T

Données structurées (JSON-LD / Schema.org)

Le balisage qui décrit explicitement le contenu d'une page dans un vocabulaire que Google comprend, Schema.org, au format recommandé JSON-LD glissé dans un script. Il dit noir sur blanc « ceci est un produit, un article, une FAQ, une personne », de quoi débloquer des résultats enrichis et nourrir la compréhension des moteurs comme des IA. Deux règles d'or : baliser ce qui est réellement visible sur la page, sous peine de sanction, et coller aux types éligibles aux rich results plutôt que de tout baliser pour le plaisir.

Analyseur Schema.org · Veille Schema.org

Voir aussi Résultats enrichis (rich results) Entité Knowledge Graph

E-E-A-T

Experience, Expertise, Authoritativeness, Trust, la grille de lecture que Google donne à ses évaluateurs qualité pour juger la fiabilité d'un contenu et de son auteur. Ce n'est pas un score technique qu'on optimise directement, mais un faisceau de signaux, auteur identifié et compétent, sources, réputation, cohérence de l'entité. Il pèse d'autant plus sur les sujets sensibles, santé, argent, et désormais sur ce que les IA choisissent de citer. En clair : montre qui écrit, pourquoi il est légitime, et fais-le vérifier ailleurs.

SEO technique

Voir aussi Entité Knowledge Graph GEO (SEO génératif)

SERP (page de résultats)

Search Engine Results Page, la page de résultats. Elle n'a plus rien de la liste de dix liens bleus d'il y a quinze ans : featured snippets, People Also Ask, images, vidéos, pack local et maintenant AI Overviews se disputent l'espace et repoussent le premier lien organique vers le bas. Conséquence pratique, la première position ne vaut plus ce qu'elle valait, et le vrai combat se joue sur les blocs enrichis. Analyser la SERP réelle d'un mot-clé, avant de le cibler, est devenu un préalable, pas un luxe.

Suggest Detector

Voir aussi Featured snippet (position zéro) Résultats enrichis (rich results) AI Overviews

Featured snippet (position zéro)

L'encadré de réponse que Google affiche tout en haut, au-dessus des liens classiques, en piochant un extrait directement dans une page. On l'attrape en répondant de façon nette et cadrée à une question précise, juste après l'avoir posée : une définition courte, une liste, un tableau. Un balisage propre et une structure de titres claire aident, mais c'est surtout la formulation qui décroche la place. À double tranchant : la position zéro apporte de la visibilité, mais parfois moins de clics puisque la réponse est déjà donnée.

Suggest Detector

Voir aussi SERP (page de résultats) Résultats enrichis (rich results) AI Overviews

Résultats enrichis (rich results)

Étoiles d'avis, prix, FAQ dépliables, fil d'Ariane, image de recette, générés par Google à partir de tes données structurées. Ils ne changent pas ton classement mais gonflent ta visibilité et ton taux de clic en occupant plus de place et en rassurant l'internaute. Encore faut-il être éligible : le bon type de balisage, conforme aux règles de Google, et un contenu qui correspond vraiment. Le Test des résultats enrichis dit ce qui est éligible, ça ne garantit pas l'affichage, Google reste seul juge.

Analyseur Schema.org

Voir aussi Données structurées (JSON-LD / Schema.org) Featured snippet (position zéro) SERP (page de résultats)

AI Overviews

Les réponses générées par IA que Google affiche en haut de certaines requêtes, en synthétisant plusieurs sources. Elles poussent encore les liens organiques vers le bas et peuvent capter le clic, puisque l'utilisateur a déjà sa réponse sous les yeux. Pour une marque, l'enjeu bascule : ce n'est plus seulement être classé, c'est être cité dans la synthèse. Et ça favorise les mêmes ingrédients que le SEO sérieux, contenu factuel, structuré, faisant autorité, entité claire. Le point de rencontre entre le SEO classique et le GEO.

Veille user agents IA

Voir aussi GEO (SEO génératif) Featured snippet (position zéro) SERP (page de résultats)

GEO (SEO génératif)

Generative Engine Optimization : travailler pour être cité par les moteurs génératifs et les AI Overviews, ChatGPT, Gemini, Perplexity. Le raisonnement change d'échelle, on ne vise plus une position mais une mention dans une réponse synthétisée. Les leviers, eux, restent cohérents avec le bon vieux SEO : du contenu factuel et structuré qui fait autorité, une entité limpide, des données structurées, et un choix assumé de qui, parmi les crawlers d'IA, a le droit d'accéder au site. Nouveau nom, vieilles vertus, plus quelques réglages propres aux bots IA.

Veille user agents IA · Générateur robots.txt IA

Voir aussi AI Overviews Entité E-E-A-T llms.txt

llms.txt

Un fichier proposé à la racine du site, sur le modèle du robots.txt, censé offrir aux modèles de langage une version claire et hiérarchisée de tes contenus importants. L'idée : leur mâcher le travail plutôt que de les laisser deviner dans un HTML bruité. C'est un standard émergent, pas encore officiellement suivi par les grands acteurs, donc à voir comme un pari peu coûteux plutôt qu'une garantie. À ne pas confondre avec le blocage des crawlers IA, qui se joue, lui, dans le robots.txt et les en-têtes.

Générateur robots.txt IA

Voir aussi GEO (SEO génératif) Fichier robots.txt User-agent (Googlebot & crawlers IA)

Cannibalisation

Quand plusieurs de tes pages visent le même mot-clé et se disputent la place, au lieu d'unir leurs forces. Google hésite, alterne les URL classées, et aucune ne performe vraiment. Le symptôme se lit dans la Search Console, une même requête qui fait remonter deux ou trois URL différentes au fil du temps. On règle ça en tranchant : fusionner les contenus, canonicaliser ou rediriger le doublon le plus faible, et clarifier le maillage pour désigner la page de référence. Souvent, c'est un souci d'architecture éditoriale plus que de SEO technique.

Suggest Detector

Voir aussi Maillage interne / cocon sémantique URL canonique (rel=canonical) Duplicate content