Umgang mit Crawler-Drosselung

Ich hatte eine allgemeine Frage, wie die Crawler-Drosselung implementiert wird.

Laut Reduce Google Crawl Rate | Google Search Central  |  Documentation  |  Google for Developers ist der empfohlene HTTP-Status 429 (Zu viele Anfragen) oder 503 (Website nicht verfügbar).

Beim Durchlesen des Quellcodes sieht es jedoch so aus, als ob die Drosselung durch Auslösen eines Fehlers implementiert wird: discourse/lib/rate_limiter.rb at 85fddf58bc1e751d0ac5b8192a630c59a34aed7d · discourse/discourse · GitHub

Meine Ruby on Rails-Tage liegen lange hinter mir, aber ich gehe davon aus, dass dies einen generischen 505 auslöst?

Der Google-Crawler versteht die Drosselung von Discourse nicht ganz und in der Google Search Console sehe ich, dass unsere Indexierung und damit die Impressionen nach der Implementierung der Drosselung drastisch reduziert wurden, aber nicht aufgrund der Drosselung, sondern aufgrund von 5xx-Serverfehlern.

Ich verstehe, dass Drosselungsinstanzen manchmal notwendig sein können, wenn sie zu viel Traffic verursachen, aber ich hatte erwartet, dass Discourse eine HTTP 429 meldet, anstatt dem Crawler einen 505 Internal Error zu servieren.

1 „Gefällt mir“

Ich glaube, wonach Sie suchen, ist

Dies ist die “globale” Controller-Rettung für diesen Fehler, die den Statuscode festlegt.

1 „Gefällt mir“

Danke! Das ist beruhigend, erklärt aber nicht ganz, warum die Google Search Console 5xx-Fehler meldet, die mit der Implementierung der Drosselung korrelieren.

Sie meldet sogar, dass sie die discourse sitemap.xml nicht abrufen konnte.

Insbesondere scheint die Drosselung von sitemap.xml problematisch zu sein.

Ich gehe davon aus, dass dies die Lücke in der Abdeckung verursacht hat. Ich könnte mir vorstellen, dass Google 429 fälschlicherweise als 5xx meldet.

1 „Gefällt mir“