Miért technikai SEO audittal kezdünk minden marketinget?

Azért kezdünk minden marketing-munkát technikai SEO audittal, mert a marketing forgalmat terel egy weboldalra, és ha az oldal technikailag hibás, a befektetett pénz egy része eleve elfolyik. Ha a Google nem indexeli a fontos oldalakat, ha mobilon lassú a betöltés, vagy ha az AI-keresők robotjai ki vannak zárva, akkor se a hirdetés, se a tartalom nem hozza azt, amit hozhatna. Az audit megmutatja, mi blokkolja a növekedést, és sorrendet ad: mit kell rendbe tenni, mielőtt a forgalomra költünk.

Kampányt bármikor el lehet indítani, de ha két hónap múlva derül ki, hogy a céloldalak egy része nincs a Google indexében, az addigi mérések is félrevisznek. Az AI-keresés ezen csak élesített. A Google hivatalos útmutatója szerint az AI-összefoglalóban és az AI Módban csak olyan oldal lehet forrás, amely indexelve van, és részlettel (snippettel) megjeleníthető a keresőben. Külön technikai követelmény nincs, aki tehát az alapokon elcsúszik, az AI-válaszokból is kimarad.

Miért nem a kampánnyal kezdünk?

Mert a marketing szorzó, nem alap: azt sokszorozza meg, ami az oldalon van, a hibákat is. Három okból ragaszkodunk ehhez a sorrendhez:

• Láthatóság: ami nincs indexelve, az nem tud rangsorolni, és a Google AI-funkcióiban sem lehet forrás.
• Mérés: ha nem tudjuk, honnan indulunk, azt sem tudjuk megmondani, mit ért a kampány. A Google szerint az AI-összefoglalókból és az AI Módból érkező forgalom a Search Console teljesítményjelentésében, a „Web” keresési típuson belül jelenik meg, nem külön. Ezért az audit egyben kiinduló pillanatkép is.
• Fizetett forgalom: a hirdetésből érkező látogató is a céloldalra jut. Ha az lassú vagy mobilon szétesik, ott ugyanúgy veszítesz, csak minden kattintásért fizetsz.

Az elvi hátteret egy korábbi cikkben írtuk le, a gyakorlatban nálunk ez hat lépés.

Hogyan néz ki nálunk egy technikai audit, lépésről lépésre?

1. Célok és hozzáférések

Nem crawlerrel kezdünk, hanem egy kérdéssel: melyik 10–20 oldal hozza a pénzt? Hozzáférést kérünk a Search Console-hoz és az analitikához, mert egy külső eszköz csak a kívülről látható képet adja, a Search Console viszont a Google saját adatait.

2. Feltérképezés

Crawlerrel járjuk be az oldalt, ahogy egy keresőrobot. Ezeket nézzük:

• státuszkódok: 404-es oldalak, 5xx szerverhibák, átirányítási láncok;
• canonical címkék: önmagukra mutatnak-e, és nem mutatnak-e átirányított vagy hibás URL-re;
• noindex és robots.txt: nincs-e véletlenül kizárva fontos oldal;
• belső linkek: elérhető-e minden fontos oldal néhány kattintásból, és van-e árva oldal, amelyre semmi nem mutat;
• sitemap: csak élő, indexelendő URL-ek vannak-e benne.

A canonicalnál érdemes tudni, hogy a Google dokumentációja szerint az átirányítás és a rel="canonical" erős jel, a sitemapbe tétel viszont csak gyenge. Ha ezek ellentmondanak egymásnak, nem biztos, hogy a te választásod nyer.

3. Indexelés: mit lát belőle a Google?

A crawl azt mutatja meg, mit lehetne indexelni, a Search Console pedig azt, mi lett belőle. Az Oldalindexelés jelentésben azt nézzük, hogy a fontos oldalak bent vannak-e, és ha nem, miért. A Google is leírja, hogy a legtöbb webhelynek van néhány nem indexelt oldala, a duplikált URL-eknek pedig nem is kell indexben lenniük. A kérdés az, hogy a pénzt hozó oldalak bent vannak-e. Egy-egy konkrét oldal állapotát az URL-ellenőrző eszközzel nézzük meg.

4. Renderelés és sebesség

Ha az oldal JavaScript-keretrendszerrel készült, összevetjük, mi van a nyers HTML-ben, és mi jelenik meg csak renderelés után. A Google JavaScript SEO-útmutatója szerint a Googlebot három fázisban dolgozik (feltérképezés, renderelés, indexelés), az úgynevezett app shell modellnél pedig a kezdő HTML nem tartalmazza a tényleges tartalmat. Ilyenkor a Google-nek le kell futtatnia a JavaScriptet, hogy lássa a tartalmat.

Sebességnél a Core Web Vitals mutatókat a web.dev küszöbértékeihez mérjük: az LCP legfeljebb 2,5 másodperc, az INP legfeljebb 200 milliszekundum, a CLS legfeljebb 0,1 legyen. A javaslat az, hogy ezeket az oldalbetöltések 75. percentilisén nézd, mobilra és asztalira külön. Ezért valós felhasználói adatot nézünk, ha van, nem csak laborpontszámot.

5. AI-elérhetőség

Itt elsősorban a robots.txt-t és a szerveroldali tiltásokat nézzük. Az OpenAI crawler-dokumentációja szerint az OAI-SearchBot felel azért, hogy egy oldal megjelenjen a ChatGPT keresésében. Ha kizárod, az oldalad nem kerül be a ChatGPT keresési válaszaiba (navigációs linkként még felbukkanhat). A GPTBot ettől független beállítás, vagyis engedheted a keresést, és közben tilthatod, hogy a tartalmadat modelltanításra használják:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

Ez példa, nem ajánlás: a GPTBot engedélyezése üzleti döntés. Előfordul viszont, hogy egy tűzfal- vagy CDN-szabály minden AI-robotot egyben kizár, és erről senki nem tud. Az llms.txt-t is megnézzük, de nem ezzel kezdünk.

6. Priorizált javítási lista

Az audit kimenete nálunk nem egy vaskos PDF, hanem egy rövid lista, amelyben minden tételhez három kérdésre válaszolunk:

Szempont	Kérdés
Hatás	Hány pénzt hozó oldalt érint, és mennyire?
Ráfordítás	Beállítás egy adminfelületen, vagy fejlesztői munka?
Felelős	Ki javítja: mi, a te fejlesztőd, vagy a platform szolgáltatója?

Elöl a nagy hatású, kis ráfordítású tételek állnak. Egy rossz robots.txt-sor javítása percek kérdése, egy renderelési probléma viszont hetekig tartó fejlesztés lehet.

Milyen hibákat találunk a leggyakrabban?

Az alábbi példák anonimizáltak és összevontak: nem egy-egy ügyfél adatai, hanem több auditban visszaköszönő helyzetek, ezért számokat sem írunk melléjük.

A webshop, ahol a szűrők több URL-t gyártanak, mint ahány termék van

Szín, méret, ár, rendezés: minden kombináció új URL. A Google 2024-es összefoglalója szerint a szűrős navigáció URL-jeinek feltérképezése mindig szervererőforrást visz el, és lassíthatja az új tartalom felfedezését. A javítás itt döntés arról, melyik kombináció érdemel saját, indexelhető oldalt (például egy ténylegesen keresett „fekete női futócipő”), és melyik maradjon ki a feltérképezésből. Ehhez a webshop-motort is ismerni kell.

A céges oldal, ahol a robots.txt és a noindex kioltja egymást

Néhány régi oldalt a robots.txt-ben tiltottak le, és a biztonság kedvéért noindexet is kaptak. Az oldalak ettől még a találatok között maradtak. A Google dokumentációja szerint a noindex csak akkor működik, ha a robots.txt nem blokkolja az oldalt, különben a robot sosem látja a címkét. A robots.txt ugyanis a Google szerint nem arra való, hogy egy oldalt kizárj a keresőből.

A modern oldal, amelynek első HTML-je üres

Kliensoldali renderelés: böngészőben minden rendben, de a nyers HTML-ben a menün kívül alig van szöveg. A Google renderelés után látja a tartalmat, de ez plusz lépés, más robotoknál pedig nem építenénk arra, hogy lefuttatják a JavaScriptet. A javítás fejlesztés: szerveroldali renderelés vagy előrenderelés. Egyedi rendszernél ez a fejlesztői csapatunk asztala.

Az átköltöztetés, ahol a régi URL-ek a semmibe vezetnek

Új platform, új URL-szerkezet, a régi címekről pedig nincs átirányítás. A külső linkek és a könyvjelzők 404-re futnak. Mivel a Google az átirányítást a legerősebb kanonikus jelek közé sorolja, a 301-es átirányítási térkép nálunk minden relaunch kötelező része.

Mi történik az audit után?

A javítási lista mellett rögzítjük a kiinduló értékeket: a fontos oldalak indexelési állapotát, az organikus forgalmat a Search Console-ban, a Core Web Vitals adatokat, és ahol releváns, azt, hogy a fő kérdésekre kit idéz az AI-összefoglaló. Erről a mérésről itt írtunk részletesen.

A marketing csak ezután indul, és a sorrendje az audit eredményéhez igazodik. Ha a kategóriaoldalak nincsenek indexben, nem blogcikkekkel kezdünk. Ha a céloldal mobilon lassú, előbb azt javítjuk, és csak utána skálázzuk a hirdetést. Ha minden rendben van (ilyen is előfordul), az audit egy rövid dokumentum.

Ezért szeretjük, ha a fejlesztés és a marketing egy kézben van: így a fenti szempontok már a tervezésnél bekerülnek. A G8 Alakváltók appja, webshopja és weboldala is nálunk készült.

Mikor nem kell teljes audit?

Néhány tucat oldalas webhelynél nem kell nagy audit. A Google Search Console-súgója kifejezetten azt írja, hogy 500 oldal alatt valószínűleg nincs szükséged az indexelési jelentésre, elég néhány kereséssel ellenőrizni, hogy a fontos oldalak megtalálhatók-e. Ilyenkor rövidített ellenőrzést végzünk: indexelés, robots.txt, mobilsebesség, AI-robotok. Egy több ezer termékes webshopnál vagy egy relaunch előtt viszont végigmegyünk a teljes folyamaton.

Gyakori kérdések

Garantálja a technikai audit a jobb helyezést?

Nem. Az audit akadályokat tár fel és szüntet meg, a helyezés viszont a tartalmon, a versenytársakon és a keresőn is múlik. Amit ad: tudni fogod, mi akadályozza a láthatóságot, és mit érdemes először javítani.

Kell külön audit az AI-keresők miatt?

Külön nem, bővített igen. A Google szerint az AI-összefoglalókhoz nincs a klasszikus SEO-n túli technikai követelmény. A ChatGPT keresésénél viszont számít, hogy a robots.txt és a szerver engedi-e az OAI-SearchBotot, ezért az auditunk ezt is ellenőrzi.

Mi kell tőled az audithoz?

Search Console-hozzáférés (olvasási jog is elég), analitika, ha van, a platform neve és az, hogy ki fejleszti az oldalt. A legfontosabb pedig egy lista arról, mely oldalak hozzák a bevételt.

Milyen gyakran érdemes megismételni?

Minden nagyobb változás után: relaunch, platformváltás, új nyelvi verzió vagy nagy termékimport. Közben a Search Console rendszeres figyelése többet ér egy évi egyszeri nagy auditnál.

Ha kíváncsi vagy, hol tart most az oldalad, kérj tőlünk ingyenes SEO- és AI-láthatósági auditot. Ha utána a marketinget is együtt vinnénk, a részleteket a marketing-szolgáltatásunk oldalán találod.