Gestione del throttling dei crawler

Ho una domanda generale su come viene implementato il throttling del crawler.

Secondo Reduce Google Crawl Rate | Google Search Central  |  Documentation  |  Google for Developers lo stato HTTP consigliato è 429 (Troppe richieste) o 503 (Sito non disponibile).

Ma leggendo il codice sorgente sembra che il throttling sia implementato generando un errore: discourse/lib/rate_limiter.rb at 85fddf58bc1e751d0ac5b8192a630c59a34aed7d · discourse/discourse · GitHub

I miei giorni di Ruby on Rails sono ormai lontani, ma presumo che questo generi un generico 505?

Il crawler di Google non comprende appieno il throttling di discourse e in Google Search Console posso vedere che l’indicizzazione e quindi le impressioni sono drasticamente diminuite dopo l’implementazione del throttling, ma non a causa del throttling, bensì a causa di errori del server 5xx.

Capisco che le istanze di throttling possano essere a volte necessarie se causano troppo traffico, ma mi aspettavo che discourse segnalasse un HTTP 429, invece di servire al crawler un errore interno 505.

1 Mi Piace

Penso che quello che stai cercando sia

Che è il rescue “globale” del controller per quell’errore che imposta il codice di stato.

1 Mi Piace

Grazie! È rassicurante, ma non spiega del tutto perché Google Search Console segnali errori 5xx che coincidono con il momento in cui è stata implementata la limitazione.

Segnala persino che non è riuscito a recuperare il sitemap.xml di discourse.

In particolare, limitare la velocità di sitemap.xml sembra problematico.

Presumo che sia ciò che ha causato il divario nella copertura. Potrei credere che Google abbia segnalato erroneamente 429 come 5xx.

1 Mi Piace