Technikai SEO ellenőrzés: öt lépés KKV-weboldalakhoz

Egy rövid technikai ellenőrzés segít felismerni az alapvető hibákat. Ez nem helyettesít minden részletes auditot: a vizsgálat terjedelme az oldal méretétől, működésétől és a talált problémától függ. A következő öt lépés megmutatja, hol kezdjen, mivel ellenőrizzen és mikor szükséges mélyebb diagnózis. A stratégiai hátteret a teljes SEO-útmutató adja.

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.

A technikai minimum ellenőrzése elsődleges, de nem helyettesíti a felfedezhetőség vizsgálatát. A fontos URL-hez vezető belső link hiánya vagy hibája már az alapláthatóságot is akadályozhatja. A sitemap segédlet; az indexelhetőség pedig nem jelent garantált indexelést vagy helyezést.

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: a Search Console-ban érdemes beküldeni, mert a riportban követhető a feldolgozása. A Google robots.txt-hivatkozással vagy API-n keresztül is fogad sitemapet.

A canonical az elsődleges változatra adott jelzés, nem megváltoztathatatlan utasítás. Ellenőrizze a http/https és www/nem-www címeket: a kiválasztott HTTPS-változat adjon 200-as választ, a többi közvetlenül arra vezessen. Tartós költözésnél a Google a 301 és 308 szerveroldali átirányítást is kezeli. Kerülje a hurkot és a szükségtelen láncot; csak releváns célra irányítson. A valóban megszűnt tartalom helyes 404/410 válasza jobb, mint minden cím főoldalra küldése.

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

A Core Web Vitals a valós használat betöltését, válaszkészségét és vizuális stabilitását méri. A jelenlegi jó küszöbök: LCP ≤ 2,5 mp, INP ≤ 200 ms, CLS ≤ 0,1, a megtekintések 75. percentilisén. A mobil- és asztali adatot külön vizsgálja; a web.dev hivatalos útmutatója részletezi a mutatókat. A metrikánkénti okokat, a magyar valós adatokat és a javítási sorrendet külön Core Web Vitals-cikkünk tárgyalja.

A PageSpeed Insights a rendelkezésre álló valós használati adatot és a laborfuttatást külön mutatja. A laboradat hibakeresésre alkalmas; a valós mérés a látogatók élményét írja le. Kis forgalomnál lehet, hogy nincs elég valós adat. A labor nem szükségszerűen szigorúbb vagy enyhébb: a beállítása és a tényleges látogatói helyzet eltérhet.

A jó sebesség fontos használhatósági alap, de nem garantál helyezést vagy konverziós növekedést. A hibát a valós oldalon kell megkeresni. Tipikus vizsgálati pontok:

• A fő kép késleltetése: a betöltést meghatározó, azonnal látható képet ne lustán töltse be.
• Elmozduló tartalom: a képeknek és beágyazásoknak előre foglaljon helyet.
• Sok külső szkript: mérje meg, melyik widget vagy kód terheli az interakciókat.
• Lassú szerverválasz: a tárhely, az alkalmazás és a gyorsítótárazás is lehet ok; a mérés döntse el.

Mobilon ellenőrizze a teljes fontos tartalmat és a használati folyamatot. A HTTPS-t, tanúsítványt és a vegyes tartalmat is vizsgálja. Ezeket ne puszta rangsortrükknek, hanem megbízható használati alapnak tekintse.

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

Minden fontos oldalnak legyen egyedi, pontos címe és leírása. A Google a találati címet és részletet több forrásból állíthatja össze, ezért a saját szöveg nem garantált megjelenés. Karakterszám hajszolása helyett a lényeg legyen korán, a tartalom pedig feleljen meg a keresési szándéknak.

A címsorok logikus hierarchiája segíti az áttekintést és az akadálymentes navigációt; ne a darabszámot tekintse rangsorreceptnek. Az alt szöveg a kép jelentését adja át annak is, aki nem látja a képet, és a képi keresés megértését is segítheti. A fontos képhez a helyzetéhez illő, tömör leírás kell; a pusztán dekoratív kép üres altot kaphat. Kulcsszóhalmozás helyett a kép feladatát írja le.

A belső linkek segítik az oldalak felfedezését és a látogatói tájékozódást. Keresse az árva fontos URL-eket, a törött hivatkozásokat és a túl nehezen elérhető tartalmat. Az árva URL más módon még felfedezhető lehet, de a hiányzó belső kapcsolat valódi javítási feladat.

A strukturált adat a látható tartalmat írja le pontosan, és kövesse az adott típus aktuális feltételeit. A használható megjelenéseket a Google támogatott strukturáltadat-galériájában ellenőrizze. Egy érvényes schema nem biztosít gazdag találatot vagy jobb rangsort; a GYIK elsősorban az olvasónak legyen hasznos.

A párhuzamos URL-változatok kezelésénél azt döntse el, melyik maradjon elérhető. Végleges költözéshez megfelelő tartós átirányítás, együtt élő hasonló változatoknál következetes canonical lehet indokolt. Nem minden duplikáció igényel átirányítást, és nem minden törölt oldalnak van releváns utódja.

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

A fontos tartalmat az eredeti HTML-ben is ellenőrizze. Ha csak kliensoldali futtatás után áll össze, bizonyos keresők és robotok nehezebben érhetik el. A robotképességek változhatnak: a hozzáférést konkrét szolgáltatói dokumentációval és tényleges lekéréssel vizsgálja, ne egy örök „minden AI-bot” szabállyal.

Az OpenAI botdokumentációja elkülöníti a keresést és a modellfejlesztési célú feltérképezést. A robotengedély mellett a CDN vagy tűzfal is akadályozhatja a lekérést. A Bing-jelenlét ellenőrzése hasznos lehet, de nem általános előfeltétele és nem garanciája a ChatGPT-idézésnek.

A Google AI-dokumentációja nem ír elő külön llms.txt fájlt vagy speciális AI-sémát. A Google AI-áttekintése Magyarországon és magyarul is elérhető; az egyes kereséseknél történő megjelenés nem garantált. A fogalmakat a GEO-útmutató rendezi.

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

A Google URL-ellenőrzési súgója különíti el az élő és indexelt adatot. A strukturáltadat-eszközök leírása megmutatja a Rich Results Test és az általános Schema Markup Validator eltérő célját.

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

1. Elsőként: hibás hozzáférés, 5xx-válasz, véletlen noindex, feltört tartalom, fontos URL-hez vezető hiányzó vagy törött link.
2. Ezután: rossz átirányítás, canonical-ellentmondás, hiányzó mobiltartalom, a kulcsoldalak súlyos sebesség- vagy használati hibája.
3. Majd: title/leírás, releváns strukturált adat, tartalmi szerkezet és mérés finomítása. A sorrendet az üzleti hatás módosíthatja.

Az ellenőrzés gyakoriságát a változásokhoz és az oldal üzleti szerepéhez igazítsa. A mi kiinduló ajánlásunk rendszeres Search Console-áttekintés és időszakos technikai ellenőrzés; nagyobb költözésnél vagy átalakításnál előtte–utána külön vizsgálat. A szükséges idő nem fix. A SEO eredményének időtávját külön kezelje az elvégzett javítás ellenőrzésétől.

É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. Ilyenkor a weboldal-felújítás vagy egy új weboldal a kiindulópont, és 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.

Először a fontos oldalak elérhetőségét, tartalmát és használhatóságát vizsgálja. A javítás sorrendjét a konkrét hiba és az üzleti hatás adja.

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.