Comment générer un sitemap XML sur WordPress sans plugin ?

Comprendre le sitemap XML WordPress natif

Depuis WordPress 5.5, un sitemap XML est généré automatiquement à l’adresse standard /wp-sitemap.xml. Cette fonctionnalité native couvre les types de contenus les plus courants (articles, pages, catégories, étiquettes, auteurs) et convient à l’immense majorité des blogs. Elle produit un point d’entrée unique qui regroupe les sous-sitemaps par type de contenu au sein d’un sitemap index¹. Pour un blog WordPress débutant, partir de ce mécanisme évite les dépendances à des extensions, limite les risques de conflits et reste compatible avec les thèmes classiques comme les thèmes bloc. Sur un réseau multisite, chaque site enfant dispose de son propre /wp-sitemap.xml, isolé du reste du réseau, ce qui facilite la gestion à l’échelle.

Le comportement par défaut suit la visibilité du contenu dans WordPress. Les éléments en brouillon, privés ou protégés ne sont pas inclus. De plus, la balise lastmod tient compte des dates de modification des contenus, ce qui aide les moteurs à prioriser l’exploration. Avant toute personnalisation, vérifiez que l’URL /wp-sitemap.xml est accessible sur votre domaine en navigation privée et que le serveur ne renvoie pas d’erreur 404 ou 500. En cas de cache agressif, purgez-le après chaque modification de réglage liée au sitemap.

“Je pensais avoir besoin d’un plugin, mais /wp-sitemap.xml était déjà là. Après l’avoir soumis, Google a commencé à découvrir mes nouveaux articles sans délai.”

Activer l’indexation Google dans WordPress

Un sitemap ne sert que si votre site est indexable. Dans Réglages Lecture, assurez-vous que l’option “Demander aux moteurs de recherche de ne pas indexer ce site” est décochée. C’est l’étape la plus simple mais aussi la plus oubliée lors des mises en ligne. Si vous avez migré depuis un environnement de préproduction, contrôlez que d’éventuelles directives noindex héritées de l’ancien thème ou d’un en-tête HTTP n’empêchent pas l’indexation Google. Les thèmes bloc comme les thèmes classiques n’altèrent pas ce réglage, mais certaines configurations de sécurité peuvent ajouter des en-têtes X-Robots-Tag indésirables côté serveur. Un test rapide avec l’outil d’inspection d’URL de Google confirmera l’état d’exploration.

Le fichier robots.txt doit autoriser l’accès aux chemins publics et indiquer l’URL du sitemap. Un exemple simple convient à la plupart des blogs WordPress débutants : User-agent²: * puis Allow: / et enfin Sitemap: https://votre-domaine.fr/wp-sitemap.xml. Évitez de bloquer /wp-content/ et /wp-includes/ à l’aveugle, car certains fichiers CSS et JS nécessaires au rendu peuvent s’y trouver. Si vous ne pouvez pas éditer un fichier robots.txt physique à la racine, WordPress peut en servir un “virtuel” modifiable via un filtre. Pour cela, vous pouvez ajouter une courte fonction dans functions.php afin d’insérer la ligne Sitemap automatiquement et réduire les oublis lors d’une refonte.

Ajouter du code dans functions.php pour un sitemap personnalisé

Si le sitemap natif suffit, ne changez rien. Sinon, vous pouvez contrôler précisément ce qui entre dans le flux via de courts filtres dans functions.php. Travaillez de préférence dans un thème enfant pour ne pas perdre vos modifications lors d’une mise à jour de thème. Sur un multisite, placez les personnalisations communes dans un must-use plugin afin d’en garantir l’activation sur tous les sites du réseau.

Pour forcer l’activation du sitemap si un code tiers l’a désactivé : add_filter(‘wp_sitemaps_enabled’, ‘__return_true’);

Pour retirer les pièces jointes du sitemap et ajouter un type de contenu personnalisé si présent : add_filter(‘wp_sitemaps_post_types’, function($types){ unset($types[‘attachment’]); if (post_type_exists(‘portfolio’)) { $types[‘portfolio’] = ‘portfolio’; } return $types; });

Pour exclure une taxonomie, par exemple les étiquettes : add_filter(‘wp_sitemaps_taxonomies’, function($tax){ unset($tax[‘post_tag’]); return $tax; });

Pour affiner la date de dernière modification envoyée par élément : add_filter(‘wp_sitemaps_posts_entry’, function($entry, $post){ $entry[‘lastmod’] = get_post_modified_time(‘c’, true, $post); return $entry; }, 10, 2);

Pour ajouter automatiquement la ligne Sitemap dans le robots.txt virtuel de WordPress : add_filter(‘robots_txt’, function($output){ $output .= « \nSitemap:  » . home_url(‘/wp-sitemap.xml’); return $output; }, 10, 1);

Ces exemples restent légers, compatibles avec les thèmes bloc et sans dépendances additionnelles. Après ajout, videz le cache du site et, si vous avez modifié des règles de réécriture ailleurs, connectez-vous une fois à Réglages Permaliens afin que WordPress rafraîchisse les règles. Testez toujours sur une copie de préproduction avant de déployer sur un site en production.

Vérifier Search Console et fichier robots.txt

Une fois le sitemap opérationnel, ajoutez votre site dans Search Console. Préférez la propriété Domaine si vous contrôlez le DNS, sinon utilisez la propriété Préfixe d’URL. Soumettez ensuite l’URL complète du sitemap, par exemple https://votre-domaine.fr/wp-sitemap.xml. L’interface confirmera la découverte, puis affichera le nombre d’URL valides et les éventuels avertissements. Surveillez en priorité les pages Exclues et les anomalies d’exploration : une hausse soudaine peut révéler des liens internes brisés ou un conflit de directives noindex.

Si Search Console signale “Bloquée par le fichier robots.txt”, comparez la date de dernière récupération du robots.txt par Google et la version attendue. Vérifiez que la directive Sitemap pointe bien vers /wp-sitemap.xml, que l’hôte et le protocole sont corrects, et qu’aucune directive Disallow globale ne couvre involontairement /wp-*. Pour un multisite, confirmez que chaque sous-site référence son propre sitemap et non celui du site principal. En cas de migration récente vers HTTPS, recherchez les références en HTTP restées dans le robots.txt ou dans les redirections serveur. Un contrôle rapide avec l’outil robots.txt de Search Console accélère le diagnostic.

Search Console n’a pas besoin d’être “synchronisée” au-delà de la soumission du sitemap. Si vous déployez des ajustements via functions.php, vous pouvez déclencher une ré-exploration plus rapide en soumettant de nouveau le sitemap dans la section dédiée. Cette action équivaut pour Google à un signal de mise à jour et remonte plus vite les erreurs potentielles de balisage.

Automatiser les mises à jour et bonnes pratiques multisite

Le sitemap natif reflète automatiquement les nouvelles publications ; vous n’avez rien d’autre à faire côté génération. Toutefois, pour accélérer la prise en compte par les moteurs après des ajouts massifs, vous pouvez envoyer un ping³ vers l’endpoint public de Google ou de Bing. Une automatisation simple consiste à planifier une tâche qui envoie une requête HTTP lorsque des modifications surviennent en lot. Par exemple, une approche minimaliste peut utiliser wp_remote_get sur https://www.google.com/ping?sitemap= suivi de l’URL complète du sitemap. Cette notification n’est pas obligatoire, mais elle aide lorsque vous importez de nombreux articles ou régénérez des pages d’archives.

Pour automatiser côté WordPress, une planification via le système cron⁴ interne suffit : if (!wp_next_scheduled(‘my_sitemap_ping’)) { wp_schedule_event(time(), ‘hourly’, ‘my_sitemap_ping’); } puis add_action(‘my_sitemap_ping’, function(){ $url = ‘https://www.google.com/ping?sitemap=’ . urlencode(home_url(‘/wp-sitemap.xml’)); wp_remote_get($url, array(‘timeout’=>5)); });. Ajustez la récurrence et, idéalement, conditionnez l’envoi à un réel changement de contenu pour éviter les notifications inutiles. Sur un multisite, itérez sur get_sites() et utilisez switch_to_blog() pour pinger le sitemap de chaque site, puis restore_current_blog().

Au-delà de l’automatisation, appliquez quelques pratiques stables : gardez un maillage interne propre pour que les moteurs trouvent vos nouvelles pages même sans sitemap, vérifiez que votre thème bloc n’ajoute pas de pages orphelines, et surveillez régulièrement les rapports de couverture dans Search Console. Le meilleur sitemap reste celui qui correspond exactement à votre périmètre public : évitez d’y inclure des archives vides, des taxonomies sans valeur ou des URL de recherche interne. En cas de croissance du site, préférez scinder le contenu par types et laisser WordPress générer plusieurs sous-sitemaps, plutôt que d’agréger manuellement un unique fichier volumineux.

Enfin, si vous avez des besoins avancés, sachez qu’il existe des filtres pour contrôler la pagination et le nombre d’URL par fichier, ou pour exclure des pages spécifiques selon des métadonnées. Testez vos réglages avec un navigateur et des outils de validation XML, et gardez en tête que la stabilité prime : de petits ajustements bien testés valent mieux qu’une réécriture complète de la génération.

1. sitemap index : fichier racine d’un ensemble de sitemaps qui référence plusieurs sous-sitemaps par type ou par lot, facilitant l’exploration à grande échelle.
2. user-agent : identifiant d’un robot d’exploration dans robots.txt, permettant d’appliquer des règles différentes selon le robot ciblé.
3. ping : requête HTTP envoyée à un moteur pour lui signaler qu’un sitemap a été mis à jour et qu’il peut être réexaminé.
4. cron : planificateur d’exécutions récurrentes de WordPress, déclenché par les visites, utilisé pour automatiser des tâches comme des notifications.