Technikai SEO audit lépésről lépésre: a teljes 2026-os checklista

A „technikai SEO audit” a szakma egyik legjobban misztifikált szolgáltatása — pedig a diagnosztikai része nagyrészt ingyenes eszközökkel, saját kézzel elvégezhető. Ez a checklista pontosan ezt adja: öt lépésben végigmegyünk azon, mit kell ellenőrizni, mivel, és mi számít valódi hibának — a Google saját, hivatalos dokumentációja alapján, nem SEO-folklór szerint. Közben leleplezünk néhány makacs tévhitet is, amelyekre kár pénzt költeni. Ez a cikk a teljes SEO-útmutatónk technikai fejezetének mélyfúrása — ott a stratégia, itt a szerszámosláda.

Mit követel valójában a Google? A három minimális feltétel

Mielőtt bármilyen 200 pontos auditlistának nekiesne: a Google hivatalos dokumentációja szerint egy oldal indexeléséhez mindössze három technikai feltételnek kell teljesülnie:

• A Googlebot nincs kitiltva — sem a robots.txt, sem a szerver nem blokkolja.
• Az oldal működik — a szerver HTTP 200-as (sikeres) választ ad rá.
• Van indexelhető tartalma — szöveges, a Google számára olvasható tartalom.

Ez a keret adja az audit priorizálását is: ami e három egyikét sérti, az „azonnal javítandó” — minden más (sebesség, strukturált adat, belső linkek) már optimalizálás, amely a versenyben segít, de a láthatóság alapját nem dönti el. Jó hír: a három alapfeltétel ellenőrzése percek kérdése.

1. lépés: Indexelés és feltérképezés — látja-e egyáltalán a Google az oldalát?

Az első állomás a Google Search Console Oldalindexelés (Page indexing) riportja: itt látszik, mely oldalak vannak bent az indexben, és melyek miért nem. És itt jön az első tévhitleleplezés: a két leggyakrabban rettegett státusz — „Feltérképezve – jelenleg nincs indexelve” és „Felfedezve – jelenleg nincs indexelve” — a Google súgója szerint nem hiba. Az előbbinél a hivatalos útmutatás szó szerint az, hogy nem kell újra beküldeni; az utóbbi jellemzően csak annyit jelent, hogy a Google átütemezte a feltérképezést. Sőt, a Google azt is kimondja: ne várja, hogy a webhely minden oldala indexelve legyen — a 100%-os indexeltség nem cél, hanem mítosz.

A klasszikus — és máig leggyakoribb — technikai öngól a robots.txt és a noindex összekeverése. A robots.txt a feltérképezést szabályozza, nem az indexelést: a Google hivatalosan kimondja, hogy nem eszköz arra, hogy egy oldal kimaradjon a találatok közül — a tiltott oldal külső linkek révén akár tartalom nélkül is indexelődhet. Kiindexelésre a noindex való, de vigyázat, a csapda: a noindex csak akkor működik, ha a robots.txt *nem* tiltja az oldalt — különben a Google sosem látja magát a noindex utasítást. Auditnál tehát két kérdés: tilt-e a robots.txt olyat, amit nem kellene (fő tartalom, CSS/JS), és nincs-e noindex olyan oldalon, amelynek rangsorolnia kellene.

A sitemap körüli túlzások is megérnek egy bekezdést. A hivatalos szabályok: fájlonként legfeljebb 50 000 URL vagy 50 MB; a <priority> és <changefreq> mezőket a Google egyszerűen ignorálja — kár velük bíbelődni —, a <lastmod>-ot pedig csak akkor veszi figyelembe, ha következetesen pontos. (Ha a sitemap-generátor minden nap minden URL-re friss dátumot ír, a Google eldobja a jelzést.) A sitemap egyébként nem rangsor-tényező, hanem felfedezési segédlet: beküldeni a Search Console-ban kell, és a riportban látszik, hibamentes-e.

A duplikáció-kezelés alapja a canonical — és itt is hivatalos árnyalat: a rel=canonical a Google szavaival „jelzés, nem szabály” (hint), amelyet felül is bírálhat. A jelzések erősorrendje: átirányítás (erős) → rel=canonical (erős) → sitemap-szerepeltetés (gyenge). Ehhez tartozik a 30 másodperces házi teszt: írja be az oldalát mind a négy változatban (http/https × www/nem-www) — mindnek egyetlen HTTPS-változatra kell 301-gyel átirányítania. A láncolt átirányításokra is figyeljen: a Googlebot legfeljebb 10 ugrást követ, a hivatalos ajánlás viszont legfeljebb 3. A 404-től pedig nem kell félni: a Google szerint a hiányzó oldal természetes, önmagában nem árt — a soft 404 viszont valódi hiba (amikor a „nincs találat” oldal 200-as kóddal érkezik), ezt a Search Console külön jelzi.

2. lépés: Sebesség és Core Web Vitals — a valóságban elég gyors?

A sebességmérés hivatalos kerete 2026-ban is a három Core Web Vitals metrika, változatlan küszöbökkel: LCP ≤ 2,5 mp (a fő tartalom betöltése), INP ≤ 200 ms (az interakciók válaszideje — 2024 márciusa óta ez váltotta fel a FID-et), CLS ≤ 0,1 (vizuális stabilitás, azaz semmi ne ugráljon). A minősítés a valós látogatók 75. percentilisén dől el, mobilra és desktopra külön. A 2025–2026-ban SEO-blogokon terjedő „új 2026-os metrikákról” szóló hírek forrás nélküliek — a hivatalos küszöbökben nem történt változás.

A legfontosabb fogalmi tisztázás: a rangsoroláshoz a valós felhasználói (field) adat számít — a Chrome-felhasználók előző 28 napjának mérése (CrUX) —, nem a Lighthouse-pontszám. A PageSpeed Insights felül mutatja a field-adatot (ez a lényeg), alul a laboreredményt (ez csak diagnosztika). A tanulság kétirányú: a 100-as Lighthouse-pont hajszolása öncél, egy 85 pontos, de valóságban gyors oldal tökéletesen rendben van; kisebb magyar oldalaknál viszont gyakran nincs elég forgalom a field-adathoz — ilyenkor a laboradatból kell dolgozni, tudva, hogy az szigorúbb a valóságnál.

És a CWV valódi súlya? A Google saját megfogalmazása kijózanító: a Core Web Vitalst „használják a rangsorolási rendszerek”, de „a Google mindig a legrelevánsabb tartalmat igyekszik megjeleníteni — akkor is, ha az oldalélmény gyengébb”, és a jó eredmény nem garantál helyezést. Vagyis a sebesség döntetlen-eldöntő tényező és konverziós kérdés, nem csodafegyver. (Iparági adatként: 2025 őszén a weboldalak nagyjából fele — más mérésekben 40–50% közötti aránya — ment át a mobilos CWV-vizsgán (HTTP Archive/DebugBear), tehát aki átmegy, máris a jobbik felében van.) A leggyakoribb KKV-szintű hibák, amiket az audit során keresni kell:

• Lazy-load a hero-képen — a hajtás feletti fő képet soha ne késleltesse — ez az első számú LCP-gyilkos.
• Méret nélküli képek és beúszó elemek — a width/height nélküli kép, az utólag betöltődő banner és cookie-sáv okozza a CLS-t.
• Widget- és mérőkód-halmozás — chat, pixel, heatmap, videó-embed: mind a fő szálat terheli, ez rontja az INP-t.
• Lassú szerverválasz (TTFB) — gyakran nem a kód, hanem az olcsó tárhely a szűk keresztmetszet; ezt a PageSpeed Insights külön jelzi.

Két gyors alapellenőrzés zárja ezt a lépést: mobil — a mobile-first indexelés 2023 októbere óta teljes, tehát ami mobilon nincs a lapon, az a Google számára nem létezik (ellenőrzés: nyissa meg telefonon, és nézze meg, minden fontos tartalom elérhető-e); HTTPS — 2014 óta hivatalos, de a Google szerint „nagyon könnyűsúlyú” rangsorjelzés, 2026-ban egyszerűen alapkövetelmény: vegyes (http-s) tartalom és lejárt tanúsítvány ne legyen.

3. lépés: On-page technika és strukturált adat — amit a Google 2026-ban tényleg használ

A title továbbra is a legerősebb on-page elem — a Google utolsó hivatalos közlése szerint (2021) az esetek ~87%-ában a lap saját <title>-jét használja a találati oldali címhez, a maradéknál átírja (jellemzően a túl hosszú, kulcsszóhalmozó vagy generikus címeket). A meta description szerepe szerényebb: a Google a snippetet elsősorban az oldal tartalmából generálja, és a meta leírást csak akkor használja, ha az pontosabb — egy nagy SEO-eszközgyártó 2020-as mérése szerint nagyjából az esetek kétharmadában át is írja. Hivatalos karakterlimit egyikre sincs; az iparági ökölszabály (title ~50–60, description ~150–160 karakter) a képernyőlevágást követi, nem Google-szabály. Az audit-teendő: minden fontos oldalnak legyen egyedi, pontos title-je és leírása — a duplikáltakat a Screaming Frog percek alatt kilistázza.

Két gyorsan letudható tévhit: a heading-hierarchia (H1–H6) sorrendje és darabszáma a Google hivatalos kezdőútmutatója szerint rangsorolási szempontból nem számít — az olvasó és az akadálymentesség szempontjából, illetve title-forrásként viszont igen, tehát a rendezett szerkezet nem felesleges, csak nem rangsorvarázslat. Az alt szöveg fő terepe pedig a Google Képek: a képi találatokhoz és a kontextushoz járul hozzá — írjon tömör, leíró alt-ot, de a kulcsszóhalmozás itt spamjelzés lehet.

A belső linkelés technikai oldala annál fontosabb: a Google az új oldalak túlnyomó többségét linkeken keresztül találja meg, tehát az árva oldal (amire semmi nem mutat) gyakorlatilag láthatatlan. Az audit során a Screaming Frog „inlinks” nézetében keresse a 0 belső linkkel rendelkező oldalakat, és nézze a kattintási mélységet is — a fontos oldalak a főoldaltól lehetőleg 2–3 kattintáson belül legyenek (ez utóbbi Google-munkatársi iránymutatás, nem dokumentáció).

A strukturált adatnál 2026-ban a legfontosabb tudnivaló az, hogy mi él még. A rich result-leépítés idővonala: a HowTo 2023-ban, a sitelinks keresődoboz 2024 novemberében tűnt el, 2025-ben több ritka típus (becsült fizetés, oktatóvideó stb.) került kivezetésre — és a FAQ rich result 2026. május 7. óta egyáltalán nem jelenik meg a találati oldalon. Ami egy magyar KKV-nak ma valóban számít: Organization, LocalBusiness (a Google Cégprofillal párban), Product/Offer webshopnak, Article a blognak, BreadcrumbList és a Review snippet. Két árnyalat: a strukturált adat jogosulttá tesz a megjelenésre, de nem garantálja, és önmagában nem rangsortényező; a bent maradt halott markup (pl. régi FAQ-séma) pedig nem árt — csak nem csinál semmit. Ellenőrzés: Rich Results Test + a Search Console rich result riportjai.

A duplikált tartalomról végül: olyan, hogy „duplikált tartalom büntetés”, a Google szerint nincs. A valódi tét az, hogy a szétforgácsolt változatok (paraméteres URL-ek, http/https, www-variánsok, szűrő-oldalak) egymás elől szívják el a jelzéseket — a megoldás a konszolidáció: 301-es átirányítás vagy canonical az elsődleges változatra.

4. lépés: Az AI-réteg — ezt adja hozzá az audithoz 2026-ban

Az audit 2026-os, új fejezete az AI-asszisztensek láthatósága — és itt egy technikai tény mindent meghatároz: a mérések szerint (Vercel+MERJ) a legtöbb AI-crawler nem futtat JavaScriptet. A GPTBot (OpenAI), a ClaudeBot (Anthropic) és a PerplexityBot letölti, de nem hajtja végre a JS-t — a Gemini a Googlebot-infrastruktúrán renderel, így kivétel. A gyakorlati teszt egyszerű: nézze meg az oldala forráskódját (view source vagy kikapcsolt JavaScripttel) — ha az árak, a leírások és a kapcsolati adatok nincsenek benne a nyers HTML-ben, akkor a ChatGPT, a Claude és a Perplexity számára láthatatlanok. Ez a kliensoldalon renderelt oldalak (rosszul konfigurált SPA-k) legnagyobb 2026-os kockázata.

A ChatGPT-láthatóság technikai útja kettős: engedje az OAI-SearchBotot, és legyen bent a Bing indexében — az OpenAI dokumentált keresőpartnere ugyanis a Bing (saját indexet is épít, de a Bing a nevesített útvonal). Ehhez a Bing Webmaster Tools ingyenes: sitemap-beküldés, napi 10 000 URL manuális beküldése, beépített technikai audit (Site Scan) — és IndexNow-támogatás, amellyel az új/módosult URL-ek azonnal bejelenthetők a Bingnek és társainak (a Google nem vesz részt benne, oda marad a sitemap). Tapasztalatunk szerint a magyar oldalak a Bing-vonalat jellemzően teljesen elhanyagolják — 2026-ban ez már AI-láthatósági hiba.

És az llms.txt? Őszintén: a Google 2026. júniusi hivatalos közlése szerint a Google-kereséshez nem kell, a láthatóságot se nem javítja, se nem rontja — az elterjedtsége a teljes weben ~2% (Web Almanac 2025). Feltölteni pár perc, és nem árt, de aki „AI-optimalizálási csomagként” árulja, az túlígér. A Google az AI-megjelenésekről is egyértelmű: az AI Overviews-hoz és az AI Mode-hoz semmilyen külön fájl, markup vagy séma nem kell — a feltétel az indexelt, snippet-képes oldal, vagyis pontosan az, amit e checklista 1–3. lépése rendbe tesz. (Az AI Overviews itthon egyelőre nem él, a Google AI Mode viszont igen — a teljes képet a GEO-útmutatónkban találja.)

Az ingyenes eszköztár egy táblában

5. lépés: Priorizálás — mit javítson azonnal, és mikor hívjon szakembert?

1. Azonnal javítandó: ami a három minimális követelményt sérti — kitiltott Googlebot, 5xx-hibák, noindex a fő oldalakon, feltörés/spam. Ezek láthatóság-gyilkosok.
2. Fontos (heteken belül): soft 404-ek, redirect-láncok, duplikáció-konszolidáció, bukott Core Web Vitals a kulcsoldalakon, hiányzó mobiltartalom.
3. Finomhangolás (folyamatos): strukturált adat bővítése, belső linkek és horgonyszövegek, title/meta-csiszolás, alt szövegek, Bing/IndexNow-réteg.

Milyen gyakran? Hivatalos szabály nincs — a mi módszertani ajánlásunk: negyedévente egy gyors átvilágítás (a fenti eszköztárral 1–2 óra), havonta egy pillantás a Search Console-ra, és kötelezően teljes audit minden átalakítás, migráció vagy redesign után — tapasztalatunk szerint a láthatósági katasztrófák túlnyomó része ilyenkor születik. Arról, hogy mennyi idő alatt látható a SEO eredménye, külön cikkben írtunk — a technikai javítások jellemzően a leggyorsabban ható beavatkozások.

És a határvonal: a diagnózis DIY, a beavatkozás egy szinten túl nem. Bátran csinálja maga: a riportok olvasását, a sitemap-beküldést, a title/meta-írást, a képméretezést, a felesleges widgetek gyérítését, a schemát SEO-bővítménnyel. Szakembert hívjon: a robots.txt és a szerverkonfiguráció módosításához, tömeges 301-átirányításhoz, a renderelés átalakításához (CSR→SSR) és a CWV-mérnöki munkához (TTFB, long task-debug). Az ökölszabály: ha egy beavatkozás egyetlen fájllal az egész site láthatóságát el tudja rontani, az nem kísérletezős terep — a pontos diagnózissal viszont a szakembernek is kevesebbet fizet.

Nálunk ez a szolgáltatás kiírt áron él: a Technikai SEO Sprint (190 000 Ft, egyszeri) a fenti lista mérnöki magját fedi — Core Web Vitals, schema/JSON-LD, sitemap és indexelés, belső linkstruktúra, meta-adatok, GA4 + Search Console bekötés. (A nagyobb átépítések — például egy renderelés-átalakítás vagy teljes migráció — külön fejlesztési munkák, ezt előre megmondjuk.) A SEO Foundation (290 000 Ft, egyszeri) ugyanezt a kulcsszó- és tartalomstratégiával együtt adja — ez a havi együttműködésünk belépője. Árak nettóban, +ÁFA; a teljes listát az árainknál találja, a szolgáltatás részleteit a SEO-oldalunkon.

A technikai SEO nem varázslat, hanem higiénia: a Google három dolgot követel, minden más versenyelőny. A diagnózist ingyen elvégezheti — mi ott lépünk be, ahol a javítás már kódot és szervert érint.

Ha végigment a checklistán, és a Search Console-ban olyan hibákat lát, amelyeket nem tud hova tenni — vagy csak szeretné, hogy egy második szempár is átnézze —, írjon nekünk: megmondjuk, mi az, amit ebből a listából maga is megold, és mi az, amiért érdemes fizetnie.