A Search Console webes felülete kényelmes addig, amíg havonta egyszer ránézel egy vonaldiagramra. Amint viszont valódi döntéseket akarsz hozni belőle, gyorsan falba ütközöl: a táblázat csak az első ezer sort mutatja, az összehasonlítás legfeljebb két időszakot enged, az exportot kézzel kell elindítani, és fél év múlva már nem tudod visszanézni, pontosan mi történt egy adott héten. Az API ugyanazt az adatbázist nyitja meg, csak korlátozás nélküli bontásban és emberi kattintgatás nélkül. Egy magyar kkv-nál, ahol nincs külön analitikus, ez a különbség dönti el, hogy az adat valóban használható-e vagy csak dísz.
Mit ad a Search Console API, amit a felület nem?
Röviden: mennyiséget, folytonosságot és szabad kombinálhatóságot. Hivatalosan igazolt: a Search Analytics végpont kérésenként legfeljebb 25 000 sort ad vissza, és lapozással ennél is többet érhetsz el, míg a felület táblázata jóval kevesebbet jelenít meg. Ugyancsak hivatalos, hogy az adatok 16 hónapig érhetők el visszamenőleg, tehát ami ennél régebbi, az végleg eltűnik, ha nem mentetted el.
A gyakorlati különbség ennél is nagyobb. Az API-ban egyetlen kérésben kombinálhatod a keresőkifejezést, a céloldalt, az eszközt és az országot, így megkapod azt a listát, amit a felületen csak sok tucat szűréssel tudnál összerakni. Ha ezt naponta lefuttatod és elmented, néhány hónap alatt olyan saját adatbázisod lesz, amit a Google már nem tud elvenni tőled.
Saját tapasztalat: a legtöbb kisvállalkozásnál nem a kulcsszókutatás hiánya a probléma, hanem az, hogy senki nem tudja megmondani, mire jelent meg valójában az oldal az elmúlt negyedévben. A napi mentés ezt a kérdést egyszer és mindenkorra leveszi a napirendről.
Milyen adatokat lehet ténylegesen kinyerni programozottan?
Az API négy fő területet fed le, és érdemes tudni, melyik mit ad.
- Keresési teljesítmény (Search Analytics): kattintás, megjelenés, átkattintási arány és átlagos pozíció, a következő bontásokban: keresőkifejezés, oldal, ország, eszköz, dátum és keresési megjelenés (például kiemelt találat vagy termékadat).
- Keresési típusok: a lekérésben megadhatod, hogy webes, kép-, videó- vagy hírtalálatokra kérdezel, sőt a Discover és a Google Hírek felület adatai is elérhetők, ha az adott domainnél egyáltalán keletkezik ilyen forgalom.
- URL-ellenőrzés (URL Inspection API): egy adott cím indexelési állapota, a legutóbbi feltérképezés dátuma, a kanonikus URL és a strukturált adatok észlelése. Hivatalosan igazolt: ebből naponta 2000 lekérés futtatható property-nként.
- Sitemap-adatok: mikor olvasta be a Google a webhelytérképet, hány URL-t talált benne, jelzett-e hibát.
Amit viszont nem kapsz meg: keresési volumen, versenytársak adatai, konverzió, felhasználói azonosító, és semmilyen olyan mező, ami egyedi látogatót azonosítana. Az API kizárólag a saját, igazolt tulajdonú property-d aggregált teljesítményét adja vissza.
Hol vannak a korlátok, amiket érdemes előre tudni?
A legfontosabb korlát nem technikai, hanem adatvédelmi. Hivatalosan igazolt: a Google elhagyja azokat a keresőkifejezéseket, amelyeket túl kevesen használtak, mert azonosíthatók lennének. Ennek egyenes következménye, hogy ha keresőkifejezés szerinti bontásban kérsz adatot, a sorok összege kevesebb lesz, mint a bontás nélküli összesítés. Ez nem hiba a szkriptedben, hanem tervezett működés. Egy kisebb magyar szolgáltatónál, mondjuk egy Székesfehérváron dolgozó asztalosnál, ez a kimaradás akár a megjelenések jelentős részét is érintheti, mert sok a nagyon ritka, egyedi keresés.
További korlátok, amikkel számolni kell:
- Késleltetés: a friss adat általában két-három napos csúszással válik teljessé. A lekérésben a
dataStateparaméterrel kérheted a nem véglegesített adatot is, de akkor tudnod kell, hogy a legutóbbi napok még változni fognak. - Kvóták: percenkénti és napi lekérési korlátok élnek, projekt- és property-szinten egyaránt. Napi egyszeri, jól megírt lekérésnél ezt nehéz elérni, de egy hibás, végtelen ciklusban lapozó szkript könnyen belefut.
- Property-típus: domain szintű és URL-előtag szintű property más adatot ad. Ha csak a
https://www.pelda.hu/előtagot igazoltad, a www nélküli vagy aldomain forgalom hiányozni fog. - Pozícióadat: az átlagos pozíció aggregált érték, nem az, amit te látsz keresésnél. Két hasonló szám mögött teljesen más eloszlás állhat.
Szakmai feltételezés: ahogy a keresési eredmények egyre inkább generált válaszokká alakulnak, a megjelenés fogalma is puhul. Nem tudni pontosan, egy AI-összefoglalóban való szerepeltetés hogyan csapódik le a megjelenésekben, ezért a hirtelen megjelenésszám-változásokat érdemes óvatosan értelmezni.
Hogyan indítsd el a napi lekérést lépésről lépésre?
A folyamat egy átlagos kkv-nál fél nap alatt összerakható, és utána évekig fut magától.
- Hozz létre egy projektet a Google Cloud felületén, és kapcsold be benne a Search Console API-t.
- Készíts szolgáltatásfiókot, tölts le hozzá egy kulcsfájlt, majd a Search Console beállításaiban add hozzá a szolgáltatásfiók e-mail-címét felhasználóként a property-hez. Ez a lépés marad ki a leggyakrabban, és ilyenkor jogosultsági hibát kapsz.
- Telepítsd a hivatalos klienskönyvtárat (Pythonban a
google-api-python-clientcsomagot), és írj egy rövid szkriptet, ami lekéri az előző napokat. - A lekérés törzse nagyjából így néz ki:
{'startDate': '2026-08-01', 'endDate': '2026-08-07', 'dimensions': ['date','query','page'], 'rowLimit': 25000, 'startRow': 0, 'dataState': 'final'}, és amíg 25 000 sort kapsz vissza, lapozz tovább astartRownövelésével. - Az eredményt írd egy adatbázisba vagy akár egy napi bontású fájlba, kulcsként a dátum, kifejezés és oldal hármassal, hogy az ismételt futás ne duplázzon.
- Ütemezd naponta egyszer, kora reggelre. Kérj le mindig egy visszamenőleges ablakot is, például az elmúlt öt napot, és írd felül a korábbi sorokat, mert a friss adat még pontosodik.
- Építs rá egy egyszerű riasztást: ha egy fontos oldal kattintása az előző négy hét azonos napjaihoz képest jelentősen visszaesik, menjen róla e-mail.
Aki nem akar kódot írni, annak a Looker Studio beépített csatlakozója is használható, de az szintén a felület korlátaival dolgozik nagyobb bontásoknál, és nem archivál. A saját mentés értéke pont az archiválásban van.
Milyen kérdésekre ad választ a napi adat, amit a felület nem?
A legérdekesebb kérdések majdnem mind idősor-jellegűek, és a felület nem enged tetszőleges idősort tetszőleges bontásban.
- Mikor pontosan mozdult el egy oldal? Napi bontásban látszik, hogy egy esés egyetlen napon történt (ami inkább algoritmusfrissítésre vagy technikai hibára utal), vagy két hét alatt csúszott le fokozatosan.
- Új kifejezésre jelentél meg, vagy a régiek erősödtek? Ha minden nap elmented a kifejezéslistát, egyszerű halmazkülönbséggel megkapod, mely keresések jelentek meg először ezen a héten. Egy debreceni állatorvosi rendelőnél például kiderülhet, hogy a növekedés nem a fő szolgáltatásból jött, hanem tucatnyi új, tünetleíró kérdésből.
- Kannibalizálják-e egymást az oldalaid? A kifejezés és oldal együttes bontásából látszik, ha ugyanarra a keresésre hetente váltakozva más-más aloldalad jelenik meg. A felületen ezt csak egyesével, szűrögetve lehetne kibogozni.
- Kereslet csökkent vagy láthatóság? Ha a megjelenés stabil, de a kattintás esik, jó eséllyel a találati oldal szerkezete változott vagy a címsorod gyengült. Ha a megjelenés is esik, akkor pozíciót vagy indexeltséget vesztettél. Ez a két eset teljesen más beavatkozást igényel.
- Mi történik a hosszú farokkal? A ritka, hosszú kérdésekből álló forgalom összesítve gyakran nagyobb, mint a néhány fő kulcsszó, de a felület ezt egyszerűen nem mutatja meg egyben.
Saját tapasztalat: a napi mentés leggyakoribb haszna nem a nagy felismerés, hanem az, hogy egy panaszos telefonhívásra („zuhan a forgalom") tizenöt perc alatt lehet tényadattal válaszolni, nem érzésre. Ez nem garantál jobb helyezést, de sokkal jobb döntéseket tesz lehetővé.
Hogyan kapcsolódik ez az AI-keresőkben való láthatósághoz?
A generált válaszok korában a klasszikus kattintás egyre kevesebbet mond el önmagában. A Search Console adata viszont továbbra is az egyetlen olyan forrás, amelyben a Google saját mérése szerepel arról, hogy egyáltalán megjelentél-e egy kérdésre. Szakmai feltételezés: ha egy oldal megjelenésszáma stabil vagy nő, miközben az átkattintási arány tartósan csökken, az egyik lehetséges magyarázat, hogy a választ maga a találati oldal adja meg. Ez nem bizonyíték, csak jelzés, és érdemes más forrásokkal, például a hivatkozó forgalom elemzésével összevetni.
A gyakorlatban ezért két számot érdemes külön követni: a kérdés jellegű, több szóból álló keresések megjelenéseit, és ezek átkattintási arányát. Ha az előbbi nő, a tartalmad releváns marad a kérdésekre, akkor is, ha a kattintás nem követi. Ez a mérés önmagában nem mutatja meg, hogy egy chatbot idézett-e téged, de a legolcsóbb rendszeres visszajelzés arról, hogy a tartalom egyáltalán versenyben van-e.
Mit ellenőrizz az első hónapban?
- A szolgáltatásfiók tényleg megkapta a hozzáférést a property-hez, és a szkript nem csendben, hibaüzenet nélkül hal el.
- A property típusa (domain vagy URL-előtag) lefedi az összes verziót, amin forgalmad lehet.
- A lapozás működik: ha pontosan 25 000 sort kapsz, akkor biztosan van még adat.
- A visszamenőleges felülírás beépült, különben az utolsó napok tartósan alulmérve maradnak.
- Az adatot időbélyeggel mented, hogy később kiderüljön, mikor futott a lekérés.
- A tárolt adat mérete kezelhető marad: egy közepes kkv-oldalnál napi néhány tízezer sor néhány év alatt is elfér egy egyszerű adatbázisban.
- A riasztás küszöbe nem túl érzékeny, különben egy hónap után senki nem olvassa el.
Milyen hibákat érdemes elkerülni?
A leggyakoribb tévedés, hogy valaki a részletes bontás sorait összeadja, és eltérést talál az összesítéshez képest, majd hibát keres a kódban. Nincs hiba, ez az anonimizálás következménye. A második gyakori csapda az átlagos pozíció túlértelmezése: egy 8,4-es átlag jelenthet stabil nyolcadik helyet és erős ingadozást is, ezért a döntést inkább a megjelenés és kattintás alapján hozd meg. A harmadik, hogy a friss, még véglegesítetlen napokra épül riasztás, ami hamis pánikot okoz minden reggel.
Végül: az adat önmagában nem javít semmit. A napi lekérés akkor ér valamit, ha havonta legalább egyszer valaki tényleg végignézi, kérdést tesz fel neki, és abból tartalmi vagy technikai feladat születik.
Források és további olvasnivalók
- Google Search Central: Search Console API dokumentáció (Search Analytics, URL Inspection, Sitemaps végpontok)
- Google Search Central: Search Console adatkezelési és anonimizálási tudnivalók
- Google Cloud dokumentáció: szolgáltatásfiókok és OAuth 2.0 hitelesítés
- Google Search Central Blog: keresési teljesítményjelentés frissítései
- Schema.org: strukturált adat típusok referenciája
- W3C: webes szabványok és akadálymentességi ajánlások
- A felület soronkénti korlátja miatt a hosszú farok nagy része láthatatlan marad, az API viszont kérésenként akár 25 000 sort ad vissza.
- A napi automatizált mentés a 16 hónapos adatmegőrzési ablakon túl is megőrzi a saját idősorodat.
- Az anonimizált keresések miatt a részletes bontások összege soha nem fogja kiadni a teljes összesítést, ez nem hiba, hanem tervezett működés.
- A kereslet és a megjelenés szétválasztása (megjelenés, pozíció, kattintás külön) mutatja meg, hogy forgalomvesztés vagy csak láthatóságvesztés történt.
- A napi mentés a nulla kattintásos válaszmotoros környezetben az egyik legolcsóbb objektív visszajelzés a tartalmaidról.
Gyakori kérdések
Kell hozzá programozói tudás, ha kkv-t vezetek?
Alapszintű szkriptelés vagy egy fejlesztő pár órás segítsége elég. A lekérés maga néhány tucat sor kód, és ha egyszer fut, utána nem igényel beavatkozást. Aki egyáltalán nem akar kódhoz nyúlni, annak a Looker Studio csatlakozója jelent részleges megoldást, de az nem archiválja hosszú távra az adatot.
Miért kevesebb a kulcsszavas bontás összege, mint a teljes szám?
Mert a Google elhagyja a nagyon ritka kereséseket, amelyekből visszakövethető lenne egy személy. Ez hivatalos, szándékos működés, nem mérési hiba. Ezért a részletes bontásokat mindig trendként érdemes nézni, nem abszolút könyvelési adatként.
Meddig érhető el visszamenőleg az adat?
Hivatalosan 16 hónapig. Ennél régebbi időszakot az API sem ad vissza, ezért éri meg naponta menteni: a saját adatbázisodban utána tetszőlegesen hosszú idősorod lesz, amit már senki nem törölhet ki alólad.
Naponta hányszor érdemes lekérni?
Napi egy futás bőven elég, mert az adat sem frissül ennél sűrűbben érdemben. Fontos viszont, hogy ne csak az előző napot kérd le, hanem egy néhány napos visszamenőleges ablakot is, mert a friss adat még pontosodik.
Megmutatja az API, hogy szerepelek-e egy AI-válaszban?
Közvetlenül nem. Nincs olyan mező, ami ezt jelezné. Közvetett jelzés lehet, ha egy oldal megjelenései stabilak, de az átkattintási arány tartósan csökken, ez azonban feltételezés, amit más adatforrásokkal kell alátámasztani.
Mi a leggyakoribb beállítási hiba?
Hogy létrejön a szolgáltatásfiók, de senki nem adja hozzá felhasználóként a Search Console property-hez. Ilyenkor a szkript jogosultsági hibát kap. A második leggyakoribb a rossz property-típus, ami miatt a forgalom egy része láthatatlan marad.
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.