Technikai SEO ellenőrzőlista: A végső lista a webhely javításához

.

Technikai SEO ellenőrzőlista

Lekérdezés és indexelés

Az első dolog, amit a technikai audit során meg kell vizsgálni, az az, hogy webhelyét hogyan indexelik és kúsznak be a keresőmotorok. Hiszen ha a webhelyén lévő oldalakat nem lehet feltérképezni, akkor nem is indexelik őket (kevés kivételtől eltekintve). Ennek következtében az indexben nem szereplő oldalak nem fognak részt venni a rangsorolásban.

Tekintse át az Oldalindexelési jelentést a Google Search Console alkalmazásban.

A legpontosabb és legmegbízhatóbb módja webhelye indexelésének elemzésére a Google Search Console-ban található Oldalindexelési jelentés elemzése. Nézze meg az indexelt oldalak jelentését, és ellenőrizze, hogy mely oldalak szerepelnek az indexben. Nézze meg, hogy vannak-e olyan oldalak, amelyeken szűrési vagy rendezési lehetőségek vannak, vannak-e tesztoldalak vagy más olyan oldalak, amelyeket nem szeretne indexelni. Nézze meg a kizárt oldalakat is. Nem minden állapot a Kizárt oldalak jelentésben jelentkező állapotok jelentenek problémát. Nem az összes kizárt oldalra kell összpontosítania a figyelmét, hanem csak azokra, ahol a Google viselkedése nem felel meg az Ön szándékainak. Az alábbi táblázatban láthatja azokat az állapotokat, amelyek általában figyelmet és mélyebb elemzést igényelnek:

Állapot	Mit jelent	Mit kell tennie
Átirányítási hiba	A Google nem tudta követni az URL-t átirányítási problémák miatt.	Csökkentse az átirányítások számát (1-2-re). Kerülje a végtelen és körkörös átirányításokat.- Győződjön meg róla, hogy a végső URL 200 OK-t ad vissza, és nincs blokkolva a robots.txt/noindexben.
Szerverhiba	A szerver 5xx hibát küldött vissza.	Ellenőrizze a szervernaplókat. Győződjön meg róla, hogy a webhely nincs túlterhelve.- Javítsa ki a belső hibákat, különösen, ha azok ismétlődnek.
Felfedezett – nem indexelt	A Google tud az oldalról, de még nem láncolta be. A feltérképezési költségvetéssel kapcsolatos problémákat jelez.	Győződjön meg róla, hogy az oldal szerepel az oldaltérképen. Adjon hozzá belső linkeket. Optimalizálja a feltérképezési költségvetést.
Feltérképezve – nem indexelve	A Google meglátogatta az oldalt, de úgy döntött, hogy nem indexeli. Általában alacsony oldalminőséget jelez.	Javítsa a tartalom minőségét és egyediségét. Győződjön meg arról, hogy az oldal nem tartalmaz duplikátumokat. Adjon hozzá belső linkeket.
Duplikátum felhasználó által kiválasztott kanonikus nélkül	A Google az oldalt duplikátumnak tekinti, de nem adott meg kanonikus elemet.	Ellenőrizze az oldalpárokat, és adja meg a szükséges kanonikust, vagy gondolja át az oldalszerkezetet.
Duplikátum, a Google a felhasználótól eltérő kanonikust választott	A Google figyelmen kívül hagyta az Ön által megadott kanonikust.	Ennek számos oka lehet; alaposan meg kell vizsgálnia az oldal adatait, és ki kell választania a legmegfelelőbb stratégiát (noindex, átirányítás, eltávolítás, robots.txt, a webhelyszerkezet és a belső hivatkozás megváltoztatása).
Soft 404	Az oldal „üresnek” vagy „nem találhatónak” tűnik, de 200 OK státuszt küld vissza.	404-es vagy 410-es visszaadás. Készítsen átirányítást. Javítsa a tartalmat. Blokkolja az indexeléstől.

A többi státusz valószínűleg nem jelez semmilyen problémát. Azonban ezeket a jelentéseket is érdemes átnézni, hogy megbizonyosodjunk arról, hogy az oldalakat nem távolították el, irányították át, kanonizálták vagy blokkolták az indexelésből véletlenül.

Állapot	Mit jelent	Amit tudnia kell
Alternatív oldal megfelelő kanonikus címkével	A Google helyesen nyugtázta az Ön által megadott kanonikus taget.	Minden az elvárásoknak megfelelően működik. Nincs szükség intézkedésre. Győződjön meg róla, hogy megadta a kívánt kanonikus taget.
A robots.txt által blokkolt URL	A Google nem tudja feltérképezni az oldalt.	Ellenőrizze a robots.txt fájlt. Engedélyezze a hozzáférést, ha azt szeretné, hogy indexelésre kerüljön.
„noindex” jelzésű URL	Az oldal rendelkezik a noindex direktívával.	Győződjön meg róla, hogy a noindex tag szándékosan van beállítva. Ha az oldal fontos, távolítsa el ezt a taget.
Nem található (404)	Az oldal nem létezik.	Ha ez fontos, állítsa vissza az oldalt. Ha az oldal véglegesen törlődött, győződjön meg arról, hogy nincsenek rá mutató belső hivatkozások.
Nem engedélyezett kérés miatt blokkolva (401)/ Hozzáférés tiltva (403)	Az oldal jogosultság miatt blokkolva vagy tiltott.	Engedélyezze a hozzáférést, ha az oldalt indexelni kell.
Oldal átirányítással	Az oldal átirányít egy másikra.	Ellenőrizze, hogy az átirányítás szándékos és helyes-e.
Egyéb 4xx probléma miatt blokkolt URL	Az oldal a 404-től eltérő 4xx hiba (pl. 403, 401, 410 stb.) miatt nem érhető el.	Ellenőrizze manuálisan a HTTP státuszkódot. Javítsa ki a hozzáférési beállításokat. Állítson be helyes státuszkódokat vagy átirányításokat. Engedélyezze a Googlebot számára a hozzáférést, ha szükséges.

A Google Súgóközpontban átfogó leírást talál az oldaljelentésről, példákkal a problémákra és az egyes státuszok részletes magyarázatával. A Screaming Frog segíthet az indexelt vagy az indexből kizárt oldalak elemzésében is. Ehhez az oldal feltérképezésének megkezdése előtt csatlakoznia kell a Google Search Console API-hoz. A csatlakozáshoz válassza a Konfiguráció -> API hozzáférés -> Google Search Console menüpontot. Kattintson a Sign in with Google (Bejelentkezés a Google-lal) gombra, és kövesse az utasításokat.

A csatlakozást követően engedélyezze az URL-ellenőrzést, és engedélyezheti azt a lehetőséget is, hogy figyelmen kívül hagyja az indexelés ellenőrzését az indexelhetetlen URL-ek esetében.

Ezután láthatja és összehasonlíthatja az egyes oldalak állapotát a Search Console szerint (ahogyan a Google látja) és a tényleges állapotát, ahogyan azt a feltérképezési folyamat során megállapították.

Felhívjuk figyelmét, hogy naponta csak 2000 URL érhető el egy-egy webhely esetében, ezért ez a módszer inkább kis webhelyek számára alkalmas.

Ellenőrizze, hogy mi van a sitemap.xml fájlban

A Sitemap.xml egy olyan XML-fájl, amely a keresőmotorok lánctalpasai számára egy webhely oldalainak listáját, valamint (opcionálisan) az utolsó módosításuk dátumára, a frissítés gyakoriságára és az ajánlott lánctalpas prioritásra vonatkozó információkat szolgáltatja. Általában a webhely gyökerénél helyezik el, például: https://example.com/sitemap.xml. Az Sitemap.xml segít a keresőmotoroknak gyorsabban megtalálni az új vagy frissített oldalakat. Ezenkívül egy oldalnak ebben a fájlban való szerepeltetése az egyik, bár gyenge jel az oldal kanonikus változatának meghatározásához.

A sitemap.xml fájl különösen hasznos:

• kevés külső hivatkozással rendelkező új oldalak;
• nagy, sok oldallal rendelkező webhelyek;
• sok médiatartalommal rendelkező oldalak;
• gyakran frissülő híroldalak.

A Sitemap.xml-nek tartalmaznia kell az összes olyan oldalt, amelyet indexelni szeretne. A Screaming Frog vagy más lánctalpasok segítségével ugyanúgy elemezheti a Sitemap.xml-ben szereplő oldalakat. A Screaming Frogban a sitemap.xml külön is átvizsgálható a List Mode-ban, vagy beilleszthető egy normál webhely átvizsgálásba. Ehhez a Configuration -> Spider -> Crawl menüpontban aktiválja az XML sitemap szkennelést, és adja hozzá a feltérképezni kívánt sitemapok abszolút URL-jét. Nem ajánlott különböző online szolgáltatásokat használni a Sitemap generálásához, mivel ezek csak statikus sitemapet generálhatnak, amely nem frissül automatikusan. Az optimális megoldás az, ha a sitemap.xml-t annak a CMS-nek a bővítményeivel generálja, amelyen a webhely fut, vagy ha olyan egyéni szkriptet ír, amely a megadott feltételek szerint generálja a sitemap-et, és automatikusan frissíti azt, amikor a webhelyen változások történnek. A sitemap.xml generálásakor ügyeljen arra, hogy a fájl megfeleljen a sitemap.xml protokollnak. Ehhez különböző online validátorokat használhat, például a https://www.xml-sitemaps.com/validate-xml-sitemap.html. Szükséges-e a protokollban felsorolt összes címkét tartalmaznia? Nem mindig. A Google például csak a <loc> és a <lastmod> címkéket veszi figyelembe. Ügyeljen arra, hogy a <lastmod> tagben szereplő dátum pontos legyen. Ha megpróbálják manipulálni, a Google figyelmen kívül hagyhatja ezt a taget.

Győződjön meg arról, hogy a robots.txt fájlban nincsenek hibák.

A robots.txt fájl az első hely, amelyet a keresőrobot megnéz, mielőtt feltérképez egy webhelyet. Ez határozza meg, hogy a webhely mely részeit lehet és melyeket nem lehet feltérképezni, és ennek eredményeképpen a keresőmotorok mely oldalakat indexelik. Mindig a https://example.com/robots.txt címen kell lennie . Ez a fájl a webhely lánctalpas feltérképezésének (nem indexelésének!) irányítására szolgál. Egyes oldalakat, még ha a robots.txt-ben le is tiltja őket, akkor is indexelhetők (általában akkor, ha belső vagy külső linkek vezetnek rájuk). Az ilyen (a robots.txt-ben blokkolt oldalak ellenére indexelt) oldalak a Google Search Console-ban az „Indexelt, bár a robots.txt által blokkolt” jelentésben láthatók.

Íme, mit kell feltétlenül ellenőrizni a robots.txt fájl tekintetében egy technikai SEO audit részeként:

1. A fájl elérhetősége

A fájlnak elérhetőnek kell lennie a https://example.com/robots.txt címen, és 200 OK válasz státuszt kell adnia. Hiánya, letöltési hibák vagy átirányítások (301, 302, 403, 404) megakadályozhatják, hogy a keresőmotorok helyesen értelmezzék a webhely lánctalpas szabályait.

1. Szintaxis és helyesség

Ellenőrizze, hogy a fájlszerkezet követi-e a szabványt. Példa egy alapsablonra:

• User-agent: *
• Letiltás: /admin/
• Allow: /public/
• Oldaltérkép: https://example.com/sitemap.xml

1. Letiltás és engedélyezés direktívák

Ellenőrizze, hogy a fontos oldalakat véletlenül sem tiltja-e le, pl:

• Főoldal (/)
• Termékkártyák (/product/)
• Blog vagy cikkek (/blog/, /articles/)

Gyakori hiba a képek, stílusok és szkriptek letiltása az adminisztratív mappák letiltásakor. Ilyen esetben meg kell határozni, hogy bár az adminisztrációs mappa blokkolva van, bizonyos fájltípusok mégis nyitva maradjanak a beolvasás előtt. Ez gyakran előfordul WordPress oldalakon, amikor az összes felhasználói tartalmat tartalmazó mappa, Disallow: /wp-content van blokkolva. Ebben az esetben csak bizonyos formátumú fájlok nyithatók meg vizsgálatra:

• Allow: /wp-content/uploads/*.css
• Allow: /wp-content/uploads/*.js
• Allow: /wp-content/uploads/*.jpeg

A robots.txt érvényesítéséhez és a hozzáadni kívánt irányelvek teszteléséhez használhatja ezt az eszközt.

1. Más irányelvekkel való kompatibilitás ellenőrzése

Gyakran előfordulnak hibák, amikor a robots.txt ütközik a következőkkel:

• meta tag <meta name=”robots” content=”noindex”>
• canonical

Ha például egy oldal a robots.txt-ben nyitva van, de a noindexen keresztül blokkolva, akkor az oldal ugyan feltérképezésre kerül, de nem kerül be az indexbe. Ez elfogadható, de fontos, hogy ez szándékosan történik. Szintén gyakori probléma, ha a forráskódban más utasítások vannak a botok számára, és ezzel egyidejűleg az oldal blokkolása a robots.txt-ben. A keresőrobotok nem vizsgálják a robots.txt-ben blokkolt oldalakat. Nem látják a kódban megadott címkéket, például a kanonikalizációt. Vagyis egy ilyen kanonikus egyszerűen nem lesz számon tartva.

Ellenőrizze a belső linkelését

A technikai audit egyik legfontosabb feladata annak biztosítása, hogy az oldal belső linkelése megfelelően működjön. Ez azt jelenti, hogy minden belső hivatkozásnak valódi, létező oldalakra kell vezetnie, amelyek nyitottak az indexelésre, 200 OK státuszkódot adnak vissza, nem tartalmaznak átirányításokat, és ami a legfontosabb, nem mutatnak 4xx/5xx hibás oldalakra. Első pillantásra ez apróságnak tűnhet, de a gyakorlatban már a helytelen belső linkek is negatívan befolyásolhatják:

• A webhely keresőmotorok általi feltérképezésének hatékonyságát,
• A belső SEO súlyának (PageRank) eloszlását,
• A felhasználói élményt.

Az elemzés első lépése az összes belső hivatkozás hibaellenőrzése. Különösen fontos a 404-es, 410-es vagy egyéb hibás (pl. 403-as, 500-as) oldalakra vezető hibás linkek azonosítása. Az alábbi táblázatban a belső linkekben előforduló főbb hibatípusok, jelentésük és a javításukhoz javasolt intézkedések szerepelnek.

Hiba típusa	Mit jelent	Mi a teendő
404	Az oldal nem található	Távolítsa el a linket, vagy cserélje ki egy működőre.
403	Hozzáférés megtiltva	Ellenőrizze a hozzáférési beállításokat
301/302	Átirányítás	Frissítse a linket a végleges URL-re
5xx	Szerver hiba	Ellenőrizze a szervert vagy a CMS-t

Fontos az oldalhierarchia mélységének elemzése is, vagyis annak meghatározása, hogy a főoldaltól hányadik szinten és hány kattintással távolabb található a kulcsfontosságú tartalom. A fontos oldalak lehetőleg ne legyenek mélyebben, mint a harmadik szint – ez növeli elérhetőségüket mind a keresőmotorok, mind a felhasználók számára. Az elemzés egyik legfontosabb eleme az „árva” oldalak azonosítása – azoké, amelyekre nem mutatnak belső linkek. Még ha ezek az oldalak szerepelnek is az oldaltérképben, a belső hivatkozások hiánya miatt kevésbé hozzáférhetőek. Emellett fontos elemezni a horgonyszövegeket – a hivatkozásokat tartalmazó szavakat és kifejezéseket. Ezeknek relevánsnak és értelmesnek kell lenniük, mivel a horgonyszövegek segítenek a keresőmotoroknak megérteni a link kontextusát.

Elemezze a feltérképezési statisztikákat

A lánctalálási statisztikák elemzése egy módja annak, hogy megértsük, hogyan lép interakcióba a Googlebot egy oldallal: mely oldalakat láncolja fel, milyen gyakran, és ez hogyan befolyásolja a SEO-t. Ezek az adatok a Google Search Console → Beállítások → Lánctalpas statisztikák menüpontban érhetők el. Az alábbi táblázatban láthatja a leggyakoribb problémákat, amelyekről ebben a jelentésben tájékozódhat:

Probléma	Mit kell keresni a jelentésben	Lehetséges okok
A lánctalpasodás erőteljes csökkenése	Kevesebb mászás naponta	Hozzáférhetőségi problémák, helytelen beállítások a robots.txt-ben, blokkok, 5xx hibák.
Sok 4xx és 5xx hiba	Hibák az URL-ekben	Törölt oldalak, törött linkek, szerverproblémák
Megnövekedett válaszidő	>1 másodperc – figyelmeztető jel	Tárhelyproblémák, szervertúlterhelés
Sok 3xx átirányítás	Átirányítások a közvetlen URL-ek helyett	Hibás átirányítások, átirányítási láncok, nagyszámú belső link átirányítással.
CSS/JS nem láncolva	Hiányoznak a statisztikákból	Robots.txt által blokkolva

Ezenkívül a szervernaplók is elemezhetők. Ezek lehetővé teszik, hogy a keresőrobotok (nemcsak a Googlebot, hanem a Bingbot, a YandexBot és mások) tényleges kéréseit is láthassa, nem pedig csak a Google Search Console összesített adatait. Ez egy fejlett, „nyers” diagnosztikai módszer, amely jelentős időt igényel. Az adatok vizualizálásához olyan nyílt forráskódú eszközöket használhat, mint a GoAccess vagy a Screaming Frog Log File Analyser.

Strukturált adatok végrehajtása

A strukturált adat egy speciális jelölési formátum egy weboldalon, amely segít a keresőmotoroknak pontosabban és mélyebben megérteni az oldal tartalmát. A Google és más keresőmotorok számára „tippként” szolgál, hogy pontosan mi található az oldalon – egy cikk, termék, recept, ismertető, videó stb. Bár nem hivatalos rangsorolási jel, közvetve befolyásolja a rangsorolást azáltal, hogy javítja, hogyan értik meg a keresőmotorok az oldalt. A weboldalak strukturált adatainak fő szabványa vagy protokollja a Schema.org. Vannak más protokollok is, például az OpenGraph, de ezt a közösségi hálózatoknál használják. A Schema.org a Google, a Microsoft, a Yahoo és a Yandex közös projektje, amelyet a webes strukturált adatok egységes szabványának kidolgozására és karbantartására hoztak létre. A Schema.org több száz entitás-típust tartalmaz, a leggyakrabban használtakat az alábbi táblázat tartalmazza:

Kategória	Entitás (@típus)	Cél
Tartalom és oldalak	Cikk	Cikk vagy hírek tartalma
	Blogbejegyzés	Blogbejegyzés
	HírekCikk	Hírcikk a Google News számára
	GYIKAoldal	Gyakran Ismételt Kérdések (GYIK) oldal
	HowTo	Egy lépésről-lépésre útmutató
	Weboldal	Általános információk egy weboldalról
Termékek és ajánlatok	Termék	Termék leírása
	Ajánlat	Árajánlat
	AggregateOffer	Egy termék árkategóriája különböző eladóknál
Vélemények és értékelések	Értékelés	Egy termék vagy szolgáltatás értékelése
	Értékelés	Egy numerikus értékelés (gyakran egy Értékelésen belül)
	AggregateRating	Több értékelésen alapuló átlagos értékelés
Szervezetek és emberek	Szervezet	Egy vállalat vagy márka leírása
	LocalBusiness	Helyi vállalkozás elérhetőségi adatokkal és menetrenddel
	Személy	Egy személy (pl. cikkíró, előadó stb.)
Események	Esemény	Online vagy offline esemény
Navigáció és szerkezet	BreadcrumbList	Kenyérmorzsák navigációja
	SiteNavigationElement	Fő menüelemek
Multimédia	VideoObject	Videó metaadatokkal (videórészletekhez)
	ImageObject	Kép leírással
Oktatás és állások	Tanfolyam	Online tanfolyam vagy képzési program
	JobPosting	Álláshirdetés (a Google for Jobs esetében)

A strukturált adatokat ajánlott JSON-LD formátumban megvalósítani. Ez a blokk a HTML-dokumentum <head> vagy <body> részébe kerül, de a felhasználó számára nem jelenik meg – a keresőrobotok olvassák be. Minden nagyobb keresőmotor, például a Google, a Bing és a Yahoo támogatja ezt a formátumot. Egy példa a JSON-LD kódra az alábbiakban látható: <script type=”application/ld+json”> { „@context”: „https://schema.org”, „@type”: „Article”, „headline”: „What is JSON-LD?”, „author”: { „@type”: „Person”, „name”: „John Smith” }, „datePublished”: „A Schema.org protokoll egyes strukturált adattípusai segíthetnek a Google keresési találatokban a gazdag snippetek megjelenítésében is. Vegye figyelembe, hogy a Google követelményei a gazdag snippetek strukturált adataira vonatkozóan némileg eltérnek a Schema.org szabványtól. Gyakran több mezőt kell megadni, mint amennyit a Schema.org protokoll előír. tehát, ha Rich Snippetet szeretne elérni, kövesse a Google strukturált adatokra vonatkozó irányelveit. A microdata implementáció helyességét a rich snippet validátor segítségével ellenőrizheti. Számos microdata generátor is létezik, de ezek csak statikus kódot tudnak létrehozni, amely nem frissül az oldalon bekövetkező tartalmi változásokkal. Annak biztosítása, hogy a mikroadatokban szereplő információk megfeleljenek annak, ami a felhasználók számára az oldalon látható, a Google strukturált adatokra vonatkozó követelményeinek része. A strukturált adatokra vonatkozó irányelvek megsértése esetén az oldal elveszítheti az összes rich snippetet, és bizonyos esetekben manuális büntetéssel is számolnia kell. Ezért győződjön meg arról, hogy a mikroadatok automatikusan generálódnak és automatikusan frissülnek.

Tartalom

A technikai SEO-ellenőrzés részeként fontos értékelni az alapvető tartalmi jellemzőket: a címsorok és a meta-tagek szerkezetétől kezdve a képek alt attribútumainak meglétéig és az esetleges duplikált oldalakig. Ezek az elemek közvetlenül befolyásolják mind az indexelést, mind azt, hogy a keresőmotorok hogyan érzékelik az oldalt.

Tesztelje webhelyét a teljes duplikátumok tekintetében

Teljes duplikátumok akkor fordulnak elő, ha az azonos tartalom a webhely különböző URL-címein keresztül érhető el. A duplikációk teljesen károsíthatják webhelye rangsorolását. A teljes duplikációk leggyakoribb típusai a következők:

• HTTP-n és HTTPS-en keresztüli elérhetőség
• WWW-vel és anélkül való elérhetőség
• Hozzáférhetőség egy zárójeles perjelrel vagy anélkül
• URL-ek nagy- és kisbetűs elérhetősége
• Az oldal elérhetősége olyan fájlkiterjesztésekkel, mint .html, .htm, .php, .aspx, és azok nélkül is
• Az oldal tartalmát nem változtató paraméterek, például az UTM címkék
• Azonos tartalom különböző URL-címek alatt. Például egy termék két kategóriában szerepel, amelyek két különböző URL-címen keresztül érhetők el. Vagy a termékoldal elérhető az URL-ben szereplő kategóriával és anélkül.
• A webhely tesztverziói (a fejlesztéshez használt DEV domain).

Az URL-változatokhoz kapcsolódó oldalduplikátumok megtalálásához tesztelje az URL-eket kézzel, és ellenőrizze a kiszolgáló válaszkódját ezekre az URL-változatokra vonatkozóan. A szerver válaszkódok ellenőrzésére bármilyen eszközt használhat, például a https://httpstatus.io/. Adja meg az URL-variációkat, és ellenőrizze elérhetőségüket.

A HTTP/HTTPS, www/without-www, slash-sel/végződés nélkül, nagy/kisbetűvel, valamint a .html, .htm, .php, .aspx kiterjesztésű és az ezek nélküli oldalak elérhetőségével kapcsolatos problémák megoldásához 301-es átirányítást kell beállítani a preferált verzióra. Ha az azonos tartalom elérhetősége miatt duplikációkat találunk az URL-hez hozzáadott vagy eltávolított részekkel (például egy termék két kategóriában is elérhető), a legjobb, ha átgondoljuk az URL-struktúrát és a webhelyszerkezetet. Az UTM és egyéb paraméterek esetében a kanonikalizálás is megoldást jelenthet. Fontos azonban megjegyezni, hogy a Google a kanonikus címkét ajánlásként kezeli, és a végső döntés, hogy melyik URL-t választja, a Google-nál marad. Ha a webhely tesztváltozata megtalálható a Google indexében, akkor azt blokkolni kell az indexelésből, és a Google Search Console-on keresztül kérvényt kell küldeni az eltávolítására.

Részleges oldalduplikátumok feloldása

Részleges oldalduplikátumok akkor fordulnak elő, ha a webhely két vagy több oldala nagyon hasonló, de nem teljesen azonos tartalmat tartalmaz. A részleges duplikációk leggyakoribb típusai a következők:

• Oldalak rendezése
• Oldalak szűrése
• Paginációs oldalak
• Hasonló termékeket tartalmazó oldalak (pl. a termékek csak a színükben különböznek).
• Az oldal több verziója ugyanazon a nyelven, de különböző régiókra vonatkozóan (pl. három angol nyelvű oldal az USA, az Egyesült Királyság és Ausztrália számára).

Természetesen minden webhely egyedi, és a technikai audit során a duplikált tartalom más eseteit is azonosíthatja, amelyek egyedi megoldásokat igényelnek. A fenti példák azonban a leggyakoribbak. A részleges duplikációkat jellemzően a webhelyek különböző lánctalpasok általi feltérképezése során találják meg. Ezek ismétlődő paraméterekkel rendelkeznek, és lehet, hogy ugyanaz a címük és H1-jük, mint a fő kategóriaoldalaknak. A részleges duplikációk kiküszöbölése érdekében nem lehet átirányítást beállítani, mivel ezekre az oldalakra szükség van a webhely funkcionalitásához. Az alábbiakban a részleges duplikátumok kezelésének módszereit tárgyaljuk.

Oldalak rendezése és szűrése

Ezeket az oldalakat a robots.txt fájlban meg lehet akadályozni a lánctalálást, bár ezt a Google figyelmen kívül hagyhatja, különösen, ha a linkek ezekre az oldalakra mutatnak. Ez segít megőrizni a lánctalálási költségvetést. A <meta name=”robots” content=”noindex, nofollow” /> direktíván keresztül is blokkolhatja őket, ami megakadályozza ezen oldalak indexelését, de nem mondja meg a Google-nak, hogy nem szabad lánctalálni őket. A legjobb megközelítés ebben az esetben az, ha JavaScriptet használ az oldal tartalmának frissítésére, amikor a felhasználó rendezést vagy szűrést alkalmaz, anélkül, hogy további URL-eket és linkeket generálna a szűrő vagy rendező oldalakra.

Különböző URL-címeken elérhető termékváltozatok

Ideális esetben az összes termékváltozatot egy oldalon kellene egyesíteni, ahol a felhasználó az URL megváltoztatása nélkül, JavaScript segítségével kiválaszthatja a kívánt színt vagy méretet. Ha azonban minden egyes változathoz külön oldal tartozik, akkor meg kell adni egy kanonikus linket a fő termékoldalra. Azonban, mint korábban említettük, a Google figyelmen kívül hagyhatja a felhasználó által beállított kanonikus linket.

Paginációs oldalak

A lapozgató oldalakat nem szabad kizárni az indexelésből. Annak érdekében, hogy a Google a kategória első oldalát tekintse főoldalnak:

• Csak az első oldalt vegye fel a sitemap.xml fájlba.
• Minden paginációs oldalon adjon linket a kategória főoldalára.
• Adjon oldalszámokat a paginációs oldalak címéhez és H1-éhez. Például: „Fehér ingek – 2. oldal”.

Egy nyelven, de különböző régiókban elérhető oldalak

Ebben az esetben a Hreflang attribútumokat kell használni. Ezeket arra használják, hogy megmondják a keresőmotoroknak, hogy egy weboldal melyik nyelvi és regionális változatát mutassák meg a felhasználóknak a nyelvi preferenciájuk és a tartózkodási helyük alapján. A Hreflang attribútumok többféleképpen is megvalósíthatók:

• A HTTP fejlécekben
• A <head> szakaszban lévő címkéken keresztül
• A sitemap.xml címkéin keresztül

A legegyszerűbb módszer a <head> szakaszban található címkéken keresztül történő megvalósítás. Megvannak azok a szabályok, amelyeknek a <head> szakaszban található címkéken keresztül megvalósított hreflang attribútumoknak meg kell felelniük:

• • Az attribútumnak a következő formátumúnak kell lennie: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
  • A nyelv- és országkódoknak érvényesnek kell lenniük. Az egyes nyelvmutációkhoz tartozó érvényes kódok kiválasztásához lásd ezt az oldalt.

• Minden nyelvváltozatnak fel kell sorolnia magát és az összes többi nyelvváltozatot is a hreflang attribútumaiban. Ez azt jelenti, hogy minden oldalnak ugyanannyi hreflang attribútummal kell rendelkeznie.

• A hreflang attribútumokban szereplő linkeknek abszolútnak és indexelhetőnek kell lenniük.

Egy kódpélda: <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” /> <link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” /> <link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />

A címek, h1, h2 és leírások duplikátumok ellenőrzése

Bár a címek, leírások és H1-H6 címsorok az on-page SEO-hoz kapcsolódnak, elemzésük egy technikai audit keretében hasznos lehet a duplikációk felderítéséhez. Ezek elemzéséhez bármilyen lánctalpas programot használhat, amely összegyűjti ezeket a címkéket. Ha duplikált címeket, H1-H6 címkéket és leírásokat talál, elemezze az oldal adatait és azonosítsa a duplikáció okát. Ennek oka lehet az oldal HTTP-n és HTTPS-en keresztüli elérhetősége, a fő kategóriacímkék duplikációja a szűrőoldalakon, vagy egyszerűen emberi hiba, amikor ezeket a címkéket helytelenül töltötték ki.

Optimalizálja a képek alt attribútumait

Az alt attribútumok a <img> címkén belül használt HTML-attribútumok, például így: <img src=”image.jpg” alt=” A kép leírása”>. Fő célja, hogy szöveges leírást adjon a kép tartalmáról. Ez a szöveg akkor jelenik meg, ha a kép nem töltődik be, és a képernyőolvasók felolvassák, hogy segítsék a látássérült felhasználókat. A megfelelő, leíró alt szöveg segíthet a képek rangsorolásában a képkeresőben, és javíthatja az oldal általános relevanciáját. Ha sok vizuális tartalommal rendelkező webhelye van, akkor az alt attribútumok optimalizálása fontosabb lépés, mint a klasszikus, szöveges tartalomra támaszkodó webhelyek esetében. Számos lánctalpas program, például a Screaming Frog, az Ahrefs, a SemRush stb. elemzi az alt attribútumokat, és ott kaphat adatokat a hiányzó vagy üres alt attribútumokról. A leíró alt attribútumok létrehozásáról bővebben a Google hivatalos dokumentumaiban olvashat.

A webhely sebessége, mobil és felhasználóbarát jellege

HTTPs protokoll használata

A biztonságos HTTPS protokoll használata elengedhetetlen a felhasználó és a kiszolgáló közötti adatátvitel biztonságának biztosításához. Ez nemcsak a felhasználók bizalmát növeli, hanem a SEO-ra is pozitív hatással van. A HTTPS ellenőrzéséhez egyszerűen nézze meg a böngésző címsorát – egy lakat ikonnak kell megjelennie. Részletes elemzéshez használhatja az SSL Labs szolgáltatást, amely teljes körű jelentést készít az SSL-tanúsítvány állapotáról, és azonosítja az esetleges problémákat. Fontos továbbá, hogy ne legyen vegyes tartalom – HTTP erőforrások a HTTPS oldalakon. Ehhez az elemzéshez használhatja a Google Search Console HTTPS-jelentését, amely megmutatja a HTTP és HTTPS tartalmú URL-címeket.

Source: Search Console ügyfeleinknél

A Core Web Vitals javítása

A Core Web Vitals egy, a Google által javasolt mérőszámok összessége, amely a felhasználói élmény minőségének értékelésére szolgál egy weboldalon. Ezek a mérőszámok a betöltési sebességre, az interaktivitásra és az oldalon lévő tartalom vizuális stabilitására összpontosítanak. Három kulcsfontosságú mutatót tartalmaznak:

Mérőszámok:	Leírás	Optimális érték
Legnagyobb tartalmi festék (LCP)	Az oldal legnagyobb látható elemének (pl. kép vagy szöveg) betöltési idejét méri.	Kevesebb mint 2,5 másodperc
Első bemeneti késleltetés (FID)	Azt az időt méri, amely alatt az oldal reagál az első felhasználói interakcióra (pl. egy gombra vagy linkre kattintás).	Kevesebb mint 100 milliszekundum
Halmozott elrendezési eltolódás (CLS)	Az oldal vizuális stabilitását értékeli, azaz azt, hogy az elemek mennyit mozdulnak el az oldal betöltése során.	Kevesebb, mint 0,1

A valós felhasználóktól gyűjtött adatok megtekinthetők a Search Console „Core web vitals” jelentésében (összesített adatok) vagy a PageSpeed Insights-ban (egyedi tesztek esetében). A Core Web Vitals munkája során tartsa szem előtt, hogy meg kell határoznia azokat a problémákat, amelyek nagy hatással vannak a CWV-mérőszámokra. Például az LCP optimalizálásakor meg kell határoznia, hogy a 4 szempont (TTFB, Load Delay, Load Time, vagy Render delay) közül melyik járul hozzá leginkább a magas LCP pontszámhoz. Az alábbi példában látható, hogy nem kell a TTFB vagy a Load Time optimalizálására összpontosítanunk. Ehelyett minden energiánkat a Load Delay, majd a Render Delay javítására fordíthatjuk.

Forrás: https://pagespeed.web.dev/ – a nike.com weboldal tesztje (csak a példa kedvéért). A tartomány elmosódott

Biztosítsa, hogy webhelye mobilbarát legyen

A mobilbarátság 2018 óta kulcsfontosságú tényezővé vált, amikor a Google áttért a mobil-első indexelési megközelítésre. Ez azt jelenti, hogy a Google mostantól elsősorban egy weboldal mobilverzióját használja a rangsoroláshoz és indexeléshez, nem pedig az asztali változatot. A Google Search Console-ban az URL-ellenőrző eszközben a „Test Live URL” gombra kattintva tesztelheti oldalait, és megnézheti, hogyan látja azt a Googlebot-Mobile.

Képek tömörítése

A képek tömörítését célzó képoptimalizálás minőségromlás nélkül segít felgyorsítani a weboldal betöltését, különösen, ha sok grafikus tartalom van az oldalakon. A képek tömörítésére olyan online eszközök használhatók, mint a TinyPNG vagy a Squoosh. Azt is érdemes ellenőrizni, hogy a modern képformátumokat, például a WebP-t használják-e, mivel ezek jelentősen csökkenthetik a fájlméretet.

CDN használata nemzetközi weboldalakhoz

A CDN használatának akkor van értelme, ha webhelye földrajzilag távoli régiók széles körét szolgálja ki. A CDN (Content Delivery Network) a webhely tartalmát a felhasználókhoz közelebb található szerverekre osztja szét, csökkentve a betöltés során fellépő késleltetést. A CDN használatát ellenőrizheti a böngésző fejlesztői eszközeiben (Hálózat fül) a HTTP-kérelem fejlécek vizsgálatával, ahol a CDN-szolgáltatóra, például a Cloudflare-re vagy az Akamai-ra való hivatkozások jelenhetnek meg. A CDN tesztelésére online eszközök is léteznek. A CDN konfigurálása jellemzően a tárhelypanelen vagy a CMS-en keresztül történik. Tárolás használata A gyorsítótárazás lehetővé teszi a böngészők és a proxykiszolgálók számára, hogy az erőforrások másolatait tárolják, csökkentve ezzel a szerverterhelést és felgyorsítva a betöltést a későbbi látogatások során. A gyorsítótárazás helyességét a böngésző fejlesztői eszközeiben ellenőrizheti – a Network szakaszban nézze meg a Cache-Control, Expires és ETag fejléceket. A Google PageSpeed Insights szintén ajánlásokat ad a gyorsítótárazásra vonatkozóan. Fontos, hogy a statikus erőforrások (képek, szkriptek, stílusok) megfelelő gyorsítótárazási beállításokkal rendelkezzenek, és a kiszolgálónak rendelkeznie kell a megfelelő szabályokkal (pl. a .htaccess vagy az nginx konfigurációban). A gyorsítótárazás ellenőrzéséhez olyan online szolgáltatásokat használhat, mint a GiftOfSpeed.

Következtetés

Egy weboldal technikai ellenőrzése nem egyszeri eljárás, hanem folyamatos folyamat, amely rendszeres figyelmet igényel a weboldal teljesítményét és láthatóságát befolyásoló technikai tényezőkre. Mivel minden weboldal egyedi, az ellenőrzések konkrét fókusza és gyakorisága eltérő lesz. Ez a technikai SEO-ellenőrzésre vonatkozó ellenőrző lista segít abban, hogy ne felejtsen el semmi fontosat.