Mit állítottam be, hogy az AI-asszisztensek idézni tudják az oldalam?

A pappfer.hu-t úgy építettem fel, hogy az AI-asszisztensek is el tudják olvasni és idézni tudják a tartalmát. Ha valaki például magyarországi Laravel-fejlesztőt keres a ChatGPT-vel, szeretném, ha az asszisztens az oldalam alapján is tájékozódhatna arról, mivel foglalkozom. Ehhez nagyrészt a szokásos SEO-beállításokra volt szükség, néhány dolgot pedig kísérletképpen tettem hozzá.

Azt viszont senki nem tudja garantálni, hogy egy asszisztens téged fog idézni. Ezt akkor is tartsd észben, ha AI-keresőoptimalizálásra költesz. A Google leírja, hogy az AI-áttekintésekhez és az AI Mode-hoz nem kell külön fájl, jelölés vagy speciális optimalizálás. Az oldalnak szerepelnie kell a Google indexében, és engedélyezned kell, hogy a kereső szöveges kivonatot jelenítsen meg róla. Ettől még nem biztos, hogy az AI-válaszban hivatkozik is rá. Azt tudod befolyásolni, hogy a robotok hozzáférnek-e az oldaladhoz, a szövegből könnyen kiemelhető-e egy önmagában is érthető válasz, és mindenhol ugyanazok az adatok szerepelnek-e rólad.

Röviden

1. Nézd meg a robots.txt-t: ha minden robotra ugyanazok a szabályok vonatkoznak, elég egy User-agent: * csoport. Külön csoportot annak a robotnak adj, amelyikre más szabályokat szeretnél alkalmazni.
2. Az OAI-SearchBot és a Claude-SearchBot érje el az oldalt. Ezek a kereséshez gyűjtenek tartalmat. Attól, hogy a modellek tanításához adatot gyűjtő robotokat beengeded, a keresőbotok még nem feltétlenül férnek hozzá az oldalhoz.
3. Add meg a saját vagy a céged adatait JSON-LD-ben. Minden személynek és cégnek legyen saját, állandó @id azonosítója, és minden oldalon ezzel hivatkozz rá.
4. A definíciók és az önállóan is idézhető szakaszok kapjanak állandó horgonyazonosítót, hogy közvetlenül lehessen rájuk hivatkozni. Szerkesztéskor ezeket ne változtasd meg.
5. A sitemap <lastmod> dátuma csak akkor változzon, ha a tartalom is.
6. Az IndexNow-n keresztül csak azután küldj értesítést a keresőknek, hogy az új tartalom élesben is elérhető.
7. Az llms.txt-t nyugodtan tedd ki, de ne ettől várd a csodát.

Miért nincs GPTBot-csoport a robots.txt-ben?

Az oldalam robots.txt fájlja három beállítást és három megjegyzést tartalmaz:

User-agent: *
Allow: /

Sitemap: https://pappfer.hu/sitemap.xml

# Structured summary for LLMs: https://pappfer.hu/llms.txt
# Full site content as plain text: https://pappfer.hu/llms-full.txt
# Machine-readable CV (JSON Resume): https://pappfer.hu/resume.json

Sok útmutató azt javasolja, hogy vegyél fel külön User-agent: GPTBot, User-agent: ClaudeBot és hasonló csoportokat, mindegyikben Allow: / sorral. Ha a * csoportban már mindent engedélyeztél, ezek a külön engedélyek feleslegesek. Az RFC 9309 szerint a robot a saját nevéhez tartozó csoport szabályait követi. A * csoportot csak akkor veszi figyelembe, ha nincs neki szóló csoport.

Később ebből könnyen hiba lehet. Ha a GPTBotnak saját csoportja van, a * csoportot egyáltalán nem nézi meg. Fél év múlva valaki beír egy Disallow: /admin/ sort a * alá, és ezt a saját csoporttal rendelkező botok közül egyik sem látja. Én ezért használok egyetlen csoportot: az ide írt szabályokat minden olyan robotnak követnie kell, amely betartja a protokollt. A robots.txt azonban nem akadályozza meg a hozzáférést. Az adminfelülethez továbbra is bejelentkezést kell kérni.

A robotok neve azért számít, mert más-más feladatot végeznek. Az OpenAI GPTBotja a modellek tanításához gyűjt adatot, az OAI-SearchBot pedig a ChatGPT keresőjéhez. A ChatGPT-User felhasználói kérésre tölt le oldalakat; az OpenAI szerint ilyenkor a robots.txt szabályai nem feltétlenül érvényesek. Az Anthropicnál hasonló a felosztás: a ClaudeBot a tanításhoz, a Claude-SearchBot a kereséshez gyűjt tartalmat, a Claude-User pedig a felhasználó kérésére nyit meg oldalakat.

Ha a keresésben szeretnél megjelenni, de a modellek tanításához nem szeretnéd átadni a tartalmadat, a GPTBotot és a ClaudeBotot tiltsd le, a keresőbotok hozzáférését pedig engedélyezd. Ezzel a két szolgáltató saját robotjainak adsz utasítást. Arra nincs garancia, hogy más forrásból sem jut el hozzájuk a tartalmad.

A robots.txt mellett a CDN és a tűzfal szabályait is nézd meg. Hiába engeded a keresőbotot, ha a Cloudflare közben blokkolja vagy böngészős ellenőrzést kér tőle. Nézd meg a naplókban, milyen választ kaptak a keresőbotok kérései. A robot azonosításához az OpenAI által közzétett IP-tartományokat is használhatod; a kérésben megadott robotnév önmagában nem bizonyítja, ki küldte.

Strukturált adat: egy személy, egy @id

A főoldal, a szolgáltatásoldalak, a szótár és a cikkek JSON-LD-je ugyanazzal az azonosítóval hivatkozik rám: https://pappfer.hu/#ferenc-papp. A főoldalon szereplő Person típusú adat tartalmazza a munkakörömet, a lakóhelyemet, a beszélt nyelveket és a közösségi profiljaimra mutató sameAs hivatkozásokat. A ProfessionalService leírásában a founder mezővel hivatkozom magamra, a szolgáltatásoldalakon a provider, a cikkekben az author mezővel. Mindegyikben ugyanaz az azonosító szerepel, így jelzem, hogy ugyanarról a személyről van szó. Az már a keresőtől vagy az asszisztenstől függ, hogy felhasználja-e ezt az összefüggést.

Leginkább az számít, hogy a JSON-LD és a látható szöveg ugyanazt mondja. Ha a strukturált adatokban „15+ év” áll, a Rólam részben meg 12, a robot nem tudja eldönteni, melyik igaz. Ahogy az ember sem.

A GYIK tartalmát egy FAQPage típusú JSON-LD-blokkban is megadom. A látható kérdéseket külön, microdata formátumban már nem jelölöm meg: ugyanazt ismételném meg, amit a JSON-LD-ben egyszer már leírtam. Ezt a jelölést annak ellenére megtartottam, hogy a Google 2026. május 7-én megszüntette a GYIK-válaszok kiemelt megjelenítését a találati listán. A kérdések és válaszok szövege ettől még megjelenhet a szokásos keresési találatokban. A JSON-LD-ben pedig egyértelműen megadhatom, melyik kérdéshez melyik válasz tartozik. A hivatkozott dokumentációk alapján nem tudom megmondani, melyik asszisztens használja ezt a blokkot a válaszaihoz.

Szótár: horgonyok, amik nem mozdulnak

Az AI-szótárban 50 fogalom van, mindegyiknek saját horgonyazonosítója (például a RAG definíciójáé), és mindegyik szerepel egy DefinedTermSet-ben is:

{
  "@type": "DefinedTerm",
  "@id": "https://pappfer.hu/hu/ai-szotar/#rag",
  "name": "RAG (retrieval-augmented generation)",
  "termCode": "rag",
  "inDefinedTermSet": { "@id": "https://pappfer.hu/hu/ai-szotar/#termset" }
}

Egy rövid, önmagában is érthető definíciót könnyű idézni, ha valaki egy fogalom jelentésére kérdez rá. A fogalmak azonosítóját ezért nem változtatom meg: ugyanaz szerepel a hivatkozás végén és a strukturált adat @id mezőjében. Ha a rag azonosítót átírnám retrieval-augmented-generation-re, a korábbi hivatkozások többé nem vinnének a definícióhoz. Ha a név változik, a megjelenített szöveget írom át, az azonosító marad.

Ugyanez igaz a cikkek ## címeire: ezekből horgony lesz, ezért rövidek, és megjelenés után nem fogalmazom át őket.

Pontos lastmod: a tartalomból számolt hash, nem a builddátum

Az a sitemap, amelyikben minden oldal <lastmod>-ja a build napja, rosszabb, mint ha nem lenne benne dátum. A Google azt írja, hogy akkor használja a <lastmod> értékét, ha ellenőrizni tudja, hogy az rendszeresen a valós módosítások dátumát jelzi. Ha minden élesítéskor az összes URL friss dátumot kap, akkor a dátumokból nem derül ki, melyik tartalom változott ténylegesen.

Nálam az oldal forrástartalmából számított hash alapján derül ki, történt-e változás. A hash itt ellenőrzőösszegként szolgál: az értékek összehasonlításával észlelem, ha változott a tartalom. A számításhoz az adott oldalt meghatározó forrásadatokat használom, például a fordítási fájl megfelelő részét. A kész HTML-t nem veszem alapul. Így a tartalom módosítási dátuma nem változik attól, hogy átírom a CSS-t vagy frissül az évszám a láblécben.

Az URL-ekhez tartozó hashértékeket és dátumokat egy fájlban tárolom, és ezt a fájlt is verziókezelem. A dátumot csak akkor frissítem, ha az adott tartalom hashértéke megváltozott:

function trackLastmod(urlPath, source) {
  const hash = crypto.createHash('sha1')
    .update(JSON.stringify(source)).digest('hex').slice(0, 16);
  const prev = lastmodStore[urlPath];
  if (prev && prev.hash === hash) return prev.date;
  lastmodStore[urlPath] = { hash, date: BUILD_DATE };
  return BUILD_DATE;
}

Ahol van JSON-LD dateModified mező, az is ebből a nyilvántartásból kapja a dátumot.

IndexNow: értesíts élesítés után, ne előtte

Az IndexNow-val értesítheted a Binget, a Yandexet, a Seznamot, a Navert és a többi részt vevő keresőt arról, hogy egy URL tartalma megváltozott. Elég egyszer beküldened az URL-t, az értesítést megosztják egymással. A Google nem vesz részt ebben; neki továbbra is az oldaltérkép és a követhető linkek segítenek megtalálni az oldalakat. Az értesítés a részt vevő keresőknél sem garantálja, hogy az oldal bekerül az indexbe.

Az értesítést könnyű túl korán elküldeni. A Cloudflare Pages előbb lefuttatja a buildet, és csak utána teszi közzé az eredményt. Ha már a buildből értesíted a keresőket, még a régi tartalmat találhatják az oldalon.

Nálam ezért egy GitHub Actions-munkafolyamat küldi az értesítést. A változtatások feltöltése után újra lefuttatja a buildet, majd rendszeresen lekéri az éles sitemap.xml fájlt. Megvárja, amíg az megegyezik az új buildben készült oldaltérképpel, és csak ezután küldi be azoknak az oldalaknak az URL-jét, amelyek tartalma megváltozott. Ha csak a CSS-t módosítottam, nem küld értesítést.

A kulcsot egy egyszerű szövegfájlban teszem közzé a webhely gyökérkönyvtárában (/<kulcs>.txt). Ez szándékosan nyilvános, a keresők ebből ellenőrzik, hogy hozzáférek a webhelyhez. Én megtartom a kulcsot, de le is lehet cserélni: ilyenkor az új kulcsfájlt is közzé kell tenni, és az új kulccsal kell beküldeni az URL-eket.

llms.txt: hasznos, de ne várj tőle csodát

Az llms.txt-t Jeremy Howard javasolta 2024 szeptemberében: egy Markdown-fájl a webhely gyökérkönyvtárában, benne egy főcímmel, rövid összefoglalóval és az elolvasásra ajánlott oldalakra mutató linkekkel. A pappfer.hu llms.txt fájlja mellett egy llms-full.txt is elérhető. Ebben egy helyen olvasható a főoldalak, a szolgáltatásoldalak, a szótárak, valamint az angol és a magyar cikkek szövege.

Szerintem megér egy órát foglalkozni vele. A fájl kiszolgálásához ezen a statikus webhelyen nincs szükség külön szerveroldali programra. Az ágens egy rövid szövegfájlból tájékozódhat az oldal tartalmáról. Már az is hasznos, hogy az összeállításakor egyszerűen le kell írnod, ki vagy és mit csinálsz.

Az itt hivatkozott dokumentációban viszont sem az OpenAI, sem az Anthropic nem ígéri, hogy a keresője használja az llms.txt-t. A Google kifejezetten azt írja, hogy nincs szükség új „AI-szövegfájlra”. Ha valaki azt ígéri, hogy az llms.txt miatt fog rád hivatkozni a ChatGPT, többet ígér annál, mint amit igazolni tud.

Mi számít igazán?

A legtöbb időt magára a szövegre érdemes fordítani. A mondatok a környezetükből kiemelve is legyenek érthetők, például: „Papp Ferenc debreceni full-stack fejlesztő.” Egy GYIK-válasz megértéséhez ne kelljen elolvasni az előző kérdést, a címekből pedig derüljön ki, miről szól az adott rész. Egy RAG-rendszer gyakran szövegrészletekre bontja a dokumentumokat, és a kérdéshez illő részeket keresi ki. Ha egy részlet csak az előző bekezdéssel együtt érthető, önmagában könnyű félreérteni. Szemantikus keresést és RAG-rendszereket is fejlesztek, ezért a saját oldalamon is figyelek arra, hogy az egyes szövegrészletek önmagukban is érthetők legyenek.

Segítsek?

Az AI-keresőoptimalizálás részeként megnézem, mit mondanak az asszisztensek a cégedről, és van-e olyan technikai akadály, ami miatt nem férnek hozzá az oldaladhoz. Írd meg, melyik oldalról van szó.