# A · Crawl et indexation
> Source: https://seorunbook.com/playbook/a-crawl-and-indexing/
> SEO Run Book — 410 SEO actions, free to read
> Last built: 2026-09-15
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.
20 actions, numérotées 1 à 20.
### 1. 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 : https://votresite.com/sitemap-1.xml 2026-08-16 · 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)
### 2. Renseigner 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 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 mis à jour à chaque build. · Pour les pages sans modification réelle depuis des années, mettez à la date de publication et n’y touchez plus. Un stable est plus utile qu’un motif permanent « date du jour ».
**À éviter.** Utiliser l’heure de build : chaque déploiement met tous les 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
### 3. 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 · 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)
### 4. 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é
### 5. Servir des sitemaps d’images et de vidéos séparés (ou les extensions / )
**Comment.** Choisissez votre approche. Soit : Option A : des fichiers sitemap-images.xml et sitemap-videos.xml distincts · Option B : ajouter des entrées et dans les blocs 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 a besoin d’un (l’URL de l’image) et, en option, de , , . · Pour les vidéos, chaque a besoin d’un , , , (ou ). · 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
### 6. 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)
### 7. 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
### 8. 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(//); 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)
### 9. 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 »)
### 10. 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)
### 11. 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)
### 12. 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)
### 13. 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 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)
### 14. 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)
### 15. 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)
### 16. Piloter la priorité par ; 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 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
### 17. 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)
### 18. 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 )
### 19. 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)
### 20. 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