Technikai SEO audit nagy és összetett weboldalakhoz

A technikai SEO audit megközelítésem egyetlen szabállyal indul: ne a tüneteket kezeld gyökérokokként. A weboldalon több ezer kizárt oldal is lehet a Search Console-ban, de a valódi probléma valahol máshol van: belső linkelésben, sablonok duplikációjában, megjelenítésben (renderelésben) vagy a feltérképezési források (crawl allocation) elosztásában az alacsony értékű útvonalak felé. Ezért a standard audit eszközöket egyedi adatkivonással és Python SEO automatizálással kombinálom, ahelyett hogy egyetlen crawler exportjára és egy ellenőrzőlistára hagyatkoznék. A cél nem egy hosszú dokumentum előállítása; a cél egy döntéstámogató rendszer létrehozása, amely megmutatja, mit érdemes először javítani, és azt is, hogy miért. A munka során a üzletileg kritikus oldalcsoportokból indulok ki: kategóriasablonok, termékoldali részletező oldalak, szerkesztőségi hubok, szűrők, találati (search result) oldalak és nemzetközi verziók. Vállalati (enterprise) oldalak esetén minden javaslatnak tesztelhetőnek, skálázhatónak és elég egyértelműnek kell lennie ahhoz, hogy az engineering, a product és a SEO szereplői egyetértsenek a megvalósításban. A díszítő jellegű audit és a valóban hasznos közti különbség az, hogy az eredmények megállják-e a helyüket a valós platformokkal, a release ciklusokkal és a backlog korlátokkal való találkozás során.

A gyakorlatban az audit több adatréteget kombinál: Screaming Frog vagy egy egyéni crawler a struktúrához, a Google Search Console API az indexelési és lekérdezési adatokhoz, a szervernaplók a botok viselkedéséhez, a Chrome UX adatok a teljesítményhez, valamint célzott kézi ellenőrzés a megjelenített HTML és a sablonlogika vizsgálatához. Gyakran URL-szintű adathalmazokat is belekotrok Pythonba vagy táblázatokba, hogy az issue-okat sablon, alkönyvtár, paramétertípus, nyelv vagy status-code mintázat szerint csoportosítsam. Ez azért fontos, mert egy 200 termékoldalt érintő probléma nem kezelhető ugyanúgy, mint egy 4.2M fasettált URL-t érintő mintázat. Emellett a crawl kimenetét összevetem az indexelési és a forgalmi adatokkal, hogy azonosítsam a false pozitívokat: egyes technikailag tökéletlen URL-eknek nincs valódi üzleti költségük, míg mások csendben elnyomják a legnagyobb értékű oldalait. Azoknál az ügyfeleknél, akiknek folyamatos rálátásra van szükségük a javításokra, az eredmények közvetlenül betáplálhatók SEO riportálás és analitika irányítópultokba, így az előrehaladás issue-kategóriánként mérhető, nem elszigetelt képernyőképek alapján. Ez az adatszerkezet különösen akkor hasznos, ha több csapat felel a technológiai stack különböző részeiért. Az audit így működő ütemtervvé válik, nem pedig egy egyszeri PDF-dokumentummá.

Az AI a munkafolyamat része, de nem ott használom, ahol a pontosság elcsúszhat. Claude és GPT modelleket használok a klaszterezés, címkézés, dokumentációs vázlatok, regex javaslatok és a szélső esetek (edge-case) átvizsgálásának felgyorsításához, különösen ha hatalmas URL-készletekkel vagy ismétlődő sablonproblémákkal dolgozom. Ez a munkafolyamat egy olyan, kontrollált folyamat részeként fut, amely hasonlít a AI & LLM SEO workflows megközelítésemhez: minden olyan kimenet, amelyet modell segített, a feltérképezési (crawl) adatok, a forráskód vagy a logok alapján kerül ellenőrzésre, mielőtt ajánlássá válna. Például az AI segíthet 50 000 duplikált title-minta összefoglalásában, vagy javasolhat kategóriákat a paraméter-zajhoz, de nem dönti el, hogy egy canonical implementáció technikailag helyes-e. A legnagyobb emberi szerep akkor fontos, amikor a jelzések ütköznek, például ha a renderelt canonicals eltér a nyers HTML-től, vagy ha a Search Console riportjai lemaradnak a post-fix feltérképezési viselkedéshez képest. Ha helyesen alkalmazzák, az AI akár 80%-kal is csökkenti a manuális munkát az ismétlődő elemzési és dokumentációs feladatok során. Ezt az időmegtakarítást pedig olyan részekre fordítom, amelyek ténylegesen változtatják az eredményeket: architektúra-döntésekre, priorizálásra és az implementáció minőségének ellenőrzésére. Így gyorsabb az átfutási idő úgy, hogy az audit nem válik általános másolattá.

A skálázás megváltoztatja az audit kialakítását. Egy 20 000 oldalas brosúraoldal gyakran már 1-2 feltérképezési körrel diagnosztizálható, de egy 5M indexelt oldallal, 20M generált URL-lel rendelkező, több ccTLD-t használó és piaconként eltérő sablonokat alkalmazó oldalon már a kezdetektől szegmentálásra van szükség. A vállalati auditokat oldal-típus taxonómiákra, nyelv–piac kombinációkra, belső link gráf mintázatokra, kanonikus klaszterekre és crawl-log szeletekre építem, hogy elkülöníthessük, hol invesztál túl sokat a Googlebot, illetve hol invesztál túl keveset. Ez a munka gyakran metszi a webhelyarchitektúra & URL-struktúra, az nemzetközi & többnyelvű SEO és az eCommerce SEO területeit is, mert a technikai hibák ritkán maradnak egyetlen SEO-kategórián belül. Többnyelvű weboldalakon a hreflang és a kanonikus hibák akár akkor is elnyomhatják a helyes piacokra célzott oldalak teljesítményét, ha a tartalom minősége erős. Nagy katalógusoknál egy rosszul kontrollált szűrőrendszer akár milliónyi, alacsony értékű URL-t is létrehozhat, amelyek eltemetik a kategória- és termékfelfedezést. Az én feladatom, hogy ezt a komplexitást olyan bevezetési (implementációs) sorrenddé csökkentsem, amelyet a csapatod ténylegesen le tud szállítani, ellenőrizni és fenntartani tud.