AI által kitalált URL-ek: mit kezdj a nem létező oldalakra mutató hivatkozásokkal?

Scheo · 2026-10-15 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egyre többen kérdezik a ChatGPT-t, a Perplexityt vagy a Geminit arról, hol találnak valamit egy adott weboldalon. A válasz sokszor egy kattintható link, ami jól néz ki, logikus a szerkezete, és mégis egy 404-es oldalra visz. Az AI ilyenkor kitalált egy URL-t, ami a te domainedre mutat, de nálad sosem létezett. Ez a cikk végigveszi, hogyan veszed észre ezeket a látogatásokat, mit érdemes velük kezdeni, és mit tanulhatsz belőlük az oldalad szerkezetéről.

Mi történik, amikor egy AI nem létező URL-t ad meg a weboldaladon?

A nyelvi modell a valószínű szerkezet alapján összerak egy hihető címet, a látogató rákattint, és a szervered 404-es választ ad. A modell nem minden esetben néz utána valós időben, hogy az oldal létezik-e. Ha a tanítóadatban sok hasonló felépítésű webhelyet látott, akkor a /szolgaltatasok/weboldal-karbantartas vagy a /blog/google-cegprofil-optimalizalas típusú címeket „logikusnak” tartja, és megadja akkor is, ha nálad a karbantartás egy másik útvonalon van, vagy egyáltalán nincs róla külön oldalad.

A keresővel támogatott válaszoknál (amikor az AI a válasz előtt valóban letölti a forrásokat) ez ritkábban fordul elő, de nem tűnik el teljesen. Előfordul, hogy a modell egy valós oldalt talál, és a hivatkozásnál mégis egy rövidített vagy átfogalmazott címet ír ki. Ez hétköznapi hibának tűnik, a látogató szemében viszont a te oldalad „romlott el”, hiszen a 404-et a te domaineden látja.

Miért érdemes foglalkozni ezekkel a 404-ekkel?

Mert ezek a látogatók egy konkrét szándékkal érkeznek, és egy rossz 404-es oldal miatt jó eséllyel azonnal elmennek. Aki AI-válaszból kattint, az általában már szűkített kérdést tett fel, tehát közelebb jár a döntéshez, mint egy általános keresésből érkező látogató. Ha a 404-es oldalad üres, angol nyelvű alapértelmezett szöveg, vagy nincs rajta semmi továbblépési lehetőség, ezt a forgalmat elveszíted.

A keresőoptimalizálás szempontjából a helyzet megnyugtatóbb. Hivatalosan igazolt: a Google Search Central dokumentációja szerint a nem létező URL-ekre adott 404-es válasz önmagában nem rontja a webhely rangsorolását, ez a web normális működésének része. A gond tehát elsősorban a felhasználói élmény és az elveszett érdeklődő, a rangsorolási büntetéstől nem kell tartanod.

Hogyan szűröd ki a szervernaplóból az AI-ból érkező 404-eket?

A hozzáférési naplóban a 404-es státuszkódú sorokat kell összevetni a hivatkozó forrással (referer) és az URL-ben lévő követőparaméterekkel. A szervernapló a legpontosabb forrás, mert minden kérést rögzít, akkor is, ha a látogató böngészője letiltja az analitikai kódot.

Mit keress a naplóban?

• Hivatkozó domainek. A leggyakoribbak a chatgpt.com, a perplexity.ai, a gemini.google.com, a copilot.microsoft.com és a claude.ai.
• Követőparaméter az URL-ben. A ChatGPT a kimenő linkekhez jellemzően hozzáteszi az utm_source=chatgpt.com paramétert. Az OpenAI a kiadóknak szóló dokumentációjában leírja, hogy ez alapján azonosíthatod a ChatGPT-ből érkező forgalmat.
• A 404-es státuszkód. Ellenőrizd, hogy a 404-es oldalad valóban 404-et ad vissza, különben a naplóban 200-as sorként bújik el a hiba.

Egy Apache vagy Nginx alapértelmezett (combined) formátumú naplójában az alábbi parancssor kilistázza a leggyakoribb AI-ból érkező, nem létező URL-eket:

grep ' 404 ' access.log | grep -E 'chatgpt\.com|perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai|utm_source=chatgpt' | awk '{print $7}' | sed 's/?.*//' | sort | uniq -c | sort -rn | head -50

A parancs kiszűri a 404-es sorokat, megtartja az AI-forrásból érkezőket, levágja a paramétereket, és gyakoriság szerint sorba rendezi az útvonalakat. Megosztott tárhelyen a napló általában a tárhelykezelő felületéről tölthető le, ha nincs parancssori hozzáférésed, egy táblázatkezelőben is elvégezheted ugyanezt szűréssel.

Saját tapasztalat: a mobilos AI-alkalmazásokból érkező kattintások egy része nem küld hivatkozó forrást, ezért ezek a naplóban közvetlen látogatásnak tűnnek. Ha egy furcsa, soha nem létezett útvonalra hivatkozó forrás nélkül érkezik több kérés, és a felépítése az AI-forrásból jövő URL-ekre hasonlít, érdemes ugyanabba a csoportba sorolni.

Hogyan látod ugyanezt a GA4-ben?

A GA4-ben egy felfedezés (Exploration) jelentéssel szűrheted a 404-es oldal címére, és mellé teheted a munkamenet forrását meg a teljes oldal URL-t. Ehhez először az kell, hogy a 404-es oldalad egyedi, felismerhető címet kapjon.

1. Adj a 404-es oldalnak egyértelmű címet, például 404 | Az oldal nem található. Sok sablon alapból is ad ilyet, de ellenőrizd a böngésző fülén.
2. Nyiss egy új szabad formátumú felfedezést a GA4 Felfedezés menüpontjában.
3. Dimenzióként vedd fel az Oldal címe, az Oldal helye (page location), a Munkamenet forrása és az Oldal hivatkozója mezőket.
4. Szűrj arra, hogy az oldal címe tartalmazza a „404” szót.
5. A sorokba tedd az oldal helyét, az oszlopokba a munkamenet forrását. Így egy táblázatban látod, melyik nem létező URL-re melyik AI-szolgáltatásból jöttek.
6. Mentsd el a jelentést, és havonta futtasd újra ugyanarra az időszakra.

A GA4 csak azokat a látogatásokat mutatja, ahol az analitikai kód lefutott és a látogató hozzájárult a méréshez. A számok ezért jellemzően alacsonyabbak lesznek, mint a naplóban. A trend követésére és a minták felismerésére ez is elég, a pontos számokat a napló adja.

Milyen URL-mintákat érdemes keresni?

A kitalált URL-ek ritkán véletlenszerűek, jellemzően néhány visszatérő mintába rendeződnek. Ha a listádat ezek szerint csoportosítod, sokkal gyorsabban döntesz.

• Angol nyelvű útvonal magyar oldalon. Például /services/seo a valós /szolgaltatasok/keresooptimalizalas/ helyett.
• Sablonos szekciónevek. /about-us, /contact, /pricing, /faq, ami más webhelyeken gyakori, nálad viszont másképp vagy sehogy sem létezik.
• Átfogalmazott blogcím. A valós cikk címének rövidített vagy szinonimákkal átírt változata, ékezet nélkül, más szórenddel.
• Kitalált mélység. Egy létező kategória alá kitalált aloldal, például /szolgaltatasok/weboldal-keszites/webshop-keszites, amikor nálad a webshop külön, felső szinten van.
• Települési változat. /weboldal-keszites-szekesfehervar típusú címek akkor is, ha nincs helyi aloldalad.
• Régi szerkezet. Egy korábban létező, de azóta átnevezett vagy törölt oldal, amit az AI a régi tanítóadatból ismer.

Az utolsó csoport különleges, mert ott az URL nem kitalált, csak elavult. Ezeket egyszerű 301-es átirányítással a legtöbb esetben jól lehet kezelni, ha van egyértelmű utód.

Mikor érdemes átirányítani a legközelebbi valódi oldalra, és mikor nem?

Akkor irányíts át, ha a kitalált URL tartalmilag egyértelműen egy létező oldaladra utal, és rendszeresen érkezik rá látogató; minden más esetben a jó 404-es oldal a tisztább megoldás. Az átirányítás egy ígéret a látogatónak, hogy azt kapja, amit keresett. Ha ez nem teljesül, a látogató csalódott, a kereső pedig zavaros jelet kap.

Mikor jó döntés az átirányítás?

• A kitalált /services/seo és a valódi keresőoptimalizálási oldalad között egyértelmű a megfelelés.
• A hiba ismétlődik, havonta több látogató érkezik ugyanarra az útvonalra.
• Az URL egy régi, átnevezett oldaladra utal, és van közvetlen utódja.
• Az átfogalmazott blogcím alapján pontosan beazonosítható, melyik cikkre gondolt az AI.

Mikor ne irányíts át?

• Ha csak a főoldal vagy egy általános kategória lenne a cél. Hivatalosan igazolt: a Google a nem releváns oldalra (például a főoldalra) mutató tömeges átirányítást soft 404-ként kezelheti, így az átirányítás nem ér el semmit, a látogatót pedig összezavarja.
• Ha egyszeri kérésről van szó. Egyetlen látogatás miatt nem érdemes szabályt írni.
• Ha az AI olyan szolgáltatást vagy terméket keresett, amit nem kínálsz. Ilyenkor az átirányítás félrevezető lenne.
• Ha több valódi oldal is szóba jöhet, és nem tudod eldönteni, melyikre gondolt a felhasználó.

Ha az átirányítás mellett döntesz, használj végleges, 301-es átirányítást, és írj külön szabályt minden URL-re. Nginx alatt például így néz ki egy szabály:

location = /services/seo { return 301 /szolgaltatasok/keresooptimalizalas/; }

WordPressen egy átirányítás-kezelő bővítménnyel is felveheted ugyanezt. Szakmai feltételezés: gyűjtő (regex) szabályokat csak óvatosan írj, mert egy túl tág minta valódi oldalakat is elnyelhet, és a hibát később nehéz visszakeresni.

Mit árul el a kitalált URL-ek mintázata arról, mit hiányol az AI az oldalszerkezetedből?

Ha az AI rendszeresen ugyanazt a nem létező oldaltípust találja ki, az jó eséllyel azt jelzi, hogy a felhasználók erre kérdeznek rá, a webhelyeden viszont nincs rá egyértelmű, önálló oldal. Ez a rész a teljes elemzés talán leghasznosabb hozadéka.

Szakmai feltételezés: a modell a kérdés és a hasonló webhelyek alapján „elvárja”, hogy egy ilyen témájú cégnél legyen például GYIK-oldal, külön szolgáltatásoldal vagy helyi aloldal. Ha ezek nálad hiányoznak, vagy egy hosszú, általános oldalba vannak beolvasztva, a modell egy saját elképzelés szerinti címet ír. Néhány tipikus olvasat:

• Sok kitalált /faq vagy /gyik URL. A felhasználók konkrét kérdésekkel jönnek, és nem találnak rájuk összegyűjtött választ.
• Kitalált szolgáltatás-aloldalak. Egy szolgáltatáscsoportot egyetlen oldalon tárgyalsz, miközben az emberek külön-külön keresnek rá.
• Kitalált települési oldalak. A helyi kérdésekre nincs olyan tartalmad, ami megmondja, hol dolgozol.
• Angol útvonalak tömegesen. Előfordulhat, hogy a magyar URL-szerkezeted nehezen kiolvasható, vagy következetlen.

Ebből nem következik, hogy minden kitalált URL-re azonnal oldalt kell építeni. Akkor érdemes, ha a téma valóban a kínálatod része, és tudsz hozzá olyan tartalmat írni, ami önmagában is értékes. Ilyenkor a kitalált címhez közeli, beszédes URL-t választhatsz, és a korábbi 404-et átirányíthatod az új oldalra. Hogy ettől az AI ezentúl a jó címet adja-e meg, azt senki nem tudja előre megmondani, de a valódi, jól strukturált oldal segítheti, hogy a keresővel támogatott válaszok megtalálják.

Milyen legyen egy hasznos 404-es oldal?

Egy hasznos 404-es oldal valódi 404-es státuszkódot ad, emberi nyelven elmondja, mi történt, és két-három kattintásnyi utat kínál a látogató valószínű céljához. Az alábbi ellenőrzőlistát egyszer érdemes végigvenni, és minden nagyobb sablonváltás után megismételni.

• A szerver 404-es (vagy véglegesen törölt tartalomnál 410-es) státuszkódot küld, 200-ast semmiképp.
• Az oldal címe egyedi és felismerhető, hogy a GA4-ben szűrni tudj rá.
• Egy rövid, magyar mondat elmondja, hogy ez az oldal nem létezik, és lehet, hogy egy hibás hivatkozásból érkezett.
• Van rajta keresőmező, ami a webhely saját keresőjét használja.
• Kiemelve szerepelnek a fő szolgáltatás- vagy kategóriaoldalak, legfeljebb öt-hat link.
• Elérhető a kapcsolatfelvételi lehetőség, telefonszám vagy űrlap linkje.
• Megmarad a webhely fejléce, menüje és lábléce, hogy a látogató ne érezze magát kidobva.
• Gyorsan betölt, és mobilon is olvasható.
• Nem irányít át automatikusan pár másodperc után a főoldalra.
• Nem szerepel az XML oldaltérképben, és belső link sem mutat rá állandó címként.

Saját tapasztalat: a legtöbb látogatót az a 404-es oldal tartja meg, amelyik az URL-ből kiolvasható témára ajánl linket. Ha a kért útvonalban szerepel például a „karbantartas” szó, és a 404-es oldal a karbantartási oldaladat kínálja fel elsőként, az sokkal jobban működik, mint egy általános lista. Ez egyszerű szóegyezéssel is megoldható, nem kell hozzá bonyolult rendszer.

Hogyan építs ebből havi rutint?

Elég havonta egyszer lefuttatni a naplószűrést és a GA4-jelentést, majd a legalább néhány ismétlődő látogatást kapó URL-ekről egyenként dönteni. A rutin lépései:

1. Töltsd le az elmúlt harminc nap hozzáférési naplóját, és futtasd le rajta a szűrést.
2. Nyisd meg a mentett GA4-felfedezést ugyanarra az időszakra.
3. Csoportosítsd az URL-eket a fenti minták szerint.
4. Minden ismétlődő URL-nél döntsd el, hogy átirányítás, új tartalom vagy a 404-es oldal marad-e.
5. Vezesd egy táblázatban a döntéseket a dátummal együtt, hogy később lásd, mi változott.
6. Negyedévente nézd át, mely oldaltípusok hiánya jön elő újra és újra, és ezt vidd be a tartalmi tervbe.

A táblázat azért hasznos, mert ugyanaz a kitalált URL hónapokon át visszatérhet. Ha már egyszer döntöttél róla, nem kell újra végiggondolnod.

Mi hivatalos információ, mi saját tapasztalat és mi szakmai feltételezés ebben a témában?

A státuszkódok és az átirányítások kezelése dokumentált, az AI-forrásból érkező 404-ek gyakorisága és oka viszont nagyrészt megfigyelésen alapul. Röviden a cikkben szereplő állítások besorolása:

• Hivatalosan igazolt: a 404-es válasz önmagában nem rontja a rangsorolást, a nem releváns oldalra mutató átirányítás soft 404-ként kezelhető, a ChatGPT kimenő linkjei utm_source=chatgpt.com paramétert kaphatnak, a 301-es és a 410-es státuszkód jelentését a HTTP-szabvány rögzíti.
• Saját tapasztalat: a mobilos AI-alkalmazások egy része nem küld hivatkozó forrást, a témára szabott 404-es ajánlás több látogatót tart meg, a kitalált URL-ek néhány visszatérő mintába rendeződnek.
• Szakmai feltételezés: az ismétlődő kitalált oldaltípus hiányzó tartalomra utal, egy új, jól strukturált oldal segítheti, hogy az AI később a valódi címet adja meg.

Források és további olvasnivalók

• Google Search Central: HTTP-állapotkódok és hálózati hibák hatása a Google Keresőre
• Google Search Central: Átirányítások és a Google Kereső
• Google Search Central: Soft 404-es hibák a Search Console-ban
• OpenAI: Publishers and Developers FAQ (ChatGPT search, hivatkozó forgalom azonosítása)
• Google Analytics súgó: Felfedezések (Explorations) a GA4-ben
• IETF RFC 9110: HTTP Semantics (állapotkódok)