Van egy visszatérő jelenet az ügyfél-egyeztetéseken. Kimásolod a Search Console lekérdezés-táblázatát, összeadod a kattintásokat, és 612 jön ki ott, ahol a riport teteje 941-et mutat. Átváltasz az Oldalak fülre, ott meg 878 az összeg. Három szám, egy időszak, egy property, és az ügyfél joggal kérdezi meg, melyiket higgye el.
A rossz válasz az, hogy a Google hibázik. A jó válasz az, hogy a Search Console nem könyvelési rendszer, hanem adatvédelmi okból szűrt, sorszámban korlátozott, dimenziónként pedig eltérően összesített riport. Aki ezt pontos kimutatásnak adja el, az előbb vagy utóbb olyan állítást tesz, amit nem tud megvédeni. Ebben a cikkben végigveszem, mi okozza az eltérést, és hogyan lehet mégis becsületesen riportolni.
Miért kevesebb a lekérdezésekre bontott kattintások összege a teljes számnál?
Rövid válasz: mert a teljes szám minden kattintást tartalmaz, a lekérdezés-táblázat viszont csak azokat, amelyeket a Google hajlandó lekérdezésenként megmutatni. A különbség három forrásból jön: az anonimizált lekérdezésekből, a sorlimitből, és abból, hogy egyes szűrők csendben átkapcsolják az aggregáció módját.
Hivatalosan igazolt: a Google Search Central dokumentációja kimondja, hogy a teljesítmény-riport nem jelenít meg olyan lekérdezéseket, amelyeket csak nagyon kevesen kerestek. Ezek a kattintások és megjelenések nem tűnnek el a rendszerből, beleszámítanak az összesített értékekbe, csak nem kapnak saját sort. Ezért matematikailag garantált, hogy a lekérdezés-bontás összege kisebb vagy egyenlő lesz a teljes számnál, soha nem nagyobb.
Saját tapasztalat: minél szélesebb és minél hosszabb farkú egy oldal keresési profilja, annál nagyobb a rés. Egy szűk, néhány tucat kulcskifejezésre élő szolgáltatásoldalnál a lefedettség jellemzően magas, egy sok száz aloldalas, sokféle információs kérdésre válaszoló tudásbázisnál viszont a bontás a teljes forgalom jóval kisebb részét mutatja meg. Ezt érdemes minden propertyn külön megmérni, nem általános ökölszabályt használni rá.
Mit jelent pontosan az anonimizált lekérdezés?
Rövid válasz: olyan keresőkifejezés, amelyet a Google azért nem ír ki, mert annyira ritka, hogy a megmutatásával személyt lehetne azonosítani.
Gondolj bele, milyen keresések futnak be egy ügyvédi iroda vagy egy magánorvosi rendelő oldalára. Az emberek beírják a saját nevüket, a lakcímüket, az ügyük azonosítóját, néha az egész élethelyzetüket egy mondatban. Ha a Search Console ezeket kilistázná, a tulajdonos lényegében egyéni keresési előzményeket olvasna. A szűrés tehát nem kényelmetlenség, hanem a rendszer egyik alapvető viselkedése.
Fontos részlet, hogy ez nem fix darabszámhoz kötött küszöb, amit ki lehetne számolni, és nem is állítható be. Szakmai feltételezés: a küszöb dinamikus, és összefügg a lekérdezés gyakoriságával az adott időszakban, ezért ugyanaz a kifejezés az egyik hónapban megjelenhet, a következőben nem. Ebből következik egy gyakorlati csapda: ha egy kulcskifejezés eltűnik a listádból, az önmagában nem bizonyítja, hogy a helyezésed romlott, csak annyit jelent, hogy a keresési volumene a küszöb alá esett.
Mennyit visz el a sorlimit a riportból?
Rövid válasz: a felületen a táblázat legfeljebb 1000 sort mutat, tehát minden, ami az ezres sorszám alatt van, egyszerűen nem kerül bele az összegzésbe.
Hivatalosan igazolt: a webes felület teljesítmény-táblázata 1000 sorra van korlátozva, a Search Analytics API viszont kérésenként lényegesen több sort ad vissza, jelenleg legfeljebb 25 000-et, és lapozással tovább lehet haladni. Vagyis ha az API-n keresztül kérdezel le, a bontás összege közelebb kerül a teljes számhoz, de az anonimizált rész miatt akkor sem éri el.
Ez a különbség önmagában is tud ügyfél-félreértést okozni. Ha te egy exportáló eszközből dolgozol, az ügyfél pedig a saját felületén nézi ugyanazt az időszakot, két eltérő összeget fogtok látni ugyanarra a kérdésre. Érdemes előre tisztázni, melyik forrásból riportoltok, és utána abból dolgozni végig.
Miért nem adódik ki az oldalak összege sem?
Rövid válasz: mert az oldal-bontásra is él a sorlimit, és mert a kattintás nem minden esetben rendelhető hozzá egy stabil URL-hez.
Itt érdemes egy árnyalatot kiemelni, amit sokan elrontanak. A kattintás mindig egy konkrét találathoz, tehát egy URL-hez tartozik, ezért az oldal-bontás elvileg sokkal közelebb van a teljes számhoz, mint a lekérdezés-bontás. Ha mégis nagy a rés, az általában nem adatvédelmi szűrés, hanem levágott hosszú farok: sok olyan aloldal van, amelyik havi egy-két kattintást hozott, és a táblázat ezredik sora alá szorult.
Szakmai feltételezés: a maradék eltérésben szerepe lehet az átirányításoknak és a kanonikus URL-ek időközbeni változásának is, mert ilyenkor ugyanaz a forgalom több URL-sorra hasad szét, vagy éppen olyan címre kerül, amit már nem keresel a riportban. Ezt kívülről nem lehet visszaigazolni, ezért soha ne állítsd tényként az ügyfélnek.
Mit jelent a property-szintű és az oldal-szintű aggregáció?
Rövid válasz: ugyanaz a keresési esemény másképp számolódik attól függően, hogy a teljes webhelyre vagy egyetlen oldalra nézed, ezért a két nézet nem is adhatja ugyanazt.
Megjelenés
Hivatalosan igazolt: ha egy keresési találati oldalon a te webhelyedről két URL is szerepel ugyanarra a lekérdezésre, property-szintű aggregációnál ez egyetlen megjelenés, oldal-szintűnél viszont kettő. Vagyis az oldalankénti megjelenések összege szabályosan lehet nagyobb, mint a property teljes megjelenésszáma. Ez nem ellentmondás, hanem két különböző kérdésre adott két helyes válasz.
Átlagos pozíció
Property-szinten a legjobb helyezésű URL pozíciója számít, oldal-szinten mindegyik URL a sajátja. Ebből következik a leggyakoribb riportolási hiba: az átlagos pozíciókat nem lehet összeadni, kiátlagolni, sem oldalak között egyszerű számtani átlaggal összevonni. Ha mégis megteszed, egy olyan számot kapsz, aminek nincs jelentése, és az első komolyabb kérdésnél szétesik.
Erre rakódik rá még két dolog, amit érdemes fejben tartani: a Search Console adatai csendes-óceáni idő szerinti napokra vannak vágva, tehát a magyar naptári hónapod széle mindig kissé elcsúszik, és az utolsó néhány nap adata még változhat, mert a rendszer utólag pontosít.
Hogyan olvasd helyesen egy szolgáltatásoldal havi adatait?
Rövid válasz: felülről lefelé haladj, és minden lépésnél tudd, melyik szám mire vonatkozik. Nézzünk egy elméleti, illusztratív példát egy klímatelepítéssel foglalkozó vállalkozás egyetlen szolgáltatásoldalára.
- A property teljes szűretlen adata az adott hónapban 1240 kattintás. Ez a legmegbízhatóbb szám, mert semmilyen bontás nem vágja meg.
- Oldal-szűrővel a szolgáltatásoldalra 318 kattintás jön ki. Ez is szűretlen abban az értelemben, hogy nem sorlimitált összeg, tehát nyugodtan riportolható.
- Ugyanezen a szűrőn belül a lekérdezés-táblázat 194 sort mutat, ezek összege 201 kattintás. A különbözet, ebben a példában 117 kattintás, az anonimizált lekérdezésekből áll össze.
- A lefedettség tehát nagyjából 63 százalék. Ezt a mutatót érdemes hónapról hónapra kiszámolni, mert ha hirtelen leesik, az többnyire nem a forgalom szerkezetéről szól, hanem arról, hogy szélesebb, ritkább kérdéshalmazt kezdtél el behozni.
- Az átlagos pozíciót csak az oldalra szűrt nézetből olvasd ki, és mindig írd oda, hogy oldal-szintű aggregációról van szó.
A helyes olvasat ebben az esetben az, hogy a szolgáltatásoldal 318 kattintást hozott, ebből 201 esetben tudjuk, pontosan mire kerestek, a maradék pedig ritka, egyedi megfogalmazású keresésekből jött. Ez a mondat mind a két irányban igaz marad akkor is, ha valaki utánaszámol.
Melyik számot vidd ki az ügyfélnek, és mit írj mellé?
Rövid válasz: a fejléc mindig a szűretlen teljes szám legyen, a bontás pedig külön blokkban, irányjelzőként szerepeljen. Ez a rövid ellenőrzőlista minden havi riport előtt átfut nálam:
- A kiemelt kattintás- és megjelenésszám a szűretlen property-adatból jöjjön, ne táblázat-összegből.
- Az oldal-szintű számokat oldal-szűrővel olvasd ki, ne az oldalak listájából add össze őket.
- A lekérdezés-lista alá kerüljön egy állandó mondat, például: a lista a beazonosítható kereséseket tartalmazza, a ritka, egyedi lekérdezéseket a Google adatvédelmi okból nem bontja le, ezért a lista összege kevesebb a teljes értéknél.
- Átlagos pozíciót soha ne átlagolj több oldalra vagy több kulcskifejezésre.
- Hónapról hónapra ugyanabból a forrásból dolgozz, mert felület és API között eltérés lesz.
- Jelöld a dátumtartományt és minden aktív szűrőt, beleértve a keresés típusát is, mert a Discover és a Google Hírek adatai külön kezelendők.
- Ha domain property és URL-prefix property is létezik ugyanarra a webhelyre, döntsd el, melyik a hivatalos forrás, és maradj annál.
Ez a hat sor több vitát megspórol, mint bármilyen szép diagram. Az ügyfél nem attól lesz nyugodt, hogy nagy a szám, hanem attól, hogy a szám mögött van egy módszer, amit vissza tud kérdezni.
Mikor érdemes átváltani BigQuery exportra?
Rövid válasz: akkor, ha az anonimizált rész nagyságát nem csak becsülni akarod, hanem mérni.
Hivatalosan igazolt: a Search Console tömeges adatexportja napi bontásban tölti a Google BigQuery tábláit, és a webhely-szintű táblában külön logikai mező jelzi, hogy az adott sor anonimizált lekérdezésből származik-e. Ezzel az arány kiszámolhatóvá válik:
SELECT SUM(clicks) AS osszes_kattintas, SUM(CASE WHEN is_anonymized_query THEN clicks ELSE 0 END) AS anonim_kattintas FROM `projekt.searchconsole.searchdata_site_impression` WHERE data_date BETWEEN '2026-08-01' AND '2026-08-31'
Az export beállítása fejlesztői közreműködést és egy felhőprojektet igényel, a tárolás és a lekérdezés pedig a felhőszolgáltató szokásos elszámolása alá esik, ezért nem minden esetben indokolt. Saját tapasztalat: ott hozza a legtöbbet, ahol sok aloldal és széles kérdéshalmaz van, mert a felületes nézet éppen ilyenkor a legfélrevezetőbb. Egy néhány oldalas bemutatkozó webhelynél viszont felesleges bonyolítás.
Mi az, amit sosem szabad állítani a Search Console számairól?
Itt jön a saját nézőpontom, amit évek óta ugyanígy mondok el. A Search Console arra való, hogy irányt mutasson: nő vagy csökken a láthatóság, melyik oldal kezd el mozogni, milyen kérdéstípusok jönnek be. Arra nem való, hogy tételesen elszámoljon, mert nem is annak épült.
Ezért három mondatot érdemes kitiltani a riportjaidból. Az első, hogy ennyi kattintást hozott pontosan ez a kulcsszó, mert a bontás hiányos. A második, hogy ennyi az oldal átlagos helyezése a keresőben, mert az átlagos pozíció aggregációfüggő és erősen torzítható. A harmadik, hogy a számok eltérése a Google hibája, mert nem az, és ezzel a mondattal a saját szakmai hitelességedet égeted el.
Aki a Search Console-t pontos könyvelésnek adja el, az egy olyan ígéretet tesz, amit a rendszer felépítése tesz lehetetlenné. Aki viszont előre elmondja, mit mutat és mit nem, annál a hiányzó szám nem gyanú lesz, hanem szakértelem. Ez az egyetlen különbség a védhető és a védhetetlen riport között.
Források és további olvasnivalók
- Google Search Central: Search Console teljesítmény-riport súgó
- Google Search Central: Adateltérések a Search Console-ban
- Google Search Console API: Search Analytics dokumentáció
- Google Search Console: tömeges adatexport (Bulk data export) dokumentáció
- Google Cloud: BigQuery dokumentáció
- Google Search Central Blog: a teljesítmény-adatok feldolgozásáról szóló bejegyzések
- A lekérdezés-táblázat összege szinte soha nem egyezik a teljes kattintásszámmal, és ez nem hiba, hanem adatvédelmi tervezési döntés.
- Az anonimizált (ritka) lekérdezések benne vannak az összesítésben, de nem jelennek meg külön sorként.
- A felületen 1000 sor látszik, az API egy kérésben legfeljebb 25 000 sort ad vissza, tehát a hosszú farok magától levágódik.
- A megjelenés és az átlagos pozíció property- és oldal-szinten eltérően aggregálódik, ezért a két nézet számai nem vetíthetők egymásra.
- Ügyfélnek a szűretlen teljes számot vidd ki, a bontást külön blokkban, egy mondatos módszertani jegyzettel.
Gyakori kérdések
Miért nem jön ki a lekérdezések összege a teljes kattintásszámra?
Mert a Google adatvédelmi okból nem bontja le azokat a lekérdezéseket, amelyeket túl kevesen kerestek, és mert a táblázat sorszáma korlátozott. Ezek a kattintások benne vannak az összesítésben, csak nincs saját soruk.
Beállítható valahol, hogy lássam az anonimizált lekérdezéseket?
Nem. Ez a Search Console működésének alapvető része, nem kapcsolható ki. A BigQuery tömeges exporttal az anonimizált rész mennyisége mérhetővé válik, de maguk a kifejezések nem jelennek meg.
Hány sort mutat a Search Console felülete?
A teljesítmény-táblázat legfeljebb 1000 sort jelenít meg. Az API egy kérésben ennél lényegesen több sort ad vissza, és lapozással tovább lehet haladni, ezért az API-ból számolt összeg magasabb lesz.
Miért nagyobb az oldalankénti megjelenések összege a webhely teljes megjelenésszámánál?
Mert eltérő az aggregáció. Ha egy találati oldalon két URL-ed is szerepel, az a webhely szintjén egy megjelenés, oldal szinten viszont kettő. Mindkét szám helyes, csak más kérdésre válaszol.
Összeadhatom vagy átlagolhatom az átlagos pozíciókat?
Nem érdemes. Az átlagos pozíció aggregációfüggő érték, több oldalra vagy kulcskifejezésre vetített számtani átlaga értelmezhetetlen számot ad, amit egy kérdésnél nem tudsz megvédeni.
Melyik számot vigyem ki a havi riportba?
A szűretlen teljes kattintás- és megjelenésszámot, oldal-szinten pedig az oldal-szűrővel kiolvasott értéket. A lekérdezés-bontás menjen külön blokkba, egy mondatos magyarázattal arról, hogy miért kevesebb az összege.
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.