Crawl et indexation
Rien d’autre sur cette liste ne compte si Google ne peut ni récupérer ni indexer la page. Ces actions viennent en premier parce qu’elles sont la porte : une page bloquée, prise dans une boucle de redirections ou enterrée derrière un paramètre n’entre jamais en compétition, aussi bonne soit-elle.
Pourquoi ce module existe
Commencez ici, toujours. Une seule ligne mal placée dans le robots.txt peut annuler une année de travail éditorial.
Module A 20 actions n° 1 à 20 sur 410
-
001
Générer un sitemap XML, découpé à 50 000 URLs / 50 Mo par fichier, et les indexer dans un sitemap_index.xml
- Comment
- Choisissez la source de votre sitemap. WordPress : Yoast ou Rank Math. Next.js : next-sitemap. Statique (Hugo/Astro/Jekyll) : un générateur à l’étape de build. Sur mesure : un script qui interroge la base de votre CMS.
- Générez les fichiers sitemap. Découpez à 50 000 URLs ou 50 Mo non compressés, au premier des deux atteint. La plupart des sites n’y arrivent jamais — de 10 000 à 100 000 URLs, un seul fichier suffit.
- Générez un sitemap_index.xml qui liste tous vos fichiers sitemap. Exemple : <?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>https://votresite.com/sitemap-1.xml</loc> <lastmod>2026-08-16</lastmod> </sitemap> </sitemapindex>
- Placez les fichiers à la racine du site : /sitemap.xml et /sitemap_index.xml. Les deux doivent être servis avec Content-Type: application/xml.
- Référencez-le dans le robots.txt : Sitemap: https://votresite.com/sitemap_index.xml
- Soumettez l’URL du sitemap_index dans la Search Console → Sitemaps. Revenez 24 à 48 h plus tard voir le nombre d’« URLs découvertes ».
- À éviter
- Y inclure /admin/, /cart/, les résultats de recherche interne, les pages paginées ou les variantes ?utm_source=
- Générer un seul fichier massif de 200 000 URLs sans le découper (Google ne traitera que les 50 000 premières)
- Servir le sitemap avec Content-Type: text/html au lieu de application/xml
- Oublier de mettre à jour le sitemap à la publication (la plupart des extensions CMS s’en chargent ; les builds sur mesure souvent pas)
- Vérifier
- Ouvrez https://votresite.com/sitemap.xml dans un navigateur — il doit s’afficher en XML brut, pas en HTML
- Validez avec le validateur xml-sitemaps.com ou xmllint --noout sitemap.xml
- Vérifiez la Search Console → Sitemaps 24 à 48 h après la soumission : les « URLs découvertes » doivent être > 0 et augmenter
-
002
Renseigner <lastmod> dans le sitemap avec la vraie date de dernière modification du contenu (pas l’heure de build) ; Google s’en sert comme signal de fraîcheur et de crawl
- Comment
- Identifiez le champ de votre CMS qui contient le vrai horodatage de dernière édition. WordPress : post_modified (et non post_date ). Sanity : _updatedAt. Contentful : sys.updatedAt. Sites statiques avec frontmatter : le champ updated:.
- Branchez votre générateur de sitemap sur ce champ. Exemple en Node.js : const pages = await db.query('SELECT slug, updated_at FROM posts WHERE status = ?', ['published']); for (const p of pages) { sitemap.push({ loc: `https://votresite.com/${p.slug}`, lastmod: p.updated_at.toISOString().split('T')[0] // AAAA-MM-JJ }); }
- Ne mettez à jour <lastmod> que lors d’un vrai changement de contenu. Pas pour un commentaire ajouté, un widget de barre latérale modifié ou une correction typographique. Google dévalue en quelques semaines un <lastmod> mis à jour à chaque build.
- Pour les pages sans modification réelle depuis des années, mettez <lastmod> à la date de publication et n’y touchez plus. Un <lastmod> stable est plus utile qu’un motif permanent « date du jour ».
- À éviter
- Utiliser l’heure de build : chaque déploiement met tous les <lastmod> au même horodatage, ce que Google dévalue en quelques semaines
- N’utiliser que la date de publication : une page très retravaillée affichant une date de 2020 dit à Google qu’elle est périmée
- Utiliser des dates futures : ça n’aide pas et peut déclencher des signaux qualité
- Oublier de mettre à jour lors de vraies éditions : le signal perd tout sens
- Vérifier
- Prenez 5 URLs d’âges différents. Vérifiez leur <lastmod> dans le sitemap.
- Modifiez-en une. Régénérez le sitemap. Vérifiez que le <lastmod> est passé à la nouvelle date d’édition.
- Ne vous attendez pas à ce que tous les <lastmod> portent la même date — s’ils le font, vous utilisez l’heure de build et non celle du contenu.
-
003
Ne lister dans le sitemap que des URLs en 200, canoniques et indexables — ni redirections, ni 404, ni noindex, ni URLs à paramètres
- Comment
- Avant de générer le sitemap, filtrez votre liste d’URLs. Excluez : les URLs portant <meta name="robots" content="noindex">
- les URLs avec un en-tête HTTP X-Robots-Tag: noindex
- les URLs dont la canonical pointe vers une autre URL
- les URLs répondant en 3xx, 4xx ou 5xx
- les URLs à paramètres (?id=, ?utm_source=) sauf si ce sont les versions canoniques indexables
- les URLs de pagination (/blog?page=2) — une seule URL canonique par contenu
- · Sous WordPress, servez-vous des réglages « Exclure » de Yoast. Pour un build sur mesure, filtrez dans le générateur : const indexable = pages.filter(p => p.status === 200 && !p.hasNoindex && p.canonical_url === p.url && !p.hasQueryParams );
- Après génération, relisez à la main 10 URLs du sitemap au hasard. Chacune doit être une page réelle, indexable et canonique.
- À éviter
- Injecter toutes les URLs de la base du CMS, brouillons, articles privés et résultats de recherche interne compris
- Inclure des URLs à paramètres qui pointent toutes en canonical vers une même URL de base (une seule est canonique, pas les autres)
- Inclure des pages 404 qui répondent quand même en 200 (soft-404)
- Inclure les vues paginées d’un même contenu (chaque ?page=N doit être exclue ou canonicalisée)
- Vérifier
- Prenez 20 URLs au hasard dans votre sitemap. Faites curl -I sur chacune. Toutes doivent répondre 200.
- Ouvrez-en 5 dans l’inspection d’URL de la Search Console. Aucune ne doit indiquer « Exclue par une balise noindex » ni « Redirigée ».
- Si la Search Console rapporte un écart important entre « URLs découvertes » et « URLs envoyées », c’est que votre sitemap contient des URLs non indexables.
-
004
Soumettre le sitemap index dans la Search Console → Sitemaps et le référencer dans le robots.txt via Sitemap:
- Comment
- Ouvrez la Search Console → Sitemaps (barre latérale gauche). Collez l’URL de votre index de sitemaps (par exemple https://votresite.com/sitemap_index.xml ). Cliquez sur Envoyer.
- Ajoutez une ligne Sitemap: à votre robots.txt, en bas du fichier : User-agent: * Allow: / Sitemap: https://votresite.com/sitemap_index.xml
- Soumettez les sitemaps par propriété si vous avez des comptes Search Console régionaux ou par sous-domaine.
- Pour Bing, soumettez aussi dans Bing Webmaster Tools → Sitemaps.
- Revenez dans la Search Console 24 à 48 h plus tard. Le « Statut » doit être « Réussite » et les « URLs découvertes » doivent croître au fil de la semaine.
- À éviter
- Ne soumettre que le sitemap_index parent sans les fichiers sitemap individuels (la Search Console découvrira les enfants depuis l’index, mais certains moteurs non)
- Oublier de re-soumettre après un changement d’URL du sitemap (la Search Console ne re-télécharge les sitemaps soumis que périodiquement)
- Soumettre à la fois chaque sitemap individuel ET l’index, ce qui double le décompte affiché
- Vérifier
- Ouvrez la Search Console → Sitemaps. Le statut doit être « Réussite ». La date de dernier téléchargement doit être récente.
- Vérifiez le robots.txt : curl https://votresite.com/robots.txt | grep Sitemap doit renvoyer la ligne.
- Au bout d’une semaine, les « URLs découvertes » doivent représenter environ 80 à 100 % de vos URLs indexables réelles.
-
005
Servir des sitemaps d’images et de vidéos séparés (ou les extensions <image:image> / <video:video>)
- Comment
- Choisissez votre approche. Soit : Option A : des fichiers sitemap-images.xml et sitemap-videos.xml distincts
- Option B : ajouter des entrées <image:image> et <video:video> dans les blocs <url> de votre sitemap existant
- L’option B est plus simple si votre sitemap principal est déjà petit. L’option A est plus propre pour les sites riches en images ou en vidéos.
- Pour les images, chaque <image:image> a besoin d’un <image:loc> (l’URL de l’image) et, en option, de <image:title>, <image:caption>, <image:geo_location>.
- Pour les vidéos, chaque <video:video> a besoin d’un <video:thumbnail_loc>, <video:title>, <video:description>, <video:content_loc> (ou <video:player_loc>).
- Référencez-les dans le sitemap_index.xml et soumettez-les à la Search Console.
- À éviter
- Inclure des images qui ne sont pas sur la page (ne listez pas les images d’une médiathèque globale si elles n’apparaissent pas sur l’URL listée)
- Oublier la miniature — Google n’indexera pas une vidéo sans image de thumbnail valide
- Faire pointer video:content_loc vers une URL privée nécessitant une authentification pour être lue
- Ajouter des sitemaps d’images pour des photos de banque d’images sans aucune valeur SEO
- Vérifier
- Soumettez votre sitemap images/vidéos dans la Search Console. Vérifiez le nombre d’URLs « découvertes ».
- Ouvrez Google Images et cherchez un texte alternatif unique de l’une de vos images. Vérifiez que la page ressort.
- Utilisez le test des résultats enrichis de Google pour valider le schema vidéo.
-
006
Dans le robots.txt : autoriser tous les chemins indexables, interdire les chemins à facettes, à paramètres, de recherche, de panier et d’administration
- Comment
- Partez d’une base permissive : User-agent: * Allow: / Disallow: /search Disallow: /admin/ Disallow: /cart Disallow: /account/ Disallow: /*?* Sitemap: https://votresite.com/sitemap_index.xml
- Repérez les chemins qui ne doivent jamais être indexés : les résultats de recherche interne (/search?q=)
- l’administration (/admin/, /wp-admin/)
- les pages de compte (/account/, /login)
- les URLs de navigation à facettes (/products?color=red&size=large)
- les pages de résultats de la recherche interne
- le panier et le tunnel de commande
- · Utilisez Disallow: /chemin (sans slash final) pour bloquer un chemin et tout ce qu’il contient. Disallow: /chemin/ (avec slash) est fonctionnellement identique mais signale un « répertoire ».
- Ne bloquez pas les fichiers CSS et JS. Google en a besoin pour rendre correctement votre page.
- Testez avec l’outil de test du robots.txt de la Search Console.
- À éviter
- Bloquer /wp-admin/ sans vérifier si votre thème l’utilise pour des points d’entrée AJAX (vous bloquez alors de vraies fonctionnalités)
- Interdire /? pour bloquer les paramètres, ce qui peut bloquer des URLs paramétrées légitimes
- Bloquer des fichiers CSS ou JS (Google ne peut plus rendre la page correctement)
- Oublier d’autoriser le fichier sitemap lui-même (certains modèles l’interdisent par accident)
- Vérifier
- Ouvrez l’outil de test du robots.txt de la Search Console. Vérifiez que les règles s’interprètent correctement.
- Testez quelques URLs : une vraie page indexable doit être « Autorisée », une URL d’administration « Bloquée ».
- Au bout de 2 à 3 semaines, regardez la Search Console → Pages → « Explorée, actuellement non indexée ». Un pic suggère un robots.txt trop restrictif.
-
007
Auditer la couverture d’indexation chaque semaine dans la Search Console → Pages ; enquêter sur « Explorée, non indexée » et « Détectée, non indexée »
- Comment
- Ouvrez la Search Console → Pages (ou Index → Pages dans l’ancienne interface).
- Filtrez par « Pourquoi des pages ne sont pas indexées ». Regardez les trois premiers motifs par nombre d’URLs.
- Pour « Explorée, actuellement non indexée » : exportez la liste d’URLs (les 1 000 premières)
- croisez-la avec vos statistiques : ces URLs reçoivent-elles du trafic ? Si oui, ce sont des signaux qualité qui les retiennent
- ouvrez les pages elles-mêmes. Sont-elles quasi identiques à d’autres ? Sont-elles trop maigres ?
- · Pour « Détectée, actuellement non indexée » : ce sont des URLs que Google connaît (via les sitemaps ou les liens) mais qu’il n’a pas encore explorées
- normal sur un site neuf, préoccupant sur un site établi
- corrigez en améliorant le maillage interne vers ces pages, en vous assurant qu’elles sont dans le sitemap, et en réduisant le gaspillage global de budget de crawl
- · Refaites cet audit chaque semaine. Suivez les compteurs.
- À éviter
- Ignorer le rapport parce que le chiffre est « faible » (chaque URL non indexée est du trafic potentiel perdu)
- Forcer l’indexation par l’inspection d’URL sur chaque page (la Search Console applique un quota)
- Ne pas chercher la cause — le rapport dit quelles URLs sont touchées, à vous de diagnostiquer pourquoi
- Vérifier
- Prenez 5 URLs de la liste « Explorée, non indexée ». Ouvrez-les en navigation privée. Sont-elles utiles ? Sont-elles distinctes des autres pages du site ?
- Passez l’une d’elles dans l’inspection d’URL de la Search Console. Que dit Google de la version rendue ?
- Revérifiez le compteur chaque semaine. Il doit être stable ou en baisse.
-
008
Retirer les noindex accidentels (meta robots et en-tête HTTP X-Robots-Tag) des pages que vous voulez voir classées
- Comment
- Auditez vos pages les plus importantes. Utilisez un outil comme Screaming Frog en mode liste, ou écrivez un script rapide : const pages = ['/', '/about', '/product-1', ...]; for (const url of pages) { const res = await fetch(url); const meta = await res.text(); const noindex = meta.match(/<meta name="robots" content="([^"]+)">/); const xRobots = res.headers.get('X-Robots-Tag'); if (noindex?.[1].includes('noindex') || xRobots?.includes('noindex')) { console.log('NOINDEX:', url); } }
- Pour chaque page touchée, remontez à la source. Causes fréquentes : le CMS a une case « masquer aux moteurs de recherche » qui a été cochée
- le thème contient un test de mode staging qui ajoute un noindex à toutes les pages hors production (et le test est faux en production)
- un reverse proxy ou un CDN ajoute X-Robots-Tag: noindex sur certains motifs de chemins
- le .htaccess ou la configuration nginx contient une règle noindex sur un chemin précis
- · Corrigez la source. Ne vous contentez pas de retirer la balise — corrigez la configuration pour qu’elle ne revienne pas.
- Redemandez une exploration par l’inspection d’URL. Google doit repasser en quelques jours.
- À éviter
- Ne corriger que la balise sans trouver la configuration en cause (elle reviendra)
- Oublier de vérifier l’en-tête HTTP X-Robots-Tag (une source souvent négligée)
- Ne pas vérifier les environnements de préproduction (s’il y en a un, c’est lui qui doit porter le noindex)
- Vérifier
- Après correction, relancez l’audit. Toutes les pages importantes doivent renvoyer « index, follow ».
- Utilisez l’inspection d’URL de la Search Console → « Demander une indexation » sur 5 des pages les plus importantes.
- Vérifiez 7 jours plus tard : les URLs concernées doivent apparaître dans le décompte « Indexées » de la Search Console.
-
009
Crawler l’intégralité du site avec Screaming Frog ou Sitebulb ; corriger chaque 4xx et chaque 5xx
- Comment
- Procurez-vous un outil. Screaming Frog SEO Spider (gratuit jusqu’à 500 URLs) ou Sitebulb (payant, meilleurs rapports).
- Configurez : user-agent Googlebot (Smartphone)
- respect du robots.txt : activé
- suivre les liens internes en « nofollow » : désactivé (vous voulez les voir)
- limitez la profondeur ou le nombre d’URLs selon la taille du site
- · Lancez le crawl. Exportez « Response Codes » et « Client Errors ».
- Pour chaque 4xx et 5xx : 4xx (erreur client) : corrigez la page, mettez une redirection 301, ou supprimez le lien qui pointe vers elle
- 5xx (erreur serveur) : réglez le problème serveur. Google déprioritise les sites qui présentent des 5xx récurrents
- · Relancez ce crawl tous les mois. Suivez l’évolution du nombre d’erreurs.
- À éviter
- Ne le lancer qu’une fois et supposer le site propre (les erreurs reviennent)
- Ne pas regarder les 5xx — ce sont les plus dommageables, car ils signalent une instabilité du site
- Ignorer les chaînes 3xx — elles gaspillent le budget de crawl (voir l’action 10)
- Passer à côté des soft-404 (pages qui répondent 200 avec un contenu « page introuvable »)
- Vérifier
- Lancez le crawl. Vérifiez que le nombre de 4xx et de 5xx est à 0, ou tout proche.
- Pour chaque « soft-404 » détecté, renvoyez un vrai 404/410 ou ajoutez du contenu réel
- Après correction, relancez le crawl. Le compteur doit baisser. Programmez un crawl récurrent (mensuel au minimum)
-
010
Remplacer toutes les chaînes et boucles de redirections par un seul saut 301
- Comment
- Crawlez le site avec Screaming Frog ou Sitebulb. Exportez « Redirect Chains » et « Redirect Loops ».
- Pour chaque chaîne (A → B → C), décidez de la bonne correction : si A et C sont deux URLs légitimes, faites pointer A directement vers C en sautant B
- si B était une ancienne URL, redirigez A directement vers C et supprimez B, ou redirigez B vers C aussi
- chaque URL doit avoir exactement un saut 301 vers sa destination finale
- · Pour les boucles (A → B → A), cassez le cycle : identifiez l’URL « réelle »
- redirigez l’autre directement vers elle
- supprimez le code qui recrée la boucle (par exemple une règle du CMS qui ajoute un slash final, puis une autre qui l’enlève)
- · Recrawlez pour confirmer que les chaînes sont réduites à un saut.
- À éviter
- Ajouter une nouvelle redirection par-dessus une chaîne existante (la chaîne s’allonge)
- Utiliser une 302 (temporaire) pour un déplacement définitif (utilisez une 301)
- Créer des redirections meta-refresh ou JavaScript là où une 301 suffirait (Google les suit, mais plus lentement)
- Laisser des boucles en place parce que les URLs « fonctionnent quand même » (Google peut refuser de les indexer)
- Vérifier
- Recrawlez. Le rapport « Redirect Chains » doit être vide.
- Prenez 5 URLs auparavant enchaînées. Faites curl -I -L et comptez les réponses 3xx — il doit y en avoir exactement une.
-
011
Garder des en-têtes de réponse propres : une seule canonical, le bon Content-Type, un 200 pour les pages indexables
- Comment
- Testez vos pages clés. Faites curl -I https://votresite.com/ et examinez : HTTP/2 200 — bon statut
- Content-Type: text/html; charset=utf-8 — type correct pour du HTML
- Cache-Control — doit autoriser la mise en cache des ressources statiques, avec des valeurs adaptées pour le HTML
- pas de X-Robots-Tag: noindex (sauf intention)
- · Pour les pages indexables, renvoyez 200 OK. Pour les redirections, 301 Moved Permanently. Pour l’introuvable, 404 Not Found (ou 410 Gone pour un contenu définitivement retiré).
- Ne renvoyez pas 200 pour les URLs paginées, à facettes ou filtrées. Utilisez une canonical, un noindex, ou bloquez-les via le robots.txt.
- Vérifiez que votre CDN ou votre reverse proxy n’ajoute pas d’en-têtes contradictoires.
- À éviter
- Renvoyer 200 pour une soft-404 (une page qui affiche « introuvable » mais répond en 200)
- Servir du HTML avec Content-Type: text/plain (certains CDN le font pour des fichiers statiques servis depuis la mauvaise origine)
- Ajouter des en-têtes no-cache qui empêchent Google de mettre votre HTML en cache (gaspillage de budget de crawl)
- Vérifier
- Faites curl -I sur 10 pages importantes. Vérifiez le 200, le bon type de contenu, l’absence de X-Robots-Tag parasite.
- Lancez un crawl Screaming Frog avec le filtre « Response Codes » sur 200 — relisez à la recherche de motifs de soft-404.
-
012
Vérifier que Googlebot rend bien le contenu JavaScript : Search Console → inspection d’URL → afficher le HTML généré ; le contenu principal doit être dans le DOM
- Comment
- Ouvrez la Search Console → inspection d’URL. Collez une URL dont le contenu est rendu en JavaScript. Cliquez sur « Afficher le HTML testé ».
- Vérifiez que votre contenu principal (h1, texte, liens internes) est présent dans le HTML rendu, et pas seulement dans le HTML non traité.
- S’il manque du contenu : passez en rendu côté serveur plutôt qu’en rendu côté client
- ou pré-rendez avec Puppeteer/Playwright à l’étape de build
- ou utilisez un service de dynamic rendering pour les crawlers (moins recommandé)
- · Pour Next.js : utilisez getServerSideProps ou la génération statique. Évitez le chargement de données dans un useEffect côté client pour du contenu à indexer.
- Testez avec le test d’optimisation mobile de Google (déprécié, mais des outils équivalents existent).
- À éviter
- Montrer à Google les 200 premières millisecondes de HTML et ne charger le vrai contenu qu’en JavaScript (Google peut ne pas attendre)
- Bloquer les fichiers CSS/JS à Googlebot dans le robots.txt (Google ne peut pas rendre la page sans eux)
- Faire porter le contenu par un état client lourd (le contenu indexable doit être rendu côté serveur)
- Vérifier
- Pour 5 pages importantes, regardez « Afficher le HTML testé » dans l’inspection d’URL. Le contenu doit y être.
- Ouvrez les DevTools de Chrome → désactivez JavaScript → rechargez la page. Ce que vous voyez est ce que Google voit lors de la première vague.
-
013
Rendre le contenu principal côté serveur ou le pré-rendre ; ne pas dépendre d’un clic ou d’un scroll pour injecter le texte à indexer
- Comment
- Choisissez entre SSG, SSR et ISR : SSG (statique) : idéal pour un contenu qui change rarement (articles, documentation, pages marketing). Généré au déploiement. Exemples : Next.js avec getStaticProps, Gatsby, Astro, Hugo, Jekyll.
- SSR (rendu serveur) : pour un contenu qui doit être frais au moment de la requête (tableaux de bord, données temps réel). Exemple : Next.js avec getServerSideProps.
- ISR (régénération statique incrémentale) : du SSG avec revalidation à la demande. Le meilleur des deux pour les gros sites de contenu. Next.js le gère nativement.
- · En SSG, pré-rendez à l’étape de build. Assurez-vous que votre pipeline génère un vrai fichier HTML par URL.
- En SSR, rendez la page côté serveur avec les vraies données. Ne servez pas une coquille que le JavaScript remplit ensuite.
- Vérification : curl https://votresite.com/page | grep "votre contenu principal" doit trouver des correspondances.
- À éviter
- Prétendre faire du SSR mais ne livrer qu’une coquille <div id="root"></div> sans contenu
- Utiliser le rendu client pour du contenu critique en SEO (accueil, articles, fiches produit)
- Ne pas traiter les erreurs d’hydratation (la page s’affiche différemment une fois le JS chargé)
- Supposer que le rendu client suffit pour Google (il peut marcher, mais il est plus lent à indexer et plus facile à casser)
- Vérifier
- Affichez le code source de vos pages clés. Le contenu principal doit être dans le HTML, pas seulement dans une balise script ou chargé après.
- Faites un curl depuis un serveur (sans JS) — si vous voyez le contenu, vous êtes en SSR/SSG.
- Regardez le HTML rendu dans l’inspection d’URL de la Search Console pour quelques pages.
-
014
Garder des URLs courtes, en minuscules, séparées par des tirets, statiques et porteuses de mots-clés ; pas de ?id=, pas d’identifiants de session, pas de majuscules
- Comment
- Fixez les règles d’URL de votre site : minuscules uniquement — configurez le serveur pour passer les URLs en minuscules (ou faites une 301 des majuscules vers les minuscules)
- séparez les mots par des tirets, pas des underscores : /tshirt-coton-bleu et non /tshirt_coton_bleu
- évitez les identifiants de session, d’utilisateur ou les paramètres internes dans les URLs
- gardez l’URL totale sous 75 à 100 caractères quand c’est possible
- incluez un mot-clé principal : /seo/schema-markup plutôt que /articles/12345
- · Pour les URLs existantes mal formées, mettez des redirections 301 vers la version propre. Ne cassez jamais une URL déjà indexée sans redirection.
- Sous WordPress, allez dans Réglages → Permaliens → Titre de la publication. Configurez le système pour imposer ces règles.
- Pour une application sur mesure, ajoutez une validation d’URL dans la couche de routage qui rejette les mauvais motifs en 404.
- À éviter
- Utiliser des underscores : Google les traite comme faisant partie d’un même mot, pas comme des séparateurs
- Mettre la date dans l’URL d’un contenu intemporel (vous obligera soit à rediriger plus tard, soit à assumer la date)
- Rendre les URLs sensibles à la casse — /Page et /page sont deux URLs différentes pour Google
- Utiliser ?id=12345 pour tout (le pire cas, aussi bien pour le SEO que pour le partage)
- Vérifier
- Prenez 20 URLs de votre site. Vérifiez : en minuscules ? séparées par des tirets ? courtes ? sans paramètres ?
- Testez une URL avec des majuscules : https://votresite.com/Nom-De-Page doit faire une 301 vers /nom-de-page
- Cherchez dans la Search Console les URLs à paramètres parmi les plus indexées — ce sont en général celles à nettoyer
-
015
Optimiser le budget de crawl : renvoyer 304 Not Modified sur les pages inchangées ; garder un TTFB bas pour que Googlebot explore davantage
- Comment
- Vérifiez d’abord que le budget de crawl est vraiment un problème. Search Console → Paramètres → Statistiques d’exploration. Regardez : les requêtes par jour (votre rythme d’exploration)
- le temps de téléchargement d’une page (plus bas est mieux — sous 200 ms, c’est excellent)
- le total d’octets téléchargés par jour
- le taux d’« Explorée, non indexée » (un taux élevé = budget gaspillé)
- · Optimisez si nécessaire : renvoyez 304 Not Modified sur les pages inchangées. Configurez votre serveur pour prendre en charge l’en-tête If-Modified-Since et répondre 304 quand il le faut
- réduisez le TTFB (Time To First Byte) — des réponses plus rapides permettent à Googlebot d’explorer plus d’URLs par seconde
- supprimez les soft-404 et le contenu maigre (ils gaspillent du budget sur des URLs qui ne se classeront pas)
- bloquez les espaces infinis via le robots.txt (calendriers, recherche interne, navigation à facettes)
- · Revérifiez les statistiques d’exploration chaque mois.
- À éviter
- Optimiser le budget de crawl sur un petit site où ce n’est pas un enjeu (effort perdu)
- Bloquer les CSS/JS à Googlebot (Google en a besoin pour le rendu)
- Ajouter la gestion des 304 mais laisser le serveur renvoyer 200 quand même (bug serveur)
- Vérifier
- Regardez la Search Console → Paramètres → Statistiques d’exploration. Observez la tendance sur les 90 derniers jours.
- Faites curl -I -H "If-Modified-Since: [date récente]" sur quelques pages. Elles doivent renvoyer 304 si rien n’a changé.
- Mesurez le TTFB avec WebPageTest ou GTmetrix. Visez moins de 200 ms.
-
016
Piloter la priorité par <lastmod> ; pinguer IndexNow (Bing) et utiliser l’inspection d’URL → Demander une indexation pour les pages clés nouvelles ou mises à jour
- Comment
- Pour une page clé nouvelle ou substantiellement mise à jour : ouvrez la Search Console → inspection d’URL → collez l’URL → « Demander une indexation »
- Google la met en file pour une réexploration rapide (de quelques heures à quelques jours selon l’autorité du site)
- · Pour IndexNow : générez une clé d’API une fois : openssl rand -hex 16
- hébergez un fichier {clé}.txt à l’adresse https://votresite.com/{clé}.txt contenant la clé
- à chaque URL nouvelle ou mise à jour, soumettez : curl "https://api.indexnow.org/indexnow?url=https://votresite.com/nouvelle-page&key=VOTRE_CLE"
- · N’abusez pas de la demande d’indexation. La Search Console applique un quota par propriété. Réservez-la à vos 5 à 10 pages les plus importantes par semaine, pas à toutes.
- Vérification : après quelques heures, l’URL doit apparaître comme « Explorée » dans l’inspection d’URL.
- À éviter
- Demander l’indexation de toutes les pages du site (la Search Console vous limitera)
- Demander l’indexation de pages qui ne sont pas réellement nouvelles (Google le remarque et peut ralentir vos demandes suivantes)
- Oublier de brancher <lastmod> sur les vraies dates de contenu (voir l’action 2) — sans ça, la demande d’indexation n’a aucun signal de fraîcheur sur lequel s’appuyer
- Vérifier
- Après une demande d’indexation, l’URL doit apparaître « Explorée » dans l’inspection d’URL en quelques heures sur un site à forte autorité
- Surveillez la Search Console → Pages la semaine suivante : l’URL demandée doit rejoindre le décompte « Indexées »
- Pour IndexNow, regardez la réponse de la commande curl — un 200 signifie que l’URL a été acceptée
-
017
Corriger les soft-404 (pages maigres ou vides répondant 200) ; renvoyer un vrai 404/410 pour le contenu disparu
- Comment
- Repérez les soft-404. Lancez un crawl avec Screaming Frog ou utilisez la Search Console → Pages filtrée sur « Soft 404 ».
- Pour chaque soft-404, choisissez la bonne correction : la page a réellement disparu : renvoyez un vrai 404 Not Found (ou 410 Gone si le retrait est définitif). Configurez votre serveur ou votre CMS pour ça.
- la page existe mais est vide ou maigre : ajoutez du contenu réel et unique. L’URL a une raison d’être — honorez-la.
- la page était un résultat de recherche ou une vue filtrée : bloquez-la via le robots.txt ou un noindex, ne la passez pas en 404 (c’est peut-être une vraie URL de filtre)
- · Sous WordPress : n’utilisez pas une extension de « page 404 » qui renvoie 200 avec un gabarit 404. Renvoyez un vrai 404.
- Pour une application sur mesure : configurez votre gestionnaire d’erreurs pour renvoyer le bon code. Gabarit 404 = statut 404.
- À éviter
- Renvoyer 200 avec un gabarit « Page introuvable » (l’erreur de soft-404 la plus courante)
- Renvoyer 404 pour des URLs qui devraient être réelles (résultats de recherche, vues filtrées, index paginés)
- Utiliser 404 au lieu de 410 pour un contenu définitivement retiré (410 est plus explicite et légèrement plus rapide à désindexer pour Google)
- Ne pas vérifier le code de réponse de votre propre page 404 (elle doit répondre 404, pas 200)
- Vérifier
- Visitez quelques URLs manifestement inexistantes. Vérifiez qu’elles répondent 404 (ou 410).
- Regardez la Search Console → Pages → Soft 404. Le compteur doit tomber à 0 au cycle d’exploration suivant.
-
018
Bloquer les pièges à crawl infinis (calendriers, filtres) via le robots.txt et un rel="nofollow" sur les liens internes concernés
- Comment
- Repérez les pièges à crawl classiques sur votre site : /calendar/2026/08/16/page/3 — chaque date multipliée par chaque page = des millions d’URLs
- /search?q=rouge&filter=taille&filter=couleur&page=2 — chaque combinaison de filtres = une infinité d’URLs
- /products?sort=price&dir=asc&page=1 — tri, sens et page = de nombreuses URLs pour le même contenu
- · Bloquez-les dans le robots.txt : Disallow: /calendar/ Disallow: /search Disallow: /*?sort=* Disallow: /*&sort=*
- Ajoutez rel="nofollow" sur les liens internes vers ces URLs. Ne leur transmettez pas de PageRank.
- Utilisez des balises canonical faisant pointer les URLs à paramètres vers l’URL de base.
- Vérification : lancez Screaming Frog avec « Respect robots.txt : ON ». Il ne doit pas explorer les motifs bloqués.
- À éviter
- Bloquer /calendar/ alors que votre contenu est justement calendaire (vous bloquez de vraies pages)
- Ne pas mettre de nofollow sur les liens internes (le PageRank continue de couler vers des URLs bloquées, donc perdu)
- Bloquer un motif et en manquer un semblable (bloquer /search mais pas /find)
- Vérifier
- Après mise à jour du robots.txt, surveillez la Search Console → Pages pendant 2 à 4 semaines : le nombre d’URLs explorées issues de vos motifs pièges doit tomber à 0
- Lancez Screaming Frog en respectant le robots.txt. Les URLs pièges doivent être exclues du crawl
-
019
Adopter une taxonomie de dossiers logique dans les URLs (/theme/sous-theme/page), reflet de la hiérarchie du site
- Comment
- Cartographiez l’architecture de l’information de votre site. Regroupez le contenu en : catégories de premier niveau (3 à 7 grands sujets)
- sous-catégories (les sujets précis dans chacune)
- contenus (les pages elles-mêmes)
- Exemple pour un site marketing : /seo/ — tout le contenu SEO
- /seo/schema/ — les pages sur le schema
- /seo/schema/guide-balisage — un article précis
- · Configurez votre CMS ou votre framework pour imposer cette structure. WordPress : utilisez les catégories et de bons permaliens. Sur mesure : imposez-la dans la couche de routage.
- Pour un site existant aux URLs désordonnées, mettez des redirections 301 vers les nouvelles URLs propres. Mettez à jour les liens internes vers les nouvelles URLs.
- Tenez-la dans la durée. Quand vous ajoutez du contenu, rangez-le au bon endroit. Si une nouvelle catégorie émerge, créez-la explicitement.
- À éviter
- Une imbrication trop profonde (plus de trois niveaux) allonge les URLs et signale que la page est « loin » dans le site
- Changer la taxonomie sans redirections (vous perdez tout le capital accumulé sur les anciennes URLs)
- Ajouter des catégories au coup par coup (chaque nouvel article obtient sa propre catégorie de premier niveau, ce qui annule l’intérêt de la hiérarchie)
- Vérifier
- Prenez 10 URLs au hasard. Chacune doit entrer proprement dans la taxonomie que vous avez documentée.
- Cherchez les pages orphelines : celles qui ne pointent vers rien et vers lesquelles rien ne pointe. Utilisez le filtre « Orphan Pages » de Screaming Frog.
-
020
Vérifier toutes les variantes de propriété (http/https, www/sans www) dans la Search Console ; rediriger en 301 toutes les variantes vers un seul hôte canonique
- Comment
- Choisissez votre hôte et votre protocole canoniques. Choix courants : https://votresite.com (sans www) — le plus répandu en 2026
- https://www.votresite.com (avec www) — tout aussi acceptable
- toujours https, jamais http
- · Ajoutez des redirections 301 de chaque variante vers la canonique. Sous nginx : server { server_name www.votresite.com votresite.com; return 301 https://votresite.com$request_uri; } server { listen 80; return 301 https://votresite.com$request_uri; }
- Dans la Search Console, ajoutez et validez les QUATRE propriétés : http://votresite.com
- http://www.votresite.com
- https://votresite.com
- https://www.votresite.com
- Dans chaque propriété non canonique, désignez la canonique comme domaine préféré.
- À éviter
- Ne rediriger que http → https sans traiter www → sans www (ou l’inverse)
- Ne valider que la propriété canonique dans la Search Console (il faut valider toutes les variantes)
- Utiliser des balises canonical au lieu de redirections (la canonical est un indice, pas une directive — pour consolider réellement, il faut une 301)
- Laisser https://www continuer d’être indexé parce que vous ne l’avez pas ajouté à la Search Console
- Vérifier
- Testez chaque variante : curl -I http://votresite.com, curl -I https://www.votresite.com. Toutes doivent faire une 301 vers la canonique.
- Dans la Search Console, vérifiez que les quatre propriétés sont validées et que la canonique est bien désignée comme préférée.