Indexation Google pour WordPress : le guide complet pour faire trouver chaque page
WordPress propulse plus de 40 % du web, mais des milliers de sites WordPress ont des pages que Google ne découvre jamais. Ce guide te fait passer en revue chaque réglage, configuration de plugin et ajustement serveur dont tu as besoin pour assurer une indexation complète et rapide de ton contenu WordPress.
Dans ce guide
WordPress propulse plus de 40 % du web, mais sa flexibilité crée des dizaines d'endroits où l'indexation peut se casser. Une case mal cochée dans Réglages > Lecture peut masquer ton site entier. Une mauvaise config d'un plugin SEO peut ajouter silencieusement des directives noindex. Un thème mal codé peut injecter des balises canoniques en double qui sèment la confusion chez Googlebot.
Ce guide est une revue spécifique à WordPress de chaque point de configuration qui affecte l'indexation : réglages du cœur, sitemaps Yoast/RankMath, structures de permaliens, règles .htaccess et endpoints de la REST API. Que tu gères un blog ou une boutique WooCommerce, les étapes ici s'appliquent.
Comprendre comment Google explore les sites WordPress
Google découvre les pages WordPress via trois canaux principaux :
- Ton sitemap XML — le mécanisme principal de découverte
- Les liens internes dans ton site que Googlebot suit
- Les backlinks externes pointant vers tes pages depuis d'autres sites
WordPress génère un sitemap intégré à /wp-sitemap.xml depuis la version 5.5, mais la plupart des propriétaires de sites utilisent un sitemap généré par plugin parce qu'il offre plus de contrôle sur les types de contenus, taxonomies et archives inclus.
Quand Googlebot arrive sur ton site WordPress, il vérifie d'abord robots.txt à la racine du domaine. WordPress génère un robots.txt virtuel via une fonction PHP plutôt que de servir un fichier statique, ce qui veut dire que les plugins et fonctions de thème peuvent le modifier de manière programmatique. Le robots.txt WordPress par défaut autorise tous les crawlers et pointe vers le sitemap, mais les plugins de sécurité ajoutent fréquemment des règles restrictives qui bloquent l'accès à /wp-admin/, /wp-includes/ et parfois même /wp-content/uploads/ — le dossier où vivent tous tes fichiers médias.
Après avoir lu robots.txt, Googlebot commence à explorer les pages. WordPress sert un HTML généralement bien structuré, mais le pipeline de rendu compte. Si ton thème dépend fortement de JavaScript pour la mise en page (courant avec des constructeurs de pages comme Elementor, Divi ou WPBakery), Google doit effectuer une deuxième passe de rendu. Cette indexation en deux passes — d'abord le HTML brut, puis la version rendue par JavaScript — peut retarder l'indexation complète de plusieurs jours, voire de semaines. Les pages construites avec l'éditeur de blocs natif Gutenberg sont rendues côté serveur et évitent complètement ce délai.
WordPress expose aussi le contenu via sa REST API à /wp-json/wp/v2/. Si Googlebot ne crawle généralement pas les endpoints REST API à des fins d'indexation, les sites mal configurés ont parfois des URLs REST API qui apparaissent dans les sitemaps ou les liens internes, créant de la confusion dans la file d'attente de crawl de Google.
Les réglages du cœur WordPress qui affectent l'indexation
Le réglage d'indexation le plus important de WordPress se trouve dans Réglages > Lecture. La case intitulée « Demander aux moteurs de recherche de ne pas indexer ce site » ajoute une balise <meta name="robots" content="noindex, nofollow"> à chaque page et modifie robots.txt pour inclure Disallow: /. Ce réglage est censé être utilisé pour les environnements de développement et de staging, mais on l'oublie en production plus souvent que tu ne l'imagines. Chaque audit d'indexation WordPress devrait commencer ici.
La structure des permaliens, configurée dans Réglages > Permaliens, détermine le format d'URL pour chaque article et page. La structure par défaut utilise des chaînes de requête simples comme /?p=123, qui sont crawlables mais ne fournissent aucun signal de mot-clé à Google. La structure recommandée pour la plupart des sites est « Nom de l'article » (/%postname%/), qui crée des URLs propres et lisibles. Si tu changes la structure des permaliens sur un site existant, WordPress ne crée pas de redirections automatiques pour les anciennes URLs. Chaque URL précédemment indexée renverra une 404 sauf si tu ajoutes des règles de redirection à .htaccess ou utilises un plugin comme Redirection.
Les réglages d'adresse du site dans Réglages > Général comptent aussi. Si ton adresse WordPress et ton adresse de site ne correspondent pas, ou si l'un utilise www et l'autre non, Google voit deux versions différentes de chaque URL. WordPress gère la redirection www-vers-non-www via les RewriteRules de .htaccess, mais les mauvaises configs ici provoquent des boucles de redirection qui empêchent complètement le crawl.
WordPress envoie aussi des pingbacks XML-RPC quand tu publies du nouveau contenu. Bien que le système XML-RPC à /xmlrpc.php soit largement obsolète au profit de la REST API, l'écran Réglages > Écriture a une liste de « services de notification » qui contrôle quels services reçoivent des notifications. Ajouter l'endpoint de ping de Google pour les sitemaps n'est plus efficace car Google a retiré le ping de sitemap en 2023, mais beaucoup de guides obsolètes continuent de le recommander.
Configuration des plugins SEO : Yoast SEO et RankMath
Yoast SEO et RankMath sont les deux plugins SEO WordPress les plus populaires, et tous deux offrent un contrôle étendu sur ton indexation. Ils génèrent les sitemaps XML, gèrent les directives meta robots, définissent les URLs canoniques et contrôlent l'apparence de ton contenu dans les résultats de recherche.
Yoast SEO génère son sitemap à /sitemap_index.xml, qui est un index de sitemaps contenant des liens vers des sitemaps individuels pour les articles, pages, catégories, étiquettes, archives d'auteurs et types de contenus personnalisés. Tu contrôles quels types de contenus apparaissent via Yoast > Réglages > Types de contenus et Yoast > Réglages > Catégories et étiquettes. Chaque type de contenu a un bouton « Afficher dans les résultats de recherche » — le désactiver ajoute une directive noindex à tout ce type de contenu et le retire du sitemap. C'est la cause numéro un de noindexation accidentelle sur WordPress.
RankMath utilise une approche similaire mais avec une interface plus granulaire. Ses réglages de sitemap se trouvent dans RankMath > Sitemap Settings, où chaque type de contenu et taxonomie a son propre onglet. RankMath a aussi un onglet « Avancé » par page dans l'éditeur d'article où tu peux régler des pages individuelles sur noindex, nofollow ou noarchive. Une erreur courante est de mettre une page en noindex pendant le développement et d'oublier de la remettre avant publication.
Les deux plugins définissent les URLs canoniques automatiquement. Des conflits d'URL canonique apparaissent quand :
- Les deux plugins sont actifs simultanément — ne fais jamais tourner deux plugins SEO en même temps
- Un plugin de cache sert une version périmée de la page avec une balise canonique obsolète
Le sitemap généré par ces plugins remplace le sitemap natif de WordPress. Si à la fois le sitemap natif (/wp-sitemap.xml) et le sitemap du plugin (/sitemap_index.xml) sont actifs, Google peut découvrir les deux et gâcher du budget de crawl à traiter des entrées en double. Yoast et RankMath désactivent tous deux le sitemap natif automatiquement, mais désactiver le plugin SEO sans supprimer sa configuration peut réactiver le sitemap natif tout en laissant des URLs de sitemap orphelines dans Google Search Console.
Le fichier .htaccess et les contrôles d'indexation au niveau serveur
Le fichier .htaccess dans la racine de ton WordPress est l'un des fichiers les plus puissants et les plus mal compris qui affectent l'indexation. WordPress y écrit ses propres règles de réécriture pour la gestion des permaliens, mais les plugins, hébergeurs et modifications manuelles peuvent ajouter des règles qui bloquent les crawlers ou créent des chaînes de redirection.
Le bloc .htaccess WordPress par défaut vérifie si le fichier ou dossier demandé existe, et sinon, route la requête vers index.php pour que WordPress la gère. Les plugins de sécurité comme Wordfence, Sucuri et iThemes Security ajoutent leurs propres règles au-dessus du bloc WordPress. Ces règles incluent parfois du blocage par IP, du rate limiting ou du filtrage par user-agent qui peut bloquer Googlebot par inadvertance. Si ton plugin de sécurité a une fonctionnalité « bloquer les user agents suspects », vérifie que la chaîne user agent de Googlebot est explicitement en liste blanche.
Les hébergeurs modifient aussi .htaccess. Les hébergeurs WordPress managés comme WP Engine, Kinsta et Flywheel ajoutent des en-têtes de cache, des règles de compression GZIP, et parfois des règles de redirection pour leur CDN. C'est généralement bien, mais si ton hôte force le HTTPS via .htaccess et que tes réglages WordPress référencent encore des URLs HTTP, tu obtiens une chaîne de redirection :
- 1HTTP vers HTTPS (via
.htaccess) - 2Normalisation www/non-www (via WordPress)
Chaque redirection dans la chaîne coûte du budget de crawl et ajoute de la latence.
Pour auditer ton .htaccess, télécharge-le via SFTP ou ton gestionnaire de fichiers d'hébergement et passe en revue chaque bloc de règles. Cherche :
- Des règles
Deny from allqui pourraient bloquer des dossiers entiers - Des patterns
RewriteRulequi redirigent les user agents de crawlers - Des directives
Header set X-Robots-Tagqui ajoutent noindex au niveau serveur
L'en-tête X-Robots-Tag est particulièrement sournois parce qu'il n'apparaît pas dans le source de ta page — tu peux seulement le voir dans les en-têtes de réponse HTTP en utilisant curl ou les devtools du navigateur.
Conflits de plugins et problèmes de thème qui bloquent l'indexation
L'architecture de plugins de WordPress signifie que n'importe quel plugin installé peut modifier les en-têtes HTTP, injecter des balises meta, altérer robots.txt ou changer ton sitemap. Les conflits qui cassent l'indexation les plus courants impliquent :
Les plugins de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache) servant du HTML périmé contenant des balises meta robots ou des URLs canoniques obsolètes. Quand tu changes une page de noindex à index, la version cachée peut continuer à servir la balise noindex jusqu'à ce que le cache soit purgé. Purge toujours ton cache de page complet après chaque changement lié au SEO.
Les plugins de membres et de paywall (MemberPress, Restrict Content Pro, WooCommerce Memberships) qui enveloppent le contenu dans des vérifications d'authentification. Si le plugin cache le contenu derrière une connexion sans fournir de fallback pour les utilisateurs anonymes, Googlebot voit soit un formulaire de connexion soit du contenu vide. Certains plugins de membres ont une option « Afficher l'extrait aux moteurs de recherche » — active-la pour que Google puisse indexer un snippet significatif.
Les plugins de constructeur de pages stockent le contenu dans des formats de base de données personnalisés que la fonction the_content() par défaut de WordPress ne sort pas. Elementor stocke ses données de mise en page en post meta et les rend via JavaScript. Si les fichiers CSS et JS d'Elementor sont bloqués dans robots.txt, Google ne peut pas rendre la page et indexe une mise en page vide. La même chose s'applique à Divi, Beaver Builder et WPBakery. Vérifie l'outil Inspection de l'URL de Google Search Console et clique sur « Voir la page explorée » pour voir exactement ce que Googlebot rend.
Les thèmes peuvent aussi interférer. Certains thèmes incluent leurs propres fonctionnalités SEO — champs de meta description, balises Open Graph, ou même générateurs de sitemap — qui entrent en conflit avec ton plugin SEO. Les balises meta générées par le thème peuvent créer des balises title et description en double dans ton head HTML. Inspecte le source de ta page et cherche des <meta name="description"> ou <meta name="robots"> en double. Si ton thème ajoute les siens, désactive cette fonctionnalité dans les réglages du thème ou change de thème.
WordPress REST API et optimisation du budget de crawl
La REST API de WordPress expose ton contenu à /wp-json/wp/v2/posts, /wp-json/wp/v2/pages et endpoints similaires. Bien que ces endpoints ne soient pas destinés à la consommation par les moteurs de recherche, ils apparaissent parfois dans l'index de Google s'ils sont liés depuis ton sitemap, le JavaScript de ton thème ou des sources externes. Les réponses REST API renvoient du JSON, pas du HTML, donc les URLs API indexées s'affichent comme des données brutes dans les résultats de recherche.
Pour empêcher les URLs de la REST API d'être indexées, ajoute un en-tête X-Robots-Tag: noindex aux réponses de la REST API. Tu peux faire ça avec un petit snippet de code dans le functions.php de ton thème ou un plugin personnalisé. Certains plugins SEO gèrent ça automatiquement, mais vérifie en visitant une URL REST API et en vérifiant les en-têtes de réponse.
Le budget de crawl est une vraie préoccupation pour les gros sites WordPress. Si tu as des milliers d'articles, plus des archives d'étiquettes, d'archives de catégories, d'archives de dates, d'archives d'auteurs et des versions paginées de toutes ces archives, Google doit explorer des dizaines de milliers d'URLs. Beaucoup de ces pages d'archives ont du contenu pauvre. Mets ce qui suit en noindex dans les réglages de ton plugin SEO :
- Archives d'étiquettes — contiennent souvent seulement 1-2 articles
- Archives de dates — mois où tu n'as publié qu'une fois
- Archives d'auteurs — inutiles sur les blogs à un seul auteur
Cela concentre le budget de crawl sur ton vrai contenu.
WordPress génère des URLs de flux à /feed/, /comments/feed/ et des flux par catégorie et par étiquette. Ce sont des mécanismes de découverte valides et ils devraient rester crawlables, mais ils ne devraient pas être indexés. La plupart des plugins SEO ajoutent noindex aux réponses de flux par défaut. Vérifie en visitant /feed/ et en cherchant une directive noindex dans l'en-tête XML.
Enfin, considère le temps de réponse de ton site. WordPress sur hébergement mutualisé avec beaucoup de plugins actifs a souvent un Time to First Byte (TTFB) de 2-4 secondes. Googlebot interprète les réponses lentes comme un signal que le serveur est surchargé et réduit son taux de crawl. Utilise du cache au niveau serveur (cache d'objet Redis ou Memcached, cache de page via ton hébergeur) pour faire passer le TTFB sous 500 ms. Cela à lui seul peut augmenter dramatiquement le nombre de pages que Google explore par jour.
Guide étape par étape
Vérifie que la case « Demander aux moteurs de recherche de ne pas indexer » est décochée
Connecte-toi à ton tableau de bord d'administration WordPress et va dans Réglages > Lecture. Descends jusqu'à la section « Visibilité par les moteurs de recherche ».
La case intitulée « Demander aux moteurs de recherche de ne pas indexer ce site » doit être décochée sur les sites de production. Si elle est cochée, décoche-la et clique sur Enregistrer les modifications.
Cette seule case contrôle une directive noindex au niveau du site qui empêche complètement Google d'indexer toute page de ton site. Après l'avoir décochée, regarde le source de ta page et confirme que <meta name="robots" content="noindex, nofollow"> n'apparaît plus dans la section <head>.
Configure les réglages de sitemap et d'indexation de ton plugin SEO
Yoast SEO : Va dans Réglages > Types de contenus et active « Afficher dans les résultats de recherche » pour les Articles et les Pages. Sous Catégories et étiquettes, indexe les catégories mais envisage de mettre les étiquettes en noindex.
RankMath : Va dans Sitemap Settings et active chaque type de contenu. Dans Titles & Meta, vérifie qu'aucun type de contenu n'a son Robots Meta réglé sur noindex.
Visite /sitemap_index.xml dans un navigateur et confirme qu'il charge un XML valide pointant vers ton contenu.
Définis la structure de permalien optimale et mets en place les redirections
Va dans Réglages > Permaliens et sélectionne « Nom de l'article » comme structure de permalien. Cela crée des URLs comme tondomaine.com/titre-de-ton-article/ qui sont propres, riches en mots-clés et faciles à analyser pour Google.
Si tu changes depuis une structure différente sur un site existant :
- 1Installe le plugin Redirection avant de faire le changement
- 2Change la structure de permalien et enregistre
- 3Le plugin Redirection enregistrera automatiquement les erreurs 404 des anciennes URLs
- 4Mets en place des règles de redirection des anciens patterns vers les nouveaux
Par exemple, si ton ancienne structure était /%year%/%monthnum%/%postname%/, crée une redirection regex de ^/\d{4}/\d{2}/(.+)$ vers /$1 pour préserver l'équité des liens.
Audite robots.txt et .htaccess pour repérer les blocages de crawler
Visite tondomaine.com/robots.txt et vérifie qu'il n'y a pas de règle Disallow: / et que l'URL de ton sitemap est listée avec une directive Sitemap:.
Télécharge .htaccess via SFTP et vérifie qu'il n'y a pas de règles de blocage par user-agent, de restrictions IP affectant la plage 66.249.x.x de Google, ni d'en-têtes X-Robots-Tag provenant de plugins de sécurité. Si tu trouves des règles suspectes, désactive les plugins de sécurité un par un pour identifier la source.
Soumets ton sitemap à Google Search Console
Connecte-toi à Google Search Console et sélectionne ta propriété WordPress. Va dans Sitemaps dans la barre latérale gauche et entre l'URL de ton sitemap :
/sitemap_index.xmlsi tu utilises Yoast ou RankMath/wp-sitemap.xmlsi tu utilises le sitemap natif de WordPress
Clique sur Envoyer. Google va commencer à traiter le sitemap, ce qui prend généralement 24-48 heures pour la lecture initiale.
Après la soumission, surveille le rapport Sitemaps pour les erreurs courantes :
- URLs renvoyant 404 (articles supprimés encore dans le sitemap)
- URLs bloquées par robots.txt
- URLs avec des chaînes de redirection
Le rapport Pages te montrera combien d'URLs soumises ont été indexées, exclues ou ont eu des erreurs.
Teste le rendu de la page avec l'Inspection d'URL
Dans Google Search Console, utilise Inspection de l'URL sur tes pages les plus importantes. Clique sur « Tester l'URL en direct » et vérifie que la réponse HTTP est 200, que le statut d'indexation montre que l'URL peut être indexée, et que la capture d'écran rendue sous « Voir la page explorée » correspond à ton navigateur.
Si la page rendue montre du contenu manquant ou des sections vides, tu as un problème de rendu JavaScript dû à des ressources bloquées ou des conflits de constructeur de page.
Utilise IndexBolt pour accélérer l'indexation des pages restantes
Après avoir terminé tous les correctifs techniques ci-dessus, certaines pages peuvent encore prendre des semaines à être indexées via le cycle de crawl naturel de Google, surtout sur les sites WordPress plus récents ou à plus faible autorité.
Utilise IndexBolt pour soumettre ces URLs directement à l'indexation :
- 1Exporte les URLs de ton sitemap (trouve-les dans ton
sitemap_index.xmlen cliquant sur chaque sous-sitemap) - 2Colle-les dans le formulaire de soumission d'IndexBolt
- 3Laisse notre API les pousser à travers le pipeline d'indexation Google
Pour le contenu sensible au temps comme les nouvelles pages produits, les annonces d'événements ou les actualités, utilise l'indexation instantanée d'IndexBolt pour sauter la file d'attente et faire indexer les pages en heures plutôt qu'en jours.
Problèmes courants et comment les résoudre
La case « Demander aux moteurs de recherche de ne pas indexer » est encore cochée
Cause : Cette case dans Réglages > Lecture a été activée pendant le développement ou la migration du site et n'a jamais été désactivée. Certains hébergeurs l'activent par défaut sur les environnements de staging, et elle persiste quand tu pousses le staging en production. Les installateurs WordPress automatisés des panneaux d'hébergement la laissent parfois cochée aussi.
Solution : 1. Va dans **Réglages > Lecture**, décoche **« Demander aux moteurs de recherche de ne pas indexer ce site »**, et clique sur **Enregistrer les modifications** 2. Visite le code source de ta page d'accueil et confirme que la balise meta **noindex** a disparu 3. Vérifie `robots.txt` (`tondomaine.com/robots.txt`) pour confirmer qu'il ne contient plus `Disallow: /` 4. **Vide le cache de ton plugin de cache** après ce changement pour que le HTML mis à jour soit servi immédiatement
Un plugin SEO met en noindex un type de contenu ou une taxonomie entière
Cause : Dans Yoast SEO, le bouton « Afficher dans les résultats de recherche » sous Réglages > Types de contenus a été désactivé pour un type de contenu. Dans RankMath, le Robots Meta d'un type de contenu a été défini à noindex sous Titles & Meta. Cela ajoute une directive noindex à chaque page de ce type et les retire du sitemap, même si des articles individuels ont du contenu de valeur.
Solution : Ouvre les réglages de ton plugin SEO et passe en revue chaque type de contenu et taxonomie. - **Yoast :** Va dans **Réglages > Types de contenus** et active **« Afficher dans les résultats de recherche »** pour chaque type que tu veux indexer - **RankMath :** Va dans **Titles & Meta > Post Types** et règle le Robots Meta sur **« index »** Après le changement, régénère ton sitemap en le visitant dans un navigateur et confirme que les URLs affectées apparaissent maintenant. **Resoumets le sitemap** dans Google Search Console.
Le changement de structure de permaliens a causé des erreurs 404 en masse
Cause : Changer la structure de permaliens dans Réglages > Permaliens met à jour tous les liens internes mais ne crée pas de redirections pour les anciens patterns d'URL. Tous les liens externes, marque-pages ou URLs précédemment indexées pointant vers l'ancienne structure renvoient maintenant des erreurs 404. Google va éventuellement désindexer ces pages.
Solution : 1. Installe le plugin **Redirection** (ou utilise directement ton `.htaccess`) pour créer des **redirections 301** basées sur des patterns, de l'ancienne structure d'URL vers la nouvelle 2. Si ton ancienne structure était `/%category%/%postname%/`, crée une redirection mappant les anciennes URLs vers la nouvelle structure `/%postname%/` 3. Surveille les **erreurs 404** dans le rapport Pages de Google Search Console 4. Ajoute des redirections individuelles pour les URLs que la règle basée sur pattern a manquées Avec le temps, Google mettra à jour son index pour refléter la nouvelle structure d'URL.
Plusieurs plugins génèrent des sitemaps conflictuels
Cause : Faire tourner deux plugins SEO simultanément (par exemple, Yoast et RankMath), ou avoir un plugin SEO en plus d'un plugin de sitemap dédié comme Google XML Sitemaps, crée plusieurs fichiers de sitemap. Si robots.txt ou Google Search Console référencent les deux sitemaps, Google traite des entrées URL en double et peut les détecter comme suspectes. Certains plugins tout-en-un de sécurité comme All In One WP Security génèrent aussi leurs propres sitemaps.
Solution : **N'utilise qu'un seul plugin pour la génération de sitemap.** Si tu utilises Yoast ou RankMath, désactive ou supprime tout plugin de sitemap autonome. 1. Vérifie `robots.txt` pour des lignes `Sitemap:` multiples et supprime les doublons 2. Dans Google Search Console, va dans **Sitemaps** et supprime toute soumission obsolète ou en double 3. Vérifie que le sitemap natif de WordPress à `/wp-sitemap.xml` est désactivé par ton plugin SEO (Yoast et RankMath le font tous deux automatiquement quand ils sont actifs)
Le plugin de cache sert des pages noindex périmées
Cause : Tu as changé une page de noindex à index (ou corrigé n'importe quel problème de balise meta), mais ton plugin de cache (WP Rocket, W3 Total Cache, LiteSpeed Cache, etc.) sert encore le vieux HTML mis en cache contenant la directive noindex. Les caches de page peuvent persister pendant des heures ou des jours selon ta configuration.
Solution : **Purge ton cache de page entier** après chaque changement lié au SEO : - **WP Rocket :** Réglages > WP Rocket > **« Vider le cache »** - **W3 Total Cache :** Performance > Dashboard > **« Empty All Caches »** - **LiteSpeed Cache :** LiteSpeed Cache > Toolbox > **« Purge All »** Si tu utilises un CDN comme **Cloudflare**, purge aussi le cache CDN depuis le tableau de bord Cloudflare. Après la purge, vérifie en visitant la page dans une **fenêtre de navigation privée** et en regardant le source pour confirmer que les bonnes balises meta sont présentes.
Un thème lourd et un constructeur de pages ralentissent le taux de crawl
Cause : Les thèmes WordPress complexes avec de gros bundles CSS/JS et les constructeurs de pages comme Elementor ou Divi augmentent significativement le temps de chargement des pages. Quand le Time to First Byte dépasse 2 secondes, Googlebot réduit son taux de crawl pour éviter de surcharger ton serveur. Sur de l'hébergement mutualisé, ça peut faire chuter ton volume de crawl quotidien de centaines de pages à seulement quelques dizaines.
Solution : Active le **cache côté serveur** pour améliorer les temps de réponse : 1. Installe un plugin de cache et configure-le pour le **cache de page complète** 2. Utilise un **cache d'objet** (**Redis** ou **Memcached**) si ton hôte le supporte 3. **Minifie et combine** les fichiers CSS/JS via ton plugin de cache 4. Envisage de passer à un hébergeur WordPress managé (**WP Engine**, **Kinsta**, **Cloudways**) qui inclut le cache au niveau serveur et un CDN Vérifie ton taux de crawl dans Google Search Console sous **Paramètres > Statistiques sur l'exploration**, qui montre les requêtes de crawl quotidiennes, la taille de téléchargement et les temps de réponse.
Astuces pro
Les sites WordPress peuvent avoir des centaines ou des milliers de pages qui attendent que Google les découvre. IndexBolt te permet de soumettre tes URLs WordPress directement à l'indexation, en évitant l'attente du prochain crawl de Googlebot. Que tu viennes de corriger un problème noindex ou que tu aies publié un lot de nouveaux articles, fais-les entrer dans l'index Google en heures plutôt qu'en semaines.
100 crédits gratuits. Aucune carte bancaire requise. Résultats en moins de 24 heures.
Questions fréquentes
Combien de temps faut-il à Google pour indexer une nouvelle page WordPress ?+
Pour les **sites WordPress établis** avec de bons taux de crawl, les nouvelles pages apparaissent généralement dans Google en **2 à 7 jours** après publication. Pour les **sites plus récents** ou les sites à faible autorité de domaine, cela peut prendre **2 à 6 semaines**. Si ta page n'est pas indexée après 4 semaines, il y a probablement un problème technique qui bloque l'exploration ou l'indexation. Utiliser **IndexBolt** peut réduire ce délai à des **heures** pour les pages urgentes.
Dois-je utiliser le sitemap natif de WordPress ou celui de mon plugin SEO ?+
Utilise le **sitemap de ton plugin SEO** si tu as Yoast SEO ou RankMath installé. Ces plugins génèrent des sitemaps plus complets avec un meilleur contrôle sur les types de contenus inclus, et ils **désactivent automatiquement le sitemap natif** pour éviter les doublons. Le sitemap natif de WordPress à `/wp-sitemap.xml` est adéquat pour les sites simples sans plugin SEO, mais il manque des contrôles granulaires que Yoast et RankMath fournissent.
Puis-je avoir trop de pages dans mon sitemap WordPress ?+
Un seul fichier sitemap peut contenir jusqu'à **50 000 URLs** selon la spec du protocole sitemap. Yoast et RankMath divisent tous deux les gros sitemaps en sous-sitemaps de **1 000 URLs** chacun (configurable). La vraie préoccupation n'est pas la taille du sitemap mais la **qualité des URLs** qu'il contient. Si ton sitemap contient des milliers de pages d'archives pauvres, de pages d'étiquettes avec un seul article, ou d'URLs paginées, le **budget de crawl** de Google est gaspillé sur des pages de faible valeur. Garde ton sitemap allégé en **mettant en noindex les types de contenus pauvres**.
Changer mon thème WordPress affecte-t-il mes classements Google ?+
Changer de thème peut **absolument affecter l'indexation et les classements**. Un nouveau thème peut : - Modifier ta **structure de page** et la **hiérarchie des titres** - Modifier les **patterns de liens internes** - Ajouter ou supprimer des **données structurées** - Introduire un comportement différent de **rendu JavaScript** Si le nouveau thème est plus lent ou utilise beaucoup de JavaScript, Google peut explorer et indexer tes pages moins efficacement. **Teste toujours un changement de thème sur un site de staging d'abord** et surveille de près le rapport Pages de Google Search Console après le changement.
Pourquoi mes pages d'étiquettes WordPress apparaissent comme « Découverte, actuellement non indexée » ?+
Google classe fréquemment les pages d'archives d'étiquettes comme **faible valeur** parce qu'elles contiennent les mêmes extraits d'articles qui apparaissent sur d'autres pages d'archives (pages de catégories, pages d'auteurs, page d'accueil du blog). Quand Google détermine qu'une page n'apporte pas de valeur unique, il découvre l'URL mais **choisit de ne pas l'indexer**. La meilleure pratique est de **mettre en noindex les archives d'étiquettes** dans les réglages de ton plugin SEO, sauf si tes étiquettes ont un contenu unique substantiel. Cela aide en fait tes pages importantes à être indexées plus vite en **concentrant le budget de crawl**.
Mon site WordPress utilise un constructeur de pages. Est-ce que ça affecte l'indexation ?+
Les constructeurs de pages comme **Elementor**, **Divi** et **WPBakery** stockent le contenu dans leur propre format et le rendent via JavaScript sur le frontend. Google peut rendre le JavaScript mais le fait dans une **deuxième passe différée**, ce qui signifie que les pages construites avec des constructeurs de pages peuvent prendre plus de temps à être complètement indexées. Plus important, si ton `robots.txt` bloque les fichiers CSS ou JS du constructeur de pages (certains plugins de sécurité font ça), Google **ne peut pas rendre la page du tout** et peut indexer une mise en page vide. Teste avec l'outil **Inspection de l'URL** de Google Search Console pour vérifier que Google voit la page entièrement rendue.