A sitemap lastmod mezője a legolcsóbb jelzés, amit egy weboldal a keresőknek küldhet. Nincs hozzá fejlesztői projekt, nincs hozzá külön költségvetés, mégis sok oldalon pont ez a mező hazudik a legtöbbet. Nem szándékosan, hanem azért, mert a rendszer automatikusan írja felül, és senki nem nézte meg, hogy mit ír bele.
Ebben a cikkben végigveszem, mit jelent valójában ez a dátum, miért veszíti el a hitelét, hogyan ellenőrzöd, és hogyan hozod rendbe a leggyakoribb WordPress-sitemapokban. A szövegben külön jelölöm, mi hivatalosan igazolt információ, mi saját tapasztalat és mi szakmai feltételezés.
Mit jelent valójában a sitemap lastmod mezője?
A lastmod azt mondja meg, mikor módosult utoljára az adott URL tartalma. Nem utasítás, nem kérés, nem időzítő. Egy adat, amit a kereső mérlegel a többi jelzés mellett, amikor eldönti, mikor érdemes újra megnéznie az oldalt.
Hivatalosan igazolt: a sitemaps.org protokoll és a Google Search Central dokumentációja is úgy fogalmaz, hogy a lastmod akkor hasznos, ha pontos, és hogy a keresők figyelmen kívül hagyhatják, ha megbízhatatlannak találják. A Google emellett kimondta, hogy a changefreq és a priority mezőt nem használja, a lastmod viszont számít, ha következetes.
Egy tipikus sitemap-bejegyzés így néz ki.
<url><loc>https://pelda.hu/szolgaltatas/</loc><lastmod>2026-09-18T10:24:00+02:00</lastmod></url>
A dátumnak W3C Datetime formátumban kell állnia, időzónával vagy UTC-jelöléssel. A csak dátumot tartalmazó alak (2026-09-18) is érvényes, de a pontos időbélyeg hasznosabb, mert nagyobb oldalaknál megkülönbözteti az egy napon belüli változásokat.
Miért hagyják figyelmen kívül a keresők a hiteltelen lastmod értéket?
Azért, mert a kereső ellenőrizni tudja. Letölti az oldalt, összeveti a korábban tárolt változattal, és látja, hogy a törzsszövegből egyetlen karakter sem változott, csak a láblécben lévő évszám vagy egy "legutóbb frissítve" felirat. Ha ez sokszor ismétlődik, a rendszer megtanulja, hogy ezen a domainen a lastmod nem hordoz információt.
Szakmai feltételezés: a megbízhatóság szerintem nem URL-enként, hanem domain-szinten vagy legalábbis szakasz-szinten alakul ki. Vagyis ha a blogod minden nap hamis dátumot küld, azzal a valóban frissített szolgáltatásoldalad jelzését is gyengíted. Ezt hivatalos dokumentáció nem mondja ki ilyen formában, de a viselkedés, amit nagyobb oldalakon látok, ezzel konzisztens.
A következmény nem büntetés. Egyszerűen annyi történik, hogy a kereső visszaáll a saját becslésére, vagyis abból indul ki, milyen gyakran szokott változni az oldal, mennyire fontos, mennyi belső és külső hivatkozás mutat rá. Elveszítesz egy gyorsítósávot, amit ingyen használhattál volna.
Mi számít érdemi módosításnak, és mi nem?
A döntési szabály egyszerű. Akkor érdemi a változás, ha a felhasználó más döntést hozna az új verzió alapján, mint a régi alapján.
Ezek érdemi módosítások, ezeknél indokolt a lastmod frissítése.
- A törzsszöveg bővül, átíródik, új szakasz kerül bele, vagy elavult rész kikerül belőle.
- Változik az ár, a csomagtartalom, a szállítási feltétel vagy a garanciaidő.
- Változik az elérhetőség, a nyitvatartás, a cím, a telefonszám vagy a kiszolgált terület.
- Készlet- vagy elérhetőségi állapot vált egy terméknél, ha az a vásárlási döntést érinti.
- A címsor-szerkezet, a strukturált adat vagy a kanonikus hivatkozás változik.
Ezek nem érdemi módosítások, ezeknél hagyd békén a dátumot.
- Lábléc, fejléc, menü, sütibanner, oldalsáv, vagyis minden sablonelem, ami minden oldalon egyszerre változik.
- Új hozzászólás, értékelés vagy visszajelzés, hacsak nem kifejezetten a felhasználói tartalom az oldal lényege.
- Automata mezőfrissítés, például amikor egy plugin hozzányúl a poszt metaadataihoz, és a rendszer emiatt új módosítási időt ír.
- Elgépelés javítása, egy vessző, egy kép alt-szövegének apró pontosítása.
- Kapcsolódó bejegyzések blokkja, népszerű cikkek lista, bármilyen forgó tartalmi modul.
Saját tapasztalat: a határeset általában a bővülő GYIK. Ha egy meglévő oldalhoz három új, valódi kérdés és válasz kerül, az érdemi. Ha egy meglévő válasz szórendjét igazítod, az nem az. Érdemes írásban rögzíteni a saját szabályodat, mert különben a szerkesztők minden apró mentést frissítésnek szánnak.
Hogyan ellenőrzöd, hogy a lastmod értéked megbízható-e?
Az ellenőrzés lényege, hogy két adatsort hasonlítasz össze, a sitemapben szereplő dátumot és a tartalom tényleges változását. Ehhez nem kell drága eszköz.
- Töltsd le a sitemapet, és nézd meg a dátumok eloszlását. Ha a legtöbb URL-en ugyanaz a mai nap szerepel, az már önmagában gyanús. Parancssorból ez gyors, például
curl -s https://pelda.hu/sitemap.xmlkimenetéből kigyűjtöd alastmodsorokat, és megszámolod, hány esik ugyanarra a napra. - Válassz ki tíz oldalt vegyesen, régit és újat is. Mindegyiknél keresd meg, mikor változott utoljára a látható törzsszöveg. WordPressen ehhez a bejegyzés-revíziók listája ad támpontot, ha nincsenek kikapcsolva.
- Vesd össze a kettőt. Ha a sitemap szerint az oldal három napja frissült, a revíziók szerint viszont tizennégy hónapja nem nyúlt hozzá senki, akkor megvan a hiba.
- Nézd meg a mentett verziókat egy webarchívumban, ha nincs revíziód. Két időpont szövegét összevetve látod, változott-e bármi a sablonelemeken kívül.
- Vezess egy rövid táblázatot az URL-ről, a sitemap-dátumról, a valós változás idejéről és a különbségről. Húsz sor elég ahhoz, hogy lásd, rendszerhiba van-e vagy egyedi eset.
Mit mutat meg a Search Console, és mit nem?
A Search Console nem írja ki, hogy a lastmod értékedet hitelesnek fogadja-e el. Közvetett jeleket viszont ad.
A Sitemapek jelentésben látod, mikor olvasta be utoljára a rendszer a sitemapet, és hány URL-t talált benne. Ha a beolvasás dátuma hetekkel elmarad a te napi frissítéseidtől, az önmagában elgondolkodtató.
Az URL-ellenőrző eszköz megmutatja az utolsó feltérképezés idejét, és azt, hogy a feltérképezés sitemapből vagy hivatkozásból indult. Ha egy oldalt frissítesz, és a következő hetekben az utolsó feltérképezés dátuma nem mozdul, akkor nem a jelzés erősítése a következő lépés, hanem a tartalom és a belső hivatkozások megnézése.
A Feltérképezési statisztikák alatt a napi kérésszám és a válaszidők tendenciája látszik. Saját tapasztalat: ha a napi lastmod-frissítés bekapcsolása után a kérésszám nem mozdul, a hipotézis megdőlt, akármit is ígért a plugin leírása.
Hivatalosan igazolt: a Google közlése szerint a sitemap egy felfedezési és jelzési csatorna, nem indexelési ígéret. Attól, hogy egy URL benne van, és friss dátumot kap, még nem kerül be az indexbe, és nem is kerül feljebb.
Hogyan javítod a leggyakoribb WordPress-sitemapokat?
WordPress beépített sitemap
A WordPress 5.5 óta saját XML sitemapet ad a /wp-sitemap.xml címen. Ez alapból nem tesz lastmod mezőt a bejegyzésekhez, vagyis ha ezt használod, nincs mit elrontani. Ha szeretnél valódi dátumot, a wp_sitemaps_posts_entry szűrővel tudsz hozzáadni a post_modified_gmt értékből dolgozva. Ilyenkor a felelősség is a tiéd, tehát gondoskodj róla, hogy a mentés ne nyúljon hozzá feleslegesen ehhez a mezőhöz.
Yoast SEO
A Yoast a post_modified_gmt értékből dolgozik, és van egy hasznos kapcsolója, amivel egy szerkesztéshez jelölheted, hogy nem érdemi változás. A bejegyzés szerkesztőjében a Yoast dobozában megjelölheted, hogy a módosítás ne frissítse a dátumot. Ha tömeges keresés és csere után az egész oldalad friss lett, a leggyorsabb megoldás az érintett bejegyzések post_modified és post_modified_gmt mezőjének visszaállítása egy adatbázis-műveletben, mentés után.
Rank Math
A Rank Mathban a sitemap-beállítások között kapcsolható, hogy a lastmod egyáltalán bekerüljön-e, és kizárhatók bizonyos tartalomtípusok. Ha a sitemapedben szerepelnek címkearchívumok vagy szerzői oldalak, ott a dátum szinte mindig félrevezető, mert bármelyik hozzájuk tartozó bejegyzés mozgása frissíti őket. Ezeket az archívumokat érdemes kivenni a sitemapből, ha amúgy sincs önálló tartalmi értékük.
All in One SEO
Az AIOSEO sitemap-moduljában szintén állítható, hogy melyik tartalomtípus kerüljön be, és van gyorsítótár a sitemap mögött. Ha javítottál, de a kimenet nem változik, először a sitemap gyorsítótárát ürítsd, és csak utána keresd máshol a hibát.
WooCommerce termékek
Itt a leggyakoribb zaj a készletmozgás. Minden vásárlás csökkenti a készletet, ez hozzányúl a termék metaadataihoz, és sok konfigurációban új módosítási dátumot eredményez. Egy közepes webshopon ettől naponta több száz termék tűnik frissnek, holott a leírás, az ár és a paraméterek érintetlenek. Két megoldás kínálkozik, vagy leválasztod a készletmozgást a módosítási dátumról egy kisebb kódrészlettel, vagy elfogadod, hogy a termék-sitemapben a lastmod nem hordoz információt, és nem építesz rá.
Cache és statikus export
Ha oldal-gyorsítótárat, CDN-t vagy statikus exportot használsz, a sitemap könnyen elavul. Ellenőrizd, hogy a tartalom mentése után mennyi idővel frissül a kiszolgált XML. Saját tapasztalat: több esetben a valódi hiba nem a hamis dátum volt, hanem a fordítottja, vagyis az órákkal vagy napokkal korábbi állapotot kiszolgáló, gyorsítótárazott sitemap.
Miért nem gyorsítja a napi tömeges lastmod-frissítés az újralátogatást?
Ez a cikk saját nézőpontja, és a legfontosabb gyakorlati tanulság. A logika, ami mögötte áll, érthető. Ha a friss dátum újralátogatást hoz, akkor a napi friss dátum napi újralátogatást hoz. A gyakorlatban nem ez történik.
A keresők feltérképezési kapacitása véges, és nem egyetlen mezőn múlik, hogyan osztják el. Amikor mindent frissnek jelölsz, nem több figyelmet kapsz, hanem megszünteted a különbségtételt. Pont azt az információt dobod el, ami a lastmod egyetlen valódi haszna, vagyis hogy a kereső tudja, melyik ötven oldalt nézze meg a háromezerből.
Saját tapasztalat: a jól működő beállítás az, amikor egy hónapban a sitemap sorainak kis része visel friss dátumot, és mindegyik mögött van valódi szerkesztés. Az ilyen oldalakon a frissített URL-ek feltérképezése jó eséllyel gyorsabb, mint a mindent naponta frissítő állapotban volt. Ez megfigyelés, nem kontrollált kísérlet, tehát nem mondom ki oksági bizonyosságként.
Szakmai feltételezés: a jelzés hitelének visszaépítése hetekben mérhető, nem napokban, mert a rendszernek újra meg kell tanulnia, hogy a dátumod megbízható. Ezért nincs értelme egy hét után visszakapcsolni a régi beállítást azzal, hogy nem működött.
Számít a lastmod az AI-válaszmotoroknál is?
Az AI-asszisztensek és válaszmotorok jellemzően keresőindexre vagy saját feltérképezésre támaszkodnak, tehát közvetve ugyanaz a mechanizmus hat rájuk. Ha a friss tartalmad lassabban kerül be az indexbe, akkor a válaszmotor is a régebbi változatot idézheti.
Szakmai feltételezés: a frissesség itt még többet számít, mint a hagyományos találati listán, mert az idézett válasz egyetlen állapotot mutat a felhasználónak, összehasonlítási lehetőség nélkül. Ha az áraid vagy a nyitvatartásod elavultan jelenik meg egy asszisztens válaszában, azt a felhasználó a te hibádnak látja. Ez nem ok a napi tömeges frissítésre, hanem ok arra, hogy a valódi változásaid gyorsan és pontosan jelenjenek meg a sitemapben.
Milyen ellenőrzőlistával zárd le a munkát?
- A sitemap dátumai szórtak, nem esik a többségük ugyanarra a napra.
- Tíz véletlenszerű URL-nél a sitemap-dátum és a valódi utolsó szerkesztés egybeesik.
- A sablonelemek módosítása nem írja át egyetlen oldal dátumát sem.
- A hozzászólások és értékelések nem frissítik a bejegyzés módosítási idejét.
- A készletmozgás nem hat a termékek dátumára, vagy tudatosan elfogadtad, hogy hat.
- A dátumformátum W3C Datetime, időzónával, és nem áll a jövőben.
- A sitemap gyorsítótára percekben, nem napokban frissül a mentés után.
- A szerkesztőid tudják, mikor kell és mikor nem kell frissítésnek jelölni egy mentést.
- A Search Console Sitemapek jelentésében nincs olvasási hiba, és a beolvasás dátuma friss.
Ha ezeken végigmész, a lastmod meződ újra jelent valamit. Ez nem varázslat és nem is helyezés-javító trükk, hanem egy pontosan működő jelzés, ami segítheti, hogy a valódi frissítéseid hamarabb érjenek célba.
Források és további olvasnivalók
- Google Search Central, Sitemapek dokumentáció (Build and submit a sitemap)
- Google Search Central Blog, a sitemap mezők használatáról szóló közlemények
- Google Search Console súgó, Sitemapek jelentés és URL-ellenőrző eszköz
- Google Search Central, Feltérképezési statisztikák jelentés dokumentációja
- sitemaps.org, XML Sitemap protokoll 0.9 specifikáció
- W3C, Date and Time Formats (NOTE-datetime)
- WordPress Developer Resources, XML Sitemaps API és a kapcsolódó szűrők
- Bing Webmaster Tools dokumentáció, sitemapek és IndexNow
- A lastmod értéket a keresők csak akkor veszik figyelembe, ha következetesen a valódi tartalmi változást tükrözi.
- Érdemi módosítás a törzsszöveg, az ár és az elérhetőség változása, nem érdemi a lábléc, a hozzászólás vagy egy automata mezőfrissítés.
- Az ellenőrzés egyszerű: hasonlítsd össze a sitemapben szereplő dátumot azzal, mikor változott utoljára ténylegesen az oldal tartalma.
- A napi tömeges lastmod-frissítés nem gyorsítja az újralátogatást, viszont elrontja a jelzés hitelét.
- WordPressen a legtöbb hamis dátum plugin-beállításból, tömeges szerkesztésből vagy automata mezőírásból jön, és néhány lépésben rendbe tehető.
Gyakori kérdések
Ha nem vagyok biztos a lastmod helyességében, jobb, ha egyáltalán nem teszem bele?
Igen, ez védhető megoldás. A hiányzó lastmod semleges, a rendszeresen hamis viszont rontja a jelzés hitelét. A WordPress beépített sitemapje alapból nem is ad meg dátumot a bejegyzésekhez, és ettől még használható marad.
Meddig tart, amíg egy elrontott lastmod-jelzés újra megbízhatóvá válik?
Erre nincs hivatalos szám. Szakmai feltételezés, hogy hetekben mérhető, mert a keresőnek több feltérképezési körön át kell látnia, hogy a jelzett változások mögött valódi tartalmi módosítás áll. Ezért nem érdemes néhány nap után visszaállítani a régi beállítást.
A listaoldalakon és a kategóriaarchívumokon mit írjak a lastmod mezőbe?
Ott a legutóbb hozzáadott vagy módosított elem ideje a logikus érték, de ez könnyen zajossá válik. Ha az archívum önmagában nem hordoz tartalmi értéket, érdemesebb kivenni a sitemapből, mint megbízhatatlan dátummal benne tartani.
Segít az IndexNow, ha a lastmod nem hoz eredményt?
Az IndexNow egy külön értesítési csatorna, amit a Bing és több más kereső támogat, és a frissítés tényét közvetlenül jelzi. Ugyanaz a fegyelem vonatkozik rá, csak valódi változásnál küldj jelzést, különben ez a csatorna is veszít az értékéből.
A WooCommerce készletváltozása miatt minden nap friss lesz a termék-sitemapem. Ez baj?
Jelzés szempontjából igen, mert a leírás és az ár közben változatlan. Vagy leválasztod a készletmozgást a módosítási dátumról, vagy tudomásul veszed, hogy a termék-sitemapedben ez a mező nem hordoz információt, és nem építesz rá döntést.
Egy elgépelés javítása után frissítsem a dátumot?
Nem. A szabály az, hogy akkor frissíts, ha a felhasználó az új verzió alapján másképp döntene. Egy vessző vagy egy elütés javítása ebbe nem fér bele, egy árváltozás vagy egy új szakasz viszont igen.
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.