Belső ellentmondások a saját weboldaladon: így találd meg, mielőtt az AI rosszul választ közülük

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

Egy weboldal ritkán hazudik szándékosan, de sokszor mond egyszerre két dolgot. A főoldalon „15 éve a szakmában” áll, a Rólunk oldalon 2006-os alapítás, egy régi blogcikkben pedig „tízéves jubileumunkat ünnepeljük”. Az ember ezen átsiklik, a nyelvi modellre épülő keresők és asszisztensek viszont mindhárom állítást megtalálhatják, és nekik kell eldönteniük, melyiket adják tovább. Ebben a cikkben megmutatom, hogyan derítheted fel ezeket az ellentmondásokat, hogyan rögzítsd egy helyen a hiteles adatokat, és ki figyeljen rájuk hosszú távon.

Miért okozhat hibás AI-választ, ha a weboldalad önmagának ellentmond?

Ha ugyanarra a kérdésre több eltérő adat szerepel az oldaladon, az AI-alapú válaszmotor nem tudja megbízhatóan eldönteni, melyik az érvényes, ezért jó eséllyel a régit, a gyakoribbat vagy egy kevertet ad vissza. A modell nem tudja, hogy a 2019-es blogcikkben szereplő nyitvatartás már nem él, ha ezt semmi nem jelzi.

Hivatalosan igazolt. Az OpenAI és a Google is nyilvánosan leírja, hogy a nagy nyelvi modellek tévedhetnek, és tényszerűen hibás, de magabiztosan megfogalmazott választ adhatnak. A Google Search Central dokumentációja szerint az AI-alapú keresési funkciók ugyanazokra az alapvető minőségi és rangsorolási rendszerekre épülnek, mint a hagyományos keresés, tehát a forrásoldal tartalma közvetlenül befolyásolja, mi kerül a válaszba.

Saját tapasztalat. Amikor egy cégről rossz adatot ad egy asszisztens, a hiba forrása meglepően gyakran magán a cég oldalán van. Egy elfelejtett aloldal, egy régi árlista-PDF vagy egy sosem frissített lábléc elég hozzá.

Szakmai feltételezés. Úgy gondolom, hogy a következetes adat önmagában nem garantál helyes AI-választ, de az ellentmondás jó eséllyel növeli a hibás válasz kockázatát, mert a modellnek ilyenkor tippelnie kell.

Milyen adatok csúsznak szét a leggyakrabban egy weboldalon?

Azok az adatok csúsznak szét, amelyek idővel változnak, de több helyre lettek bemásolva, és frissítéskor csak egy-két helyen írták át őket. A tipikus jelöltek ezek:

• Szolgáltatási terület. A főoldal szerint „egész Fejér megyében”, a szolgáltatásoldal szerint „Székesfehérváron és 30 km-es körzetében”, egy régi cikk szerint „Budapesten is”.
• Alapítási év és tapasztalat. A „20 éves tapasztalat” típusú szöveg minden évben elavul, ha nem évszámmal írták.
• Létszám. „5 fős csapat” a Rólunk oldalon, „több mint 10 munkatárs” az álláshirdetésben.
• Garanciaidő. 2 év az ÁSZF-ben, 3 év egy kampány-landingen, ami azóta is elérhető.
• Nyitvatartás. A láblécben, a kapcsolat oldalon, a strukturált adatban és a Google Cégprofilban négy külön érték.
• Elérhetőség. Régi telefonszám egy PDF-ben, régi cím egy térképbeágyazásban.
• Szolgáltatáslista. Megszűnt szolgáltatás, aminek még él az aloldala.

Érdemes külön figyelni a számokkal megfogalmazott, de évszám nélküli állításokra. A „több mint 500 elégedett ügyfél”, a „10 fős csapat” vagy a „15 év tapasztalat” mind egy adott pillanatban volt igaz, és a szöveg nem árulja el, melyikben. Egy ember a környezetből kikövetkezteti, hogy régi cikket olvas. A válaszmotor ezt csak akkor teheti meg, ha a cikken látható dátum vagy frissítési megjegyzés van, ezért a dátumozás önmagában is sokat segíthet.

Hogyan találod meg az ellentmondásokat lépésről lépésre?

Először írd le a kulcsadatokat, aztán keresd meg mindegyik összes előfordulását az oldalon, a dokumentumokban és a strukturált adatban, végül vesd össze őket egy táblázatban. Egy közepes céges oldalnál ez jellemzően néhány óra munka, nagy tartalomarchívumnál több.

1. Készíts kulcsadat-listát

Mielőtt keresni kezdesz, tudnod kell, mit keresel. Írd fel azokat a tényeket, amelyekre egy ügyfél vagy egy AI-asszisztens rákérdezhet. Hány éve működik a cég, hol dolgozik, mennyi a garancia, mikor van nyitva, hány fő a csapat, milyen szolgáltatásokat nyújt. Minden adathoz írj keresőszavakat is, például a garanciához „garancia”, „jótállás”, „év garancia”, „hónap”.

2. Keress rá a kulcsadatokra a teljes oldalon

A legegyszerűbb a Google site: operátora, például site:pelda.hu "garancia" vagy site:pelda.hu "alapítva". Ez gyors, de nem teljes, mert csak az indexelt oldalakat mutatja. Alaposabb, ha letöltöd az oldal másolatát, és helyben keresel benne:

wget --mirror --no-parent --adjust-extension https://pelda.hu/

grep -rniE "alapít|óta|éve |garancia|jótállás|nyitva|munkatárs|fős" pelda.hu/ > talalatok.txt

Egy crawler (például a Screaming Frog egyéni keresés funkciója) ugyanezt grafikus felületen is megcsinálja, és oldalankénti listát ad a találatokról.

3. Nézd át a régi blogcikkeket

A blog a legnagyobb ellentmondás-forrás, mert a cikkek az írás pillanatának állapotát rögzítik. Egy 2018-as „Most már Győrben is!” bejegyzés akkor is ott van, ha a győri telephely azóta bezárt. Szűrd a grep-találatokat a blog URL-mintájára, és minden régi cikknél dönts, hogy frissíted, dátummal és megjegyzéssel látod el, vagy összevonod egy aktuális oldallal.

4. Ne hagyd ki a PDF-eket

Árlisták, katalógusok, ÁSZF-ek, garanciajegyek, prezentációk. Ezeket a keresők és az AI-crawlerek is el tudják olvasni, a tartalomkezelőben viszont senki nem látja őket. Gyűjtsd ki a feltöltött PDF-eket (WordPressnél a médiatárból vagy a wp-content/uploads mappából), és alakítsd szöveggé:

for f in *.pdf; do pdftotext "$f" - | grep -iHn --label="$f" -E "garancia|nyitva|telefon"; done

5. Vesd össze a láblécet, a fejlécet és a kapcsolat oldalt

A lábléc minden oldalon megjelenik, ezért egy hibás nyitvatartás ott több száz példányban szerepel. Gyakori, hogy a láblécet egy widget, a kapcsolat oldalt egy oldalépítő modul, a térképet egy harmadik bővítmény kezeli, és mindháromban külön van beírva az adat.

6. Ellenőrizd a strukturált adatot

A JSON-LD jelölést a látogató nem látja, ezért könnyen elavul. Nézd meg a forráskódban, vagy a Schema.org Validatorral és a Google Rich Results Testtel. Egy helyi vállalkozás jelölésének releváns része így nézhet ki:

{"@context": "https://schema.org", "@type": "LocalBusiness", "name": "Példa Kft.", "foundingDate": "2006", "numberOfEmployees": {"@type": "QuantitativeValue", "value": 8}, "areaServed": "Fejér megye", "openingHoursSpecification": [{"@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "08:00", "closes": "17:00"}]}

Hivatalosan igazolt. A Google strukturáltadat-irányelvei szerint a jelölésnek a látogató számára látható tartalmat kell tükröznie, és nem lehet félrevezető. Ha a JSON-LD mást mond, mint a lábléc, az irányelv-sértés is lehet, nem csak ellentmondás.

7. Pillants rá a külső profilokra is

Szigorúan véve nem a weboldalad része, de az AI-válaszok gyakran a Google Cégprofilt, a Facebook-oldalt és a katalógusoldalakat is felhasználják. Ha a saját oldalad már egységes, ezeket igazítsd hozzá.

Hogyan néz ki a kanonikus adattábla, és mit érdemes beleírni?

A kanonikus adattábla egyetlen dokumentum, amely minden kulcsadatnál rögzíti a hiteles értéket, a forrását, az összes előfordulási helyét és az utolsó ellenőrzés dátumát. Ebből dolgozik mindenki, aki az oldalhoz nyúl. Egy közös táblázatkezelőben ezekkel az oszlopokkal érdemes indulni:

• Adat neve (például garanciaidő)
• Kanonikus érték (például 24 hónap)
• Megfogalmazás a weboldalon (a pontos, jóváhagyott mondat)
• Hiteles forrás (ÁSZF, cégkivonat, belső döntés)
• Előfordulási helyek (URL-ek, PDF-ek, lábléc, JSON-LD, Cégprofil)
• Felelős
• Utolsó ellenőrzés
• Következő ellenőrzés
• Megjegyzés (például várható változás, régi érték, amit keresni kell)

Egy kitöltött sor CSV-formában:

Garanciaidő;24 hónap;"24 hónap teljes körű garanciát adunk";ÁSZF 6. pont;/garancia, /aszf, arlista.pdf, lábléc, JSON-LD;ügyvezető;2026-10-01;2027-01-01;régi érték: 3 év (kampány-landing)

Az időben elavuló adatokat évszámmal rögzítsd. A „2006 óta” mondat helyes marad, a „20 éve” nem.

Mit csinálj, ha találtál egy ellentmondást?

Döntsd el, melyik érték a hiteles, írd be a kanonikus táblába, majd minden előfordulásnál javítsd vagy egyértelműen jelöld az elavult tartalmat. A javítás sorrendje a gyakorlatban így működik jól:

1. A hiteles érték rögzítése a táblában, forrással együtt.
2. A sablonszintű helyek javítása (lábléc, fejléc, widgetek), mert ezek a legtöbb oldalon jelennek meg.
3. A strukturált adat frissítése, majd ellenőrzése validatorral.
4. A PDF-ek cseréje ugyanazon az URL-en, vagy ha új URL kell, a régi átirányítása.
5. A régi blogcikkek frissítése, vagy egy jól látható „Ez a cikk 2019-ben készült, a garanciaidő azóta 24 hónap” megjegyzés.
6. Megszűnt szolgáltatás oldalánál 301-es átirányítás a legközelebbi élő oldalra, vagy egyértelmű tájékoztatás a megszűnésről.
7. A külső profilok igazítása.

Saját tapasztalat. Ha egy adatot ismétlődően több helyre kell beírni, érdemes központi helyre tenni, például egy WordPress-beállításba vagy rövidkódba, amit a lábléc, a kapcsolat oldal és a sablonok is onnan olvasnak. Így a következő változásnál egy helyen kell módosítani.

Szakmai feltételezés. Az AI-rendszerek nem azonnal követik a javítást. Az újbóli feltérképezés és a válaszok frissülése oldalanként és rendszerenként eltérő ideig tarthat, erről a szolgáltatók nem adnak pontos ígéretet.

Ki legyen a felelős az adatok egységességéért?

Legyen egy megnevezett gazdája a kanonikus táblának, aki dönt a hiteles értékről, és legyen egy végrehajtója, aki a weboldalon és a profilokban átvezeti. Kisebb cégnél ez lehet ugyanaz az ember, de a döntést mindig az hozza, aki az adat mögötti valóságért felel.

• Adatgazda. Jellemzően az ügyvezető vagy az irodavezető. Ő tudja, mennyi a garancia és ki dolgozik a cégnél.
• Végrehajtó. A weboldalt kezelő kolléga vagy ügynökség. Ő javít, ő futtatja a keresést, ő frissíti a JSON-LD-t.
• Jelzők. Mindenki, aki változásról tud (HR új kollégáról, értékesítés új szolgáltatási területről). Nekik egy egyszerű szabály kell. Ha változik egy kulcsadat, szólnak az adatgazdának.

A legtöbb ellentmondás onnan jön, hogy a változásról a weboldalt kezelő ember nem értesül, vagy csak az egyik helyen írja át. A felelősség kijelölése ezen segít a legtöbbet.

Milyen gyakran érdemes megismételni az ellenőrzést?

Negyedévente egy gyors ellenőrzés és évente egy teljes átvizsgálás jó kiindulópont, emellett minden ismert változás után azonnal érdemes célzottan átnézni az érintett adatot.

• Eseményhez kötve. Költözés, új telephely, nyitvatartás-változás, létszámváltozás, új garanciafeltétel, szolgáltatás megszűnése, weboldal-újratervezés vagy migráció után.
• Negyedévente. A kulcsadatok grep-keresése, a lábléc, a kapcsolat oldal és a JSON-LD összevetése a táblával.
• Évente. Teljes kör a régi blogcikkekkel, a PDF-ekkel és a külső profilokkal együtt. Ilyenkor érdemes az „X éve” típusú mondatokat is levadászni.
• Szúrópróbaszerűen. Kérdezz rá a cégedre néhány AI-asszisztensnél („Mennyi garanciát ad a Példa Kft.?”), és nézd meg, milyen forrásra hivatkoznak. Ha rossz adatot látsz, a forrás gyakran megmutatja, hol maradt elavult tartalom.

Saját tapasztalat. Az ütemezett, naptárba írt ellenőrzés sokkal ritkábban marad el, mint a „majd ha lesz időnk” típusú. A negyedéves kör egy kis oldalnál rövid feladat, ha a kanonikus tábla és a keresőparancsok már készen állnak.

Mi számít hivatalos információnak, és mi tapasztalatnak ebben a témában?

Hivatalosan igazolt, hogy a nyelvi modellek tévedhetnek, és hogy a strukturált adatnak a látható tartalmat kell tükröznie; az viszont már tapasztalat és feltételezés, hogy pontosan mennyit javít az egységes adat az AI-válaszokon.

• Hivatalosan igazolt. Az LLM-ek hallucinálhatnak (OpenAI, Google). A Google AI-funkciói a megszokott keresési rendszerekre épülnek. A JSON-LD nem térhet el a látható tartalomtól (Google strukturáltadat-irányelvek). A Schema.org definiálja a foundingDate, numberOfEmployees, areaServed és openingHoursSpecification tulajdonságokat.
• Saját tapasztalat. A hibás AI-válasz forrása gyakran a cég saját elavult tartalma. A PDF-ek és a régi blogcikkek a leggyakoribb rejtett ellentmondás-források.
• Szakmai feltételezés. Az egységes adat jó eséllyel csökkenti a hibás válasz kockázatát, de semmilyen helyes megjelenést nem garantál, és a javítás hatása rendszerenként eltérő idő alatt látszik.

Mi legyen az ellenőrzőlistádon?

• Megvan a kulcsadat-lista keresőszavakkal.
• Lefutott a teljes oldalas keresés (site: és helyi másolat).
• A régi blogcikkek át vannak nézve, a szükségesek frissítve vagy jelölve.
• A PDF-ek szöveggé alakítva és átvizsgálva.
• A lábléc, a fejléc, a kapcsolat oldal és a térkép egyezik.
• A JSON-LD egyezik a látható tartalommal, validatorral ellenőrizve.
• A Google Cégprofil és a közösségi profilok igazítva.
• A kanonikus tábla kitöltve, felelőssel és következő ellenőrzési dátummal.
• Az „X éve” típusú mondatok évszámra cserélve.

Források és további olvasnivalók

• Google Search Central, Általános strukturáltadat-irányelvek
• Google Search Central, AI-funkciók és a weboldalad (AI Overviews, AI Mode)
• Google Search Central, Helyi vállalkozás (LocalBusiness) strukturált adat
• Schema.org, Organization és LocalBusiness típusok dokumentációja
• OpenAI, A ChatGPT keresés és az OAI-SearchBot crawler dokumentációja
• OpenAI, Why language models hallucinate (kutatási összefoglaló)
• W3C, JSON-LD 1.1 ajánlás