Technique
5 min de lecture
2 novembre 2026

Sitemap et indexation après migration : contrôler les bonnes URL

Une méthode concrète pour contrôler un sitemap, lire les verdicts GSC et suivre chaque nouvel article sans confondre découverte, demande et indexation.

À retenir

  • Un sitemap accessible ne prouve ni l’exploration ni l’indexation.
  • Vérifiez la page finale, sa canonique et sa navigation avant une demande.
  • Conservez un verdict daté ; une demande confirmée reste distincte d’une indexation.
Quatre étapes distinctes : publier, faire découvrir, contrôler, puis suivre le verdict Google

Sitemap, exploration, indexation : quatre états à suivre séparément

Après une migration, voir un sitemap accessible ne suffit pas à conclure que les articles sont présents dans Google. Le sitemap décrit les adresses que le site veut faire découvrir. L’exploration correspond à une visite du robot. L’indexation signifie que Google a retenu une page dans son index. Une demande d’indexation est seulement une démarche destinée à attirer son attention sur une URL. Tenir ces quatre états dans des colonnes distinctes permet d’éviter un tableau de bord rassurant mais inexact.

Pour commencer, choisissez une adresse précise et gardez-la pendant tout le contrôle. Un mélange entre http et https, www et sans www, ou entre une adresse redirigée et sa destination rend la comparaison confuse. Relevez l’URL finale affichée, puis celle déclarée comme canonique. Si les deux diffèrent, comprenez la raison avant de préparer une demande. Le suivi doit porter sur la version que vous voulez réellement voir retenue.

Vérifier un sitemap sans confondre ses pages et ses images

Ouvrez le sitemap annoncé dans robots.txt et identifiez son format : index de sitemaps ou liste d’URL. Dans le premier cas, examinez les fichiers enfants. Dans le second, contrôlez les adresses de pages et leurs variantes. Un sitemap d’images peut contenir d’autres balises loc à l’intérieur de chaque entrée : les traiter comme des pages produit de faux diagnostics de titre, de H1 ou de canonical. Une image JPEG n’a pas besoin d’une structure HTML d’article.

La documentation Google recommande d’y présenter les URL canoniques que l’on souhaite voir apparaître dans les résultats. La présence d’une date lastmod doit refléter une modification significative de la page : changer toutes les dates à chaque génération ne prouve pas que tous les articles ont été mis à jour. Lorsque la date fiable n’est pas disponible, mieux vaut corriger la source de cette information que fabriquer un calendrier de fraîcheur.

Exemple fictif : un export annonce 240 adresses, dont 90 images imbriquées. Le propriétaire croit disposer de 240 pages et relève 90 erreurs de H1. En séparant les entrées de pages des ressources, il retrouve 150 pages à contrôler. Son problème initial est celui de l’inventaire, pas celui de 90 articles dépourvus de titre. Conservez donc la provenance et le type de chaque adresse dans votre relevé.

Examiner la page rendue avant de solliciter Google

Sur une page d’article, vérifiez l’accès, le contenu visible, les liens de navigation et la version canonique. Regardez aussi les directives d’indexation et les éventuels obstacles à l’exploration. Un code 200 peut accompagner une page d’erreur présentée par le thème ; il faut donc lire le résultat. Inversement, une redirection cohérente peut être normale pour une ancienne variante, mais cette variante ne doit pas être confondue avec la page finale à suivre.

Un autre cas fréquent après migration vient du gabarit : le titre est affiché par le thème et un deuxième H1 reste dans le corps importé. Cela mérite une correction de la hiérarchie, sans réécrire automatiquement tout le texte ni changer son adresse. Vérifiez ensuite les liens internes qui conduisent à l’article. Une page présente dans un fichier XML mais difficile à trouver depuis les rubriques demande aussi un travail de navigation.

Pour un site JavaScript, assurez-vous que les ressources nécessaires au rendu peuvent être explorées. Un blocage large du dossier des scripts n’a pas la même portée que l’interdiction d’une API privée. Le contrôle doit distinguer ces ressources au lieu d’appliquer une règle de robots.txt copiée sans contexte. Retrouvez les repères complémentaires dans notre dossier sur le crawl et l’indexation.

Lire un verdict Google avec sa date et ses limites

L’inspection d’URL renseigne sur une adresse et sur les informations connues par Google au moment de la consultation. Gardez la date du contrôle, le verdict, la canonique retenue et, lorsqu’elle est disponible, la date du dernier crawl. Ne remplacez pas une absence de verdict par « non indexée ». Une autorisation expirée ou un accès refusé signifie que la lecture n’a pas pu être effectuée, pas que le site est absent de l’index.

Pour suivre plusieurs centaines de pages, commencez par les nouvelles publications et les anomalies confirmées. Les pages déjà inspectées récemment n’ont pas besoin d’être interrogées à chaque ouverture du tableau de bord. Un échantillon de vingt URL ne permet pas d’affirmer que toutes les autres ont le même statut. Affichez séparément le nombre de verdicts obtenus et le nombre d’adresses dont l’état reste inconnu.

Demander une indexation sans promettre son résultat

Google propose une demande dans l’outil d’inspection de Search Console pour les utilisateurs disposant des droits nécessaires. Il existe des quotas et répéter la demande ne fait pas explorer une même URL plus vite. Pour un grand ensemble d’adresses nouvelles ou modifiées, le sitemap constitue le canal de découverte adapté ; les demandes individuelles doivent rester maîtrisées et suivies, sans boucles de répétition.

L’API URL Inspection sert à lire des informations d’indexation, pas à envoyer cette demande. L’Indexing API de Google est réservée aux pages éligibles de type JobPosting ou BroadcastEvent dans VideoObject. Un article de blog ordinaire ne devient pas éligible parce qu’on souhaite accélérer sa découverte. Ne confondez pas davantage l’accusé d’un prestataire externe avec une confirmation Google d’indexation.

Un fonctionnement solide journalise une tentative avant l’action, puis son résultat explicite. Si l’interface confirme la demande, conservez une preuve datée. Si elle reste en cours ou que la connexion est interrompue après le clic, marquez l’issue comme incertaine et vérifiez-la avant de recommencer. Un contrôle de sécurité ou un quota impose un arrêt ; ce n’est pas une raison pour changer de compte ou contourner le blocage.

Organiser le suivi de chaque nouvel article

À la publication, contrôlez la page, son entrée de sitemap et un lien depuis une rubrique ou un article connexe. Enregistrez ensuite son URL finale dans une file dédupliquée. Un contrôle différé permet de constater la disponibilité et de rechercher un verdict Google lorsque l’accès le permet. L’article déjà indexé n’a pas besoin d’une nouvelle demande uniquement pour remplir une case du suivi.

Dans un exemple fictif, un article publié lundi entre dans le sitemap immédiatement. Mardi, le contrôle confirme un contenu lisible, une canonique cohérente et une navigation fonctionnelle. Le suivi indique ensuite soit un verdict d’indexation, soit une demande confirmée, soit un blocage nommé. Une semaine plus tard, la personne relit l’état avant d’agir à nouveau. Ce calendrier est une méthode d’organisation, pas un engagement sur le délai de Google.

La bonne synthèse tient en quelques nombres explicites : pages découvertes, pages contrôlées, verdicts récents, demandes confirmées et cas bloqués. Ajoutez un lien vers les détails plutôt qu’un indicateur unique « tout est indexé ». Vous pourrez alors prioriser les problèmes réels de contenu, de technique ou de découverte, sans multiplier des actions qui donnent une impression d’activité mais ne répondent pas au diagnostic.

Pour approfondir : comprendre le crawl et l’indexation et organiser la navigation du site.

Pages liees et ressources

Les pages les plus utiles a consulter ensuite sur ce sujet.

Sources

Sources citees

Docs officielles, standards et references. A enrichir au fil de l'eau.

  1. 1
  2. 2
  3. 3
  4. 4