Technikai SEO audit készítése

Technikai SEO audit készítése – teljes útmutató 2026-ra lépésről lépésre

Lehet, hogy rengeteg energiát fordítasz a tartalomkészítésre, mégsem érkezik annyi organikus látogató a weboldaladra, amennyit vársz. Ilyenkor sokan azonnal új kulcsszavakat keresnek, még több cikket írnak vagy linképítésbe kezdenek, pedig a valódi probléma gyakran a háttérben rejtőzik. Egyetlen technikai hiba is elég lehet ahhoz, hogy a Google vagy az AI-alapú keresők ne tudják megfelelően feltérképezni, értelmezni vagy indexelni az oldaladat.

A technikai SEO audit feltárja azokat a hibákat, amelyek akadályozzák a keresőmotorokat abban, hogy a weboldalad teljes értékét felismerjék. Egy jól elkészített audit nemcsak a jelenlegi problémákat mutatja meg, hanem egy egyértelmű fejlesztési tervet is ad arra, hogy mely javítások hozzák a legnagyobb eredményt.

2026-ban a technikai SEO szerepe még fontosabb lett, mint korábban. A Google mellett már olyan AI-alapú keresők is feldolgozzák a weboldalakat, mint a ChatGPT Search, a Gemini, a Claude vagy a Perplexity. Ezek a rendszerek rendkívül gyorsan elemzik az oldal szerkezetét, a strukturált adatokat, a belső linkelést, a betöltési sebességet és azt is, hogy mennyire könnyű számukra megérteni a tartalom jelentését. Egy technikailag jól felépített weboldal ezért ma már nemcsak jobb helyezéseket érhet el, hanem nagyobb eséllyel jelenik meg AI-válaszokban és összefoglalókban is.

A technikai SEO nem a látogatóknak készül, hanem a keresőmotorok és az AI rendszerek számára teszi egyértelművé, hogyan épül fel a weboldalad. Minél könnyebben tudják feltérképezni és értelmezni az oldaladat, annál nagyobb az esély arra, hogy megfelelően rangsorolják, idézzék vagy ajánlják azt.

Sokan úgy gondolják, hogy egy technikai audit kizárólag fejlesztőknek szól, pedig ez egyáltalán nincs így. Egy SEO szakembernek, marketingesnek, webáruház-tulajdonosnak vagy szolgáltató vállalkozásnak ugyanúgy értenie kell az alapelveket. Ha például egy villanyszerelő weboldalán több száz 404-es hiba található, egy kertészeti blogon hibás a belső linkelés, egy menyasszonyi ruhaszalon oldalán hiányoznak a strukturált adatok, vagy egy webáruház termékoldalai lassan töltődnek be, akkor ezek mind közvetlenül csökkenthetik az organikus forgalmat.

Ebben az útmutatóban lépésről lépésre végigvezetlek egy professzionális technikai SEO audit teljes folyamatán. Megmutatom, milyen elemeket érdemes megvizsgálni, milyen eszközöket használj, hogyan priorizáld a talált hibákat, és mire figyelj, ha azt szeretnéd, hogy a weboldalad ne csak a Google, hanem az AI-alapú keresők számára is könnyen értelmezhető és ajánlható legyen. A cikk végére pontosan tudni fogod, hogyan építs fel egy olyan technikai auditot, amely valódi SEO eredményeket hoz, és hosszú távon stabil alapot teremt a weboldalad növekedéséhez.

Ismerd meg, hogyan készül egy professzionális technikai SEO audit 2026-ban! Megmutatom, milyen hibákat kell keresned, milyen eszközöket használj, hogyan priorizáld a javításokat, és hogyan tedd a weboldalad AI keresők és Google számára is könnyen értelmezhetővé.

Tartalomjegyzék

1. Mi az a technikai SEO audit?
2. Miért fontosabb a technikai SEO audit 2026-ban, mint valaha?
3. Mit vizsgál egy professzionális technikai SEO audit?
4. Hogyan készíts technikai SEO auditot lépésről lépésre?
5. Hogyan ellenőrizd, hogy a Google és az AI robotok valóban bejárják az oldaladat?
6. Milyen indexelési hibákat kell keresned?
7. Hogyan ellenőrizd a weboldal teljesítményét és Core Web Vitals értékeit?
8. Milyen strukturált adatok hiányozhatnak az oldaladról?
9. Hogyan vizsgáld meg a belső linkelési rendszert?
10. Hogyan derítsd fel a duplikált tartalmakat?
11. Milyen mobilos problémák ronthatják a SEO-t?
12. Hogyan priorizáld a talált hibákat?
13. Milyen eszközöket érdemes használni technikai SEO audithoz?
14. Milyen hibákat követnek el a legtöbben?
15. Technikai SEO audit ellenőrző lista
16. Összegzés
17. GYIK

Mi az a technikai SEO audit?

A technikai SEO audit a weboldalad teljes műszaki állapotának részletes felmérése, amelynek célja feltárni azokat a hibákat, amelyek akadályozzák a Google és az AI-alapú keresők feltérképezését, indexelését és értelmezését.

Sokan a keresőoptimalizálást kizárólag kulcsszavakkal és tartalomkészítéssel azonosítják, pedig ezek csak az egyik oldalát jelentik a sikernek. Hiába írsz kiváló cikkeket vagy készítesz értékes szolgáltatási oldalakat, ha a keresőrobotok nem tudják megfelelően feldolgozni a weboldaladat. A technikai SEO audit éppen ezért a háttérben működő elemeket vizsgálja meg, amelyek első pillantásra gyakran láthatatlanok, mégis döntő hatással vannak az organikus teljesítményre.

A cél nem csupán az, hogy hibákat találj, hanem hogy pontos képet kapj arról, mennyire keresőbarát a weboldalad. Egy jól elkészített audit megmutatja, hogy mely problémák igényelnek azonnali beavatkozást, melyek javíthatók később, és milyen fejlesztések hozhatják a legnagyobb eredményt.

Mit vizsgál egy technikai SEO audit?

Egy professzionális audit számos technikai területet elemez, többek között:

Miért nem csak hibakeresésről szól?

A technikai SEO audit nem egy hibalista, hanem egy fejlesztési stratégia.

Egy jó audit nemcsak azt mondja meg, hogy valami rosszul működik, hanem azt is, hogy:

• mely hibák akadályozzák leginkább a helyezéseidet;
• milyen sorrendben érdemes javítani őket;
• mely problémák okozzák a legnagyobb forgalomvesztést;
• milyen javítások hozhatnak gyors eredményt;
• mely fejlesztések növelik hosszú távon a weboldal értékét.

Ez különösen fontos nagyobb weboldalaknál, ahol több száz vagy akár több tízezer URL található. Egy webáruház esetében például előfordulhat, hogy több ezer termékoldal nincs megfelelően indexelve, míg egy kertészeti tudásbázisnál vagy egy SEO blognál a hibás belső linkelés akadályozza a keresőrobotok munkáját.

Miért lett ennyire fontos az AI keresők megjelenésével?

A modern AI keresők nemcsak a tartalmat olvassák, hanem a weboldal technikai felépítését is elemzik.

A ChatGPT Search, a Gemini, a Claude és a Perplexity célja, hogy gyorsan és pontosan megértsék egy weboldal tartalmát. Ehhez szükségük van egy jól strukturált, könnyen feltérképezhető és technikailag hibamentes oldalra.

Az AI rendszerek különösen figyelnek többek között:

• az egyértelmű URL-struktúrára;
• a megfelelő HTML-fejlécekre;
• a strukturált adatokra (Schema markup);
• a logikus belső linkhálózatra;
• a gyors betöltési időre;
• a hibamentes indexelésre;
• a duplikált tartalmak elkerülésére.

Ha ezek rendben vannak, sokkal nagyobb az esélye annak, hogy az AI rendszerek megbízható forrásként kezelik az oldaladat, és felhasználják azt válaszaik elkészítéséhez.

Kinek érdemes technikai SEO auditot készítenie?

Minden olyan weboldalnak, amely organikus forgalmat szeretne szerezni vagy növelni.

Különösen ajánlott:

• szolgáltató vállalkozásoknak;
• webáruházaknak;
• helyi cégeknek;
• szakmai blogoknak;
• hírportáloknak;
• vállalati weboldalaknak;
• tudásbázisoknak;
• nagy tartalmi oldalaknak.

Egy technikai SEO audit akkor is hasznos, ha új weboldalt indítasz, jelentős átalakítást végeztél, vagy azt tapasztalod, hogy csökkent az organikus forgalmad. A rendszeres – legalább félévente vagy nagyobb fejlesztések után elvégzett – audit segít időben felismerni a problémákat, így még azelőtt kijavíthatod őket, hogy komolyabb hatással lennének a keresőbeli teljesítményedre.

Miért fontosabb a technikai SEO audit 2026-ban, mint valaha?

2026-ban a technikai SEO audit már nemcsak a Google helyezések javításáról szól, hanem arról is, hogy a weboldalad érthető, megbízható és könnyen feldolgozható legyen az AI-alapú keresőrendszerek számára.

Az elmúlt néhány évben alapjaiban változott meg az internetes keresés. Korábban elegendő volt jól optimalizált tartalmakat írni, megfelelő kulcsszavakat használni és néhány minőségi hivatkozást szerezni. Ma azonban a Google AI Overviews, a ChatGPT Search, a Gemini, a Claude és a Perplexity már nem egyszerűen weboldalakat rangsorolnak, hanem információkat gyűjtenek, összekapcsolnak és összefoglalnak.

Ehhez viszont a weboldalad technikai felépítésének is hibátlannak kell lennie. Ha a keresőrobotok vagy az AI modellek nem tudják megfelelően feltérképezni az oldalt, hiába készítesz kiváló tartalmat, annak láthatósága jelentősen csökkenhet.

Az AI keresők sokkal gyorsabban dolgozzák fel a weboldalakat

Az AI rendszereknek másodpercek alatt kell megérteniük egy weboldal szerkezetét és tartalmát, ezért előnyben részesítik az egyértelműen felépített oldalakat.

Míg korábban a Google elsősorban dokumentumokat indexelt, ma már a mesterséges intelligencia rendszerei összefüggéseket keresnek. Nem egyetlen oldalra kíváncsiak, hanem arra, hogy egy vállalkozás, márka vagy szakértő milyen tudásbázist épített fel.

Ezért egy technikai audit során ma már nemcsak azt vizsgáljuk, hogy egy oldal indexelhető-e, hanem azt is, hogy:

• logikus-e az URL-struktúra;
• könnyen követhető-e a belső linkelés;
• megfelelően kapcsolódnak-e egymáshoz a témák;
• gyorsan feldolgozható-e az oldal HTML-szerkezete;
• rendelkezik-e megfelelő strukturált adatokkal.

Ezek az elemek segítik az AI rendszereket abban, hogy gyorsabban megértsék az oldal tartalmát.

A technikai hibák ma már az AI láthatóságot is rontják

Egy technikai probléma ma már nemcsak a Google rangsorolását befolyásolhatja, hanem azt is, hogy az AI rendszerek egyáltalán felhasználják-e az oldaladat forrásként.

Néhány gyakori példa:

• hibás canonical címkék;
• rosszul működő átirányítások;
• blokkolt JavaScript vagy CSS fájlok;
• hiányzó strukturált adatok;
• túl lassú betöltési idő;
• hibás XML sitemap;
• rosszul konfigurált robots.txt;
• nagy mennyiségű 404-es oldal.

Ezek a hibák megnehezítik a keresőrobotok munkáját, és csökkentik annak esélyét, hogy az oldalad bekerüljön az AI által felhasznált források közé.

A felhasználói élmény közvetlenül összefügg a technikai SEO-val

A keresőmotorok egyre inkább olyan weboldalakat részesítenek előnyben, amelyek gyorsak, stabilak és minden eszközön jól használhatók.

A technikai SEO ma már szorosan összekapcsolódik a felhasználói élménnyel (UX). Egy lassan betöltődő oldal vagy egy mobiltelefonon nehezen kezelhető weboldal nemcsak a látogatók számára okoz problémát, hanem negatív jelzés a keresőmotorok felé is.

Ez különösen fontos például:

• egy webáruház esetében, ahol minden másodperc késlekedés csökkentheti a vásárlások számát;
• egy villanyszerelő szolgáltatási oldalán, ahol a látogató gyorsan szeretne kapcsolatba lépni;
• egy kertészeti tudásbázisnál, ahol sok képet és hosszú cikkeket kell gyorsan betölteni;
• egy menyasszonyi ruhaszalon weboldalán, ahol a nagy felbontású galériák megfelelő optimalizálása elengedhetetlen.

A technikai SEO audit segít megtalálni azokat a teljesítménybeli problémákat, amelyek rontják a felhasználói élményt és ezzel együtt a keresőbeli teljesítményt is.

A strukturált adatok szerepe jelentősen felértékelődött

A strukturált adatok ma már nemcsak gazdag találatok megjelenítésére szolgálnak, hanem az AI rendszerek számára is fontos értelmezési segítséget jelentenek.

A Schema markup segítségével pontosan megadhatod, hogy egy oldal:

• szolgáltatást mutat be;
• terméket értékesít;
• GYIK-et tartalmaz;
• cikket jelenít meg;
• egy szervezetet vagy szakértőt ismertet.

Minél pontosabban tudja az AI értelmezni az oldalad tartalmát, annál nagyobb az esély arra, hogy megbízható forrásként kezelje.

A technikai SEO audit segít hatékonyabban kihasználni a crawl budgetet

A nagyobb weboldalak esetében különösen fontos, hogy a keresőrobotok az értékes oldalakat térképezzék fel először.

Ha egy weboldalon sok hibás URL, felesleges átirányítás vagy duplikált tartalom található, akkor a keresőrobotok idejének jelentős részét ezek feldolgozása emészti fel.

Egy technikai audit során kiderülhet például, hogy:

• több száz régi URL még mindig elérhető;
• a sitemap olyan oldalakat tartalmaz, amelyeket már töröltél;
• ugyanaz a tartalom több URL-en is megjelenik;
• a belső linkek hibás vagy megszűnt oldalakra mutatnak.

Ezek javításával a keresőrobotok gyorsabban eljutnak a valóban fontos oldalakhoz.

A technikai SEO ma már a bizalom egyik alapja

A technikailag rendezett weboldal nagyobb hitelességet sugall a keresőmotorok és az AI rendszerek felé is.

A modern algoritmusok nemcsak azt figyelik, hogy mit írsz, hanem azt is, mennyire gondosan építetted fel a weboldaladat. Egy hibamentes technikai háttér azt jelzi, hogy az oldal karbantartott, naprakész és megbízható.

Ez különösen fontos olyan területeken, ahol a hitelesség kiemelt szerepet játszik, például:

• egészségügyi témák;
• pénzügyi szolgáltatások;
• jogi tanácsadás;
• építőipar;
• villanyszerelés;
• keresőoptimalizálás.

Összességében már nem kérdés, hogy szükség van-e technikai SEO auditra

2026-ban a technikai SEO audit nem opcionális fejlesztés, hanem a sikeres organikus jelenlét egyik alapfeltétele.

A Google és az AI-alapú keresők egyre nagyobb hangsúlyt fektetnek a technikai minőségre. Egy gyors, jól strukturált, hibamentes és könnyen feltérképezhető weboldal nemcsak jobb helyezésekre számíthat, hanem nagyobb eséllyel válik az AI rendszerek által idézett és ajánlott forrássá is. A rendszeresen elvégzett technikai audit ezért hosszú távon az egyik legjobb befektetés, amelyet a weboldalad láthatósága érdekében megtehetsz.

Mit vizsgál egy professzionális technikai SEO audit?

Hogyan készíts technikai SEO auditot lépésről lépésre?

A technikai SEO auditot mindig meghatározott sorrendben érdemes elvégezni: először feltérképezed a weboldalt, majd ellenőrzöd a hozzáférhetőséget, az indexelést, a teljesítményt, a webhelyszerkezetet és végül fontossági sorrendbe állítod a talált hibákat.

Nem érdemes rögtön a képek tömörítésével vagy a meta leírások hosszával kezdened. Ha ugyanis a Google nem tudja feltérképezni a fontos oldalakat, vagy egy hibás noindex beállítás miatt nem kerülnek be az indexbe, minden kisebb optimalizálás másodlagossá válik.

Egy jól felépített technikai audit tehát nem véletlenszerű ellenőrzésekből, hanem egymásra épülő vizsgálatokból áll.

1. Hogyan határozd meg a technikai SEO audit célját?

Mielőtt megnyitnád az első SEO-eszközt, tisztázd, hogy miért készül az audit, melyik weboldalrészeket vizsgálod, és milyen üzleti problémára keresel választ.

Más típusú ellenőrzésre lehet szükség egy új weboldal indulása előtt, egy organikus forgalomcsökkenés után vagy egy több ezer termékes webáruház migrációját követően.

Az audit előtt gyűjtsd össze:

• a weboldal összes használt domain- és aldomain-változatát;
• a Google Search Console és a Google Analytics hozzáférést;
• az XML sitemap elérhetőségét;
• a robots.txt fájl címét;
• a korábbi fejlesztések és migrációk időpontját;
• az organikus forgalom változásait;
• a legfontosabb szolgáltatási, kategória- és termékoldalakat;
• azokat az oldalakat, amelyek üzletileg a legtöbb bevételt vagy érdeklődőt hozzák.

Egy villanyszerelő weboldalán például a hibakeresés, a villanyóra-szabványosítás és a főzőlap-bekötés szolgáltatási oldalak lehetnek kiemelten fontosak. Egy webáruháznál viszont a kategóriaoldalak, a legnépszerűbb termékek és a szűrésből létrejövő URL-ek kerülhetnek a vizsgálat középpontjába.

2. Hogyan térképezd fel a teljes weboldalt?

A következő lépésben egy keresőrobot működését utánzó crawlerrel járd be a weboldalt, hogy egy helyen lásd az URL-eket, státuszkódokat, címsorokat, canonical címkéket és belső linkeket.

Erre használhatsz például:

• Screaming Frog SEO Spider;
• Sitebulb;
• Semrush Site Audit;
• Ahrefs Site Audit;
• JetOctopus;
• Oncrawl.

A feltérképezés során lehetőleg ne csak a kezdőoldalról induló linkeket vizsgáld. Töltsd be az XML sitemap URL-jeit, és nagyobb oldalnál hasonlítsd össze a crawler által megtalált címeket a Search Console-ból, analitikából vagy szervernaplókból származó URL-ekkel is.

A crawl eredményében keresd többek között:

• a 3xx átirányításokat;
• a 4xx és 5xx hibákat;
• a nem indexelhető URL-eket;
• a hiányzó vagy hibás canonical címkéket;
• a túl hosszú átirányítási láncokat;
• a duplikált title és H1 elemeket;
• az árva oldalakat;
• a túl mélyen elhelyezkedő URL-eket;
• a hibás belső linkeket;
• a JavaScript-függő tartalmakat;
• a nagyon nagy HTML-dokumentumokat.

Fontos, hogy a crawler beállításai igazodjanak a weboldal működéséhez. Egy JavaScript-alapú webáruház esetében például érdemes külön lefuttatni a hagyományos HTML-crawlt és a renderelt JavaScript-crawlt. A Google a JavaScript-oldalakat is feldolgozhatja, de a feltérképezés és a renderelés külön munkafolyamat, ezért a csak kliensoldalon megjelenő tartalom és linkek külön figyelmet igényelnek.

3. Hogyan ellenőrizd a robots.txt fájlt?

A robots.txt fájlban azt kell ellenőrizned, hogy nem tiltja-e véletlenül a fontos oldalak, könyvtárak vagy erőforrások feltérképezését.

A fájl általában ezen a címen érhető el:

https://pelda.hu/robots.txt

Vizsgáld meg:

• nincs-e tiltva a teljes webhely;
• hozzáférhetők-e a szolgáltatási és tartalmi oldalak;
• nincs-e blokkolva fontos CSS- vagy JavaScript-fájl;
• szerepel-e benne a megfelelő XML sitemap;
• indokoltak-e az adminisztrációs vagy szűrési útvonalak tiltásai;
• külön szabályok vonatkoznak-e egyes robotokra.

A robots.txt nem az indexelés biztos megakadályozására szolgál. Elsősorban azt szabályozza, hogy a robot mely URL-eket kérheti le. Egy blokkolt URL bizonyos esetekben továbbra is megjelenhet a keresőben, ha más oldalak hivatkoznak rá. Az indexelés tiltásához inkább noindex beállítás vagy hozzáférés-védelem szükséges.

Ez gyakori hiba fejlesztésből éles környezetbe helyezett weboldalaknál. Előfordulhat, hogy a tesztoldalon használt teljes tiltás az éles domain robots.txt fájljában is megmarad.

4. Hogyan vizsgáld meg az XML sitemap állapotát?

Az XML sitemapnek kizárólag olyan végleges, indexelhető és 200-as státuszkódot adó URL-eket kell tartalmaznia, amelyeket valóban szeretnél megjeleníteni a Google találatai között.

Ellenőrizd, hogy a sitemapben:

• csak kanonikus URL-ek szerepelnek-e;
• nincsenek-e 301-es vagy 302-es átirányítások;
• nincsenek-e 404-es oldalak;
• kimaradtak-e a noindex URL-ek;
• nem szerepelnek-e paraméteres vagy duplikált oldalak;
• megtalálhatók-e benne az új, fontos tartalmak;
• megfelelő-e a protokoll és a domainváltozat;
• valósak-e a módosítási dátumok.

Ezután hasonlítsd össze a sitemapben szereplő URL-ek számát a Search Console indexelési adataival.

Az XML sitemap segíti a keresőket az URL-ek felfedezésében, de nem garantálja sem a feltérképezést, sem az indexelést. Egy jól belinkelt kisebb oldalnál a Google sitemap nélkül is megtalálhatja az oldalak többségét, nagy, új vagy összetett webhelyeknél azonban különösen hasznos lehet.

5. Hogyan ellenőrizd az indexelést a Google Search Console-ban?

A Search Console Oldalak jelentésében azt kell összevetned, hogy mely URL-eket szeretnéd indexeltetni, és melyeket tartja ténylegesen indexben a Google.

Ne abból indulj ki, hogy minden „nem indexelt” URL hibát jelent. Egy adminisztrációs oldal, kosároldal, belső keresési találat vagy duplikált szűrési URL helyesen is lehet kizárva.

Elsősorban ezeket a kategóriákat vizsgáld:

• feltérképezve, jelenleg nincs indexelve;
• felfedezve, jelenleg nincs indexelve;
• duplikált oldal megfelelő canonical nélkül;
• a Google a felhasználó által megadottól eltérő canonicalt választott;
• noindex címke miatt kizárva;
• robots.txt által blokkolva;
• soft 404;
• átirányítást tartalmazó oldal;
• szerverhiba miatt nem elérhető URL.

A fontos URL-eket külön is ellenőrizd az URL-ellenőrző eszközzel. Nézd meg:

• indexelhető-e az oldal;
• mikor térképezte fel legutóbb a Google;
• melyik canonical URL-t választotta;
• engedélyezett-e a feltérképezés;
• milyen oldalról fedezte fel;
• megfelelően renderelődik-e a tartalom.

A Google is a Search Console indexelési jelentését és az URL-ellenőrzőt ajánlja a webhelyszintű, illetve URL-szintű problémák feltárására.

6. Hogyan ellenőrizd a HTTP-státuszkódokat és az átirányításokat?

Minden vizsgált URL-nél meg kell állapítanod, hogy a szerver a tartalom állapotának megfelelő HTTP-választ adja-e.

A legfontosabb státuszkódok:

Külön keresd az átirányítási láncokat, például:

régi URL → köztes URL → új URL → végleges URL

Ezt érdemes egyetlen közvetlen átirányításra rövidíteni:

régi URL → végleges URL

Weboldal-költöztetés vagy URL-struktúra módosítása után ellenőrizd azt is, hogy a belső linkek már a végleges célcímre mutatnak-e. Nem ideális, ha minden belső kattintás egy 301-es átirányításon keresztül jut el a tartalomhoz.

7. Hogyan vizsgáld meg a canonical címkéket és a duplikációkat?

Minden indexelhető oldalnak egyértelműen jeleznie kell, melyik URL képviseli a tartalom elsődleges változatát.

A canonical címke ellenőrzésekor nézd meg:

• önmagára mutat-e az egyedi oldal canonicalja;
• 200-as és indexelhető URL-re mutat-e;
• nem vezet-e átirányított vagy hibás oldalra;
• egyezik-e a sitemapben szereplő URL-lel;
• egyezik-e a belső linkek céljával;
• következetes-e a HTTP/HTTPS és www/nem-www változat;
• nincs-e több, egymásnak ellentmondó canonical jelzés.

Duplikáció gyakran keletkezik:

• webáruházi szűrők és rendezési paraméterek miatt;
• nyomtatható oldalváltozatokból;
• címkékkel és kategóriákkal létrehozott archívumokból;
• HTTP és HTTPS változatokból;
• záró perjeles és perjel nélküli URL-ekből;
• ugyanazt a terméket megjelenítő több kategóriaútvonalból;
• UTM-paraméteres címekből.

A canonical a preferált URL jelzésére szolgál, de a Google több jel alapján választja ki a reprezentatív változatot. Ezért a canonical címke, az átirányítások, a sitemap és a belső linkelés lehetőleg ugyanarra az URL-re mutasson.

8. Hogyan ellenőrizd a weboldal felépítését és belső linkelését?

A fontos oldalakat lehetőleg néhány logikus kattintással elérhetővé kell tenned, és egyetlen értékes tartalom sem maradhat belső hivatkozás nélkül.

Vizsgáld meg:

• hány kattintásra helyezkednek el az oldalak a kezdőoldaltól;
• mely URL-ek nem kapnak belső linket;
• mely oldalakra mutat túl kevés hivatkozás;
• megfelelőek-e a linkek anchor szövegei;
• vannak-e túl sok linket tartalmazó sablonrészek;
• követhető-e a kategóriák és alkategóriák hierarchiája;
• működik-e a morzsamenü;
• összekapcsolódnak-e a kapcsolódó témák.

Egy kertészeti tudásbázisban például a paradicsom termesztéséről szóló fő útmutatónak kapcsolódnia kell az öntözésről, tápanyaghiányokról, betegségekről és kártevőkről szóló tartalmakhoz. Egy menyasszonyi ruhaszalon oldalán a fazonokat bemutató cikkekből érdemes linkelni a próbafoglalási és kapcsolati oldalra, de nem minden bekezdésben ugyanazzal az erőltetett anchor szöveggel.

Az XML sitemap nem helyettesíti a belső linkelést. A Google dokumentációja szerint a megfelelő navigációból vagy oldalon belüli linkekből elérhető fontos URL-eket a kereső általában sitemap nélkül is fel tudja fedezni.

9. Hogyan ellenőrizd a Core Web Vitals és sebességértékeket?

A teljesítményvizsgálatnál először a valódi felhasználóktól származó terepadatokat nézd meg, majd laboradatokkal keresd meg a problémák technikai okát.

A három Core Web Vital mutató:

A minősítésnél jellemzően az oldalletöltések 75. percentilisét kell figyelembe venni, külön mobilos és asztali értékeléssel.

Használható adatforrások:

• Google Search Console Core Web Vitals jelentés;
• PageSpeed Insights;
• Chrome UX Report;
• Lighthouse;
• Chrome DevTools;
• WebPageTest;
• saját valós felhasználói mérés.

A laboradat egy ellenőrzött tesztkörnyezet eredménye, míg a terepadat valódi felhasználói látogatásokból származik. Ezért előfordulhat, hogy ugyanaz az oldal Lighthouse-ban jó eredményt kap, a Search Console-ban mégis problémás. A két adattípus eltérő kérdésre válaszol, ezért nem érdemes egyiket a másik helyettesítőjeként kezelni.

A lassulás gyakori okai:

• túl nagy hero kép;
• lassú szerverválasz;
• nem megfelelő gyorsítótárazás;
• túl sok külső script;
• használaton kívüli JavaScript;
• blokkoló CSS;
• betűkészletek lassú betöltése;
• foglalatlan képméretek;
• nehéz bővítmények;
• túlzott DOM-méret.

A Core Web Vitals része a Google oldalélményre vonatkozó rendszereinek, de önmagában a jó pontszám nem garantál magas helyezést.

10. Hogyan ellenőrizd a mobilos működést?

A mobilverzió tartalmának, linkjeinek, strukturált adatainak és metaelemeinek lényegében meg kell egyezniük az asztali változat értékes elemeivel.

A Google mobil-first indexelést használ, vagyis elsősorban a weboldal mobilváltozatának tartalmát veszi alapul az indexeléshez és a rangsoroláshoz.

Ellenőrizd valódi telefonon és böngészőfejlesztői eszközökkel is:

• olvasható-e a szöveg nagyítás nélkül;
• megfelelő távolságra vannak-e a kattintható elemek;
• működik-e a navigáció;
• látható-e minden lényeges tartalom;
• nem takarja-e ki az oldalt felugró ablak;
• megfelelően jelennek-e meg a táblázatok;
• használhatók-e az űrlapok;
• működik-e a kosár és a fizetés;
• nem töltődik-e lényegesen lassabban a mobilnézet;
• ugyanazok-e a canonical és robots beállítások.

Egy klímaszerelő oldalán például különösen fontos, hogy a telefonszám és az ajánlatkérő gomb könnyen használható legyen mobilon. Egy webáruháznál viszont a termékszűrő, a képgaléria és a pénztár működése igényel kiemelt ellenőrzést.

11. Hogyan ellenőrizd a strukturált adatokat?

Csak olyan strukturált adatot használj, amely megfelel az oldal látható tartalmának, technikailag érvényes, és az adott oldaltípushoz valóban releváns.

Vizsgáld meg:

• milyen Schema típusok jelennek meg;
• vannak-e hibák vagy figyelmeztetések;
• teljesülnek-e a kötelező tulajdonságok;
• megfelelnek-e az adatok a látható tartalomnak;
• helyesek-e a kapcsolatok az entitások között;
• nincs-e ugyanaz az elem több bővítményből duplikálva;
• indexelhető-e az oldal, amelyen a jelölés szerepel.

Használd:

• a Rich Results Test eszközt;
• a Schema Markup Validatort;
• a Search Console bővített találati jelentéseit;
• az URL-ellenőrző eszközt.

A Google a JSON-LD formátumot ajánlja, de a hibátlan szintaxis önmagában nem elegendő. A jelölés tartalmának pontosnak, valósnak és a felhasználó számára is láthatónak kell lennie.

Egy helyi villanyszerelőnél például releváns lehet a LocalBusiness, a Service és a BreadcrumbList. Egy webáruháznál a Product, az Offer és adott esetben a termékszállítási adatok lehetnek fontosak. Nem érdemes olyan értékelést vagy szolgáltatási információt megjelölni, amely valójában nem szerepel az oldalon.

12. Hogyan vizsgáld meg a képeket és médiafájlokat?

A képeknek megfelelő méretben, korszerű formátumban, leíró környezetben és technikailag elérhető módon kell betöltődniük.

Ellenőrizd:

• a fájlméreteket;
• a megjelenési mérethez képest túl nagy felbontásokat;
• a WebP vagy AVIF használatát;
• a szélesség- és magasságértékeket;
• az indokolt lazy loading beállítást;
• a hiányzó alt attribútumokat;
• a hibás kép-URL-eket;
• a robots.txt miatti blokkolást;
• a kép-sitemap szükségességét;
• a képfájlok gyorsítótárazását.

Egy menyasszonyi ruhaszalon galériájánál nem szerencsés minden képet több megabájtos eredeti fotóként betölteni. Egy építőipari referenciaoldalon viszont arra is ügyelj, hogy a képekhez tartozó szöveg pontosan ismertesse a munkát, helyszínt vagy alkalmazott megoldást.

13. Hogyan ellenőrizd a biztonságot és a webhely technikai konzisztenciáját?

A webhely minden nyilvános oldalának biztonságos HTTPS-kapcsolaton, egyetlen következetes domainváltozaton kell működnie.

Vizsgáld meg:

• érvényes-e az SSL-tanúsítvány;
• van-e vegyes HTTP–HTTPS tartalom;
• minden HTTP URL HTTPS-re irányít-e;
• egységes-e a www vagy nem-www változat;
• nincs-e több különböző kezdőoldal-URL;
• megfelelően működnek-e a biztonsági fejlécek;
• nem került-e rosszindulatú tartalom az oldalra;
• elérhetők-e véletlenül teszt-, mentési vagy adminisztrációs fájlok.

Érdemes azt is ellenőrizni, hogy a weboldal nem hoz-e létre végtelen számú URL-t hibás naptárakból, keresésekből, szűrőkből vagy paraméterekből. Ezek nemcsak indexelési zavart okozhatnak, hanem feleslegesen terhelhetik a szervert is.

14. Hogyan használd a szervernaplókat az auditban?

A szervernapló megmutatja, hogy a keresőrobotok ténylegesen mely URL-eket kérik le, milyen gyakran járnak az oldalon, és milyen válaszokat kapnak.

A crawler azt mutatja meg, hogy elméletileg mit lehet bejárni. A logelemzés ezzel szemben azt mutatja meg, hogy a Googlebot a gyakorlatban mit jár be.

Keresd például:

• mely könyvtárakat látogatja leggyakrabban a Googlebot;
• kimaradnak-e fontos oldalak;
• túl sok erőforrás jut-e értéktelen paraméteres URL-ekre;
• milyen gyakran kap 3xx, 4xx vagy 5xx választ;
• milyen mobilos és asztali robotok érkeznek;
• mennyi idő telik el egy frissített oldal újrafeltérképezéséig;
• vannak-e robotcsapdák.

A naplóelemzés főként nagy webáruházaknál, hírportáloknál, apróhirdetési oldalakon és több tízezer URL-t kezelő tudásbázisoknál hasznos. Egy húszoldalas szolgáltatói webhelyen általában nincs szükség rendkívül mély crawl budget elemzésre.

15. Hogyan vesd össze a technikai hibákat a forgalmi adatokkal?

A technikai problémák üzleti jelentőségét akkor tudod pontosan megítélni, ha összekapcsolod őket a Search Console és az analitikai rendszer adataival.

Vizsgáld meg:

• mely hibás oldalak kaptak korábban organikus forgalmat;
• mely URL-ek vesztettek kattintást vagy megjelenést;
• mely oldalak hoznak bevételt vagy ajánlatkérést;
• mikor kezdődött a visszaesés;
• egybeesik-e a változás migrációval, sabloncserével vagy fejlesztéssel;
• csak egy könyvtárat vagy az egész webhelyet érinti-e;
• mobilon vagy asztali gépen erősebb-e a probléma;
• márkás vagy nem márkás keresések estek-e vissza.

A Search Console és a Google Analytics együtt átfogóbb képet ad arról, hogyan találják meg és hogyan használják a látogatók a weboldalt.

Egy 404-es oldal önmagában lehet alacsony prioritású. Ha azonban korábban több száz kattintást és értékes külső linkeket kapott, a helyreállítása vagy megfelelő átirányítása sürgős feladat lehet.

16. Hogyan priorizáld a feltárt technikai SEO hibákat?

A hibákat ne a darabszámuk, hanem a SEO-hatásuk, az érintett oldalak értéke, a javítás költsége és a kockázat alapján rangsorold.

Használhatsz például ilyen prioritási rendszert:

Minden hibához rendelj:

• pontos leírást;
• érintett URL-listát;
• képernyőképet vagy exportot;
• várható SEO-hatást;
• javítási javaslatot;
• felelőst;
• határidőt;
• ellenőrzési módszert.

Ne írj olyan általános feladatot, hogy „javítani kell a weboldal sebességét”. Sokkal használhatóbb például ez:

A szolgáltatási oldalak LCP-eleme egy 2,4 MB-os hero kép. Készíts legfeljebb 1600 pixel széles AVIF-változatot, add meg a méreteit a HTML-ben, és ne töltsd be lazy loadinggal a hajtás feletti képet.

17. Hogyan ellenőrizd a javításokat?

A technikai SEO audit nem ér véget a jelentés átadásával: minden módosítást újra kell tesztelned ugyanazzal a módszerrel, amellyel a hibát megtaláltad.

A javítás után:

1. futtasd újra az érintett URL-ek crawl-ját;
2. ellenőrizd a státuszkódokat;
3. teszteld a canonical és robots beállításokat;
4. vizsgáld meg a renderelt oldalt;
5. ellenőrizd a strukturált adatokat;
6. küldd be a frissített sitemapet, ha szükséges;
7. fontos URL-eknél használd a Search Console URL-ellenőrzőjét;
8. figyeld az indexelési és teljesítményadatokat;
9. hasonlítsd össze az audit előtti és utáni eredményeket;
10. dokumentáld a lezárt és fennmaradó feladatokat.

A feltérképezés vagy újraindexelés nem feltétlenül történik meg azonnal. A Google szerint az újrafeldolgozás néhány naptól akár több hétig is tarthat, és a beküldés nem garantálja az indexelést.

Milyen sorrendben érdemes elvégezni a technikai SEO auditot?

A leghatékonyabb munkafolyamat az elérhetőségtől halad a részletes optimalizálás felé.

Egy jó technikai SEO audit végeredménye nem egy automatikusan generált, több száz soros hibajegyzék, hanem egy végrehajtható fejlesztési terv. Pontosan megmutatja, mely problémák gátolják az indexelést, melyek rontják a felhasználói élményt, mit kell azonnal javítani, és mely feladatokkal érdemes később foglalkozni.

Hogyan ellenőrizd, hogy a Google és az AI robotok valóban bejárják az oldaladat?

A robotok tényleges látogatását a szervernaplók bizonyítják a legpontosabban. A Google Search Console, a robots.txt ellenőrzése és az URL-tesztelő eszközök megmutatják, hogy egy robot hozzáférhet-e az oldalhoz, de azt, hogy valóban mikor és milyen választ kapva kereste fel, a szerver logfájljából tudod biztosan megállapítani.

A feltérképezés, a renderelés és az indexelés három különböző folyamat. Attól, hogy egy URL technikailag elérhető, még nem biztos, hogy a Googlebot már meglátogatta. Attól pedig, hogy meglátogatta, még nem következik automatikusan, hogy az oldal bekerült a kereső indexébe.

Ezért az ellenőrzést több adatforrás együttes használatával érdemes elvégezned.

Mi a különbség a feltérképezés és az indexelés között?

A feltérképezés azt jelenti, hogy egy robot lekérte az URL-t, az indexelés pedig azt, hogy a rendszer feldolgozta és kereshető adatként eltárolta a tartalmat.

A folyamat általában így épül fel:

1. a robot felfedezi az URL-t;
2. ellenőrzi a robots.txt szabályait;
3. lekéri az oldalt;
4. feldolgozza a HTML-kódot;
5. szükség esetén rendereli a JavaScriptet;
6. értékeli a tartalmat és a canonical jelzéseket;
7. dönthet az indexelésről.

A Google hivatalos leírása szerint a Googlebot algoritmikusan határozza meg, hogy mely webhelyeket, milyen gyakran és hány URL erejéig térképez fel. Egy oldal feltérképezése tehát önmagában nem garantálja az indexelést vagy a keresési megjelenést.

Hogyan ellenőrizd a Googlebot látogatásait a Search Console-ban?

A Search Console Feltérképezési statisztikák jelentése megmutatja, hogy a Googlebot milyen gyakran keresi fel a webhelyedet, milyen fájltípusokat kér le, és milyen szerverválaszokat kap.

A jelentést a Search Console beállításai között találod. A pontos elnevezés a felület nyelvétől függően „Feltérképezési statisztikák” vagy „Crawl Stats” lehet.

A jelentésben vizsgáld meg:

• a napi feltérképezési kérelmek számát;
• a letöltött adatmennyiséget;
• az átlagos válaszidőt;
• a Googlebot által használt eszköztípust;
• a fájltípusok megoszlását;
• a 200-as, 301-es, 404-es és 5xx válaszokat;
• a gazdagép elérhetőségi problémáit;
• a hirtelen megugró vagy visszaeső robotaktivitást;
• a robots.txt lekérésével kapcsolatos hibákat;
• a DNS- és szerverproblémákat.

Ha például a Googlebot kérései egyik napról a másikra jelentősen visszaesnek, ellenőrizd, nem történt-e:

• robots.txt módosítás;
• szerverleállás;
• tűzfal- vagy CDN-beállítás;
• WordPress biztonsági bővítmény frissítése;
• domain- vagy tárhelymigráció;
• nagyobb URL-struktúra-váltás.

A Google a Crawl Stats jelentést kifejezetten a feltérképezési előzmények és a gazdagép-elérhetőségi hibák vizsgálatára ajánlja. Ugyanakkor ebből a jelentésből nem tudod minden esetben pontos útvonal vagy URL alapján visszakeresni a teljes crawl-előzményt, ezért az egyedi URL-ek vizsgálatához szervernaplóra vagy URL-ellenőrzésre is szükséged lehet.

Hogyan ellenőrizd egy konkrét URL Googlebot-hozzáférését?

Egy adott oldal ellenőrzésére a Search Console URL-ellenőrző eszköze a leggyorsabb megoldás.

Írd be a teljes URL-t, majd nézd meg:

• szerepel-e az URL a Google indexében;
• engedélyezett-e a feltérképezése;
• mikor történt az utolsó feltérképezés;
• milyen Googlebot-típust használt a rendszer;
• sikeres volt-e az oldal lekérése;
• melyik canonical URL-t választotta a Google;
• található-e noindex utasítás;
• betölthetők-e az oldal fontos erőforrásai;
• megjelenik-e a fő tartalom a renderelt változatban.

Az „Élő URL tesztelése” funkcióval azt is ellenőrizheted, hogy a Googlebot a vizsgálat pillanatában hozzáfér-e az oldalhoz. Ez azonban nem ugyanaz, mint annak bizonyítása, hogy az URL már szerepel az indexben.

A Google az URL-ellenőrzést egyedi oldalak hozzáférhetőségének, renderelésének és indexelési állapotának vizsgálatára ajánlja.

Hogyan állapítsd meg a szervernaplóból, hogy valóban járt-e ott a robot?

A szervernapló minden valódi HTTP-kérést rögzíthet, ezért ebből láthatod a robot látogatásának időpontját, a lekért URL-t, a státuszkódot és a user-agentet.

A logbejegyzés általában ilyen adatokat tartalmaz:

• a kérés időpontja;
• a forrás IP-címe;
• a lekért URL;
• a HTTP-metódus;
• a visszaküldött státuszkód;
• a válasz mérete;
• a hivatkozó oldal;
• a user-agent;
• esetenként a válaszidő.

Egy egyszerűsített bejegyzés például így nézhet ki:

66.249.xxx.xxx - - [21/Jul/2026:08:32:14 +0200]
"GET /technikai-seo-audit/ HTTP/1.1" 200
"Mozilla/5.0 ... Googlebot/2.1 ..."

Ez arra utalhat, hogy egy Googlebot user-agenttel érkező kérés lekérte az oldalt, és a szerver 200-as választ adott.

A user-agent neve azonban önmagában nem elegendő bizonyíték, mert meghamisítható. A Google azt javasolja, hogy a valódi Googlebot-forgalmat fordított DNS-ellenőrzéssel vagy a hivatalosan közzétett Googlebot IP-tartományokkal való összehasonlítással hitelesítsd.

Milyen adatokat keress a logelemzés során?

Ne csak azt nézd meg, hogy járt-e robot az oldalon, hanem azt is, hogy mely URL-eket, milyen gyakran és milyen szerverválasszal térképezte fel.

Készíts kimutatást legalább ezekről:

Egy webáruházban például kiderülhet, hogy a Googlebot több tízezer rendezési és szűrési URL-t kér le, miközben az új termékkategóriákat ritkán látogatja. Egy SEO tudásbázisnál az derülhet ki, hogy a régi címkeoldalak kapják a kérések jelentős részét, az új szakmai útmutatók pedig túl mélyen helyezkednek el a webhelyszerkezetben.

Hogyan ellenőrizd, hogy a robots.txt engedélyezi-e a robotokat?

Nyisd meg a robots.txt fájlt, és minden fontos robot user-agentjére külön ellenőrizd, hogy nincs-e tiltva a teljes webhely vagy valamely lényeges könyvtár.

A fájl általában itt érhető el:

https://domain.hu/robots.txt

Egy általános engedélyező beállítás például:

User-agent: *
Disallow:

Sitemap: https://domain.hu/sitemap_index.xml

Egy ilyen szabály viszont a teljes webhelyet blokkolhatja:

User-agent: *
Disallow: /

Figyelj arra, hogy külön szabálycsoportok is szerepelhetnek a fájlban:

User-agent: Googlebot
Disallow:

User-agent: OAI-SearchBot
Disallow:

User-agent: GPTBot
Disallow: /

Ebben a példában a Googlebot és az OpenAI keresési robotja hozzáférhet a webhelyhez, a GPTBot viszont nem.

A robots.txt a lekérést szabályozza, de nem garantálja, hogy egy URL biztosan kimarad a keresési indexből. A Google szerint egy robots.txt által blokkolt URL külső hivatkozások alapján URL-szinten továbbra is megjelenhet a találatok között. A biztos kizáráshoz megfelelő noindex utasítás vagy hozzáférés-védelem szükséges.

Hogyan ellenőrizd az OpenAI robotjait?

A ChatGPT keresési megjelenéséhez elsősorban azt ellenőrizd, hogy az OAI-SearchBot nincs-e blokkolva a robots.txt fájlban. A GPTBot ettől eltérő feladatot lát el, ezért a két user-agentet ne kezeld automatikusan azonos módon.

Az OpenAI hivatalos tájékoztatása szerint az OAI-SearchBot hozzáférésének engedélyezése segíti, hogy a nyilvános weboldal tartalma megjelenhessen a ChatGPT keresési összefoglalóiban, idézeteiben és hivatkozásaiban. A GPTBot külön user-agent, amelynek kezelése a potenciális modelltréninggel kapcsolatos webhelytulajdonosi döntéshez kötődik.

Engedélyező példa:

User-agent: OAI-SearchBot
Disallow:

A naplóban többek között erre a user-agentre keress:

OAI-SearchBot

Fontos, hogy az engedélyezés még nem bizonyítja a látogatást. A tényleges lekérést továbbra is a szervernaplóban kell megkeresned.

A ChatGPT-ből érkező felhasználói forgalmat az analitikai rendszerben is figyelheted. Az OpenAI tájékoztatása szerint a ChatGPT keresési hivatkozások utm_source=chatgpt.com paramétert tartalmazhatnak. Ez azonban felhasználói átkattintást, nem pedig robotlátogatást bizonyít.

Hogyan ellenőrizd a Perplexity robotját?

A Perplexity keresési feltérképezéséhez a PerplexityBot user-agentet keresd a robots.txt fájlban és a szervernaplóban.

A Perplexity hivatalos dokumentációja szerint a PerplexityBot a webhelyek keresési eredményekben történő megjelenítését és hivatkozását támogatja. A szolgáltató külön kezeli a felhasználói kérésekhez kapcsolódó Perplexity-User hozzáférést.

Engedélyező példa:

User-agent: PerplexityBot
Disallow:

A naplókban ezeket érdemes külön kezelni:

PerplexityBot
Perplexity-User

Ne vond le automatikusan azt a következtetést, hogy a Perplexity-User látogatása rendszeres indexelő crawl volt. Az ilyen kérés egy konkrét felhasználói művelethez is kapcsolódhat.

Hogyan ellenőrizd az Anthropic robotjait?

Az Anthropic robotjainál a hivatalosan megadott user-agenteket kell ellenőrizned a robots.txt fájlban és a hozzáférési naplókban.

Az Anthropic tájékoztatása szerint robotjai tiszteletben tartják a robots.txt tiltásait, és egyes esetekben a nem szabványos Crawl-delay utasítást is támogatják. A szabályokat minden érintett aldomainen külön kell beállítani.

Példa a hozzáférés engedélyezésére:

User-agent: ClaudeBot
Disallow:

A túl gyakori crawl lassítására használható lehet:

User-agent: ClaudeBot
Crawl-delay: 1

Ezt azonban csak akkor alkalmazd, ha ténylegesen terhelési problémát tapasztalsz, mert a crawl lassítása a friss tartalmak felfedezését is késleltetheti.

Hogyan ellenőrizd, hogy a robot a teljes tartalmat is látja-e?

Nem elég, hogy a robot 200-as választ kapjon: azt is meg kell vizsgálnod, hogy a válaszban vagy a renderelt oldalon valóban szerepel-e a fő tartalom, a linkek és a strukturált adat.

Ez különösen fontos JavaScript-alapú weboldalaknál.

Ellenőrizd:

• benne van-e a fő szöveg a kezdeti HTML-ben;
• megjelenik-e a renderelt HTML-ben;
• elérhetők-e a JavaScript- és CSS-fájlok;
• normál <a href=""> linkként jelennek-e meg a belső hivatkozások;
• betöltődik-e a navigáció;
• megjelennek-e a termékadatok;
• betöltődik-e a strukturált adat;
• nincs-e JavaScript-hiba;
• nem csak felhasználói kattintás után jelenik-e meg a fontos tartalom.

A Google a JavaScript-oldalakat külön crawl- és renderelési folyamatban dolgozhatja fel. Ha egy oldal vagy fontos erőforrás robots.txt által blokkolt, a Google nem feltétlenül tudja megfelelően renderelni a tartalmat.

Milyen szerver- és biztonsági beállítások blokkolhatják a robotokat?

A robots.txt akkor is engedélyezheti a hozzáférést, ha közben a tűzfal, a CDN vagy egy biztonsági bővítmény mégis visszautasítja a robot kérését.

Ellenőrizd:

• a Cloudflare és más CDN-szabályokat;
• a webalkalmazási tűzfalat;
• a tárhely botvédelmi funkcióit;
• a WordPress biztonsági bővítményeket;
• az IP-alapú tiltásokat;
• az ország szerinti blokkolást;
• a túl szigorú rate limitet;
• a CAPTCHA megjelenését;
• a bejelentkezési kötelezettséget;
• a cookie-fal mögé került tartalmat;
• a 403-as és 429-es válaszokat;
• az időszakos 5xx hibákat.

Egy robot számára a következő válaszok különösen problémásak lehetnek:

Ha a Googlebot rendszeresen 5xx hibákat vagy túl hosszú válaszidőt tapasztal, csökkentheti a webhelyen végzett feltérképezés intenzitását.

Hogyan készíts gyors robotellenőrzési folyamatot?

Egy fontos URL vizsgálatához használd ugyanazt a rövid ellenőrzési sorrendet minden alkalommal.

1. Nyisd meg az URL-t normál böngészőben.
2. Ellenőrizd a HTTP-státuszkódot.
3. Vizsgáld meg a robots.txt szabályait.
4. Keresd meg a robots meta és az X-Robots-Tag utasításokat.
5. Ellenőrizd a canonical URL-t.
6. Nézd meg az URL-t a Search Console-ban.
7. Futtass élő URL-tesztet.
8. Ellenőrizd a renderelt oldalt.
9. Keresd meg az URL-t a szervernaplóban.
10. Szűrj a Googlebot és az engedélyezett AI-user-agentek neveire.
11. Hitelesítsd a fontos robotkérések IP-címét, ahol erre van hivatalos módszer.
12. Ellenőrizd, hogy 200-as választ kaptak-e.
13. Nézd meg, nem blokkolja-e őket tűzfal vagy CDN.
14. Hasonlítsd össze a crawl dátumát az oldal utolsó frissítésével.

Milyen eredményt rögzíts a technikai SEO auditban?

Az auditjelentésben robotonként és URL-csoportonként dokumentáld a hozzáférést, a tényleges látogatást és a tapasztalt hibákat.

A legfontosabb bizonyíték tehát nem az, hogy egy SEO-eszköz szerint az oldal „crawlolható”, hanem az, hogy a hitelesített robotkérés ténylegesen megjelent a szervernaplóban, elérte a kívánt URL-t, és megfelelő HTTP-választ kapott. A Search Console megmutatja a Google állapotát, a robots.txt és az élő tesztek a hozzáférés lehetőségét, a logelemzés pedig a valódi robottevékenységet.

Milyen indexelési hibákat kell keresned?

Az indexelési hibák azok a problémák, amelyek miatt a Google és az AI-alapú keresők nem tudják vagy nem akarják felvenni a weboldalad oldalait az indexükbe. Ha egy oldal nincs megfelelően indexelve, gyakorlatilag esélye sincs arra, hogy organikus forgalmat hozzon.

Az egyik leggyakoribb tévhit, hogy minden létrehozott oldal automatikusan megjelenik a Google találatai között. A valóságban a keresőmotorok folyamatosan eldöntik, hogy egy adott URL érdemes-e az indexelésre. Ha technikai hibát, duplikációt vagy gyenge minőségű tartalmat találnak, előfordulhat, hogy az oldalt nem veszik fel az indexbe, vagy később el is távolítják onnan.

Éppen ezért egy technikai SEO audit során az indexelési problémák felderítése az egyik legfontosabb feladat.

Hibás noindex beállítások

Az egyik legsúlyosabb indexelési hiba, amikor egy fontos oldal véletlenül noindex utasítást kap.

A noindex arra utasítja a keresőmotorokat, hogy az adott oldalt ne vegyék fel az indexükbe. Ez hasznos lehet például:

• belső keresési találatoknál;
• adminisztrációs oldalaknál;
• kosár és pénztár oldalaknál;
• köszönőoldalaknál;
• tesztoldalaknál.

Komoly problémát jelent viszont, ha ilyen utasítás kerül például:

• szolgáltatási oldalakra;
• kategóriaoldalakra;
• termékoldalakra;
• blogcikkekre;
• tudásbázis oldalakra.

Audit során mindig ellenőrizd:

• HTML meta robots címkét;
• X-Robots-Tag HTTP fejlécet;
• WordPress SEO bővítmények beállításait;
• fejlesztésből bent maradt tiltásokat.

A Google feltérképezte az oldalt, de nem indexelte

A „Feltérképezve – jelenleg nincs indexelve” állapot arra utal, hogy a Google már meglátogatta az oldalt, de egyelőre nem tartotta megfelelőnek az indexeléshez.

Ez több okból is előfordulhat:

• kevés egyedi tartalom;
• gyenge minőség;
• túl rövid oldal;
• duplikáció;
• rossz belső linkelés;
• kevés külső hivatkozás;
• alacsony hozzáadott érték.

Ez gyakran előfordul például:

• automatikusan létrejött címkeoldalakon;
• nagyon hasonló termékoldalakon;
• vékony tartalmú szolgáltatási oldalakon.

Az oldal ismert, de még nem térképezte fel a Google

A „Felfedezve – jelenleg nincs indexelve” állapot azt jelenti, hogy a Google tud az URL létezéséről, de még nem látogatta meg.

Ennek oka lehet:

• alacsony crawl budget;
• túl sok új URL;
• lassú szerver;
• hibás sitemap;
• kevés belső link.

Nagy webáruházaknál vagy több tízezer cikket tartalmazó tudásbázisoknál ez gyakran előfordul.

Hibás canonical címkék

A rosszul beállított canonical címke miatt a Google egy másik URL-t tekinthet elsődlegesnek, így az eredeti oldal nem kerül indexelésre.

Ellenőrizd, hogy a canonical:

• önmagára mutat-e;
• létező oldalra mutat-e;
• nem irányít-e át;
• nem 404-es oldalra vezet-e;
• nem mutat-e másik nyelvi verzióra.

Egy hibás canonical akár teljes kategóriák eltűnését is okozhatja a keresőből.

Duplikált tartalom

Ha ugyanaz vagy nagyon hasonló tartalom több URL-en is elérhető, a Google gyakran csak egy változatot indexel.

Leggyakoribb okok:

• HTTP és HTTPS változat;
• www és nem-www;
• paraméteres URL-ek;
• szűrések;
• rendezések;
• nyomtatható verziók;
• több kategóriában szereplő termékek.

Ilyenkor nem feltétlenül hiba történik, de fontos biztosítani, hogy a kereső a megfelelő verziót válassza.

Soft 404 hibák

A Soft 404 olyan oldal, amely ugyan 200-as státuszkódot ad vissza, de valójában nem tartalmaz értékes információt.

Tipikus példák:

• üres kategóriaoldalak;
• „Nincs találat” oldalak;
• kifutott termékek rossz kezelése;
• automatikusan generált üres oldalak.

A Google ezeket gyakran hibás oldalnak tekinti.

Robots.txt által blokkolt fontos oldalak

Ha a robots.txt tiltja egy fontos URL feltérképezését, a Google nem tudja megfelelően feldolgozni az oldalt.

Audit során ellenőrizd:

• fontos könyvtárak;
• blog;
• szolgáltatások;
• termékoldalak;
• képek;
• JavaScript;
• CSS.

Sok fejlesztés után véletlenül bent maradnak korábbi tiltások.

Hibás XML sitemap

Az XML sitemapnek csak olyan oldalakat szabad tartalmaznia, amelyeket valóban indexelni szeretnél.

Gyakori hibák:

• 404-es URL-ek;
• 301-es átirányítások;
• noindex oldalak;
• hibás domain;
• régi URL-ek;
• hiányzó új oldalak.

A sitemapet mindig hasonlítsd össze a Search Console adataival.

Hibás HTTP státuszkódok

A nem megfelelő státuszkódok megakadályozhatják az indexelést vagy félrevezethetik a keresőrobotokat.

Figyelj különösen:

Árva oldalak (Orphan Pages)

Az árva oldalak olyan URL-ek, amelyekre semmilyen belső hivatkozás nem mutat, ezért a keresőrobotok nehezebben találják meg őket.

Előfordulhatnak:

• kampányoldalak;
• régi blogcikkek;
• elfelejtett szolgáltatási oldalak;
• manuálisan létrehozott landing oldalak.

Ha egy oldal csak az XML sitemapben szerepel, de a webhely navigációjából nem érhető el, kisebb az esélye a rendszeres feltérképezésnek.

Átirányítási láncok és hurkok

A túl sok egymásra épülő átirányítás lassítja a feltérképezést és ronthatja az indexelés hatékonyságát.

Például:

régi oldal
↓
301
↓
új oldal
↓
301
↓
végleges oldal

Helyette mindig közvetlen átirányítást használj.

JavaScript miatt nem látható tartalom

Ha a fontos tartalom csak JavaScript betöltése után jelenik meg, előfordulhat, hogy a keresőrobotok nem dolgozzák fel megfelelően.

Ellenőrizd:

• renderelt HTML;
• belső linkek;
• menürendszer;
• termékleírások;
• kategóriák;
• strukturált adatok.

Ez különösen gyakori modern JavaScript keretrendszereknél.

Gyenge minőségű vagy vékony tartalom

Nem minden indexelési probléma technikai eredetű. A Google akkor is dönthet úgy, hogy nem indexel egy oldalt, ha az nem nyújt elegendő értéket a felhasználóknak.

Ez jellemző lehet:

• néhány mondatos szolgáltatási oldalakra;
• automatikusan generált kategóriákra;
• ismétlődő termékleírásokra;
• kevés információt tartalmazó blogbejegyzésekre.

Egy SEO audit során ezért mindig együtt kell vizsgálni a technikai és a tartalmi tényezőket.

Hogyan ellenőrizheted az indexelési hibákat?

Az indexelési problémák feltárásához több eszközt is érdemes kombinálni, mert egyik sem mutat teljes képet önmagában.

Mely indexelési hibákat javítsd először?

Nem minden indexelési hiba ugyanolyan súlyú. Először mindig azokat a problémákat javítsd, amelyek megakadályozzák a fontos oldalak megjelenését a keresőben.

Ajánlott prioritási sorrend:

1. Hibás noindex beállítások.
2. Robots.txt blokkolások.
3. 5xx szerverhibák.
4. Hibás canonical címkék.
5. Hibás XML sitemap.
6. Soft 404 oldalak.
7. Árva oldalak.
8. Duplikált tartalmak.
9. Átirányítási láncok.
10. Vékony vagy ismétlődő tartalom.

Egy professzionális technikai SEO audit során az indexelési hibák feltárása az egyik legnagyobb hatású feladat. Ha a fontos oldalak megfelelően feltérképezhetők, indexelhetők és egyértelműen értelmezhetők, akkor a Google és az AI-alapú keresők sokkal nagyobb eséllyel jelenítik meg őket a keresési eredményekben és az AI által generált válaszokban.

Hogyan ellenőrizd a weboldal teljesítményét és Core Web Vitals értékeit?

A weboldal teljesítményét nem egyetlen sebességpontszám alapján kell megítélned. A professzionális ellenőrzés során külön kell vizsgálnod a valódi látogatóktól származó terepadatokat, a tesztkörnyezetben mért laboradatokat, valamint az egyes oldaltípusokat mobilon és asztali gépen.

Egy weboldal lehet gyors egy erős irodai számítógépen és stabil internetkapcsolaton, miközben egy középkategóriás mobiltelefonon, mobilinterneten már lassan reagál. Ezért a technikai SEO auditban nem elég egyszer lefuttatnod egy PageSpeed Insights tesztet a kezdőoldalon.

A cél annak megállapítása, hogy:

• milyen gyorsan jelenik meg a fő tartalom;
• mennyire gyorsan reagál az oldal a kattintásokra;
• történnek-e váratlan elrendezésváltozások;
• mely sablonok és oldaltípusok teljesítenek rosszul;
• milyen technikai elemek okozzák a lassulást;
• a problémák valódi felhasználókat is érintenek-e.

Mit mérnek a Core Web Vitals mutatók?

A Core Web Vitals három felhasználói élményt mérő mutatóból áll: az LCP a betöltést, az INP az interaktivitást, a CLS pedig a vizuális stabilitást értékeli.

A Google jelenlegi ajánlása szerint a jó felhasználói élményhez az LCP-nek legfeljebb 2,5 másodpercnek, az INP-nek legfeljebb 200 ezredmásodpercnek, a CLS-nek pedig 0,1-nél kisebbnek kell lennie. Az értékelésnél a látogatások 75. percentilisét veszik figyelembe, külön mobilos és asztali környezetben.

Mi az a Largest Contentful Paint?

Az LCP azt méri, mennyi idő alatt jelenik meg a felhasználó számára a látható területen található legnagyobb tartalmi elem.

Ez az elem gyakran:

• a hero kép;
• egy nagy címsor;
• egy termékkép;
• egy cikk kiemelt képe;
• egy háttérkép;
• egy nagy szövegblokk.

Ha az LCP értéke gyenge, a látogató azt érzékeli, hogy az oldal lassan tölti be a lényegi tartalmát, még akkor is, ha a fejléc vagy néhány kisebb elem már megjelent.

Az LCP romlását gyakran a következők okozzák:

• lassú szerverválasz;
• túl nagy hero kép;
• rosszul tömörített képfájl;
• renderelést blokkoló CSS;
• későn betöltődő webfont;
• kliensoldali JavaScript-renderelés;
• túl sok külső erőforrás;
• az LCP-kép indokolatlan lazy loading beállítása.

Egy menyasszonyi ruhaszalon oldalán például a főoldali, több megabájtos teljes képernyős fotó lehet az LCP-elem. Egy SEO-szolgáltatói oldalon viszont egy egyedi betűtípussal megjelenített nagy főcím késleltetheti a legnagyobb elem kirajzolását.

Mi az az Interaction to Next Paint?

Az INP azt vizsgálja, milyen gyorsan ad látható visszajelzést az oldal a látogató kattintásaira, koppintásaira és billentyűzetes műveleteire.

Az INP nem csupán az első interakciót méri. Az oldal használata közben bekövetkező kattintások, érintések és billentyűzetes műveletek késleltetését figyeli, majd ezek alapján értékeli az oldal általános válaszkészségét.

Gyenge INP-értéket okozhat:

• hosszú JavaScript-feladat;
• túl sok egyidejű eseménykezelő;
• bonyolult menürendszer;
• nehéz kereső- vagy szűrőfunkció;
• nagy DOM-méret;
• lassú harmadik féltől származó script;
• túlbonyolított WordPress-bővítmény;
• egyszerre túl sok elem újrarenderelése.

Tipikus példa, amikor a felhasználó megnyomja a mobilmenü gombját, de a menü csak fél másodperccel később nyílik meg. Webáruháznál a termékszűrő, a kosárgomb vagy a variációválasztó lassú reakciója is INP-problémát jelezhet.

Mi az a Cumulative Layout Shift?

A CLS azt méri, hogy a látható elemek mennyire mozdulnak el váratlanul az oldal használata közben.

Ilyen elmozdulás történhet például akkor, ha:

• egy kép méretfoglalás nélkül töltődik be;
• egy hirdetés utólag jelenik meg;
• a cookie-sáv eltolja a tartalmat;
• a webfont betöltése megváltoztatja a szöveg méretét;
• egy felugró ajánlat átrendezi az oldalt;
• egy dinamikusan betöltött blokk a meglévő tartalom fölé kerül.

A CLS nem az összes elmozdulás egyszerű összege, hanem az oldal teljes életciklusa alatt bekövetkező váratlan elrendezésváltozások legnagyobb csoportját értékeli.

A probléma különösen zavaró, amikor a felhasználó már rákattintana egy gombra, de az elem hirtelen elmozdul, és helyette egy másik hivatkozást nyom meg.

Mi a különbség a terepadat és a laboradat között?

A terepadat valódi felhasználók böngészési körülményeit mutatja, a laboradat pedig egy előre meghatározott tesztkörnyezetben végzett mérés eredménye. A végső értékeléshez mindkettőre szükséged van.

A PageSpeed Insights egyszerre jeleníthet meg Chrome UX Reportból származó terepadatokat és Lighthouse-alapú laboreredményeket.

A két eredmény eltérhet egymástól. Ennek oka lehet például:

• eltérő eszközteljesítmény;
• eltérő hálózati sebesség;
• földrajzi különbség;
• bejelentkezett és kijelentkezett látogatók eltérő élménye;
• gyorsítótár használata;
• felhasználói interakciók;
• hirdetések és külső scriptek változó működése;
• a laborvizsgálat egyetlen oldalbetöltése.

A Google webes teljesítményről szóló dokumentációja külön felhívja a figyelmet arra, hogy a labor- és terepadatok akár mindhárom Core Web Vitals mutatónál eltérhetnek.

Hogyan ellenőrizd az adatokat a Google Search Console-ban?

A Search Console Core Web Vitals jelentésével azt ellenőrizheted, hogy a Google valós felhasználói adatai alapján mely URL-csoportok teljesítenek jól, fejlesztendően vagy gyengén.

A jelentésben külön vizsgáld:

• a mobilos eredményeket;
• az asztali eredményeket;
• a gyenge URL-csoportokat;
• a fejlesztendő URL-csoportokat;
• az érintett Core Web Vitals mutatót;
• a hasonló sablon alapján csoportosított URL-eket;
• a probléma időbeli változását.

A Search Console jellemzően nem minden URL-t jelenít meg külön. Hasonló technikai jellemzőkkel rendelkező oldalakat csoportosíthat, ezért egy hibás termékoldalsablon akár több száz URL-t is érinthet.

A jelentés elemzésekor először azt nézd meg, hogy:

1. melyik mutató hibás;
2. mobilon vagy asztali gépen jelentkezik-e;
3. hány URL-t érint;
4. melyik sablontípushoz tartoznak az oldalak;
5. történt-e változás a hiba megjelenése előtt.

Ha például kizárólag a blogcikkek LCP-értéke gyenge, valószínűleg a cikkek kiemelt képe, a sablon vagy egy blogoldalakon betöltődő bővítmény okozza a problémát.

Hogyan használd a PageSpeed Insights eszközt?

A PageSpeed Insights segítségével külön megvizsgálhatod egy URL terepadatait, laboreredményeit és a javítási lehetőségeket.

A vizsgálat során ne csak a 0–100 közötti teljesítménypontszámot nézd meg. Ez a Lighthouse által számított összesített laborpontszám, amely több mutatóból, súlyozott rendszerben áll össze.

Ehelyett ellenőrizd:

• megfelel-e az URL a Core Web Vitals követelményeknek;
• van-e URL-szintű terepadat;
• ha nincs, elérhető-e domain- vagy origin-szintű adat;
• melyik elem az LCP;
• milyen hosszú feladatok rontják az interaktivitást;
• mely elemek okoznak elrendezésváltozást;
• mennyi a TTFB;
• milyen erőforrások blokkolják a renderelést;
• mennyi nem használt CSS és JavaScript töltődik be;
• megfelelően vannak-e méretezve a képek;
• mely külső scriptek lassítják az oldalt.

Ne csak egyszer futtasd le a tesztet. A laboreredmény a szerver terhelése és a mérési körülmények miatt változhat, ezért érdemes legalább három mérést végezni, majd a tipikus eredményt értékelni.

Hogyan futtass Lighthouse-vizsgálatot a Chrome böngészőben?

A Lighthouse részletes laborvizsgálatot készít a teljesítményről, és megmutatja, mely technikai elemek okozzák a lassulást.

A Chrome böngészőben:

1. nyisd meg a vizsgált oldalt;
2. nyomd meg az F12 billentyűt;
3. válaszd a Lighthouse panelt;
4. jelöld ki a mobilos vagy asztali módot;
5. válaszd a teljesítményvizsgálatot;
6. indítsd el az elemzést;
7. mentsd el az eredményt összehasonlítás céljából.

A Lighthouse nyilvános és bejelentkezést igénylő weboldalakon egyaránt futtatható, és a teljesítmény mellett többek között hozzáférhetőségi, SEO- és bevált gyakorlatokra vonatkozó auditokat is tartalmaz.

A pontosabb méréshez:

• használj inkognitóablakot;
• kapcsold ki a böngészőbővítményeket;
• ne futtass közben más erőforrás-igényes programot;
• minden teszt előtt töltsd újra az oldalt;
• ugyanazzal az eszköz- és hálózati beállítással mérj;
• külön vizsgáld a mobilos és asztali nézetet.

Hogyan használd a Chrome DevTools Performance paneljét?

A Performance panellel részletesen megvizsgálhatod, mi történik a böngésző fő szálán az oldal betöltése és használata közben.

Ez az eszköz különösen akkor hasznos, ha:

• lassan nyílik meg a menü;
• késve reagál a gomb;
• akadozik a görgetés;
• lassú a termékszűrés;
• egy interakció után lefagy az oldal;
• túl sok JavaScript fut;
• hosszú főszál-feladatok jelennek meg.

A felvétel során hajts végre valós műveleteket:

• nyisd meg a mobilmenüt;
• kattints a CTA-gombra;
• használj termékszűrőt;
• nyiss meg lenyíló elemet;
• tölts ki űrlapot;
• tegyél terméket a kosárba;
• válts képet a galériában.

Ezután keresd:

• a hosszú feladatokat;
• a JavaScript-végrehajtás idejét;
• a stílus-újraszámítást;
• az elrendezési műveleteket;
• a renderelési késéseket;
• a harmadik féltől származó scripteket;
• a hirtelen elrendezésváltozásokat.

Milyen további teljesítménymutatókat érdemes ellenőrizned?

A Core Web Vitals mellett több diagnosztikai mutató is segít megtalálni a lassulás valódi okát.

Ezek nem mind Core Web Vitals mutatók, de segítenek megérteni, miért gyenge az LCP, az INP vagy a CLS.

Milyen oldalakat mérj meg?

Ne csak a kezdőoldalt vizsgáld, hanem minden fontos sablontípusból válassz több reprezentatív URL-t.

Egy általános szolgáltatói weboldalon vizsgáld meg:

• a kezdőoldalt;
• egy fő szolgáltatási oldalt;
• egy aloldalt;
• egy hosszú blogcikket;
• egy kapcsolatfelvételi oldalt;
• egy nagy képgalériát tartalmazó oldalt.

Webáruháznál ezen felül:

• kategóriaoldalt;
• alkategóriaoldalt;
• termékoldalt;
• szűrt találati oldalt;
• kosarat;
• pénztárt;
• belső keresési találatot.

Egyetlen gyors kezdőoldal nem bizonyítja, hogy a teljes webhely jól teljesít. Gyakran éppen a termékoldal, a hosszú cikk, a galéria vagy a kapcsolatfelvételi űrlap a leglassabb.

Hogyan vizsgáld meg a mobilos teljesítményt?

A mobilos eredményeket kezeld elsődleges vizsgálati területként, mert a látogatók gyengébb processzorral, kisebb memóriával és lassabb hálózattal is használhatják az oldaladat.

Mobilon különösen figyelj:

• a nagyméretű képekre;
• a mobilmenü reakcióidejére;
• a túl sok JavaScriptre;
• a felugró ablakokra;
• a ragadós fejlécre;
• a cookie-kezelőre;
• a mobilon betöltődő külön scriptekre;
• a külső betűkészletekre;
• a háttérvideókra;
• az érintésre reagáló elemekre.

A mobilos mérésnél ne csak a böngészőben szimulált nézetet használd. Ellenőrizd az oldalt valódi telefonon és mobilinternet-kapcsolaton is.

Hogyan keresd meg az LCP-probléma okát?

Az LCP javításánál először azonosítsd az LCP-elemet, majd külön vizsgáld meg a szerverválaszt, az erőforrás felfedezését, a letöltési időt és a renderelési késést.

Ellenőrizd:

• mi az LCP-elem;
• a kezdeti HTML-ben szerepel-e;
• túl nagy-e a fájl;
• megfelelő képformátumot használ-e;
• kapott-e magas betöltési prioritást;
• nem lazy loadinggal töltődik-e;
• blokkolja-e CSS vagy JavaScript;
• késlelteti-e a betűkészlet;
• lassú-e a szerverválasz;
• CDN-en keresztül érkezik-e.

A gyakorlatban először a TTFB-t érdemes megvizsgálni. Ha a szerver csak hosszú idő után kezdi el visszaküldeni a HTML-t, a képek tömörítése önmagában nem fogja megoldani a teljes LCP-problémát.

Hogyan keresd meg az INP-probléma okát?

Az INP javításához azt kell azonosítanod, mely felhasználói interakciók váltanak ki hosszú JavaScript-feladatokat vagy lassú renderelést.

Vizsgáld meg:

• mely gombokra reagál lassan az oldal;
• mely eseménykezelők futnak;
• mennyi ideig foglalt a fő szál;
• felbonthatók-e a hosszú JavaScript-feladatok;
• szükséges-e minden betöltött script;
• késleltethetők-e harmadik fél kódjai;
• túl sok elemet frissít-e egy interakció;
• optimalizálható-e a DOM;
• alkalmazható-e szerveroldali renderelés;
• csökkenthető-e a bővítmények száma.

WordPress-oldalakon különösen gyakori ok lehet:

• vizuális oldalépítő;
• több animációs bővítmény;
• nehéz menürendszer;
• élő chat;
• hőtérkép;
• közösségi média script;
• rosszul optimalizált kapcsolatfelvételi űrlap;
• több, egymással átfedő optimalizáló bővítmény.

Hogyan keresd meg a CLS-probléma okát?

A CLS javításához azonosítsd azokat az elemeket, amelyek betöltődés után helyet foglalnak vagy megváltoztatják a már megjelent tartalom méretét.

Ellenőrizd:

• van-e szélesség és magasság megadva a képeknél;
• foglalsz-e helyet a hirdetéseknek;
• eltolja-e a cookie-sáv az oldalt;
• megváltoztatja-e a webfont a szövegtörést;
• kerül-e új tartalom a meglévő tartalom fölé;
• változik-e a fejléc magassága;
• okoz-e elmozdulást a ragadós navigáció;
• töltesz-e be dinamikus ajánlódobozt;
• elmozdulnak-e az űrlapelemek hibaüzenet megjelenésekor.

Az elrendezést módosító CSS-animációk szintén növelhetik a CLS-t. A Google teljesítményre vonatkozó útmutatója szerint az olyan tulajdonságok animálása, mint a top, left, margin vagy a szegélyméret, könnyebben idéz elő elrendezésváltozást, mint a transform használata.

Hogyan mérj saját valós felhasználói adatokat?

Nagyobb vagy üzletileg fontos weboldalnál érdemes saját Real User Monitoring rendszert kialakítani, mert a nyilvános CrUX-adatok nem minden URL-hez és látogatói csoporthoz biztosítanak elegendő részletet.

A saját mérésben rögzítheted:

• az URL-t;
• az oldaltípust;
• az eszközt;
• a böngészőt;
• a hálózati kapcsolatot;
• az országot;
• az LCP-elemet;
• a lassú interakció típusát;
• a CLS-t okozó elemet;
• a bejelentkezési állapotot;
• az adott kiadási vagy sablonverziót.

Ez segít megállapítani például, hogy:

• csak iPhone-on rossz-e az INP;
• csak mobilinterneten lassú-e az LCP;
• egy adott ország látogatói tapasztalnak-e magas TTFB-t;
• egy új cookie-kezelő után romlott-e a CLS;
• kizárólag a bejelentkezett ügyfelek felülete lassú-e.

A CrUX és a saját RUM-rendszer eltérő adatokat mutathat, mert nem feltétlenül ugyanazokat a felhasználókat, oldalakat és mérési feltételeket tartalmazzák.

Hogyan priorizáld a teljesítményhibákat?

Először a valódi felhasználói adatokkal igazolt, sok fontos URL-t érintő problémákat javítsd, ne pedig a legkönnyebben módosítható apró figyelmeztetéseket.

Javasolt prioritási sorrend:

Ne kizárólag a Lighthouse 100-as pontszám elérésére törekedj. A Google szerint a jó Core Web Vitals értékek támogatják a felhasználói élményt és a keresési teljesítményt, de önmagukban nem garantálnak magas rangsorolást. A tökéletes eszközpontszám hajszolása nem feltétlenül a legjobb erőforrás-felhasználás.

Hogyan ellenőrizd a javítások eredményét?

Minden teljesítményjavítás után ugyanazon oldalakon, azonos mérési feltételekkel ismételd meg a laborvizsgálatokat, majd figyeld meg, hogy a terepadatokban is megjelenik-e a javulás.

A folyamat:

1. rögzítsd a kiinduló értékeket;
2. dokumentáld a módosítást;
3. futtasd újra a Lighthouse-t;
4. ellenőrizd a PageSpeed Insights laboreredményét;
5. teszteld az oldalt valódi telefonon;
6. vizsgáld meg az érintett interakciókat;
7. ellenőrizd, nem romlott-e másik mutató;
8. figyeld a saját RUM-adatokat;
9. kövesd a Search Console Core Web Vitals jelentését;
10. csak igazolt javulás után zárd le a feladatot.

A terepadatok nem azonnal frissülnek, ezért előfordulhat, hogy a laboreredmény már javulást mutat, miközben a Search Console jelentésében még a korábbi állapot látható.

Core Web Vitals ellenőrzési lista

A teljesítményvizsgálat akkor tekinthető alaposnak, ha minden fontos sablont, eszköztípust és mérési adatforrást lefed.

• Ellenőrizted a Search Console mobilos jelentését.
• Ellenőrizted az asztali jelentést.
• Megvizsgáltad az LCP, INP és CLS értékeket.
• Külön kezelted a terep- és laboradatokat.
• Több fontos URL-típust teszteltél.
• Legalább három laborvizsgálatot futtattál.
• Azonosítottad az LCP-elemet.
• Tesztelted a valódi felhasználói interakciókat.
• Megkerested a CLS-t okozó elemeket.
• Ellenőrizted a TTFB-t.
• Megvizsgáltad a képek méretét és formátumát.
• Ellenőrizted a JavaScript főszálterhelését.
• Megvizsgáltad a külső scripteket.
• Valódi mobiltelefonon is teszteltél.
• Dokumentáltad a kiinduló eredményeket.
• A javítások után ismételt mérést végeztél.

A professzionális teljesítményaudit nem azt kérdezi, hogy a weboldal hány pontot kapott egyetlen teszten, hanem azt, hogy a valódi látogatók gyorsan látják-e a fő tartalmat, az oldal azonnal reagál-e a műveleteikre, és használat közben stabil marad-e. A Search Console és a CrUX megmutatja a valós problémát, a PageSpeed Insights, a Lighthouse és a DevTools pedig segít feltárni annak technikai okát.

Milyen strukturált adatok hiányozhatnak az oldaladról?

"author": "Kiss Péter"

"author": {
  "@id": "https://pelda.hu/szerzo/kiss-peter/#person"
}

Hogyan vizsgáld meg a belső linkelési rendszert?

A belső linkelési rendszer vizsgálatakor azt kell ellenőrizned, hogy a fontos oldalak könnyen felfedezhetők-e, megfelelő mennyiségű és minőségű hivatkozást kapnak-e, valamint a linkek világosan mutatják-e a webhely témái közötti kapcsolatokat.

A belső linkelés nem csupán navigációs kérdés. Meghatározza, hogy a keresőrobotok milyen útvonalon járják be a weboldalt, mely tartalmakat tartják fontosnak, hogyan értelmezik a témakörök kapcsolatát, és milyen gyorsan fedezik fel az új oldalakat.

Egy jó belső linkelési rendszer egyszerre segíti:

• a látogatókat;
• a Google feltérképezését;
• az indexelést;
• a webhely hierarchiájának megértését;
• a témaklaszterek kialakítását;
• az oldalak közötti relevancia átadását;
• az AI-alapú keresőrendszerek tartalomértelmezését.

Miért fontos a belső linkelés egy technikai SEO auditban?

A belső linkek mutatják meg a keresőrobotoknak, hogyan kapcsolódnak egymáshoz az oldalak, és mely URL-ek töltenek be központi szerepet a webhelyen.

Ha egy oldal sok releváns belső hivatkozást kap, az rendszerint azt jelzi, hogy fontos része a webhely struktúrájának. Ha viszont egy értékes tartalomra egyetlen másik oldal sem mutat, a kereső nehezebben találja meg, ritkábban térképezheti fel, és kevésbé értheti meg a szerepét.

A belső linkelés segít:

• az új URL-ek felfedezésében;
• a mélyen elhelyezkedő oldalak elérésében;
• a fő témák és altémák elkülönítésében;
• a kulcsoldalak fontosságának jelzésében;
• a felhasználói útvonalak kialakításában;
• a kapcsolódó tartalmak összekötésében;
• a linkérték webhelyen belüli elosztásában.

Hogyan térképezd fel a teljes belső linkhálózatot?

A vizsgálatot egy teljes webhely-crawllal kezdd, majd exportáld az egyes URL-ek bejövő és kimenő belső linkjeit.

Erre használhatsz például:

• Screaming Frog SEO Spider;
• Sitebulb;
• Ahrefs Site Audit;
• Semrush Site Audit;
• JetOctopus;
• Oncrawl.

A crawl során gyűjtsd össze:

• az összes indexelhető URL-t;
• az egyes oldalakra mutató belső linkek számát;
• az egyes oldalakról kimenő linkek számát;
• a linkek anchor szövegét;
• a kattintási mélységet;
• a link forrásoldalát;
• a link céloldalát;
• a link státuszkódját;
• a nofollow attribútumokat;
• a navigációs, tartalmi és láblécből érkező linkeket.

A cél nem az, hogy egyszerűen megszámold a linkeket, hanem hogy megértsd a webhely szerkezetét.

Mely oldalakat tekintsd kiemelten fontosnak?

Először határozd meg azokat az URL-eket, amelyek üzleti, tartalmi vagy keresési szempontból a legfontosabbak, majd ellenőrizd, hogy megfelelő belső támogatást kapnak-e.

Ilyenek lehetnek:

• fő szolgáltatási oldalak;
• fontos kategóriaoldalak;
• kiemelt termékoldalak;
• pillar tartalmak;
• magas konverziós értékű landing oldalak;
• jelentős organikus forgalmat hozó cikkek;
• újonnan létrehozott stratégiai oldalak;
• kapcsolatfelvételi vagy ajánlatkérő oldalak.

Egy SEO-szolgáltatói weboldalon például a SEO audit, a havidíjas keresőoptimalizálás és a SEO tanácsadás oldalak lehetnek prioritásban. Egy villanyszerelő weboldalon a hibakeresés, a teljesítménybővítés és a főzőlap-bekötés oldalai kaphatnak kiemelt szerepet.

Azt ellenőrizd, hogy ezek az oldalak:

• elérhetők-e a fő navigációból;
• kapnak-e hivatkozást kapcsolódó cikkekből;
• szerepelnek-e kategória- vagy szolgáltatási összefoglaló oldalakon;
• legfeljebb néhány kattintásra vannak-e a kezdőoldaltól;
• megfelelő anchor szövegeket kapnak-e;
• nem csak a láblécből érhetők-e el.

Hogyan azonosítsd az árva oldalakat?

Az árva oldal olyan URL, amely létezik, akár indexelve is lehet, de a webhely egyetlen másik oldaláról sem vezet rá belső hivatkozás.

Az árva oldalak felderítéséhez hasonlítsd össze:

• a crawler által megtalált URL-eket;
• az XML sitemap URL-jeit;
• a Google Search Console adatait;
• a Google Analytics landing oldalait;
• a CMS-ben található közzétett oldalakat;
• a szervernaplókból ismert URL-eket.

Ha egy URL szerepel a sitemapben vagy forgalmi adatot kap, de a crawler nem találja meg, valószínűleg árva oldal.

Gyakori példák:

• régi kampányoldalak;
• elfelejtett blogcikkek;
• korábban menüből elérhető szolgáltatások;
• importált termékoldalak;
• manuálisan létrehozott landing oldalak;
• szerzői profilok;
• rosszul kezelt címke- és kategóriaoldalak.

Nem minden árva oldal érdemel új belső linket. Először döntsd el, hogy:

• értékes és megtartandó;
• frissítendő;
• összevonandó;
• átirányítandó;
• törlendő;
• szándékosan elkülönített oldal.

Hogyan vizsgáld meg a kattintási mélységet?

A kattintási mélység azt mutatja meg, hogy hány belső kattintással érhető el egy URL a kezdőoldalról vagy egy kijelölt kezdőpontból.

Általános irányelvként:

Ez nem merev rangsorolási szabály. Egy több százezer URL-es webáruházban nem minden oldal helyezhető el két kattintásra a kezdőoldaltól. Egy húszoldalas szolgáltatói webhelyen azonban indokolatlan, ha egy fontos szolgáltatás csak öt-hat kattintással érhető el.

A túl mély oldalakat közelebb hozhatod:

• kategóriaoldalak létrehozásával;
• témaklaszterek kialakításával;
• kapcsolódó tartalmi blokkokkal;
• breadcrumb navigációval;
• releváns cikkekből adott linkekkel;
• hub- vagy pillar oldalak használatával.

Hogyan értékeld a bejövő belső linkek számát?

A bejövő linkek száma önmagában nem döntő, de megmutathatja, hogy egy fontos oldal megfelelő helyet kap-e a webhely struktúrájában.

Keresd meg:

• azokat a fontos URL-eket, amelyek kevés linket kapnak;
• a túl sok linket kapó, alacsony értékű oldalakat;
• a csak sablonból linkelt oldalakat;
• a kizárólag breadcrumbból elérhető tartalmakat;
• a jelentős forgalmú, de rosszul támogatott oldalakat.

Egy kulcsfontosságú szolgáltatási oldalnak általában több releváns belső hivatkozást kell kapnia, mint egy jogi nyilatkozatnak vagy egy kevésbé fontos címkeoldalnak.

Ugyanakkor nem érdemes mesterséges linkszámot meghatározni. Egy természetes belső linkelési rendszerben a linkek száma az oldal szerepéből és a hozzá kapcsolódó tartalmak mennyiségéből következik.

Hogyan vizsgáld meg az anchor szövegeket?

Az anchor szövegnek természetesen és egyértelműen kell jeleznie, hogy a hivatkozás milyen tartalomhoz vezet.

Jó anchor szöveg például:

• technikai SEO audit készítése;
• kültéri konnektor telepítése;
• hőszivattyú karbantartása;
• csipke menyasszonyi ruhák;
• Core Web Vitals javítása.

Kevésbé informatív anchor szövegek:

• kattints ide;
• további információ;
• bővebben;
• ezen az oldalon;
• itt olvashatsz róla.

Az audit során keresd:

• az üres anchor szövegeket;
• a képlinkeket hiányzó alt attribútummal;
• azonos célra mutató túl sok különböző kifejezést;
• különböző célokra mutató, teljesen azonos anchorokat;
• túlzottan kulcsszóhalmozott linkeket;
• félrevezető anchor szövegeket.

Nem szükséges minden alkalommal ugyanazt az egzakt kulcsszót használnod. A természetes változatok segítenek a témakör pontosabb értelmezésében.

Például ugyanarra a technikai SEO oldalra mutathat:

• technikai SEO audit;
• weboldal technikai ellenőrzése;
• indexelési és feltérképezési hibák vizsgálata;
• technikai keresőoptimalizálás.

Hogyan különítsd el a navigációs és a tartalmi linkeket?

Nem minden belső link ad azonos kontextust: a szöveges tartalomból érkező, témába illeszkedő hivatkozások általában többet mondanak az oldalak kapcsolatáról, mint a minden URL-en megjelenő sablonlinkek.

Belső linkek származhatnak:

• főmenüből;
• mobilmenüből;
• láblécből;
• oldalsávból;
• breadcrumbból;
• tartalmi szövegből;
• kapcsolódó cikkek blokkjából;
• kategóriaoldalról;
• képekről;
• CTA-elemekből.

Az auditban érdemes külön mérni:

Ha egy szolgáltatási oldal csak a láblécből kap hivatkozást, érdemes megvizsgálni, hogy valóban megfelelő helyen van-e a struktúrában.

Hogyan ellenőrizd a témaklaszterek belső linkelését?

A témaklaszter akkor működik jól, ha van egy központi pillar oldal, az altémák egymáshoz kapcsolódnak, és a klaszteren belül világos linkirányok alakulnak ki.

Egy technikai SEO klaszter például tartalmazhatja:

• technikai SEO útmutató;
• technikai SEO audit;
• robots.txt;
• XML sitemap;
• canonical címke;
• indexelési hibák;
• Core Web Vitals;
• strukturált adatok;
• belső linkelés;
• JavaScript SEO.

A belső kapcsolatoknak nem csak a pillar oldalról kell kifelé mutatniuk. Az altémáknak is érdemes:

• visszalinkelniük a központi útmutatóra;
• egymás releváns fejezeteire hivatkozniuk;
• további részletes tartalmakhoz vezetniük;
• a megfelelő szolgáltatási oldalhoz kapcsolódniuk.

Kerüld a teljesen mechanikus megoldást, amelyben minden cikk ugyanarra a tíz oldalra linkel. Csak akkor helyezz el hivatkozást, ha az valóban segíti az olvasót a téma folytatásában vagy pontosabb megértésében.

Hogyan ellenőrizd a hibás belső linkeket?

Minden belső linknek közvetlenül működő, releváns és lehetőleg 200-as státuszkódot adó céloldalra kell mutatnia.

Keresd:

• a 404-es céloldalakat;
• a 410-es URL-eket;
• az 5xx hibára vezető linkeket;
• az átirányított célokat;
• az átirányítási láncokat;
• a hurkokat;
• a rossz protokollt;
• a hibás www vagy nem-www változatot;
• a helytelen kis- és nagybetűhasználatot;
• a hibás horgonyazonosítókat;
• a relatív URL-ekből eredő problémákat.

Egy belső link ne lehetőleg így működjön:

régi URL → 301 → köztes URL → 301 → végleges oldal

Hanem közvetlenül:

forrásoldal → végleges oldal

Az átirányítás önmagában nem mindig probléma, de a saját webhelyeden belül érdemes a linkeket a végleges URL-ekre frissíteni.

Hogyan vizsgáld meg a nofollow belső linkeket?

A belső linkeken használt nofollow attribútumot külön ellenőrizd, mert gyakran régi vagy félreértett SEO-beállításból marad az oldalon.

Indokolt lehet speciális esetekben, de általában nem ajánlott a fontos belső navigációs linkekre.

Keresd meg:

• a főmenü nofollow linkjeit;
• fontos kategóriák tiltott hivatkozásait;
• szolgáltatási oldalakra mutató nofollow CTA-kat;
• automatikusan nofollow-ra állított belső linkeket;
• bővítmények által hozzáadott attribútumokat.

A belső linkérték mesterséges irányítása, vagyis az úgynevezett PageRank sculpting miatt nem érdemes tömegesen nofollow attribútumokat használni. Ha egy oldal nem kívánatos a kereső számára, annak technikai kezelését ne kizárólag nofollow linkekkel próbáld megoldani.

Hogyan ellenőrizd, hogy a linkeket valóban látják-e a robotok?

A fontos hivatkozásoknak szabványos HTML-linkként kell megjelenniük, és lehetőleg már a renderelt oldalban is elérhetőknek kell lenniük.

A legbiztosabban felismerhető forma:

<a href="https://pelda.hu/technikai-seo-audit/">
  Technikai SEO audit
</a>

Problémás lehet, ha a navigáció kizárólag:

• JavaScript eseményre;
• onclick megoldásra;
• nem szabványos gombra;
• felhasználói görgetés után betöltődő elemre;
• robots.txt által blokkolt scriptre;
• bejelentkezéshez kötött menüre

épül.

Ellenőrizd:

• az oldal forráskódját;
• a renderelt HTML-t;
• a Search Console élő URL-tesztjét;
• JavaScript-rendereléssel futtatott crawl eredményét;
• a böngésző JavaScript nélküli nézetét.

Hogyan vizsgáld meg a belső linkek elhelyezését?

A linket ott érdemes elhelyezni, ahol az olvasó számára természetes következő lépést jelent, és a környező szöveg egyértelmű kontextust biztosít.

Általában értékesebb egy hivatkozás, ha:

• releváns bekezdésben jelenik meg;
• pontosan kapcsolódik a tárgyalt témához;
• értelmes anchor szövege van;
• segít egy részletkérdés továbbfejtésében;
• nem reklámszerűen van beillesztve.

Kerüld:

• a linkhalmozást egyetlen mondatban;
• a minden bekezdésben ismétlődő szolgáltatási linket;
• az indokolatlanul hosszú anchor szöveget;
• a félrevezető hivatkozást;
• a tartalomtól idegen oldalra mutató linket;
• az egymás mellett sorakozó „kattints ide” linkeket.

Hogyan vizsgáld meg a linkek eloszlását?

A belső linkek eloszlásának tükröznie kell a webhely üzleti és tartalmi prioritásait.

Készíts összehasonlítást:

Ez megmutatja, ha a webhely belső linkértékének jelentős része alacsony üzleti értékű oldalakra kerül.

Hogyan használd a Search Console adatait a vizsgálatban?

A Search Console Belső linkek jelentése segíthet megállapítani, hogy a Google mely oldalakat érzékeli a legtöbb belső hivatkozással rendelkező URL-ként.

Hasonlítsd össze a listát a saját prioritásaiddal.

Vizsgáld meg:

• a legfontosabb szolgáltatási oldalak előkelő helyen vannak-e;
• túl sok linket kapnak-e alacsony értékű archívumok;
• megjelennek-e az új pillar oldalak;
• megfelelően változott-e a lista egy belső linkelési átalakítás után.

A Search Console nem feltétlenül mutat minden egyes linket, és az adatai késleltetve frissülhetnek. Ezért a jelentést crawleres és saját adatbázisból származó adatokkal együtt érdemes használni.

Hogyan értékeld a felhasználói útvonalakat?

A jó belső linkelés nemcsak a robotokat vezeti, hanem a látogatót is segíti a következő logikus lépés megtalálásában.

Vizsgáld meg, hogy egy felhasználó:

• könnyen eljut-e az általános témától a részletes útmutatóig;
• megtalálja-e a kapcsolódó szolgáltatást;
• vissza tud-e lépni a kategóriaoldalra;
• eléri-e a kapcsolatfelvételt;
• megtalálja-e a következő kapcsolódó cikket;
• nem kerül-e zsákutcába.

Egy jó útvonal például:

Technikai SEO útmutató → Indexelési hibák → Technikai SEO audit szolgáltatás → Kapcsolatfelvétel

Egy másik:

Menyasszonyi ruhák → Csipke menyasszonyi ruha → Fazonválasztási útmutató → Ruhapróba foglalása

A belső linkelés akkor működik jól, ha nemcsak több oldalletöltést eredményez, hanem valóban segíti a látogatót a döntésben.

Milyen belső linkelési hibákat keress?

Az audit során a hibás linkek mellett a strukturális aránytalanságokat és a relevanciahiányt is vizsgálnod kell.

Gyakori hibák:

• árva oldalak;
• túl mélyre helyezett fontos tartalmak;
• hibás vagy törött linkek;
• átirányított céloldalak;
• nem informatív anchor szövegek;
• túlzott kulcsszóhasználat;
• fontos oldalak alacsony linkszáma;
• értéktelen archívumok túlzott belinkelése;
• minden cikkből ugyanarra az oldalra mutató linkek;
• témaklaszterek közötti kapcsolatok hiánya;
• mobilmenüből kimaradó oldalak;
• JavaScript miatt nem követhető hivatkozások;
• belső linkeken alkalmazott indokolatlan nofollow;
• duplikált navigációs elemek;
• túl sok, kevéssé hasznos lábléclink;
• nem létező horgonyokra mutató tartalomjegyzék.

Hogyan priorizáld a belső linkelési javításokat?

Először azokat a problémákat javítsd, amelyek fontos oldalak felfedezését, feltérképezését vagy felhasználói elérhetőségét akadályozzák.

Hogyan készíts belső linkelési javítási tervet?

A javítási tervben URL-enként add meg, honnan, milyen anchor szöveggel és milyen célból szükséges új hivatkozást elhelyezni.

Példa:

Ez lényegesen használhatóbb, mint egy általános utasítás, hogy „készíts több belső linket”.

Belső linkelési ellenőrző lista

A vizsgálat akkor teljes, ha a technikai hibák, a webhelyhierarchia, a témakapcsolatok és a felhasználói útvonalak egyaránt ellenőrzésre kerültek.

• Lefuttattad a teljes webhely-crawlt.
• Exportáltad a bejövő és kimenő linkeket.
• Meghatároztad a kiemelt URL-eket.
• Felderítetted az árva oldalakat.
• Ellenőrizted a kattintási mélységet.
• Megvizsgáltad a belső linkek eloszlását.
• Ellenőrizted az anchor szövegeket.
• Megkerested a hibás linkeket.
• Frissítetted az átirányított célokra mutató linkeket.
• Ellenőrizted a nofollow attribútumokat.
• Megvizsgáltad a JavaScript-linkeket.
• Ellenőrizted a mobilos navigációt.
• Átnézted a breadcrumb útvonalakat.
• Megvizsgáltad a témaklaszterek kapcsolatait.
• Összevetetted az eredményt a Search Console adataival.
• Készítettél konkrét URL-szintű javítási tervet.

A jól felépített belső linkelési rendszer nem attól erős, hogy minden oldalon sok hivatkozás található, hanem attól, hogy a linkek következetesen tükrözik a webhely témáit, hierarchiáját és üzleti céljait. A látogatók könnyen megtalálják a következő releváns tartalmat, a Google hatékonyabban térképezi fel az oldalakat, az AI-rendszerek pedig világosabb képet kapnak az egyes fogalmak és entitások közötti kapcsolatokról.

Hogyan derítsd fel a duplikált tartalmakat?

A duplikált tartalmak felderítéséhez nem elég néhány mondatot összehasonlítani. A teljes URL-rendszert, a technikai változatokat, a paraméteres oldalakat, a canonical beállításokat és a nagyon hasonló szövegeket is együtt kell vizsgálnod.

Duplikált tartalomról akkor beszélünk, amikor ugyanaz vagy közel azonos tartalom több URL-en is elérhető. Ez nem minden esetben jelent közvetlen büntetést, de komoly SEO-problémákat okozhat, mert a keresőnek el kell döntenie:

• melyik URL az eredeti;
• melyiket térképezze fel rendszeresen;
• melyiket vegye fel az indexbe;
• melyik oldal kapja a rangsorolási jeleket;
• melyik változat jelenjen meg a találatok között.

Ha a rendszer nem egyértelmű, a Google olyan URL-t választhat elsődlegesnek, amelyet te nem szeretnél előtérbe helyezni.

Milyen típusú duplikált tartalmak léteznek?

A duplikáció lehet teljesen azonos, részlegesen ismétlődő vagy technikai okból több URL-en elérhető tartalom.

Hogyan kezdd a duplikált tartalmak vizsgálatát?

Első lépésként futtass teljes webhely-crawlt, majd keresd meg az azonos vagy nagyon hasonló címeket, meta leírásokat, H1-eket és tartalmi blokkokat.

Erre használhatsz például:

• Screaming Frog;
• Sitebulb;
• Semrush Site Audit;
• Ahrefs Site Audit;
• Siteliner;
• Copyscape;
• saját adatbázis- vagy exportelemzést.

A crawl során gyűjtsd össze:

• URL;
• title;
• meta description;
• H1;
• canonical URL;
• szó- és karakterszám;
• indexelhetőség;
• státuszkód;
• hash vagy tartalmi hasonlóság;
• bejövő belső linkek;
• sitemapben való szereplés.

Hogyan azonosítsd az azonos title és meta description értékeket?

Az ismétlődő title és meta description gyakran arra utal, hogy több oldal túl hasonló vagy ugyanazt a keresési szándékot célozza.

Keresd meg:

• teljesen azonos title elemeket;
• csak egy szóban eltérő title-öket;
• azonos meta leírásokat;
• azonos H1 címeket;
• sablonosan ismétlődő oldalfejléceket.

Például:

• „SEO audit Budapest”
• „SEO audit Debrecen”
• „SEO audit Szeged”

Ha a három oldal tartalma szinte teljesen azonos, és csak a városnév változik, az nem valódi lokális egyediség. Ilyenkor a kereső nehezen tudja megállapítani, hogy miért érdemes mindhárom oldalt külön indexelni.

Az azonos meta adatok önmagukban még nem bizonyítják a tartalmi duplikációt, de fontos figyelmeztető jelek.

Hogyan használd a tartalmi hasonlósági jelentéseket?

A tartalmi hasonlósági jelentések megmutatják, hogy két oldal szövege mekkora arányban egyezik meg.

Az eszközök különböző módszereket használhatnak:

• szóegyezés;
• mondat-összehasonlítás;
• HTML-tartalom hash;
• shingle-alapú hasonlóság;
• szemantikai összehasonlítás;
• near duplicate elemzés.

Általános értelmezés:

Ezek nem merev SEO-határok. Egy webáruház termékoldalain természetes lehet bizonyos sablonszövegek ismétlődése, míg egy szolgáltatói webhelyen már 60–70 százalékos hasonlóság is problémás lehet.

Hogyan keresd meg a technikai URL-változatokat?

Ellenőrizd, hogy ugyanaz a tartalom nem érhető-e el több protokollon, domainváltozaton vagy eltérő URL-formában.

Vizsgáld meg:

• HTTP és HTTPS változat;
• www és nem-www;
• záró perjeles és perjel nélküli URL;
• kis- és nagybetűs változat;
• index.php vagy index.html;
• nyomtatási nézet;
• AMP-változat;
• UTM-paraméteres URL;
• session ID;
• rendezési paraméter;
• szűrési paraméter;
• lapozási URL;
• keresési eredményoldal.

Példa:

https://pelda.hu/szolgaltatas
https://pelda.hu/szolgaltatas/
https://www.pelda.hu/szolgaltatas/
http://pelda.hu/szolgaltatas/
https://pelda.hu/szolgaltatas/?utm_source=facebook

Ezek közül lehetőleg egyetlen kanonikus változat maradjon indexelhető, a többi pedig megfelelő átirányítással vagy canonical jelöléssel mutasson rá.

Hogyan vizsgáld meg a canonical címkéket?

A canonical jelölésnek világosan meg kell mutatnia, melyik URL az elsődleges változat, de hibás beállítás esetén maga is duplikációs problémát okozhat.

Ellenőrizd:

• minden indexelendő oldal rendelkezik-e megfelelő canonical URL-lel;
• a canonical önmagára mutat-e;
• nem mutat-e átirányított oldalra;
• nem vezet-e 404-es URL-re;
• nem mutat-e másik nyelvi verzióra;
• több hasonló oldal nem hivatkozik-e tévesen ugyanarra a főoldalra;
• a canonical és az XML sitemap ugyanazt az URL-t preferálja-e;
• a belső linkek a canonical változatra mutatnak-e.

Gyakori hiba, amikor minden termékvariáció canonicalja a kategóriaoldalra mutat. Ilyenkor a Google azt érzékelheti, hogy a termékoldalak nem önálló tartalmak.

Hogyan használd a Search Console-t duplikációk keresésére?

A Search Console indexelési jelentése megmutathatja, amikor a Google más URL-t választott kanonikusnak, mint amit te megadtál.

Keresd az ilyen állapotokat:

• „Duplikált, a Google másik kanonikus oldalt választott”;
• „Duplikált, beküldött URL nincs megjelölve kanonikusként”;
• „Alternatív oldal megfelelő kanonikus címkével”;
• „Feltérképezve – jelenleg nincs indexelve”;
• „Kizárva noindex címke miatt”.

Egyedi URL vizsgálatakor ellenőrizd:

• a felhasználó által megadott canonicalt;
• a Google által kiválasztott canonicalt;
• az utolsó feltérképezés dátumát;
• a sitemapben való szereplést;
• a hivatkozó oldalakat.

Ha a Google következetesen másik canonicalt választ, annak oka lehet:

• gyenge önálló tartalom;
• ellentmondó belső linkelés;
• hibás sitemap;
• túl hasonló oldalak;
• átirányítási jelek;
• eltérő nyelvi vagy regionális beállítások.

Hogyan keresd meg a kulcsszó-kannibalizációt?

A kulcsszó-kannibalizáció nem minden esetben duplikált tartalom, de gyakran hasonló oldalak ugyanazért a keresési szándékért versenyeznek egymással.

Keresd meg azokat az oldalakat, amelyek:

• ugyanarra a fő kulcsszóra rangsorolnak;
• ugyanazt a felhasználói kérdést válaszolják meg;
• nagyon hasonló title-t és H1-et használnak;
• egymást váltják a találati listán;
• egyik héten az egyik, másik héten a másik URL kap kattintásokat;
• azonos szolgáltatást mutatnak be eltérő megfogalmazással.

A Search Console-ban szűrj egy lekérdezésre, majd nézd meg, hány URL kapott rá megjelenést és kattintást.

Például problémás lehet, ha külön oldalad van:

• „Mi az a technikai SEO audit?”
• „Technikai SEO audit készítése”
• „Technikai SEO ellenőrzés”
• „Weboldal technikai SEO elemzése”

Ha mind a négy oldal lényegében ugyanazt a keresési szándékot célozza, érdemes lehet őket összevonni vagy világosan elkülöníteni.

Hogyan vizsgáld meg a lokális oldalak egyediségét?

A településenként létrehozott szolgáltatási oldalak gyakran csak a helységnévben különböznek, ezért különösen nagy a duplikáció veszélye.

Ellenőrizd, hogy minden lokális oldal tartalmaz-e:

• valós helyi szolgáltatási információt;
• egyedi bevezetőt;
• területspecifikus példákat;
• helyi referenciát;
• eltérő GYIK-et;
• valós kiszállási vagy működési adatokat;
• környékbeli sajátosságokat;
• egyedi képeket vagy esettanulmányokat.

Nem megfelelő gyakorlat:

Villanyszerelés Budapesten gyorsan és megbízhatóan.
Villanyszerelés Érden gyorsan és megbízhatóan.
Villanyszerelés Budaörsön gyorsan és megbízhatóan.

Ez önmagában nem teremt valódi helyi relevanciát.

Hogyan vizsgáld meg a webáruházak duplikációit?

Webáruházaknál a szűrési, rendezési, kategória- és termékvariációs URL-ek okozzák a legtöbb ismétlődést.

Keresd:

• ugyanazon termék több kategória-URL-jét;
• szín- és méretvariációkat külön oldalon;
• rendezési paramétereket;
• ár szerinti szűréseket;
• gyártói leírásokat;
• lapozott oldalak ismétlődő szövegét;
• kifutott és új termékoldalak átfedését;
• azonos termék több kiszerelését.

Például:

/ruhak/feher-ruha/
/menyasszonyi-ruhak/feher-ruha/
/akcios-termekek/feher-ruha/

Ha mindhárom URL-en ugyanaz a termékoldal jelenik meg, egységes kanonikus és belső linkelési rendszerre van szükség.

Hogyan keresd meg a CMS által létrehozott duplikációkat?

A tartalomkezelő rendszer automatikusan generálhat olyan archívumokat és URL-eket, amelyek ugyanazokat a tartalmakat ismétlik.

WordPress esetén vizsgáld meg:

• kategóriaoldalak;
• címkeoldalak;
• dátumarchívumok;
• szerzői archívumok;
• médiacsatolmány-oldalak;
• belső keresési oldalak;
• lapozási URL-ek;
• RSS-feedek;
• nyomtatható változatok;
• kép- és attachment oldalak.

Egy egyszemélyes blognál például a szerzői archívum gyakran ugyanazokat a bejegyzéseket listázza, mint a blog főoldala. Ha nincs önálló szerepe, felesleges indexelési réteget hozhat létre.

Hogyan ellenőrizd a külső tartalmi másolatokat?

A külső duplikáció azt jelenti, hogy a saját szöveged más webhelyen is megjelenik, vagy te használsz máshonnan átvett tartalmat.

Erre használhatsz:

• pontos idézőjeles Google-keresést;
• Copyscape-et;
• Plagiumot;
• Sitelinert;
• saját márkaneves kereséseket;
• egyedi mondatok keresését.

Keress rá egy hosszabb, egyedi mondatra idézőjelben:

"egyedi mondat a saját cikkedből"

Vizsgáld meg:

• melyik oldal jelent meg korábban;
• van-e canonical visszahivatkozás;
• partneri újraközlés történt-e;
• teljes vagy részleges másolatról van-e szó;
• a másolat felülmúlja-e az eredeti oldalt.

Ha te használsz gyártói termékleírást, azt érdemes egyedi tapasztalatokkal, saját specifikációs táblázattal, GYIK-kel, képekkel és vásárlási tanácsokkal kiegészíteni.

Hogyan különítsd el a sablonszöveget a valódi duplikációtól?

A fejléc, lábléc és állandó navigáció természetesen ismétlődik, ezért a duplikációs vizsgálatban a fő tartalmi területet kell előtérbe helyezni.

Ismétlődhet például:

• menü;
• lábléc;
• jogi nyilatkozat;
• kapcsolati blokk;
• CTA;
• szerzői doboz;
• kapcsolódó szolgáltatások;
• cookie-szöveg.

Ez önmagában nem probléma. A gond akkor jelentkezik, ha az egyedi fő tartalom túl rövid, és az oldal nagy részét sablonelemek alkotják.

Egy 200 szavas szolgáltatási oldalon például 500 szónyi ismétlődő lábléc és CTA aránytalanul nagy tartalmi átfedést eredményezhet.

Mit tegyél a duplikált tartalmakkal?

A megfelelő megoldás attól függ, hogy szükség van-e mindegyik URL-re, és van-e közöttük valódi tartalmi különbség.

Mikor használj 301-es átirányítást?

A 301-es átirányítás akkor megfelelő, ha két oldal közül csak az egyiket szeretnéd hosszú távon megtartani.

Használd, ha:

• két cikket összevonsz;
• megszüntetsz egy régi URL-t;
• egységesíted a perjeles változatokat;
• HTTP-ről HTTPS-re váltasz;
• www és nem-www változatot egységesítesz;
• egy régi szolgáltatási oldalt új vált fel.

A belső linkeket ezután mindig frissítsd a végleges URL-re.

Mikor használj canonical címkét?

Canonical jelölést akkor használj, ha több URL-nek működnie kell, de közülük egyet szeretnél elsődleges változatként megjelölni.

Tipikus esetek:

• szűrési paraméterek;
• kampánymérési paraméterek;
• termékvariációk;
• partneri másolatok;
• nyomtatási változatok;
• több útvonalon elérhető ugyanazon tartalom.

A canonical jelzés, nem kötelező utasítás. Ha a többi jel ellentmond neki, a Google más URL-t választhat.

Mikor kell inkább egyedivé tenni az oldalakat?

Ha az oldalak külön keresési szándékot, szolgáltatást vagy célközönséget szolgálnak ki, ne vond össze őket automatikusan, hanem alakíts ki valódi tartalmi különbséget.

Az egyediséghez szükség lehet:

• eltérő keresési szándékra;
• saját példákra;
• önálló táblázatokra;
• eltérő szakmai mélységre;
• külön GYIK-re;
• saját esettanulmányra;
• egyedi képekre;
• külön célcsoportra;
• saját ajánlatra vagy folyamatra.

Például a „SEO audit” és a „havidíjas SEO” külön szolgáltatás, ezért nem kell őket összevonni. A két oldalnak azonban egyértelműen eltérő célt, folyamatot, árazást és eredményt kell bemutatnia.

Hogyan készíts duplikációs audit táblázatot?

A hibák javításához URL-páronként vagy URL-csoportonként rögzítsd a probléma típusát, a preferált oldalt és a szükséges beavatkozást.

Milyen duplikált tartalmi hibákat javíts először?

Elsőként azokat a duplikációkat kezeld, amelyek fontos oldalak indexelését, rangsorolását vagy belső linkértékét osztják meg.

Javasolt prioritási sorrend:

1. Több technikai változaton elérhető teljes webhely.
2. Hibás canonical által érintett fontos oldalak.
3. Egymással versengő szolgáltatási és landing oldalak.
4. Nagy mennyiségű paraméteres URL.
5. Duplikált termék- és kategóriaoldalak.
6. Településnév-cserével létrehozott lokális oldalak.
7. Felesleges címke-, szerzői és dátumarchívumok.
8. Külső oldalakon megjelenő teljes tartalmi másolatok.
9. Ismétlődő title és H1 elemek.
10. Rövid, sablonos oldalak.

Duplikált tartalmak ellenőrző listája

A vizsgálat akkor teljes, ha a belső, technikai és külső tartalmi másolatokat egyaránt ellenőrizted.

• Lefuttattad a teljes webhely-crawlt.
• Megkerested az azonos title elemeket.
• Ellenőrizted a duplikált meta leírásokat.
• Megvizsgáltad az azonos H1 címeket.
• Lefuttattad a near duplicate elemzést.
• Ellenőrizted a HTTP és HTTPS változatokat.
• Megvizsgáltad a www és nem-www változatokat.
• Ellenőrizted a záró perjeles URL-eket.
• Megvizsgáltad a paraméteres oldalakat.
• Ellenőrizted a canonical címkéket.
• Átnézted a Search Console canonical állapotait.
• Megvizsgáltad a kategória- és címkeoldalakat.
• Ellenőrizted a termékvariációkat.
• Megvizsgáltad a lokális oldalak egyediségét.
• Ellenőrizted a külső tartalmi másolatokat.
• Készítettél URL-szintű javítási tervet.

A duplikált tartalom kezelése nem azt jelenti, hogy minden hasonló mondatot el kell távolítanod. A cél az, hogy minden indexelhető URL-nek világos szerepe, önálló keresési szándéka és egyértelmű elsődleges változata legyen. Ha a canonical jelzések, az átirányítások, a belső linkek és a sitemap ugyanazt az URL-t támogatják, a Google és az AI-alapú keresők is könnyebben azonosítják az eredeti és legfontosabb tartalmat.

Milyen mobilos problémák ronthatják a SEO-t?

A mobilos SEO-problémák akkor jelentkeznek, amikor a Google mobilos robotja vagy a telefonról érkező látogató kevesebb tartalmat, rosszabb teljesítményt, nehezebb navigációt vagy eltérő technikai jelzéseket kap, mint asztali környezetben. Mivel a Google a mobilos változat tartalmát használja az indexeléshez és a rangsorolás értékeléséhez, a mobilverzió hibái közvetlenül érinthetik az oldal organikus láthatóságát.

A mobilos audit során nem elég megnézned, hogy az oldal „elfér-e” egy keskeny kijelzőn. Külön ellenőrizned kell:

• a mobilon elérhető tartalmat;
• a technikai SEO-elemek egyezőségét;
• a navigáció működését;
• az oldal betöltési sebességét;
• a Core Web Vitals értékeket;
• a képek és videók megjelenítését;
• a felugró elemeket;
• az űrlapokat;
• a kattintható elemek használhatóságát;
• a Googlebot Smartphone számára elérhető erőforrásokat.

Eltérő vagy hiányos mobilos tartalom

Az egyik legsúlyosabb hiba, ha mobilon kevesebb fő tartalom jelenik meg, mint asztali gépen. A Google mobil-first indexelése miatt a mobilverzión nem elérhető szöveget, képet, videót vagy linket a kereső nem feltétlenül veszi figyelembe megfelelően.

Ellenőrizd, hogy mobilon is szerepel-e:

• a teljes főszöveg;
• minden H2 és H3 címsor;
• a termék- vagy szolgáltatásleírás;
• a fontos táblázat;
• az ár és készletinformáció;
• a GYIK;
• a szerzői információ;
• a képek alt szövege;
• a videók címe és leírása;
• a fontos belső linkek;
• a strukturált adatok alapjául szolgáló látható tartalom.

Problémás lehet, ha egy hosszú tartalmat mobilon teljesen eltávolítasz, és nem csupán összecsukható elemben jelenítesz meg. A harmonika vagy „Tovább” megoldás önmagában nem feltétlenül hiba, ha a tartalom a betöltött HTML-ben elérhető, használható és a Google számára feldolgozható.

Eltérő title, meta description vagy robots beállítás

A mobilos és asztali változat technikai SEO-jelzéseinek következetesnek kell lenniük. Ha a mobilverzió más title-t, canonicalt vagy robots utasítást ad, a Google bizonytalan lehet abban, melyik változatot kell indexelnie.

Különösen ellenőrizd:

• a <title> elemet;
• a meta descriptiont;
• a meta robots címkét;
• az X-Robots-Tag fejlécet;
• a canonical URL-t;
• a hreflang jelöléseket;
• a strukturált adatokat;
• az Open Graph adatokat;
• a fő címsort;
• a nyelvi beállításokat.

Súlyos hiba lehet például, ha:

• az asztali oldal indexelhető, de a mobilos változat noindex;
• a mobilos canonical a kezdőoldalra mutat;
• a mobil URL és az asztali URL között hibás a kapcsolat;
• mobilon hiányzik a hreflang;
• más Organization vagy Product adat jelenik meg.

Blokkolt CSS-, JavaScript- vagy képfájlok

Ha a Googlebot Smartphone nem fér hozzá az oldal megjelenítéséhez szükséges erőforrásokhoz, nem biztos, hogy ugyanúgy látja az oldalt, mint a felhasználó.

A robots.txt vagy a szerverbeállítások blokkolhatják:

• a CSS-fájlokat;
• a JavaScriptet;
• a képeket;
• a webfontokat;
• az API-végpontokat;
• a dinamikus tartalom betöltését;
• a mobilmenü működéséhez szükséges fájlokat.

Ennek következménye lehet:

• hibás renderelés;
• hiányzó navigáció;
• fel nem ismert tartalom;
• rosszul értelmezett reszponzív elrendezés;
• hiányzó belső linkek;
• alacsonyabb oldalélmény.

A Search Console URL-ellenőrző eszközében vizsgáld meg a renderelt mobilos képet és a betöltési hibákat.

Nem reszponzív elrendezés

A nem megfelelően reszponzív oldal vízszintes görgetést, levágott tartalmat és nehezen kezelhető elemeket okozhat.

Tipikus problémák:

• fix szélességű oldal;
• túl széles táblázat;
• kilógó kép;
• fix méretű videó vagy iframe;
• képernyőn kívülre kerülő gomb;
• összecsúszó oszlopok;
• levágott szöveg;
• hibás mobilmenü;
• nem megfelelő CSS media query;
• asztali elrendezés egyszerű lekicsinyítése.

A reszponzív képek és elrendezések javítják a különböző eszközökön nyújtott felhasználói élményt.

Hiányzó vagy hibás viewport beállítás

A viewport meta tag nélkül a mobilböngésző asztali szélességű oldalként próbálhatja megjeleníteni a tartalmat, majd lekicsinyíti azt.

Általános beállítás:

<meta name="viewport" content="width=device-width, initial-scale=1">

Gyakori hibák:

• teljesen hiányzik a viewport;
• fix szélesség van megadva;
• le van tiltva a nagyítás;
• túl nagy vagy túl kicsi kezdő méretezés szerepel;
• több, egymásnak ellentmondó viewport tag jelenik meg.

A felhasználói nagyítás letiltását különösen érdemes kerülni, mert akadálymentességi problémát is okozhat.

Túl kicsi betűméret

Ha a szöveg nagyítás nélkül nehezen olvasható, a látogató hamarabb elhagyhatja az oldalt, és romolhat a mobilos használhatóság.

Vizsgáld meg:

• a főszöveg méretét;
• a menüpontokat;
• a lábjegyzeteket;
• a gombfeliratokat;
• az űrlapmezők szövegét;
• a táblázatok tartalmát;
• a képaláírásokat;
• a sortávolságot;
• a kontrasztot.

Nem csak a betűméret számít. A túl hosszú sorok, a kicsi sortávolság és a gyenge kontraszt együtt még olvashatatlanabbá tehetik a szöveget.

Túl közel elhelyezett kattintható elemek

A túl kicsi vagy egymáshoz túl közel elhelyezett linkek és gombok miatt a látogatók könnyen rossz elemre koppinthatnak.

Keresd:

• az apró menüpontokat;
• az egymás melletti szöveges linkeket;
• a kis lapozógombokat;
• a nehezen bezárható felugró ablakokat;
• az apró kosár- vagy keresésikonokat;
• a sűrű címkefelhőket;
• a túl kicsi checkboxokat;
• a szűk gombsorokat.

Különösen fontos, hogy a mobilmenü bezárógombja, az űrlap elküldése és a vásárlási gomb kényelmesen használható legyen.

Lassú mobilos betöltés

A mobilos látogatók gyakran lassabb hálózatot és gyengébb processzort használnak, ezért az asztali gépen elfogadható oldal mobilon könnyen túl lassúvá válhat.

A leggyakoribb okok:

• túl nagy képek;
• háttérvideók;
• sok JavaScript;
• túl sok WordPress-bővítmény;
• lassú szerver;
• hiányzó gyorsítótár;
• túl sok külső script;
• sok webfont;
• renderelést blokkoló CSS;
• nem használt kód;
• rossz CDN-beállítás;
• túl nagy DOM;
• bonyolult oldalépítő.

A Google oldalélmény-rendszere a Core Web Vitals mutatókat is figyelembe veszi, de a jó pontszám önmagában nem garantál magas helyezést. A teljes felhasználói élmény és a tartalom minősége együtt számít.

Gyenge mobilos LCP

A rossz Largest Contentful Paint azt jelzi, hogy a mobilos látogató túl sokáig vár a fő tartalom megjelenésére.

Mobilon gyakori ok:

• nagyméretű hero kép;
• nem megfelelő képformátum;
• túl magas TTFB;
• későn felfedezett LCP-kép;
• az LCP-elem lazy loadinggal töltődik;
• lassan betöltődő betűtípus;
• renderelést blokkoló stíluslap;
• JavaScripttel létrehozott fő tartalom;
• túl sok elsődleges erőforrás.

A mobilos hero képhez ne feltétlenül ugyanazt a több ezer pixel széles fájlt töltsd le, amelyet nagy asztali monitorhoz használsz.

Gyenge mobilos INP

A rossz Interaction to Next Paint miatt az oldal lassan reagál a koppintásra, a menü megnyitására, a szűrésre vagy az űrlap használatára.

Tipikus problémák:

• túl sok JavaScript fut a fő szálon;
• lassan nyílik a mobilmenü;
• akadozik a termékszűrő;
• késve reagál a kosárgomb;
• nehéz animáció fut;
• élő chat vagy hőtérkép terheli az oldalt;
• túl sok elem frissül egyszerre;
• nagy DOM-ot kell újrarenderelni;
• harmadik fél scriptje blokkolja az interakciót.

A gyengébb mobilprocesszor miatt olyan JavaScript-feladatok is problémává válhatnak, amelyek asztali gépen szinte észrevehetetlenek.

Magas mobilos CLS

A váratlan elrendezésváltozás mobilon különösen zavaró, mert a kis képernyőn egy kisebb elmozdulás is nagyobb arányban változtatja meg a látható területet.

Gyakori ok:

• méret nélküli kép;
• utólag megjelenő hirdetés;
• betöltődő cookie-sáv;
• változó magasságú fejléc;
• felülre beillesztett ajánlat;
• webfont miatti szövegátrendeződés;
• későn betöltődő kapcsolódó tartalom;
• hibás mobilos sticky elem;
• dinamikusan megjelenő űrlaphiba.

A CLS a vizuális stabilitást méri, ezért a képeknek, hirdetéseknek és beágyazott elemeknek előre meghatározott helyet kell foglalniuk.

Túl nagy vagy rosszul optimalizált képek

A mobilos oldal lassulásának egyik leggyakoribb oka, hogy a böngésző a szükségesnél jóval nagyobb képfájlt tölt le.

Ellenőrizd:

• van-e srcset;
• megfelelő-e a sizes attribútum;
• WebP vagy AVIF formátumot használsz-e;
• megfelelően tömörítettek-e a képek;
• indokolt-e a lazy loading;
• az LCP-kép nincs-e késleltetve;
• meg van-e adva a szélesség és magasság;
• nem töltődik-e be rejtett asztali kép mobilon is;
• a háttérképhez van-e mobilos változat.

Gyakori hiba, hogy CSS-sel elrejtenek egy asztali képet, de a böngésző ettől még letölti azt.

Mobilon használhatatlan táblázatok

A széles táblázatok vízszintes görgetést, levágott adatokat vagy összenyomott szöveget okozhatnak.

Megoldási lehetőség:

• görgethető táblázatkonténer;
• kártyás mobilos megjelenítés;
• kevésbé fontos oszlopok elrejtése;
• rövidebb cellatartalom;
• részletes táblázat külön oldalon;
• megfelelő tördelés.

Arra ügyelj, hogy a mobilos változatból ne távolíts el lényeges információkat kizárólag azért, hogy a táblázat jobban elférjen.

Hibás mobilmenü

A mobilmenü hibája feltérképezési és felhasználói problémát is okozhat, különösen akkor, ha fontos oldalak csak ezen keresztül érhetők el.

Gyakori problémák:

• a menü nem nyílik meg;
• JavaScript-hiba miatt üres;
• a Googlebot nem látja a linkeket;
• hiányoznak belőle fő kategóriák;
• túl sok szintet tartalmaz;
• nehéz visszalépni;
• az almenük nem koppinthatók;
• a háttér nem görgethető;
• a bezárógomb nem látható;
• a menü eltakarja a teljes oldalt.

A fontos navigációs elemek lehetőleg szabványos HTML-linkként jelenjenek meg:

<a href="/szolgaltatas/">Szolgáltatás</a>

Ne kizárólag JavaScript onclick eseményekre építsd a belső navigációt.

Eltérő belső linkelés mobilon

Ha a mobilos változatból fontos belső linkek hiányoznak, az oldalak mélyebbre kerülhetnek a webhely szerkezetében, vagy akár árva oldallá is válhatnak.

Vizsgáld meg, hogy mobilon is elérhető-e:

• minden fő szolgáltatás;
• a kategóriák;
• a breadcrumb;
• a kapcsolódó cikkek;
• a szerzői profil;
• a következő logikus tartalom;
• a kapcsolatfelvétel;
• a termékvariációk;
• a lapozás.

A mobilmenü egyszerűsítése hasznos lehet, de ne járjon azzal, hogy fontos SEO-oldalak teljesen eltűnnek a belső linkhálózatból.

Hibás végtelen görgetés

A kizárólag görgetésre vagy gombnyomásra betöltődő tartalmat a keresőrobot nem feltétlenül fedezi fel úgy, mint egy hagyományos lapozási rendszert.

Ez gyakori:

• webáruházakban;
• blogarchívumokban;
• képgalériákban;
• híroldalakon;
• mobilos listázásoknál.

A Google dokumentációja szerint a keresőrobot általában nem görget és nem kattint gombokra felhasználóként, ezért az újabb tartalmakhoz feltérképezhető URL-eket és megfelelő lapozási struktúrát kell biztosítani.

Ellenőrizd, hogy:

• minden lapnak van saját URL-je;
• a linkek szabványos <a href> formában jelennek meg;
• az URL-ek közvetlenül megnyithatók;
• nincs tartalmi átfedés a lapok között;
• a lapozás JavaScript nélkül is értelmezhető.

Zavaró felugró ablakok és közbeiktatott elemek

A mobilos képernyő nagy részét eltakaró felugró ablakok megnehezíthetik a fő tartalom elérését, és ronthatják az oldalélményt.

Problémás lehet:

• teljes képernyős hírlevélablak;
• azonnal megjelenő reklám;
• nehezen bezárható kupon;
• túl nagy cookie-banner;
• alkalmazástelepítést erőltető réteg;
• több egymásra nyíló popup;
• görgetést lezáró felület.

A Google oldalélmény-útmutatója a zavaró közbeiktatott elemek hiányát is a jó felhasználói élmény részeként említi.

Jogszabály által szükséges elemek, például megfelelő cookie-hozzájárulási felületek indokoltak lehetnek, de ezeket is érdemes a lehető legkevésbé zavaró módon kialakítani.

Mobilon rosszul működő űrlapok

A kapcsolatfelvételi, ajánlatkérő vagy vásárlási űrlap hibái közvetlenül ronthatják a konverziót, és gyenge felhasználói jeleket eredményezhetnek.

Ellenőrizd:

• megfelelő billentyűzet nyílik-e meg;
• elég nagyok-e a mezők;
• láthatók-e a címkék;
• működik-e az automatikus kitöltés;
• olvashatók-e a hibaüzenetek;
• nem takarja-e ki a billentyűzet a gombot;
• megfelelő-e a mezők sorrendje;
• használható-e a dátumválasztó;
• nem indul-e újra az oldal elküldéskor;
• működik-e a CAPTCHA;
• nem túl hosszú-e az űrlap.

Használj megfelelő mezőtípusokat, például:

<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">

Mobilon nem lejátszható videók

A hibás videóbeágyazás lassíthatja az oldalt, eltolhatja az elrendezést vagy teljesen használhatatlanná teheti a tartalmat.

Vizsgáld meg:

• reszponzív-e a videó;
• támogatott-e a formátum;
• van-e bélyegkép;
• indokolt-e az automatikus lejátszás;
• nincs-e bekapcsolva automatikus hang;
• meg van-e adva a helye betöltés előtt;
• betöltődik-e egyszerre több videó;
• elérhető-e szöveges átirat;
• mobilon is szerepel-e a videó strukturált adata.

Hibás mobilos átirányítások

Külön mobil URL-ek használatakor előfordulhat, hogy minden asztali oldal ugyanarra a mobilos kezdőoldalra irányít, vagy a mobil URL nem a megfelelő tartalomhoz vezet.

Például hibás:

pelda.hu/termek/123/
→ m.pelda.hu/

Helyesebb:

pelda.hu/termek/123/
→ m.pelda.hu/termek/123/

Külön mobiloldalaknál ellenőrizd:

• a kölcsönös canonical és alternate kapcsolatot;
• a megfelelő URL-párokat;
• a státuszkódokat;
• az eszközfelismerést;
• a Googlebot kezelését;
• a hibás átirányításokat;
• a szerveroldali gyorsítótárat.

Általában az egyetlen URL-en működő reszponzív kialakítás könnyebben karbantartható és kisebb technikai hibakockázattal jár.

Hibás strukturált adatok mobilon

A mobilverzión ugyanazokat a releváns strukturált adatokat kell biztosítani, mint az asztali oldalon, és azoknak egyezniük kell a látható mobilos tartalommal.

Ellenőrizd:

• az Organization vagy LocalBusiness adatokat;
• az Article vagy BlogPosting objektumot;
• a Product és Offer mezőket;
• a BreadcrumbList jelölést;
• a szerzői adatokat;
• a képeket;
• az árakat;
• a készletet;
• a dátumokat;
• a GYIK-et.

Hiba lehet, ha mobilon:

• teljesen hiányzik a JSON-LD;
• kevesebb termékadat szerepel;
• más ár jelenik meg;
• a Schema olyan GYIK-et tartalmaz, amely mobilon nem látható;
• a fő kép URL-je nem tölthető be.

Eltérő hreflang beállítások

Nemzetközi weboldalon a mobilos és asztali URL-ek hreflang kapcsolatai könnyen ellentmondásossá válhatnak.

Vizsgáld meg:

• minden nyelvi változat visszahivatkozik-e;
• a mobil URL a megfelelő mobil nyelvi URL-re mutat-e;
• az asztali URL-ek egymással vannak-e összekötve;
• a canonical nem mutat-e másik nyelvre;
• szerepel-e x-default, ha indokolt;
• érvényesek-e a nyelvi és régiós kódok.

Rossz mobilos tipográfia és tartalmi szerkezet

A hosszú, tagolatlan szöveg mobilon sokkal nehezebben olvasható, még akkor is, ha technikailag megfelelően jelenik meg.

Javítsd:

• a túl hosszú bekezdéseket;
• a gyenge címsorhierarchiát;
• a hatalmas szövegblokkokat;
• a túl sok kiemelést;
• a nehezen áttekinthető listákat;
• a túl széles táblázatokat;
• a hosszú, tördelés nélküli URL-eket;
• a túl nagy fejlécet.

Mobilon különösen fontos:

• a rövidebb bekezdés;
• a jól látható alcím;
• a megfelelő sortávolság;
• az áttekinthető tartalomjegyzék;
• a logikus információs sorrend.

Mobilon eltérő vagy hibás hirdetéselhelyezés

A túl sok hirdetés eltolhatja a fő tartalmat, növelheti a CLS-t és nehezítheti az olvasást.

Keresd:

• a hajtás feletti túlzott hirdetéseket;
• a tartalmat megszakító sűrű reklámokat;
• az elmozdulást okozó hirdetéshelyeket;
• a teljes képernyős hirdetéseket;
• az egymásra nyíló reklámokat;
• a közeli hirdetés- és navigációs gombokat;
• a nem előre lefoglalt helyeket.

Hogyan ellenőrizd a mobilos SEO-problémákat?

A mobilos auditban kombináld a Google eszközeit, a webhely-crawlokat és a valódi eszközön végzett kézi tesztelést.

Ne csak egyetlen mobilméreten tesztelj. Vizsgálj:

• keskeny telefont;
• nagyobb okostelefont;
• álló és fekvő nézetet;
• Androidot és iOS-t;
• lassabb mobilinternetet;
• gyengébb teljesítményű készüléket.

Milyen mobilos hibákat javíts először?

Elsőként azokat a hibákat kezeld, amelyek miatt a mobilos Googlebot nem látja a teljes tartalmat, vagy a látogatók nem tudják használni a legfontosabb funkciókat.

Mobilos SEO ellenőrző lista

A mobilos SEO-vizsgálat akkor teljes, ha a tartalmi, technikai, teljesítmény- és használhatósági különbségeket egyaránt ellenőrizted.

• Mobilon is elérhető a teljes fő tartalom.
• A title és meta description megfelelő.
• Nincs hibás noindex.
• A canonical egyezik az asztali változatéval.
• A strukturált adatok teljesek és következetesek.
• A CSS és JavaScript nincs blokkolva.
• A mobilmenü működik.
• A fontos belső linkek mobilon is elérhetők.
• Nincs vízszintes görgetés.
• A képek és videók reszponzívak.
• A szöveg nagyítás nélkül olvasható.
• A kattintható elemek megfelelő méretűek.
• Az űrlapok telefonon is használhatók.
• A popupok nem takarják el a fő tartalmat.
• A végtelen görgetéshez vannak feltérképezhető URL-ek.
• Megfelelő a mobilos LCP, INP és CLS.
• Valódi telefonon is tesztelted az oldalt.
• Ellenőrizted a Googlebot Smartphone renderelését.
• Összevetetted a mobilos és asztali tartalmat.
• Készítettél prioritás szerinti javítási tervet.

A mobilos SEO legfontosabb alapelve, hogy a telefonos változat ne legyen az asztali oldal csökkentett értékű másolata. Ugyanazt a lényegi tartalmat, technikai információt és navigációs lehetőséget kell biztosítania, gyorsabb, egyszerűbb és kis képernyőre optimalizált megjelenítéssel. Mivel a Google a mobilos változat alapján térképezi fel és értékeli az oldalakat, minden mobilon elrejtett fontos szöveg, hibás link vagy technikai eltérés az egész webhely keresőteljesítményét ronthatja.

Hogyan priorizáld a talált hibákat?

Milyen eszközöket érdemes használni technikai SEO audithoz?

Milyen hibákat követnek el a legtöbben?

A technikai SEO audit önmagában még nem javítja a weboldal teljesítményét. A legnagyobb hibát sokan már az audit elkészítése során elkövetik: rosszul értelmezik az adatokat, vagy olyan problémákra fordítanak túl sok időt, amelyeknek alig van hatásuk a keresőoptimalizálásra. Egy jól elkészített audit nem a hibák számáról, hanem a megfelelő következtetésekről és a javítási tervről szól.

Az egyik leggyakoribb hiba, hogy valaki kizárólag egyetlen SEO eszköz eredményeire támaszkodik. Bár a különböző auditprogramok rendkívül hasznosak, egyik sem látja teljes egészében a weboldal működését. Érdemes mindig összevetni a Google Search Console, egy webhelycrawler (például Screaming Frog vagy Sitebulb) és a teljesítménymérő eszközök adatait.

Sokan elkövetik azt a hibát is, hogy minden figyelmeztetést egyformán fontosnak tekintenek. Egy hiányzó meta leírás javítása általában jóval kisebb hatással van a SEO-ra, mint egy hibás robots.txt fájl, egy rosszul beállított canonical címke vagy egy tömeges indexelési probléma. Ezért mindig a kritikus hibákat kell elsőként javítani.

Gyakori probléma az is, hogy az audit csak az asztali verzióra koncentrál. Mivel a Google mobil-first indexelést használ, legalább akkora figyelmet kell fordítani a mobilos megjelenésre, a Core Web Vitals mutatókra és a telefonos használhatóságra is.

Sok weboldal-tulajdonos kizárólag a technikai hibák kijavítására összpontosít, miközben megfeledkezik a tartalom minőségéről és a belső linkelésről. Egy technikailag hibátlan weboldal sem fog jó eredményeket elérni, ha a tartalom nem válaszolja meg a felhasználók kérdéseit, vagy a fontos oldalak nincsenek megfelelően összekapcsolva.

A javítások után gyakran elmarad az ellenőrzés is. Egy hibás átirányítás, egy rosszul sikerült fejlesztés vagy egy WordPress-frissítés könnyen új problémákat okozhat. Ezért minden módosítás után érdemes újra lefuttatni a technikai SEO auditot, és ellenőrizni, hogy valóban megszűntek-e a korábban feltárt hibák.

A leggyakoribb technikai SEO audit hibák

A technikai SEO audit akkor igazán értékes, ha nem csupán egy hosszú hibalistát készít, hanem világos iránymutatást ad a fejlesztésekhez. A legjobb eredményeket azok a weboldalak érik el, ahol az audit rendszeresen ismétlődik, a hibákat fontossági sorrendben javítják, és a technikai optimalizálás szorosan együttműködik a minőségi tartalommal, a jó felhasználói élménnyel és a folyamatos SEO-fejlesztésekkel.

Technikai SEO audit ellenőrző lista

Egy átfogó technikai SEO audit során nem elegendő csupán néhány hibát kijavítani. Az alábbi ellenőrző lista segít abban, hogy a weboldal minden fontos technikai elemét átvizsgáld, és semmilyen lényeges SEO-probléma ne maradjon rejtve.

Feltérképezés és indexelés

• A weboldal indexelhető oldalai elérhetők a Google számára.
• A robots.txt fájl megfelelően van beállítva.
• Az XML sitemap naprakész és hibamentes.
• Minden fontos oldal szerepel a sitemapben.
• Nincs véletlenül noindex címkével ellátott fontos oldal.
• A canonical címkék megfelelő URL-re mutatnak.
• Nincsenek hibás átirányítások vagy átirányítási láncok.
• A 404-es és 5xx hibák száma minimális.
• A Google Search Console nem jelez kritikus indexelési hibát.

Weboldal szerkezete

• A belső linkelési rendszer logikus és jól felépített.
• Nincsenek árva (orphan) oldalak.
• A fontos oldalak néhány kattintással elérhetők.
• A breadcrumb navigáció megfelelően működik.
• A belső linkek nem mutatnak hibás URL-ekre.

Duplikációk

• Nincsenek duplikált title elemek.
• Nincsenek ismétlődő meta descriptionök.
• Nem találhatók jelentős duplikált tartalmak.
• A www és nem-www változat megfelelően átirányított.
• A HTTP verzió HTTPS-re irányít.
• A paraméteres URL-ek megfelelően kezeltek.

Mobilbarát működés

• A weboldal teljesen reszponzív.
• Mobilon is minden fontos tartalom elérhető.
• A menü és a navigáció megfelelően működik.
• A gombok és linkek könnyen használhatók.
• A mobilos betöltési sebesség megfelelő.

Teljesítmény és Core Web Vitals

• Az LCP érték megfelelő.
• Az INP érték megfelelő.
• A CLS érték alacsony.
• A képek optimalizáltak.
• A JavaScript és CSS fájlok optimalizáltak.
• A gyorsítótár megfelelően működik.
• A szerver válaszideje megfelelő.

Strukturált adatok

• A Schema markup hibamentes.
• A strukturált adatok megfelelnek a látható tartalomnak.
• A Rich Results Test nem jelez hibát.
• A LocalBusiness, Organization vagy Service Schema megfelelően van beállítva.
• A Breadcrumb Schema működik.

On-page technikai elemek

• Minden oldalnak egyedi title eleme van.
• A meta descriptionök egyediek.
• Minden oldalnak egyetlen H1 címe van.
• A címsorok logikus hierarchiát követnek.
• A képek rendelkeznek alt attribútummal.

Biztonság

• HTTPS működik minden oldalon.
• Nincs vegyes (Mixed Content) tartalom.
• Az SSL tanúsítvány érvényes.
• Az átirányítások biztonságosak.

Technikai hibák

• Nincsenek törött belső linkek.
• Nincsenek hibás képek.
• A JavaScript nem akadályozza a feltérképezést.
• A CSS fájlok nincsenek blokkolva.
• A fontos oldalak 200-as státuszkóddal érhetők el.

Google-eszközök ellenőrzése

• Google Search Console hibák átnézve.
• Core Web Vitals jelentés ellenőrizve.
• URL-ellenőrző eszközzel tesztelve a fontos oldalak.
• PageSpeed Insights eredményei átvizsgálva.

Audit lezárása

• A hibák prioritási sorrendbe kerültek.
• Elkészült a javítási terv.
• A javítások után újra lefutott a technikai SEO audit.
• A Search Console-ban ellenőrizted az eredményeket.
• Dokumentáltad az elvégzett módosításokat.

Érdemes ezt az ellenőrző listát legalább negyedévente újra végigvenni, illetve minden nagyobb weboldal-fejlesztés, WordPress-frissítés vagy szerkezeti módosítás után ismét lefuttatni. A rendszeres technikai SEO audit segít megelőzni az indexelési problémákat, javítja a felhasználói élményt, és stabil alapot biztosít a hosszú távú keresőoptimalizálási eredményekhez.

Összegzés

A technikai SEO audit az egyik legfontosabb alapja egy sikeres keresőoptimalizálási stratégiának. Hiába készülnek kiváló tartalmak és minőségi linkek mutatnak a weboldalra, ha a Google nem tudja megfelelően feltérképezni, indexelni vagy értelmezni az oldalt, a várható eredmények elmaradnak.

Egy alapos technikai audit során érdemes végigvizsgálni az indexelést, a feltérképezhetőséget, a belső linkelési rendszert, a weboldal sebességét, a Core Web Vitals mutatókat, a mobilos működést, a strukturált adatokat, a duplikált tartalmakat és az esetleges technikai hibákat. Ezek együtt biztosítják azt a stabil alapot, amelyre a tartalommarketing és a többi SEO-feladat épülhet.

Fontos azonban, hogy a technikai SEO audit ne egyszeri feladat legyen. Egy új WordPress-bővítmény, egy weboldal-frissítés, egy sabloncsere vagy akár egy kisebb fejlesztés is okozhat olyan problémákat, amelyek hosszú távon rontják a keresőbeli teljesítményt. Ezért érdemes rendszeresen – legalább évente néhány alkalommal, illetve minden jelentősebb módosítás után – újra átvizsgálni a weboldalt.

A mesterséges intelligenciára épülő keresők és a Google folyamatos fejlődése miatt a technikai SEO szerepe tovább erősödik. Az AI-rendszerek számára is kulcsfontosságú, hogy a weboldal logikusan felépített, gyors, jól strukturált és könnyen értelmezhető legyen. A megfelelő technikai háttér nemcsak a hagyományos keresési találatokban segíthet jobb helyezéseket elérni, hanem növelheti annak esélyét is, hogy a tartalom megjelenjen az AI-alapú válaszokban és összefoglalókban.

Egy jól elkészített technikai SEO audit tehát nem csupán hibákat tár fel, hanem világos fejlesztési tervet is ad. Ha a feltárt problémákat fontossági sorrendben javítod, weboldalad gyorsabbá, biztonságosabbá, felhasználóbarátabbá és keresőoptimalizálási szempontból is sokkal versenyképesebbé válik. Ez hosszú távon több organikus látogatót, jobb felhasználói élményt és stabilabb online jelenlétet eredményez.

GYIK – gyakran ismételt kérdések

Mi az a technikai SEO audit?

A technikai SEO audit egy átfogó vizsgálat, amely feltárja a weboldal technikai hibáit. Célja annak ellenőrzése, hogy a Google és más keresőmotorok megfelelően tudják-e feltérképezni, indexelni és értelmezni az oldalt.

Milyen gyakran érdemes technikai SEO auditot készíteni?

Érdemes legalább félévente egyszer elvégezni, de minden nagyobb weboldal-frissítés, sabloncsere vagy szerkezeti módosítás után is ajánlott újra lefuttatni az auditot.

Mennyi ideig tart egy technikai SEO audit?

Ez nagymértékben függ a weboldal méretétől. Egy kisebb vállalkozói honlap auditja néhány órát vehet igénybe, míg egy több ezer oldalas webáruház elemzése akár több napig is eltarthat.

Milyen eszközök szükségesek egy technikai SEO audithoz?

A leggyakrabban használt eszközök közé tartozik a Google Search Console, a Google PageSpeed Insights, a Screaming Frog SEO Spider, a Sitebulb, az Ahrefs Site Audit, a Semrush Site Audit, valamint a Rich Results Test és a Schema Markup Validator.

Mi a különbség a technikai SEO és az on-page SEO között?

A technikai SEO a weboldal működésére, feltérképezhetőségére, indexelésére és teljesítményére koncentrál, míg az on-page SEO elsősorban a tartalom, a címsorok, a meta elemek és a kulcsszóhasználat optimalizálásával foglalkozik.

Befolyásolja a technikai SEO a Google helyezéseket?

Igen. Bár a technikai SEO önmagában nem garantál első helyezést, megfelelő technikai alapok nélkül a keresőmotorok nehezebben tudják feldolgozni a weboldalt, ami jelentősen ronthatja a rangsorolást.

Miért fontos a Core Web Vitals egy technikai audit során?

A Core Web Vitals mutatók megmutatják, milyen gyors és stabil a weboldal, illetve mennyire jó felhasználói élményt nyújt. A lassú vagy instabil oldalak rosszabb felhasználói élményt eredményeznek, ami a keresőoptimalizálásra is negatív hatással lehet.

Elég egyszer elkészíteni egy technikai SEO auditot?

Nem. A weboldalak folyamatosan változnak, új tartalmak, bővítmények és frissítések kerülnek fel, ezért rendszeres ellenőrzésre van szükség ahhoz, hogy a technikai hibák ne halmozódjanak fel.

Segít a technikai SEO audit az AI keresőkben való megjelenésben?

Igen. Az AI-alapú keresők és asszisztensek is előnyben részesítik a gyors, jól strukturált, könnyen feltérképezhető weboldalakat. A megfelelő technikai háttér növeli annak esélyét, hogy a tartalom megjelenjen az AI által generált válaszokban is.

Mikor érdemes SEO szakember segítségét kérni?

Ha a weboldalon tartós indexelési problémák jelentkeznek, romlanak a helyezések, sok technikai hibát jeleznek az elemzőeszközök, vagy nagyobb weboldal-fejlesztés előtt állsz, érdemes tapasztalt SEO szakember segítségét kérni. Egy professzionális technikai SEO audit sok időt takaríthat meg, és segíthet megelőzni a komolyabb hibákat.

Miért érdemes befektetni egy jó SEO szakértőbe?

A SEO ma már jóval többről szól, mint néhány kulcsszó optimalizálásáról. Az AI Overviews, a GEO (Generative Engine Optimization), a szemantikus SEO, az entitásalapú keresés és a topical authority korában azok a weboldalak kerülnek előnybe, amelyek valódi szakértői tudásközpontként jelennek meg a Google és az AI-alapú keresők számára.

Egy profi SEO szakértő nemcsak a jobb helyezések elérésében segít, hanem olyan hosszú távú stratégiát épít, amely növeli a weboldalad láthatóságát, erősíti a márkádat, és releváns érdeklődőket hoz az oldaladra. A megfelelően felépített SEO nem egyszeri költség, hanem olyan befektetés, amely hónapokon és éveken keresztül képes folyamatos forgalmat és új ügyfeleket generálni.

A keresési környezet folyamatosan változik. A Google algoritmusai, az AI-alapú találatok és a felhasználói szokások is egyre gyorsabban alakulnak. Egy tapasztalt SEO szakember segít alkalmazkodni ezekhez a változásokhoz, kiépíteni a szükséges topical authorityt, valamint olyan tartalomstratégiát kialakítani, amely nemcsak ma, hanem a jövő keresőiben is versenyképes marad. Egy rosszul kivitelezett SEO munka viszont könnyen idő-, pénz- és forgalomveszteséget okozhat, ezért különösen fontos, hogy a weboldalad optimalizálását valódi szakértőre bízd.

Miért érdemes választani a HonlapSEO-t?

Több éve foglalkozom keresőoptimalizálással, és munkám során nemcsak a hagyományos SEO-ra, hanem a modern keresési trendekre, az AI-alapú keresésekre és a GEO (Generative Engine Optimization) stratégiákra is kiemelt figyelmet fordítok. Segítek abban, hogy weboldalad ne csupán jobb helyezéseket érjen el a Google találati listáján, hanem az AI-alapú rendszerek, például a ChatGPT, a Google AI Overviews vagy a Perplexity számára is hiteles és könnyen feldolgozható forrássá váljon.

Szolgáltatásaim közé tartozik a SEO audit, a technikai optimalizálás, a kulcsszókutatás, a SEO szövegírás, a topical authority építés, a tartalomstratégia kialakítása, valamint a belső linkrendszer és a szemantikus SEO fejlesztése. Minden projekt során hosszú távú gondolkodásra törekszem, hiszen a cél nem csupán a rövid távú helyezésjavulás, hanem egy stabil, folyamatosan növekvő organikus jelenlét kialakítása. Ehhez a havidíjas SEO-t ajánlom.

Ha szeretnéd, hogy weboldalad valódi szakértői státuszt építsen ki a saját piacán, növelje a látogatottságát és felkészüljön az AI-alapú keresések jövőjére, szívesen segítek a megfelelő SEO és GEO stratégia kialakításában.

Keresőoptimalizáláshoz profi Seo szakembert keresel? Azonnal használható, gyors megoldások a Google irányelvei alapján. Megjelennél a a Google AI Overviews találataiban?

Elérhetőségeim:

Burai Barbi SEO szakember, SEO szakértő,

 AI-GEO mentor

Telefon: +36-30-242-9494

E-mail: info(kukac)honlapseo.hu

Web: HonlapSEO   SEO alapok

Eredményes keresőoptimalizáláshoz profi SEO szakembert keresel?

Vedd fel Velem a kapcsolatot az alábbi űrlap kitöltésével:

• About
• Latest Posts

Burai Barbi SEO szakember, Honlap SEO

SEO szakember, Keresőoptimalizálás szakértő at HonlapSEO

Keresőoptimalizálás, SEO, Honlap SEO, SEO tanácsadás, SEO audit, SEO szövegírás, weboldal elemzés, versenytárs elemzés. SEO szakértő segítségével, a honlapok keresőbeli előkelőbb helyezésének elérése. Gyors, hatékony megoldások a Google irányelvei alapján. A már elkészült honlapok utólagos keresőoptimalizálása, SEO több éves szakmai tapasztalattal.
Google AI Overviews optimalizálás, Topical authority építés, GEO és AI keresőkre optimalizálás.

Latest posts by Burai Barbi SEO szakember, Honlap SEO (see all)

• Technikai SEO audit készítése - 2026-07-22
• Miért nem talál meg az AI, ha a Google igen? - 2026-07-21
• Entity SEO lépésről lépésre - 2026-07-20