A frissesség mint hivatkozási jelzés: Frissítési gyakoriság, utolsó módosítás és hírszitemapok

A frissesség mint hivatkozási jelzés: Frissítési gyakoriság, utolsó módosítás és hírszitemapok

Írta: Lukas Richter, vezető tartalomautomatizálási stratégiai szakértő

Egy oldal friss dátuma önmagában nem garantálja a hivatkozásokat. Egy értelmes frissítés segíthet az AI-összefoglalónak a tartalom helyes verziójának használatában, de egy dátumbélyegző önmagában nem bizonyítja, hogy az oldal hasznos – vagy aktuális.

A gyakorlati feladat az, hogy egy pontos változás felderítésre, feltérképezésre, indexelésre, majd kiválasztásra kerüljön egy releváns válaszhoz. Ezek különálló lépések. Egy keresőmotor lekérhet egy frissítést anélkül, hogy indexelné azt. Egy AI rendszer indexelhet egy oldalt anélkül, hogy hivatkozna rá.

A legerősebb rendszer nem az „minden oldalt minden héten frissíteni”. Ez egy hibrid: értelmes ütemezés szerint felülvizsgálni, és gyorsan reagálni, ha fontos tények változnak. Használjon pontos dátumokat és változási jelzéseket, hogy a valódi frissítéseket könnyebb legyen megtalálni. Ne kreáljon mesterséges frissességet egy algoritmus kedvéért.

Mit jelent a frissesség az AI hivatkozások szempontjából

A „frissesség” több különböző dologra is utalhat:

1. Tartalmi frissesség: Mikor ellenőrizték vagy módosították utoljára az oldalon található értelmes tényt vagy ajánlást.
2. Feltérképezési gyakoriság: Mikor kérdezte le utoljára a keresőmotor az oldalt.
3. Indexelési gyakoriság: Mikor kezdte el a keresőmotor indexe tükrözni a frissített verziót.
4. Hivatkozási gyakoriság: Mikor választotta ki utoljára egy AI összefoglaló azt az oldalt forrásként egy lekérdezésre.

Ezek az órák nem mozognak együtt. Egy oldal rendelkezhet új lastmod dátummal, de régi verzióval az indexben. Lehet aktuális az indexben, de mégis elveszíthet egy hivatkozást egy tisztább, megbízhatóbb forrással szemben.

A Google szerint rendelkezik frissességi rendszerekkel az olyan keresésekhez, ahol a felhasználók valószínűleg új információkat szeretnének. Generatív AI funkciói szintén a Google Keresési indexében található tartalmakra támaszkodnak. A Microsoft hasonlóképpen állítja, hogy a pontos, naprakész tartalom számít az AI által generált válaszokba való bekerüléshez. Ez azt támasztja alá, hogy a frissességet a lekérdezés részének tekintsük – nem pedig garantált hivatkozási löketnek. Source 1 Source 2 Source 3 (developers.google.com)

Mit mutat – és mit nem – a bizonyíték

Az Ahrefs közel 17 millió hivatkozott URL elemzése megállapította, hogy az AI asszisztensek átlagosan újabb oldalakra hivatkoztak, mint a Google organikus keresési eredményei. Ez azonban egy megfigyelésen alapuló összehasonlítás volt, nem pedig annak tesztje, hogy egy dátum megváltoztatása vagy egy fix ütemezés szerinti publikálás okozta-e, hogy egy oldalra hivatkoztak. Az eredmények platformonként is eltértek: a Google AI Áttekintések körülbelül olyan régi oldalakra hivatkoztak, mint organikus eredményei, míg a ChatGPT átlagosan újabb oldalakat idézett. Source 4 (ahrefs.com)

Egy 2025-ös tanulmány, amely a forrásokat vizsgálta fogyasztói elektronikai és autóipari lekérdezésekben, szintén különbségeket talált az AI platformok és a tématerületek között. Tanulmánya két vertikumra korlátozódott, és a hivatkozott oldalak korát mérte; nem hasonlította össze a fix frissítési ütemezéseket a reaktív frissítésekkel. Source 5 (arxiv.org)

A hasznos következtetés szerény: a frissesség akkor tűnik fontosabbnak, ha maga a kérdés is elavulhat, és a mértéke keresési termékenként változik. A nyilvános kutatás nem támasztja alá, hogy a heti frissítési gyakoriság felülmúlná a reaktívat, vagy hogy egy látható „Ma frissítve” bélyegző közvetlenül növelné az AI hivatkozási arányát.

Mire képes az egyes frissességi jelzés

A Google következetes, látható dátumokat és strukturált dátuminformációkat javasol, ha azt szeretné, hogy megértse a publikálási vagy frissítési dátumokat. Nem garantálja, hogy ezeket a dátumokat meg fogja jeleníteni az eredményekben. A Google azt is mondja, hogy triviális szerkesztéseket nem szabad felhasználni arra, hogy egy oldal frissnek tűnjön. Source 6 Source 7 Source 8 (developers.google.com)

Fix ütemezés versus reaktív frissítések

Nincs nyilvános, ellenőrzött tanulmány, amely eldöntené, melyik megközelítés eredményez több AI hivatkozást. A mechanizmusok azonban egyértelművé teszik a kompromisszumot.

A Google számára a sitemap javaslat, nem parancs. A Google szerint a legtöbb oldalnak számolnia kell azzal, hogy a feltérképezés és indexelés több napig vagy tovább is tarthat; az aznapi kezelés valószínűbb híroldalak vagy más nagyon időérzékeny tartalmak esetében, de nem garantált. A Bing és más IndexNow résztvevők számára egy beküldés felgyorsíthatja egy megváltozott URL felderítését, de egy beküldés elfogadása nem garantálja az azonnali indexelést. Source 9 Source 10 (developers.google.com)

Javaslatom: használjon naptárat biztonsági hálóként, ne az oldal módosításának okaként. Állítson be eseményindítókat olyan tényekhez, amelyek károkat vagy elmaradt eladásokat okozhatnak, ha elavulnak. A többi esetében a felülvizsgálati intervallumot az alapján válassza meg, hogy tényei milyen gyorsan változnak.

Technikai útmutató: dátumok, sitemapek és fejlécek

Legyen a <lastmod> igaz

Helyezze a legutóbbi értelmes oldalváltozást a sitemapbe. A Google szerint használhatja a <lastmod> értéket, ha az következetesen pontos és ellenőrizhető. A fő tartalom, strukturált adatok vagy linkek változásai számíthatnak; a szerzői jogi év megváltoztatása nem. A Google figyelmen kívül hagyja a priority és changefreq értékeket. Source 7 (developers.google.com)

xml https://example.com/guides/current-pricing/ YYYY-MM-DDThh:mm:ss+00:00

Adja meg az indexelni kívánt kanonikus URL-t. A időbélyegzőt a tartalomrekordból vagy a publikálási rendszerből generálja – nem abból az időpontból, amikor a sitemap fájl elkészült. Ha egy oldal nem változott értelmesen, hagyja érintetlenül a <lastmod> értékét.

Illessze össze a látható dátumot és a strukturált adatokat

Tartsa összhangban az oldal látható címkéjét, a strukturált adatokat, a sitemap dátumát és a szerver dátumát. Egy cikk esetében a datePublished maradjon az eredeti publikálási dátum; frissítse a dateModified értéket, amikor az oldalt értelmesen átdolgozzák. Használjon ISO 8601 dátumot időzónával a strukturált adatokban. Source 6 Source 11 (developers.google.com)

{ "@context": "https://schema.org", "@type": "BlogPosting", "datePublished": "2025-07-10T09:00:00-04:00", "dateModified": "2026-10-21T10:15:00-04:00" }

A példa külön dátumokat használ, mert egy frissítésnek nem szabad egy régi cikket újonnan publikáltnak láttatnia.

Csak hírekhez használjon hírszitemapot

A hírszitemap híradó kiadóknak és hírcikkeknek szól, nem pedig az örökzöld oldalak átcímkézésének gyorsítósávja. A Google szerint az új cikkeket publikálásukkor hozzá kell adni, csak az utolsó két napban létrehozott cikkeket kell a hír részben tartani, és tartalmazniuk kell az eredeti publikálási dátumot. Egy sitemap legfeljebb 1000 news:news bejegyzést tartalmazhat. A Google azt is állítja, hogy a hírszitemapokat ugyanolyan gyakran térképezik fel, mint az oldal többi részét, így nem jelentenek garantált gyorsítósávot. Source 12 (developers.google.com)

Állítsa be a HTTP fejléceket a pontos ellenőrzéshez

A HTTP Last-Modified fejléc azt írja le, hogy a szerver mikor vélte utoljára megváltozottnak az oldal reprezentációját. Az ETag a reprezentációnak egy verzióazonosítót ad. Ezek a feltételes kérésekkel együtt segíthetnek a crawlernek elkerülni a teljes válasz letöltését, ha semmi sem változott. A HTTP szabvány szerint egy szerver 304 Not Modified státuszt adhat vissza, ha a kért verzió még aktuális. Source 13 (rfc-editor.org)

http Last-Modified: ETag: ""

A Google szerint a crawlerek általában támogatják az If-Modified-Since és az If-None-Match fejléceket, de nem küldik el azokat minden feltérképezésnél. Egy helyes 304 állapotkód spórolhatja a lekérdezési munkát, ha az oldal változatlan. Ezek a fejlécek segítik a szervereket és a crawlereket a verziók hatékony kezelésében; nem ígérnek gyorsabb indexelést vagy több hivatkozást. Source 9 Source 13 (developers.google.com)

Mutassa meg, mi változott

Tartsa a fő cikket egy stabil, kanonikus URL-en. Adjon hozzá egy rövid átdolgozási megjegyzést, például:

Frissítve 2026. október 21-én: A régi áradatokat a jelenlegi csomagárakra cseréltük, ellenőrizve a közzétett árlistával.

Anyagi változások esetén hivatkozzon az azokat alátámasztó forrásra. Ha az olvasóknak több részletre van szükségük, mellékeljen dátumozott felülvizsgálati előzményeket ugyanazon az oldalon, vagy hivatkozzon egy hasznos változási naplóra. Különbségi oldal (diff page) akkor van értelme, ha valódi értéket képvisel, például a szakpolitikai változások olvasható nyilvántartása. Ne hozzon létre vékony „új verzió” URL-t csak azért, hogy egy crawler újra felkeresse a tartalmat. Ez egy átláthatósági és karbantartási javaslat, nem dokumentált AI rangsorolási taktika.

Hozzon létre egy frissességi munkafolyamatot, amely nem generál felesleges munkát

A legtöbb termékcsapat számára elegendő egy kis rendszer:

1. Nevezze meg azokat a tényeket, amelyek elavulhatnak. Példák: árak, funkciók elérhetősége, szabályok, benchmarkok és támogatási lépések.
2. Válasszon ki egy megbízható forrást és egy tulajdonost. A tulajdonos megerősíti a változást, mielőtt az a cikkbe kerül.
3. Figyelje a fontos változásokat. Használjon kiadási megjegyzéseket, termékadatokat vagy más megbízható forrásokat a felülvizsgálat kiváltására.
4. Csak az érintett szakaszokat vázolja fel. Hagyja az oldal többi részét érintetlenül.
5. Vizsgálja felül a tényeket, majd publikálja. Frissítse a látható dátumot, a strukturált adatokat, a sitemapot és a HTTP fejléceket ugyanabból a publikálási rekordból.
6. Értesítse a résztvevő keresőmotorokat, ahol hasznos. Az IndexNow értesítheti a résztvevő motorokat a hozzáadott, megváltozott vagy eltávolított URL-ekről. Nem garantálja, hogy egy URL indexelve lesz. Source 10 (indexnow.org)
7. Ellenőrizze, hogy megérkezett-e az új verzió. Használja a szerver naplókat és az elérhető keresőmotor ellenőrző eszközöket. A Google URL ellenőrző jelentése megmutatja az utolsó feltérképezést; a Bing URL ellenőrző eszköze megmutathatja az indexelt verzióját és a feltérképezési részleteket. Source 14 Source 15 (support.google.com)

Ha a cél a ChatGPT Search-be való bekerülés, ellenőrizze, hogy webhelye nem blokkolja-e az OAI-SearchBot-ot; az OpenAI szerint a nyilvános webhelyeket fel lehet fedezni és hivatkozni rájuk, ha a releváns crawler hozzáfér hozzájuk. A crawler hozzáférés előfeltétel, nem hivatkozási garancia. Source 16 (help.openai.com)

Az automatizálás előkészíthet egy javasolt frissítést, összehasonlíthatja azt a jelenlegi oldallal, és jelezheti a megváltozott állításokat. Egy személynek továbbra is ellenőriznie kell a tényeket. Egy olyan eszköz, mint az AutoPod, beviheti a tulajdonos Alkotói, Közönségi és Ízlési inputjait minden tervezetbe, így egy gyorsabb frissítés nem lapítja el a termék nézőpontját generikus szöveggé.

Frissességi KPI-k

Kövesse nyomon az utat a változástól a válaszig. Ne tekintsen egy új dátumbélyegzőre sikerjelként.

A hivatkozási arányhoz határozza meg a nevezőt, mielőtt elkezdi:

URL hivatkozási arány = az oldalát hivatkozó lekérdezési futtatások ÷ az azonos rögzített lekérdezési halmaz összes futtatása

Válassza szét az időérzékeny kérdéseket az örökzöldektől. Tartsa konzisztensen a megfogalmazást, régiót és motort, ahol lehetséges, és ismételje meg az egyes lekérdezéseket idővel. Egy válasz pillanatkép, nem tendencia.

Az eszközök nem azonos eredményeket jelentenek. 2026. október 21-én a Google Search Console generatív AI jelentései olyan mérőszámokat mutatnak, mint a megjelenések, oldalak és teljesítmény idővel. A Bing Webmaster Tools AI Teljesítmény jelentése hivatkozási számokat, hivatkozott oldalakat és mintavételi alapozó lekérdezéseket mutat; a hivatkozási száma nem mondja meg, hol jelent meg egy forrás a válaszban. Tekintse ezeket hasznos, de eltérő nézeteknek, nem egy univerzális AI-hivatkozási pontszámnak. Source 17 Source 18 (developers.google.com)

Adjon hozzá egy védőkorlát-metrikát: frissességi lefedettség – a prioritási oldalak aránya, amelyeket a vállalkozása által meghatározott időkorláton belül ellenőriztek. Ez megmutatja, hogy a tartalomrendszer naprakészen tartja-e a fontos tényeket, még mielőtt a hivatkozások elmozdulnának.

Konklúzió

A frissesség nem egy publikálási ütemezés. Az bizonyítékok és kézbesítés láncolata. Az oldalnak okból kell megváltoznia, őszintén meg kell mutatnia ezt a változást, el kell jutnia a keresési indexbe, és választ kell adnia egy olyan kérdésre, ahol az aktualitás számít.

Használjon fix felülvizsgálatokat a lassú eltolódás megfogására. Használjon reaktív frissítéseket az anyagi változásokhoz. Tartsa konzisztensen a dátumokat, tartson egy fő URL-t, és mérje külön a feltérképezési, indexelési és hivatkozási gyakoriságot. A cél nem az, hogy minden oldal újnak tűnjön. Hanem az, hogy a megfelelő oldal legyen a legvilágosabb, legaktuálisabb forrás, amikor valakinek – vagy egy AI összefoglalónak – szüksége van rá.

Források

• Source 1 — Google Keresés rangsorolási rendszerek
• Source 2 — Google útmutató a generatív AI funkciókhoz a Keresésben
• Source 3 — Bing útmutató sitemapekhez és AI-alapú kereséshez
• Source 4 — Ahrefs elemzés a hivatkozott URL-ek koráról
• Source 5 — Tanulmány a generatív keresési forrásokról és frissességről
• Source 6 — Google byline-dátum útmutató
• Source 7 — Google sitemap útmutató
• Source 8 — Google feltérképezési mítoszok és tények
• Source 9 — Google feltérképezési és feltételes kérésekre vonatkozó útmutató
• Source 10 — IndexNow GYIK
• Source 11 — Google Cikk strukturált adat útmutató
• Source 12 — Google hírszitemap útmutató
• Source 13 — RFC 9110, HTTP Szemantika
• Source 14 — Google Search Console URL ellenőrzés
• Source 15 — Bing Webmaster Tools URL ellenőrzés
• Source 16 — OpenAI kiadói útmutató
• Source 17 — Google Keresés generatív AI teljesítmény jelentések
• Source 18 — Bing AI teljesítmény jelentés