— Keresőoptimalizálás

Technikai SEO

Az a rész, ami nélkül a legjobb tartalom sem teljesít: hogy a kereső elérje, megértse és gyorsan kiszolgálhassa az oldalaidat.

A keresőmotor két részből áll: az egyik összegyűjti az információt, a másik rendszerezi. A robot a linkeket követve bolyong a weboldalak között, és letölti a tartalmukat — ha ebben bármi megakasztja, a tartalom nem is jut el az indexbe.

A technikai munka ezért az alapoknál kezdődik: mit lát a robot, mit tud értelmezni, és milyen sebességgel. Ide tartozik a struktúrált adatok kérdése is, ami az AI-keresők korában felértékelődött: a gépi olvashatóság ma nem extra, hanem belépő.

Migráció, webshop-átállás vagy domainváltás esetén ez a legkockázatosabb terület — érdemes még a fejlesztés előtt bevonni valakit, aki látta már, mi tud elromlani.

Tipikus munkák

• Indexelési és crawl-problémák feltárása, javítási terv
• Oldalsebesség és Core Web Vitals
• Struktúrált adatok (schema.org) bevezetése
• Belső linkstruktúra és URL-szerkezet
• Migrációk, átirányítási tervek, domainváltás
• Webshop-specifikus kérdések: szűrők, variánsok, duplikációk

A Google nem ugyanazt az oldalt látja, amit te

Te megnyitod a weboldalt, végigkattintod a menüt, látod a képeket, a termékeket és a szöveget, majd joggal gondolhatod, hogy minden a helyén van. A kereső közben egy egészen más útvonalon próbálja feltérképezni ugyanezt: URL-eket fedez fel, linkeket követ, JavaScriptet dolgoz fel, átirányításokon halad keresztül, canonical jelzéseket értelmez, majd eldönti, hogy az így megtalált oldalak közül melyeket érdemes egyáltalán indexelnie.

Ha ezen az útvonalon valami félremegy, a weboldal még tökéletesen működőképesnek tűnhet.

Lehet olyan fontos kategóriaoldalad, amelyhez alig vezet belső link. Lehet több URL-ed ugyanazzal a tartalommal, miközben nem egyértelmű, melyiket szeretnéd rangsoroltatni. Előfordulhat, hogy egy szűrőrendszer tízezrével gyárt olyan oldalakat, amelyekre valójában nincs szükség, miközben az üzletileg fontos URL-ek feltérképezése nehezebb, mint kellene.

A technikai SEO első feladata ezért nem az, hogy hibákat gyűjtse, hanem hogy megértse, hogyan járja be és hogyan értelmezi a kereső a webhelyet.

Ha ez eltér attól, amit te szeretnél, ott érdemes elkezdeni dolgozni.

Az indexelés nem attól működik, hogy beküldtük a sitemapet

A sitemap hasznos. A Search Console URL-ellenőrzője is hasznos. Ettől még egyik sem jelent garanciát arra, hogy a Google minden általad fontosnak tartott oldalt indexelni fog, és főleg nem arra, hogy a megfelelő URL-t választja majd egy adott tartalom reprezentánsául.

Nagyobb webhelyeken sokkal érdekesebb kérdés, hogy milyen arányban vannak az indexben azok az oldalak, amelyekből valóban organikus forgalmat szeretnénk, és mennyi fölösleges vagy gyenge URL kerül ugyanabba a rendszerbe.

Egy webáruháznál például a kategóriák, szűrők, rendezések, paraméterek és termékvariációk kombinációja könnyen hatalmas URL-készletet hozhat létre úgy, hogy annak csak kis része képvisel önálló keresési értéket. Tartalmi oldalaknál ugyanezt megcsinálhatják a címkék, az archívumok, a lapozások és a több év alatt egymásra rakódott régi tartalmak.

Ilyenkor nem az a cél, hogy „minél több oldal legyen a Google-ben”.

Az a cél, hogy a megfelelő oldalak legyenek ott, és a kereső számára is egyértelmű legyen, melyik URL mire való.

Ehhez néha canonical kell, néha noindex, máskor átirányítás vagy egyszerűen jobb belső struktúra. Olyan helyzet is van, amikor a helyes megoldás az, hogy egy technikailag furcsának tűnő állapothoz egyáltalán nem nyúlunk.

A technikai SEO-ban a „javítható” és a „javítandó” nem ugyanaz.

A crawl budget ritkán az első probléma. A rossz struktúra annál gyakrabban

A crawl budget jól hangzik, ezért könnyű vele komoly technikai projektet indokolni. A legtöbb kisebb és közepes weboldalnál azonban sokkal prózaibb kérdésekben van a valódi probléma: túl mélyre kerülnek fontos oldalak, rosszul működik a belső linkelés, fölösleges URL-ek szaporodnak, vagy maga a webhely sem teszi egyértelművé, mely tartalmak a legfontosabbak.

Ha egy kulcsfontosságú szolgáltatási vagy kategóriaoldal csak öt-hat kattintás után érhető el, miközben kevés belső hivatkozást kap, abból a kereső is következtet valamire.

Ha száz különböző URL vezet lényegében ugyanahhoz a tartalomhoz, abból is.

A jó webhelystruktúra ezért egyszerre technikai és tartalmi kérdés. A navigáció, az URL-szerkezet, a kategóriák és a belső linkek együtt mutatják meg, hogyan épül fel az oldal, mely témák tartoznak össze, és mely tartalmaknak adsz nagyobb súlyt.

Sok esetben ezen többet lehet nyerni, mint újabb száz SEO-beállítás finomhangolásával.

Az oldalsebességet sem stopperórára optimalizáljuk

A lassú weboldal kellemetlen, különösen mobilon, ezért az oldalsebességgel és a Core Web Vitals-mutatókkal kell foglalkozni. A probléma ott kezdődik, amikor a technikai SEO egy Lighthouse-pontszám-hajszolásává válik, és heteket töltünk azzal, hogy egy már jól használható oldal 91 pontból 97 legyen.

A teljesítményt érdemes összefüggéseiben nézni.

Mi lassítja az első betöltést? Mikor jelenik meg a lényegi tartalom? Ugrál-e az oldal olvasás közben? Mennyi felesleges JavaScriptet töltünk be? Mit okoznak a harmadik féltől érkező szkriptek, mérőkódok, chatablakok, videók vagy hirdetési rendszerek? A probléma az egész webhelyet érinti, vagy csak egy sablont?

Egy webshop termékoldalán egészen más kompromisszum lehet elfogadható, mint egy egyszerű szolgáltatási landing oldalon, mert az előbbinél termékképek, értékelések, variációk és egy sor funkció terhelik a böngészőt.

A cél nem laboratóriumi rekord.

Az a cél, hogy a valódi felhasználónak gyors oldal jusson, úgy, hogy közben ne bontsunk le olyan funkciókat, amelyekből üzlet lesz.

A JavaScript akkor érdekes, amikor valamit elrejt

A modern weboldalak jelentős része JavaScript nélkül már alig hasonlítana önmagára, ezért önmagában az nem probléma, hogy egy oldal sok JavaScriptet használ. A technikai SEO szempontjából akkor válik érdekessé, amikor fontos tartalom, link vagy funkció csak olyan módon jelenik meg, amelyet a kereső nehezebben fedez fel vagy értelmez.

Ezt nem lehet pusztán abból eldönteni, hogy milyen framework készült az oldal.

Meg kell nézni, mi érkezik meg az első HTML-ben, mi kerül renderelésre később, hogyan működnek a belső linkek, látható-e ugyanaz a tartalom a robot számára, és nem építettünk-e véletlenül olyan felületet, amely felhasználóként látványos, keresőként viszont meglepően üres.

Különösen fontos ez JavaScript-heavy webshopoknál, SPA-knál és egyedi fejlesztésű alkalmazásoknál, ahol a technikai döntések már közvetlenül meghatározhatják, hogy milyen tartalmat tud a kereső egyáltalán felfedezni.

Itt a „SEO majd a végén beállítja” megközelítés általában drága.

Sokkal olcsóbb akkor gondolni rá, amikor a rendszer még készül.

A strukturált adat nem varázsszer

A schema markup hasznos eszköz, mert gépileg egyértelműbbé tehet bizonyos információkat egy oldalon: egy termékről, szervezetről, eseményről, receptről vagy más támogatott entitásról strukturált formában is közölhetünk adatokat.

Ebből azonban könnyű egy újabb kipipálandó SEO-feladatot csinálni.

Attól, hogy húszféle schema került az oldal forrásába, még nem lett világosabb maga a tartalom, nem lett jobb a webhelystruktúra, és egy gyenge oldal sem válik automatikusan erős találattá.

A strukturált adat akkor jó, amikor pontosan leképezi azt, ami ténylegesen megtalálható az oldalon, technikailag helyes, és van világos oka annak, hogy használjuk.

Ugyanez igaz az AI-keresők miatt kialakuló technikai lelkesedésre is. Érdemes gépileg jól értelmezhető, tisztán strukturált weboldalt építeni, csak nem azért, mert találtunk egy új titkos kapcsolót, hanem mert minél egyértelműbb a tartalom és annak kapcsolatrendszere, annál kevesebb találgatást hagyunk a feldolgozó rendszerekre.

Egy webshop technikai SEO-ja különműfaj

Egy húszoldalas szolgáltatói webhelyen viszonylag könnyű átlátni, mely URL-eknek kell létezniük. Egy tízezer termékkel rendelkező webáruházban már minden technikai döntés megsokszorozódhat.

Ha egy hibás szabály termékenként három fölösleges URL-t hoz létre, abból nem három, hanem harmincezer probléma lesz.

Ezért webshopoknál különösen fontos a kategóriastruktúra, a faceted navigation, a szűrők és rendezések kezelése, a termékvariációk, az elfogyott termékek, a duplikációk, a canonical beállítások és a belső linkek rendszere. Ehhez jön még a termékfeed, a strukturált termékadatok, a JavaScript és az a folyamatos változás, amit maga a készlet okoz.

A technikai SEO itt nem egyszeri nagytakarítás, mert az oldal szerkezete folyamatosan együtt mozog az üzlettel.

Új kategória jön létre. Termékek tűnnek el. Szűrők változnak. URL-ek születnek. Egy fejlesztés módosítja a navigációt.

Ha a SEO-logika nincs beépítve ezekbe a folyamatokba, a technikai adósság szép lassan újratermeli magát.

Migrációnál a legjobb SEO-eredmény néha az, hogy nem történik semmi

Új weboldal készül, változik a motor, átalakul az URL-struktúra, új domainre költözik a cég, összeolvad két webhely vagy teljesen új kategóriarendszer kerül a régi helyére.

Marketingoldalról ez rendszerint új kezdet.

Keresőoldalról kockázat.

A régi URL-eknek múltjuk van: linkeket kaptak, helyezéseket szereztek, a Google ismeri őket, a felhasználók pedig keresési találatokból érkeznek rájuk. Ha egy migráció során mindezt úgy cseréljük le, hogy nincs pontos URL-térkép, megfelelő átirányítás, tesztelés és utókövetés, akkor hónapok vagy évek alatt felépített organikus teljesítményt lehet néhány élesítési döntéssel visszavágni.

Ezért a technikai SEO-s migrációs tervet nem az élesítés előtti délután érdemes elkezdeni.

Már a fejlesztés során tudni kell, mely URL-ek maradnak, melyek változnak, mit mivel vonunk össze, hogyan örökítjük tovább a régi struktúra értékét, és milyen mérésekből fogjuk látni az élesítés után, hogy valami félrement.

Egy jól levezényelt migráció után gyakran nincs látványos grafikon, amit ünnepelni lehet.

Pont ez benne a szép.

A forgalom nem zuhant be.

Robots.txt, sitemap, canonical: egyik sem helyettesíti a gondolkodást

A technikai SEO tele van olyan eszközökkel és direktívákkal, amelyek egy konkrét problémára kiválóan használhatók, rossz helyen alkalmazva viszont könnyen új problémát hoznak létre.

A robots.txt segítségével szabályozhatjuk a feltérképezést, de nem ugyanazt csinálja, mint az indexelés kezelése. A canonical jelezheti, melyik URL-t tekintjük elsődlegesnek, de nem arra való, hogy minden duplikációs problémát automatikusan megoldjon. A sitemap segíti a fontos URL-ek felfedezését, de egy rosszul felépített belső linkstruktúrát nem rendez.

Ezeket nem különálló checkboxokként érdemes kezelni, hanem ugyanannak a rendszernek a részeként.

Mit akarunk feltérképeztetni?

Mit akarunk indexeltetni?

Melyik URL-t szeretnénk megmutatni egy adott tartalomhoz?

És hogyan tesszük mindezt következetesen egy olyan webhelyen, amely közben folyamatosan változik?

Ha erre nincs világos válasz, néhány újabb SEO-plugin beállítása valószínűleg nem fog megoldást jelenteni.

A technikai audit végén nem száz piros sorra van szükséged

Egy crawler pillanatok alatt több száz vagy több ezer eltérést találhat egy nagyobb webhelyen, ezért technikai hibajegyzéket gyártani önmagában nem különösebb művészet.

A munka ott kezdődik, amikor ezeket kontextusba kell helyezni.

Egy minden termékoldalt érintő canonical hiba nyilván súlyosabb, mint néhány üres meta description. Egy véletlenül noindexelt kategória sürgősebb lehet, mint a Core Web Vitals néhány tizedmásodperces javítása, egy közelgő migráció pedig teljesen átírhatja azt, minek van most értelme.

Én ezért hatás, kockázat és ráfordítás szerint rakom sorrendbe a technikai feladatokat, hogy a fejlesztő ne egy százsoros SEO-listát kapjon a nyakába, hanem értse, melyik probléma miért fontos, hogyan kell javítani, és mit kell utána ellenőrizni.

A technikai SEO akkor működik jól, amikor egy idő után már alig látszik.

A Google eléri, amit el kell érnie, nem téved el a fölösleges URL-ek között, a fontos oldalak indexelhetők, a webhely gyorsan és kiszámíthatóan működik, egy új fejlesztés pedig nem bontja le azt, amit korábban már felépítettünk.

Nem hibamentes weboldal kell. Olyan technikai háttér kell, amely nem fogja vissza azt, amit a tartalommal és a keresőoptimalizálással el akarunk érni.