304 Not Modified és a feltételes kérések: így spórolsz a botok bejárásán

Scheo · 2026-09-13 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha nagy tartalmi archívumot üzemeltetsz, a Googlebot és a többi bejáró jó eséllyel naponta rengeteg olyan oldalt kér le, amely hónapok óta nem változott. A szerver ilyenkor általában újra legenerálja és teljes terjedelmében elküldi a HTML-t, pedig elég lenne egy rövid válasz is: nincs újdonság. Erre való a 304 Not Modified státuszkód és a feltételes kérés. Megnézzük, hogyan működik a Last-Modified és az ETag fejléc, hogyan méred fel a mostani állapotot, és milyen beállítási hibák miatt vész el a megtakarítás. Minden fontos állításnál jelöljük, hogy hivatalosan igazolt, saját tapasztalat vagy szakmai feltételezés.

Mit jelent a 304 Not Modified válasz?

A 304 Not Modified azt jelenti, hogy a kért erőforrás nem változott, mióta a kliens utoljára letöltötte. A szerver ezért törzs nélkül válaszol, a kliens pedig a nála tárolt példányt használja.

A 304 mindig feltételes kérésre érkezik. A kliens (böngésző, CDN vagy bejáró) a kérés fejlécében visszaküldi az előző letöltéskor kapott validátort, a szerver pedig összeveti a mostani állapottal. Ha a kettő egyezik, 304 jön, üres törzzsel. Ha nem, a megszokott 200 jön, a teljes tartalommal.

Hivatalosan igazolt: a HTTP szemantikáját leíró RFC 9110 szerint a 304-es válasznak nem lehet üzenettörzse. Ha a kérésben az If-None-Match és az If-Modified-Since is szerepel, az If-None-Match az erősebb.

Mi a különbség a Last-Modified és az ETag fejléc között?

A Last-Modified egy időbélyeg: azt mutatja, mikor változott utoljára az erőforrás. Az ETag egy szabadon választott azonosító (általában hash vagy verziószám), amely a tartalom egy adott változatát jelöli.

• Last-Modified: például Last-Modified: Tue, 01 Sep 2026 08:00:00 GMT. A kliens később az If-Modified-Since fejlécben küldi vissza. Másodpercre pontos, és az időt mindig GMT-ben kell megadni.
• ETag: például ETag: "a3f9c1-v12". A kliens az If-None-Match fejlécben küldi vissza. Lehet erős (pontos, bájtra egyező változatot jelöl) vagy gyenge. A gyengét a W/ előtag jelzi, például W/"a3f9c1".

A kettő megfér egymás mellett, érdemes mindkettőt küldeni. A Last-Modified könnyen érthető, és egyszerűen összeköthető a tartalomkezelő „utoljára módosítva” mezőjével. Az ETag rugalmasabb: olyan dolgot is beleírhatsz, ami nem időhöz kötött, például a sablon verzióját vagy a kapcsolódó cikkek blokkjának állapotát.

Hivatalosan igazolt: a Google Search Central 2024 decemberi, HTTP-gyorsítótárazásról szóló blogbejegyzése szerint ha a válaszban az ETag és a Last-Modified is szerepel, a Google bejárói a szabványnak megfelelően az ETag-et használják. A Google az ETag-et ajánlja, mert kevésbé hibaérzékeny: nincs vele dátumformátum-gond.

Hogyan használja a Googlebot a feltételes kérést?

Amikor a Googlebot újra bejár egy korábban már letöltött URL-t, visszaküldheti az előző válaszból kapott ETag-et az If-None-Match, a Last-Modified értékét pedig az If-Modified-Since fejlécben. Ha a szerver 304-gyel felel, a tárolt változatot használja tovább.

Egy archív cikknél ez így zajlik:

1. Első bejárás: a Googlebot lekéri az URL-t, a szerver 200-zal válaszol, a válaszban ETag: "cikk-4812-r3" és Last-Modified: Tue, 01 Sep 2026 08:00:00 GMT.
2. Újrabejárás: a kérésben megjelenik az If-None-Match: "cikk-4812-r3" és/vagy az If-Modified-Since: Tue, 01 Sep 2026 08:00:00 GMT fejléc.
3. Ha a cikk nem változott, a szerver 304 Not Modified választ ad, törzs nélkül.
4. Ha közben javítottál a cikken, új ETag keletkezik (például r4), és a szerver 200-zal elküldi a friss tartalmat.

Hivatalosan igazolt: a Google bejáróinak dokumentációja szerint a Google bejárási rendszere támogatja a HTTP-gyorsítótárazást az ETag/If-None-Match és a Last-Modified/If-Modified-Since fejlécpárokkal. A dokumentáció azt is kimondja, hogy az egyes bejárók a hozzájuk tartozó termék igényei szerint vagy használják a gyorsítótárat, vagy nem. Arra tehát nincs ígéret, hogy minden újrabejárás feltételes kérés lesz.

Szakmai feltételezés: a 304 önmagában nem rangsorolási jelzés, csak kevesebb adat megy át, és olcsóbb lesz a bejárás. Logikusnak tűnik, hogy emiatt több bejárási kapacitás jut a ténylegesen változó oldalakra, de a Google ezt nem számszerűsíti.

Miért kap az oldalad feleslegesen 200-as választ minden bejárásnál?

Többnyire azért, mert a dinamikusan generált HTML oldalak alapból semmilyen validátort nem küldenek. A bejárónak így nincs mit visszaküldenie, a szervernek pedig nincs mihez hasonlítania.

Statikus fájloknál (képek, CSS, JavaScript) a webszerver, például az Nginx vagy az Apache, a fájl módosítási ideje és mérete alapján magától küld Last-Modified és ETag fejlécet. A PHP-ből, Node-ból vagy más alkalmazásból érkező HTML-nél ez nem így van. Amíg az alkalmazás nem állítja be ezeket a fejléceket, a válasz validátor nélkül megy ki, és minden bejárás teljes, 200-as letöltés lesz.

Saját tapasztalat: WordPress-oldalak átvizsgálásakor gyakran látjuk, hogy a képek és a stíluslapok rendesen 304-et adnak, a cikkoldalak viszont soha. A tulajdonos ezt nem veszi észre, mert a böngészőben semmi nem látszik belőle.

A másik gyakori ok, hogy van ugyan validátor, de hibás: minden kérésnél más az értéke, így a feltétel soha nem teljesül. Az alábbi mérési lépésekkel ez gyorsan kiderül.

Hogyan ellenőrizd curl-lel a fejléceket?

Kérd le egyszer az oldalt, hogy megkapd a validátorokat, aztán küldd vissza őket feltételes fejlécben. Ha a második válasz 304, a mechanizmus működik. Ha 200, valahol hiba van.

1. Fejlécek lekérése. curl -sI https://pelda.hu/archiv/regi-cikk/. A válaszban keresd az ETag, a Last-Modified és a Cache-Control sort.
2. Ismételt lekérés. Futtasd le még kétszer, egymás után. Ha az ETag vagy a Last-Modified minden alkalommal más, meg is van a hiba.
3. Feltételes kérés ETag-gel. curl -sI -H 'If-None-Match: "a3f9c1-v12"' https://pelda.hu/archiv/regi-cikk/. Az ETag értékét az idézőjelekkel együtt másold be. Ezt kell kapnod: HTTP/2 304.
4. Feltételes kérés dátummal. curl -sI -H 'If-Modified-Since: Tue, 01 Sep 2026 08:00:00 GMT' https://pelda.hu/archiv/regi-cikk/. Pontosan azt a Last-Modified értéket add meg, amelyet kaptál.
5. Próba GET-tel is. A -I kapcsoló HEAD kérést küld, és egyes szerverek vagy gyorsítótárak másként válaszolnak HEAD-re. Nézd meg GET-tel is: curl -s -o /dev/null -D - -H 'If-None-Match: "a3f9c1-v12"' https://pelda.hu/archiv/regi-cikk/.
6. Próba tömörítéssel. Tedd hozzá a -H 'Accept-Encoding: gzip, br' fejlécet is. A bejárók tömörített választ kérnek, a tömörítés pedig megváltoztathatja az ETag értékét.

Ha az oldal előtt CDN van, a teszt a CDN viselkedését méri. Futtasd le közvetlenül az eredeti szerveren is (például a curl --resolve kapcsolójával), így kiderül, melyik réteg rontja el a fejléceket.

Mit mutat a Search Console Bejárási statisztikák jelentése?

A Bejárási statisztikák jelentésben a válaszkód szerinti bontás külön sorban mutatja, hogy a Google bejárási kéréseinek hány százaléka kapott 304-es (Not modified) választ.

A jelentést a Search Console Beállítások menüjében találod. A magyar felületen „Feltérképezési statisztikák” néven is szerepelhet, angolul Crawl stats. Nagyjából az elmúlt 90 nap adatait mutatja. Így olvasd:

• Válasz szerinti bontás (By response): nézd meg, hány százalék a 304-es sor. Ha nincs ilyen sor, vagy közel nulla, egy nagyobb archívumnál szinte biztos, hogy a HTML oldalak nem adnak 304-et.
• Fájltípus szerinti bontás (By file type): ha a kérések nagy része HTML, a 304-ek aránya viszont alacsony, akkor ott van a megtakarítási lehetőség.
• Cél szerinti bontás (By purpose): a Refresh (újrabejárás) és a Discovery (új URL felfedezése) arányából látod, mennyi az ismételt bejárás. Sok újrabejárás és alacsony 304-es arány együtt a klasszikus pazarlás.
• Átlagos válaszidő: a javítás után figyeld. A törzs nélküli válaszok jó eséllyel lejjebb viszik az átlagot.

Hivatalosan igazolt: a jelentés a Google bejáróinak kéréseit mutatja, válaszkód, fájltípus, cél és Googlebot-típus szerint bontva. Az oldal és az általa használt erőforrások külön kérésnek számítanak, ezért a számok nem egyeznek az oldalak számával.

Hogyan számold ki a 304-es arányt a szerver access logjából?

Szűrd ki a hitelesített Googlebot HTML-oldalakra küldött kéréseit, számold meg a 200-as és a 304-es válaszokat, majd oszd el a 304-esek számát a kettő összegével.

A Search Console összesített képet ad, a log viszont minden egyes URL-t megmutat. Az Apache és az Nginx szokásos combined naplóformátumában a státuszkód a kilencedik mező.

1. A Googlebotnak adott státuszkódok eloszlása: grep 'Googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
2. 304-es arány csak a HTML-re (statikus fájlok nélkül): grep 'Googlebot' access.log | grep -vE '\.(css|js|png|jpe?g|webp|svg|woff2?)' | awk '$9==200{a++} $9==304{b++} END{if(a+b) printf "304 arany: %.1f%%", 100*b/(a+b)}'
3. Hitelesítés: a user-agentet bárki meghamisíthatja. Az IP-címet fordított DNS-lekérdezéssel ellenőrizd (host 66.249.66.1): a névnek googlebot.com vagy google.com végződésűnek kell lennie, és az előre irányú lekérdezésnek ugyanarra az IP-re kell visszamutatnia. Másik lehetőség, hogy összeveted a Google által közzétett IP-tartományokkal.
4. Lista URL-enként: nézd meg, mely régi URL-ek kapnak rendszeresen 200-at: grep 'Googlebot' access.log | awk '$9==200{print $7}' | sort | uniq -c | sort -rn | head -50. Ha ezek hónapok óta változatlan cikkek, velük kezdd a javítást.

Az aránynál ne feledkezz meg arról, hogy 304 csak feltételes kérésre jöhet. Ha a naplóformátumba felveszed a kérés If-None-Match fejlécét (Nginx-nél $http_if_none_match, Apache-nál %{If-None-Match}i), azt is látod, hány kérés érkezett validátorral, és ezekre hányszor adott a szerver 304-et.

Szakmai feltételezés: egy ritkán frissülő, nagy archívumnál jó beállítás mellett a HTML-kérésekre számolt 304-es arány várhatóan érezhetően nő a mostani, közel nulláról. Pontos célszámot viszont nem érdemes kitűzni, mert a Google oldalanként másként jár be.

Mikor rossz a helyzet, pedig látszólag van ETag és Last-Modified?

Akkor, ha a validátor nem a tartalom változását követi: minden kérésnél új ETag keletkezik, a Last-Modified mindig az aktuális időt mutatja, vagy egy gyorsítótár-réteg felülírja, esetleg el is dobja a fejléceket.

Minden lekérésnél változó ETag

Ennek jellemzően három oka van. Az első, hogy az ETag olyan HTML-ből készül, amelyben kérésenként változó elem van, például CSRF-token, nonce, időbélyeg vagy véletlenszerű ajánlóblokk. A második, hogy több szerver mögött fájlrendszer-inode alapján számolt ETag gépenként eltér (ez régebbi vagy egyedi Apache-beállításnál fordul elő). A harmadik, hogy a tömörítő modul átírja az értéket: az Apache mod_deflate például -gzip utótagot fűz az ETag-hez, ami bizonyos verzióknál és beállításoknál megakadályozta a 304-et. A megoldás: az ETag a tartalom stabil adataiból készüljön (bejegyzés-azonosító, módosítási idő, sablonverzió), ne a kész HTML-ből.

Dinamikusan generált Last-Modified

Ha az alkalmazás a Last-Modified értékének a kiszolgálás pillanatát adja meg, az If-Modified-Since feltétel soha nem teljesül, hiszen a tartalom mindig „most” változott. Ugyanilyen hiba, ha az érték a legutóbbi hozzászóláshoz, a láblécben vagy a menüben történt módosításhoz kötődik, mert így az egész archívum egyszerre „frissül”. A helyes forrás a tartalom tényleges, érdemi módosítási ideje. Ha viszont a sablon változik, az valódi változás, ilyenkor rendben van, hogy minden oldal új validátort kap.

Gyorsítótár-bővítmény vagy CDN által felülírt fejlécek

A WordPress gyorsítótár-bővítmények előre elkészített, statikus HTML-t szolgálnak ki, a CDN-ek pedig a saját logikájuk szerint kezelik a validátorokat. Bármelyik réteg eldobhatja az eredeti szerver helyes ETag-jét, gyengére cserélheti, vagy Last-Modified értékként a gyorsítótárba mentés idejét adhatja vissza. A Cloudflare például tömörítéskor alapból gyengévé alakítja az erős ETag-et, ezt a Respect Strong ETags beállítással lehet megváltoztatni. Egyes HTML-módosító funkcióinál az ETag akár el is tűnhet. Saját tapasztalat: a fejléchibák jó része nem az alkalmazásban keletkezik, hanem a köztes rétegekben. Ezért mindig rétegenként tesztelj: eredeti szerver, gyorsítótár-bővítmény, CDN.

A fordított hiba: téves 304

Ha az ETag csak a cikk szövegéből készül, közben pedig a kapcsolódó cikkek, a belső linkek vagy a strukturált adatok változnak, a szerver akkor is 304-et ad, és a bejáró megtartja a régi változatot. Ez rosszabb, mint a felesleges 200, mert a módosításod nem jut el a keresőhöz.

Úgy csökkenti a szerverterhelést, hogy a friss tartalom indexelése nem lassul?

Jó beállítás mellett igen. A változatlan oldalak rövid 304-et kapnak, a módosult oldalak azonnal új validátort és 200-at, így a friss tartalom ugyanúgy eljut a bejáróhoz, csak a felesleges letöltések maradnak el.

Nagy tartalmi archívumnál ezt az egyik legolcsóbb szerveroldali optimalizálásnak tartjuk. Két feltétele van:

• A validátort olcsón számold ki. Ha előbb legenerálod a teljes oldalt, és csak utána készítesz belőle hasht, a sávszélességen spórolsz, a processzoridőn és az adatbázis-lekérdezéseken alig. Az igazi megtakarítás akkor jön, ha az alkalmazás már a kérés elején, egyetlen könnyű lekérdezésből (például a bejegyzés módosítási idejéből és a sablonverzióból) eldönti, hogy 304-et ad.
• Minden változás hozzon új validátort. Ha ez teljesül, a mechanizmus nem lassítja a friss tartalom indexelését, hiszen módosult oldalra soha nem megy ki 304.

Hivatalosan igazolt: a Google nagy oldalaknak szóló bejárásikeret-útmutatója szerint a bejárási kerettel főleg nagy oldalaknál érdemes foglalkozni: nagyjából 1 millió egyedi oldal fölött, ha a tartalom hetente változik, vagy 10 000 oldal fölött, ha naponta. Az útmutató szerint a gyorsan válaszoló szervernél a Google növelheti a bejárási kapacitást. Kisebb oldalnál a 304 inkább a szerverterhelésről és a sávszélességről szól, mint az indexelésről. Szakmai feltételezés: a kisebb, gyorsabb válaszok jó eséllyel hozzájárulnak ahhoz, hogy a bejárás ne lassuljon le a szerver terhelése miatt. Azt azonban, hogy ebben mekkora szerepe van a 304-nek, a Google nem számszerűsíti, és gyorsabb indexelést sem garantál.

A sitemap lastmod értékét érdemes ugyanabból a módosítási időből venni, mint a Last-Modified fejlécet. A Google akkor használja a lastmod értéket, ha az következetesen pontos, így a két jelzés erősíti egymást.

Mi legyen az ellenőrzőlistádon?

Ezt a hét pontot érdemes végignézni, és a javítás után havonta megismételni:

• A HTML oldalak küldenek ETag és/vagy Last-Modified fejlécet.
• Két egymás utáni lekérésnél ugyanazok az értékek.
• Feltételes kérésre HEAD-del és GET-tel is 304 jön, törzs nélkül.
• Tömörített válasz kérésekor is 304 jön.
• Ha módosítod a cikket, új ETag és új Last-Modified keletkezik.
• A Search Console Bejárási statisztikák jelentésében megjelenik a 304-es sor, és a javítás után az aránya nő.
• A logból havonta kiszámolod és feljegyzed a hitelesített Googlebot HTML-kéréseinek 304-es arányát, a teszteket pedig rétegenként (eredeti szerver, bővítmény, CDN) futtatod.

Források és további olvasnivalók

• Google Search Central: Overview of Google crawlers and fetchers (HTTP caching)
• Google Search Central Blog: Crawling December: HTTP caching (2024)
• Google Search Central: Large site owner's guide to managing your crawl budget
• Google Search Console súgó: Crawl Stats report
• Google Search Central: Verifying Googlebot and other Google crawlers
• Google Search Central: Build and submit a sitemap
• IETF RFC 9110: HTTP Semantics
• IETF RFC 9111: HTTP Caching
• Cloudflare Docs: ETag headers
• Apache HTTP Server dokumentáció: FileETag direktíva, mod_deflate