L'indexation, goulot d'étranglement sous-estimé : l'Indexing Hub du panneau Semalt
Une page absente de l'index ne se positionne pas mal : elle ne se positionne pas du tout. Cet article explique pourquoi le budget de crawl, la découverte et l'indexation sont trois étapes distinctes, et comment le module Indexing Hub du panneau Semalt rend cet angle mort mesurable.
La plupart des projets SEO menés à Bruxelles ou en Wallonie commencent par le contenu, les mots-clés et les liens. Le réflexe se comprend : c'est là que le travail se voit. On saute pourtant l'étape préalable, savoir si le moteur connaît vos pages et s'il a accepté de les conserver. Tant que cette question reste ouverte, toute optimisation porte sur un objet qui, pour la recherche, n'existe pas.
Le problème ne touche pas que les grands portails. Une boutique de huit mille fiches, une agence immobilière avec mille annonces, un éditeur assis sur vingt ans d'archives : partout les volumes d'adresses croissent plus vite qu'on ne peut les recenser. Le retard n'apparaît qu'au moment où le trafic organique stagne malgré une publication régulière.
Budget de crawl, découverte et indexation ne sont pas la même chose
Le raccourci le plus courant traite l'indexation comme un événement unique. Il s'agit de trois phases successives, dotées chacune de sa logique : une difficulté née dans la première ne se répare pas dans la troisième. Qui garde cette distinction en tête pose la bonne question : à quelle étape cela bloque-t-il ?
La découverte d'une adresse, son téléchargement par un robot et la décision de la retenir sont des opérations séparées, parfois espacées de semaines. Un panorama général figure sur la page décrivant le nouveau panneau Semalt ; seul le chapitre consacré à l'indexation nous occupe ici.
| Étape | Ce qui s'y passe | Blocage typique | Contre-mesure adaptée |
|---|---|---|---|
| Découverte | Le moteur apprend qu'une URL existe : liens internes, sitemap, liens externes ou notification. | Page orpheline, absence du sitemap, profondeur de clic excessive. | Maillage interne, sitemap propre, soumission active. |
| Exploration | Le robot télécharge réellement l'adresse. Le volume de téléchargements sur une période s'appelle le budget de crawl. | Serveur lent, erreurs 5xx en charge, variantes paramétrées sans valeur. | Infrastructure, codes de statut, nettoyage des variantes d'URL. |
| Indexation | La page téléchargée est évaluée puis retenue — ou justement pas. La décision porte sur le fond. | Contenu maigre, duplication, canonisation contradictoire. | Substance éditoriale, adresses canoniques nettes, signaux cohérents. |
Le budget de crawl n'est pas une ligne sur une facture : il résulte de la performance du serveur, de la qualité des réponses passées et de l'intérêt estimé du domaine. Un serveur qui renvoie des erreurs aux heures de pointe, ou met trois secondes à livrer le premier octet, reçoit moins de téléchargements : le moteur se freine pour ne pas l'accabler.
Six raisons pour lesquelles des pages restent dehors
Au fil des audits, les causes se répètent avec une régularité remarquable. Les six schémas ci-dessous couvrent l'essentiel, classés par étape.
Pages orphelines
L'adresse répond, mais aucune page du site n'y renvoie : il n'existe aucun chemin d'accès.
- Refontes de catégories, suppressions de filtres
- Pages de campagne retirées de la navigation
- En ligne, mais introuvable
Maillage interne faible
Formellement liée, pratiquement inaccessible. La profondeur de clic se lit comme un signal d'importance.
- Un produit à la quatorzième page de pagination
- Douze clics depuis l'accueil
- Invisible pour le visiteur comme pour le robot
Contenu dupliqué
Les boutiques fabriquent des doublons toutes seules. Le moteur choisit une variante, pas forcément la vôtre.
- Un produit accessible par trois chemins
- Paramètres de tri, de filtre, de session
- Versions imprimables, barre oblique présente ou non
Balises canoniques fautives
Bon outil contre la duplication, mais fréquemment retourné contre soi-même.
- Toutes les pages de pagination pointent vers la page un
- La cible redirige, porte un noindex ou n'existe plus
- La canonique est une recommandation, pas un ordre
robots.txt contre noindex
Deux mécanismes constamment confondus, aux conséquences coûteuses en mise en production.
- Une URL interdite n'est pas lue, son noindex non plus
- Sortir de l'index exige accessibilité plus noindex
- Un noindex de préproduction oublié coûte des semaines
Livraison lente
Le temps de réponse limite le nombre de téléchargements par heure. Décisif sur les grands sites.
- Deux cents millisecondes contre deux secondes
- Sur trente mille URL : des jours ou des mois
- Les erreurs serveur déteignent sur tout le domaine
La Belgique ajoute un facteur aggravant : le multilinguisme. Une boutique qui publie ses fiches en français et en néerlandais double son inventaire d'adresses ; une version anglaise pour la clientèle internationale de Bruxelles le triple. Le budget de crawl, lui, ne triple pas. Qui gère de gros volumes sans maîtriser son temps de réponse commence par là : les fondations techniques ouvrent la marche.
L'Indexing Hub et ses limites explicites
L'Indexing Hub réunit la soumission d'adresses, le traitement des sitemaps et l'observation qui s'ensuit. Ses limites sont déterminantes pour la planification : elles fixent ce qui est réalisable et dans quel délai, et valent mieux que n'importe quelle promesse.
Le plus intéressant est le plus petit de ces nombres. Mille URL par jour semble beaucoup pour un site vitrine de soixante pages ; sur un catalogue de dizaines de milliers d'adresses, c'est un budget qui se planifie comme un budget publicitaire. L'apport est là : la limite force à décider quelles pages comptent, décision que le quotidien permet d'esquiver.
| Paramètre | Valeur | Portée pratique |
|---|---|---|
| Quota quotidien du suivi d'URL | 1 000 URL par jour et par compte | La vraie limite de débit. Mille adresses choisies valent mieux que mille au hasard. |
| Soumission en masse | jusqu'à 10 000 URL par lot | La liste part en une opération. Le traitement reste soumis au quota du jour. |
| Source du sitemap | envoi de fichier ou adresse | On contrôle un sitemap pas encore public, par exemple avant une mise en production. |
| Traitement récursif | jusqu'à 3 niveaux de profondeur | Un index renvoyant vers un autre index est déplié. Au-delà, aplatissez la structure. |
| Sitemaps par tâche | jusqu'à 1 000 | Couvre en une passe les ensembles segmentés par catégorie ou langue. |
| Tâches simultanées | 2 au maximum | Deux domaines ou deux jeux de sitemaps en parallèle ; le reste patiente. |
| File d'attente | 20 tâches au maximum | Suffisant pour une agence de quelques clients, mais pas illimité. |
| Journal par URL | horodatage, statut, détail d'erreur | Prouve si une adresse a été téléchargée, et comment. |
Deux portes d'entrée : le lot et le sitemap
Le hub propose deux points d'entrée : l'un part d'une liste d'adresses précises, l'autre d'une structure de sitemaps existante. Tous deux débouchent sur le même suivi et partagent le même quota.
Soumission d'URL en masse
Pour les situations où beaucoup d'adresses changent d'un coup.
- Une opération au lieu de dix. La liste complète part en une fois ; le découpage manuel disparaît.
- Le frein reste le quota du jour. Un lot de dix mille adresses se traite à raison de mille par jour.
- L'ordre est une décision. Le budget étant serré, le classement de la liste décide du résultat de la première semaine.
- Utile pour les exceptions, pas pour la routine. Refonte, migration, catégorie saisonnière, gamme nouvelle ou blocage levé après coup.
Traitement des sitemaps
Pour les grands ensembles déjà organisés en index de sitemaps.
- Fichier envoyé ou adresse indiquée. Fichier téléversé ou URL saisie, ce qui permet de vérifier une structure avant sa mise en ligne.
- Récursif sur trois niveaux. Un index qui renvoie vers un autre index est déplié ; au-delà, aplatissez l'arborescence.
- Jusqu'à 1 000 sitemaps par tâche. Une passe absorbe les jeux segmentés par langue ou par type de contenu.
- Deux tâches en parallèle, vingt en attente. Cela suffit pour plusieurs clients, mais impose un ordre conscient : la mise en production de vendredi passe avant la maintenance de routine.
Dans les deux cas, la transmission passe par l'interface IndexNow, vers GoogleBot et BingBot. Pour voir comment le module d'indexation de Semalt s'articule avec le reste du panneau, la présentation de la plateforme le détaille.
Le push plutôt que l'attente, et ce que dit ensuite le journal
IndexNow comme notification active
L'indexation fonctionne classiquement en mode pull : le moteur décide seul quand il repasse, et sur un domaine peu actif les pages profondes attendent des semaines. IndexNow inverse le sens : le site annonce lui-même qu'une adresse a changé.
Le gain porte sur le délai en cas de modification. Description corrigée, prix actualisé, catégorie ouverte : au lieu d'espérer que la prochaine visite de routine le remarquera, on émet un signal. Pour les secteurs saisonniers, c'est la différence entre une visibilité à temps et une visibilité après la saison.
Le push raccourcit donc le délai jusqu'à la découverte et remplace une question sans réponse — le moteur connaît-il cette page ? — par une question soluble : pourquoi l'écarte-t-il ?
Le journal des visites de robots comme instrument de diagnostic
La partie la plus précieuse du hub n'est pas la soumission mais le journal tenu pour chaque URL : moment de la visite du robot, statut obtenu, détail de l'erreur. S'y ajoutent des compteurs en direct des adresses soumises, trouvées et en échec, si bien qu'une opération en cours ne se suit pas à l'aveugle.
L'utilité naît de leur combinaison : l'horodatage dit si le téléchargement a eu lieu, le statut sépare le technique de l'éditorial, le détail de l'erreur indique la réparation.
- Aucune visite malgré la soumission. Annoncée, pas téléchargée. Vérifiez le robots.txt, la charge du serveur, un éventuel ralentissement du domaine.
- Visite avec erreur serveur. Le robot a rencontré une 5xx. Sujet d'infrastructure qui pèse sur tout le domaine.
- Visite avec statut 404 ou 410. Sitemap périmé ou lien interne vers un contenu supprimé. À nettoyer, pas à resoumettre.
- Visite aboutissant à une redirection. Une étape intermédiaire a été transmise. Transmettez toujours l'adresse cible.
- Visite réussie sans acceptation. La partie technique est faite. La cause tient au contenu, à la canonisation ou au maillage.
40 000 URL à mille par jour
Le calcul qui suit est illustratif : il rend les ordres de grandeur tangibles, ce n'est pas une mesure relevée sur un projet réel.
Une boutique déclare 40 000 adresses dans son sitemap, versions française et néerlandaise confondues. Avec un quota de 1 000 URL par jour, cela donne 40 jours, à condition que la limite soit consommée intégralement et sans reprise. Les passes correctives portent le délai réaliste à six ou huit semaines. Le lot de dix mille adresses ne raccourcit rien : il économise le découpage manuel.
Six semaines, c'est trop long pour une campagne saisonnière. La conséquence n'est pas de renoncer à l'outil, mais de trier. Une répartition plausible ressemble à ceci.
- Environ 12 000 variantes et pages à paramètres. Couleurs, tailles, filtres, tris : cela relève de la canonisation. Budget consommé : nul.
- Environ 6 000 références définitivement indisponibles. Elles appellent une redirection ou une suppression.
- Environ 400 pages de catégorie et de conseil. Elles portent la part du lion du chiffre d'affaires : une demi-journée de budget.
- Environ 5 000 fiches produits recherchées et en stock. Elles suivent en cinq jours et couvrent l'activité courante.
- Environ 16 000 pages de longue traîne. Elles défilent ensuite en arrière-plan, sans échéance.
Les quarante jours de soumission aveugle deviennent moins de six jours pour tout ce qui décide commercialement. La différence tient à l'ordre, pas à la technique. En Belgique s'ajoute un critère : le volume se répartit entre le français, le néerlandais et parfois l'anglais, si bien qu'une analyse par pays masque ce qu'il faudrait voir. Tranchez langue par langue ; les tableaux de visibilité de la même plateforme sont dans le même compte, sans export séparé.
Hygiène des sitemaps et procédure exploitable
Un sitemap n'est pas l'inventaire des adresses existantes, c'est une recommandation : chaque entrée affirme que la page mérite d'être indexée. Si trente pour cent du fichier sont des redirections, des pages d'erreur et des adresses en noindex, la confiance dans l'ensemble baisse — et avec elle l'utilité du fichier pour les pages qui y figurent à bon droit.
Pages cibles indexables
Uniquement des adresses canoniques répondant en 200 dans leur écriture définitive.
- Des lastmod honnêtes, pas une date réécrite chaque nuit
- Une segmentation par catégorie, produit et langue
- Un index de sitemaps en toiture, adapté au récursif
Tout ce qui n'est pas indexable
Chaque adresse qui sera de toute façon écartée affaiblit le propos du fichier.
- Noindex, adresses interdites dans robots.txt, redirections
- Variantes filtrées, résultats de recherche interne
- Panier, espace client, hôtes de test, pages d'erreur
De là découle un ordre de marche qui commence par le nettoyage. On assainit d'abord le sitemap, puis on le fait traiter, par envoi de fichier ou par adresse selon qu'il est déjà public. Le résultat livre un premier état des lieux : adresses trouvées, adresses en échec, codes de statut qui s'accumulent.
Cette liste d'erreurs se traite avant qu'un jour de quota ne soit dépensé. La transmission priorisée ne commence qu'ensuite, pages décisives en tête. Au bout d'une semaine, le journal fournit assez de points de mesure : visitée et retenue, visitée et écartée, jamais téléchargée. Le troisième groupe désigne des causes techniques, le deuxième des causes éditoriales.
Questions fréquentes
En combien de temps une URL soumise est-elle indexée ?
Aucun délai ne peut être promis ; tout chiffre avancé reste une estimation. La soumission raccourcit le temps jusqu'à la découverte et au premier téléchargement. Que l'entrée dans l'index suive, et quand, dépend de l'appréciation du moteur. Le journal montre au moins si le téléchargement a eu lieu : c'est la moitié de la réponse.
Mille URL par jour suffisent-elles à une boutique de taille moyenne ?
Pour l'exploitation courante, presque toujours : les nouveautés et les pages modifiées restent sous ce seuil, même sur une boutique active. Le quota ne devient serré qu'au premier référencement de grands ensembles, lors d'une refonte ou d'une migration. C'est là que le tri préalable paie, la part réellement pertinente d'un catalogue se réduisant à une fraction du volume.
Comment gérer un site bilingue français et néerlandais ?
Chaque version linguistique est une URL distincte et consomme sa part du quota. Segmentez les sitemaps par langue sous un index commun, ce que le traitement récursif absorbe sans difficulté, puis décidez quelle version passe en premier. Les fonctions décrites reposent sur les données de Google, sans traitement propre au néerlandais : la distinction vient de vos sitemaps et de vos priorités, pas de l'outil.
Que se passe-t-il si je soumets plusieurs fois la même URL ?
Vous consommez du quota sans rien gagner : resoumettre une page inchangée n'accélère aucune décision. La retransmission n'a de sens que si le contenu, la canonisation ou un blocage technique a changé, par exemple après la suppression d'un noindex non désiré.
Combien de tâches de sitemap peuvent tourner en parallèle ?
Deux en même temps, vingt autres en file d'attente. Pour une agence suivant quelques clients, cela suffit, mais impose un ordonnancement conscient : placez les cas critiques dans le temps, comme une mise en production, avant la maintenance de routine, sans quoi une grande passe bloquera celle qui presse.
Conclusion : la visibilité commence par la trouvabilité
Si l'indexation est un goulot d'étranglement sous-estimé, c'est qu'elle reste invisible quand elle réussit et ne ressemble pas à une panne quand elle échoue. Ni alerte ni bandeau rouge, seulement des pages sans impressions. Qui ne la mesure pas travaille ses textes et ses liens pendant que la cause se situe une étape plus tôt.
L'Indexing Hub n'y change rien par magie. Il réunit trois éléments : une limite de débit claire qui oblige à prioriser, une notification active qui raccourcit le délai jusqu'à la découverte, et un journal qui remplace les suppositions par des horodatages et des codes de statut. Les limites font partie du tableau : mille adresses par jour est un nombre fini, deux tâches simultanées aussi, et une soumission reste une soumission.
C'est cette sobriété qui rend le domaine planifiable : qui sait que 40 000 adresses demandent quarante jours à plein budget planifie autrement que celui qui appuie sur un bouton en espérant. Pour vérifier combien de vos pages sont réellement prises en compte, vous pouvez ouvrir le tableau de bord Semalt et commencer par une passe de sitemap ; ce premier état des lieux est souvent plus instructif qu'on ne l'imagine.
Besoin d'Aide Avec Votre SEO ?
Notre équipe d'experts est prête à vous aider à améliorer votre classement dans les moteurs de recherche et à développer votre présence en ligne.
Consultation Gratuite