robots.txt expliqué : contrôler correctement les robots d'indexation des moteurs de recherche

Le fichier robots.txt fait partie des outils fondamentaux de l'optimisation pour les moteurs de recherche technique. Elle te permet d'indiquer aux robots d'exploration des moteurs de recherche quelles parties de ton site web ils sont autorisés à explorer et lesquelles ne le sont pas.

Cependant, une mauvaise configuration peut avoir des conséquences importantes. Dans le pire des cas, Google sera empêché d'indexer des parties importantes ou même l'intégralité du site Web.

Il est tout aussi important de comprendre ce que robots.txt ne peut pas : ce n'est pas un outil fiable pour supprimer des pages Web de l'index Google.

Dans cet article, nous expliquons comment robots.txt est constitué, ce qui Agent utilisateur, Interdire et Autoriser signifier, comment tu soumets un sitemap et quelles erreurs tu dois absolument éviter.

En bref : Le dé robots.txt contrôle en premier lieu quelles URL les robots d'indexation des moteurs de recherche sont autorisés à récupérer. Il contrôle ainsi Exploration. La question de savoir si une page Web doit être indexée en est une autre.

Qu'est-ce qu'un fichier robots.txt ? #

Le dé robots.txt est un fichier texte simple situé dans le répertoire racine d'un hôte.

Pour un site Web à l'adresse :

https://example.com

le fichier se trouve-t-il sous :

https://example.com/robots.txt

Les robots d'indexation des moteurs de recherche récupèrent ce fichier et vérifient quelles règles de exploration s'appliquent à eux.

Où doit se trouver le fichier robots.txt ? #

Le fichier doit se trouver directement dans le répertoire racine de l'hôte concerné.

Correct :

https://example.com/robots.txt

Un fichier sous :

https://example.com/verzeichnis/robots.txt

n'est-ce pas le / n'est-ce pas la robots.txt pour l'ensemble du site web.

Le nom de fichier doit robots.txt lauten.

Le fichier robots.txt s'applique toujours à l'hôte respectif #

Une particularité technique importante est le champ d'application.

Le fichier situé à :

https://example.com/robots.txt

s'applique aux URL sous cet hôte et ce protocole.

Elle ne s'applique pas automatiquement à :

https://shop.example.com

robots.txt robots.txt sous leur hôte.

De même, les différents protocoles et ports sont traités séparément sur le plan technique.

Comment est structurée une robots.txt ? #

Un fichier simple peut par exemple ressembler à ceci :

User-agent: *
Disallow: /intern/

Sitemap: https://example.com/sitemap.xml

Les éléments les plus importants sont :

Instruction	Sens
Agent utilisateur	Déterminez à quel robot d'indexation s'appliquent les règles suivantes
Interdire	Empêche l'exploration des chemins d'URL correspondants
Autoriser	Autorise l'exploration des chemins d'URL correspondants au sein des groupes de règles correspondants
Plan du site	Fournit l'adresse complète d'un sitemap.

Que signifie User-agent ? #

Avec Agent utilisateur il est déterminé pour quel robot d'indexation un groupe de règles est destiné.

L'astérisque représente ici tous les robots d'indexation auxquels s'applique ce groupe général :

User-agent: *

Une règle peut également être écrite spécifiquement pour un robot d'indexation particulier.

Par exemple :

User-agent: Googlebot
Disallow: /beispiel/

Ce groupe de règles cible ainsi spécifiquement Googlebot.

Que signifie Disallow ? #

Avec Interdire tu peux exclure un chemin d'URL pour le robot d'indexation respectif du crawling.

Exemple :

User-agent: *
Disallow: /intern/

Cela indique aux robots d'exploration concernés que les URL situées sous ce chemin ne doivent pas être explorées.

Par exemple :

https://example.com/intern/

https://example.com/intern/datei.html

https://example.com/intern/unterordner/

Que signifie une instruction Disallow vide ? #

Un vide Interdire-L'instruction ne bloque aucun chemin.

Exemple :

User-agent: *
Disallow:

Cela n'exclut rien du crawling pour ce groupe de règles.

Cependant, si l'intégralité de votre site web peut être explorée, une telle règle n'est pas strictement nécessaire. En principe, un site web peut également [se terminer brusquement ici] robots.txt-Règles soient explorées.

Bloquer l'ensemble du site Web pour les robots d'indexation #

La règle suivante est particulièrement importante :

User-agent: *
Disallow: /

Elle indique aux robots d'indexation concernés de ne pas crawler l'ensemble du site Web.

Attention : Cette configuration ne doit pas rester active par inadvertance sur un site web indexable publiquement. Surtout après le passage d'un environnement de développement ou de staging au site de production, vous devriez robots.txt contrôler.

Que signifie Allow ? #

Avec Autoriser un chemin spécifique au sein d'une structure par ailleurs bloquée peut être expressément autorisé pour le crawling.

Un exemple simplifie :

User-agent: *
Disallow: /bereich/
Allow: /bereich/oeffentlich/

Cela bloque fondamentalement la zone, tandis que le chemin spécifiquement autorisé peut être exploré.

Allow et Disallow peuvent être utilisés ensemble #

Les sites Web plus complexes peuvent nécessiter des règles où une zone plus large est exclue et une ressource ou sous-structure spécifique est réautorisée.

Il convient d'y travailler avec une attention particulière, car de légers changements dans le modèle d'URL peuvent avoir un effet différent de celui escompté.

Conseil pratique : Ferme ta robots.txt Le plus simple possible. Vous ne devez utiliser des règles complexes que s'il y a une raison technique concrète.

Le fichier robots.txt n'est pas une mesure de sécurité #

Une Interdire-La règle ne protège pas les données confidentielles.

Le fichier est accessible publiquement et ses règles peuvent être consultées par tout le monde.

Par exemple, si vous saisissez :

User-agent: *
Disallow: /geheime-dokumente/

Le chemin n'est donc pas protégé des visiteurs.

Quiconque connaît l'URL peut continuer à y accéder directement, à moins qu'il n'y ait une véritable protection contre l'accès.

Important : Les contenus confidentiels doivent être protégés par des mécanismes d'accès appropriés. Une robots.txt il n'y a pas de protection par mot de passe ni de contrôle d'accès.

robots.txt et noindex ne sont pas la même chose #

C'est la différence la plus importante de tout l'article.

robots.txt	noindex
contrôle l'exploration	contrôle l'indexation
est disponible sous forme de fichier texte central	est par exemple délivré sous forme de directive meta robots ou d'en-tête HTTP
peut empêcher la récupération d'une URL	indique aux moteurs de recherche de ne pas indexer la page
aucun outil fiable pour supprimer une page Web de Google	destiné à l'exclusion d'une page accessible de l'index

Pourquoi une URL bloquée peut-elle quand même apparaître sur Google ? #

Google peut également connaître une URL par d'autres moyens, par exemple par des liens provenant d'autres sites Web.

Si l'URL par robots.txt est exclu du crawling, Google ne peut pas récupérer son contenu réel normalement.

Google peut tout de même connaître l'URL.

C'est pourquoi l'hypothèse suivante est fausse :

Interdit = certainement pas sur Google

Un par robots.txt Une URL bloquée peut dans certaines circonstances continuer à apparaître en tant qu'URL dans les résultats de recherche.

Pourquoi noindex ne fonctionne-t-il pas si Google n'est pas autorisé à crawler la page ? #

En supposant qu'une page contienne :

<meta name="robots" content="noindex">

et en même temps bloque la robots.txt Google refuse l'accès à cette page.

Un problème se pose alors :

robots.txt
bloque l'exploration
        ↓
Google ne récupère pas la page
        ↓
Google ne voit pas la balise noindex

Pour que Google puisse noindex-Le robot d'indexation doit être autorisé à accéder à la page concernée pour pouvoir détecter l'instruction.

Remarque : Si une page accessible au public doit être exclue de l'index Google, vous ne devez pas en même temps empêcher Google de noindex-Instruction à voir.

Peut-on écrire noindex dans le fichier robots.txt ? #

Non. Google soutient noindex pas comme une règle au sein de la robots.txt.

Par conséquent, vous ne devriez pas utiliser les éléments suivants :

User-agent: *
Noindex: /beispiel/

Si l'on ne souhaite pas qu'une page HTML soit indexée, il est possible d'utiliser par exemple une balise meta robots :

<meta name="robots" content="noindex">

Pour d'autres types de ressources, un en-tête HTTP approprié peut être utilisé selon le cas d'utilisation.

Quand le fichier robots.txt est-il utile ? #

Une robots.txt est particulièrement utile si tu souhaites contrôler l'exploration de certaines zones d'URL.

Cela peut par exemple être pertinent pour les sites web qui possèdent un très grand nombre de variantes d'URL générées techniquement.

Les cas possibles sont :

certains domaines techniques

des URL de recherche ou de filtre inutiles

certains modèles d'URL générés automatiquement

l'accès des robots d'exploration à des ressources individuelles

de grands volumes d'URL d'exploration non pertinentes

Cependant, l'utilité d'un verrou doit être évaluée pour chaque système spécifique.

Toutes les URL techniques ne doivent pas nécessairement être bloquées #

Une longue robots.txt n'est pas automatiquement meilleure qu'une courte.

Pour les petits sites web bien structurés, il n'y a souvent aucune raison de bloquer par précaution de nombreux répertoires.

Chaque règle supplémentaire augmente plutôt le risque d'exclure par inadvertance des contenus ou des ressources importants.

Qu'en est-il de WordPress ? #

Les sites WordPress possèdent souvent un contenu fourni automatiquement ou dynamiquement robots.txt.

Selon la configuration et les plugins utilisés, leur contenu peut différer.

C'est pourquoi tu ne dois pas reprendre aveuglément un „ robots.txt WordPress optimal “ d'origine inconnue provenant d'Internet.

Ouvrez d'abord :

https://deine-domain.ch/robots.txt

et vérifie quelles règles ton site web livre réellement.

Le paramètre de visibilité pour les moteurs de recherche de WordPress #

WordPress propose dans ses réglages une option permettant d'empêcher les moteurs de recherche d'indexer le site Web.

Ce paramètre est par exemple pertinent pendant une phase de développement.

Dans le cas d'un site web public, vous devez impérativement vérifier après le lancement qu'aucune ancienne configuration de développement n'a été laissée par inadvertance.

Le résultat technique qui en découle peut dépendre de la version de WordPress, de la configuration et des plugins utilisés. C'est pourquoi le site web effectivement livré est toujours déterminant.

Traiter correctement les sites de staging #

Un site de développement ou de staging ne devrait normalement pas apparaître publiquement dans les moteurs de recherche.

Une pure robots.txt-Cependant, le verrouillage n'offre pas une protection complète contre cela.

Pour les environnements de développement non publics, une véritable protection par le contrôle d'accès est nettement plus fiable.

Par exemple :

Site de staging
↓
Authentification /
Protection par mot de passe
↓
Non accessible au public

Cela protège non seulement contre l'exploration par les moteurs de recherche, mais aussi contre tout accès public non souhaité.

Vérifier le robots.txt après une refonte #

Après une refonte de site web, la robots.txt parmi les fichiers que tu devrais absolument vérifier.

Vérifiez en particulier :

Le site web de production est-il crawlable ?

Est-ce que Disallow: / est activé par erreur ?

Des zones importantes sont-elles bloquées ?

Les ressources CSS/JS importantes sont-elles accessibles ?

L'adresse du sitemap est-elle correcte ?

Les règles proviennent-elles encore de l'environnement de développement ?

Si la structure des URL a été modifiée en même temps, tu dois également vérifier les redirections, les sitemaps et l'état d'indexation.

Ne pas bloquer inutilement les fichiers CSS et JavaScript importants #

Google restitue les sites web modernes et a souvent besoin pour cela de ressources CSS, JavaScript et autres.

Lorsque des ressources importantes par robots.txt être bloqué, Google pourrait ne pas être en mesure de traiter et d'afficher une page de la même manière qu'un visiteur normal la voit.

C'est pourquoi vous ne devez pas bloquer globalement les répertoires CSS et JavaScript simplement parce que ces fichiers eux-mêmes ne sont pas destinés à apparaître comme des résultats de recherche normaux.

Google doit pouvoir comprendre la page le plus possible comme le ferait un visiteur #

Si la mise en page, la navigation ou les contenus essentiels dépendent de JavaScript ou du CSS, le blocage de ces ressources peut compliquer le traitement.

En cas de problème, vous pouvez utiliser l'outil d'inspection d'URL de la Google Search Console pour examiner comment Google traite la page concernée.

Pour en savoir plus sur la vérification d'URL, consultez Google n'indexe pas mon site web : vérifier les causes.

Spécifier un sitemap dans robots.txt #

Le dé robots.txt peut pointer vers un plan de site XML.

Exemple :

User-agent: *
Disallow:

Sitemap: https://example.com/sitemap.xml

L'adresse du sitemap doit être indiquée en entier.

Si votre site Web utilise un index de sitemap, celui-ci peut être spécifié en conséquence :

Plan du site : https://example.com/sitemap_index.xml

Nous expliquons le fonctionnement des sitemaps XML et la manière de les soumettre à Google sur Plan du site XML : Ce qu'il fait et comment le soumettre à Google.

Le plan du site (sitemap) et le fichier robots.txt ont des rôles opposés #

Pour faire simple, vous pouvez retenir la différence ainsi :

Plan du site

"Voici les URL importantes
que tu devrais connaître."


robots.txt

"Tu ne dois pas explorer
ces zones d'URL."

C'est pourquoi les deux configurations doivent logiquement correspondre.

Ne pas recommander et bloquer une URL en même temps #

Si une URL figure dans votre sitemap XML en tant que page importante et indexable, elle ne doit pas en même temps par robots.txt être exclu du crawling.

Une telle configuration génère des signaux contradictoires :

Plan du site :
"Cette URL est pertinente."

robots.txt :
"Ne pas récupérer cette URL."

Vérifiez donc toujours les deux côtés de la configuration en cas de problèmes d'indexation.

Utiliser des commentaires dans robots.txt #

Les commentaires peuvent être avec un # être initié.

Exemple :

# Ne pas explorer la zone technique
User-agent: *
Disallow: /intern/

Tout après # est traité comme un commentaire dans cette ligne.

Les commentaires peuvent aider à documenter pourquoi une règle spécifique existe dans le cas de fichiers plus complexes.

Respecter la casse des chemins d'URL #

Dans les chemins d'URL Autoriser– et Interdire-règles, la casse est importante.

Par exemple :

/Images/

/images/

pas nécessairement le même modèle d'URL.

Écrivez par conséquent des règles adaptées aux chemins d'URL réellement utilisés.

Caractères génériques dans robots.txt #

Google prend en charge, entre autres, l'astérisque dans les règles de chemin d'accès. * comme espace réservé.

Un exemple :

User-agent: Googlebot
Disallow: /*.pdf

Cela permet de capturer les chemins d'URL à l'aide d'un motif.

Vous devez utiliser ce type de règles avec précaution, car elles peuvent concerner nettement plus d'URL qu'une simple règle de répertoire.

Le signe dollar pour la fin d'une URL #

Google prend également en charge $, pour marquer la fin d'un motif d'URL.

Exemple :

User-agent : Googlebot
Disallow : /*.pdf$

Le modèle cible les URL dont le chemin correspond à .pdf se termine.

Une URL comportant des caractères supplémentaires ou des paramètres selon ce modèle peut ainsi être traitée différemment.

Conseil pratique : Les caractères génériques sont puissants, mais sujets aux erreurs. Pour un site Web d'entreprise normal, vous ne devriez pas utiliser de motifs compliqués si des règles simples remplissent le même objectif.

Quelle règle l'emporte en cas de chevauchement ? #

Si plusieurs Autoriser– et Interdire-règles correspondent à une URL, Google évalue la règle spécifique correspondante en fonction de la longueur du chemin correspondant.

Un exemple simplifie :

User-agent: *
Disallow: /ordner/
Allow: /ordner/oeffentlich/

Pour une URL sous :

https://example.com/ordner/oeffentlich/seite

est la plus spécifique Autoriser-Règle déterminante.

C'est pourquoi, en particulier pour les ensembles de règles complexes, vous ne devez pas seulement regarder l'ordre des lignes.

Délai d'exploration et Google #

Manche robots.txt-Les exemples sur Internet contiennent une instruction telle que :

Crawl-delay: 10

Google prend en charge délai d'exploration dans robots.txt pas.

Vous ne devez donc pas utiliser cette instruction comme méthode pour contrôler la vitesse de crawl de Googlebot.

ne pas encombrer inutilement le robots.txt avec des règles tierces #

On trouve sur Internet de nombreux fichiers prêts à l'emploi contenant de longues listes de bots et de règles.

Tu ne devrais pas reprendre de tels modèles aveuglément.

Une configuration externe peut :

être destiné à un autre CMS
contenir des règles obsolètes
bloquer des ressources importantes
contenir des règles de bot inutiles
ne pas correspondre à la structure de vos URL
rendre les erreurs futures plus difficiles à identifier

Un fichier court, compréhensible et documenté est souvent la meilleure solution.

robots.txt et robots d'indexation IA #

D'autres systèmes automatisés peuvent également utiliser leurs propres noms d'agents utilisateurs et respecter le protocole d'exclusion des robots.

Le fait qu'un service particulier interprète ou non les règles de crawling, et comment il le fait, dépend du fournisseur et du robot d'indexation concernés.

Vous ne devez donc pas supposer qu'une seule règle pour Googlebot concerne automatiquement l'ensemble des moteurs de recherche, des intelligences artificielles, des outils d'analyse et autres robots d'indexation.

Si vous souhaitez cibler et contrôler un robot d'indexation particulier, vous devriez consulter sa documentation officielle actuelle et la désignation de son agent utilisateur.

Vérifier robots.txt publiquement dans le navigateur #

La première vérification, et la plus simple, consiste à appeler directement le fichier :

https://deine-domain.ch/robots.txt

Vérifiez ensuite :

Le fichier est-il affiché ?

Le contenu est-il conforme aux attentes ?

Y a-t-il un Disallow: / ?

Des chemins importants sont-ils bloqués ?

Le sitemap est-il correct ?

Y a-t-il d'anciennes règles ?

Vérifier le fichier robots.txt dans la Search Console de Google #

Google Search Console fournit des informations sur les éléments reconnus par Google robots.txt Prêt.

Cela vous permet par exemple de vérifier quel fichier Google a détecté pour votre site web et s'il y des problèmes lors de la récupération.

Pour une URL spécifique, l'outil d'inspection d'URL est également important si vous souhaitez examiner si Google peut explorer la page.

Après une modification, ne pas se contenter de vérifier le navigateur #

Si vous robots.txt-tu as modifié la règle, tu ne devrais pas seulement vérifier si le nouveau fichier est visible dans le navigateur.

Vérifiez en outre une ou plusieurs URL effectivement concernées.

Par exemple :

Règle modifiée
        ↓
Vérifier robots.txt dans le navigateur
        ↓
Identifier l'URL concernée
        ↓
Utiliser l'outil d'inspection d'URL
        ↓
Contrôler l'explorabilité

Google peut mettre en cache le fichier robots.txt #

Google rappelle robots.txt régulièrement et peut en mettre le contenu en cache.

Une modification ne doit donc pas nécessairement être prise en compte à la même seconde lors de chaque exploration.

Une fois que vous avez résolu un problème critique de blocage, vous devez vérifier l'état actuel et donner à Google le temps de récupérer et de traiter à nouveau la modification.

Que se passe-t-il si robots.txt est inaccessible ? #

Le comportement d'un robot d'indexation dépend également du statut HTTP que robots.txt livre.

Un manquant permanent robots.txt-Le document n'est pas identique à une erreur temporaire du serveur lors de la récupération.

Vous ne devez donc pas expérimenter intentionnellement avec des états d'erreur pour contrôler le crawling.

Pour un site Web normal, la configuration souhaitée doit être accessible de manière claire et fiable.

Nous expliquons les bases des réponses HTTP sous Codes d'état HTTP expliqués : 200, 301, 404, 403 et 500.

robots.txt et 404 #

Si non robots.txt existe et que la récupération correspondante renvoie un statut normal de type „ non trouvé “, Google traite fondamentalement la situation comme s'il n'y avait aucune restriction deexploration par un fichier robots.txt.

Cela ne signifie pas pour autant que tu devrais générer intentionnellement un fichier erroné.

Une configuration existante et compréhensible est généralement plus simple pour la maintenance et le diagnostic.

Vérifier le fichier robots.txt d'un nouveau site web #

Avant le lancement d'un nouveau site web, vous devriez vérifier les points suivants :

robots.txt accessible ?
        ↓
pas de blocage total
accidentel ?
        ↓
pages importantes
crawlables ?
        ↓
ressources importantes
crawlables ?
        ↓
adresse du sitemap
correcte ?
        ↓
contrôler noindex
séparément ?
        ↓
Search Console
configurée ?
        ↓
tester les URLs
importantes ?

robots.txt après un changement de domaine #

Lors d'un changement de domaine, vous devez robots.txt à prendre en compte aussi bien dans le cadre de l'ancien que du nouveau domaine.

Le nouveau site Web ne doit pas empêcher accidentellement Google de l'indexer.

En même temps, les redirections nécessaires des anciennes URL doivent être accessibles pour Google.

Ne bloquez donc pas systématiquement l'ancien site web si Google doit encore pouvoir crawler ses redirections.

robots.txt et redirections #

Si Google supprime une ancienne URL en raison d'une robots.txtUne règle -Disallow peut empêcher Google de récupérer normalement une redirection qui y est configurée.

Lors d'une migration, Google doit donc en principe pouvoir récupérer les anciennes URL pertinentes afin de détecter leurs redirections vers les nouvelles destinations.

Nous vous expliquons comment utiliser correctement les redirections permanentes sous Configurer une redirection 301 : rediriger des URL de manière permanente.

Examiner les robots.txt et les codes d'état HTTP ensemble #

En cas de problèmes de référencement technique, vous devez distinguer plusieurs niveaux :

robots.txt
→ Google est-il autorisé à explorer l'URL ?

Code HTTP
→ Que répond le serveur ?

noindex
→ La page peut-elle être indexée ?

Canonical
→ Quelle est l'URL de la version privilégiée ?

Sitemap
→ Quelle URL est signalée comme pertinente ?

Seule l'interaction de ces signaux montre comment une URL est configurée techniquement.

Exemple : la page publique doit être indexée #

Supposons que l'URL suivante doive apparaître sur Google :

https://example.com/ratgeber

Une configuration propre pourrait ressembler, de manière simplifiée, à ceci :

robots.txt :
Exploration autorisée

HTTP :
200 OK

Meta Robots :
pas de noindex

Balise canonique :
https://example.com/ratgeber/

Sitemap :
URL incluse

Liens internes :
présents

Il n'y a donc pas de contradictions techniques évidentes à ces niveaux.

Exemple : La page ne doit pas être indexée #

Une page accessible au public doit pouvoir être explorée par Google, mais ne doit pas apparaître dans les résultats de recherche.

Le principe pourrait alors être le suivant :

robots.txt :
Exploration autorisée

Méta Robots :
noindex

Google peut explorer la page qui noindex-Détecter l'instruction et la traiter en conséquence.

Exemple : espace privé #

Un espace réellement confidentiel ne devrait pas simplement être :

Disallow: /privat/

„être protégé.

Au lieu de cela, il a besoin d'une véritable protection contre les accès non autorisés.

contenu privé
        ↓
Connexion / Authentification
        ↓
non accessible publiquement

La question de l'indexation par les moteurs de recherche n'est alors qu'une partie du contrôle d'accès proprement dit.

Exemple : site Web complet bloqué par mégarde #

Après une refonte, le fichier indique :

User-agent: *
Disallow: /

Cependant, le site Web doit être exploré publiquement par Google.

Alors cette règle est une erreur de configuration critique.

Après la correction, vous devez :

rappeler robots.txt
        ↓
contrôler la règle
        ↓
vérifier les URL importantes avec
la Search Console
        ↓
contrôler le sitemap
        ↓
observer l'évolution de l'indexation

Exemple : L'URL est dans le sitemap et bloquée en même temps #

Plan du site :

https://example.com/produkt/


robots.txt :

Disallow: /produkt/

Si la page produit doit être indexée normalement, ces signaux se contredisent.

La solution ne consiste pas à demander plus souvent à Google d'indexer, mais à corriger d'abord la configuration technique.

Quand devriez-vous même modifier robots.txt ? #

Ne modifiez le fichier que si vous avez une raison valable de le faire.

Par exemple :

zone de crawl inutile identifiée

structure d'URL générée techniquement
ne doit pas être crawlée

corriger la règle erronée existante

ajouter l'adresse du sitemap

contrôler un robot d'indexation ciblé

configurer correctement la migration / le refonte

„Je veux améliorer mon référencement“ ne suffit pas en soi pour justifier des dépenses Interdire-d'intégrer des règles.

Toujours vérifier les impacts avant toute modification #

Une seule règle courte peut concerner des milliers d'URL.

De :

Disallow: /shop/filter/

et

Disallow: /shop/

il peut en résulter des effets tout à fait différents.

Vérifiez par conséquent précisément avant l'enregistrement quelles URLs sont concernées par une règle.

Attention : N'expérimentez pas directement sur un site web de production avec des complexité robots.txt-Règles, si vous ne pouvez pas en évaluer clairement les impacts.

Erreurs fréquentes dans robots.txt #

Disallow : / sur le site en direct

utiliser robots.txt comme noindex

bloquer simultanément une page noindex

" protéger " du contenu confidentiel uniquement avec robots.txt

bloquer des fichiers CSS importants

bloquer des fichiers JavaScript importants

saisir une URL de sitemap incorrecte

reprendre d'anciennes règles de staging

copier des modèles WordPress tiers sans les vérifier

utiliser des caractères génériques (wildcards) compliqués sans nécessité

ignorer la casse (majuscules/minuscules)

utiliser Crawl-delay pour Google

bloquer l'ancien domaine lors d'une migration, alors que les redirections doivent être explorées

Liste de contrôle : vérifier correctement robots.txt #

https://deine-domain.ch/robots.txt
accéder
        ↓
Fichier accessible ?
        ↓
Bon hte ? -> Bon hôte ?
        ↓
Vérifier les règles User-agent
        ↓
Vérifier les règles Disallow
        ↓
Disallow: / présent ?
        ↓
Vérifier les règles Allow
        ↓
Contrôler les caractères génériques (wildcards)
        ↓
Pages importantes crawlables ?
        ↓
Ressources CSS/JS importantes crawlables ?
        ↓
Adresse du sitemap correcte ?
        ↓
Vérifier noindex séparément
        ↓
Tester les URLs importantes dans
la Search Console
        ↓
Recontrôler après modifications

robots.txt, noindex et sitemap en comparaison #

Outil	Tâche principale	Objectif typique
robots.txt	Contrôler le crawling	Empêcher les robots d'indexation d'accéder à certaines sections d'URL
noindex	Empêcher l'indexation	exclure une page accessible des résultats de recherche
Plan du site XML	Communiquer les URL	Indiquer les URL pertinentes aux moteurs de recherche

Ces trois mécanismes ne se remplacent pas mutuellement.

Un site web techniquement propre les utilise selon leur tâche respective.

Résumé #

Le dé robots.txt est un fichier texte accessible au public situé dans le répertoire racine d'un hôte. Il indique aux robots des moteurs de recherche quelles zones d'URL ils sont autorisés à explorer et lesquelles ne le sont pas.

Avec Agent utilisateur tu détermines le robot d'indexation concerné. Interdire exclut les chemins appropriés du crawling, tandis que Autoriser peut autoriser des chemins plus spécifiques. De plus, l'adresse complète d'un sitemap XML peut être indiquée.

La distinction la plus importante est : Les robots.txt contrôlent le crawling et noindex contrôle l'indexation. Un par robots.txt Une URL bloquée peut tout de même être connue de Google et, dans certaines circonstances, continuer à apparaître dans les résultats de recherche.

Une robots.txt n'est par ailleurs pas une fonction de sécurité. Les contenus confidentiels nécessitent une véritable protection contre les accès non autorisés.

Une prudence particulièrement s'impose après une refonte, lors de changements de domaine et sur les sites de staging. Une règle accidentelle telle que Disallow: / peut empêcher Google d'indexer l'ensemble du site Web productif.

Vous ne devriez utiliser des règles complexes, des caractères génériques (wildcards) et de longues listes de robots d'indexation étrangers que s'il existe une raison technique concrète pour le faire.

Une bonne robots.txt n'est donc pas aussi exhaustive que possible. Elle est aussi simple que possible et aussi spécifique que nécessaire – et chaque blocage qu'elle contient a un objectif compréhensible.