Maîtrisez le plan de site XML : le créer valide et le soumettre à Google

Vous avez un site, il est peut-être même bien référencé, et puis un jour vous ouvrez Google Search Console et vous découvrez que des dizaines de pages ne sont pas indexées. Vous vous dites que c'est un bug, que ça va passer. Ça ne passe pas. Le problème est souvent ailleurs : votre plan de site XML est invalide, ou pire, vous n'en avez jamais soumis un.

J'ai vu ça des dizaines de fois, sur mes propres projets comme sur ceux de mes clients. Un sitemap XML semble être un détail technique ennuyeux. En réalité, c'est le fil conducteur qui guide Google à travers votre site. Sans lui, le crawler navigue à l'aveugle.

Pourquoi votre sitemap XML est peut-être invalide sans que vous le sachiez

Générer un sitemap, c'est facile. Trop facile, justement. La plupart des plugins WordPress le font automatiquement, et on ne regarde jamais le résultat. J'ai longtemps fait partie de ces gens. Puis un jour, en inspectant le fichier brut d'un site client, j'ai découvert des balises fermées dans le désordre et des caractères encodés n'importe comment. Le plugin faisait son travail, mais le thème, lui, injectait du contenu indésirable dans le flux.

Un sitemap XML valide repose sur quelques règles non négociables. Premièrement, le fichier doit être encodé en UTF-8. Deuxièmement, chaque URL doit être contenue dans une balise <loc>, obligatoire. Troisièmement, la taille totale ne doit pas dépasser 50 Mo non compressé, avec un maximum de 50 000 URLs par fichier. Quatrièmement, le fichier doit être accessible directement en HTTP, sans redirection ni blocage par robots.txt.

Et là, surprise : beaucoup de gens ignorent la limite des 50 000 URLs. J'ai un ami qui gérait un site e-commerce avec plus de 60 000 fiches produits. Son plugin générait un fichier unique, parfaitement valide selon lui. Google ne prenait que les 50 000 premières, et le reste du catalogue restait invisible. Le problème n'était pas le sitemap en soi, c'était son architecture.

Quelles sont les balises obligatoires dans un sitemap ?

La réponse est simple : une seule balise est réellement obligatoire, c'est <loc>. Elle contient l'URL complète, absolue, de la page. Sans elle, le fichier est invalide.

Les autres balises, comme <lastmod> (date de dernière modification), <changefreq> (fréquence de changement) ou <priority> (priorité relative), sont facultatives. Vous pouvez les utiliser, mais elles n'influencent pas la validité du fichier. D'ailleurs, Google l'a répété à plusieurs reprises : ces métadonnées sont largement ignorées dans le classement. Ne perdez pas votre temps à les peaufiner. Concentrez-vous sur la structure.

Comment soumettre un sitemap à Google : étapes concrètes

Une fois votre fichier validé, la soumission est presque une formalité. Presque. Parce que si vous vous trompez de propriété dans Search Console, vous allez envoyer le fichier au mauvais endroit et vous demander pourquoi rien ne se passe.

Voici la procédure exacte, celle que j'applique pour tous mes sites :

1. Connectez-vous à votre compte Google Search Console.
2. Sélectionnez votre propriété de site dans le menu en haut à gauche. Vérifiez que c'est bien la bonne version (https, www, etc.).
3. Dans le menu de gauche, sous la section Indexation, cliquez sur Sitemaps.
4. Tapez la fin de l'adresse de votre sitemap dans la zone de texte. Par exemple : sitemap.xml.
5. Cliquez sur le bouton Envoyer pour valider.

C'est tout. Vraiment. La procédure prend deux minutes. Mais j'ai vu des gens bloquer à l'étape 4, en tapant l'URL complète (https://monsite.com/sitemap.xml) au lieu du simple nom de fichier. Search Console vous demande juste la fin du chemin, parce qu'il connaît déjà le domaine. Une erreur bête, qui génère un message « Sitemap introuvable » et beaucoup de confusion inutile.

Combien de temps Google met-il à traiter un sitemap ?

Franchement, c'est variable. Parfois quelques heures, parfois plusieurs jours. Ne vous attendez pas à une indexation instantanée. J'ai soumis un sitemap un vendredi soir pour un site de services, et le rapport affichait encore « En attente » le lundi matin. Puis tout est passé en « Réussi » dans la journée.

Ce qu'il faut surveiller, c'est le statut affiché dans le rapport. S'il reste bloqué sur « Impossible de récupérer » ou « Erreur de format », il y a un problème. Et le plus souvent, le problème est une faute de syntaxe XML dans votre fichier.

Valider votre sitemap avant de le soumettre : le geste qui vous évitera des jours de confusion

Je vais vous raconter une erreur que j'ai faite, et que je refais encore parfois par fainéantise. J'avais un site avec un sitemap généré à la volée par un script maison. Je l'ai soumis directement, sans vérifier. Résultat : « Erreur de format » pendant trois semaines. J'ai passé des heures à chercher une balise mal fermée dans un fichier de plusieurs milliers de lignes. La cause ? Un caractère spécial non échappé dans une description de page. Une virgule mal placée, et tout le fichier tombait.

Depuis, j'ai une règle : je valide toujours le fichier localement avant de l'envoyer. Concrètement, j'ouvre le fichier dans un navigateur ou un outil de validation XML, et je vérifie la structure. Un validateur XML standard suffit. Il détecte la moindre balise mal formée, tout de suite, sans ambiguïté.

Autre point que je vérifie systématiquement : l'accessibilité du fichier. J'utilise une simple requête curl pour m'assurer que le serveur répond avec un code 200, et non une redirection ou une erreur 404. Parce qu'un sitemap qui renvoie une redirection, c'est un sitemap que Google ne traitera pas correctement, même si le fichier est techniquement valide.

Les erreurs courantes après soumission et comment les corriger

Le rapport Sitemaps de Search Console ne ment pas. S'il affiche une erreur, c'est qu'il y en a une. Voici les plus fréquentes, celles que j'ai rencontrées en vrai, pas dans un manuel :

• Sitemap introuvable (404) : le fichier n'est pas à l'endroit indiqué, ou l'URL saisie est incomplète. Vérifiez que le fichier existe réellement à cette adresse.
• Erreur de format : le XML est mal formé. Une balise fermée en trop, un caractère non échappé, un encodage cassé. Validez le fichier avec un outil XML.
• URL bloquée par robots.txt : le fichier ou certaines URLs qu'il contient sont explicitement interdits au crawler. Modifiez robots.txt ou corrigez le sitemap.

Ce qui m'agace le plus, c'est l'erreur « Sitemap introuvable » alors que le fichier existe et fonctionne parfaitement dans un navigateur. Dans ce cas, 99% du temps, c'est une histoire de redirection ou de domaine. Le navigateur suit la redirection, Google non, du moins pas pour la soumission de sitemap. Vérifiez que l'URL exacte du fichier répond avec un code 200, sans redirection.

Quand faut-il utiliser un index de sitemaps ?

Pour les gros sites, la réponse est simple : dès que vous approchez des 50 000 URLs ou des 50 Mo. Mais franchement, il vaut mieux anticiper bien avant. J'ai un site avec environ 12 000 URLs, et je le fractionne déjà en plusieurs fichiers par catégories de contenu. Pourquoi ? Parce que c'est plus propre, plus facile à déboguer, et que je peux soumettre chaque fichier individuellement pour suivre son statut.

Le principe est simple : au lieu d'un seul sitemap.xml, vous créez un fichier index qui référence plusieurs fichiers de sitemap. Par exemple :

• sitemap-index.xml qui contient des références vers sitemap-produits.xml et sitemap-articles.xml
• Chaque fichier individuel contient ses propres URLs, avec ses propres balises
• Dans Search Console, vous soumettez uniquement le fichier index

J'ai mis du temps à adopter cette approche, parce que mon plugin WordPress ne le faisait pas nativement à l'époque. Maintenant, la plupart des bons plugins de SEO le proposent intégré. Si vous utilisez un générateur manuel, c'est un peu plus de travail, mais le gain en lisibilité est énorme.

Un conseil d'ami : si vous avez un site e-commerce avec des milliers de pages générées dynamiquement (filtres, tris, variantes), ne mettez pas tout dans le sitemap. Sélectionnez les URLs les plus importantes, celles qui apportent de la valeur. Un sitemap rempli de pages de filtres inutiles, c'est une invitation à diluer votre budget de crawl.

Comment vérifier que mon sitemap est bien pris en compte par Google ?

Le rapport Sitemaps dans Search Console est votre meilleur allié. Après soumission, il affiche le statut, la date de dernière lecture, et le nombre d'URLs découvertes. Si le statut est « Réussi », le fichier a été parsé correctement. Si le nombre d'URLs découvertes est très inférieur au nombre d'URLs dans votre fichier, il y a un problème à creuser, souvent lié à des redirections ou des pages en noindex.

Une autre façon de vérifier : l'outil d'inspection d'URL. Saisissez une URL qui se trouve dans votre sitemap, et vérifiez si Google la voit comme indexée. Mais attention, ce n'est pas une preuve directe que le sitemap fonctionne. C'est juste une indication que la page est accessible au crawler.

Dernier conseil : ne vous arrêtez pas à la soumission

Un sitemap n'est pas un document statique. Votre site évolue, de nouvelles pages apparaissent, d'autres disparaissent. Le sitemap doit suivre le mouvement. Un plugin qui se met à jour automatiquement, c'est bien. Une vérification mensuelle de votre rapport Sitemaps, c'est mieux. Je consacre vingt minutes chaque premier lundi du mois à cette vérification sur l'ensemble de mes sites. Ça m'a sauvé plus d'une fois, notamment quand une mise à jour de thème a cassé la génération du fichier sans que je m'en aperçoive.

Et si vous vous demandez encore si tout ça en vaut la peine : un site sans sitemap, c'est un site qui laisse Google découvrir ses pages au hasard, au rythme de ses liens internes. Parfois ça marche, souvent ça traîne. Le sitemap, lui, donne la liste exacte de ce que vous voulez indexer, sans ambiguïté. C'est un gain de temps, pour vous et pour Google. Alors oui, ça vaut la peine.