Google je pojasnio kako zaglavlje Retry-After, uz HTTP odgovore 503 ili 429, može da pomogne kada obilazak sajta opterećuje server. To nije nova funkcija niti promena algoritma. Za domaće prodavnice i portale vest znači jasnije uputstvo za kratke incidente: signalizirajte privremeni problem, otklonite uzrok i vratite normalne odgovore.

Izmena dokumentacije zabeležena je u izveštaju Search Engine Roundtablea od 6. oktobra 2026. Suština je važnija od naslova: Google nije uveo dugme kojim podešavate koliko često Googlebot dolazi. Dopunio je postojeće smernice primerima koje administrator može da primeni tokom preopterećenja.

Šta je Google zapravo promenio?

Prema izveštaju Search Engine Roundtablea, Google je reorganizovao deo uputstva o hitnom smanjenju saobraćaja svojih crawlera. Dodao je objašnjenje i primere zaglavlja Retry-After. Podrška za ovo zaglavlje postojala je ranije; sada je lakše pronaći u dokumentaciji koja se bavi upravo učestalošću obilaska.

Zvanično Google uputstvo za smanjenje crawl ratea navodi da odgovori 500, 503 i 429 mogu da posluže kao hitna mera za kratko vreme. Kao primere trajanja Google navodi nekoliko sati ili jedan do dva dana. To nisu preporučeni rokovi za redovno održavanje, već okvir za vanrednu situaciju.

Uz 503 ili 429 možete dodati Retry-After i naznačiti kada crawler može ponovo da pokuša. Google prihvata dva oblika: broj sekundi i apsolutni datum sa vremenom u UTC-u. Dokumentacija ne obećava da će svaki sledeći zahtev stići tačno po isteku navedenog vremena.

Promena je u objašnjenju. Nemojte ovu vest tumačiti kao novi faktor rangiranja ili način da ubrzate indeksiranje.

Kada ovo ima smisla za sajt u Srbiji?

Zamislite internet prodavnicu na ograničenom hosting paketu. Katalog ima nekoliko hiljada proizvoda, ali filteri po boji, veličini i ceni stvaraju mnogo više kombinacija URL-ova. Ako crawler obilazi veliki broj tih kombinacija, server obrađuje zahteve koji mu troše kapacitet, a kupcima stranice počinju sporo da se otvaraju.

Drugi primer je portal tokom incidenta: baza podataka radi usporeno, aplikacija se oporavlja, a dodatni zahtevi otežavaju stabilizaciju. U takvoj situaciji administratoru treba samo predah, bez trajnog zatvaranja sajta za Google.

Pre intervencije proverite:

  • Da li pristupni logovi zaista pokazuju nagli rast zahteva Googleovih crawlera?
  • Da li opterećenje dolazi od skupih stranica, filtera ili drugih izvora saobraćaja?
  • Da li se problem vidi u procesoru, memoriji, bazi ili sporim odgovorima aplikacije?
  • Može li hosting da ublaži incident bez promene odgovora za zdrave stranice?

Ime Googlebot u identifikacionom zaglavlju zahteva nije dovoljan dokaz porekla. Taj naziv može da pošalje i drugi program. Nemojte donositi odluku o blokiranju ili ograničavanju samo na osnovu tog podatka; tražite da administrator proveri poreklo saobraćaja.

Kako izgleda odgovor sa zaglavljem Retry-After?

Google daje jednostavan primer sa čekanjem od 120 sekundi:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

Odgovor govori da usluga trenutno nije dostupna, a zaglavlje naznačava kada ima smisla pokušati ponovo. Broj 120 je primer sintakse, a stvarno vreme treba da odgovara proceni trajanja problema.

Drugi dozvoljeni oblik je apsolutni datum:

HTTP/1.1 503 Service Unavailable
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

Ovo je primer iz Googleovog uputstva, pa ga ne kopirajte na produkcioni sajt. Koristite vreme koje odgovara vašem incidentu, u pravilnom HTTP formatu. Za većinu kratkih intervencija broj sekundi je jednostavniji za proveru.

Značenje zaglavlja definisano je u HTTP standardu RFC 9110. Bitno je i mesto primene: zaglavlje mora da bude u HTTP odgovoru. Tekst „pokušajte ponovo kasnije” na stranici nije zamena za njega.

Proveru stvarnog odgovora prepustite administratoru ili uradite kontrolisani HTTP zahtev. Posebno proverite da li CDN ili posrednički server menja status, uklanja zaglavlje ili zadržava odgovor duže nego što očekujete.

Da li treba koristiti 503 ili 429?

503 Service Unavailable opisuje privremenu nedostupnost usluge, na primer tokom održavanja ili preopterećenja. 429 Too Many Requests označava da je broj zahteva prevelik u odnosu na primenjeno ograničenje. Oba statusa Google navodi kao mogućnost uz Retry-After.

Izbor treba da odgovara stvarnom stanju sistema. Ako je aplikacija privremeno nedostupna, 503 je razumljiv signal. Ako postoje jasno definisana ograničenja učestalosti zahteva, administrator može da koristi 429 tamo gde je to opravdano.

Google navodi i 500 među odgovorima koji smanjuju crawling, ali za opisanu upotrebu zaglavlja Retry-After izričito daje 503 i 429. Nema razloga da namerno izazivate internu grešku servera ako sistem može da vrati precizniji odgovor.

Ne menjajte zdrave stranice u greške zato što ste pročitali vest. Ova mera ima smisla kada postoji stvarni operativni problem. Ako hosting radi normalno, normalan odgovor ostaje normalan odgovor.

Šta se dešava sa ostatkom sajta?

Važan detalj Googleovog uputstva lako promakne: kada infrastruktura za crawling naiđe na značajan broj URL-ova sa odgovorima 500, 503 ili 429, smanjuje učestalost obilaska na nivou celog hostnamea.

To obuhvata i URL-ove koji vraćaju grešku i URL-ove koji i dalje prikazuju sadržaj. Ako greške šaljete sa dela kataloga na istom hostnameu, nemojte pretpostaviti da će posledica ostati ograničena samo na taj deo. Google opisuje smanjenje za hostname, ne samo za pojedinačnu stranicu.

Kada se broj tih grešaka smanji, Google automatski ponovo povećava crawling. Ne daje obećanje o tačnom trenutku povratka prethodne učestalosti. Zato pratite stvarne logove i stanje servera umesto da oporavak procenjujete samo po jednom zahtevu koji je uspeo.

Ako objavljujete nove proizvode ili često menjate sadržaj, privremeno sporiji obilazak može da uspori otkrivanje promena. Kratak, kontrolisan incident nije isto što i višednevno ostavljanje sajta u neispravnom stanju.

Zašto ovo nije zamena za rešavanje problema sa URL-ovima?

Google među čestim uzrocima naglog rasta crawlinga navodi neefikasnu strukturu URL-ova: filtere i sortiranje, kalendare sa mnogo datuma, kao i određene situacije povezane sa Dynamic Search Ads ciljevima.

Za internet prodavnicu to znači da treba pogledati šta sistem uopšte omogućava crawleru da otkriva. Ako svaki filter pravi novu kombinaciju koju server skupo obrađuje, privremeni 503 ne sređuje strukturu kataloga i samo daje prostor da se bavite uzrokom.

Nakon stabilizacije proverite:

  • Koje grupe URL-ova stvaraju najviše zahteva i najsporije odgovore?
  • Da li interna navigacija vodi do nepotrebnih kombinacija filtera?
  • Da li keširanje stvarno smanjuje obradu ponovljenih zahteva?
  • Da li pravila za obilazak odgovaraju sadržaju koji želite u pretrazi?

Za širi pregled rada sa robotima koristan je tekst o Google crawlerima i pravilima u robots.txt. Nemojte, međutim, automatski preneti jedno pravilo na sve Googleove crawlere: imaju različite namene, što ilustruje i Mediapartners-Google za oglasne proizvode.

Šta uraditi kada hosting ne može da primeni ovu meru?

Google navodi mogućnost posebnog zahteva za smanjenje crawlinga ako na vašoj infrastrukturi nije izvodljivo vraćanje navedenih odgovora. U zahtevu treba opisati neuobičajeno visoku učestalost obilaska i navesti odgovarajuću stopu za sajt.

To nije trenutno rešenje. Google kaže da razmatranje i sprovođenje mogu potrajati nekoliko dana. Ovim putem ne možete tražiti povećanje učestalosti obilaska. Za incident koji traje sada, prvo razgovarajte sa hostingom o tome šta može odmah da uradi.

Najkorisnija poruka administratoru glasi: proveri poreklo i raspodelu zahteva, proceni privremenu meru i definiši kada je uklanjamo. Dogovorite i proveru da su posle oporavka normalni odgovori vraćeni na svim pogođenim rutama.

Šta da uradite pri preopterećenju

Google je jasnije dokumentovao postojeći način hitnog usporavanja svojih crawlera. Uz 503 ili 429, zaglavlje Retry-After može da naznači vreme za novi pokušaj, ali nije precizan raspored Googlebotovih poseta.

Za vlasnike sajtova u Srbiji redosled je praktičan: potvrdite uzrok opterećenja, uvedite kratkotrajnu i nadziranu meru samo ako je potrebna, pa rešite problem i vratite normalan rad. Zapamtite da smanjenje crawlinga može zahvatiti ceo hostname. Ako server radi dobro, ova vest nije razlog da menjate konfiguraciju.