Est-il problématique d'inclure les versions décodées et codées des mêmes directives dans robots.txt?
Cette question fait suite à celle-ci:
Faut-il masquer les URL encodées RTL dans robots.txt ou non?
Est-il problématique d'inclure des versions décodées et codées des mêmes directives dans robots.txt, tels que les suivants?
Disallow: /מדיה_ויקי:*
Disallow: /%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:*
Les deux sont en fait "les mêmes" dans le sens où le premier est dans sa syntaxe RTL d'origine (hébreu, dans ce cas) et décodé et le second est encodé.
La "raison d'être" est de "viser" ( tout standard actuel ou possible à venir de Google (ou de tout autre moteur de recherche majeur d'ailleurs) .
Par exemple:
Aujourd'hui, une grande équipe de développement de moteurs de recherche pourrait préférer les versions décodées et demain une autre pourrait préférer la version codée;
D'où la question de savoir s'il est acceptable d'avoir les deux et d'en finir?
Indépendamment du fait que le proposé brouillon standard spécifie que vous devez encoder ou non, pour répondre à votre question spécifique ...
Non, il est peu probable que cela cause un problème si vous incluez des URL codées (% -encodées) et des URL décodées (%-décodées) dans robots.txt. L'un ou l'autre sera simplement ignoré, car l'un ou l'autre ne correspondra tout simplement pas.
MISE À JOUR: Pour clarifier tout (c'est-à-dire l'ensemble robots.txt fichier) doit être encodé en UTF-8. Il s'agit simplement de l'encodage des caractères du fichier. Ainsi, les URL "URL encodées" et "URL décodées" dans robots.txt sont en fait encodés en UTF-8. "UTF-8 encoded" et "URL encoded" font référence à des choses différentes. J'avais précédemment utilisé l'expression " standard UTF-8 encoded" pour faire la différence avec "URL encoded" - c'était peut-être trompeur, car les deux sont "UTF-8 encoded". Les consignes aux webmasters de Google (citées ci-dessous) utilisent les termes "caractères UTF-8" et "caractères codés UTF-8 à pourcentage échappé" pour différencier les deux.
Plutôt confus, l'outil de testeur robots.txt de Google ne semble correspondre qu'aux URL% décodées*1. Mais, pour autant que j'ai pu le déterminer, c'est un (surprenant* 2) incohérence dans l'outil uniquement et non reflétée dans le vrai Googlebot. Référence: https://www.screamingfrog.co.uk/search-console-robots-txt-tester-inconsistencies/
(*1 Il ressemble à l'outil aveuglément L'URL code l'URL avant la comparaison?)
(* 2 Si c'est vraiment un bug dans l'outil, pourquoi Google n'a-t-il pas résolu ce problème au cours des 3 dernières années?)
FWIW, les Consignes d'aide des webmasters de Google concernant robots.txt , qui indique qu'il a été mis à jour pour refléter la norme Internet proposée (1er juillet 2019) semble suggérer que si vous% codez l'URL ou non est optional:
Non 7 bits ASCII dans un chemin peuvent être inclus en tant que caractères UTF-8 ou en tant que caractères codés en UTF-8 échappés en pourcentage par RFC 3986
Et le Robots Exclusion Protocol - draft standard stipule:
octets dans les chemins URI et robots.txt en dehors de la plage du jeu de caractères codés US- ASCII, et ceux de la plage réservée définie par RFC3986, DOIT être en pourcentage -encodé comme défini par RFC3986 avant la comparaison .
Notez la dernière phrase, "avant la comparaison" - c'est une instruction pour les implémenteurs de la norme proposée, pas nécessairement pour ceux qui écrivent le robots.txt fichier lui-même.
Disallow: /מדיה_ויקי:* Disallow: /%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:*
A part: Vous n'avez pas besoin du joker* à la fin de l'URL, puisque robots.txt est le préfixe correspondant par défaut.