Warum sind semrushbot und ahrefsbot standardmäßig blockiert?

Jamie_Liu1 · 14. Juli 2020 um 08:57

Ich habe den Coverage-Bericht in der Google Search Console überprüft und festgestellt, dass viele unserer Forenseiten durch die robots.txt-Datei blockiert sind. Daher habe ich die robots.txt-Datei geprüft. Dabei habe ich festgestellt, dass semrushbot und ahrefsbot standardmäßig blockiert sind:

Mir ist bekannt, dass dies zwei weit verbreitete SEO-Tools sind. Warum werden deren Bots blockiert?

neounix · 14. Juli 2020 um 09:03

Weil diese Bots „ressourcenschluckende Bot-Schweine

Jamie_Liu1 · 14. Juli 2020 um 09:29

Vielen Dank für die Informationen!

Ich habe ein weiteres Problem festgestellt. Vielleicht kannst du dazu auch deine Einschätzung abgeben.

Ich weiß, dass Discourse Benutzerseiten standardmäßig blockiert, aber in meinem Bericht zur Abdeckung in der Google Search Console sind dennoch einige Benutzerseiten indiziert. Das ist aus Googles Sicht ein Problem, da all diese Seiten nicht indiziert werden sollten:

Vielen Dank!

osioke · 14. Juli 2020 um 12:35

Dies wurde kürzlich mit

behoben. Kannst du dein Discourse aktualisieren und erneut verifizieren?

Jamie_Liu1 · 15. Juli 2020 um 02:14

@osioke Danke für deine Antwort! Ich glaube, unsere installierte Version hat die Funktion bereits? Denn mir ist aufgefallen, dass die Korrektur im Januar eingefügt wurde.

Könntest du bitte überprüfen, ob ich auf die neueste Version upgraden muss, um diese Funktion zu erhalten?

osioke · 15. Juli 2020 um 07:03

Es schadet meiner Meinung nach nicht, ein Update durchzuführen, aber ja, diese Korrektur sollte in deiner installierten Version enthalten sein. Ich würde versuchen, das Update durchzuführen und die Verifizierung erneut vorzunehmen, es sei denn, du möchtest aus einem anderen Grund kein Update durchführen.

codinghorror · 15. Juli 2020 um 21:41

Weil sie schlecht sind? Sie verursachen eine hohe Serverlast ohne erkennbaren Nutzen, und unsere Kunden haben bei ihren Tarifen Pageview-Limits.

Jamie_Liu1 · 16. Juli 2020 um 02:13

Klingt gut. Wir aktualisieren gerade. Hoffentlich funktioniert alles nach dem Update. Ich melde mich und halte dich auf dem Laufenden. Danke!

trying2survive · 2. Dezember 2020 um 15:30

Nur zur Klarstellung: Gibt es wirklich keine Möglichkeit, semrushbot und SEO Spider wieder freizuschalten? Wir benötigen sie für SEO-Audits. Wir haben versucht, beide aus /admin/customize/robots zu entfernen (auch mit Allow:), aber in Screaming Frog erhalten wir weiterhin einen 429-Fehler. Oder ist dieser 429-Fehler ein separates Problem? Ihre Einschätzung wäre uns sehr hilfreich.

Johani · 2. Dezember 2020 um 16:34

429-Fehler bedeuten, dass diese Crawler drosselt werden. Discourse hat standardmäßig einige Drosselmechanismen aktiviert, um Missbrauch zu verhindern. Weitere Informationen dazu finden Sie hier.

neounix · 3. Dezember 2020 um 09:35

Hast du das schon versucht (ersetze aber deinen Container-Namen)?

Hinweis: Du kannst dies auch in der Admin-Oberfläche konfigurieren:

# 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)>

Siehe auch:

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

Siehe auch:

  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

Wie du dem Code entnehmen kannst, führt das Setzen dieser beiden Site-Einstellungen auf „blank“ dazu, dass keine Blockierung stattfindet:

SiteSetting.allowed_crawler_user_agents
SiteSetting.blocked_crawler_user_agents

Ich empfehle dir, dies nicht zu ändern, da diese von Discourse Core standardmäßig blockierten Bots robots.txt nicht einhalten. Es ist jedoch deine Website, und du kannst tun, was du möchtest. Es gibt einen guten Grund, warum sie im Core blockiert sind.

Trotzdem bietet dir Discourse über die Site-Einstellungen in der Benutzeroberfläche die Möglichkeit, diese Bots „freizugeben".

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

Warum sind semrushbot und ahrefsbot standardmäßig blockiert?

Verwandte Themen