Technika seo: amit tudnod kell róla

Scheo · 2026-09-01 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha a technika seo kifejezésre kerestél, valószínűleg nem elméleti definíciót akarsz. Vagy azt vetted észre, hogy a friss oldalaid nem jelennek meg a Google-ben, vagy kaptál egy jelentést tele piros pontokkal, esetleg valaki azt mondta, hogy az oldalad lassú. Ez a cikk erre a helyzetre készült: végigmegyünk azon, mi tartozik ténylegesen a technikai SEO alá, hogyan derül ki, nálad melyik réteg hibás, és milyen sorrendben érdemes nekiállni. A szövegben külön jelölöm, hogy egy állítás hivatalosan igazolt (a gyártó dokumentációjában szerepel), saját tapasztalat (ügyfélmunkából származó megfigyelés), vagy szakmai feltételezés (logikus következtetés, hivatalos megerősítés nélkül).

Mit jelent pontosan a technikai SEO, és mi nem tartozik bele?

Rövid válasz: a technikai SEO az a munka, amivel a weboldalad gépileg feldolgozhatóvá válik: a keresőrobot el tudja érni, le tudja tölteni, meg tudja jeleníteni és be tudja indexelni az oldalaidat, méghozzá gyorsan és félreértés nélkül. A szövegírás minősége és a hivatkozásszerzés nem tartozik bele, viszont mindkettő hatástalan marad, ha a technikai alap hibás.

Hivatalosan igazolt: a Google dokumentációja négy lépésre bontja a folyamatot, ezek a feltérképezés, a megjelenítés, az indexelés és a kiszolgálás. A technikai SEO gyakorlatilag az első három lépés akadálymentesítése. Ha az elsőn elakadsz, a többi el sem indul.

Mi tartozik bele a gyakorlatban:

• elérhetőség: robots.txt, HTTP-státuszkódok, szerverválaszidő, átirányítási láncok
• indexelhetőség: noindex, kanonikus URL-ek, sitemap, paraméteres duplikációk
• megjelenítés: JavaScript-függő tartalom, szerveroldali vagy kliensoldali renderelés
• műszaki felhasználói jelek: Core Web Vitals, mobilnézet, HTTPS
• gépi értelmezés: strukturált adat, belső linkstruktúra, egyértelmű címhierarchia

Ami nem technikai SEO, bár gyakran ide keverik: a kulcsszókutatás, a tartalom minősége, a külső hivatkozások szerzése és a Google Cégprofil kezelése. Ezek külön munkák, más eszközökkel és más mérőszámokkal.

Honnan tudod, hogy nálad tényleg technikai hiba van?

Rövid válasz: akkor gyanakodj technikai okra, ha az oldal létezik és rendben van, de a Google szerint nem létezik, vagy létezik, de nem úgy, ahogy te látod. A tünet szinte mindig a megjelenések oldalán kezdődik, nem a pozíciónál.

Konkrét jelek:

• A site:domain.hu/utvonal keresés nem hozza vissza a publikált oldalt.
• A Search Console indexelési jelentésében nő a Felfedezve, jelenleg nincs indexelve vagy a Feltérképezve, jelenleg nincs indexelve kategória.
• Az oldal forráskódjában nem szerepel az a szöveg, amit a böngészőben látsz.
• A szolgáltatásoldal helyett a Google a kezdőlapot vagy a kategóriaoldalt mutatja a keresésre.
• Ugyanaz a tartalom sokféle URL-en elérhető: szűrőparaméterrel, nyomkövető paraméterrel, záró perjellel és anélkül.

Saját tapasztalat: amikor egy oldal hónapok óta nincs indexelve, az ok ritkán egzotikus. Vagy bennmaradt egy noindex az élesítés után, vagy az oldalra egyetlen belső link sem mutat, így a robot csak a sitemapból tud róla, és nem tartja fontosnak. Ezt a kettőt öt perc alatt ki lehet zárni, ezért érdemes velük kezdeni.

Hogyan ellenőrzöd, hogy a keresőrobot egyáltalán eléri az oldalaidat?

Rövid válasz: három dolgot nézz meg ebben a sorrendben: a robots.txt nem tiltja-e az útvonalat, az oldal 200-as státuszkóddal válaszol-e, és nincs-e rajta noindex. Ha bármelyik hibás, semmilyen tartalmi munka nem segít.

A robots.txt a domain gyökerében található, például a https://pelda.hu/robots.txt címen. Egy józan alapbeállítás sorai:

• User-agent: *
• Disallow: /wp-admin/
• Allow: /wp-admin/admin-ajax.php
• Sitemap: https://pelda.hu/sitemap_index.xml

A státuszkódot parancssorból a leggyorsabb megnézni: curl -I https://pelda.hu/szolgaltatas/. A válasz első sorában 200 kell hogy álljon. Egyetlen 301 önmagában nem baj, de az egymásba fűzött átirányítások feleslegesen égetik a feltérképezési keretet. Hivatalosan igazolt: a Googlebot csak korlátozott számú egymást követő átirányítást követ egy menetben, a hosszabb láncokat későbbre halasztja.

A noindexet a HTML fejlécében keresd: <meta name="robots" content="noindex, follow">. WordPressben ugyanezt a Beállítások, Olvasás menü keresőmotor-tiltó pipája is kiteszi az egész oldalra. Élesítés után ez a leggyakoribb önlövés. Egyedi oldalra a Search Console URL-ellenőrző eszköze mondja meg a legpontosabban, mit lát a Google.

Mit kezdj a Search Console indexelési jelentésével?

Rövid válasz: a jelentés kategóriái nem egyformán súlyosak. A kizárt URL-ek nagy része szándékos és teljesen rendben van, valódi bajt csak néhány kategória jelez.

1. Felfedezve, jelenleg nincs indexelve. A Google tud az URL-ről, de nem töltötte le. Gyakori ok a lassú szerver vagy az alacsony észlelt fontosság. Teendő: erősítsd a belső linkeket az oldalra, és nézd meg a válaszidőt.
2. Feltérképezve, jelenleg nincs indexelve. Letöltötte, de nem tartotta érdemesnek indexelni. Ez tartalmi jelzés műszaki köntösben. Teendő: bővítsd érdemben, vagy vond össze egy erősebb oldallal.
3. Duplikált tartalom, a Google más kanonikus oldalt választott. A jelölésedet felülbírálta. Teendő: nézd meg, tényleg különbözik-e a két oldal.
4. Átirányítás vagy noindex miatt kizárva. Általában szándékos. Csak akkor foglalkozz vele, ha olyan URL van köztük, aminek indexelve kellene lennie.
5. Szerverhiba (5xx) és nem található (404). A 404 önmagában nem büntetés, de ha belső link mutat rá, javítsd. Az 5xx viszont sürgős.

Hivatalosan igazolt: a Google szerint egyetlen oldal indexelése sem garantált, hibátlan technikai állapot mellett sem. A cél tehát nem a nulla kizárt URL, hanem az, hogy a fontos oldalaid mind az indexeltek között legyenek.

Miért lassú az oldalad, és mit érdemes ténylegesen javítani rajta?

Rövid válasz: három mérőszám számít, az LCP (a fő tartalom megjelenése), az INP (a válaszkészség kattintásra) és a CLS (a tartalom ugrálása). A hazai kis- és középvállalati oldalaknál a probléma túlnyomó része a képekből és a túl sok bővítményből jön.

Hivatalosan igazolt küszöbök: LCP 2,5 másodperc alatt, INP 200 ezredmásodperc alatt, CLS 0,1 alatt. Ezeket a Google valós felhasználói adatból számolja, nem laborteszt alapján, ezért egy szép PageSpeed-pontszám önmagában még nem jelenti, hogy jól állsz.

• A hero-kép mérete és formátuma. Egy súlyos JPEG helyett WebP vagy AVIF, a tényleges megjelenítési méretre vágva, gyakran önmagában megoldja az LCP-t.
• Betűtípusok. A külső forrásból húzott webfont késlelteti a szöveg megjelenését, a saját kiszolgálás és a font-display: swap segít.
• Rögzített képméretek. Ha a képnek van width és height attribútuma, nem ugrál a tartalom, és a CLS lemegy.
• Bővítmények. Sliderek, chatbuborékok és követőkódok együtt könnyen megduplázzák a JavaScript mennyiségét.
• Szerverválaszidő. Ha a szerver lomhán kezd válaszolni, a frontend-optimalizálás csak kozmetika.

Szakmai feltételezés: a sebesség önmagában ritkán emel pozíciót, sokkal inkább a küszöb alatti állapot húz vissza. Ezért a jó tartomány elérése a cél, nem a százpontos eredmény hajszolása.

Hogyan kezeld a duplikált tartalmat és az URL-káoszt?

Rövid válasz: minden tartalomnak pontosan egy címe legyen, és minden más változat erre mutasson vissza. A duplikáció nem büntetést hoz, hanem szétosztja a jeleket több URL között, így egyik sem lesz elég erős.

A leggyakoribb források: a www és a nem www változat, a http és a https, a záró perjellel és anélkül elérhető cím, a szűrő- és rendezési paraméterek, valamint a hirdetésekből érkező nyomkövető paraméterek. Egy közepes webshopnál nem ritka, hogy néhány száz termék több tízezer URL-en elérhető.

1. Válassz egy kanonikus formátumot, és mindent irányíts át rá 301-gyel.
2. Minden oldalon legyen önhivatkozó kanonikus jelölés: <link rel="canonical" href="https://pelda.hu/termek/">
3. A szűrőparaméteres változatok kanonikusa mutasson az alap kategóriaoldalra, kivéve ha a szűrt nézetnek önálló keresési szándéka van.
4. A sitemap kizárólag indexelhető, 200-as státuszú, kanonikus URL-eket tartalmazzon.
5. Több nyelv esetén a hreflang legyen kölcsönös: ha az A oldal hivatkozik a B-re, a B is hivatkozzon vissza.

Hivatalosan igazolt: a kanonikus jelölés erős jelzés a Google felé, de nem utasítás. Ha a tartalom láthatóan eltér, a Google felülbírálhatja a választásodat.

Milyen strukturált adat kell, és hogyan ellenőrzöd?

Rövid válasz: a strukturált adat nem rangsorolási tényező, viszont ez az a formátum, amiben a legkevesebb félreértéssel adod át a tényeket: ki vagy, mit kínálsz, hol vagy, mikor tartasz nyitva. JSON-LD formában a legegyszerűbb karbantartani.

• Organization vagy LocalBusiness a kezdőlapon: név, cím, telefon, nyitvatartás, közösségi profilok.
• BreadcrumbList a morzsamenühöz, hogy a találatban az útvonal jelenjen meg a nyers URL helyett.
• Product és Offer webshopban, készletinformációval együtt.
• Article a blogbejegyzéseknél, szerzővel és a módosítás dátumával.
• FAQPage a valódi gyakori kérdéseknél, kizárólag akkor, ha a kérdés és a válasz az oldalon látható is.

Ellenőrzés: a Rich Results Test és a Search Console bővítmény-jelentései mutatják, mi érvényes. A Schema.org validátora tágabb, azt is elfogadja, amit a Google nem használ fel megjelenítéshez, de más rendszerek olvashatják.

Saját tapasztalat: a hibás strukturált adat rosszabb, mint a hiányzó. Ha a jelölésben más nyitvatartás, más cím vagy más adat szerepel, mint az oldal látható szövegében, az ellentmondás előbb-utóbb gondot okoz.

Mit jelent a technikai SEO az AI-válaszmotorok korában?

Rövid válasz: ugyanazok az alapok kellenek, plusz két új szempont: a lényeg legyen benne a nyers HTML-ben, és tudatosan döntsd el, mely AI-robotokat engeded be. Az AI-asszisztensek jelentős része nem futtat JavaScriptet úgy, ahogy a Googlebot.

Hivatalosan igazolt: az OpenAI, az Anthropic és a Perplexity is közzéteszi a robotjainak azonosítóit, és azt, hogy a robots.txt szabályait figyelembe veszik. A Google külön Google-Extended tokent ad arra, hogy a tartalmad felhasználható-e a generatív termékeiben, ez független a keresőben való megjelenéstől.

A robots.txt-ben ezekkel az azonosítókkal dolgozol: GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Mindegyikhez külön Allow: / vagy Disallow: / tartozhat, tehát nem kell mindent egyben eldöntened.

Szakmai feltételezés: az idézhetőség szempontjából a szerveroldalon renderelt HTML és a stabil URL fontosabb, mint bármelyik korábbi SEO-korszakban. Ha egy asszisztens egyszer hivatkozott egy oldaladra, az URL megváltoztatása elrontja a hivatkozást, és a rendszer legközelebb jó eséllyel máshonnan idéz. Erre hivatalos megerősítés nincs, a rendszerek működési logikájából következtetek rá.

Milyen sorrendben végezd el a technikai SEO-átvilágítást?

Rövid válasz: alulról felfelé haladj. Először az elérhetőség, aztán az indexelhetőség, végül a sebesség és a gépi értelmezés. Fordított sorrendben dolgozni pazarlás.

1. Nyisd meg a robots.txt-t, és nézd meg, mit tiltasz.
2. Ellenőrizd a fontos oldalak státuszkódját és noindexét az URL-ellenőrzővel.
3. Az indexelési jelentésben kategóriánként írd fel, miért nincs indexelve egy fontos oldal.
4. Vesd össze a sitemapot a valóban létező, kanonikus URL-ekkel.
5. Ellenőrizd a domain-változatokat: www, nem www, http, https, záró perjel. Mind egy helyre kell futnia.
6. Mérj sebességet a három legfontosabb sablonon, és a valós felhasználói adatot nézd, ne csak a labormérést.
7. Nézd meg a mobilnézetet valódi telefonon, ne csak a fejlesztői eszközben.
8. Validáld a strukturált adatot a kulcssablonokon.
9. Térképezd fel a belső linkeket: van-e fontos oldal, amire egyetlen link sem mutat.
10. Két oszlopba írd a hibákat: ami blokkolja az indexelést, és ami csak kellemetlen. Az elsőt javítsd most, a másodikat ütemezd.

Saját tapasztalat: egy tíz-húsz oldalas bemutatkozó weboldalon ez a lista egy nap alatt végigmegy, egy nagyobb webshopon inkább egy hét. A súlyos hibák többsége már az első öt pontban kiderül.

Források és további olvasnivalók

• Google Search Central: Search Essentials, valamint a feltérképezés és indexelés dokumentációja
• Google Search Console súgó: Oldalindexelés jelentés és URL-ellenőrző eszköz
• web.dev: Core Web Vitals (LCP, INP, CLS) mérőszámok leírása
• Chrome User Experience Report (CrUX) dokumentáció
• Schema.org: típusok és tulajdonságok hivatalos referenciája
• Google Search Central: strukturált adatok általános irányelvei és a Rich Results Test
• OpenAI: GPTBot dokumentáció
• Anthropic: ClaudeBot és a webes feltérképezésre vonatkozó tájékoztató
• W3C: HTML szabvány és a WCAG akadálymentességi irányelvek
• RFC 9309: Robots Exclusion Protocol