- A technikai döntéshozó nyelvi modellel rövidíti a beszállítói listát, így a gép által olvasható szakmai tartalom a belépő.
- A stacket, verziószámot és integrációs tapasztalatot konkrétan ki kell írni, mert az AI a szövegben szereplő entitásokat tudja csak összekapcsolni.
- A kliensoldali renderelés és a bezárt dokumentáció a leggyakoribb technikai ok, amiért egy fejlesztő cég láthatatlan marad.
- A TechArticle, SoftwareApplication és FAQPage jelölés segítheti az értelmezést, de önmagában nem ad helyezést.
- Az AI-láthatóságot rendszeres, naplózott promptteszteléssel és GA4 hivatkozó-forgalommal érdemes követni.
Ha szoftverfejlesztéssel, rendszerintegrációval vagy IT-üzemeltetéssel foglalkozol, a vevőd nem úgy keres, mint egy fürdőszoba-felújítást tervező családapa. A tipikus döntéshozó nálad egy CTO, egy fejlesztési vezető vagy egy termékmenedzser, aki a saját munkájában is napi szinten használ nyelvi modelleket. Amikor beszállítót keres, ritkán néz végig tíz találatot: megkérdezi az asszisztensét, hogy melyik magyar csapatnak van tapasztalata legacy .NET Framework rendszer .NET 8-ra migrálásában, aztán a kapott három nevet ellenőrzi. Ez a szűrés gyorsabb és keményebb, mint bármelyik korábbi keresési szokás, és teljesen máshova helyezi a marketinged súlypontját.
Miben más az AI SEO egy szoftverfejlesztő cégnél?
A különbség egy mondatban: nálad nem a kereslet felkeltése a feladat, hanem az, hogy egy gépi szűrőn átmenj. A vevőd tudja, mit akar, ismeri a szakszavakat, és pontosan az a dolga, hogy kizárja azokat, akik nem hitelesek.
Saját tapasztalat: a legtöbb magyar IT-cég honlapja három-négy általános szolgáltatásoldalból áll (egyedi fejlesztés, webalkalmazás, tanácsadás, üzemeltetés), és ezek szövege szinte teljesen felcserélhető bármelyik versenytárséval. Egy nyelvi modell számára az ilyen oldal információsűrűsége majdnem nulla: nincs benne egyetlen entitás sem, amit horgonyként fel tudna használni. Ha a szövegedben nem szerepel, hogy Kubernetes, Postgres, RabbitMQ, Salesforce-integráció vagy PSD2-megfelelés, akkor ezekre a kérdésekre nem is fogsz felmerülni.
A gyakorlati következtetés kellemetlenül egyszerű. Az általánosan fogalmazott, mindenkinek szóló oldal helyett érdemes szűk, konkrét, technológiánként és problématípusonként bontott tartalmakat építeni, még akkor is, ha ezek külön-külön kevés látogatót hoznak. Az AI-válaszokban nem a látogatószám számít, hanem az, hogy van-e olyan bekezdésed, ami pontosan a feltett kérdésre felel.
Hogyan szűr téged egy technikai vevő, aki maga is AI-t használ?
A tipikus folyamat három lépcsős: az asszisztens ad egy rövid listát, a vevő ellenőrzi a listát a saját oldalaidon, végül a csapatával megnézi a nyilvános kódodat vagy dokumentációdat. Mindhárom lépcsőn külön kell átjutnod.
Az első lépcső az említés. Ide az kerül be, akinek a neve elég sok, egymással összhangban lévő helyen szerepel ugyanazokkal a technológiai kifejezésekkel együtt. Szakmai feltételezés: a modellek nem egyetlen forrásból dolgoznak, hanem a rólad szóló információk egybecsengéséből építenek bizalmat, ezért a saját honlapod, a cégadatbázisok, a szakmai portálok és a fejlesztői közösségek adatai közötti ellentmondás (más cégnév, más profil, elavult stack) rontja az esélyedet. Ezt hivatalos dokumentáció nem mondja ki így, de a gyakorlati megfigyelések ebbe az irányba mutatnak.
A második lépcső az ellenőrzés. Itt a vevő emberként olvas, és pár másodperc alatt eldönti, hogy értesz-e ahhoz, amit írsz. Egy fejlesztési vezetőt nem az győz meg, hogy "innovatív megoldásokat szállítunk", hanem az, hogy leírod, milyen konkrét kompromisszumot választottál egy adott helyzetben és miért.
A harmadik lépcső a mélyfúrás: nyilvános repók, csomagok, konferencia-előadás, blogbejegyzés kódmintával. Ha ezekből semmi sincs, a technikai vevő gyakran akkor is továbblép, ha a kereskedelmi ajánlatod rendben van.
Mit lát a te oldaladból egy modell, ha JavaScripttel renderelsz?
Rövid válasz: gyakran sokkal kevesebbet, mint amit te látsz a böngésződben. Hivatalosan igazolt: a Google Search Central dokumentációja szerint a Googlebot futtat JavaScriptet, de ez külön renderelési lépés, amely erőforrás-függő és késleltetést okozhat. Ugyanez a képesség viszont nem feltételezhető minden AI-crawlerről; több gyártó dokumentációja a nyers HTML letöltéséről beszél, a teljes böngészőalapú renderelést nem ígéri.
Ez az IT-szektorban azért fáj, mert pont a fejlesztő cégek oldalai épülnek gyakran React vagy Vue kliensoldali rendereléssel, gyakran statikus HTML-váz nélkül. A gyakorlati teszt egyszerű, futtasd le a saját oldaladon:
curl -s https://sajatdomain.hu/referenciak | wc -c, majd nézd meg, benne van-e a tényleges szöveg- kapcsold ki a JavaScriptet a böngészőben, és olvasd el az oldalt úgy
- a Search Console URL-ellenőrzőjében nézd meg a renderelt HTML-t
- ellenőrizd, hogy a fő tartalom nem csak görgetésre vagy kattintásra töltődik-e be
Ha az első parancs néhány kilobájtnyi keretet ad vissza szöveg nélkül, akkor szerveroldali renderelésre vagy statikus generálásra van szükséged a tartalmi oldalakon. A vezérlőpult maradhat kliensoldali, az a vevőnek szóló szöveg, ami nem.
Hogyan írj projektleírást úgy, hogy egy AI-asszisztens is fel tudja használni?
A használható projektleírás nem sikertörténet, hanem mérnöki napló. A tanulság ott van benne, hogy mi volt a kiinduló állapot, milyen korlátok között kellett dönteni, és mi lett a következménye.
Egy magyar kkv-méretű példán: tegyük fel, hogy egy nyolcfős csapat egy hazai gyártócég raktárkezelő alkalmazását újította fel. A gyenge leírás annyit mond, hogy "modern, felhasználóbarát rendszert készítettünk". Az erős leírás felépítése ehelyett ez:
- a kiinduló rendszer és a valós korlát (például Delphi kliens, egyetlen MSSQL-példány, éjszakai leállás nélküli átállás követelménye)
- a döntési pont és az elvetett alternatíva, indoklással
- a választott architektúra a konkrét komponensekkel és verziókkal
- az adatmigráció módszere és a validáció menete
- a mérhető technikai kimenet (például kötegelt zárás futásideje, hibaarány, üzemidő), üzleti túlígérés nélkül
- amit ma másképp csinálnál
Saját tapasztalat: ez az utolsó pont a legritkább és a leghatásosabb. Egy olyan bekezdés, amiben leírod, hogy egy adott döntés utólag drágának bizonyult, több bizalmat épít egy technikai olvasónál, mint három oldal önreklám. Nyelvi modell szempontjából pedig az ilyen szöveg tele van olyan konkrét összefüggéssel, amit idézni tud.
Fontos korlát: ha ügyfélnevet nem adhatsz meg, attól még leírhatod a szektort, a méretet és a technikai kontextust. Kitalált ügyfelet vagy kitalált számot semmiképp ne írj, mert egyetlen ellenőrzés lerombolja az egész oldal hitelét.
Miért a dokumentáció minősége a legerősebb AI-SEO eszközöd?
Mert a dokumentáció az egyetlen marketinganyag, amit a vevőd önszántából olvas el. Egy jól strukturált fejlesztői dokumentáció ráadásul pontosan olyan formátumú, amit a nyelvi modellek szeretnek: rövid, egyértelmű címek, feladatorientált bekezdések, kódpéldák, hibakódok magyarázata.
Ha van saját terméked, API-d vagy belső eszközöd, tedd a dokumentációt nyilvánossá, kereshető HTML-ben (ne csak PDF-ben), stabil URL-eken. Szakmai feltételezés: a hibaüzenetekre és konkrét paraméterekre írt magyarázó oldalak jó eséllyel gyakrabban kerülnek be a válaszokba, mint a marketingoldalak, mert ezek a szövegek egyértelműen egy kérdésre felelnek. Ez a megfigyelés logikus, de nem gyártói állítás.
Ugyanez működik akkor is, ha nincs terméked: írj le nyilvánosan megoldott, jól körülhatárolt problémákat. Egy "így oldottunk meg egy időzóna-hibát ütemezett feladatoknál" jellegű írás Székesfehérváron ülő csapattól ugyanúgy hasznos egy budapesti vevőnek, és pontosan az a fajta tartalom, ami mögé a modellek szakmai hitelt tudnak rendelni.
Milyen strukturált adatra van szükséged?
Hivatalosan igazolt: a Schema.org szótára tartalmazza a TechArticle, SoftwareApplication, SoftwareSourceCode, HowTo, FAQPage és Organization típusokat, a Google pedig külön dokumentálja, mely jelöléseket használja fel megjelenítéshez. Az is hivatalos álláspont, hogy a strukturált adat segíti az értelmezést, de önmagában nem ad jobb helyezést.
Egy tipikus IT-cégnél ez a minimum: Organization a főoldalon (pontos név, székhely, profil, hivatkozás a hiteles külső profilokra), Service vagy TechArticle a szakmai oldalakon, FAQPage ott, ahol tényleg kérdés-válasz szerkezet van. Egy vázlatos példa:
{"@context":"https://schema.org","@type":"TechArticle","headline":"Legacy .NET Framework migráció .NET 8-ra","proficiencyLevel":"Expert","about":{"@type":"SoftwareApplication","applicationCategory":"BusinessApplication"},"author":{"@type":"Organization","name":"Példa Kft."}}
A jelölés csak akkor ér valamit, ha megfelel az oldal látható tartalmának. Az eltérés irányelvsértés, és többet árt, mint amennyit használ.
Beengedd-e az AI-crawlereket?
Hivatalosan igazolt: az OpenAI dokumentációja leírja a GPTBot és az OAI-SearchBot user agenteket, és azt, hogy ezek a robots.txt szabályait követik; hasonló nyilvános leírás más gyártóknál is elérhető. A döntés tehát a tiéd, de a következménye is.
User-agent: GPTBotmajdAllow: /, ha azt akarod, hogy a nyilvános szakmai tartalmad felhasználható legyen- tiltás csak azokra a könyvtárakra, ahol ügyféladat vagy zárt anyag van
- a bot-forgalom terhelését inkább gyorsítótárral és rate limittel kezeld, ne teljes kizárással
- szerverlogból havonta nézd meg, mely AI-crawlerek járnak nálad és milyen státuszkódot kapnak
Saját tapasztalat: a teljes tiltás rövid távon csökkenti a szerverterhelést, hosszabb távon viszont kiveszi a céget azokból a válaszokból, ahol a vevő éppen szűkíti a listát. IT-cégnél ez különösen kockázatos, mert itt a vevő nagyobb arányban kezdi asszisztenssel a keresést.
Hogyan méred, hogy tényleg téged idéznek?
Mérés nélkül ez az egész hitkérdés marad. A minimum egy egyszerű, ismételhető promptteszt: állíts össze 20 kérdést, amit a vevőd valóban feltenne, futtasd le őket havonta több asszisztensben, és naplózd, hogy megjelent-e a céged, milyen kontextusban, és melyik oldaladra hivatkozott.
Ehhez jön a forgalmi oldal: a GA4-ben nézd külön az AI-felületekről érkező hivatkozó forgalmat, és ne a mennyiséget figyeld, hanem a viselkedést (mennyi ideig olvasnak, eljutnak-e a kapcsolatfelvételig). Szakmai feltételezés: az AI-ból érkező látogató jellemzően később van a döntési folyamatban, ezért kevesebb, de érettebb megkeresést hoz. Ez a mintázat sok helyen visszaköszön, de nem tekinthető általános törvényszerűségnek, és önmagában nem jelent biztos üzletet.
Milyen ellenőrzőlistával indulj el a következő 90 napban?
- Ellenőrizd, hogy a fő tartalmi oldalaid JavaScript nélkül is olvashatók-e.
- Írd ki minden szolgáltatásoldalon a konkrét stacket, verziókat és integrációkat.
- Készíts három részletes, mérnöki hangvételű projektleírást a fenti hatpontos váz szerint.
- Tedd nyilvánossá és kereshetővé a dokumentációt vagy legalább a megoldott problémák leírásait.
- Rakd fel a
TechArticle,FAQPageésOrganizationjelölést, és teszteld validátorral. - Egységesítsd a cégnevet és a profilt minden külső adatbázisban és szakmai profilon.
- Rendezd a robots.txt AI-crawler szabályait tudatos döntés alapján.
- Indítsd el a havi promptteszt-naplót 20 valós vevői kérdéssel.
- Nevezz meg egy felelőst, aki a szakmai tartalmakat lektorálja, hogy ne csússzon be technikai pontatlanság.
Ez a lista nem ígér helyezést és nem is ígérhet: az AI-válaszok összetétele változékony, ugyanarra a kérdésre két nap múlva más nevek jöhetnek. Amit befolyásolni tudsz, az az, hogy amikor a modell keres valakit a te szakterületeden, találjon-e nálad olyan konkrét, ellenőrizhető, gépileg is olvasható szakmai anyagot, ami mellé oda mer tenni egy cégnevet.
Források és további olvasnivalók
- Google Search Central: JavaScript SEO alapok, strukturált adat irányelvek, Search Console súgó
- Schema.org szótár: TechArticle, SoftwareApplication, SoftwareSourceCode, FAQPage, Organization
- OpenAI dokumentáció: GPTBot és OAI-SearchBot crawler leírás, robots.txt kezelés
- W3C: WCAG akadálymentességi irányelvek és szemantikus HTML ajánlások
- Google Analytics 4 súgó: forgalmi források és hivatkozó forgalom jelentései
- Robots Exclusion Protocol specifikáció (IETF RFC 9309)
Gyakori kérdések
Elég, ha csak a blogunkra írunk AI-nak szánt tartalmat?
Nem elég. Az AI-válaszokba jellemzően az kerül be, ami több, egymással összhangban lévő helyen visszaigazolható: a szolgáltatásoldal, a projektleírás, a dokumentáció és a külső szakmai profilok együtt adják ki a képet. Egy különálló blog önmagában ritkán bizonyul elég erős jelnek.
Muszáj nyilvánossá tenni a kódot ahhoz, hogy hiteles legyünk?
Nem muszáj, de a technikai vevő valamilyen ellenőrizhető nyomot keres. Ha a kódot nem oszthatod meg, helyettesítheted nyilvános dokumentációval, részletes technikai írásokkal, konferencia-előadással vagy nyílt forrású segédeszközzel. A lényeg, hogy legyen valami, amit a vevő maga is meg tud nézni.
Rontja-e az AI-láthatóságot, ha kizárjuk a botokat a szerverterhelés miatt?
Jó eséllyel igen, mert amit nem tudnak letölteni, azt nehezebben tudják idézni. A terhelést érdemesebb gyorsítótárral, tömörítéssel és kérésszám-korlátozással kezelni, a teljes tiltást pedig csak a zárt vagy érzékeny könyvtárakra korlátozni.
Mennyi idő alatt látszik bármi az AI-válaszokban?
Ez nem tervezhető pontosan, mert a modellek frissítési ciklusa és a keresőalapú válaszok forrásválasztása is eltérő. A tapasztalat az, hogy a keresésre támaszkodó válaszokban hetek alatt megjelenhet az új tartalom, a modellek belső tudásába kerülés viszont jóval lassabb és bizonytalanabb folyamat.
Angolul vagy magyarul írjunk, ha külföldi ügyfelet is szeretnénk?
Mindkettőt érdemes, de külön, teljes értékű nyelvi verzióként, helyes hreflang jelöléssel, nem gépi fordításként ugyanazon az URL-en. A magyar tartalom a hazai vevőnél és a magyar nyelvű kérdéseknél számít, az angol pedig a nemzetközi szakmai kontextusban.
Kell-e külön oldalt csinálni minden technológiának?
Akkor érdemes, ha valóban van mögötte tapasztalat és mondanivaló. Egy vékony, kulcsszóért létrehozott oldal inkább árt, mert felhígítja a szakmai képet. Jobb kevesebb, de mély oldal, amiben konkrét döntések és megoldások szerepelnek.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.