Technikai SEO tanácsadás

Adatgyűjtés és hozzáférések

Az adatgyűjtés a hozzáférésekkel kezdődik: Search Console, Bing Webmaster Tools, analitika, szervernapló és a staging-környezet. A csapatodtól ebben a lépésben a hozzáférések megadása és egy egyeztetés kell arról, hogyan épül fel az oldal.

A crawlt Screaming Frog SEO Spiderrel futtatom, renderelt módban is, így látszik, mit kap a kereső a nyers HTML-ben, és mit a JavaScript lefutása után. A crawl adja az URL-leltárt: minden elérhető URL a státuszkódjával, a canonicaljával, az indexelhetőségével és a belső linkjeivel. Nagy oldalon a crawl szerveren fut, nem a laptopomon, így a belső hálón vagy VPN mögött futó staging is ellenőrizhető. Ha sok csapat és üzletág dolgozik ugyanazon az oldalon, és szegmentált, jogosultság szerinti hozzáférés kell, a crawlt az igényhez szabom.

A szervernapló mutatja meg, mit csinál valójában a Googlebot, a Bingbot és az AI-crawlerek: melyik URL-t kérik le, milyen gyakran, és milyen választ kapnak. Ezt Screaming Frog Log File Analyserrel elemzem.

A Search Console URL-vizsgálata, az Oldalindexelés és a Feltérképezési statisztikák jelentés mutatja, mit indexelt a Google, és mit hagyott ki. A Bing Webmaster Tools ugyanezt adja a Bingről.

A Core Web Vitals terepi adata a Chrome UX Reportból jön, vagyis valódi látogatók méréséből. A Lighthouse és a WebPageTest laborban mér: a hibakereséshez jó, de a kettőt nem keverem össze. Az Ahrefs a backlinkeket és a láthatóságot, a DataForSEO a kulcsszó- és SERP-adatot adja. Az eszközök költségét én fizetem, benne van az óradíjban.

A saját fejlesztésű ellenőrzőm a technikai és az entitáshibákat nézi végig. Az eszközök a hibák megtalálását automatizálják, a diagnózist és a sorrendet nem.

Mérés: a kiinduló állapot

A kiinduló állapot rögzíti, honnan indulunk: egy meghatározott időszakot, oldalcsoportonként (sablon, eszköz, piac), és azt is, milyen külső változás volt közben, például Google-frissítés vagy kampány. Ezeket a mutatókat mérem:

• Indexelt oldalak: az értékes URL-ek közül hány van az indexben.
• Indexelési idő: mennyi idő telik el a közzététel és az indexbe kerülés között.
• Crawl-hatékonyság: a Googlebot kéréseinek mekkora része jut az értékes URL-ekre, és mennyi megy el paraméteres, duplikált vagy hibás címekre.
• Canonical-egyezés: a megadott canonicalt választja-e a Google.
• Strukturált adat: hibátlan-e a jelölés, és jogosult-e az oldal kiemelt találatra.
• Szerverválasz (TTFB, DNS): milyen gyorsan válaszol a szerver. Ez a sebesség technikai SEO-haszna: gyorsabb válasznál a robotok többet és gyorsabban crawlolnak.
• Core Web Vitals (LCP, INP, CLS): a betöltés, a reakcióidő és az elrendezés stabilitása valódi látogatóknál. A Google rangsorolási rendszerei is figyelembe veszik, de a nagyobb hatása a felhasználói élményen és a konverzión látszik.
• Organikus teljesítmény: kattintás, megjelenés, átkattintási arány és pozíció a Search Console-ban.

Audit: mit nézek

Az audit területenként nézi végig, mi akadályozza a crawlolást, a renderelést és az indexelést. Minden hibánál azt keresem, melyik mutatón látszik, és mi az oka.

Feltérképezhetőség. A feltérképezhetőség azt jelenti, hogy a robot eljut-e az oldalakra. Megnézem a crawl-útvonalakat és a robotok hozzáférését, a paraméterek kezelését és a crawl budgetet, vagyis hogy a Googlebot ideje az értékes URL-ekre jut-e. A belső linkelésnél az árva oldalakat és a linkmélységet nézem: ami mélyen van, azt a robot is ritkábban éri el.

Indexelhetőség. Az indexelhetőség azt jelenti, hogy az elért oldal bekerülhet-e az indexbe. Itt a canonical a fő kérdés: abszolút URL-e, önmagára mutat-e, és egyezik-e azzal, amit a Google választ. A robots.txt-ben a tiltásokat és a user-agent csoportokat nézem, az XML sitemapben azt, hogy csak kanonikus, indexelhető URL-ek vannak-e benne. Az átirányításoknál a típust (a 301 és a 308 végleges, a 302 és a 307 ideiglenes), a láncokat és a hurkokat ellenőrzöm.

Renderelés. A renderelés azt jelenti, hogy a kereső mit lát a JavaScript lefutása után. Összevetem a nyers HTML-t és a renderelt DOM-ot: ha a szöveg, a linkek vagy a meta tagek csak JavaScripttel jelennek meg, a kereső később látja őket, több AI-crawler pedig egyáltalán nem. Ilyenkor a szerveroldali renderelés (SSR), a statikus generálás (SSG) vagy az inkrementális újragenerálás (ISR) a megoldás, és megnézem a hydrationt és a cache-rétegeket is.

Sebesség. A sebesség technikai SEO szempontból a szerver válaszidejéről és a renderelés költségéről szól: minél gyorsabb a válasz, és minél kevesebb a kliensoldali JavaScript, annál többet és gyorsabban crawlolnak a kereső- és AI-robotok. A CDN-nél az edge cache-t nézem, és azt, hogy nem zárja-e ki a robotokat. A látogatói oldalon a Core Web Vitals mutatja, sablononként mi okozza a rossz LCP-t, INP-t vagy CLS-t. A lassú oldalról a látogató gyorsabban lép vissza a találatokhoz, és ezt a Google és a Bing is negatív jelként kezelheti; a Google a kattintási adatok használatát a 2023-as amerikai trösztperben el is ismerte. Hogy a sebesség hogyan hat a konverzióra, azt a sebesség és konverzió esettanulmányban mutatom meg.

Strukturált adat. A strukturált adatnál a JSON-LD jelölést nézem: egyezik-e az oldal tartalmával, és hiba nélkül átmegy-e a Schema.org- és a Google-ellenőrzésen.

Oldalszerkezet. Az oldalszerkezetnél az URL-hierarchiát és a crawl-mélységet nézem, és azt, hogy a CMS sablonjai milyen URL-eket és milyen HTML-t gyártanak. Az információs architektúra, a szűrős navigáció és a kategóriarendszer tartalmi kérdés is, erről a tartalmi SEO oldalon írok. A CMS kiválasztásáról és fejlesztéséről a weboldal-fejlesztés oldalon.

Nemzetközi beállítások. Többnyelvű vagy több országra szóló oldalon a hreflang-jelöléseket és azok egyezését a canonicallal ellenőrzöm. Hogy melyik piacra milyen URL-szerkezettel és lokalizációval érdemes belépni, arról a nemzetközi SEO tanácsadás oldalon írok.

Költözés. Költözésnél régi–új URL-térképet készítek, átirányítási és canonical-tervet, élesítés előtt végigcrawlolom a staginget, és figyelem a DNS-átállást. Előtte és utána is crawl fut, hogy a kettő összevethető legyen. Egy saját költözés számait a WordPressről Astróra esettanulmány mutatja.

Priorizálás és roadmap

A priorizálás dönti el, mi legyen az első. Minden hibát négy szempont szerint sorolok be: mekkora a hatása, mennyi munka, mekkora a kockázata, és mennyire biztos az ok. Ebből technikai SEO roadmap lesz felelőssel, határidővel és függőségekkel, és minden tételnél ott van, melyik mutatón fog látszani. Ez a technikai SEO stratégia: nem a hibák listája, hanem a javítások sorrendje.

Implementálás a fejlesztőkkel

Az implementálás fejlesztői jegyekkel megy. Minden jegyben benne van, mit kell változtatni, miért, és mi az elfogadási feltétel, így a fejlesztő kérdés nélkül el tudja kezdeni. A jegyek a ti backlogotokba és sprintjeitekbe kerülnek, és előre megmondom, mennyi fejlesztői időt kérnek, hogy beférjenek a kapacitásba. Shopifyn és WordPressen a javításokat magam csinálom, más platformon a fejlesztőitekkel dolgozom, amíg a jegyek kimennek. A munka nem ér véget az audittal.

Ellenőrzés kiadás előtt és után

Az ellenőrzés két ponton fut: kiadás előtt a stagingen, kiadás után élesben. Regressziót keresek, vagyis azt, hogy a javítás nem rontott-e el mást. Ha a fejlesztés GitHubon megy, az ellenőrzés a kiadási folyamatba épül, és minden módosításnál lefut. Más esetben kiadás előtt és után crawl fut.

Visszamérés és eredmény

A visszamérés ugyanazokat a mutatókat nézi, ugyanazokon az oldalcsoportokon, mint a kiinduló állapot. Riasztási küszöböt állítok be, és számolok azzal, hogy a Google-nek idő kell az újracrawlhoz és az újrafeldolgozáshoz.

Először a technikai eredmény látszik: gyorsabb és több indexelés, gyorsabb szerverválasz, kevesebb elpazarolt crawl, egyező canonicalok. Az üzleti eredmény később jön: nagyobb láthatóság, több releváns organikus látogató, több organikus konverzió. Ezt analitikai adatokkal mérjük, a mérés beállításáról a webanalitika tanácsadás oldalon írok. Ha a forgalom elég nagy, a hatást sablonszintű SEO split teszttel, kontrollcsoporttal mérem. Időt nem ígérek: azt mondom meg, mit mérünk, és mihez viszonyítjuk.