Van egy meetingtípus, amit minden SEO-tanácsadó átélt. Az ügyfél fejlesztője megnyit egy 900 soros táblázatot, amit egy auditeszközből exportáltak, lassan végiggörget rajta, és felteszi az egyetlen kérdést, ami számít: „Ezek közül melyik kerül nekünk ténylegesen pénzbe?" A legtöbb auditeszköz erre nem tud válaszolni. Nagyon jók abban, hogy megtalálják a hibákat, és nagyon rosszak abban, hogy rangsorolják őket.
A Semalt platform auditja pontosan e köré a kérdés köré épül, nem a teljesség köré. Ebben a cikkben végigmegyünk azon, mit vizsgál, hogyan dönti el, mi a fontos, és — ezt a részt a legtöbb útmutató kihagyja — hogyan lesz a kimenetéből olyan fejlesztői jegysorozat, amit egy leterhelt csapat tényleg végig is csinál.
A lényeg röviden
- Az audit projekthez kötött, ütemezett bejárás, így minden futás különbséglista — nem azt olvassa, mi rossz ma, hanem azt, mi romlott el a héten.
- A megállapítások ok szerint csoportosulnak, nem URL szerint: egy sablonhiba egyszer jelenik meg, 1400 érintett URL-lel.
- A javításokat üzleti hatás szerint sorrendezze, soha ne súlyossági címke szerint — a bevételt termelő oldalak indexelési hibái mindig elsők.
- Egy megállapítás nem jegy. A fejlesztőnek URL-minta, szabály, egy mondat következmény és ellenőrzési módszer kell.
Mi is valójában az audit
A Semalt auditja nem egy letölthető egyszeri riport. Egy projekthez kötött, ütemezett bejárás, így minden futás különbséglistát ad az előző állapothoz képest. Ez a különbség megváltoztatja a használat módját. Egy pillanatkép-audit arra válaszol, „mi rossz ma". Egy folyamatos crawl arra, „mi romlott el ezen a héten" — és ez az a kérdés, amely katasztrófákat előz meg.
A crawler futtatja a JavaScriptet, konfigurálható mélységig követi a belső linkeket, a beállítástól függően tiszteletben tartja vagy szándékosan figyelmen kívül hagyja a robots-direktívákat, és külső jeleket is behúz: Search Console-adatot, ha összeköti, Core Web Vitals mezőadatot, ahol elérhető, valamint élő SERP-pozíciókat a projekt kulcsszókészletére. A kimenet egyetlen hibalista, ahol minden tétel tudja, hány URL-t érint, és azok az URL-ek mennyit érnek.
Hogyan állítsunk be egy hasznos futást
Három beállításon múlik, hogy az első crawl használható adat lesz-e vagy zaj.
- Hatókör. Nagy oldalakon először reprezentatív részhalmazt járjon be. Egy 5000 URL-es, minden sablont lefedő minta ugyanazokat a sablonszintű hibákat találja meg, mint egy 400 000 URL-es bejárás, töredék idő alatt.
- Renderelés. Ha az oldal a fő tartalmat kliensoldalon építi fel, a renderelést be kell kapcsolni, különben a crawl mindenhol vékony tartalmat jelez, és Ön egy nem létező problémát fog kergetni.
- Paraméterkezelés. A szűrőnavigáció gyakorlatilag végtelen URL-t generálhat. Előre döntse el, mely paramétereket hagyja figyelmen kívül, különben a crawl-büdzsé színszűrőkre megy el.
Ezek beállítása tíz perc, és egy nap félreolvasást spórol. Ha most hozza létre az első projektjét, nyissa meg az irányítópultot, adja hozzá a domaint, és összetett oldalnál a futtatás előtt konfigurálja a bejárást ahelyett, hogy elfogadná az alapértelmezéseket.
Mindhárom szám a cikkben végigvitt példákból származik.
Indexelés: a hibák, amelyek csendben törlik az oldalakat
Következetesen ez a legértékesebb kategória. Az indexelési problémák nem fokozatosan rontják a teljesítményt — teljesen eltávolítják az oldalt a keresésből, és mivel az oldal az emberek számára továbbra is rendben betöltődik, senki nem veszi észre, amíg a forgalmi riport hónapokkal később ki nem mutatja.
Az audit jelzi a szokásos gyanúsítottakat: staging deploy után bent felejtett noindex címkék, rossz URL-re mutató canonicalok, canonical-láncok, robots.txt-ben tiltott, de a sitemapben szereplő oldalak, átirányítási hurkok, valamint soft 404-ek, ahol a „nincs találat" oldal 200-as kóddal tér vissza.
Kettő közülük külön figyelmet érdemel, mert ezekkel találkozunk a leggyakrabban valós auditokban. Az első a staging noindex: a sablon a címkével együtt kerül élesbe, a deploy folyamat nem távolítja el, és egy egész szekció csendben kisétál az indexből. A második az elrontott önhivatkozó canonical lapozott vagy szűrt oldalakon, ahol a sorozat minden oldala az első oldalra kanonizál, a kereső pedig készségesen törli a katalógus többi részét a találatok közül.
A két leggyakrabban talált hiba. A staging noindex, amely túléli a deploy folyamatot, és csendben kiveszi az indexből egy egész szekciót; valamint a lapozott vagy szűrt oldalak, amelyek mind az első oldalra kanonizálnak, ezzel törölve a katalógus többi részét a találatokból. Mindkettő tökéletesen betöltődik a látogatóknak — pontosan ezért nem veszi észre senki hónapokig.
Duplikáció és vékony tartalom sablonszinten
A duplikált címek és leírások szinte soha nem szövegírási hibák. Sablonhibák. Amikor 1400 termékoldal ugyanazt a „Termék | Webshop" címet viseli, azt egy sor sablonkód okozta, és egy sor fogja megjavítani.
Itt termeli meg magát a Semalt ok szerinti csoportosítása. 1400 sor helyett egyetlen problémát kap egy URL-mintával és egy darabszámmal. A fejlesztőnek a mintát adja át, nem a táblázatot. Ugyanez igaz a vékony oldalakra: az audit sablononként fürtözi őket, így azonnal látszik, hogy tartalmi problémája van-e (egyedi oldalak, amiket senki nem írt meg) vagy architekturális (egy sablon, amely több száz majdnem üres oldalt gyárt, amelyeknek sosem kellett volna indexelhetőnek lenniük).
Erről részletesen itt írtunk: Az új Semalt: egyetlen platform, amely az egész SEO-folyamatot kézben tartja.
Egy teszt, amit érdemes lefuttatni. Rendezze a vékony tartalmú listát sablon szerint. Ha a jelzett URL-ek több mint 60%-a egyetlen sablonból jön, hagyja abba a tartalomírást, és javítsa a sablont. Láttunk oldalakat jelentős láthatóságot visszanyerni pusztán azzal, hogy noindexre tettek egy címke-archívum sablont, amely négyezer majdnem üres oldalt generált.
Core Web Vitals: laborzaj és valós felhasználói adat
A sebességriport az a pont, ahol a legtöbb audit félrevezet. Egy egyszeri szintetikus futás laborpontszáma azt mondja meg, mit tapasztalt egy szimulált eszköz egyszer. A mezőadat azt, mit tapasztaltak a valódi felhasználói 28 nap alatt. Gyakran ellentmondanak egymásnak, és ilyenkor a mezőadat nyer, mert az hat a rangsorolásra.
Az audit mindkettőt megjeleníti, és — ami hasznosabb — sablononként csoportosítja az URL-eket, így nem az derül ki, hogy „az oldal lassú", hanem az, hogy „a kategóriasablonnak Largest Contentful Paint problémája van mobilon". Ez cselekvésre alkalmas állítás. Az „oldal lassú" nem az.
A gyakorlati tanács, amit az ügyfeleinknek adunk: először az LCP-t javítsa, mert általában ez a bukó mérőszám, és általában valami konkrét és javítható okozza — egy optimalizálatlan hero-kép, egy renderelést blokkoló betűtípus, egy lassú szerverválasz nem gyorsítótárazott oldalakon. A Cumulative Layout Shift a második, és szinte mindig hirdetési helyek vagy méret nélküli képek okozzák. Az interakciós késleltetés a harmadik, és általában a legnehezebb, mert JavaScriptet jelent, a JavaScript pedig valódi mérnöki beszélgetést.
Strukturált adatok és hreflang
Két ellenőrzés, amely a súlyánál többet nyom többnyelvű és helyi vállalkozásoknál.
A strukturált adatok validálása azokat a hibákat fogja meg, amelyek csendben elveszik a rich resultokat: ár nélküli Product séma, LocalBusiness bejegyzés olyan címmel, amely nem egyezik a látható oldalon szereplővel, Review jelölés olyan oldalon, ahol nincs látható értékelés. A csillagos értékelés elvesztése a találati listán azonnal és észrevétlenül csökkenti az átkattintási arányt.
A hreflang az, amely a legtöbbet számít az olyan oldalakon, amilyeneket Budapesten üzemeltetünk, ahol magyar, angol és német verzió él egymás mellett. A szabályok egyszerűek, és szinte mindenhol sérülnek: minden nyelvi verziónak hivatkoznia kell minden másikra, önmagát is beleértve, az annotációknak kölcsönöseknek kell lenniük, és minden verziónak saját, önmagára mutató canonical kell. Az audit felszínre hozza a hiányzó visszamutató linkeket és azokat a verziókat, amelyek nyelvek között kanonizálnak — ez a hiba lényegében azt közli a keresőkkel, hogy hagyják figyelmen kívül a teljes fordított oldalt.
Javítási sorrend a Core Web Vitalsnál. Először az LCP — általában ez a bukó mérőszám, és általában konkrét oka van: optimalizálatlan hero-kép, renderelést blokkoló betűtípus, lassú válasz nem gyorsítótárazott oldalakon. Másodszor a CLS, amit szinte mindig hirdetési helyek vagy méret nélküli képek okoznak. Harmadszor az interakciós késleltetés, mert az JavaScriptet jelent — a JavaScript pedig valódi mérnöki beszélgetést.
Hogyan priorizáljunk, ha a lista hosszabb a büdzsénél
Minden audit több megállapítást termel, mint amennyit bárki megjavít. A készség a sorrendezés, és a sorrendnek üzleti hatást kell követnie, nem súlyossági címkéket.
| Sorrend | Kategória | Miért ez van elöl |
|---|---|---|
| 1 | Indexelési hiba bevételt termelő oldalon | Az oldal láthatatlan; addig semmi más nem számít |
| 2 | Sablonszintű duplikáció fő sablonokon | Egy javítás, több száz URL, azonnali hatás |
| 3 | Törött hreflang a nyelvi verziók között | A rossz nyelvű találat megöli a konverziót minősített forgalmon |
| 4 | LCP a legnagyobb forgalmú sablonon | Rangsorolásra és konverzióra is hat |
| 5 | Strukturált adat rich-result jogosult oldalakon | Olcsó javítás, közvetlen CTR-hatás |
| 6 | Minden más | Valóban minden más |
A Semalt hatáspontozása ezt automatikusan közelíti azzal, hogy a hibákat az egyes URL-ek forgalmi és pozícióadataihoz súlyozza, de a pontszám nem tudhatja, mely oldalak hozzák a bevételét. Szánjon tizenöt percet arra, hogy a projekt beállításánál csoportként megjelöli a kereskedelmi URL-eket, és a priorizálás lényegesen pontosabb lesz.
Teljes útmutató a témához: Semalt analitika és pozíciókövetés.
Megállapításból jegy, amit a fejlesztő elfogad
Itt hal el a legtöbb SEO-munka. Egy auditmegállapítás nem jegy. A „javítsuk a duplikált címeket" örökre a backlogban fog ülni. Egy olyan jegy, ami elkészül, így néz ki:
- Hol
A pontos sablonfájl vagy URL-minta — nem egy exportból bemásolt URL-lista.
- Mit
A jelenlegi és a kívánt kimenet, olyan szabályként, amit a fejlesztő egyszer implementál.
- Miért
Egy mondat üzleti következmény. Nem SEO-előadás, és nem súlyossági címke.
- Hogyan ellenőrizzük
A konkrét ellenőrzés, ami visszaigazolja — itt a következő ütemezett crawl, amely vagy elejti a hibát, vagy nem.
Ez az utolsó pont az, amiben a platform a legtöbbet segít. Mivel a bejárás ütemezett és összehasonlító, a javított hiba eltűnik a következő futásból, és megoldottként jelenik meg a változásnaplóban. Nem kell a fejlesztőnek Önben bíznia, és nem kell kézzel újraellenőriznie 1400 URL-t. A rendszer igazolja a javítást, és mindkettejüknek megmondja.
Öt hiba, amit auditeszközökkel el szoktak követni
A hibaszám pontszámként kezelése. A 400-ról 40-re csökkenés semmit nem jelent, ha az a 40, ami maradt, éppen a kategóriaoldalakon van. Súlyozzon, ne számoljon.
Alapbeállításokkal bejárni egy JavaScript-oldalt. Olyan riportot fog kapni, amely szerint az oldalon nincs tartalom. Van tartalom. A crawler nem renderelt.
Azt javítani, ami könnyű, ahelyett, ami számít. Alt szöveg 300 képhez látványos, jólesően mérhető haladás. A legtöbb oldalon ugyanakkor a nullához közeli értéket képvisel egyetlen canonical-hibához képest a kategóriasablonon.
Egyszer futtatni az auditot. Az egyszeri audit a mai problémákat találja meg. Az oldalak folyamatosan romlanak — deployok, bővítményfrissítések, CMS-változások. Az érték a különbségben van, nem a pillanatképben.
A nyers exportot elküldeni az ügyfélnek. A SEO-n kívül senki nem tudja elolvasni, és a munkáját panaszlistának mutatja terv helyett. Küldjön három priorizált tételt, és azt, hogy melyik mennyit ér.
Amire a bejárás jól válaszol
- Indexelhetőség, canonicalok, átirányítási logika
- Sablonszintű duplikáció és vékony oldalak
- hreflang-kölcsönösség a nyelvi verziók között
- Strukturált adatok érvényessége, rich-result jogosultság
Amire szerkezetileg nem tud
- Mit töltött le ténylegesen a Googlebot és milyen gyakran (ez loganalízis)
- Hogy a jól formázott oldal mond-e bármi olvasásra érdemeset
- Hogy az oldal illeszkedik-e a lekérdezés mögötti szándékhoz
- Hogy melyik oldala hordozza a kereskedelmi súlyt
Ismételhető havi auditfolyamat
Ezt a kört futtatjuk retainereken, ami beállítás után nagyjából másfél óra ügyfelenként havonta.
Nyissa meg a crawl különbséglistáját, és csak azt olvassa, ami változott. Az új hibák azonnal triázsra kerülnek, a megoldottakat feljegyzi a riporthoz. Bármi, ami újként jelenik meg egy kereskedelmi sablonon, még aznap kivizsgálandó, mert a pénzt termelő oldalakon megjelenő új problémákat majdnem mindig egy deploy okozza, a deployokat pedig akkor a legkönnyebb visszafordítani, amíg mindenki emlékszik rájuk.
Ezután vesse össze a pozícióadatokkal ugyanazon az idővonalon. Ha a rangsorolás ugyanabban az ablakban esett, amikor technikai változás történt, akkor hipotézise van rejtély helyett. Ez az egyetlen szokás — a technikai és a pozícióváltozás egy diagramon való olvasása — több valós problémát fog meg, mint az audit bármelyik önálló ellenőrzése.
Végül írja meg azt a két-három jegyet, amit ebben a hónapban érdemes megírni, a többi pedig várjon. Egy lassan növekvő, de folyamatosan fogyasztott auditbacklog jobb, mint egy hősies negyedéves nagytakarítás, amely soha nem történik meg.
Amit egy bejárás nem tud megmondani
A határ tisztázása hasznosabbá teszi az eszközt, nem kevésbé hasznossá. A crawler azt látja, amit egy crawler elér. Nem látja, mit döntött a Googlebot ténylegesen letölteni, milyen gyakran, és mit kezdett a válasszal. Ez a szerverlogokban él, a loganalízis pedig továbbra is külön szakma, amit egyetlen auditeszköz sem vált ki teljesen. Néhány ezer URL alatti oldalaknál ez ritkán számít. Egy nagy webáruház-katalógusnál, ahol a crawl-büdzsé a szűk keresztmetszet, az audit megmondja, mi a hiba, a logok pedig azt, hogy a Google egyáltalán ránézett-e.
A bejárás a tartalom minőségét sem tudja úgy megítélni, ahogy egy olvasó. Tud hosszt mérni, közeli duplikációt észlelni és egyedi szöveg nélküli oldalakat jelezni, és ezek a jelek hasznosan korrelálnak a problémákkal. De egy 2000 szavas oldal, amely semmit nem mond, minden valaha megírt automatikus ellenőrzésen átmegy. Ha a pozíciói laposak és a technikai riport tiszta, a probléma nagy valószínűséggel éppen az, amit a crawler szerkezetileg képtelen értékelni.
Végül a szándékbeli eltérést sem látja. Egy oldal lehet technikailag tökéletes, gyors, jól jelölt — és teljesen rossz arra a lekérdezésre, amelyre céloz: egy szolgáltatásoldal olyan kifejezésre versenyez, ahol minden rangsoroló találat összehasonlító cikk. Ez a diagnózis a SERP nézéséből jön, és ezért az audit a stratégia egyik bemenete, nem maga a stratégia.
Amit magyar oldalakon a leggyakrabban találunk
Több tucat magyar oldal auditja után kirajzolódik néhány visszatérő minta, amelyek máshol ritkábbak. A leggyakoribb az ékezetes URL-ek és az átirányítások keveredése: az oldal él ékezetesen és ékezet nélkül is, mindkettő 200-as kóddal, canonical nélkül. Ez tökéletes duplikációt gyárt, és a magyar oldalak talán negyedén megtaláljuk.
A második a webáruházak méretkészlet-problémája. A magyar webshopmotorok szeretnek minden méret- és színvariánsra önálló, indexelhető URL-t generálni. Egy 400 termékes bolt így 12 000 majdnem azonos oldallal jelenik meg a bejárásban, és a Google a valódi termékoldalak helyett ezeket olvassa.
A harmadik a többnyelvűség félkész állapota. Nagyon sok budapesti szolgáltatónál az angol verzió egy részleges fordítás, ahol a lefordítatlan aloldalak a magyar tartalmat mutatják angol URL-en. Ez a hreflang szempontjából a legrosszabb eset: a keresőnek két nyelvi verziót ígér, és ugyanazt a szöveget adja. Az audit ezt duplikációként és hreflang-inkonzisztenciaként is jelzi, és általában ez az a hiba, amelynek javítása a leggyorsabban hoz mérhető eredményt a nemzetközi forgalomban.
Összegzés
Pusztán a technikai ellenőrzések szélessége alapján a Semalt auditja kényelmesen megáll a bevett crawlerek mellett anélkül, hogy drámaian különbözne — a komoly eszközök nagyjából ugyanazt vizsgálják, mert az, amit érdemes vizsgálni, jól ismert.
Lásd még: AI-keresés, AEO és helyi SEO.
Ahol elválik tőlük, az a crawl utáni rész: ok szerinti csoportosítás URL-listák helyett, hatássúlyozás lapos súlyossági szintek helyett, és folyamatos összehasonlítás pillanatképek helyett. Ez a három döntés dokumentumból folyamattá alakítja az auditot — és a folyamat az, ami az oldalakat ténylegesen megjavítja.
Ha olcsón akarja tesztelni ezt az állítást, futtassa le olyan oldalon, amelynek ismeri a problémáit. Hozzon létre egy projektet, konfigurálja rendesen a bejárást, és nézze meg, hogy az első három priorizált tétel egyezik-e azzal a hárommal, amit Ön választott volna. Ez az egyetlen mérce, amely számít.
Gyakori kérdések
Milyen gyakran fusson a bejárás?
A gyakoriságot a változási ütem határozza meg, nem az oldal mérete. Legalább olyan gyakran járjon be, ahogy publikál vagy deployol, hogy minden változás pontosan egyszer jelenjen meg egy különbséglistában. A ritkább bejárás összevont jelentéseket ad, amelyekben az okok már nem választhatók szét — pedig éppen ez a szétválaszthatóság a módszer valódi értéke.
Az audit több száz hibát listáz. Hol kezdjem?
A bevételt termelő oldalak indexelési hibáival, mert egy láthatatlan oldal mellett minden más lényegtelen. Utána a kereskedelmi sablonok sablonszintű duplikációja, majd a nyelvi verziók közti törött hreflang, majd az LCP a legnagyobb forgalmú sablonon. Minden más tényleg várhat — és ha a projekt beállításánál csoportként megjelöli a kereskedelmi URL-eket, a platform saját priorizálása is lényegesen pontosabb lesz.
JavaScript-alapú az oldalam. Működni fog a bejárás?
Igen, de a renderelést az első futás előtt be kell kapcsolni. Kikapcsolt rendereléssel a riport azt fogja állítani, hogy nincs tartalom az oldalon, és egy napot fog egy nem létező probléma kergetésével tölteni. Összetett oldalaknál a hatókört, a renderelést és a paraméterkezelést a bejárás előtt állítsa be, ne fogadja el az alapértelmezéseket.
Kiváltja az audit a szerverlog-elemzést?
Nem. A crawler azt látja, amit egy crawler elér; nem látja, mit döntött a Googlebot ténylegesen letölteni, milyen gyakran, és mit kezdett a válasszal. Néhány ezer URL alatt ez ritkán számít. Nagy katalógusnál, ahol a crawl-büdzsé a szűk keresztmetszet, az audit megmondja, mi a hiba, a logok pedig azt, hogy a Google egyáltalán ránézett-e.
Nyissa meg a Semalt irányítópultot
Audit, pozíciókövetés, versenytárs-adatok és riportok egy felületen. Jelentkezzen be, és néhány percen belül lát valós adatot a saját domainjéről.
Belépés a SemaltbaVagy nézze meg előbb a szolgáltatásokat a semalt.com.