Robots.txt et sitemap WordPress : réglages SEO

Si vous avez déjà vu Google indexer une page “/wp-admin/” ou, à l’inverse, ignorer vos nouveaux articles pendant des jours, le problème vient souvent d’un duo mal réglé : robots.txt et sitemap. Sur WordPress 6.9.4 (avril 2026), vous avez déjà tout ce qu’il faut pour faire propre, mais il y a quelques pièges récurrents que je croise en dépannage, surtout sur des sites avec cache agressif et plugins SEO empilés.

Ce qu’on va construire

Vous allez mettre en place une configuration simple, stable et “SEO-friendly” pour :

un sitemap XML fiable (celui du cœur WordPress ou celui d’un plugin, mais pas les deux en conflit),
un robots.txt clair, qui n’empêche pas l’indexation utile et qui évite les zones sensibles (admin, endpoints techniques),
une vérification concrète via des URL de test et quelques contrôles indispensables (cache, en-têtes, statut HTTP).

C’est destiné aux blogs, sites vitrines, portfolios, et aussi aux sites un peu plus “chargés” (Elementor, Divi 5, Avada) tant que vous avez accès à l’admin WordPress et, idéalement, à votre hébergement.

À la fin, vous saurez :

où se trouve le sitemap sur WordPress 6.9.4,
comment WordPress génère robots.txt (et quand il ne le fait pas),
comment personnaliser robots.txt via un hook (un point d’accroche dans WordPress) sans modifier le cœur,
comment éviter les erreurs classiques (double sitemap, robots.txt mis en cache, “Disallow: /” en production).

Résumé rapide

WordPress 6.9.4 fournit un sitemap natif : /wp-sitemap.xml.
robots.txt peut être virtuel (généré par WordPress) ou physique (fichier à la racine). Le fichier physique prend le dessus.
La meilleure base : autoriser l’exploration, bloquer l’admin, et déclarer l’URL du sitemap.
Évitez de “bloquer pour le SEO” : bloquer des URL dans robots.txt n’empêche pas forcément l’indexation si des liens externes existent.
Ne cumulez pas : un seul générateur de sitemap (WordPress ou plugin SEO).
Testez toujours avec une URL directe + un contrôle HTTP (200/404/301) + vidage des caches.

Quand utiliser cette solution

Vous êtes sur WordPress 6.9.4+ et vous voulez une base propre sans dépendre d’un plugin.
Vous avez un site qui “marche”, mais Google Search Console signale :
- sitemap introuvable,
- URL bloquées par robots.txt,
- exploration qui part dans des pages techniques (paramètres, endpoints).
Vous utilisez Divi 5 / Elementor / Avada : ces builders n’empêchent pas la config robots/sitemap, mais ils ajoutent souvent des URLs et assets. Une base propre évite de surcorriger.
Vous voulez une méthode maintenable (mu-plugin ou plugin custom), pas un bricolage dans le core.

Quand ne PAS utiliser cette solution

Vous êtes sur un site en préproduction derrière un mot de passe HTTP (Basic Auth) : dans ce cas, robots/sitemap n’est pas votre priorité. La protection HTTP bloque déjà les robots.
Vous utilisez un plugin SEO (Yoast SEO, Rank Math, SEOPress) et vous voulez absolument son sitemap : ne forcez pas en plus celui du cœur sans vérifier les doublons.
Vous n’avez aucun accès à l’hébergement et votre hébergeur impose un robots.txt serveur : vous pourrez personnaliser via WordPress, mais certains comportements (cache/CDN) seront difficiles à maîtriser.
Vous cherchez à “désindexer” des pages déjà indexées : robots.txt n’est pas l’outil. Il faut plutôt noindex (meta robots) et/ou suppression via Search Console.

Avant de commencer (prérequis)

Avant de toucher à robots.txt, faites une sauvegarde. J’ai souvent vu un simple Disallow: / copié-collé au mauvais endroit faire chuter l’exploration pendant plusieurs semaines, surtout sur des sites avec cache qui fige l’erreur.

Prérequis techniques

WordPress : 6.9.4 ou plus récent
PHP : 8.1 minimum recommandé
Accès : identifiants admin WordPress + accès FTP/cPanel (ou gestionnaire de fichiers)
Thème enfant activé : recommandé si vous touchez au code (sinon, utilisez un plugin custom ou mu-plugin)

Outils utiles

Un navigateur + mode navigation privée (pour éviter le cache local)
Un outil de test HTTP (au choix) :
- le terminal avec curl,
- ou l’onglet Réseau des DevTools,
- ou un vérificateur d’URL dans Google Search Console.

Définitions rapides (pour débuter sans se perdre)

robots.txt : fichier (ou contenu) lu par les robots pour savoir quelles URLs explorer. Ce n’est pas un verrou de sécurité.
Sitemap XML : fichier listant des URLs importantes à découvrir/explorer. Sur WordPress, il peut être index (plusieurs sous-sitemaps).
Hook : point d’accroche dans WordPress. Un filtre modifie une valeur (ex : texte de robots.txt), une action déclenche du code (ex : au chargement).
mu-plugin : plugin “must-use” placé dans wp-content/mu-plugins/, chargé automatiquement. Très pratique pour ce type de snippet.

Résultat attendu (capture textuelle)

À la fin, vous devez pouvoir ouvrir :

https://votre-domaine.tld/robots.txt et voir :
- une section User-agent: *,
- un blocage de /wp-admin/ (avec exception /wp-admin/admin-ajax.php),
- une ligne Sitemap: https://votre-domaine.tld/wp-sitemap.xml (ou celle de votre plugin SEO).
https://votre-domaine.tld/wp-sitemap.xml et obtenir un HTTP 200 avec un XML lisible.

Étape 1 : Auditer votre robots.txt et votre sitemap existants

Le but est d’éviter le scénario classique : vous optimisez robots.txt, mais en réalité un plugin SEO ou un fichier robots.txt physique écrase tout, ou votre CDN sert une vieille version.

1) Vérifier robots.txt

Ouvrez : https://votre-domaine.tld/robots.txt
Copiez le contenu dans un fichier texte local (pour garder une trace).

Résultat attendu : un contenu texte (pas une 404). Si c’est une 404, ce n’est pas forcément grave : WordPress peut servir un robots “virtuel”, mais certains setups le désactivent (Nginx, règles serveur, sécurité).

2) Vérifier le sitemap natif WordPress

Ouvrez : https://votre-domaine.tld/wp-sitemap.xml
Vous devez voir un XML avec une liste de sitemaps (posts, pages, catégories, etc.).

Résultat attendu : HTTP 200. Si vous êtes redirigé vers une autre URL (301/302), notez-la.

3) Vérifier s’il existe un sitemap “plugin” en parallèle

Testez aussi (selon plugins courants) :

/sitemap_index.xml (souvent Yoast SEO)
/sitemap.xml (varie selon plugins)

Si plusieurs sitemaps répondent en 200, vous devez décider lequel vous gardez. Deux sitemaps valides ne “cassent” pas forcément le SEO, mais c’est une source de confusion (Search Console, erreurs de couverture, URLs incohérentes).

4) Contrôle HTTP rapide (optionnel mais très utile)

Sur votre ordinateur (macOS/Linux/WSL), testez :

curl -I https://votre-domaine.tld/robots.txt
curl -I https://votre-domaine.tld/wp-sitemap.xml

Résultat attendu :

HTTP/2 200 (ou HTTP/1.1 200)
Pas de redirection en boucle
Pas de 403 (souvent un WAF / plugin sécurité trop strict)

Étape 2 : Activer et vérifier le sitemap natif de WordPress 6.9.4

Le sitemap natif existe depuis WordPress 5.5. Sur WordPress 6.9.4, il est mature et largement suffisant pour un blog débutant à intermédiaire.

2.1 Vérifier que le sitemap n’est pas désactivé par du code

Un thème ou un plugin peut désactiver le sitemap via le filtre wp_sitemaps_enabled. Si /wp-sitemap.xml renvoie 404, c’est une piste fréquente.

Si vous avez accès au code, cherchez dans vos plugins/thème (ou via un plugin de recherche) : wp_sitemaps_enabled.

2.2 Vérifier les types de contenus inclus

WordPress inclut des “providers” de sitemap (posts, taxonomies, auteurs selon config). Pour un blog, c’est généralement OK. Si votre site est petit, ne cherchez pas à tout filtrer au début : chaque exception est un risque de bug.

2.3 Déclarer le sitemap dans Google Search Console

Ouvrez Google Search Console.
Menu Sitemaps.
Ajoutez : https://votre-domaine.tld/wp-sitemap.xml

Résultat attendu : “Succès” puis, après un délai, des URLs découvertes.

Note sur les plugins SEO

Si vous utilisez Yoast/Rank Math/SEOPress et que vous préférez leur sitemap, c’est valide. Dans ce cas :

gardez un sitemap principal déclaré dans Search Console,
et évitez de bricoler le sitemap natif, sauf besoin précis.

Sources officielles utiles :

Étape 3 : Comprendre et optimiser le robots.txt (virtuel) de WordPress

WordPress peut générer un robots.txt “virtuel” si aucun fichier robots.txt n’existe à la racine. C’est pratique, mais ça surprend : vous modifiez un fichier en FTP… qui n’est jamais lu, ou l’inverse.

3.1 Robots virtuel vs fichier robots.txt physique

Robots virtuel : WordPress répond sur /robots.txt via une requête. Vous pouvez le modifier via un filtre.
Robots physique : un vrai fichier robots.txt à la racine du site (à côté de wp-config.php en général). Le serveur le sert directement, WordPress ne le touche pas.

Dans la vraie vie, le fichier physique est souvent mis en place par un hébergeur, un plugin de cache, ou un ancien prestataire. C’est une cause classique de “je change mais rien ne bouge”.

3.2 Base recommandée (pragmatique) pour un site WordPress

Pour un blog/vitrine, je pars presque toujours sur :

Autoriser globalement
Bloquer /wp-admin/
Autoriser /wp-admin/admin-ajax.php (utile pour certaines fonctionnalités)
Déclarer le sitemap

Exemple de contenu :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://votre-domaine.tld/wp-sitemap.xml

3.3 Ce que je déconseille aux débutants

Bloquer /wp-includes/ ou /wp-content/ “pour le SEO” : vous risquez de casser le rendu (CSS/JS/images), et donc le SEO.
Ajouter 40 règles copiées d’un vieux tutoriel : beaucoup sont obsolètes, et certaines bloquent des endpoints utiles (REST API, feeds).
Utiliser robots.txt comme une mesure de confidentialité : ce n’est pas fait pour ça.

Source officielle sur le point d’entrée robots :

Filtre robots_txt (WordPress)

Étape 4 : Personnaliser robots.txt proprement (sans casser les mises à jour)

On va utiliser un mu-plugin. C’est la méthode la plus stable : pas dépendante du thème, chargée tôt, et moins sujette aux “snippets” cassés par un builder.

4.1 Créer le mu-plugin

Via FTP/cPanel, allez dans wp-content/.
Créez un dossier mu-plugins s’il n’existe pas.
Créez un fichier : wp-content/mu-plugins/bpcab-robots-sitemap.php

Collez ce code :

<?php
/**
 * Plugin Name: BPCAB - Robots.txt & Sitemap (optimisation de base)
 * Description: Ajuste robots.txt (virtuel) et ajoute une ligne Sitemap fiable sur WordPress 6.9.4+.
 * Version: 1.0.0
 * Author: Votre Nom
 *
 * Ce mu-plugin est chargé automatiquement. Ne modifiez jamais le core WordPress.
 */

defined('ABSPATH') || exit;

/**
 * Filtre robots_txt :
 * - $output : contenu existant du robots virtuel
 * - $public : 1 si le site est "indexable" (Réglages > Lecture), 0 sinon
 *
 * Attention : si un fichier robots.txt physique existe à la racine, ce filtre ne servira à rien.
 */
add_filter('robots_txt', function (string $output, bool $public): string {

	// Si le site est réglé sur "Demander aux moteurs de recherche de ne pas indexer ce site",
	// WordPress peut générer des règles restrictives. On respecte ce choix.
	if (!$public) {
		return $output;
	}

	$site_url = home_url('/');

	// Base simple et robuste : on n'essaye pas de "sculpter" le crawl à l'excès.
	$lines = [];
	$lines[] = 'User-agent: *';
	$lines[] = 'Disallow: /wp-admin/';
	$lines[] = 'Allow: /wp-admin/admin-ajax.php';
	$lines[] = '';
	$lines[] = 'Sitemap: ' . $site_url . 'wp-sitemap.xml';

	/**
	 * Petite protection : si un plugin a déjà ajouté une ligne Sitemap,
	 * on évite de dupliquer.
	 */
	$already_has_sitemap = (stripos($output, 'sitemap:') !== false);
	if ($already_has_sitemap) {
		// On conserve l'existant et on n'ajoute pas notre ligne.
		return $output;
	}

	// On remplace proprement la sortie par notre contenu.
	return implode("n", $lines) . "n";

}, 20, 2);

4.2 Comprendre ce que fait ce code

Le filtre robots_txt reçoit le contenu actuel de WordPress et le modifie. Ici, on :

respecte le réglage “discourage les moteurs” (sinon vous pourriez rendre indexable un site volontairement bloqué),
ajoute une base minimaliste,
évite de dupliquer une ligne Sitemap: si elle est déjà présente (cas fréquent avec des plugins SEO).

4.3 Vérifier le résultat

Ouvrez : /robots.txt
Vous devez voir exactement les lignes ajoutées.

Résultat attendu (capture textuelle) : un robots.txt avec Disallow: /wp-admin/ et une ligne Sitemap:.

4.4 Si vous ne voyez aucun changement

Dans mon expérience, c’est presque toujours :

un fichier robots.txt physique existe déjà à la racine,
ou un cache (plugin, serveur, CDN) sert une version figée.

Étape 5 : Cas pratiques (blog, site vitrine, e-commerce, multisite)

Cas 1 : Blog / site vitrine (recommandé pour débuter)

Gardez la base. Ne bloquez pas les tags/catégories via robots.txt “par réflexe”. Si vous ne voulez pas indexer certaines archives, utilisez plutôt une stratégie noindex (via plugin SEO) pour éviter les incohérences.

Cas 2 : E-commerce (WooCommerce)

Sur WooCommerce, je vois souvent des gens bloquer des paramètres d’URL au hasard. Prudence : ça peut empêcher Google de découvrir des pages utiles si votre navigation utilise des paramètres.

Ce que vous pouvez envisager (avec parcimonie) :

Bloquer des endpoints purement techniques si vous en avez (à valider au cas par cas).
Ne bloquez pas /cart/ et /checkout/ via robots.txt “pour la sécurité”. Préférez noindex (plugin SEO) pour éviter que ces pages apparaissent dans les résultats.

Cas 3 : Multisite

En multisite, le sitemap natif fonctionne, mais l’architecture (sous-domaines vs sous-répertoires) change la manière dont les robots explorent. Le robots.txt à la racine impacte tout. Testez chaque site du réseau :

https://site1.tld/wp-sitemap.xml
https://site2.tld/wp-sitemap.xml

Cas 4 : Site en maintenance / staging

Si c’est un staging accessible publiquement, le bon réglage n’est pas robots.txt. Le bon réglage est :

auth HTTP (Basic Auth) côté serveur, ou
restriction IP, ou
site non accessible publiquement.

robots.txt peut être ignoré par certains bots, et il expose vos chemins sensibles.

Le résultat complet

Si vous voulez tout copier en une fois, voici le mu-plugin complet (identique à l’étape 4). Vous pouvez personnaliser uniquement la partie “lignes” si besoin.

<?php
/**
 * Plugin Name: BPCAB - Robots.txt & Sitemap (optimisation de base)
 * Description: Ajuste robots.txt (virtuel) et ajoute une ligne Sitemap fiable sur WordPress 6.9.4+.
 * Version: 1.0.0
 */

defined('ABSPATH') || exit;

add_filter('robots_txt', function (string $output, bool $public): string {

	// Respecte le réglage "discourager les moteurs" (Réglages > Lecture).
	if (!$public) {
		return $output;
	}

	$site_url = home_url('/');

	$lines = [];
	$lines[] = 'User-agent: *';
	$lines[] = 'Disallow: /wp-admin/';
	$lines[] = 'Allow: /wp-admin/admin-ajax.php';
	$lines[] = '';
	$lines[] = 'Sitemap: ' . $site_url . 'wp-sitemap.xml';

	// Évite les doublons si un plugin SEO injecte déjà une ligne Sitemap.
	if (stripos($output, 'sitemap:') !== false) {
		return $output;
	}

	return implode("n", $lines) . "n";

}, 20, 2);

Personnalisations raisonnables (débutant-friendly)

Si vous utilisez un plugin SEO et que vous voulez son sitemap :
- remplacez wp-sitemap.xml par l’URL du plugin (ex : sitemap_index.xml),
- ou laissez le plugin gérer robots.txt et supprimez ce mu-plugin (plus simple).
Si votre site est sur un sous-dossier (rare en 2026, mais ça existe), home_url('/') gère correctement la base.

Adapter pour Divi 5 / Elementor / Avada

Bonne nouvelle : robots.txt et sitemap sont indépendants du builder. Divi 5, Elementor et Avada n’ont pas besoin d’un réglage spécial pour que /wp-sitemap.xml fonctionne.

Divi 5

Divi 5 génère parfois beaucoup d’assets et de variations de CSS. Ne bloquez pas /wp-content/.
Si vous utilisez un plugin de performance spécifique à Divi (minification/critical CSS), vérifiez que /wp-sitemap.xml n’est pas mis en cache avec une mauvaise redirection.

Elementor

Elementor s’appuie sur des appels AJAX/REST. Évitez les règles robots “agressives” copiées d’anciens guides qui bloquent des endpoints.
Si vous avez un plugin de maintenance Elementor, ne le laissez pas actif en production : il peut renvoyer des codes 503/302 qui perturbent l’exploration.

Avada (Fusion Builder)

Avada + cache peut servir un robots.txt “figé” si votre cache met en cache /robots.txt. Si vous voyez un contenu qui ne change jamais, videz le cache Avada et le cache serveur.

Vérification finale

Faites ces tests dans l’ordre. Ça évite de courir après un problème de cache pendant 2 heures.

1) Vérifier l’accès direct

Ouvrez /robots.txt : vous devez voir votre contenu final.
Ouvrez /wp-sitemap.xml : vous devez voir un XML (pas une page HTML, pas un 403).

2) Vérifier les statuts HTTP

curl -I https://votre-domaine.tld/robots.txt
curl -I https://votre-domaine.tld/wp-sitemap.xml

Résultat attendu :

200 pour les deux
Pas de redirection étrange vers /index.php ou vers une URL avec paramètres

3) Vérifier la déclaration du sitemap dans robots.txt

Dans /robots.txt, cherchez une ligne :

Sitemap: https://votre-domaine.tld/wp-sitemap.xml

Si vous utilisez un plugin SEO, vérifiez que la ligne correspond bien à son URL de sitemap.

4) Vérifier côté Search Console

Soumettez le sitemap.
Contrôlez les erreurs : “Impossible de récupérer”, “URL bloquée par robots.txt”, “Soft 404”.

Tableau de diagnostic (rapide)

Symptôme	Cause probable	Vérification	Solution
robots.txt ne change jamais	Fichier robots.txt physique ou cache/CDN	Vérifier la racine du site + en-têtes cache + purge	Supprimer/éditer le fichier physique ou exclure /robots.txt du cache
/wp-sitemap.xml renvoie 404	Sitemap natif désactivé via filtre	Rechercher `wp_sitemaps_enabled` dans le code	Réactiver, ou utiliser le sitemap du plugin SEO
/wp-sitemap.xml renvoie 403	WAF / plugin sécurité / règle serveur	Tester en désactivant temporairement le plugin sécurité	Mettre en liste blanche l’URL du sitemap
Search Console: “URL bloquée par robots.txt”	Règles trop larges	Lire robots.txt et identifier le préfixe bloqué	Retirer la règle bloquante, préférer noindex

Si le résultat n’est pas celui attendu

Voici les problèmes que je rencontre le plus souvent, avec une résolution directe.

Problème 1 : “J’ai ajouté le mu-plugin, mais /robots.txt est inchangé”

Cause fréquente : un fichier robots.txt existe à la racine.
Vérification : via FTP/cPanel, cherchez public_html/robots.txt (ou équivalent).
Solution : éditez ce fichier (ou supprimez-le si vous voulez repasser en virtuel). Puis purge cache/CDN.

Problème 2 : “Mon site est en noindex (Réglages > Lecture), mais robots.txt montre un sitemap”

Cause : snippet mal écrit (ou ancien tutoriel) qui ignore le paramètre $public.
Vérification : regardez dans votre code si vous testez $public.
Solution : gardez la condition if (!$public) return $output; (comme dans le code fourni).

Problème 3 : “Erreur 500 après avoir collé le code”

Cause : parenthèse/point-virgule manquant, ou fichier encodé bizarrement.
Vérification : consultez les logs PHP sur l’hébergement, ou activez WP_DEBUG sur un environnement de test.
Solution : remplacez par le code exact, vérifiez PHP 8.1+, et évitez de coller dans un plugin de snippets qui tronque le fichier.

Problème 4 : “/wp-sitemap.xml renvoie une page de cache / maintenance”

Cause : un plugin de cache met en cache des endpoints XML, ou une règle de maintenance redirige tout.
Vérification : désactivez temporairement le cache et retestez.
Solution : excluez /wp-sitemap.xml du cache, et désactivez le mode maintenance en production.

Problème 5 : “J’ai deux sitemaps, lequel choisir ?”

Cause : sitemap natif + plugin SEO actif.
Vérification : testez /wp-sitemap.xml et /sitemap_index.xml.
Solution : choisissez un seul sitemap à soumettre dans Search Console (souvent celui du plugin SEO si vous l’utilisez pour noindex/canonicals).

Pièges et erreurs courantes

Erreur	Cause	Solution
Coller le code dans `functions.php` du thème parent	Le thème se met à jour et écrase vos modifications	Utiliser un thème enfant ou, mieux ici, un mu-plugin
Oublier de vider le cache (plugin/CDN/navigateur)	robots.txt et sitemap sont servis par une couche de cache	Purger tous les caches + tester en navigation privée + `curl -I`
Utiliser un snippet d’un tutoriel 2018	Règles obsolètes (REST, endpoints), ou code incompatible PHP 8.1	Utiliser le filtre `robots_txt` actuel et une base minimaliste
Bloquer `/wp-content/` ou `/*.js`	On “croit” réduire le crawl mais on casse le rendu	Ne pas bloquer les assets. Corriger via performance, pas via robots.txt
Confusion action/filtre	On utilise `add_action` au lieu de `add_filter`	Pour robots.txt, c’est un filtre : `add_filter('robots_txt', ...)`
Tester directement en production sans sauvegarde	Un `Disallow: /` peut rester en cache	Tester sur staging + sauvegarde + procédure de rollback

Variante / alternative

Méthode sans code : gérer robots.txt et sitemap via un plugin SEO

Si vous préférez une interface, un plugin SEO moderne peut :

générer un sitemap avancé (images, news selon plugin),
ajouter des options noindex par type de contenu,
parfois éditer robots.txt (selon plugin et selon si un fichier physique existe).

Ce que je recommande si vous passez par un plugin :

désactivez ou ignorez le sitemap natif (ne soumettez qu’un seul sitemap),
ne créez pas un fichier robots.txt physique si le plugin gère un robots virtuel,
gardez la config robots minimaliste (bloquer l’admin + sitemap).

Méthode “fichier robots.txt” (quand c’est pertinent)

Si votre serveur ne laisse pas WordPress servir /robots.txt, créez un fichier robots.txt à la racine du site (même niveau que wp-admin et wp-content).

Contenu recommandé :

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://votre-domaine.tld/wp-sitemap.xml

Résultat attendu : /robots.txt affiche exactement ce contenu, et le mu-plugin n’a plus d’effet (normal).

Conseils sécurité, performance et maintenance

robots.txt n’est pas une protection. Ne listez pas des URLs “secrètes” en pensant les cacher. Si c’est sensible, protégez par authentification/permissions.
Évitez les règles trop spécifiques. Chaque règle est une source d’erreur, surtout quand le site évolue (nouveaux plugins, nouveaux endpoints).
Surveillez le cache. Si vous avez un CDN (Cloudflare ou autre), excluez /robots.txt et /wp-sitemap.xml du cache si vous constatez des incohérences.
Gardez une trace. Notez votre robots.txt “cible” dans un doc interne. En dépannage, c’est précieux.
Mises à jour : testez après mise à jour majeure de plugin SEO/caching. J’ai déjà vu des règles serveur réécrites automatiquement.

Références utiles côté PHP (si vous devez diagnostiquer une erreur 500 liée à votre snippet) :

Gestion des erreurs PHP (php.net)

Pour aller plus loin

Une fois la base saine, vous pouvez améliorer sans risquer de tout casser :

Noindex ciblé (via plugin SEO) pour :
- pages de résultats internes,
- archives auteur (si site mono-auteur),
- tags très faibles (thin content).
Nettoyage sitemap (avancé) : exclure certains types de contenus (CPT inutiles) via les filtres de sitemaps. Faites-le seulement si vous savez exactement ce que vous retirez.
Surveillance : logs serveur + Search Console + rapports d’exploration.

Si vous devez aller plus loin côté sitemaps (développeur), commencez par la doc officielle :

WP Sitemaps API (developer.wordpress.org)

Ressources

FAQ

Est-ce que WordPress 6.9.4 génère un sitemap automatiquement ?

Oui. Par défaut, l’URL est /wp-sitemap.xml. Si vous obtenez une 404, un thème ou un plugin l’a probablement désactivé, ou une règle serveur bloque l’endpoint.

Dois-je soumettre le sitemap dans robots.txt ET dans Search Console ?

Oui, vous pouvez faire les deux. La ligne Sitemap: dans robots.txt aide certains crawlers, et Search Console reste la source de vérité pour Google.

Si je bloque une URL dans robots.txt, est-elle désindexée ?

Pas forcément. robots.txt empêche l’exploration, mais une URL peut rester indexée si Google la connaît via des liens externes. Pour désindexer, utilisez plutôt noindex (meta robots) et laissez Google explorer la page pour voir le noindex.

Pourquoi mon robots.txt affiche quelque chose alors que je n’ai pas de fichier ?

Parce que WordPress peut servir un robots.txt “virtuel”. C’est normal tant que l’URL /robots.txt renvoie un contenu cohérent.

Pourquoi mon mu-plugin ne modifie pas robots.txt ?

La cause la plus fréquente : un fichier robots.txt physique existe à la racine, et le serveur le sert avant WordPress. Deuxième cause : cache/CDN.

Dois-je bloquer /wp-json/ (REST API) dans robots.txt ?

Je ne le recommande pas pour un débutant. Beaucoup de plugins et builders s’appuient sur la REST API. Bloquer peut créer des effets de bord, sans gain SEO clair.

Est-ce dangereux de laisser /wp-admin/ accessible aux robots ?

Ce n’est pas “dangereux” au sens sécurité (la sécurité vient des permissions), mais c’est inutile à explorer. Le blocage Disallow: /wp-admin/ est une bonne hygiène.

Quel est le meilleur : sitemap natif WordPress ou sitemap d’un plugin SEO ?

Pour un site simple : le sitemap natif suffit. Si vous utilisez un plugin SEO pour gérer noindex/canonicals/filtrage fin, son sitemap peut être plus cohérent. L’important : n’en piloter qu’un.

Mon sitemap renvoie 200 mais Search Console dit “Impossible de récupérer”

J’ai vu ce cas avec des WAF/CDN qui répondent différemment à Googlebot. Vérifiez :

les logs du WAF,
un éventuel challenge (anti-bot),
les règles qui bloquent les XML.

Dois-je inclure les images dans le sitemap ?

Le sitemap natif liste surtout des URLs de contenus. Les plugins SEO peuvent enrichir avec des images. Si vous débutez, concentrez-vous d’abord sur la stabilité (200, pas de blocage) avant d’optimiser.

Que faire si j’ai copié un robots.txt “SEO” et que mon trafic baisse ?

Revenez à une base minimaliste (celle de ce tutoriel), purge cache/CDN, puis attendez la reprise d’exploration. Ensuite, corrigez avec noindex plutôt qu’avec des Disallow en cascade.