Pourquoi semrushbot et ahrefsbot sont-ils bloqués par défaut ?

Jamie_Liu1 · Juillet 14, 2020, 8:57

J’ai consulté le rapport de couverture de Google Search Console et constaté que de nombreuses pages de notre forum sont bloquées par le fichier robots.txt. J’ai donc vérifié ce fichier et découvert que semrushbot et ahrefsbot sont bloqués par défaut :

Je sais qu’il s’agit de deux outils SEO très utilisés. Pourquoi bloquer leurs robots ?

neounix · Juillet 14, 2020, 9:03

Parce que ces robots sont des « gouffres de ressources » qui apportent très peu de valeur aux sites par rapport à la quantité de ressources qu’ils consomment.

Bien sûr, vous pouvez personnaliser le fichier robots.txt de Discourse et les autoriser si vous le souhaitez ; mais nous bloquons ces robots sur nos sites bien avant la sortie de Discourse et nous les maintenons bloqués.

Note (Édité) :

J’ai oublié de mentionner que beaucoup de ces « gouffres de ressources » ne respectent pas robots.txt et doivent être bloqués au niveau de l’agent utilisateur HTTP. Nous bloquons ces « gouffres de ressources irrespectueux » avec mod_rewrite au niveau du proxy inverse, d’une manière générale (l’une des nombreuses bonnes raisons d’utiliser un proxy inverse, soit dit en passant).

Jamie_Liu1 · Juillet 14, 2020, 9:29

Merci beaucoup pour ces informations !

J’ai découvert un autre problème et j’aimerais peut-être avoir votre avis là-dessus aussi.

Je sais que Discourse a bloqué les pages utilisateur par défaut, mais dans mon rapport de couverture de Google Search Console, certaines pages utilisateur sont toujours indexées. C’est un problème aux yeux de Google, car ces pages ne devraient pas être indexées :

Merci !

osioke · Juillet 14, 2020, 12:35

Cela a été corrigé récemment avec

Pouvez-vous mettre à jour votre Discourse et le re-vérifier ?

Jamie_Liu1 · Juillet 15, 2020, 2:14

@osioke Merci pour votre réponse ! Je pense que notre version installée inclut déjà cette fonctionnalité ? Car j’ai remarqué que la correction avait été commitée en janvier.

Pourriez-vous vérifier s’il est nécessaire de passer à la dernière version pour bénéficier de cette fonctionnalité ?

osioke · Juillet 15, 2020, 7:03

Cela ne fait pas de mal de mettre à jour, à mon avis, mais oui, cette correction devrait figurer dans votre version installée. Je vous conseillerais de tenter une mise à jour et une nouvelle vérification, sauf si vous ne souhaitez pas mettre à jour pour une autre raison.

codinghorror · Juillet 15, 2020, 9:41

Parce qu’ils sont mauvais ? Ils ajoutent beaucoup de charge serveur sans bénéfice discernable, et nos clients ont des limites de vues de page sur leurs formules.

Jamie_Liu1 · Juillet 16, 2020, 2:13

Ça semble bon. Nous procédons à la mise à jour. J’espère que tout fonctionnera correctement après la mise à jour. Je reviens vers vous pour vous tenir informé. Merci !

trying2survive · Décembre 2, 2020, 3:30

Pour clarifier, existe-t-il vraiment aucun moyen de débloquer Semrushbot et SEO Spider ? Nous en avons besoin pour l’audit SEO. Nous avons essayé de les supprimer tous les deux de /admin/customize/robots (nous avons également essayé Allow:), mais nous obtenons une erreur 429 dans Screaming Frog. Ou cette erreur 429 est-elle un problème distinct ? Vos éclaircissements sont grandement appréciés.

Johani · Décembre 2, 2020, 4:34

Les erreurs 429 signifient que ces robots d’indexation sont soumis à une limitation du débit. Discourse dispose par défaut d’un mécanisme de limitation du débit activé pour prévenir les abus. Vous pouvez en savoir plus à ce sujet ici.

neounix · Décembre 3, 2020, 9:35

Avez-vous essayé ceci (en utilisant le nom de votre conteneur) ?

Remarque : vous pouvez également configurer cela dans l’interface d’administration :

# docker exec -it socket-only bash
root@socket-only:/# rails c
[1] pry(main)> SiteSetting.blocked_crawler_user_agents
=> "mauibot|semrushbot|ahrefsbot|blexbot|seo spider"
[2] pry(main)> SiteSetting.blocked_crawler_user_agents = ""
=> ""
[3] pry(main)> SiteSetting.blocked_crawler_user_agents
=> ""
[4] pry(main)>

Voir aussi :

github.com/discourse/discourse

config/site_settings.yml

d1d87b6fa

# Available options:
#
# default            - The default value of the setting. For upload site settings, use the id of the upload seeded in db/fixtures/010_uploads.rb.
# client             - Set to true if the javascript should have access to this setting's value.
# refresh            - Set to true if clients should refresh when the setting is changed.
# min                - For a string setting, the minimum length. For an integer setting, the minimum value.
# max                - For a string setting, the maximum length. For an integer setting, the maximum value.
# regex              - A regex that the value must match.
# validator          - The name of the class that will be use to validate the value of the setting.
# allow_any          - For choice settings allow items not specified in the choice list (default true)
# secret             - Set to true if input type should be password and value needs to be scrubbed from logs (default false).
# enum               - The setting has a fixed set of allowed values, and only one can be chosen.
#                      Set to the class name that defines the set.
# locale_default     - A hash which overrides according to `SiteSetting.default_locale`.
#                      The key should be as the same as possible value of default_locale.
#
#
# type: email    - Must be a valid email address.
# type: username - Must match the username of an existing user.
# type: list     - A list of values, chosen from a set of valid values defined in the choices option.

This file has been truncated. show original

Voir aussi :

  def self.allow_crawler?(user_agent)
    return true if SiteSetting.allowed_crawler_user_agents.blank? &&
      SiteSetting.blocked_crawler_user_agents.blank?
...
...

github.com/discourse/discourse

lib/crawler_detection.rb

e0d923225

# frozen_string_literal: true

module CrawlerDetection
  WAYBACK_MACHINE_URL = "archive.org"

  def self.to_matcher(string, type: nil)
    escaped = string.split('|').map { |agent| Regexp.escape(agent) }.join('|')

    if type == :real && Rails.env == "test"
      # we need this bypass so we properly render views
      escaped << "|Rails Testing"
    end

    Regexp.new(escaped, Regexp::IGNORECASE)
  end

  def self.crawler?(user_agent, via_header = nil)
    return true if user_agent.nil? || user_agent&.include?(WAYBACK_MACHINE_URL) || via_header&.include?(WAYBACK_MACHINE_URL)

    # this is done to avoid regenerating regexes

This file has been truncated. show original

Vous pouvez constater dans le code que si vous définissez ces deux paramètres du site sur « vide », aucun blocage ne sera appliqué :

SiteSetting.allowed_crawler_user_agents
SiteSetting.blocked_crawler_user_agents

Je vous recommande de ne pas modifier cela, car ces bots, qui sont bloqués par défaut par le cœur de Discourse, ne respectent pas le fichier robots.txt ; cependant, c’est votre site et vous pouvez faire comme vous le souhaitez. Il y a une bonne raison pour laquelle ils sont bloqués dans le cœur.

Cela dit, Discourse vous donne la possibilité de « débloquer » ces bots en utilisant vos paramètres du site dans l’interface utilisateur.

Sujet		Réponses	Vues
Handling Bingbot Feature	29	7484	Novembre 20, 2020
MegaIndex bot did about 4,000 pageviews on one day Community Building	40	4626	Décembre 2, 2023
Issues Google Search Console is throwing at me for wrong discourse structure (or some for wrong administration of my site) Support	18	233	Décembre 18, 2024
Why there are lots of Disallow rule in robots.txt? Support	34	4622	Décembre 22, 2020
How to protect myself from bots crawling my Discourse instance? Support	6	1632	Janvier 17, 2022

Pourquoi semrushbot et ahrefsbot sont-ils bloqués par défaut ?

Sujets connexes