A „technikai weboldal audit" kifejezésre jellemzően három helyzetben keres valaki. Vagy leesett a forgalom és nem érthető, miért. Vagy új oldalt kapott, vett át, esetleg örökölt egy fejlesztőtől, és tudni szeretné, mi van benne. Vagy ajánlatot kért valakitől, és meg akarja érteni, mit is fog pontosan kapni. Ez a cikk mind a háromra igyekszik választ adni, konkrétan és sorrendben: mit vizsgálj, mivel, milyen sorrendben, és mit kezdj a végén az eredménnyel.
Mi az a technikai weboldal audit, és mit vizsgál pontosan?
Rövid válasz: a technikai weboldal audit egy strukturált átvizsgálás, amely azt méri fel, hogy a keresőmotorok és az AI-alapú válaszmotorok képesek-e akadálytalanul elérni, feltérképezni, értelmezni és indexelni az oldalaidat, és hogy a látogató gyorsan, hibamentesen tudja-e használni az oldalt. Nem tartalmi és nem linképítési vizsgálat: azt nézi, hogy a technikai alap nem gátolja-e a többit.
Tovább a témában: Technikai SEO audit Szeged · Technikai SEO audit Szombathely
Egy teljes technikai audit jellemzően ezeket a területeket fedi le:
- Elérhetőség és indexelhetőség: robots.txt, noindex meta címkék, HTTP státuszkódok, canonical jelzések, sitemap.
- Feltérképezhetőség: belső linkstruktúra, kattintási mélység, árva oldalak, végtelen paraméteres URL-ek.
- Renderelés: mit lát a robot, ha nem futtat JavaScriptet, vagy ha korlátozottan futtat.
- Sebesség és stabilitás: Core Web Vitals mérőszámok, szerverválasz-idő, képkezelés, gyorsítótárazás.
- Mobil használhatóság: mobilnézet, érintési célpontok, olvashatóság.
- Strukturált adatok: Schema.org jelölés helyessége és lefedettsége.
- Biztonság és domain-higiénia: HTTPS, kevert tartalom, átirányítási láncok, duplikált domain-változatok.
Érdemes tisztázni azt is, amit a technikai audit nem csinál meg helyetted: nem ír tartalmat, nem választ kulcsszót, és nem szerez külső hivatkozásokat. A technikai réteg olyan, mint az út a bolthoz: attól még nem lesz jó az üzlet, hogy odavezet út, viszont út nélkül senki nem ér oda. Saját tapasztalat: a leggyakoribb csalódás abból származik, hogy valaki technikai auditot rendel, kijavít mindent, aztán nem érti, miért nem előzte meg azt a versenytársat, akinek háromszor annyi és sokkal alaposabb tartalma van ugyanarra a témára.
Mikor van értelme technikai auditot csinálni?
Rövid válasz: akkor, ha változás történt (új oldal, migráció, tárhelycsere, sablonváltás), ha váratlanul esett a megjelenések vagy a kattintások száma, vagy ha éppen komolyabb tartalmi és hirdetési munkát indítanál, és nem akarsz jó tartalmat rossz alapra tenni.
A tipikus kiváltó helyzetek:
- Új weboldal indulása után egy-két héttel, amikor már van mit indexelni.
- Domain- vagy URL-szerkezet-váltás, tárhelycsere, sablonváltás után.
- Ha a Search Console megjelenés-görbéje néhány nap alatt tört meg, nem lassan csúszott le.
- Ha az új aloldalaid hetek óta nem jelennek meg a keresőben.
- Ha átvettél valaki más oldalát, és nem tudod, mi van a motorháztető alatt.
Saját tapasztalat: a legdrágább hibák nem az elhanyagolt oldalakon keletkeznek, hanem közvetlenül egy fejlesztés után. Egy fejlesztői környezetből átemelt noindex címke, egy ottfelejtett Disallow: / sor a robots.txt-ben, vagy egy migrációnál nem átvezetett átirányítási térkép heteken belül látványosan visszaveti az oldalt. Ezek jellemzően perceken belül javíthatók, ha valaki egyáltalán megnézi őket.
Rendszeres ütemre is érdemes gondolni. Egy folyamatosan szerkesztett oldalnál a negyedéves átnézés reális kompromisszum, egy ritkán változó bemutatkozó oldalnál a féléves is elég lehet. A lényeg, hogy legyen fix időpont, mert az „majd ha baj lesz" alapon végzett ellenőrzés mindig későn érkezik.
Milyen eszközökkel tudod magad is elkezdeni?
Rövid válasz: a hibák nagy részét megtalálod a Google Search Console, a Bing Webmaster Tools, egy asztali crawler ingyenes rétege és a böngésző fejlesztői eszközei kombinációjával, fizetős szakértői platform nélkül is.
Az alap eszközkészlet:
- Google Search Console: az Oldalak (indexelés) jelentés, az URL-ellenőrző eszköz és a Core Web Vitals riport. Ez az egyetlen forrás, amely magától a keresőtől mondja meg, mit lát az oldaladból.
- Bing Webmaster Tools: külön beállítást igényel, viszont saját crawl-hibalistát és kulcsszóadatokat ad. Hivatalosan igazolt: a Microsoft dokumentációja szerint a Bing indexe több AI-asszisztens keresési rétegét is kiszolgálja, tehát nem csak a Bing felületéért érdemes figyelni rá.
- Crawler: a Screaming Frog SEO Spider ingyenes változata néhány száz URL-ig térképezi fel az oldalt, ami kisebb weboldalnál teljes lefedettséget jelent.
- PageSpeed Insights és Lighthouse: sebesség és technikai jelzések, laborból és valós felhasználói adatból egyaránt.
- Rich Results Test és a Schema.org validátor: a strukturált adatok ellenőrzéséhez.
Hogyan néz ki egy technikai audit lépésről lépésre?
Rövid válasz: mindig kívülről befelé haladj. Először azt nézd meg, hogy egyáltalán elérhető és indexelhető-e az oldal, aztán hogy feltérképezhető-e, és csak ezután foglalkozz a finomításokkal. Fordított sorrendben könnyű heteket elpazarolni sebességoptimalizálásra egy olyan aloldalon, amit a kereső egyáltalán nem indexel.
1. Indexelhetőség és elérhetőség
Nyisd meg a domain.hu/robots.txt fájlt, és olvasd el soronként. A leggyakoribb végzetes hiba így néz ki:
User-agent: *
Disallow: /
Ez minden robotot kizár a teljes oldalról. Ezután nézd meg néhány kulcsoldal forráskódjában, van-e bennük <meta name="robots" content="noindex">. WordPress esetén a Beállítások / Olvasás menüpont „Keresőmotorok láthatósága" jelölőnégyzete pontosan ezt kapcsolja be, és sok oldalon évekig bekapcsolva marad egy indulás utáni tesztfázisból. Gyors kontroll: írd be a keresőbe a site:domain.hu lekérdezést, és hasonlítsd össze a kapott nagyságrendet azzal, amit vársz.
2. Feltérképezés és belső struktúra
Futtass egy teljes crawlt, majd három dolgot nézz meg benne: milyen státuszkódot ad minden URL, hány kattintásra van a fő tartalom a kezdőlaptól, és van-e olyan oldal, amire semmi nem hivatkozik belülről. Az árva oldalakat úgy találod meg, hogy a crawl eredményét összeveted a sitemap tartalmával: ami a sitemapben szerepel, de a crawlban nem jött elő, arra belső link sem mutat. Saját tapasztalat: a négy kattintásnál mélyebbre került fontos aloldalak jellemzően rosszabbul teljesítenek, és a javításuk gyakran csak annyi, hogy néhány releváns helyről linket kapnak.
3. Átirányítások és domain-változatok
Ellenőrizd, hogy a http://, a https://, a www és a www nélküli változat mind egyetlen kanonikus címre mutat-e, egyetlen 301-es lépésben. Parancssorból ez egy sor:
curl -sIL http://domain.hu | grep -i "HTTP/\|location"
Ha három-négy lépcsőt látsz egyetlen kezdőlap-betöltésre, akkor van mit egyszerűsíteni: a láncok lassítanak és felesleges kockázatot visznek a rendszerbe.
4. Renderelés
Kapcsold ki a JavaScriptet a böngésződben, és tölts be egy fontos aloldalt. Ha üres képernyőt látsz, akkor a tartalom kizárólag kliensoldali futtatásból áll elő. Ugyanezt ellenőrizheted a forráskód megjelenítésével is: keress rá a szövegben egy jellemző mondatra, és nézd meg, benne van-e a szerver által küldött HTML-ben. A Google ezt jellemzően kezeli, de késleltetéssel. Szakmai feltételezés: az AI-válaszmotorok crawlerei nagy részben korlátozottabban vagy egyáltalán nem futtatnak JavaScriptet, ezért a szerveroldali renderelés vagy az előrenderelés jelentősége nőtt.
5. Sebesség és Core Web Vitals
Ne egyetlen oldalt mérj, hanem sablononként egyet: kezdőlap, kategória, cikk, termék, kapcsolat. A leggyakoribb reális beavatkozások: modern képformátum és méretezés, a betöltést blokkoló szkriptek halasztása, szerveroldali gyorsítótár, és a képek méretarányának rögzítése az elrendezés-elmozdulás ellen.
6. Strukturált adatok
Nézd meg, hogy a fő oldaltípusokon van-e érvényes JSON-LD jelölés. Egy helyi szolgáltatónál minimum ennyi legyen jelen:
{ "@context": "https://schema.org", "@type": "LocalBusiness", "name": "...", "address": {...}, "telephone": "...", "openingHours": "..." }
Cikkeknél Article vagy BlogPosting, GYIK-szekciónál FAQPage, terméknél Product. Hivatalosan igazolt: a Google dokumentációja szerint a strukturált adat önmagában nem rangsorolási tényező, viszont feltétele bizonyos találati megjelenéseknek.
7. Naplóelemzés
Ha hozzáférsz a szerver hozzáférési naplójához, nézd meg, mely robotok járnak az oldalon és milyen gyakran. Ez mutatja meg, hogy a keresők és az AI-crawlerek valóban elérik-e a fontos oldalakat, vagy az idejük nagy részét paraméteres, értéktelen URL-eken töltik.
Gyors ellenőrzőlista, ha csak egy órád van
- robots.txt elolvasása soronként.
- Három kulcsoldal forráskódjában
noindexkeresése. site:lekérdezés nagyságrendi ellenőrzésre.- Search Console indexelési jelentés: mi a legnagyobb „nincs indexelve" kategória.
- A négy domain-változat átirányításának ellenőrzése.
- Egy fontos aloldal betöltése JavaScript nélkül.
- PageSpeed mérés mobilon, két különböző sablonon.
- Sitemap megnyitása: friss-e, vannak-e benne törölt oldalak.
Mit nézz meg webshopnál, amit egy bemutatkozó oldalnál nem?
Rövid válasz: webshopnál a technikai audit súlypontja átkerül a duplikációra és a feltérképezési kapacitásra, mert a szűrők és a rendezések önmagukban több tízezer felesleges URL-t tudnak generálni.
Amit egy néhány oldalas bemutatkozó weboldalnál ki lehet hagyni, itt viszont nem:
- Paraméteres URL-ek: szín, méret, ár szerinti szűrés és rendezés. Döntsd el, melyik változat indexelhető, a többit canonical jelzéssel vagy tiltással kezeld.
- Lapozás: a második, harmadik oldal önálló, elérhető URL legyen, ne csak a görgetésre betöltő lista.
- Elfogyott és megszűnt termékek: előre eldöntött szabály kell rá, nem esetenkénti döntés.
- Készlet és ár a strukturált adatban: ha eltér attól, ami az oldalon látszik, az hibás megjelenéshez vezethet.
- Kereső-találati oldalak: a belső keresés eredményoldalait jellemzően nem érdemes indexeltetni.
Mit változtatott a technikai auditon az AI-keresés?
Rövid válasz: az alapok nem változtak, de három tényező súlya érezhetően nőtt: a szerveroldali elérhető tartalom, az URL-ek stabilitása és a gépi olvashatóság.
Az AI-válaszmotorok kétféleképpen érnek el téged: vagy egy indexből dolgoznak, vagy valós időben lekérik az oldalt. Mindkét úthoz az kell, hogy a válasz szempontjából lényeges információ már a szerver által küldött HTML-ben benne legyen, ne csak a felhasználói kattintás után jelenjen meg. Saját tapasztalat: a harmonikába, fülekbe vagy csak kattintásra betöltő szekcióba rejtett tartalom akkor jár jól, ha a HTML-ben eleve ott van, és csak a megjelenítése rejtett.
A robots.txt szerepe is bővült: külön sorokban lehet engedélyezni vagy tiltani az AI-crawlereket. Ez üzleti döntés, nem technikai: a tiltás csökkenti a szerverterhelést és az elemzésre kerülő tartalom mennyiségét, viszont az idézhetőség esélyét is. Szakmai feltételezés: a legtöbb kis- és középvállalkozásnál a nyitottság hoz több hasznot, mert a felismerhetőségért folyó verseny most alakul ki.
Melyek a leggyakoribb technikai hibák a magyar oldalakon?
Rövid válasz: a legtöbb probléma nem egzotikus, hanem néhány visszatérő, gyorsan javítható típushiba.
- Bent felejtett
noindexvagy tiltó robots.txt egy fejlesztés után. - Migráció után hiányzó átirányítások, tömeges 404-es oldalakkal.
- Ugyanaz a tartalom több URL-en, canonical jelzés nélkül (paraméteres, szűrős, nyomtatható változatok).
- Több megabájtos, eredeti méretű képek, méretezés és modern formátum nélkül.
- Ugyanaz a meta cím és leírás tucatnyi aloldalon.
- Kevert tartalom:
httpsoldalonhttphivatkozású kép vagy szkript. - Elavult vagy sosem frissülő sitemap, amiben már törölt oldalak szerepelnek.
- Mobilon 44 képpontnál kisebb, nehezen eltalálható gombok és linkek.
- Ékezetes vagy szóközös fájlnevek a feltöltött képeknél és dokumentumoknál.
Hogyan priorizáld azt, amit találtál?
Rövid válasz: ne a lista sorrendjében javíts, hanem hatás és ráfordítás szerint. Egy tipikus audit több tucat megállapítást ad, és ezek töredéke felel a probléma nagy részéért.
Használható háromszintű besorolás:
- Blokkoló: megakadályozza az indexelést vagy az elérést (tiltó robots.txt, noindex, szerverhiba, lejárt tanúsítvány). Azonnal javítandó.
- Rontó: nem akadályoz, de mérhetően gyengít (lassú betöltés, duplikált tartalom, törött belső linkek, átirányítási láncok). Néhány héten belül.
- Finomító: hasznos, de nem sürgős (strukturált adatok bővítése, alt szövegek, belső linkelés csiszolása). Folyamatos munka.
Egy gyakorlati példa a sorrendre: ha ugyanabban az auditban szerepel egy ottfelejtett noindex a szolgáltatás-oldalon és egy 2,8 másodperces betöltés a blogon, akkor a noindex percek alatt javítható és egy teljes oldalcsoportot enged vissza a versenybe, a blog sebessége pedig maradhat a következő fejlesztői körre. A javítás önmagában nem garantál pozíciójavulást, mert a rangsorolást sok más tényező is befolyásolja. Amit reálisan várhatsz: megszűnik az akadály, és a tartalmad végre versenyben lehet.
Mit tartalmazzon egy használható audit-dokumentum?
Rövid válasz: minden megállapításnál szerepeljen, hol van a hiba (konkrét URL vagy fájl), mi a következménye, mi a javítás, és ki tudja elvégezni.
Egy hosszú, eszközből exportált hibalista önmagában nem audit. A használható dokumentum végén ott van a prioritási sorrend, a becsült ráfordítás, és a mérés módja: mit fogsz megnézni négy vagy nyolc hét múlva a Search Console-ban, hogy tudd, változott-e valami. Ha ez a rész hiányzik, a javítás eredményét később senki nem tudja majd megítélni.
Honnan tudod, hogy a javítás tényleg hatott?
Rövid válasz: úgy, hogy a javítás előtt rögzíted a kiindulási számokat, és előre kimondod, melyik mérőszámnak kellene elmozdulnia. Utólag kitalált siker-mérce mindig talál valamit, ami éppen jobb lett.
Amit érdemes a javítás napján lementeni:
- az indexelt oldalak száma és a „nincs indexelve" kategóriák megoszlása,
- a megjelenések és kattintások száma az érintett oldalcsoportra,
- a Core Web Vitals besorolás a mért sablonokra,
- a naplóból a robotok napi kérésszáma, ha van hozzáférésed.
Az időzítéssel légy türelmes. Az újbóli feltérképezés és feldolgozás napokat vagy heteket vesz igénybe, a méretétől és a változás jellegétől függően, ezért az első értékelést nem másnapra, hanem néhány hétre érdemes tenni. Szakmai feltételezés: egy blokkoló hiba megszüntetése jellemzően gyorsabban látszik, mint egy sebességjavítás hatása, mert az előbbi bináris (be van engedve vagy nincs), az utóbbi pedig egy sokszereplős rangsorolás egyik apró bemenete.
Mikor érdemes szakemberre bízni?
Rövid válasz: az ellenőrzés nagy részét magad is el tudod végezni, a javítás egy részéhez viszont fejlesztői hozzáférés és felelősség kell.
A Search Console jelentéseinek átnézése, a robots.txt elolvasása, a mobilnézet és a sebesség mérése nem igényel fejlesztői tudást. Az átirányítási térkép megírása migrációnál, a szerveroldali renderelés bevezetése, a gyorsítótárazás beállítása vagy a sablonszintű strukturált adat kiépítése viszont igen, és itt egy elrontott lépés többet ronthat, mint amennyit az eredeti hiba okozott. A határ nagyjából ott van, ahol már fájlt írnál felül éles környezetben mentés nélkül.
Források és további olvasnivalók
- Google Search Central: dokumentáció az indexelésről, a robots.txt fájlról és a strukturált adatokról
- Google Search Console Súgó
- Google web.dev: Core Web Vitals dokumentáció
- Bing Webmaster Tools Súgó és Bing Webmaster Guidelines
- Schema.org: típusdefiníciók és példák
- W3C: HTML és WCAG akadálymentességi irányelvek
- OpenAI dokumentáció: crawler- és robots.txt-kezelés
- Mozilla Developer Network: HTTP státuszkódok és gyorsítótárazás
- A technikai audit nem tartalmi vizsgálat: azt nézi, hogy a technikai alap nem gátolja-e a tartalom érvényesülését.
- Mindig az indexelhetőséggel kezdd, mert egy rossz robots.txt vagy noindex minden más javítást értelmetlenné tesz.
- A Search Console, a Bing Webmaster Tools és egy crawler ingyenes rétege a hibák nagy részét megmutatja szakértői eszközök nélkül is.
- Az AI-válaszmotorok korában a szerveroldali renderelés, a stabil URL-ek és a strukturált adatok súlya nőtt.
- A talált hibákat hatás és ráfordítás alapján rangsorold, és előre írd le, min fogod mérni, hogy a javítás hatott-e.
Gyakori kérdések
Mennyi ideig tart egy technikai weboldal audit?
Egy néhány száz oldalas weboldalnál a feltérképezés és az elemzés jellemzően néhány óra, a megállapítások értelmezésével és a dokumentum összeállításával együtt általában egy-két munkanap. Nagy, több tízezer URL-es webshopnál ez jóval hosszabb, mert a naplóelemzés és a paraméterkezelés vizsgálata külön feladat.
El tudom végezni magam, ha nem vagyok fejlesztő?
Az ellenőrzés nagy részét igen. A Search Console jelentései, a robots.txt elolvasása, a mobilnézet és a sebesség mérése nem igényel programozói tudást. A javítás egy része viszont fejlesztői hozzáférést kíván, például az átirányítások, a szerveroldali gyorsítótár vagy a sablonszintű strukturált adat.
Milyen gyakran érdemes megismételni?
Rendszeresen frissülő oldalnál negyedévente reális, ritkán változó bemutatkozó oldalnál félévente is elég lehet. Ezen kívül mindig érdemes auditálni migráció, tárhelycsere, sablonváltás vagy nagyobb fejlesztés után, mert a hibák többsége ilyenkor keletkezik.
Javul a helyezésem attól, ha kijavítom a technikai hibákat?
Nem garantált. A technikai javítás az akadályokat szünteti meg, hogy a tartalmad egyáltalán versenybe kerülhessen. Ha az akadály valóban blokkoló volt (például noindex vagy tiltó robots.txt), a hatás jó eséllyel gyorsan látszik, egyébként a rangsorolást sok más tényező is befolyásolja.
Mi a különbség a technikai audit és a SEO audit között?
A technikai audit az elérhetőséget, feltérképezhetőséget, indexelhetőséget és a teljesítményt vizsgálja. A teljes SEO audit ezen felül kiterjed a tartalomra, a kulcsszóstratégiára, a versenytárs-elemzésre és a külső hivatkozásokra is. A technikai rész a többi alapja, ezért szokás vele kezdeni.
Kell külön foglalkozni az AI-crawlerekkel?
Érdemes eldönteni, engeded-e őket a robots.txt-ben, és megnézni a szervernaplóban, mennyi terhelést okoznak. Emellett a legfontosabb technikai feltétel az, hogy a lényegi tartalom már a szerver által küldött HTML-ben szerepeljen, ne csak kattintás után töltődjön be.
Mennyi idő múlva látszik az eredmény a Search Console-ban?
Az újbóli feltérképezés és feldolgozás napokat vagy heteket vehet igénybe. Az első értékelést jellemzően négy-nyolc hét után érdemes elvégezni, és mindig a javítás előtt rögzített kiindulási számokhoz hasonlítva.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.