Comment soumettre votre sitemap à Google Search Console (2026)

Vous avez mis le site en ligne. Les pages sont publiées, le HTML est propre, le contenu est bon. Et pourtant site:votredomaine.com ne renvoie rien. Google ne sait pas que vous existez.

Un sitemap, c’est la façon de fournir à Google une liste lisible par machine des URLs que vous voulez faire explorer. Le soumettre via Google Search Console (GSC) indique à Google « voici l’inventaire canonique de mon site — commence ici ». Cela ne garantit pas l’indexation, mais cela supprime le problème de découverte, qui est, pour un site tout neuf, la partie la plus lente.

Ce guide est la version pratique, orientée développeur : vérifier la propriété, soumettre le sitemap, demander l’indexation de vos pages importantes, décoder le déroutant statut Couldn't fetch et brancher le sitemap dans robots.txt pour que chaque crawler le trouve. Pas de blabla, de vraies commandes.

🧑‍💻 Vue développeur : un sitemap n’est qu’un document XML avec une liste d’URLs <loc> plus des indications <lastmod> optionnelles. GSC est un tableau de bord posé au-dessus du pipeline d’exploration/indexation de Google. Soumettre un sitemap est un signal de type POST « voici ma liste d’URLs » — rien de magique ne se produit, vous raccourcissez simplement le chemin entre « la page existe » et « Googlebot la récupère ».

Vérifier la propriété

Avant que GSC ne vous montre quoi que ce soit, vous devez prouver que vous êtes propriétaire du site. GSC propose deux types de propriété, et le choix compte car il détermine à la fois la méthode de vérification et les données que vous voyez.

	Propriété de domaine	Propriété de préfixe d’URL
Couvre	Tous les sous-domaines + http/https	Une seule origine exacte
Portée d’exemple	`example.com`, `www.`, `blog.`, http & https	`https://example.com/` uniquement
Vérification	Enregistrement DNS `TXT`	Balise HTML, fichier HTML, GA, GTM ou DNS
Fonctionne sur `*.pages.dev`	Non (impossible d’éditer le DNS)	Oui
Idéal pour	Sites dont vous contrôlez le DNS	Sous-domaines, démarrage rapide, données granulaires

La propriété de domaine se vérifie via un enregistrement DNS TXT puis couvre tout ce qui se trouve sous le domaine — chaque sous-domaine, les deux protocoles. C’est l’option la plus propre si vous possédez la zone DNS. GSC vous fournit un jeton à ajouter :

# Add this as a TXT record on the apex (@) of your zone
google-site-verification=AbC123dEf456GhI789jKl0mNoPqRsTuVwXyZ_example

Avec la plupart des registraires ou avec Cloudflare DNS, vous l’ajouteriez ainsi :

Type:  TXT
Name:  @            (or yourdomain.com)
Value: google-site-verification=AbC123...
TTL:   Auto

Vérifiez sa propagation avant de cliquer sur « Valider » dans GSC :

dig +short TXT yourdomain.com | grep google-site-verification
# or
nslookup -type=TXT yourdomain.com

La propriété de préfixe d’URL vérifie une seule origine exacte (le protocole + l’hôte + la barre oblique finale ont tous leur importance — https://example.com/ et https://www.example.com/ sont des propriétés différentes). Vous pouvez la vérifier de plusieurs façons sans toucher au DNS :

<!-- Option A: meta tag in the <head> of your homepage -->
<meta name="google-site-verification" content="AbC123dEf456GhI789jKl0..." />

# Option B: upload a verification file to the site root
# GSC gives you something like: google1234567890abcdef.html
# It must be reachable at:
https://example.com/google1234567890abcdef.html

Confirmez que le fichier est réellement servi avant de valider :

curl -sI https://example.com/google1234567890abcdef.html | head -n 1
# Expect: HTTP/2 200

⚠️ Le piège pages.dev (et autres *.vercel.app, *.netlify.app, *.workers.dev) : vous ne pouvez pas créer de propriété de domaine pour un sous-domaine dont vous ne contrôlez pas le DNS. Vous ne possédez pas la zone pages.dev — c’est Cloudflare — donc il n’y a aucun enregistrement TXT que vous puissiez ajouter à ce niveau. Pour les sous-domaines de prévisualisation/staging, utilisez plutôt une propriété de préfixe d’URL et vérifiez avec la balise meta HTML ou un fichier importé. Une fois le site placé sur votre propre domaine personnalisé, basculez vers (ou ajoutez) une propriété de domaine.

Pour la plupart des sites en production sur un domaine personnalisé, utilisez une propriété de domaine. Pour une URL *.pages.dev ou tout sous-domaine de plateforme, utilisez une propriété de préfixe d’URL avec vérification par fichier/meta.

Soumettre votre sitemap

Si votre build génère un index de sitemap (la plupart des frameworks le font — l’intégration sitemap d’Astro, par exemple, émet un sitemap-index.xml pointant vers un ou plusieurs morceaux sitemap-0.xml), vous soumettez l’index, pas les fichiers individuels. Google suit l’index et lit chaque enfant.

D’abord, vérifiez par bon sens que le fichier est bien en ligne et bien formé :

curl -s https://example.com/sitemap-index.xml | head -n 20
# Should return XML, not an HTML 404 page

# Check the status code and content type explicitly
curl -sI https://example.com/sitemap-index.xml | grep -iE 'HTTP/|content-type'
# Expect:
#   HTTP/2 200
#   content-type: application/xml   (or text/xml)

Un index de sitemap valide ressemble à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-0.xml</loc>
    <lastmod>2026-06-23T00:00:00.000Z</lastmod>
  </sitemap>
</sitemapindex>

Ensuite, dans GSC :

Ouvrez Search Console → votre propriété → Indexation → Sitemaps (barre latérale gauche).
Dans le champ Ajouter un sitemap, saisissez le chemin relatif à la racine de votre propriété. Pour la plupart des sites, c’est simplement sitemap-index.xml. GSC préremplit le domaine, vous ne saisissez donc que le chemin :
```
sitemap-index.xml
```
Cliquez sur Envoyer.
La ligne apparaît avec le statut Opération réussie (ou, souvent au début, un état temporaire — voir la section suivante). Cliquez sur la ligne pour voir combien d’URLs Google a découvertes.

💡 Soumettez le fichier d’index une seule fois, pas chaque enfant. Google le relit selon son propre calendrier, il n’y a donc rien à resoumettre lorsque vous publiez de nouvelles pages — votre build régénère simplement le XML et Google récupère les nouvelles entrées <loc> au passage suivant.

Demander l’indexation

Soumettre un sitemap place vos URLs dans la file de découverte de Google. Pour la poignée de pages qui comptent le plus pour vous (page d’accueil, landing pages clés, votre meilleur contenu), vous pouvez pousser Google directement avec l’outil Inspection d’URL :

Collez l’URL complète dans la barre de recherche tout en haut de GSC (elle est intitulée « Inspecter une URL dans… »).
GSC récupère l’URL depuis son index et indique si elle est déjà indexée.
Cliquez sur Tester l’URL en direct pour confirmer que Google peut récupérer la version actuelle (cela fait aussi remonter les problèmes de rendu, les blocages robots et les balises noindex).
Si tout semble bon, cliquez sur Demander une indexation. Cela ajoute l’URL à une file d’exploration prioritaire.

Inspect:  https://example.com/                 → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/pricing           → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/blog/launch-post  → "URL is not on Google" → Request Indexing

⚠️ La demande d’indexation est soumise à une limite de débit (un petit quota quotidien) et est destinée aux URLs importantes individuelles — pas à gaver de force un site de 5 000 pages. Pour le volume, le sitemap est le bon outil ; laissez l’exploration se faire à grande échelle d’elle-même. Les demandes manuelles sont réservées aux 5 à 20 pages qui comptent le plus en ce moment.

« Impossible de récupérer » est généralement une fausse alerte

Le moment de panique le plus courant pour les nouveaux propriétaires de sites : vous soumettez sitemap-index.xml, vous actualisez, et le statut affiche Couldn't fetch. Avant de commencer à réécrire votre XML, sachez ceci : juste après la soumission, ce statut est fréquemment temporaire. Google a mis la récupération en file d’attente mais ne l’a pas encore réellement récupérée ni traitée, et le tableau de bord affiche un texte de remplacement. Dans une grande proportion des cas, il bascule sur Success en quelques heures à quelques jours sans aucun changement de votre côté.

La première étape est donc vraiment : attendre 1 à 3 jours et revérifier.

Cela dit, si cela persiste, parcourez cette checklist — ce sont les vraies causes, et chacune est vérifiable depuis votre terminal :

Renvoie 200. L’URL du sitemap doit répondre avec 200 OK, pas une chaîne de redirections, ni 403, 404 ou 5xx.

curl -sI https://example.com/sitemap-index.xml | head -n 1
# HTTP/2 200   = good   |   anything else (301/302/403/404/5xx) is a problem

Bon type de contenu. Servez application/xml ou text/xml. Si votre serveur envoie text/html (fréquent lorsqu’un fallback SPA ou une page 404 est renvoyé à la place du fichier), Google peut le rejeter.

curl -sI https://example.com/sitemap-index.xml | grep -i content-type
# content-type: application/xml   = good
# content-type: text/html         = bad (you're serving an HTML page, not the sitemap)

robots.txt ne le bloque pas. Un Disallow: /sitemap égaré ou une règle trop large peut empêcher Googlebot de lire le fichier. Récupérez votre robots et lisez-le :
```
curl -s https://example.com/robots.txt
# Make sure nothing disallows the sitemap path for Googlebot
```
Aucune incohérence de protocole / d’hôte (le piège du cross-origin). Chaque <loc> à l’intérieur du sitemap doit être sur le même protocole et le même hôte que la propriété et que le fichier sitemap lui-même. Si votre propriété est le préfixe d’URL https://example.com mais que vos entrées <loc> indiquent http:// ou www.example.com, Google les traite comme cross-site et les ignore. Faites quelques vérifications ponctuelles :
```
curl -s https://example.com/sitemap-0.xml | grep -oE '<loc>[^<]+' | head
# Every URL should start with https://example.com/ — no http://, no bare www mismatch
```
Aucun noindex / mur d’authentification sur le chemin du sitemap. Les sites de staging sont souvent derrière une authentification HTTP basic ou une politique Cloudflare Access. Si le sitemap requiert une connexion, Googlebot reçoit un 401/403 et ne peut pas le récupérer.

Si les cinq points passent et que le statut refuse toujours de se débloquer après une semaine, utilisez Tester l’URL en direct sur l’URL du sitemap dans l’inspection d’URL — cela vous montre la réponse exacte que voit Googlebot, ce qui révèle généralement l’incohérence immédiatement.

Combien de temps avant d’être indexé

Posez des attentes honnêtes, car l’impatience pousse les gens à « réparer » des choses qui ne sont pas cassées :

Situation du site	Délai typique avant les premières pages indexées
Domaine tout neuf, sans backlinks	De quelques jours à plusieurs semaines
Nouvelles pages sur un site établi et fréquemment exploré	De quelques heures à quelques jours
Grand site, contenu mince ou dupliqué	Lent / partiel — Google peut sauter des pages

La découverte (Google sait que l’URL existe) est rapide une fois le sitemap soumis. L’indexation (Google récupère, rend, évalue et décide de stocker la page) est la partie qui prend du temps, et c’est une décision de qualité et de confiance, pas seulement une file d’attente. Un domaine récent sans liens et sans historique se situe plus bas en priorité — c’est normal, pas un bug. Continuez à publier, gagnez quelques liens, et la fréquence d’exploration augmente d’elle-même.

💡 « Détectée, actuellement non indexée » et « Explorée, actuellement non indexée » dans le rapport Pages ne sont pas des erreurs. Cela signifie que Google a trouvé (ou récupéré) l’URL mais n’a pas encore choisi de l’indexer — généralement un signal de contenu mince ou de faible priorité sur les nouveaux sites. Améliorez la page ou gagnez des liens plutôt que de resoumettre.

Le lier depuis robots.txt

La soumission GSC informe Google. Ajouter une ligne Sitemap: à robots.txt informe tous les crawlers — Bing, DuckDuckGo et tout ce qui respecte le standard — sans tableau de bord par moteur. C’est une mesure « ceinture et bretelles » en une ligne, et c’est la façon canonique d’annoncer un sitemap.

# robots.txt
User-agent: *
Allow: /

# Absolute URL, one per line; you can list multiple sitemaps
Sitemap: https://example.com/sitemap-index.xml

Quelques règles qui font trébucher :

L’URL Sitemap: doit être absolue (https://... complet), pas un chemin relatif.
Elle est indépendante des blocs User-agent — placez-la n’importe où dans le fichier, par convention en haut ou en bas.
Vous pouvez lister plusieurs lignes Sitemap: si vous séparez les sitemaps par section ou par langue.

Vérifiez qu’elle est en ligne :

curl -s https://example.com/robots.txt | grep -i sitemap
# Sitemap: https://example.com/sitemap-index.xml

🧑‍💻 Comment nous avons procédé sur ce site : exactement cette configuration — un sitemap-index.xml auto-généré, une ligne Sitemap: dans robots.txt, une propriété de domaine dans GSC, et quelques demandes d’indexation pour les pages piliers. Si vous voulez générer des entrées robots.txt et sitemap propres sans éditer le XML à la main, notre outil robots & sitemap le fait pour vous. Et une fois que Google explore, notre guide sur l’analyse des logs et le budget de crawl montre comment confirmer que Googlebot récupère réellement les URLs que votre sitemap annonce.

En résumé

Tout le flux, dans l’ordre :

Vérifiez la propriété — propriété de domaine (DNS TXT) si vous contrôlez le DNS ; préfixe d’URL (balise/fichier HTML) pour pages.dev et autres sous-domaines de plateforme.
Soumettez sitemap-index.xml sous Indexation → Sitemaps. Soumettez l’index, pas les enfants.
Demandez l’indexation de vos 5 à 20 URLs les plus importantes via l’inspection d’URL.
Ne paniquez pas face à Couldn't fetch — attendez 1 à 3 jours, puis déroulez la checklist 200 / type de contenu / robots / cross-origin / authentification.
Soyez patient — la découverte est rapide, l’indexation d’un nouveau domaine prend de quelques jours à quelques semaines.
Ajoutez une ligne Sitemap: à robots.txt pour que chaque crawler le trouve.

Prochaines étapes : générez votre configuration robots.txt et sitemap avec l’outil robots & sitemap, puis observez le comportement de Googlebot dans vos logs serveur avec le guide sur le budget de crawl. La soumission est le début de la conversation avec Google — les logs vous disent s’il écoute.