Publier une page et la voir trouvée sont deux événements distincts, et sur un gros site c'est le second qui prend du retard. À Québec s'ajoute une complication : le même document existe souvent à deux adresses, à cause d'un seul accent.
La plainte est toujours formulée pareil. La page est en ligne, elle est liée, elle figure au plan de site, et trois semaines plus tard une recherche par site ne ramène rien. Personne ne l'a bloquée et le remède n'est pas une balise : la page a rejoint une file d'attente invisible, derrière d'autres qui avaient un meilleur titre à l'attention du robot.
Ce texte explique ce qu'est cette file, ce qui la consomme, et ce que l'Indexing Hub du panneau Semalt peut ou ne peut pas y changer. Il s'adresse à qui exploite une bibliothèque documentaire, des archives ou un catalogue saisonnier dans la Capitale-Nationale — et à qui évalue un fournisseur d'ici et veut savoir si la réponse reçue en est une vraie.
Une page qui existe n'est pas une page qui se trouve
Les moteurs ne détiennent pas la liste de toutes les pages du Web. Ils détiennent une liste d'adresses qu'ils ont une raison de visiter, et chaque visite coûte quelque chose. Votre site est l'un de millions à se disputer une attention finie, et la part qui vous revient dépend de facteurs qu'une décision de publication ne contrôle pas : la fréquence des changements qui comptent, la vitesse de votre serveur, la part de la dernière récolte qui méritait d'être gardée.
Cette part, c'est ce qu'on appelle le budget d'exploration. Il n'est ni publié, ni configurable, ni achetable, ce qui le fait passer pour une préoccupation théorique. Il cesse de l'être dès que le site dépasse quelques milliers d'adresses, ce qui arrive ici plus vite qu'on ne le croit.
Ce qui consomme réellement le budget
Le budget d'exploration est rarement consommé par les pages qui vous tiennent à cœur. Il l'est par celles que vous aviez oubliées adressables. Chaque combinaison de filtres est une adresse. Chaque ordre de tri est une adresse. Chaque paramètre de session, chaque version imprimable, chaque mois de calendrier remontant à 2011 est une adresse, et le robot qui les suit ne passe pas ce temps sur votre nouvelle page de service.
Le motif se répète d'un secteur à l'autre. Une firme de services financiers publie un document de police et le lie depuis une page de bibliothèque, une page de recherche, une page de catégorie et une page de téléchargements, chacune avec ses paramètres. Une université publie un résultat de recherche qui apparaît sous l'auteur, le département, l'année et le dépôt. Un exploitant touristique génère une page par date. Rien de tout cela n'est une faute en soi ; l'addition, elle, est un problème de budget.
- Les variantes par paramètre. Tri, filtres et paramètres de suivi multiplient un document en dizaines d'adresses qui renvoient à peu près la même chose.
- Les réponses lentes. Un serveur qui met deux secondes par page est moins exploré qu'un serveur à deux cents millisecondes : chaque récupération coûte plus cher.
- Les échecs silencieux. Une page qui renvoie un code 200 avec un corps vide apprend au robot que venir chez vous est souvent du temps perdu.
- Les archives sans fin. Une pagination sans plafond et des archives par date sans terme absorbent l'attention indéfiniment pour presque rien.
Le correctif est sans éclat et il fonctionne : réduisez le nombre d'adresses avant de chercher à augmenter l'attention. Chaque URL retirée de la surface explorable est de l'attention rendue aux pages qui rapportent.
L'URL accentuée et sa jumelle sans accent
Ici, la multiplication des adresses prend une forme régionale qui n'existe pas ailleurs. Les titres français portent des accents, et quand un système de gestion de contenu fabrique une adresse à partir d'un titre, il doit décider quoi en faire. Les systèmes décident différemment, et un même système décide autrement d'une version à l'autre. Sur un site qui a une histoire, le résultat est prévisible : deux adresses vivantes pour un document, parfois trois.
La première est la forme dépouillée, où le é devient e et où le chemin se lit proprement dans la barre du navigateur. La deuxième garde l'accent : le caractère est encodé en pourcentage chaque fois que l'adresse circule, dans un lien, dans une ligne de journal, dans un fichier sitemap. La troisième est l'héritée, produite par un ancien système qui encodait ce caractère autrement ; elle survit parce que quelqu'un l'a mise en signet.
| Variante | D'où elle vient | Ce qu'elle vous coûte |
|---|---|---|
| Adresse dépouillée | Translittération d'un CMS moderne | Le choix canonique le plus sûr |
| Adresse accentuée | Systèmes qui gardent le titre tel quel | Encodée en pourcentage, malcommode dans les journaux |
| Adresse héritée | Plateforme d'avant migration, autre encodage | Invisible aux rédacteurs, encore explorée, encore indexée |
| Les deux formes liées à l'interne | Vieux menus et liens écrits à la main | Scinde les signaux et double la demande d'exploration |
| Les deux formes au plan de site | Export automatique d'une base mixte | Dit explicitement au robot de venir deux fois |
L'ampleur du phénomène est facile à sous-estimer. Sur des archives de dix mille documents à titres français, une histoire mixte laisse quatre ou cinq mille adresses fantômes en circulation. Ce n'est pas une inefficacité de cinq pour cent : c'est la moitié de votre demande d'exploration dépensée à confirmer que deux URL portent le même texte.
Le plan de site fait un vrai travail, si on le laisse faire
On traite le plan de site comme une pièce justificative : on le génère, on le soumet une fois, on l'oublie. Bien lu, c'est le seul endroit où vous déclarez, en langage machine, quelles adresses vous tenez pour réelles. Sur un site atteint de dédoublement, c'est la chose la plus utile que vous puissiez publier.
Soumission de sitemaps et lecture récursive
Pour les sites dont l'inventaire d'adresses vit dans un fichier d'index plutôt que dans un tableur.
- Téléverser ou pointer une adresse. Soumettez le fichier directement, ou donnez au hub l'adresse d'un plan déjà publié.
- Lecture récursive sur trois niveaux. Un index d'index de sitemaps est suivi sur trois niveaux, ce qui couvre presque toutes les structures réelles.
- Jusqu'à 1 000 sitemaps par tâche. Un gros inventaire segmenté se traite en une tâche au lieu d'être servi à la main.
- Deux tâches à la fois, vingt en attente. La simultanéité est plafonnée à deux tâches actives, avec une file de vingt derrière.
Trois niveaux, c'est plus généreux qu'il n'y paraît, et cela colle à la façon dont les sites documentaires sont bâtis. Un index principal pointe un sitemap par section ; chaque index de section pointe un fichier par année ou par famille ; chacun liste les documents. Cette structure vaut d'être conçue exprès : elle transforme une liste opaque en diagnostic, puisque vous voyez dans quelle branche la découverte traîne.
L'index du site
Une entrée par grande section, pour localiser un problème avant d'ouvrir un journal.
- Services, archives, nouvelles, ressources
- Le garder stable d'une version à l'autre
L'index de section
Découpé par année, famille ou programme, à une taille qui reste lisible quand ça va mal.
- Segmenter avant la limite du fichier
- Nommer les fichiers pour que le découpage se voie
La liste des documents
Les adresses réelles, en forme canonique seulement, avec des dates de modification honnêtes.
- Une forme par document, jamais les deux jumelles
- Aucune redirection, aucune entrée morte
Ce qui le garde utile
Un plan de site qui liste des adresses redirigées ou en 404 déclare que vous ne connaissez pas votre propre site.
- Régénérer à la publication, pas au trimestre
- Retirer les pages échues délibérément
Mettre des adresses sous les yeux du robot
À côté de la voie du plan de site, le hub accepte les URL directement. Les plafonds sont fixes et méritent d'être retenus, parce qu'ils déterminent la durée de tout projet réel. Le suivi travaille avec un budget quotidien de 1 000 URL par compte, et la soumission par lot accepte jusqu'à 10 000 URL d'un coup : le lot est le contenant, le budget quotidien est le débit auquel il se vide.
Le suivi d'URL et la soumission par lot
Pour une liste arrêtée : des archives migrées, un nouveau catalogue, une saison qui entre en ligne d'un coup.
- 1 000 URL par jour. Le budget quotidien du compte, et le chiffre autour duquel tout calendrier se construit.
- 10 000 URL par lot. La taille maximale d'un téléversement, qui se vide ensuite au rythme quotidien.
- Livraison par IndexNow. Les soumissions partent par l'API IndexNow, qui couvre GoogleBot et BingBot.
- Journal par adresse. Chaque URL porte son relevé de visites de robots, avec horodatage, statut et détail d'erreur.
IndexNow mérite d'être compris pour ce qu'il est : un protocole de notification. Il annonce aux moteurs participants qu'une adresse a changé, ce qui supprime l'attente entre la publication et le moment où le robot l'apprend. Il ne dit pas que la page est bonne et n'oblige personne à agir. Ce que vous achetez, c'est la disparition d'un délai précis — souvent le plus long, sur un site qui publie souvent.
L'état d'un lot, et ce qu'il veut dire
Une soumission qu'on ne lit pas est une soumission qu'on n'a pas faite. Le hub tient des compteurs en direct pour les adresses soumises, trouvées et échouées, plus un journal par adresse qui note les visites de robots avec horodatage, statut et détail d'erreur. Ces trois compteurs répondent à trois questions, et les confondre est l'erreur de lecture la plus répandue du domaine.
Soumise veut dire que l'adresse est partie de chez vous. Trouvée veut dire qu'un robot est venu la chercher. Échouée veut dire que la récupération a été tentée sans résultat exploitable, et c'est le détail d'erreur du relevé qui porte la vraie cause : délai dépassé, erreur de serveur, chaîne de redirections imprévue, code de statut qui ne correspond pas à ce que montre le navigateur.
| Ce que le lot affiche | Ce que cela vous dit | Quoi faire ensuite |
|---|---|---|
| Beaucoup de soumises, peu de trouvées | La notification a passé, l'attention n'a pas suivi | Regarder la demande d'exploration du site, pas le lot |
| Trouvées, mais toujours absentes des résultats | Récupérées et jugées non conservables | Question de contenu et de dédoublement, pas de technique |
| Échecs groupés dans une section | Presque toujours une faute de serveur ou de routage | Ouvrir un relevé, lire l'erreur, corriger une fois |
| Échecs épars | Adresses passagères ou périmées | Relancer les échecs, pas le lot entier |
| Trouvée, puis une redirection au journal | Vous avez soumis une jumelle non canonique | Corriger la liste source avant de resoumettre |
Où ça fait mal dans la Capitale-Nationale
Les sites d'ici qui frappent le mur ne sont pas les plus gros. Ce sont ceux qui ont une bibliothèque documentaire accrochée à un petit site vitrine, où le nombre d'adresses a grossi pour des raisons que personne n'a suivies.
La bibliothèque documentaire
Libellés de police, sommaires de garanties, grilles tarifaires et formulaires, chacun en plusieurs versions et lié depuis plusieurs index.
- Retirer proprement les versions remplacées
- Une seule page d'index par document
Les archives de publications
Travaux de recherche et documents cliniques accessibles par auteur, département, année et dépôt : quatre adresses pour un article.
- Choisir une vue canonique
- Faire des autres de la navigation, pas des URL
La saison qui échoit
Programmation, horaires et forfaits refaits chaque année, l'ensemble de l'an dernier restant en ligne et consommant de l'attention.
- Décider d'avance ce qui échoit
- Rediriger vers la page permanente, pas l'accueil
Le portfolio de projets
Un chantier terminé produit une galerie, une fiche de réalisation et une entrée d'étiquette, répétées sur plusieurs centaines de projets.
- Plafonner les pages d'étiquettes
- Fondre les galeries dans la fiche
Passons à l'arithmétique, la partie qui raccourcit la discussion de planification. Prenez une bibliothèque documentaire de services financiers de 38 000 adresses après une migration de plateforme. Soumises telles quelles, à 1 000 URL par jour, cela fait 38 jours de budget quotidien — et comme 10 000 tiennent dans un lot, vous parlez de quatre lots et d'environ six semaines avant que la dernière adresse ait seulement été annoncée.
Retirez les jumelles accentuées et les versions remplacées. Si 40 pour cent de l'inventaire est du dédoublement — chiffre réaliste pour des archives françaises passées par une migration — l'ensemble réel tourne autour de 23 000 adresses, trois lots, 23 jours. Vous avez sauvé deux semaines et cessé de demander à un robot quinze mille pages qu'il allait écarter. Le ménage est la voie rapide, et la seule qui agit encore après le lot.
Questions fréquentes
Si je soumets une URL par le hub, sera-t-elle indexée ?
Non. La soumission fait connaître une adresse et invite à venir la chercher. L'entrée à l'index se décide ensuite, par le moteur et selon ses critères, et il arrive couramment qu'une page soit récupérée puis écartée. L'attente honnête est une découverte plus rapide, pas une inclusion garantie.
L'adresse canonique doit-elle garder ses accents ou les perdre ?
Les deux tiennent techniquement, et la forme dépouillée est la plus courante parce qu'elle survit au copier-coller et aux journaux sans encodage en pourcentage. Ce qui compte bien plus, c'est qu'une seule forme soit en ligne, que l'autre redirige de façon permanente, et que les liens internes et le plan de site emploient la même.
Jusqu'où peut aller la structure de mon plan de site ?
Le hub lit récursivement sur trois niveaux, et une tâche accepte jusqu'à 1 000 sitemaps. En pratique, trois niveaux — index du site, index de section, liste de documents — suffisent à des archives de presque n'importe quelle taille, avec l'avantage de montrer quelle branche traîne.
Puis-je lancer plusieurs tâches de sitemap à la fois ?
Deux s'exécutent en même temps et jusqu'à vingt autres attendent en file. C'est amplement suffisant, puisque la contrainte d'un gros projet est le budget quotidien d'URL et non la simultanéité des tâches.
IndexNow couvre-t-il Google ?
Les soumissions du hub partent par l'API IndexNow, qui couvre GoogleBot et BingBot. Voyez-le comme un canal d'annonce : il supprime l'attente avant qu'un moteur apprenne qu'une chose a changé, sans rien promettre sur la suite.
Ce que le travail d'indexation vous achète vraiment
Bien menée, la découverte élimine une catégorie d'excuses. Vous cessez de vous demander si une page manque à cause d'une faute technique, parce que le journal dit quand un robot est venu et ce qu'il a obtenu. Vous cessez de resoumettre les mêmes archives chaque trimestre, parce que vous connaissez le plafond de mille adresses par jour et que vous planifiez avec. Et vous cessez de voir le plan de site comme de la paperasse, parce qu'il est devenu l'endroit où vous déclarez laquelle de vos jumelles est la vraie.
Ce que cela ne vous achète pas, c'est une raison d'être à l'index. Un robot qui récupère une page jugée quasi identique à ce qu'il détient déjà la refusera, poliment et durablement, et aucune resoumission n'y change rien. D'où la place du dédoublonnage en tête de tout plan qui mérite d'être suivi.
Le hub voisine avec les sections de campagne et d'analytique du même panneau : une page découverte qui commence à récolter des impressions apparaît dans les vues de la Search Console sans export séparé, et l'état d'indexation de chaque adresse reste visible à côté de son rendement. Pour les sites dont la formulation passe par une révision avant publication, le palier FullSEO à 500 USD par mois et par domaine — environ 685 CAD, conversion approximative — ajoute un mode de validation humaine par-dessus la même automatisation ; nos pages de services expliquent comment cela s'articule avec une migration d'archives.
Pour voir la file d'attente sur votre propre inventaire plutôt qu'en théorie, ouvrez le panneau et soumettez un plan de site. Pointez-le vers votre plus grosse section, lisez les compteurs de trouvées et d'échouées après 48 heures, et vous en saurez plus sur votre situation d'exploration que ne vous le dira n'importe quel document d'audit. La lecture se poursuit sur notre blogue, et l'aperçu complet des fonctions énumère les vues restantes du hub.