AI-ügynökök

Agent-ready weboldal: útmutató WordPresshez és Next.js-hez

Pintér András · 2026. július 29.

Egyre több eszköz (böngésző-asszisztensek, AI-keresők, automatizált agentek) nem csak olvassa a weboldalakat, hanem célzottan keresi rajtuk azokat a jeleket, amik megmondják neki, hogyan bánjon a tartalommal. Ezt hívják "agent-readiness"-nek. Ma végigfuttattunk egy ilyen ellenőrzést a saját oldalunkon, és amit itt leírok, azt élesben teszteltük — nem elméletben. A téma elsősorban magyarországi KKV- és tanácsadói weboldalaknak releváns, ahol jellemzően nincs API vagy fájlszintű szerverhozzáférés, csak egy WordPress- vagy Next.js-alapú admin felület.

Fontos előre leszögezni: a legtöbb ilyen ellenőrzőlista egy generikus, API-t vagy fizetős terméket kínáló weboldalra van írva. Ha ezt egy tanácsadói vagy tartalom-oldalra (mint a miénk) vakon rávetíted, a pontok nagy részét feleslegesen próbálnád teljesíteni — vagy rosszabb esetben, kitalált, nem működő végpontokat hirdetnél. Az első és legfontosabb lépés nem a megvalósítás, hanem annak eldöntése, mi releváns egyáltalán.

Eszközök, amikre érdemes támaszkodni

joost.blog/agent-native — Joost de Valk (a Yoast SEO alapítója) kiváló, alapos cikke a témáról.
github.com/progressplanner/markdown-alternate — WordPress-plugin, ami automatikusan Markdown-verziót generál a posztokból, és a megfelelő <link rel="alternate"> taget is elhelyezi.
isitagentready.com — konkrétan leellenőrzi, mennyire agent-ready a weboldalad (mostanra a pagespeed.web.dev is vizsgálja ezt).

1. lépés: döntsd el, milyen típusú oldalad van

Két kérdés szinte az összes checklist-pontot kizárja vagy bevonja:

Van API-d, fizetős tartalmad vagy checkout-folyamatod, amihez egy AI-ügynöknek hitelesítenie vagy fizetnie kellene magát?
Van fájl-/szerverszintű hozzáférésed (FTP, SSH, hosting-fájlkezelő), vagy csak a CMS admin felületéhez férsz hozzá?

Ez a két válasz szinte az egész checklistát kizárja vagy bevonja:

Ha a weboldalad…	hagyd ki ezeket a pontokat
csak admin felületen (dashboard) érhető el, nincs fájl-hozzáférésed	mindent, ami `.htaccess`-t vagy `/.well-known/` fájlokat igényel — helyette használj pluginokat
tartalom-/vállalati oldal, API nélkül	OAuth/OIDC discovery, OAuth Protected Resource Metadata, `auth.md`, API-katalógus, MCP Server Card, WebMCP
nem árul semmit programozottan	x402, MPP, UCP, ACP (fizetési protokollok agenteknek)

Ha a válasz mindkettőre "nem" és "csak admin felület" — egy tipikus KKV- vagy tanácsadói weboldalnál ez a jellemző —, akkor a hosszú checklisták nagy része nem rád vonatkozik. Ezek olyan infrastruktúrát feltételeznek, amit nem éri meg kitalálni vagy erőltetni — inkább törött, félrevezető végpontokat eredményeznének, mint hasznosat.

Ami marad, és tényleg megéri megcsinálni: Content Signals a robots.txt-ben, egy RFC 8288 Link fejléc valódi, regisztrált relációkkal, és opcionálisan egy llms.txt.

2. lépés: Content Signals a robots.txt-ben

Ez egy egyszerű, új konvenció (contentsignals.org), amivel megmondod, mihez járulsz hozzá: kereshető legyen-e a tartalmad (search), felhasználható-e élő AI-válaszokban idézésre (ai-input), és taníthatók-e rajta AI-modellek (ai-train).

WordPress: a WordPress alapból egy virtuális robots.txt-et generál. Ahhoz, hogy saját sort adj hozzá, tölts fel egy valódi fájlt a gyökérkönyvtárba (ugyanoda, ahol a wp-config.php van):

User-agent: *
Allow: /
Content-Signal: search=yes, ai-train=no, ai-input=yes

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

Ha a SEO-pluginod (Yoast, RankMath) saját robots.txt-szerkesztőt kínál, kapcsold ki azt — egy fizikai fájl és egy plugin-kezelt verzió felülírhatja egymást.

Next.js: itt nincs "virtuális" verzió — a robots.txt egy saját route. Egyetlen buktató: a beépített, típusos robots.ts konvenció nem támogat egyéni direktívákat, csak userAgent/allow/disallow/crawlDelay mezőket. A Content-Signal soréhoz egy nyers szöveges route handlerre van szükség:

// app/robots.txt/route.ts
export async function GET() {
  const content = `User-agent: *
Content-Signal: search=yes, ai-train=no, ai-input=yes
Allow: /

Sitemap: https://sajatoldalad.hu/sitemap.xml
`;
  return new Response(content, {
    headers: { "Content-Type": "text/plain; charset=utf-8" },
  });
}

Az ai-train értékét te döntsd el — ez üzleti döntés, nem technikai. Van, aki nem engedi a modell-tanítást, de engedi az élő idézést; van, aki mindkettőt nyitva hagyja, mert induló márkaként inkább a minél szélesebb AI-láthatóságot preferálja.

3. lépés: Link fejléc — de csak valódi relációkkal

Itt a legkönnyebb hibázni. A csábítás nagy, hogy kitalálj egy saját rel értéket (pl. rel="ai-usage") — ez nem fog működni. Az agent-discovery eszközök az IANA hivatalos link-relation regiszterét nézik. Ha nem regisztrált érték van a fejlécben, az a checker szemszögéből nem is létezik, még ha technikailag ott is van a válaszban.

Ha nincs API-d, a legjobb, ha valódi, hasznos oldalakra mutatsz, regisztrált relációkkal — pl. privacy-policy (adatvédelmi tájékoztató), help (GYIK), service-doc és api-catalog, ha van hozzá tartalom.

WordPress (.htaccess-ben, mert a plugin/mu-plugin megoldást a cache elnyelheti):

# Ezt a blokkot a "# BEGIN WordPress" sor ELÉ tedd
<IfModule mod_headers.c>
    Header set Link '</adatvedelem/>; rel="privacy-policy", </gyik/>; rel="help"'
</IfModule>

Fontos: ha cache-elő plugint vagy hoszting-szintű cache-t használsz, a WordPress-szintű (add_action('send_headers', ...)) megoldás cache-találat esetén ki sem fut — a fejléc csendben eltűnik. A szerverszintű .htaccess ezt a problémát elkerüli.

Next.js (next.config.ts):

async headers() {
  return [
    {
      source: "/",
      headers: [
        {
          key: "Link",
          value:
            '</.well-known/api-catalog>; rel="api-catalog", </adatvedelem>; rel="privacy-policy", </#gyik>; rel="help"',
        },
      ],
    },
  ];
},

Mindig nyers eszközzel ellenőrizz, ne böngésző-alapú checkerrel. Néhány webes header-vizsgáló HTML-en keresztül jeleníti meg az eredményt, ami csendben levághatja azt, ami HTML-tagnek tűnik (pl. egy </adatvedelem>-mel kezdődő linket). Nálunk pontosan ez történt egy korábbi ellenőrzésnél — a fejléc a háttérben helyesen ott volt, csak a checker vizuális megjelenítése vágta le. A megbízható módszer:

curl -sI https://sajatoldalad.hu/

Ha egy automata scanner azt írja, "nem sikerült ellenőrizni a fejlécet" vagy hasonló hibát dob, az gyakran a scanner saját kérésének hibája (timeout, tűzfal, rate-limit) — nem feltétlenül azt jelenti, hogy nálad van a hiba. Mindig ellenőrizz curl-lel, mielőtt egy nem is létező problémát próbálnál javítani.

4. lépés (opcionális): llms.txt

Az llms.txt egy közösségi, nem hivatalos konvenció: egy sima Markdown-fájl a gyökérben (/llms.txt), ami tömören összefoglalja, miről szól az oldal, és linkel a fontosabb aloldalakra — olyasmi, mint a robots.txt vagy a sitemap.xml, csak nyelvi modelleknek szánva. Fontos tudni: a Google Search ezt nem veszi figyelembe — ez egy kiegészítő, nem garantáltan ható lépés, nem SEO-alapkövetelmény.

WordPress: egyetlen statikus fájl feltöltése a gyökérbe — nincs szükség szerverkonfigurációhoz vagy pluginhoz, bár léteznek plugin-alapú generátorok is, ha automatikusan frissülő tartalmat szeretnél.

Next.js: egy dinamikus route handler, ami a meglévő tartalom-forrásból (pl. a blogposztok listájából) generálja a szöveget:

// app/llms.txt/route.ts
export async function GET() {
  const content = buildSiteOverviewMarkdown(); // saját összegző függvény
  return new Response(content, {
    headers: { "Content-Type": "text/plain; charset=utf-8" },
  });
}

Ez utóbbi előnye, hogy egyetlen forrásból (pl. a blog-listából) generálódik — nem kell kézzel karbantartani egy külön szöveget, ami idővel elcsúszik a valóságtól.

5. lépés (haladó): Markdown-válasz Accept-header alapján

Ez már túlmutat egy tipikus checklistán, de saját oldalunkon bevezettük, mert egyre több eszköz (pl. Cloudflare "Markdown for Agents" konvenciója) ezt keresi: ha egy kérés Accept: text/markdown fejléccel érkezik, HTML helyett Markdown-választ adsz — ugyanazon az URL-en, a böngészőknek változatlanul HTML jön.

Next.js-ben ezt middleware-szintű (proxy.ts) átírással (rewrite) oldottuk meg: ha a bejövő kérés Markdown-t kér és az útvonal egy tartalom-oldal, a kérést egy dedikált Route Handlerre irányítjuk, ami a valódi forrásból (pl. a blogposzt Markdown-fájljából) adja vissza a választ, Content-Type: text/markdown; charset=utf-8 és Vary: accept fejléccel.

Érdemes emellé egy felfedezési linket is tenni a HTML <head>-be, hogy ne csak fejléc-trükközéssel legyen megtalálható:

<link rel="alternate" type="text/markdown" href="https://sajatoldalad.hu/api/markdown/home" />

WordPress-ben hasonló elvet valósít meg pluginos megoldás (pl. a Progress Planner "markdown-alternate" bővítménye), ami a poszt tartalmából generál Markdown-verziót, és ugyanezt a <link rel="alternate"> taget helyezi el.

6. lépés (kísérleti): WebMCP

A document.modelContext.registerTool() API lehetővé teszi, hogy a böngésződ konkrét, hívható funkciókat ("tool"-okat) hirdessen AI-ügynököknek — pl. "szolgáltatások listázása" vagy "konzultáció kérése". Ez ma még csak a Chrome kísérleti előnézeti programja mögött létezik, tehát a legtöbb böngészőben egyszerűen nincs is jelen. Ha implementálod, feltétlenül feature-detectálva tedd (if (!document.modelContext) return;), hogy más böngészőkben ne törjön el semmit — nálunk ez így néz ki, néma no-op-ként a nem támogatott böngészőkben.

Amit szándékosan kihagyunk — és miért

OAuth/OIDC discovery, OAuth Protected Resource Metadata, auth.md — csak akkor van értelme, ha van védett API-d, amihez hitelesíteni kell.
MCP Server Card — egy ténylegesen futó, hívható MCP-szervert feltételez.
x402, MPP, UCP, ACP (fizetési protokollok) — kriptopénztárcát vagy valódi fizetési backendet igényelnek; helytelenül beállítva pénzügyi kockázat, nem csak SEO-hiba.
DNS-AID — DNSSEC-aláírást kér a zónádra; rosszul beállítva az egész domain feloldását tönkreteheti, egy olyan funkcióért, aminek jelenleg gyakorlatilag nulla valós adaptációja van.

Ha ezek bármelyike később ténylegesen releváns lesz (pl. tényleg építesz egy API-t vagy fizetős terméket), érdemes visszatérni rájuk — addig a kitalált, üres implementáció rosszabb, mint a hiánya.

Összefoglaló checklist

WordPress (tartalom-/vállalati oldal, API nélkül):

Content Signals: fizikai robots.txt a gyökérben
Link fejléc: .htaccess-ben, mod_headers-szel, regisztrált relációkkal
llms.txt: statikus fájl (opcionális)

Next.js:

Content Signals: nyers route.ts a típusos robots.ts konvenció helyett
Link fejléc: next.config.ts headers() funkciója
llms.txt és Markdown-negociáció: dinamikus route handlerek, egy közös adatforrásból generálva

Mindkét platformon ugyanaz a végszó: nézd át kritikusan, mi vonatkozik rád, valósítsd meg becsületesen — ne hirdess olyat, ami nincs mögötte —, és mindig nyers eszközzel (curl -I) ellenőrizz, ne csak egy vizuális checkeren keresztül.

További források

Ha németül is szívesen olvasnál hasonló, gyakorlati témákról — SEO, AI-eszközök, digitális marketing —, nézd meg a német nyelvű blogomat: andraspinter.de/digitales-wissen.

Kérdésed van, vagy szeretnéd, ha átnéznénk a saját oldalad agent-readiness szempontból? Keress a LinkedIn-profilomon, vagy kérj egy ingyenes konzultációt.

Szeretnél hasonló eredményt a saját weboldaladon?

Kérek egy ingyenes konzultációt