Mit csinál valójában az ETag és a Last-Modified?
Rövid válasz. Mindkettő újraérvényesítő fejléc, vagyis nem attól gyorsul az oldal, hogy ott vannak, hanem attól, hogy a böngésző vagy a bot a lejárt másolatát egy 304-es válasszal is megerősítheti, teljes letöltés nélkül.
A Last-Modified egy időbélyeg, amit a szerver a válasszal küld. A kliens a következő kérésnél If-Modified-Since fejlécben visszaküldi, és ha a tartalom azóta nem változott, 304 Not Modified érkezik, üres törzzsel. Az ETag ugyanezt csinálja, csak nem idővel, hanem egy azonosító karakterlánccal, amit a szerver a fájl tartalmából vagy metaadataiból számol. A párja az If-None-Match kérésfejléc.
A kettő nem zárja ki egymást. A szabvány szerint ha mindkettő jelen van, a kliensnek az ETag-et kell erősebb validátornak tekintenie, a Last-Modified pedig tartalék marad. Hivatalosan igazolt, hogy az újraérvényesítés menetét az RFC 9110 és az RFC 9111 írja le, és hogy a Google Search Central dokumentációja külön kitér a 304-es válaszok helyes kiszolgálására a feltérképezési hatékonyság kapcsán.
Amit a legtöbb WordPress-oldalon félreértenek, az a következő. Ezek a fejlécek csak akkor érnek bármit, ha a Cache-Control már lejárt, vagy eleve rövid. Egy egy évre gyorsítótárazott, verziózott fájlnevű CSS-t a böngésző meg sem kérdez újra, ott az ETag pusztán egy plusz karakterlánc a válaszban.
Mi a különbség az erős és a gyenge ETag között?
Rövid válasz. Az erős ETag bájtra pontos egyezést ígér, a gyenge, amit a W/ előtag jelöl, csak annyit, hogy a tartalom jelentése ugyanaz.
Az erős ETag akkor és csak akkor egyezik, ha a két válasz törzse bájtról bájtra azonos. Ennek van egy nagyon gyakorlati következménye. Erős ETag mellett a szerver ki tud szolgálni Range-kéréseket, tehát a félbeszakadt letöltés folytatható, és a nagy fájl darabolva is kérhető. Gyenge ETag mellett az If-Range feltétel nem teljesül, a kliens az egészet újrakezdi.
A gyenge ETag nem hibás és nem is rosszabb minőségű. Pontosan arra való, hogy a szerver akkor is mondhasson igent az újraérvényesítésre, ha a bájtok közben megváltoztak, de a jelentés nem. Ilyen a különböző tömörítési szintekkel kiszolgált ugyanaz a HTML, vagy az a minifikáló, ami két futás között más sorrendbe rakja a szóközöket.
A formátum szabad szemmel is felismerhető. Az erős alak idézőjelek közé zárt karakterlánc, a gyenge ugyanaz, elé tett W/ jelöléssel. Szakmai feltételezés a részemről, hogy a magyar piacon futó WordPress-oldalak többségén a HTML-válasz vagy gyenge ETag-et kap, vagy egyáltalán nem kap ETag-et, mert a kimenetet menet közben tömöríti valami.
Miért ad sok magyar tárhely gyenge ETag-et?
Rövid válasz. Mert a tartalom a fájlrendszer és a kliens között még átmegy egy tömörítő vagy átíró rétegen, és ott a bájtra pontos ígéret már nem tartható.
A leggyakoribb okok hazai csomagokon a következők.
- Gzip vagy Brotli tömörítés a kiszolgálásnál. Az Apache
mod_deflatea tömörített válasz ETag-jét kiegészíti, az Nginx a gzip modul mellett gyengíti a sajátját, így megjelenik aW/előtag. - Fordított proxy a webszerver előtt. Sok tárhelyen Nginx ül egy Apache vagy LiteSpeed előtt, és a proxy-rétegben az eredeti validátor átíródik vagy elveszik.
- Osztott tárhely több kiszolgáló csomóponttal. Az Apache alapértelmezett ETag-je inode alapú, az inode viszont gépenként más. Ugyanaz a fájl két csomópontról két különböző ETag-et kap. Ez nem gyenge ETag, hanem annál rosszabb, mert fölöslegesen érvényteleníti a gyorsítótárat.
- PHP-ből generált válasz. A WordPress HTML-jét nem a webszerver adja fájlként, hanem a PHP állítja elő, és ETag-et alapból nem tesz rá, hacsak egy bővítmény vagy a tárhely nem gondoskodik róla.
Saját tapasztalat. Amikor magyar tárhelyeken végignéztem ezt, a statikus asseteknél szinte mindig volt valamilyen validátor, a HTML-nél viszont gyakran egyik sem, se ETag, se Last-Modified. A feedeknél vegyesebb a kép, ott a WordPress maga küld Last-Modified fejlécet, csak a tárhely cache-rétege néha lenyeli.
Hogyan olvasod ki a fejléceket curl-lel?
Rövid válasz. Egy curl -I hívás megmutatja, milyen validátor jön, egy második hívás pedig azt is, hogy a szerver tényleg ad-e 304-et.
Az első lépés a nyers fejléc-lista, külön a HTML-re és külön egy feltöltött képre.
curl -I https://pelda.hu/curl -I https://pelda.hu/wp-content/uploads/2026/01/kep.jpg
A kimenetből a Cache-Control, az ETag és a Last-Modified sor érdekes. A meglétük viszont még semmit nem bizonyít, a lényeg az, hogy a szerver reagál-e rájuk. Ezt így ellenőrzöd.
curl -I -H 'If-None-Match: "68f2c1-5f3a"' https://pelda.hu/wp-content/uploads/2026/01/kep.jpgcurl -I -H 'If-Modified-Since: Tue, 03 Feb 2026 09:12:44 GMT' https://pelda.hu/
Ha ezekre 304 jön vissza, a lánc működik. Ha 200-at kapsz a teljes fájllal, akkor a szerver figyelmen kívül hagyja a validátort, és minden bot minden körben újra letölti a képet. Ha a tömörített valóságot akarod látni, tedd hozzá az -H 'Accept-Encoding: gzip, br' kapcsolót, mert sok szerver csak ilyenkor vált gyenge ETag-re.
Melyik fejléc melyik oldaltípuson legyen ott?
Rövid válasz. Statikus asseten mindkettő rendben van, HTML-en a Last-Modified a fontosabb, feeden a kettő együtt hoz a legtöbbet, bejelentkezett felületen pedig egyik sem való.
- Statikus asset (kép, CSS, JS, betűtípus). Erős ETag és Last-Modified is hasznos, mellé hosszú
max-age, ahol lehet,immutablejelöléssel. Verziózott fájlnév mellett a validátor gyakorlatilag tartalék. - HTML (bejegyzés, oldal, kategória). Last-Modified szinte mindig indokolt, ETag opcionális, és ha van, legyen gyenge. Rövid vagy nulla
max-agemellett a 304 itt hoz valódi forgalom-megtakarítást. - RSS és Atom feed. Last-Modified és ETag együtt, mert az olvasók és az aggregátorok sűrűn kérdeznek rá ugyanarra az URL-re.
- Sitemap XML. Last-Modified fontos, ETag opcionális, és a fájlban szereplő
lastmodérték legyen összhangban a fejléccel. - Bejelentkezett felület, kosár, pénztár, REST API írási végpont. Egyik sem kell, sőt zavaró. Ide a
Cache-Control: no-storevaló. - Átirányítás és hibaoldal. Ne küldj validátort. A 301-et a böngésző amúgy is agresszívan tárolja, a 404-en pedig kifejezetten káros a hosszú életű gyorsítótár.
Hivatalosan igazolt, hogy a Google feltérképezője kezeli az If-Modified-Since és az If-None-Match fejléceket, és a 304-es válasz nem terheli ugyanúgy a feltérképezési kapacitást, mint egy teljes letöltés. Hogy ez egy adott oldalon mekkora nyereség, az már mérés kérdése.
Mikor írják felül a cache-bővítmények ezeket a fejléceket?
Rövid válasz. Szinte mindig, amikor statikus HTML-fájlt tesznek a dinamikus válasz helyére, mert onnantól a validátor forrása a cache-fájl, nem a tartalom.
- LiteSpeed Cache. A gyorsítótárazott találatot maga a LiteSpeed szerver adja vissza, a bővítmény saját fejléc-kezelésével. A
.htaccess-be írt direktíva a cache-elt válaszra nem feltétlenül hat. - WP Rocket. Statikus HTML-t ír a cache mappába, a kiszolgálást a webszerver végzi, így a Last-Modified a cache-fájl módosítási ideje lesz. Minden ürítés után frissül, akkor is, ha a tartalom betűre ugyanaz.
- W3 Total Cache. Külön kapcsolója van a böngésző-gyorsítótár fejlécekre, és ez felülírja a szerver beállítását. Ha az ETag eltűnt a bekapcsolása után, először itt keresd.
- Nginx FastCGI cache vagy Varnish. A validátor a gyorsítótár rétegéből jön, az eredeti PHP-válasz fejléce meg sem jelenik a kliens felé.
Saját tapasztalat. A leggyakoribb rejtett mellékhatás nem az, hogy eltűnik az ETag, hanem hogy a Last-Modified minden cache-ürítésnél előreugrik. Ha az oldal naponta többször ürít teljes cache-t (új bejegyzés, widget-módosítás, bővítmény-frissítés), akkor a botok minden körben 200-at kapnak, pedig a tartalom nem változott. Szakmai feltételezés, hogy ez több fölösleges forgalmat termel, mint amennyit az ETag finomhangolása valaha megspórolna.
Hogyan kapcsolod ki az ETag-et Nginx alatt, ha a CDN már kezeli?
Rövid válasz. Egyetlen etag off; sorral, utána pedig ellenőrzöd, hogy a Last-Modified megmaradt-e.
- Nyisd meg az oldal szerverblokkját, jellemzően a
/etc/nginx/sites-available/könyvtárban. - Tedd be az
etag off;sort a statikus asseteklocationblokkjába, vagy ha az egész oldalra kéred, aserverblokkba. - Ha a CDN a Last-Modified értéket használja gyorsítótár-kulcsként, azt hagyd bekapcsolva. Teljes letiltáshoz az
add_header Last-Modified "";és azif_modified_since off;páros kell, de erre ritkán van valódi ok. - Ellenőrizd a konfigot az
nginx -tparanccsal, majdsystemctl reload nginx. - Nézd meg curl-lel az eredeti szervert és a CDN peremcsomópontját is, mert a kettő válasza eltérhet.
Fontos, hogy az etag off; csak azokra a fájlokra hat, amiket maga az Nginx szolgál ki. A PHP-FPM felől érkező válasz fejléceit nem érinti.
És LiteSpeed alatt hol kapcsolható ki?
Rövid válasz. A .htaccess FileETag None direktívája a kiindulás, de a cache-elt találatokhoz a LiteSpeed Cache bővítmény beállítása is kell.
- Írd be a
FileETag Nonesort a.htaccessfájlba, a WordPress saját blokkja elé. A LiteSpeed az Apache direktívák nagy részét értelmezi. - Ha van WebAdmin hozzáférésed, a Server Configuration alatt a Tuning fülön találod a statikus fájlok kiszolgálásának beállításait.
- A LiteSpeed Cache bővítményben a Cache fül Browser almenüje írja felül az expires és cache-control fejléceket. Bekapcsoláskor a hozzá tartozó szabályok is a
.htaccess-be kerülnek, könnyen a te sorod alá. - Üríts teljes cache-t, különben a régi válaszok a régi fejlécekkel maradnak bent.
- Ellenőrizd curl-lel, és nézd meg az
x-litespeed-cachefejlécet is, mert abból derül ki, hogy a válasz a cache-ből vagy a PHP-ból jött.
cPanel-es tárhelyen a WebAdmin általában nincs kiadva, ilyenkor marad a .htaccess, a bővítmény és szükség esetén a szolgáltató ügyfélszolgálata.
Miért nem a látogatói sebességben jelentkezik a haszon?
Rövid válasz. Mert a visszatérő látogató a legtöbb assetet a lejárati idő alapján, hálózati kérés nélkül veszi elő, a 304-es kör pedig ugyanúgy egy teljes oda-vissza út.
Saját tapasztalat és saját nézőpont. Átlagos bemutatkozó oldalakon az ETag beállítása vagy kikapcsolása után a mért betöltési időkben nem látszott érdemi különbség. Ennek egyszerű oka van. Az első látogatásnál még nincs mit újraérvényesíteni, a másodiknál pedig a jól beállított max-age miatt a böngésző meg sem kérdezi a szervert. A 304 csak abban a szűk sávban segít, amikor a másolat már lejárt, de tartalmilag még érvényes.
Két helyzetben viszont tényleg számít. Az egyik a nagy képtár. Több ezer fotós galériánál, ingatlanos listánál vagy termékkatalógusnál a lejárt képek újraérvényesítése nagyságrendekkel kevesebb adat, mint az újratöltés, és a szerver oldali sávszélesség-számla is ezen múlik.
A másik a botforgalom. A keresőrobotok, a feed-olvasók, a monitorozó eszközök és az AI-feltérképezők nem tartanak hosszú távú böngésző-gyorsítótárat, viszont sokszor kérnek rá ugyanarra az URL-re. Náluk a helyes Last-Modified és a valóban működő 304 közvetlenül csökkenti a szerverterhelést. Ez jó eséllyel segítheti azt is, hogy a feltérképezési kapacitás az új és a tényleg frissült tartalomra menjen el, de helyezést vagy idézettséget önmagában nem garantál.
Mit érdemes végigfutni, mielőtt hozzányúlsz?
- Nézd meg
curl -Iparanccsal a főoldalt, egy bejegyzést, egy feltöltött képet és a feedet. - Ellenőrizd, hogy a 304-es kör tényleg lezajlik-e, ne csak a fejléc meglétét nézd.
- Ha a HTML Last-Modified értéke a cache-fájl idejét mutatja és naponta többször ugrik, keresd meg, mi üríti a cache-t.
- CDN mellett döntsd el, melyik réteg generálja a validátort, és ne generálja mind a kettő külön logikával.
- Osztott tárhelyen inode-alapú ETag esetén inkább kapcsold ki, mint hogy csomópontonként más értéket adjon.
- Bejelentkezett és fizetési felületre ne kerüljön validátor, oda
no-storevaló. - Változtatás után mindig üríts teljes cache-t, különben a régi fejlécekkel tárolt válaszokat méred.
- Jegyezd fel, mit változtattál és mikor, hogy a szerver-napló forgalmi adatait utólag össze tudd hasonlítani.
Források és további olvasnivalók
- RFC 9110, HTTP Semantics (IETF)
- RFC 9111, HTTP Caching (IETF)
- Google Search Central, HTTP status codes and HTTP caching dokumentáció
- Google Search Central, Crawl budget management for large sites
- MDN Web Docs, ETag, Last-Modified, If-None-Match és If-Modified-Since fejlécek
- nginx dokumentáció, ngx_http_core_module (etag, if_modified_since)
- Apache HTTP Server dokumentáció, FileETag direktíva
- LiteSpeed Web Server és LiteSpeed Cache for WordPress hivatalos dokumentáció
- WordPress Developer Resources, WP_Http és a feed-fejlécek kezelése
- Az erős ETag bájtra pontos egyezést ígér, a gyenge (W/ előtag) csak azonos jelentést, és emiatt nem támogat Range-kérést.
- Sok magyar tárhelyen a gzip vagy Brotli tömörítés, a fordított proxy és az inode-alapú alapbeállítás miatt lesz gyenge vagy csomópontonként eltérő az ETag.
- A cache-bővítmények statikus HTML-fájlt tesznek a dinamikus válasz helyére, ezért a Last-Modified gyakran a cache-fájl idejét, nem a tartalom változását mutatja.
- Ha a CDN már kezeli a validátorokat, Nginx alatt egy etag off; sor, LiteSpeed alatt a FileETag None plusz a bővítmény beállítása a megoldás.
- Az ETag önmagában ritkán mérhető nyereség, a 304-es kör működése viszont közvetlenül csökkenti a bot okozta szerverterhelést.
Gyakori kérdések
Honnan tudom, hogy erős vagy gyenge ETag-et küld a szerverem?
Futtasd le a curl -I parancsot az adott URL-re, és nézd meg az ETag sort. Ha a karakterlánc előtt W/ előtag áll, gyenge ETag-ről van szó, ha nincs előtag, erősről. Érdemes a kérést Accept-Encoding: gzip, br fejléccel is megismételni, mert sok szerver csak tömörített kiszolgálásnál vált gyengére.
Ha kikapcsolom az ETag-et, romlik ettől az oldal sebessége?
Önmagában jellemzően nem, feltéve, hogy a Last-Modified fejléc megmarad, és a szerver reagál az If-Modified-Since kérésre. A két validátor ugyanazt a célt szolgálja, és a HTTP-szabvány szerint a Last-Modified is elfogadott alap az újraérvényesítéshez. A tényleges sebességet sokkal inkább a Cache-Control lejárati ideje határozza meg.
Miért kapok minden kérésre 200-at, pedig ott van az ETag a válaszban?
Ilyenkor a szerver kiírja a fejlécet, de nem dolgozza fel a beérkező If-None-Match értéket, jellemzően azért, mert egy cache-réteg vagy egy proxy átírja a választ. Nézd meg, melyik réteg szolgálja ki a fájlt, és hogy a cache-bővítmény böngésző-gyorsítótár beállítása nem írja-e felül a szerverét.
A WordPress ad alapból Last-Modified fejlécet a bejegyzésekre?
A feedekre igen, a sima HTML-oldalakra viszont nem minden beállításnál. Ha a kimenetet cache-bővítmény vagy szerver oldali gyorsítótár szolgálja ki statikus fájlként, akkor a fejléc a cache-fájl módosítási idejét fogja mutatni, nem a bejegyzés utolsó szerkesztését.
Kell-e ETag, ha Cloudflare vagy más CDN van az oldal előtt?
Ha a CDN maga generál és kezel validátort, a származási szerveren fölösleges párhuzamosan is generálni, mert a két logika eltérő értékeket adhat. Ilyenkor Nginx alatt az etag off; a tiszta megoldás, a Last-Modified viszont maradjon, mert sok CDN ezt is használja az érvényesség ellenőrzésére.
Mit nyerek azzal, ha a botok 304-et kapnak?
Kevesebb kiszolgált bájtot és kisebb szerverterhelést, különösen sok képet vagy sok aloldalt tartalmazó oldalakon. Ez jó eséllyel segítheti, hogy a feltérképezési kapacitás a tényleg új tartalomra menjen el, de sem jobb helyezést, sem több AI-idézettséget nem garantál önmagában.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.