SEO audit: hogyan végzem el egy oldal auditját lépésről lépésre

A SEO audit döntés arról, mit érdemes az oldalon előbb javítani, minden ajánlásnál bizonyítékkal és a bevezetés utáni ellenőrzés módjával. Az eszköz hibalistája csak az audit alapanyaga. A technikai SEO audit az auditnak az a része, amely azt vizsgálja, hogy a keresők és az AI-asszisztensek robotjai le tudják-e tölteni és el tudják-e olvasni az oldalt, a kereső pedig indexelni tudja-e.

Az auditot nyolc lépésben végzem:

1. Meghatározom az oldal célját és helyzetét, mielőtt elindítanám a crawlert, vagyis azt a programot, amely úgy járja be az oldalt, ahogyan a kereső robotja.
2. Ellenőrzöm, hogy a robotok egyáltalán megkapják-e az oldalt.
3. Több forrásból gyűjtök adatokat, és megnézem, mit nem lát egyik-másik.
4. Megvizsgálom a kulcsszavakat és a Google-találatokat, mielőtt a technikával foglalkoznék.
5. Átnézem az oldalt a prioritási feltételekkel ellátott problémakatalógus szerint.
6. Minden tételnél bizonyítékot mutatok.
7. Meghatározom a sorrendet, a munkaráfordítást és a változatokat.
8. Keresztellenőrzésre adom, a bevezetés után pedig minden tételt ellenőrzök.

Mi az a SEO audit, és miben különbözik a technikai SEO audit?

A SEO audit megmondja, milyen állapotban van az oldal, és mi korlátozza a láthatóságát, a technikai SEO audit pedig azt ellenőrzi, hogy a kereső le tudja-e tölteni, renderelni és indexelni az oldalt. A teljes auditban megvizsgálom az oldalak technikáját, felépítését és tartalmát, a kulcsszavakat, a külső linkeket és a versenytársakat, a végén pedig sorrendbe teszem a teendőket. A technikai audit akkor elég, ha a kérdés technikai: forgalomesés egy bevezetés után, migráció, az indexből kieső oldalak.

Az audit a stratégia bemenete, nem maga a stratégia. A stratégia megmondja, milyen keresletért küzd, és miről mond le, az audit pedig azt, mi áll ennek ma az útjában. A SEO stratégiáról szóló szövegben leírtam, hogyan megy át az egyik a másikba.

Hogyan készül a SEO audit lépésről lépésre?

A lépések sorrendje számít, mert a korábbi lépések döntik el, hogy a későbbiek számai megbízhatók-e. Két helyen megállítom a folyamatot egy döntésre: az első lépés után meghatározom a terjedelmet, a keresztellenőrzés után pedig, az ügyfélnek való elküldés előtt, ellenőrzöm a prioritásokat és a téziseket.

Lépés 1. Az oldal célja és helyzete, mielőtt elindítanám a crawlert

Az első kérdés az, hogy az oldal veszít-e forgalmat, vagy nem építi, mert a válaszon múlik az egész audit. Az oldalnak, amelynek nincs láthatósága, először a kulcsszavak és a rájuk válaszoló oldalak térképére van szüksége. Annak az oldalnak, amelynek van láthatósága, először annak védelmére, ami már pozíciót foglal el, mielőtt bárki javítani kezdené.

Indulás előtt olyanokról kérdezek, amelyeket egyetlen eszköz sem mutat meg. Mely termékek vagy szolgáltatások hoznak pénzt, tervezik-e a tartalomkezelő rendszer cseréjét vagy átépítést, ki vezeti be az ajánlásokat, és mennyi ideje van rá. A válaszokból következik az audit terjedelme és azoknak a dolgoknak a listája, amelyeket nem részletezek, mert senki sem vezetné be őket.

Ezt a szakaszt önállóan kell végigjárni, bár ma sok szakember nyelvi modellre bízza. A nyelvi modell lehet hasznos, de nem érti meg az ügyfél üzletét. Azt a kreatív, egyedi nézőpontot sem hozza, amellyel a tapasztalt SEO szakember rendelkezik.

Lépés 2. Megkapják-e a robotok egyáltalán az oldalt

Mielőtt bármilyen számot elolvasnék az eszközből, ellenőrzöm, beengedi-e a szerver a robotokat, mert a kizárt robot olyan adatokat ad, amelyek SEO-problémának látszanak. 2026 júliusának egyetlen hetében három különböző oldalon három „SEO-probléma” robotblokádnak bizonyult:

1. Egy oldal több mint 2 200 linket „veszített”, mert a linkelemző eszköz robotját visszaverte a tűzfal azokon az oldalakon, ahonnan a linkek vezettek.
2. Egy webáruház eszközében az oldal egészségi pontszáma 0 volt közel 42 000 hibánál, mert az oldalak helyett az eszköz robotja a Cloudflare tűzfal válaszait kapta.
3. A harmadik oldalon egy blokád megállította a crawlert az első címen, és ezt három hétig senki sem észlelte.

Ugyanazt a címet letöltöm hétköznapi böngészőként, valamint a Google, a Bing, az OpenAI, a Perplexity és az Anthropic robotjaiként, majd összehasonlítom a válaszkódokat és az oldal méretét. A böngésző és a robot közötti különbség az első dolog, amit tisztázni kell, mielőtt bármit számolni kezdenék. Egy ilyen teszt a saját IP-címemről küld lekérdezéseket egy robot neve alatt, a tűzfalak pedig az igazi Google- és Bing-robotokat a címükről ismerik fel. A „Googlebot” blokkolása a tesztben tehát nem bizonyítja az igazi Googlebot blokkolását. A Search Console, a Google ingyenes panelje az oldal tulajdonosai számára, megmutatja, hogyan látja az oldalt az igazi Googlebot.

A robots.txt fájlt a végéig, parserrel olvasom el, vagyis olyan programmal, amely úgy alkalmazza a szabályokat, mint a robot, nem szemmel. A Google robotja csak egy szabálycsoportot alkalmaz, a legpontosabban illeszkedő robotnévvel jelöltet, a többit figyelmen kívül hagyja. Az útvonal nélküli Disallow: szabály semmit sem tilt (Google Search Central). 2026 augusztusában az egyik oldal robots.txt-jének egy részletéből az következett, hogy blokkolja a Google-t. A parser megmutatta, hogy a Googlebotnak teljes hozzáférése van, a Bing és az AI-asszisztensek robotjai viszont blokkolva voltak. A diagnózis tehát más volt: a probléma a Binget és az AI-robotokat érintette, nem a Google-t.

A robots.txt hiánya nem blokkolja a Google-t, de minden bevezetés után ellenőrzöm, hogy a fájl nem tűnt-e el. A Google a robots.txt 4xx hibáját (a 429 kivételével) úgy kezeli, mintha a fájl nem létezne, vagyis korlátozás nélkül (Google Search Central). Az én oldalam 2026 augusztusában 404-es hibát adott a robots.txt-re, mielőtt kijavítottam.

Lépés 3. Adatok több forrásból, és amit egyik-másik nem lát

A crawler minden száma hipotézis, amíg egy második forrás nem erősíti meg. Összegyűjtöm a crawlt JavaScript-futtatással és anélkül, valamint a valódi felhasználók sebességadatait a CrUX-jelentésből. Ehhez hozzáveszem a linkprofilt és a fontos kulcsszavak Google-találatait a mérés napjáról. A linképítésről szóló szövegben leírtam, hogyan ellenőrzöm a linkprofilt a kampányterv előtt. Minden fájlnál feljegyzem a forrást, a dátumot és a terjedelmet, hogy egy hónap múlva is vissza lehessen állítani minden számot.

A Search Console adatait API-n át töltöm le, vagyis az adatok automatikus lekérésére szolgáló felületen, mert a panelből való exportálás 1 000 sornál levágja a listát. Az API naponta legfeljebb 50 000 sort ad vissza minden találattípusra, például külön az oldalak, a képek és a videók találataira (Google, Search Console súgó). Az AI-eszközökről a SEO-ban szóló szövegben megmutattam, hogyan növelte meg a csonkolt export a CTR-t egy oldalon.

A crawler alábecsülheti az oldal méretét, ezért az oldalak és termékek számát egy második forrásban ellenőrzöm. Két webáruházban a crawler eljutott a termékek kategóriabeli listájának első oldaláig, és tovább nem ment, pedig a lista további oldalai működtek, és nem voltak blokkolva. Az egyik áruházban a termékek kevesebb mint felét találta meg, a másikban kevesebb mint egyharmadát. Ha ezeket a számokat az áruházak állapotaként adtam volna meg, az audit olyan hiányokat írt volna le a kínálatban, amelyek nem léteztek.

A napi adatok hirtelen változásait leírom, mielőtt okot rendelnék hozzájuk. Ezt a kattintásokra, megjelenésekre, pozíciókra, munkamenetekre és a Google robotjának lekéréseire csinálom. Olyan napokat keresek, amelyektől kezdve a hét egymást követő nap mediánja legalább 25%-kal eltér az előttük álló tizennégy nap mediánjától. Minden ilyen dátumnál feljegyzem a magyarázatot: bevezetés, Google-frissítés, üzemzavar, mérésváltozás vagy „ismeretlen ok”. A dátumok leírása hipotéziseket ad, az okot csak más lehetséges magyarázatok ellenőrzése után nevezem meg.

Lépés 4. Kulcsszavak és Google-találatok a technika előtt

Először lehetőségeket keresek, utána javítom a hibákat. A technikai problémák egy részét csak a kulcsszavak hátterében lehet megítélni: indexelődjön-e egy webáruház szűrője, érdemel-e a címke külön oldalt, versenyez-e valóban két oldal ugyanazért. A katalógusban 32 problématípuson szerepel a jelölés, hogy a kulcsszavak és a Google-találatok elemzése nélkül nem ítélhetők meg.

Az oldal hiánya egy fontos kulcsszóra az auditjaim egyik gyakoribb problémája: a 63 auditból 15-ben, az 50 oldalból 14-ben. A crawler ezt magától nem jelzi, mert csak a létező oldalakat tölti le. Akkor látszik, ha összevetem a keresletet a címek listájával, és azzal, hogy a versenytársak mely oldalai jelennek meg a találatokban.

Lépés 5. Átnézés a prioritási feltételekkel ellátott katalógus szerint

Ugyanannak a hibának magas vagy alacsony a prioritása attól függően, hol fordul elő. Az olyan címre mutató belső link, amely átirányít, egy ezernyi oldalon ismétlődő sablonban magas prioritású. Ugyanez a link egyetlen bejegyzés szövegében közepes, az archív bejegyzésekben alacsony.

A katalógusban minden problématípusnak van észlelési szabálya, bejelentési feltétele, szükséges bizonyítéka, feltételes prioritása és a bevezetés utáni ellenőrzés módja. A 256 típusból 86-nál a prioritási szabály „magas” értékkel kezdődik, de szinte mindig feltétellel: ha a kulcsszónak van kereslete, ha az oldalnak van forgalma, ha a hiba a sablonban van.

Ezért az eszköz egészségi pontszáma nem határozza meg a prioritásokat. Az eszköz hibákat számol, nem a tőlük függő forgalmat. Az ismeretlen forgalmú oldalakra vonatkozó ajánlás nem kap magas prioritást, amíg meg nem nézem az adatokat.

Lépés 6. Bizonyíték minden tételnél

A bizonyíték nélküli tétel az auditban „ellenőrzendő” marad, nem ajánlás. Bizonyíték lehet a kód egy részletének képernyőképe, vagy a szerver HTML-je a JavaScript lefuttatása utáni változat mellett. Lehet egy Search Console-diagram, vagy egy sebességmérés annak az elemnek a nevével, amely rontja. Az elemet, amely rontja a betöltést vagy eltolja az oldal elrendezését, úgy nevezem meg, ahogyan a mérés mutatja, nem úgy, ahogy a hipotézisemhez illik.

Minden tételt négy részben írok le, a problémától a javítás ellenőrzéséig. Leírom, miben áll a probléma, miért árt és mire hat, hogyan kell lépésről lépésre kijavítani, és hogyan fogjuk ellenőrizni, hogy a javítás működött. A javítandó kódot szó szerint az oldalról másolom, hogy a programozó pontosan lássa azt a helyet, amelyet módosítania kell.

Így néz ki röviden egy bejelentés az átirányított címre mutató linkekről:

• Probléma: a menü linkjei olyan, perjel nélküli címekre mutatnak, amelyek a perjeles változatra irányítanak át.
• Miért árt: a menü minden oldalon ott van, ezért minden kattintás és minden robotletöltés egy további átirányításon megy át. Az eszközök jelentéseiben az ilyen linkek ezrei megnehezítik a fontosabb hibák megtalálását.
• Javítás: a menüsablonban a címeket a célcímekre cserélni, a változtatás előtti és utáni kódrészlettel.
• Ellenőrzés: a bevezetés után a crawl nem mutat a sablonban átirányított címre mutató linkeket.

Lépés 7. Sorrend, munkaráfordítás és változatok

Az audit eredménye a sorrend, nem a megállapítások száma. A dokumentum elején áll az összes tétel táblázata prioritással és munkaráfordítással. A ráfordítást négy kategóriában írom le: néhány óra, egy-két nap, egy hét vagy egy egész projekt. A kisebb lehetőségekkel rendelkező csapat a teljes változat mellett minimális változatot is kap, világos leírással arról, mit veszít a rövidebb úttal.

A bevezetés pontosan az audit szerint történik. Ha a bevezetés árazásakor olcsóbb változat merül fel, azt az ügyfél választja, és ezt kifejezetten feljegyzem, nem cserélem le az ajánlást az ő tudta nélkül.

Lépés 8. Keresztellenőrzés és ellenőrzés a bevezetés után

Mielőtt az audit az ügyfélhez kerül, megnézi valaki, aki nem maga írta. Két kört végzek: az elsőt a teljes dokumentumon, a másodikat csak azon, ami az első után változott. Az ellenőrzés nulláról újraszámolja a számokat, és olyan téziseket keres, amelyeket bizonyítékkal nem lehet megvédeni. A végén magam ellenőrzöm a prioritásokat és a téziseket, amelyek az ügyfél helyzetétől függnek.

A bevezetés után minden tételt a működő oldalon ellenőrzök, és megjelölöm: helyesen bevezetett, részben bevezetett vagy be nem vezetett. Ez az ellenőrzés az audit árában van. E lépés nélkül az audit a dokumentumnál ér véget, nem az oldal változásánál.

Mit ellenőrzök a technikai SEO auditban?

A technikai auditban több mint tíz területen megyek végig, a problémákat pedig leggyakrabban az átirányításokban, az oldal felépítésében és a tartalomban jelentem. Az utolsó oszlop azt mutatja, hogy az archívum 63 auditjából hányban jelentett a szerző legalább egy problémát az adott területről. A „Mit ellenőrzök” oszlop példákat ad, nem a terület teljes körét. A táblázat kiválasztott területeket mutat, a katalógus a problémákat 22 területre osztja.

A ritkán jelentett probléma nem feltétlenül fordul elő ritkán. A sebességnek és a JavaScriptnek kevés bejelentése van ebben a táblázatban, de az archívum auditjainak más volt a terjedelmük. Az alacsony bejelentésszám tehát nem mondja meg, milyen gyakoriak ezek a problémák az oldalakon.

Hogyan ellenőrzöm az oldal indexelését?

Az indexelést három listán ellenőrzöm: mi van az oldaltérképben, mit indexelt a Google, és mit talál a crawler a linkeken át. A három lista közötti eltérés jobban megmutatja a problémát, mint bármelyik külön. Az olyan címekkel rendelkező oldaltérképet, amelyek átirányítást vagy hibát adnak, vagy ki vannak zárva az indexből, a 63 auditból 20-ban jelentették, az 50 oldalból 18-nál. Az egyes címekre a Search Console címvizsgálatát használom, amely a JavaScript lefuttatása utáni oldalt is megmutatja.

Befolyásolják a Core Web Vitals a pozíciókat?

A Core Web Vitals a Google rangsorolási rendszereinek része, de nem írja felül a tartalom relevanciáját. A Google egyenesen azt írja, hogy a rangsorolási rendszerek használják a Core Web Vitalst. Azt is írja, hogy mindig a legrelevánsabb tartalmat próbálja megmutatni, gyenge oldalélmény mellett is (Google Search Central). Az auditban a valódi felhasználók adatait használom a CrUX-jelentésből, nem egyetlen laboreszközben végzett tesztet. Ahol a Google rendelkezik ilyen adatokkal az egyes oldaltípusokra, külön megadom. Az adatok hiányát leírom az auditban. 2024. március 12-től a reakciókészség mércéje az INP, amely az FID helyébe lépett (web.dev).

Milyen hibákat találok leggyakrabban a SEO auditokban?

Leggyakrabban rendezési hibák ismétlődnek, vagyis olyanok, amelyeket az eszközök könnyen észlelnek: átirányított és 404-es címekre mutató linkek, helytelen címeket tartalmazó oldaltérképek, valamint duplikált oldalcímek és leírások. Az átirányított címekre mutató belső linkek a 63 auditból 24-ben jelentek meg, az 50 oldalból 20-nál. Az eszközök jól észlelik őket, a javítás költsége a sablontól és az oldal rendszerétől függ.

A ritkábban jelentett szerkezeti problémák nagyobb hatással lehetnek a forgalomra, mint a rendezési hibák. A fontos kulcsszavakra szóló oldalak hiányát a 63 auditból 15-ben jelentették, és ugyanennyiszer azt a blogot, amely nem linkel az ajánlat és a kategóriák oldalaira. A katalógus a hiányzó oldalnak magas prioritást ad, ha a kulcsszónak van kereslete, és a versenytársak külön oldalakkal foglalják el a pozíciókat. A link nélküli blog magas prioritást kap, ha a céloldalaknak van forgalmuk vagy bevételük, a blognak pedig tekintélye. Ezeket a feltételeket adatokon ellenőrzöm, mielőtt prioritást adok.

• 938megállapítás 63 auditban 50 oldalon, amelyekből 256 problématípusból álló katalógust építettemAuditarchívum 2020-2026, katalógus 2026. október 11-éről
• 38%az átirányított címekre mutató belső linkeket tartalmazó auditok aránya, az archívum leggyakrabban jelentett problémája (24 a 63-ból)Katalógus 2026. október 11-éről
• 15 a 63-bólaudit, amelyben hiányoznak a fontos kulcsszavakra szóló oldalak, amit a crawler magától nem jelezKatalógus 2026. október 11-éről
• 14ajánlástípus, amelyet a katalógus ma elavultnak jelöl, további 30-at pedig megváltozott gyakorlatnakKatalógus 2026. október 11-éről

Mi változott a SEO auditokban 2020 óta?

A 2023-2026 közötti auditokban a strukturált adatok és a lapozás gyakrabban jelennek meg, mint a 2020-2022 közöttiekben, az átirányítások, a kanonikus címek és az indexelés pedig ritkábban. A strukturált adatokkal kapcsolatos problémákat a 33 újabb auditból 23-ban jelentették, a 30 régebbiből 16-ban. Átirányítások és válaszkódok: 23 a 33-ból, szemben 27-tel a 30-ból. Az AI-robotok blokkolása csak a 2026-os auditokban jelenik meg. Az audit éve az archívumban lévő fájl dátuma, tehát nem mindig a munka elvégzésének éve.

A csökkenés nem bizonyítja, hogy az átirányítási problémák eltűntek. Megváltozott az auditok összetétele: az újabbak gyakrabban foglalkoztak strukturált adatokkal, tartalommal és az AI-beli láthatósággal, és a munka módja is megváltozott. Ebből a grafikonból az látszik, mivel foglalkoztak az auditok, nem az, hogyan változtak az oldalak Lengyelországban.

Mely SEO-ajánlások elavultak ma?

Egyes ajánlások még mindig megjelennek az auditokban és az útmutatókban, bár ma nem érdemes bevezetni őket. Egy részük néhány éve még működött, egy részüket a Google régóta ellenezte vagy figyelmen kívül hagyta. A táblázatban minden gyakorlatnál megadom az okot és azt, mit tegyünk helyette.

A táblázat forrásai: Google a lapozásról, Google a rel=canonical öt hibájáról, Google a FAQ- és HowTo-találatokról, Matt Cutts a nofollowról és a linkerő elosztásáról, John Mueller a főoldalra irányuló átirányításokról, a Search Engine Roundtable nyomán, Google a robots.txt-ről, Google a robots.txt nem támogatott szabályairól, Google az oldaltérképekről, Google a lastmod, changefreq és priority mezőkről, web.dev az INP-ről, Google a találatokban megjelenő keresőmezőről.

Ezért a katalógusomban minden ajánlásnak van indoklással ellátott aktualitásmezője. A katalógus ma 14 ajánlástípust jelöl elavultnak, és 30-at megváltozott gyakorlatnak. Az az ajánlás, amely néhány éve helyes volt, nem kerül be az auditba csak azért, mert valaha működött.

Hogyan ellenőrizzem az AI-robotok hozzáférését az auditban?

Az AI-robotok hozzáférését ugyanabban a lépésben ellenőrzöm, mint a Googlebotét, mert ugyanaz a tűzfal- vagy CDN-beállítás blokkolhatja őket. A CDN közvetítő szerverek hálózata, például a Cloudflare. 2026 szeptemberében megvizsgáltam az ügyfeleim 12 domainjét, amelyek a Cloudflare mögött működnek. Maga a robots.txt fájl ezt mutatta:

• 3 domain ugyanazt a hét, modellek tanítására adatot gyűjtő robotból álló készletet blokkolta, azonos névlistával. Az azonos lista közös forrásra utal, például egy kész beállításra a Cloudflare panelben. Kívülről ez a beállítás nem látszik, ezért magában a panelben kell megerősíteni.
• 1 domain blokkolta azokat a robotokat, amelyek a ChatGPT, a Perplexity és a Claude válaszaihoz töltenek le oldalakat. Nem kifejezetten tette, hanem egy általános szabállyal minden névvel nem említett robotra. Ugyanez a domain a GPTBotnak noindex jelölés nélküli biztonsági oldalt mutatott, amely az oldalt kizárja az indexből. Ha egy ilyen oldalt az indexelő robot kapott volna, a tartalom helyett a blokád oldala kerülhetett volna az indexbe.
• 8 domainnek nem volt blokádja a robots.txt-ben.

A robotokról, amelyek a válaszokhoz töltenek le oldalakat, és azokról, amelyek a tanításhoz gyűjtenek adatot, külön dönt. Az AI SEO-ról és a GEO-ról szóló szövegben leírtam, hogyan lehet őket megkülönböztetni. 2026. augusztus 31-től a Search Console-ban külön beállítás is van, amely kizárja az oldalt az AI Overview-ból, az AI Módból és a Discover generatív funkcióiból. A Google szerint a keresési eredmények többi részére nincs hatással (Search Console súgó). Az ilyen beállítást az auditban ugyanúgy ellenőrzöm, mint a robots.txt-t, mert valaki bekapcsolhatta a SEO-ért felelős személy tudta nélkül. Hogy a hozzáférés megnyitása után megjelenik-e a márka a válaszokban, az már külön mérés, amelyet a márka AI-beli láthatóságáról szóló szövegben írtam le.

Egyetlen IP-címről végzett teszt a helyzetnek csak egy részét mutatja, és maga is adhat téves riasztást. Ugyanebben az áttekintésben egy lekérdezéssorozat két domainen blokádot jelzett a limit átlépése után. Ezt a blokádot a saját korábbi lekérdezéseim váltották ki. Néhány perccel későbbi ellenőrzés, egyetlen robotazonosítóval és egyedi lekérdezésekkel, öt és hét helyes választ adott egymás után. Ha ez az ellenőrzés nincs, két ügyfél olyan blokádról kapott volna információt, amely nem létezett. Csak a szerverlogok mutatják meg, hogy a ChatGPT valóban letölti-e az oldalt. Az llms.txt fájlról szóló szövegben megmutatom, mi látszik az oldalam logjaiban.

A 200-as kód nem azt jelenti, hogy a robot megkapta a tartalmat. Az egyik JavaScript-alkalmazással rendelkező ügyfélnél a Googlebot és a Bingbot kész HTML-t kapott egy prerender-szolgáltatástól, az AI-asszisztensek robotjai pedig üres oldalt. A szolgáltatás név alapján ismerte fel a robotokat, és az AI-robotok nem szerepeltek a listáján. A tesztem „rendben” eredményt adott, mert a válaszkódot mérte, nem a tartalmat. Azóta összehasonlítom a robot által kapott tartalmat a böngészőben, a JavaScript lefuttatása után kapott tartalommal.

Elég egy ingyenes SEO audit?

Az ingyenes eszköz megmutatja a hibák listáját, de a jelentésből önmagában nem következik, melyik kerül Önnek forgalomba. A lengyel Google-ben az „audyt seo” kulcsszóra az első oldal 9 organikus találatából 7 eszköz vagy ingyenes audit ajánlata (a találatok 2026. október 17-éről). Egy ilyen jelentés az eszköz szabályai szerint számol hibákat, nem aszerint, mennyi forgalom és bevétel függ tőlük. Azt is ellenőrizni kell, hogy az eredmény nem robotblokádból származik-e, mint a 0 egészségi pontszámú webáruház esetében.

Sokat tehet ingyen, ha tudja, hol nézzen. A Search Console megmutatja a Google adatait az indexelésről, a Core Web Vitalsról és az oldalt a JavaScript lefuttatása után. A Screaming Frog ingyenes változata egy crawlban legfeljebb 500 címet jár be (Screaming Frog), ami egy kis céges oldalra elég. A tanácsadóval készített audit akkor van értelme, ha a hiba sokba kerül (migráció, forgalomesés, nagy webáruház), vagy ha nincs ideje összevetni és értékelni az adatokat.

Megcsinálja a ChatGPT a SEO auditot?

A ChatGPT vagy más AI-modell nem végez el egyedül teljes auditot, mert nem úgy látja az oldalt, mint a kereső robotja. Általában egy eszközön át látja, amely letölti és szöveggé alakítja. A modell elolvassa az Ön által adott adatokat, és javasol, mit érdemes ellenőrizni. A letöltő eszköz viszont elveszítheti az oldal egy részét: 2026 szeptemberében megállapítottam, hogy a Claude Code oldalletöltő eszköze a szöveggé alakításkor kivágja a strukturált adatokat. A modell azt válaszolta, hogy nincs ilyen információ, pedig ugyanazon az oldalon egy jelölésben ott volt. Az így készített audit olyan strukturált adatok hiányát jelentené, amelyek nem hiányoznak. A folyamatomban az AI eszköz, elsősorban a crawlból, a Search Console-ból és más forrásokból származó adatok összesítésére. A terjedelmet, az értékelést és a prioritásokat magam határozom meg.

Mennyibe kerül a SEO audit?

Az auditot úgy számolom el, mint a tanácsadást: 70 EUR nettó óradíjjal, a munkaórák felső határával, amelyet az indulás előtt rögzítek. Az órák száma attól függ, mit kell ellenőrizni:

• a diagnosztikai audit, vagyis egy-két konkrét probléma (forgalomesés, migráció, indexelés), általában 10-16 óra, vagyis 700-1 120 EUR nettó;
• a teljes audit teendők sorrendjével általában 32-50 óra, vagyis 2 240-3 500 EUR nettó;
• a legfeljebb 500 címes kis oldal az alsó határhoz áll közelebb, az ezernyi címes, szűrős webáruház a felsőhöz;
• a nyelvi változatok általában 3-5 órát adnak hozzá, a folyamatban lévő válság, amelyet diagnosztizálni kell, 4-8 órát.

Az árban benne van az elemzés, a javaslatokat tartalmazó jelentés, a megbeszélés, amelyen átbeszéljük, és az ellenőrzés a bevezetés után. Magát a bevezetést az Ön csapata végzi, vagy külön árazom.

A Search Console-hoz, a CDN-panelhez és a tárhelyhez való hozzáférés nélkül a technikai részt nem tudom teljesen ellenőrizni, és ezt az árajánlat előtt megmondom. Ilyenkor megjelölöm, mit nem tudok e hozzáférések nélkül ellenőrizni, és ennek megfelelően szűkítem a terjedelmet. A SEO tanácsadásról szóló szövegben leírtam, mikor elég az audit helyett egy beszélgetés egyetlen döntésről.

Gyakori kérdések a SEO auditról

Hol kezdje?

Kezdje egyetlen kérdéssel: az oldal veszít-e forgalmat, vagy nem építi. A válaszon múlik, hogy előbb azokat az oldalakat védi-e, amelyeknek van pozíciójuk, vagy olyan kulcsszavakat keres, amelyekre hiányoznak az oldalak. Aztán végezze el a három ingyenes ellenőrzést a saját auditról szóló válaszból: robots.txt, indexelési jelentés a Search Console-ban és crawl a Screaming Frog ingyenes változatával. Ha az eredmény meglepi, vagy nem tudja, mit javítson előbb, az jó téma tanácsadásra.