SEO lépésről lépésre

SEO lépésről lépésre

Helyes válasz minden SEO-kérdésre

Tele van az internet a keresőoptimalizálásról szóló információval... cikkek, blogok, videók, hírlevelek, e-bookok, fórumok, és közösségi csoportok ontják magukból a tudást. Ennek ellenére mégis nap, mint nap tapasztaljuk, hogy még a legegyszerűbb, legalapvetőbb tudnivalókkal kapcsolatban is rengeteg a félreértés. Az alábbi listában igyekszünk a laikusok számára is érthetően megfogalmazott, valóban helyes és hiteles válaszokat adni minden olyan kérdésre, amely tapasztalatunk szerint felmerülhet a keresőoptimalizálás kapcsán.

Általános SEO kérdések

Minden weboldalnak fontos a keresőoptimalizálás?

Az üzleti célú weboldalak esetében mindig fontos a keresőoptimalizálás, ha az elérni kívánt felhasználók aktívan keresnek a kínált termékekre, szolgáltatásokra, vagy magára a vállalkozásra. Tapasztalatunk szerint egy jól optimalizált weboldalak túlnyomó többségénél stabilan az organikus csatorna hozza a legtöbb látogatót és vásárlót. A Shoprenter évente végzett kutatása, a Nagy Webáruház Felmérés is évről évre megerősíti, hogy a SEO a legeredményesebb marketingcsatorna.

Milyen weboldalakat nem érdemes keresőoptimalizálni?

Személyes, vagy hobbicélú weblapokat csak akkor érdemes optimalizálni, ha egyrészt cél az új látogatók szerzése a keresőből, másrészt ha ez nem igényel túlzott mértékű anyagi, vagy egyéb ráfordítást, hiszen ilyen weblapoknál megtérülés nem várható. Passzív (hirdetés, affiliate, stb.) jövedelemszerző célú weblapoknál ugyan fontos a keresőből történő forgalomszerzés, azt azonban ilyen esetben nagyon fontos előre reálisan felmérni, hogy valóban megtérülhet-e a keresőoptimalizálásra fordított idő és pénz. A nagyon speciális réspiacokat célzó üzleti weboldalakat addig nem igazán érdemes keresőoptimalizálni, amíg a felhasználói célcsoport nem ismeri a kínált terméket/szolgáltatást, így nem is érdeklődik iránta a keresőben. Ilyen esetben többnyire más marketingcsatornákat érdemes igénybe venni a termékek ismertségének növeléséhez, vagy a szolgáltatások népszerűsítéséhez. Azonban amint megnő a releváns keresések száma, érdemes a keresőoptimalizálással is foglalkozni, lehetőleg még mielőtt a piacra belépő új versenytársak teszik ezt meg!

Hogyan ellenőrizhetem, hogy jól teljesít-e a weblapom a keresőben?

A leghasznosabb az organikus forgalom, valamint a fontos kulcsszavak/keresési kifejezések keresőpozícióinak vizsgálata. Az organikus látogatottság legegyszerűbben valamilyen népszerű webanalitikai eszköz, például a Google Analytics használatával végezhető el. Fontos tudni, hogy az általuk jelzett adatok kizárólag a weboldalak megtekintésekor sikeresen lefutott követőkód által beküldött információkat tartalmazzák, ezért konfigurációs hiba, vagy egyéb technikai probléma esetén a valósnál alacsonyabb mennyiségű, vagy egyéb módon fals adatokat fognak jelezni. A keresőforgalom mennyiségi elemzése a webszerver látogatottsági logfájlokon keresztül is elvégezhető, ám ez rendszerint meghaladja az átlagfelhasználó szakmai felkészültségét. Az organikus forgalom elemzésének másik legnépszerűbb eszköze a Google Search Console, mely a weblap keresőben való megjelenéséről megjelenési, kattintási, és elhelyezkedési (pozíció) információkkal szolgál. Az eltérő adatokon túl a legfőbb különbség az Analyticshez képest, hogy a Search Console kizárólag a találati listákról gyűjtött adatokat jeleníti meg, a webhelyről nem gyűjt ilyen adatot. Ha tehát egy felhasználó a találati listán a webhelyükre kattint, az a Search Console statisztikáiban kattintásként jelenik meg, akkor is, ha bármilyen okból nem töltődött be neki a weboldalunk, és nem vált ténylegesen látogatóvá. Azt is fontos tudni, hogy a Search Console teljesítményjelentése mintavételezett adatokra épül (bizonyos esetekben a Google Analytics is alkalmaz mintavételezést), tehát a két eszköz által kijelzett adatok az eltérő adatgyűjtés, és feldolgozás miatt soha nem fognak pontosan egyezni egymással.

Hogyan ellenőrizhetem a kulcsszavaim keresőpozícióit?

Bár a legegyszerűbben tűnhet egyszerűen rákeresni a keresőben, ez gyakran nagyon félrevezető eredményt fog adni, mert a Google a rangsorolásnál figyelembe veheti a felhasználó keresési előzményeit, valamint egyéb fontos jellemzőit. Tehát hiába látjuk mi a saját böngészőnkben egy adott pozícióban a weboldalunkat, ez nem garantálja, hogy valódi célközönségünk is ugyanezt tapasztalja. A legnépszerűbb ingyenes pozícióellenőrző eszköz a Google Search Console teljesítményjelentése. Bár alkalmas rá, hogy konkrétan egy kulcsszó-URL páros keresőpozícióját vizsgáljuk egy adott időszakra, a megjelenített érték egy mintavételezett adathalmazon történő átlagolás eredménye lesz. Trendek vizsgálatára természetesen remek eszköz, de egy konkrét pillanatnyi pozíció kimutatására nem alkalmas, nem is ez a célja. Léteznek kifejezetten kulcsszópozíció-ellenőrző szoftverek is, pl. a Website Auditor csomagban található Rank Tracker. A jobb minőségű eredményt biztosító eszközök jellemzően fizetősek, és saját tapasztalatunk szerint a hazai piacon esetenként tökéletlen eredményt biztosítanak, pl. a találati listák külföldről történő lekérdezése, vagy tényleges napi pozíciók lekérdezése helyett a napi eredmények alkalmankénti lekérdezések alapján történő "beblöffölése"". Figyelmet igényel az adatok helyes értelmezése, mert előfordulhat, hogy pl. a fő kulcsszavunk mellett virító "1. pozíció" adat valójában csak képtalálatként történő megjelenésre vonatkozik, miközben a tényleges organikus találatok között csak a harmadik oldalon jelenik meg a weboldal. Mi munkánkhoz saját fejlesztésű pozíciólekérdező rendszerünket használjuk, melynek működését folyamatosan az aktuális találati listaszerkezethez adaptáljuk. A hazai piacra nem találtunk még ennél hitelesebb rank tracker szoftvert. Sikerdíjas SEO-ügyfeleink számára díjmentesen hozzáférést biztosítunk az optimalizált kulcsszavak valódi napi pozícióit megjelenítő felületünkhöz.

Fontos, hogy 1. helyen jelenjek meg a keresőben?

Általánosságban elmondható, hogy minél jobb pozícióban jelenik meg egy weboldal a keresőben, annál magasabb az átkattintási aránya, azaz adott számú keresésből annál több látogatót tud megszerezni. A pozíción túl azonban a tényleges keresési szándék, a márkaismertség, valamint egyéb tényezők is befolyásolják, hogy a felhasználó mely találat(ok)ra fog kattintani a listán.

Például ha egy termékre irányuló keresés esetén a találati lista felépítése a következő:

  1. Wikipédia cikk a termékről
  2. Árösszehasonlító oldal
  3. Nagy nemzetközi marketplace oldal
  4. Blogcikk a termék használatáról
  5. Hazai KKV webáruház termékoldala

...akkor például a vásárlási céllal kereső felhasználók nem fognak sem a Wikipédiára, sem a blogcikkre kattintani.
A vásárlási céllal keresők között is lesznek olyanok, akik a marketplace oldallal szemben negatív tapasztalatokkal, vagy előítéletekkel rendelkeznek, és jó esetben olyanok is, akik már ismerik/kedvelik a hazai webáruházat.
Ilyen esetekben a hazai KKV webáruház potenciális vásárlói számára az 5. pozíció egyenértékű az 1. pozícióval, hiszen számukra valójában ez az első értékes találat a listán.

Meg lehet előzni a nagy weboldalakat?

A nemzetközileg ismert brandek, vagy az adott témában vezető régi, a találati listák élére "bebetonozott" weboldalak valóban nem könnyű ellenfelek. Különösen, ha az Ön weblapjánál sokszorosan több termék és tartalom található rajtuk! Ezek olyan, website szintű pozitív rangsorolási szignálokkal rendelkeznek, amelyekkel, egy tipikus hazai kisvállalkozás jó esetben átlagos látogatottságú weblapja nem versenyezhet. A fő kérdés az, hogy milyen keresésekre lehet és érdemes "megelőzni" őket? A saját márkanevükre biztosan nem, de ennek nem is lenne értelme. A legáltalánosabb kulcsszavakra és gyűjtőkifejezésekre is nehéz velük versenyre kelni, ha mondjuk az adott termékkategóriában ötvenszer annyi, jó minőségű terméket kínál a nagy vetélytárs, mint az Ön weboldala. Viszont az Ön termékeire, speciálisabb termékkategóriáira, és egyéb, vásárlói számára fontos kifejezésekre már egyértelműen jó esély van akár a legerősebb konkurensek előtt is megjelenni! helyesen megválasztott célokkal és kulcsszavakkal tehát nem kell félni a "nagyoktól", minden weboldal képes érezhető hasznot termelni organikus keresőforgalomból.

Milyen kulcsszavakra optimalizáljam a weboldalam?

Ezt minden esetben egy alapos kulcsszókutatás, és az elérni kívánt célok alapján kell meghatározni. Általánosságban a weboldala által kínált termékekhez/szolgáltatásokhoz kapcsolódó keresőkifejezések listájából érdemes kiindulni, majd ezeket leszűkíteni azokra, amelyek valóban az Ön számára értékes látogatókat, potenciális ügyfeleket fognak szállítani. Ezt követően a várható keresési mennyiségeket és a sikeres optimalizálás realitását kell megvizsgálni. Hiába tűzi ki célul ugyanis a legnagyobb forgalmú kulcsszavakra való optimalizálást célként, ha az erős verseny, és weblapjának aktuális állapota miatt az eredmények eléréséhez rengeteg erőforrásra, és akár évekre lesz szükség! Az ideális induló kulcsszóportfolióba mindenképp érdemes olyan kifejezéseket is választani, amelyek belátható időn belül eredményt és megtérülést hoznak. Ha hosszabb távon nehezebb kulcsszavakra is szeretnénk az élmezőnybe kerülni, akkor javasolt ezek témájához kapcsolódó, kevésbé nehéz kulcsszavakra is optimalizálni és tartalmat gyártani, mert idővel az ezek révén elért tematikus relevancia lehet a nehéz, általános kulcsszó sikerének egyik titka.

Google indexelés

Hogyan térképezi fel a Google a weboldalakat?

Keresőrobotnak, vagy röviden botnak nevezett program segítségével rendszeresen beolvassák a rendszerük által már ismert weboldalak tartalmát, és az ezeken a weboldalakon felfedezett újabb weboldalak címét is hozzáadják a feltérképezendő weboldalak listájához. Ez leegyszerűsítve azt jelenti tehát, hogy ha egy új aloldal linkje megjelenik a Google által már ismert bármely weboldalon, akkor az új weboldalt is fel fogja fedezni a Google, minden egyéb speciális teendő nélkül.

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

A feltérképezés során a Googlebot beolvassa a feltérképezendő weboldal tartalmát. Az indexelés azt jelenti, hogy a feltérképezést és feldolgozást követően le is tárolja a weblap tartalmát, és a keresőben való megjelenítéshez szükséges adatokat. Az úgynevezett Google-index a valóságban a világ számos pontján, szerverközpontokban üzemelő számítógépek elképesztő sokasága, melyek weblapok milliárdjainak tartalmát tárolják, hogy egy adott pillanatban megfelelő találati listát szolgáltathassanak egy Google-keresésre. Ha egy URL-t a Google soha nem térképez(het) fel, akkor annak tartalma soha nem kerül(het) az indexbe. A felfedezhetőségen túl azonban több szempontnak is meg kell felelnie a weboldalnak ahhoz, hogy a Google ténylegesen be is indexelje. És önmagában az indexelés még nem garantálja, hogy a weboldal valaha is jó pozícióban jelenjen meg bármely keresésre.

Mi az oka, ha a Google nem indexeli a weboldalamat?

Elsősorban azt kell megvizsgálni, hogy egyáltalán felfedezte-e már a Google az indexeltetni kívánt URL-t. Ennek vizsgálata a Search Console URL-ellenőrzés eszközével a legegyszerűbb. Ha technikai beállítás (pl. noindex utasítás) akadályozza az indexelést, az itt rögtön ki is derül. Amennyiben látszólag minden rendben van az URL-lel, a Google fel is fedezte, ám nem indexeli, annak az esetek többségében minőségi, elsősorban tartalmi oka lehet. Ilyen esetben érdemes felülvizsgálni a weboldal tartalmát, hogy valóban szerepel rajta a felhasználók számára értékes, egyedi információ. John Mueller, a Google egyik SEO-szóvivője egyértelműen kijelentette, hogy szándékosan nem indexelnek olyan weboldalakat, amelyek tartalma nem hordoz érdemi plusz információt a már indexelt weboldalakhoz képest. Egy másik beszédében úgy fogalmazott, hogy ha nem egyértelmű, az új weboldalt miért lenne érdemesebb megjeleníteniük egy adott keresésre a már meglévő weboldalaknál, akkor nincs értelme indexelniük.

Hogyan gyorsíthatom fel egy weboldal indexelését?

A sikeres indexelés alapfeltétele a felfedezés, tehát elsősorban azt kell biztosítani, hogy legalább egy, a Google által már indexelt és rendszeresen feltérképezett weboldalon szerepeljen az új oldalra mutató hivatkozás (HTML link). A feltérképezés és indexelés meggyorsítható, ha a Search Console URL-ellenőrzés eszközében rákattint az "Indexelési kérelem" hivatkozásra. Fontos tudni, hogy egy már feltérképezett, de indexelésre alkalmatlannak tartott oldal esetén az indexelési kérelem küldése nem jár semmilyen előnnyel, felesleges újra és újra visszatérni, és beküldözgetni, amíg nem végezzük el azokat a módosításokat, amelyek révén az oldal eleget fog tenni az indexelés feltételeinek. Ha a tartalmat indexelésre alkalmasnak tartjuk, linkekkel jelezhetjük a Google számára az oldal fontosságát, ezzel elősegíthetjük az indexelést - érdemes tehát a jól teljesítő aloldalaink tartalmában, vagy akár a kezdőoldalon az új oldalra mutató hivatkozásokat elhelyezni. A sitemapben való szerepeltetés is elősegítheti az indexelést, bár nem feltétele annak, és nem is teszi kötelező érvényűvé az indexelést - mindössze egy viszonylag gyenge szignált ad a Google számára, hogy számunkra fontos az adott aloldal. Érdemes megemlíteni a Google Indexing API szolgáltatását is. Ez az eszköz alapvetően a gyorsan változó, korlátozott időtartamra megjelenítendő tartalmak gyors indexeltetésére, majd az indexből való gyors eltávolítására lett létrehozva. Hivatalosan jelenleg csak állásajánlatok, és élő videoközvetítések indexeltetésére használható. Az eszköz megjelenésével tömeges visszaélések kezdődtek, jónéhány nyílt forráskódú CMS-rendszerbe bekerült a funkció, valamint SEO-szolgáltatást kínáló weboldalak is elérhetővé tették a szolgáltatást, tartalomtípustól függetlenül. A gyakorlatban egyébként jó ideig működött is az azonnali indexeltetés, szinte tetszőleges tartalomra, azonban nem árt tudni, hogy ez a módszer sérti az eszköz felhasználási feltételeit.

Mit tegyek, ha egy weboldalamat szeretném eltávolíttatni a találati listáról?

A meta robots HTML-tagben, vagy az X-Robots_tag HTTP-válaszfejlécben állítson be "noindex" attribútumot. Az URL következő feltérképezésekor a Google az utasításnak megfelelően eltávolítja az oldalt a Google-indexből, és az nem jelenik meg a további keresésekre. Ha a lehető leggyorsabban szeretné eltávolíttatni az URL-t, a folyamat meggyorsítható a Search Console-on keresztül beküldött átmeneti eltávolítási kérelemmel (Indexelés -> Eltávolítások menüpont). Fontos, hogy ez a kérelem csak kb. 6 hónapra távolítja el az oldalt a találati listáról, ha tehát végleg, vagy ennél hosszabb időtartamra szükséges az eltávolítás, akkor mindenképp szükséges a noindex attribútum beállítása is, az eltávolítási kérelemtől függetlenül. Gyakori hiba a robots.txt Disallow direktívájának használata erre a célra, ez azonban nem az indexelést, hanem a feltérképezést tiltja. Ha tehát már be lett indexelve a nem kívánt URL, majd a robots.txt-ből letiltja a feltérképezést, akkor még az esetleg szintén beállított noindex attribútumot sem fogja észlelni a Google, és továbbra is indexelve marad az oldal, tehát nem kerül eltávolításra a találati listáról!

Mire való a noindex attribútum?

A meta robots HTML-tagben, vagy az X-Robots_tag HTTP-válaszfejlécben beállított "noindex" attribútum megtiltja az adott URL-en található tartalom indexelését, és a találati listán történő megjelenítését.

Mire való a nofollow attribútum?

A meta robots HTML-tagben, vagy az X-Robots_tag HTTP-válaszfejlécben beállított "nofollow" attributum megtiltja a weboldal tartalmában található hivatkozások (linkek) "követését". Ez azt jelenti, hogy az oldalon található linkek nem adnak át "linkerőt" a hivatkozott oldalaknak, illetve az itt szereplő, a Google számára korábban ismeretlen URL-ek nem kerülnek hozzáadásra a felfedezési listához - tehát ha máshonnan nem kapnak linket, és a Google egyéb módon sem szerez róluk tudomást, akkor sem feltérképezve, sem indexelve nem lesznek. Gyakran találkozni azzal a téves nézettel, hogy ha egy oldalra be van állítva a noindex attribútum, akkor szükségtelen a nofollow használata, hiszen a tartalmat emiatt nem olvashatja be a Googlebot, a linkeket nem találhatja meg bennük. Ez azonban nem igaz. A nofollow attributum nem blokkolja a tartalom beolvasását, csak a tárolását és kiszolgálását. Tehát a Google noindex attribútum esetén is beolvassa az oldal tartalmát, és feldolgozza a benne talált linkeket, ha a nofollow attribútum nem kerül beállításra.

Mi a sitemap?

A sitemap magyarul oldaltérképet jelent. Háromféle megvalósítása létezik: - HTML oldaltérkép: önálló aloldal a websiteon, amely böngészőben megtekinthető. Ez elsősorban a valós felhasználók számára lehet hasznos, ha megkönnyíti a website komplex struktúrájának áttekintését. A Google technikai értelemben nem tekinti sitemapnek, ám a többi weboldallal megegyező módon felfedezi és követi az itt megjelenített hivatkozásokat. Ez a gyakorlatban többnyire nem jár rangsorolási előnnyel, de a máshonnan nem hivatkozott URL-ek felfedezését lehetővé teszi. - XML sitemap: strukturált adatformátumban tartalmazza a websitehoz tartozó URL-ek listáját. Az URL-eken túl extra információval is szolgálhat a Google számára a helyes indexelés elősegítésére. Ez a formátum a legelterjedtebb és leghasznosabb az oldaltérképek között. - RSS/Atom sitemap: szintén strukturált formátumban tartalmazza az URL-ek listáját, ám az XML-sitemapeknél kevesebb információval, korlátozottabb funkcionalitással használható. - plaintext sitemap: egyszerű szöveges fájl, amely kizárólag az URL-ek listáját tartalmazza, járulékos információk nélkül. Mikor ajánlott az XML/RSS sitemap létrehozása? A Google elsősorban nagyobb webhelyeknél (500+ indexeltetni kívánt aloldal), vagy olyan URL-ek esetén ajánlja, amelyek más weboldalakon elhelyezett hivatkozásokon keresztül nem fedezhetőek fel.

Hová kell feltölteni a sitemapet?

A legelterjedtebb hely a webhely gyökerében a /sitemap.xml elérési út, de ettől eltérő, tetszőleges útvonal és fájlnév is alkalmazható. Különösen utóbbi esetben érdemes a robots.txt fájlban, vagy a Search Console Webhelytérképek eszközén keresztül a Googlebot tudomására hozni az oldaltérkép elérhetőségét. A Search Console-on történő beküldés hiányában a sitemap csak a szülőkönyvtárban elhelyezett oldalakra van hatással, már csak ezért is érdemes tehát a webhely gyökerében elhelyezni, hiszen így automatikusan a teljes webhely összes aloldalára érvényes lesz.

Mire kell ügyelni a sitemap esetén?

A legfontosabb, hogy ha használunk sitemapet, az folyamatosan frissítve tartalmazza a webhely összes, indexeltetni kívánt URL-ét, és ne tartalmazzon olyan URL-eket, amelyek indexelése szükségtelen, vagy káros lehet. Karakterkódolásként minden esetben UTF-8 kódolást kell használni, még akkor is, ha a weblap oldalai egyébként más kódolással jelennek meg a böngészőkben. Ha az URL-ek száma meghaladja az 50.000-et, vagy a sitemap fájl tömörítetlen mérete az 50MB-ot, akkor több, kisebb, különálló sitemapben kell szerepeltetni az URL-eket, és ezeket egy közös, sitemap index fájlban listázni.

Milyen extra információkat vesz figyelembe a Google az XML-sitemapből?

A legfontosabb, hogy a sitemapben szerepeltetett URL-eket a webhely tulajdonosa által preferált kanonikus URL-nek tekinti. Ez különösen akkor segíti elő a találati listán a megfelelő URL-ek megjelenítését, ha egyes tartalmak több, hasonló URL alatt is elérhetőek (pl. eltérően rendezett termékkategória oldalak). A Google figyelembe veszi továbbá a tartalom frissességére vonatkozó attributumot, amennyiben ez folyamatosan és következetesen pontos, valós időpontokat tartalmaz. A kép-, és video sitemapek a médiatartalmakra vonatkozó további hasznos információkat is tartalmazhatnak, ezek használata elsősorban olyan webhelyeken javasolt, amelyeken ezek a médiaelemek a tartalom kifejezetten fontos részét képezik.

Milyen információkat nem vesz figyelembe a Google az XML-sitemapből?

A Google a feldolgozás során figyelmen kívül hagyja a hivatalos sitemap protokoll szerint egyes URL-ek fontosságára utaló , valamint a tartalomfrissítés gyakoriságára utaló attributumokat, mivel ezek a múltban gyakran téves, vagy manipulatív célú adatokat tartalmaztak a webhelyek többségénél.

Milyen esetben érdemes több sitemapet beküldeni a Search Consoleba?

Különösen nagyméretű webhelyek esetén természetes jelenség, hogy az URL-ek egy része csak igen ritkán, vagy egyáltalán nem kerül feldolgozásra, még akkor sem, ha ezek egyébként szerepelnek az oldaltérképben. Ilyen esetben érdemes lehet kisebb, az URL-ek valamilyen szempont alapján elkülönített csoportját külön sitemapben szerepeltetni, és ezt a fő sitemap mellett külön beküldeni a Search Console oldaltérkép eszközében. Ezáltal elkülönítetten elemzhetővé válnak a Search Console Webhelytérképek eszközében az adott URL-csoportra vonatkozó indexelési adatok.

Mire való a robots.txt fájl?

Ezen a szöveges fájlon keresztül szabályozható, hogy a weboldal mely tartalmaihoz férhetnek hozzá a különböző feltérképező robotok, és melyek tiltottak számukra. A Googlebot naponta legalább 1 alkalommal beolvassa a robots.txt fájl tartalmát, és a szabályokat alkalmazza a további feltérképezés során. Fontos tudni, hogy a robots.txt szabályok betartása nem kötelező érvényű, ezért a kéretlen/rosszindulatú botok jellemzően nem veszik figyelembe, az ellenük történő védekezésre nem alkalmas!

Hová kell feltölteni a robots.txt fájlt?

A robots.txt fájlt minden esetben a webhely gyökerében kell létrehozni: /robots.txt Más könyvtárba, vagy más néven feltöltve semelyik bot nem veszi figyelembe. Ha egy domainhez aldomainek is tartoznak, úgy minden egyes aldomainhez külön robots.txt fájl hozható létre az egyes aldomainek gyökérkönyvtáraiban, tetszőlegesen eltérő szabályrendszerrel.

Hiba a nem létező robots.txt fájl?

Ha a webhely semelyik részén nem kívánjuk korlátozni a botok általi feltérképezést, nem szükséges robots.txt fájlt feltölteni. A robots.txt fájl hiánya nem okoz semmilyen indexelési, vagy rangsorolási problémát, amennyiben szabályos 404 HTTP-választ ad a szerver az URL-kérelemre.

Milyen szabályok adhatóak meg a robots.txt fájlban?

Konkrét URL-ekre, könyvtárakra, vagy speciális szabályok megadásával URL-csoportokra engedélyezhetjük, vagy tilthatjuk a feltérképezést. Speciális szabályként a * wildcard használata szabványos, ezzel tetszőleges karaktersorozatot helyettesíthetünk. Pl. a /valami-* szabály minden /valami karaktersorozatot tartalmazó URL-re érvényes. A robots.txt specifikáció hivatalosan nem támogatja a reguláris kifejezések használatát, ám a Googlebot a végződést jelentő $ wildcardot is figyelembe veszi. Pl. a *-valami$ szabály csak a -valami végződésű URL-ekre érvényesül, míg a *-valami szabály minden olyan URL-re, amely bárhol tartalmazza a -valami karaktersorozatot. Az Allow: direktívában megadott szabályokkal engedélyezhetjük a feltérképezést, a Disallow: direktívában megadott szabályokkal pedig tilthatjuk. Az egyes szabálycsoportok előtt megadott User-Agent: direktívával szabálycsoportonként szabályozhatjuk, hogy azok mely robotokra vonatkoznak. Végül a Sitemap: direktívában megadhatjuk az oldaltérkép teljes elérési útvonalát. Ez különösen akkor fontos, ha az oldaltérkép nem a standard /sitemap.xml útvonalon érhető el, és nem is küldtük be azt a Search Console eszközbe feldolgozásra.

Fontos: a robots.txt feldolgozásakor több, azonos URL-re vonatkozó szabály esetén mindig a legpontosabban egyező szabály érvényesül, függetlenül a fájlban szereplő utasítások sorrendjétől!
Tehát pl. ha

Allow: /tilos/szabad.html 
Disallow: /tilos/

szerepel a robots.txt fájlunkban, akkor a /tilos/szabad.html URL feltérképezése engedélyezett, hiába tiltottuk egyébként a teljes /tilos/ könyvtár tartalmának feltérképezését, és az sem akadályozza ezt meg, hogy a tiltó szabály az engedélyező után került megadásra!

Milyen hibákat okozhat a helytelen robots.txt fájl?

Nem hiba ugyan, de a leggyakoribb probléma, ha a nemkívánatos URL-ek feltérképezése nincs letiltva. Ez duplikált tartalmak, vagy gyenge minőségű oldalak indexelése révén hátrányos optimalizálási szempontból. Ennek az ellentéte, amikor a kellő szakértelem hiányával párosuló túlbuzgóságból, vagy figyelmetlenül felírt szabályokkal fontos tartalmak feltérképezése kerül tiltásra. Az is tipikus probléma, amikor a weblap megjelenéséhez szükséges css, js fájlokat tartalmazó könyvtárakat tilt a robots.txt fájl. Mivel a Google a feldolgozás során lerendereli az oldal tényleges megjelenését, az ezekhez szükséges fájlokhoz való hozzáférés hiánya miatt hibás, szétesett oldalképet generál, majd ez alapján rossz mobilos használhatóságot és oldalélményt társít a weboldalhoz, amely jelentős hátrányt jelent a rangsorolásban. A tartalomban megjelenített képek és egyéb médiaelemek tiltása szintén rontja az oldal rangsorolását, hiszen elvész az ezek feltérképezéséből származó előny - és a képek így természetesen a Google Képkeresőben sem fognak megjelenni, ami témakörtől függően jelentős látogatottságvesztést okozhat. A legsúlyosabb hiba, amivel már többször találkoztunk pályafutásunk során, ha hibás szerverkonfiguráció, vagy programhiba miatt a szerver 5xx válaszkódot ad a robots.txt megnyitásakor. Ez ahhoz vezet, hogy a Google leállítja a teljes website feltérképezését, és idővel a már korábban esetleg indexelt tartalmak rangsorolására is negatívan hat!

Tehát pontosan mi a különbség a robots.txt és a noindex tiltás között?

A meta robots tagben, vagy a X-Robots-Tag HTTP-fejlécben beállított noindex attribútum a weboldal indexelését tiltja meg. Már indexelt oldal esetén a noindex beállítása eltávolítja az oldalt a Google-indexből. A noindex nem tiltja az oldal feltérképezését, sőt, a felfedezése és betartása csak abban az esetben történhet meg, ha a engedélyezve van a feltérképezés. A robots.txt-ben beállított tiltás a feltérképezést tiltja meg. A korábban már indexelt tartalmak a feltérképezés tiltása után is az indexben maradnak, a legutolsó feltérképezés során beolvasott tartalommal. A tiltás után frissített tartalom már nem fog indexelésre kerülni, és az ekkor beállított noindex attribútum sem kerül felfedezésre, így alkalmazásra sem.

Google rangsorolás

Mi a Google-algoritmus?

Az a rendkívül komplex program, amely meghatározza, hogy egy adott keresésre mely weblapok, és milyen sorrendben jelenjenek meg a találati listán. Pontos működése nem nyilvános. A SEO-szakértők egyrészt a Google hivatalos útmutatóin és egyéb kapcsolódó információin, valamint a Google által bejegyzett szabadalmak megismerésén, másrészt saját, vagy mások által megosztott tapasztalatok révén igyekeznek minél jobban megérteni a működését.

Hogyan rangsorolja a Google a weboldalakat a találati listán?

A keresőmotor által indexelt tartalmakról, valamint a keresést végző felhasználóról tárolt információk alapján több száz - egyesek szerint ma már több ezer - rangsorolási szignál figyelembevételével határozza meg a megjelenített weblapok találati sorrendjét. A keresőalgoritmus normál működése, hogy nincs "fix", állandó találati sorrend, hanem ez számos tényezőtől függően akár keresésről keresésre változhat, még ha egy emberi felhasználó számára ez nem is tűnik fel.

Mik a rangsorolás legfontosabb szempontjai 2024-ben?

Bár az eredeti algoritmus legfőbb eleme az akkor forradalmi újdonságnak számító, linkek alapján rangsoroló PageRank rendszer volt, ez a könnyű manipulálhatóság miatt folyamatosan változott, ma már jórészt háttérbe szorult. Gary Illyes, a Google Search csapat analitikusa és szóvivője 2024-ben nyilvánosan bejelentette, hogy a linkek ugyan továbbra is fontosak, de már nem tartoznak a top 3 rangsorolási tényező közé. Bár a top 3 tényezőt nem nevezte meg, ezeket a Google jelenlegi információi alapján nagy valószínűséggel a hasznos/hiteles tartalom, az oldalélmény, és a felhasználói viselkedés jelentik.

Mik az algoritmusfrissítés fajtái?

A Google célja a lehető legjobb minőségű találatok kiszolgálása, emiatt folyamatosan ellenőrzik a találataik minőségét, és kisebb-nagyobb mértékben finomítják az azokat kiszolgáló algoritmust. - kisebb, akár tesztjellegű, akár végleges módosításokat naponta több alkalommal is végeznek az algoritmus egyes alrendszerein. Ezek hatása többnyire nem feltűnő sem az átlagfelhasználók, sem a szakértők számára. - időszakos frissítéseket évente több alkalommal, előre nem tudható időpontokban végeznek. Ezek célja gyakran az épp népszerű manipulatív SEO-technikák elleni védekezés (ilyenek voltak korábban a hírhedt Panda és Pingvin algoritmusfrissítések, de ebbe a csoportba sorolható a 2022-2024 között 3 alkalommal lefutott időszakos HCU (Helpful Content Update) algoritmusfrissítés is, mely 2024 márciusában vált az alapalgoritmus részévé. Az ilyen algoritmusfrissítések sajátossága, hogy futtatásuk során az általuk nemkívánatosnak talált aloldalakat, vagy webhelyeket "megcímkézik". A megcímkézett oldalak minden egyéb tényezőtől függetlenül, jelentősen hátrébb rangsorolódnak, vagy akár teljes egészében eltávolításra is kerülhetnek a találati listákról. Ezek a frissítések többnyire jól láthatóan átrendezik a találati listákat, hatásuk ráadásul az adott algoritmus következő időszakos frissítéséig (vagy alapalgoritmusba integrálásáig) fennmarad, ezalatt semmit nem lehet tenni ellene. Az időszakos frissítések másik csoportja nem ennyire drasztikus, ezek vagy egy meglévő rangsorolási koncepció újragondolt változatának az alapalgoritmusba integrálása előtti tesztként funkcionálnak, vagy speciális jellegű keresések, pl. egészségügyi, vagy pénzügyi témakörben tapasztalható anomáliákat igyekeznek megoldani. - a legátfogóbb frissítések az úgynevezett Core (alapalgoritmus) frissítések, melyek során a teljes rangsoroló rendszert újraépítik. Ilyenkor kerülnek az alaprendszerbe a korábban időszakos frissítésekben futtatott algoritmusok végleges változatai, valamint finomítják és javítják az egyes alrendszerek hatékonyságát. Bár a core frissítések a legösszetettebbek, néhány kivételtől eltekintve jellemzően nem okoznak jelentős felfordulást a találatok sorrendjében.

Honnan lehet tájékozódni az algoritmusfrissítésekről?

A hivatalos forrás a Google Search Status oldalán érhető el: https://status.search.google.com/products/rGHU1u87FJnkP6W2GwMi/history Ez ugyan elég szűkszavúnak tekinthető, ám egyértelműen hiteles. Természetesen számtalan SEO-portál is vezet listát az algoritmusfrissítésekről, mint például a Search Engine Journal: https://www.searchenginejournal.com/google-algorithm-history/ A szakértői listák igyekeznek informatívabbak lenni, ám extra infóik nagyrésze spekuláció, így érdemes némi fenntartással kezelni őket. A független frissítés-listákon gyakran megjelenik a "meg nem erősített algoritmusfrissítés" fogalma is. Ezek időpontját a különböző rank tracker szoftverek által a találati listák sorrendjében észlelt, az átlagosnál nagyobb mértékű fluktuációhoz kötik, ha ilyen esetekben a Google egyébként nem tesz közzé hivatalos információt.

Mi a teendő, ha egy algoritmusfrissítés után visszaesik az organikus forgalom?

Először is meg kell bizonyosodni róla, hogy valóban visszaesett-e a forgalom, nem csak mérési hibáról van szó (pl. Google Analytics). Erre legcélszerűbb a Search Console teljesítményjelentését használni. Amennyiben valóban történt visszaesés, akkor azt kell vizsgálni, hogy konkrétan mely aloldalakat és kulcsszavakat érintett a változás, és zajlott-e a visszaesés időpontjában algoritmusfrissítés. Ha zajlott, akkor érdemes minél több hitelesnek tekinthető forrásból tájékozódni, milyen változásokkal járt az algoritmusfrissítés, és ezek melyike érinthette negatívan weboldalunkat. Első körben a fejvesztett kapkodás helyett mindig érdemes néhány napot, akár 1-2 hetet várni, mert gyakran előfordul, hogy maguktól helyreállnak az eredmények. Ha azonban komoly a probléma, és vélhetően sikerült is azonosítani az okokat, akkor ennek függvényében kell megtenni a szükséges lépéseket. Alapalgoritmus frissítéskor a Google jellemzően azt a tanácsot adja, hogy nincs különösebb, konkrét teendő a weboldallal - ha mégis változtatni szeretnénk bármin, akkor tegyük azt a felhasználóink számára hasznosabbá, ne az algoritmus technikai elemeire fókuszáljunk. Ez ugyan általánosságban jó tanács, ha azonban van konkrét sejtésünk, hogy az új algoritmusnak pontosan miben nem felel meg a weboldalunk, akkor érdemes arra fókuszálni. Ha jó irányba indultunk, ilyen esetben a megfelelő rangsorolási szignálok frissülése után megtörténik a pozíciójavulás. Időszakos algoritmusfrissítések esetén rosszabb lehet a helyzet, hiszen ilyenkor hiába hárítjuk el a problémát, előfordulhat, hogy a helyezések a címkézésből adódóan a következő releváns algoritmusfrissítésig nem fognak javulni. Speciális eset, amikor egy spam elleni algoritmusfrissítés eredményeként a weblapunkra mutató linkek egy része értékét veszti. Ez esetben nincs mit helyreállítani, az ezekből adódó rangsorolási előny végérvényesen elveszik, hibaelhárítás helyett tehát más, jó minőségű módszerekkel kell az eredmények visszaszerzéséről gondoskodni.

Hogyan hat a mesterséges intelligencia a rangsorolásra?

Az elmúlt években az AI rohamos fejlődése alaposan a feje tetejére állította a keresőoptimalizálást. Egyrészt ma már a Google algoritmus legtöbb eleme is AI-alapú modellekre épül, emiatt a korábbi, viszonylag egyszerűnek tekinthető rangsorolási tényezők egyre inkább kiszorulnak a rengeteg adatpontra épülő, komplex folyamatból. Másrészt az AI által elérhetővé tett automatizált tartalomgyártás alaposan feladta a leckét a Googlenek, hiszen a tömegesen generált, értékes információt nem hordozó tartalmak olyan mennyiségben jelentek meg, amelyek feldolgozása még a Google elképesztő kapacitású erőforrásait is túlterhelte, ráadásul a találati listák minőségét is rombolta. Válaszlépésként a Google bevezette a "hasznos tartalom" (helpful content) algoritmust, mely jelentősen csökkenti az indexelésre jóváhagyott tartalmak listáját, az értéktelennek minősített indexelt tartalmakat, vagy akár komplett webhelyeket pedig hátrasorolja. Ez az algoritmus jelenleg a legjobb SEO-szakértők számára is komoly fejtörést tud okozni, hiszen sok esetben nem egyszerű eldönteni, hogy egy adott tartalom mi miatt minősül haszontalannak a Google-algoritmus számára, vagy egyáltalán a helpful content algoritmus áll-e egy organikus látogatottságcsökkenés hátterében. Egy biztos: a keresőoptimalizálásban az AI térhódításával egyre több, hagyományosan fontosnak tartott mutató válik elavulttá, vagy kontextusból kiragadva haszontalanná. A sikeres optimalizálásban ma a releváns gyakorlati tapasztalat többet ér az elméleti tudásnál, és az elemzéshez használt szoftverek adathalmazánál.

Technikai SEO

Mit jelent egyáltalán a technikai SEO?

A keresőben való megjelenés alapfeltétele, hogy a Googlebot felfedezhesse és megfelelően feldolgozhassa a webhely rangsorolás szempontjából értékes tartalmait. Szintén ide kapcsolódik a megfelelő oldalsebesség, biztonság és oldalélmény, melyek fontos rangsorolási tényezők. A technikai optimalizálás tehát az összes, indexeléshez és rangsoroláshoz köthető szerkezeti elemre kiterjed, és a tartalomkezelő rendszer beállításaitól a weblapot megjelenítő HTML/CSS/JS sablonon, oldaltérképeken és robots.txt fájlon át a weblapot kiszolgáló backend rendszeren, vagy akár a webszerveren végzett módosításokat foglalja magába.

Mikre kell ügyelni a weblap szerkezeti kialakításánál?

A legfontosabb a Googlebot számára bejárható, és megfelelően súlyozott belső linkstruktúra kialakítása, a tartalmat megjelenítő HTML-sablonok optimális kialakítása, valamint az élő és megszűnt URL-ek esetén a helyes HTTP-válaszkódok beállítása. A helyes szerkezeti kialakításhoz szervesen kapcsolódik a feltérképezést és indexelést szabályozó robots.txt, és meta információk, valamint szükség esetén a sitemap beállítása.

Milyen a jó weblap sablon?

SEO-szempontból ma már elengedhetetlen, hogy a weblap mobil eszközökön is problémamentesen használható legyen, valamint eszköztől függetlenül gyorsan betöltődjön, és jó felhasználói élményt biztosítson. Ezen felül fontos, hogy az oldal betöltődésekor a rangsorolás szempontjából fontos tartalmak ne csak a felhasználók számára legyenek elérhetőek, hanem a Google által is feldolgozható adatként jelenjenek meg.

Mik a HTTP-válaszkódok?

A weblapot kiszolgáló webszerver minden egyes URL lekérésére egy különböző információkat tartalmazó, úgynevezett HTTP-válaszfejlécet küld, melynek legfontosabb eleme a státuszra utaló válaszkód. A válaszkód a megtekintő eszköz, például webböngésző viselkedését határozza meg, és a Googlebot számára is elsődlegesen fontos indexelési információ.

Mi a HTTP-válaszkódok hatása az indexelésre?

A legelterjedtebb, és SEO-szempontból legfontosabb válaszkódok a következők: - 200 OK Jelentése: a kért tartalom elérhető és a kiszolgálása megtörténik (megjelenik a webböngészőben, illetve a Googlebot beolvashatja). Minden indexeltetni kívánt weboldal esetén ez a megfelelő válaszkód! - 404 Not Found Jelentése: a kért tartalom nem érhető el, a kiszolgálása nem történik meg. Helyes szerverkonfiguráció esetén ez minden webkiszolgáló válasza a megszűnt tartalmak, törölt fájlok esetén. Ha 404 válaszkód esetén történik tartalomkiszolgálás (például egyedi 404-oldal, vagy létező tartalomra tévesen adott 404 válaszkód esetén), az a webböngészőkben megjelenik, a Googlebot azonban nem olvassa be és nem dolgozza fel, nem indexeli! A már indexelt URL-eket a Googlebot 404 válaszkód esetén továbbra is rendszeresen, bár egyre ritkábban feltérképezi. Ha tartósan fennmarad a 404 állapot, egy idő után eltávolítja a tartalmat az indexből, ám még ezt követően is megpróbálkozik alkalmanként az újbóli feltérképezéssel, és ha egy idő után helyreáll a tartalom (200 vákaszkóddal), azt újból indexelheti. - 410 Gone Jelentése: Végleg megszűnt. Hatása a 404 válaszkóddal azonos, ám a Googlebot figyelembe veszi a végleges státuszt, ennek megfelelően a 404-nél hamarabb távolítja el a tartalmat az indexből, és csak ritkábban, vagy egyáltalán nem próbálkozik később újabb feltérképezéssel. Elsősorban akkor indokolt tehát ennek a válaszkódnak a használata, ha nem kívánt tartalmakat (pl. oldalfeltörésből származó spam oldalak tömegét) a lehető leggyorsabban és véglegesen szeretnénk eltávolíttatni a Google-indexből. - 301 Moved Permanently Jelentése: a kért tartalom véglegesen a Location válaszfejlécben megadott URL-re költözött. Hatására a webböngésző automatikusan meg is nyitja az új URL-t, és ezt meg is jegyzi, azaz a jövőben az eredeti URL megnyitása helyett már rögtön az új URL-t fogja megnyitni. A Googlebot ugyanígy értelmezi a válaszkódot, és az esetek többségében lecseréli az indexben a korábbi URL-t az újra - ilyen esetben a régi URL linkmutatóit, és pár egyéb fontos rangsorolási szignált is megörököl az új URL a régitől, a találati listán pedig a megszűnt URL helyét automatikusan az új veszi át. Ez azonban nem kötelező viselkedés a Google részéről, mivel számos SEO-manipulációs módszer létezik a 301 átirányításokból származó rangsorolási előnyökkel való visszaélésre, továbbá nem ritka a 301 átirányítások jószándékú, ám helytelen használata is. Hivatalosan tehát a Google a 301-átirányításra az "erős szignál, hogy az új URL legyen a kanonikus alak" definíciót használja. SEO-szempontból helyes használata, ha a website átalakítás/egyesítés, vagy egyéb okból megszánt, ám továbbra is fontos (pl. látogatott, jól rangsorolódó, értékes linkprofillal rendelkező, stb.) URL-eket a jövőben őket a valós felhasználók és a Google számára egyaránt megfelelően helyettesítő új oldalakra irányítjuk. - 302 Moved Temporarily Jelentése: a kért tartalom átmenetileg a Location válaszfejlécben megadott URL-re költözött. Működése látszólag megegyezik a 301-átirányítással, ám az állapotot a webböngészők sem tárolják, és a Googlebot sem tekinti véglegesnek. A Google a találati listán jellemzően továbbra is az eredeti URL-t fogja szerepeltetni, amely természetesen át fogja irányítani a felhasználókat az ideiglenes helyettesítő oldalra a 200 válaszkód visszaállításáig. A gyakorlatban weblap karbantartás miatt elérhetetlen tartalmakra, vagy egyéb okból ideiglenes megváltozott információk (pl. menetrend, stb.) esetén érdemes ezt a válaszkódot használni. Az indexelésre és rangsorolásra nincs pozitív hatása, ezért értékes tartalmak megszűnt URL-einek átirányítására nem alkalmas! Hivatalos Google-definíciója: "gyenge szignál, hogy az új URL legyen a kanonikus alak".

Milyen a SEO-szempontból helyes átirányítás?

A SEO-átirányítások lényege, hogy megszűnt URL-ek értékét más URL-eknek adjuk át. Ne hagyjuk őket az oldal megszűnésével elveszni, és természetesen az oda érkező látogatókat se veszítsük el, hanem igyekezzünk minél relevánsabb alternatív tartalmat biztosítani számukra. Ehhez az szükséges, hogy az értékes megszűnő URL-eket egyesével 301 átirányítással irányítsuk a megfelelő oldalra. Gyakori hiba a 302, meta, vagy javascript átirányítások használata erre a célra, illetve az optimális céloldalak meghatározása helyett az összes megszűnő URL tömeges átirányítása egy közös oldalra, jellemzően a webhely kezdőlapjára - ezek SEO szempontból helytelen, káros megoldások!

Mik a 301 és 302 átirányítások közti legfőbb különbségek?

A 301 átirányítás átadja az új URL-nek a régi URL néhány fontos rangsorolási szignálját, míg a 302 nem. A gyakorlatban az átirányítás Googlebot által történő felfedezését követően a Google a találati listán 301 esetén a régi helyett az új URL-t fogja megjeleníteni, míg 302 esetén továbbra is a régi URL marad a találati listán megjelenítve.

Milyen 301 átirányításra van szüksége minden webhelynek?

A webhelyek többsége http és http protokoll alatt, valamint www előtaggal és anélkül is elérhető - sőt, a webhely akár több, eltérő domainnév alatt is elérhető lehet. Amennyiben a webhely egyes részeit a Google különböző protokollal, előtaggal, vagy domainnel is indexeli, ez tartalomduplikációhoz és indexelési/rangsorolási problémákhoz vezet. Minden esetben érdemes tehát meghatározni, hogy melyik az általunk preferált alak (pl. https://azondomainneve.hu), és minden más alakot 301 átirányítással erre irányítani. Fontos, hogy ez az átirányítás is URL-szinten legyen megadva, ne aloldaltól függetlenül a kezdőoldalra történjen!

Mire való a canonical tag?

Ha a Google különböző aloldalakon annyira hasonló tartalmakat talál, hogy nem tartja szükségesnek közülük többet is megjeleníteni a felhasználói keresésekre, akkor kiválasztja, melyiket jelenítse meg közülük a találati listán. Ez lesz az úgynevezett kanonikus URL, a többi oldalt pedig néhány speciális esetet leszámítva nem fogja megjeleníteni, vagy akár indexelni sem. A canonical tag segítségével mi jelezhetjük a Google számára, hogy melyik legyen szerintünk a kanonikusként megjelölt URL, a következő formában: Fontos tudni, hogy az általunk megadott szabályt nem kötelező betartani a Google-nek. A kanonikus URL-t több szempont alapján határozza meg, de az általunk megadott érték, valamint az URL sitemapben történő szerepeltetése erős szignál a számára, hogy ténylegesen ezt válassza ki.

Mi az önhivatkozó canonical?

Az angolul self-referencing canonical-nak nevezett módszer egy bevált gyakorlat, melyet a népszerű tartalomkezelő rendszerek többsége ma már alapértelmezetten használ. A lényege, hogy minden oldal forráskódjába automatikusan bekerül a saját magára hivatkozó canonical tag. Ez megakadályozza, hogy a Google a tartalmat nem módosító technikai, vagy marketingcélú paraméterekkel ellátott URL-eket felfedezve azokat figyelmen kívül hagyja az indexelésnél, és a paraméterek nélküli, eredeti URL-t jelölje meg kanonikus alakként.

Mikor fontos a canonical tag használata?

Ha a webhelyünk működéséből adódóan azonos, vagy nagyon hasonló tartalmak jelennek meg eltérő URL-ek alatt, és mi szeretnénk megjelölni, hogy ezek közül melyiket válassza a Google kanonikus alakként. Például ha a webáruház termékkategóriáinak szűrésekor/rendezésekor a kategóriaoldal sort, order, vagy egyéb technikai célú URL-paraméterrel egészül ki, ezek indexelése nemkívánatos. Ilyen esetre egyébként tökéletes megoldást jelent az önhivatkozó canonical tagek használata.

Hogyan ne használjuk a canonical taget?

Ne helyezzünk el olyan URL-re mutató canonical taget az oldalon, amely valójában nem kapcsolódó tartalmú oldalra mutat. A Google ezeket valószínűleg egyébként is ignorálni fogja, de lehet káros hatása az indexelésre és rangsorolásra. Gyakori hiba például a lapozóoldalak mindegyikének az első oldalra történő canonicalozása. Amennyiben ezt figyelembe veszi a Google, az első oldalon kívül a lapozóoldalakon szereplő tartalom nem kerül indexelésre, valamint a rajtuk szereplő hivatkozások sem kerülnek feldolgozásra. Például ha egy 100 terméket tartalmazó webáruház termékkategória oldalanként 20 terméket jelenít meg, ám a 2.-5. lapozóoldalak mind az 1. oldalra vannak canonicalozva, akkor előfordulhat, hogy emiatt a Google csak az első 20 terméket fogja felfedezni és indexelni, a többi 80 pedig nem jelenik meg a keresőben!

Mi a közös a canonical tagben és a 301 átirányításban?

A Google hivatalos definíciója szerint mindkettő erős szignált jelent arra vonatkozóan, hogy a hivatkozott URL legyen a kanonikus alak. Ezért bármely esetben, amikor 301 átirányítás használata lenne indokolt, ám az technikai okból nem kivitelezhető, a canonical tag használata javasolt helyette. Fontos azonban tudni, hogy míg a 301 átirányítás ténylegesen átirányítja a felhasználót az új URL-re, a canonical tag ezt nem teszi meg. Megszűnt oldalak átirányítására azonban nem alkalmas a canonical tag, mivel a 404 HTTP-válaszkód után a Google nem dolgozza fel az oldal tartalmát, így a benne elhelyezett canonical taget sem fogja figyelembe venni.

Fontos, hogy a weboldal mobilbarát kialakítású legyen?

Igen. A weblapok látogatói ma már jóval magasabb arányban érkeznek mobileszközökről, mint asztali számítógépekről. Elengedhetetlen, hogy mobileszközökön is megfelelően fogyaszthatóak legyenek a webes tartalmak, a Google algoritmusban pedig emiatt a mobilos használhatóság az oldalélmény részeként fontos rangsorolási tényezővé vált.

Probléma, ha mobilon és asztali számítógépen eltérő tartalom jelenik meg a weblapon?

Igen. A Google 2020-ban bevezette a mobile-first indexing rendszert, ami azt jelenti, hogy a weboldalak mobil verzióin megjelenő tartalmat tekinti elsődleges fontosságúnak az indexelés és rangsorolás során. Bár csökkenő arányban, de a Googlebot továbbra is feltérképezi a weblapok asztali verzióit is, tehát a mobil verzió hiánya ellenére is megjelenhetnek a weblapok a keresőben. A mobil és desktop verziókon eltérő tartalom, vagy a mobilváltozat hiánya azonban többnyire negatívan hat a rangsorolásra. Fontos tehát, hogy legyen mobilbarát kialakítású a website, és a rangsorolás szempontjából fontos tartalmak és egyéb oldalelemek az asztali és mobil weboldalon megegyezzenek, és a Googlebot számára feltérképezhető módon jelenjenek meg!

Fontos az oldalbetöltési sebesség?

Természetesen igen. Számtalan tanulmány igazolta már, hogy a túl lassú oldalbetöltés felhasználó-, és vásárlóvesztéssel jár. A Google a Search Console Alapvető webes vitals-mutatók eszközén keresztül mutat általános információt a webhely oldalainak betöltési sebességeiről, az online PageSpeed, valamint a Chrome böngészőbe épített Lighthouse pedig egy konkrét URL részletes elemzését, és javítási javaslatait jeleníti meg. Az átlagosnál rosszabb oldalbetöltési sebesség negatívan hat a rangsorolásra. Ne elégedjünk meg, ha a Pagespeed eszköz az asztali verzióra megfelelően magas pontszámot ad, mert a gyakorlatban a mobil oldalbetöltési sebesség számít mérvadónak!

Hogyan javítható az oldalbetöltési sebesség?

A Google PageSpeed eszköz részletes információval szolgálnak a konkrét problémákról, és azok javításának módszereiről. A modern weblapsablonok - különösen Elementor, Divi, vagy más drag-and-drop vizuális szerkesztő használata esetén - médiagazdag tartalommal, és marketing követőkódok garmadájával a tapasztalt front-end fejlesztők számára is alaposan fel tudják adni a leckét, a cél nem a 100 pontos PageSpeed sebesség elérése. Ha a Search Consoleban - a fontos céloldalainkat is beleértve - a webhely oldalai többségében Jó webes vitals besorolást kapnak, akkor a rangsorolás sebességi feltételei megfelelően teljesülnek. Amennyiben azonban fontos céloldalaink, vagy a webhely oldalainak többsége Gyenge besorolású, mindenképp érdemes megtenni a megfelelő lépéseket az oldalbetöltési sebesség fokozására. Szerencsére a PageSpeed pontszám szempontjából fontos jellemzők egy része speciális szakértelem nélkül is viszonylag egyszerűen javítható.

Melyek a PageSpeed legkönnyebben javítható elemei?

Az alábbi lista következetes alkalmazása többnyire elegendő ahhoz, hogy a Search Console "Rossz" webes vitals mutatója Jó értékre változzon, illetve a PageSpeed besorolás pirosról legalább sárgára változzon, de akár a zöld szinthez is elég lehet!
  • Kezdeti szerverválaszidő: gondoskodjon róla, hogy webhelye megfelelően gyors tárhelyen üzemel. Ha ez önmagában nem elég, gyorsítótárazással (cache) többnyire jelentősen javítható ez az érték.
  • Méretezze megfelelően a képeket: fontos, hogy a weblapon megjelenő képek akkora méretben legyenek feltöltve, amekkorában ténylegesen meg fognak jelenni. Gyakori hiba a telefonról/fényképezőgépről letöltött kép leméretezés nélküli feltöltése a weblapra - ez ugyan az esetek többségében a kívánt méretben jelenik meg a weblapon, ám hatalmas mérete jelentősen rontja a betöltési sebességet!
  • Kódolja hatékonyan a képeket: a weblapon megjelenő képek a megfelelő minőséghez elegendő legerősebb tömörítéssel legyenek elmentve, ez jelentősen csökkenti a fájlméretet és a betöltési időt.
  • Jelenítse meg a képeket következő generációs formátumokban: a webp képformátumot minden elterjedt böngésző aktuális verziója támogatja már. Használata jelentősen javíthatja a PageSpeed értéket. Amennyiben a webhelyet régebbi, inkompatibilis böngészőkkel is látogatják a felhasználók, a legjobb gyakorlat továbbra is a jpeg képek használata, és webp-konverter segítségével a kompatibilis böngészők részére webp kódolású kép kiszolgálása - a Googlebot ez esetben a webp képet fogja feldolgozni.
  • Engedélyezze a szövegtömörítést: A tartalom tömörített kiszolgálása jelentősen csökkenti a sávszélesség-használatot, ezáltal gyorsítja az oldalbetöltést. Legegyszerűbb megvalósítása az alábbi kódrészlet elhelyezése a .htaccess fájlban:
    SetOutputFilter DEFLATE
    AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/x-javascript application/x-httpd-php
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
    BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
    Header append Vary User-Agent env=!dont-vary
    
  • Jelenítse meg a statikus eszközöket hatékony gyorsítótár-házirend használatával: a ritkán módosuló képek, videók, fontok, js-, és css fájlok böngészőoldali gyorsítótárazása megelőzi ezen fájlok indokolatlan többszöri letöltését, így csökkenti a sávszélesség-használatot, és javítja a betöltési sebességet. A gyorsítótárazás javasolt időtartama 1 év. Legegyszerűbb megvalósítása az alábbi kódrészlet elhelyezése a .htaccess fájlban:
    
    Header set Cache-Control "max-age=31536000"
    
    
  • Csökkentse a harmadik felek kódjai által kiváltott hatást: a külső szolgáltatóktól beolvasott fájlok jelentősen lassíthatják az oldal betöltődését. Érdemes például a webfontokat lokálisan, a saját szerverről kiszolgálva megjeleníteni.
  • Késleltesse a képernyőn kívüli képek betöltését: a tartalom görgetés nélkül nem látható, alsóbb régióiban megjelenő képek alapértelmezetten az oldala megnyitásakor azonnal letöltésre kerülnek, ez azonban lassítja az oldal betöltődését. Érdemes ezen képeknél az img tagen a loading="lazy" HTML-attributumot használni, melynek hatására csak akkor töltődnek le a képek a böngészőbe, ha a felhasználó ténylegesen odagörget.
  • Csatlakozzon előre a szükséges forrásokhoz: ha külső szolgáltatóktól származó betűkészletek, követőkódok, videók, vagy egyéb, az oldalbetöltést lassító elemeket használ a weboldal, ezek betöltése némileg gyorsítható a kiszolgálójukhoz történő korai csaatlakozással. Ehhez a HTML headben, még az elem beolvasása előtt helyezzünk el preconnect, vagy dns-prefetch attribútumú link taget, pl. az alábbi módon:
    <link rel="preconnect" href="https://www.google-analytics.com">
    
  • A legnagyobb vizuális tartalomválasz képének előtöltése: az LCP (Largest Contentful Paint) a Core Web Vitals egyik fontos mutatója, és a képernyőn a betöltést követően, görgetén nélkül megjelenő legnagyobb méretű tartalomblokk megjelenítési idején alapul. Ez a modern megjelenésű weboldalaknál gyakran egy nagyméretű képet jelent, melynek letöltése pusztán a viszonylag nagy fájlméret miatt lassú lehet. A HTML headben elhelyezett előtöltő kóddal már a betöltés elején megkezdhető a képfájl letöltése, mely jótékonyan hathat az LCP-értékre, ezáltal pedig a PageSpeed pontszámra is - és ezen felül természetesen a tényleges felhasználói élményt is javítja a gyorsabb képmegjelenítés. Példakód:
    <link rel="preload" fetchpriority="high" as="image" href="/kepkonyvtar/nagymeretu-fejleckep.jpg" type="image/jpeg">

Mit jelent a jó oldalélmény?

A page experience fontos rangsorolási szempont,mely több különálló szignál együttesét foglalja magába. Részei a biztonság, az oldalbetöltési sebesség és webes vitals mutatók, a mobilbarát kialakítás, valamint a zavaró elemek nélküli tartalommegjelenítés.

Mik a strukturált adatok?

A strukturált adatok a weblap forráskódjában speciális címkékkel megjelölt adatok, melyek a weblap tartalmára vonatkozó extra információkat tartalmazhatnak. A formátum részletes specifikációja a schema.org webhelyen érhető el, ám a Google nem használja az itt szereplő összes lehetőséget az indexelésnél és a találati listaelemeknél. A Google strukturált adat tesztelő eszköze itt érhető el: https://search.google.com/test/rich-results

Fontos a strukturált adatok használata?

Igen, hiszen a tartalom jobb értelmezése jótékony hatású lehet a rangsorolásra, a találati listán megjelenő extra információk (pl. értékelés, ár, stb.) pedig informatívak a keresést végző felhasználók számára, ezáltal növelhetik az átkattintás valószínűségét. A legnépszerűbb strukturált adatok közé tartoznak a navigációs elemek, termékinformációk, értékelések és vélemények. A Google által támogatott teljes lista itt található: https://developers.google.com/search/docs/appearance/structured-data/search-gallery

Fontos a tárhely minősége?

Igen. A kiszolgálás stabilitása és gyorsasága hatással van a PageSpeed értékre, tehát egy lassú tárhely önmagában rossz hatással lehet a rangsorolásra. Ha a túlterhelt webszerver rendszeresen hibaüzenetet ad a weboldalak megnyitásakor, akkor ezzel egyrészt értékes látogatókat veszíthet, másrészt a Google csökkenteni fogja a feltérképezések mennyiségét a webhelyen, ez pedig indexelési problémákhoz vezethet. Ezen túl amennyiben a Googlebot tartósan, vagy rendszeresen problémába ütközik a domainnév feloldásakor, vagy a webhely elérésekor, negatív minőségi szignált fog a webhelyhez rendelni, mely károsan hat a rangsorolásra, legrosszabb esetben pedig a találati listáról történő teljes eltávolítást is eredményezheti. Az erre vonatkozó állapotjelentés a Search Console Beállítások -> Feltérképezési statisztikák -> A gazdagép állapota menüpont alatt érhető el. A stabil, gyors működésen túl a tárhely biztonsági beállításai is fontosak, hiszen egy rosszul konfigurált, sebezhető tárhelyen magas az oldal feltörésének kockázata, mely ha megtörténik, természetesen rangsorolási problémákhoz vezet.

Számít, hogy hazai, vagy külföldi tárhelyszolgáltatónál üzemel a weboldalam?

Bár a webhely IP-címéhez tartozó földrajzi hely a lokális rangsorolási szignálok közé tartozik, az esetek többségében a külföldi tárhely használata nincs érezhető negatív hatással a rangsorolásra - amennyiben a tartalom letöltése a nagyobb távolság ellenére gyorsan megtörténik. A hazai tárhelyszolgáltatók között is bőven akad olyan, aki webszervereit külföldi szerverparkokban üzemelteti. Ha szeretné tudni, az Ön weblapja milyen földrajzi helyen üzemel, a domainnévre végzett WHOIS lekérdezéssel egyszerűen kiderítheti, például a következő weboldalon: https://whois.domaintools.com

Milyen a jó belső linkstruktúra?

Belső linkstruktúra alatt a webhely oldalainak egymásra mutató hivatkozásait értjük. A feltérképezéshez fontos, hogy a webhely minden indexeltetni kívánt aloldala kapjon linket más, már indexelt, vagy indexelhető oldal(ak)ról. A PageRank algoritmuselem a linkek alapján rendel értéket az egyes aloldalakhoz, érdemes tehát a fontos aloldalakra több hivatkozást elhelyezni, mint a kevésbé fontosakra. Jó, ha a fontos oldalak a kezdőlapról indulva legfeljebb 2-3 kattintással elérhetőek.

Milyen hatással van a breadcrumb (morzsamenü) a belső linkstruktúrára?

A breadcrumb menü lényege, hogy minden aloldal hivatkozik a szülőkategóriá(k)ra. Mivel a felsőbb kategóriaszintekhez a gyakorlatban többnyire erősebb versennyel rendelkező, általánosabb kulcsszavak tartoznak, ez a megoldás önmagában képes azt biztosítani, hogy a "fontosabb" aloldalak több belső linket kapjanak, mint a kevésbé fontosak. Sok aloldallal, többszintű kategóriarendszerrel rendelkező websiteoknál kifejezetten ajánlott a használata.

Fontosak a tartalomba ágyazott belső linkek?

A Google védjegye, a PageRank rangsorolási algoritmuselem a kezdetek óta rengeteget változott a linkmanipulációk elleni védekezés részeként. Mai formájában a SEO-közvélemény szerint a navigációs elemekben, különösen az oldalsávban és láblécben elhelyezett hivatkozásokra kevesebb értéket (link juice-t) ad át a hivatkozott oldalaknak, mint a fő szöveges tartalmakba ágyazott linkek esetén. Ezt az elméletet a gyakorlati megfigyelések jelenleg tökéletesen igazolják, ennek megfelelően igen, kifejezetten ajánlott tartalmi linkekkel erősíteni a belső linkstruktúrát.

Mire ügyeljek egy URL módosításakor?

Elsősorban arra, hogy szükségtelenül ne módosuljon! Sok tartalomkezelő rendszer az oldalcím alapján automatikusan generálja az URL-t, de egy aloldal új menücsoportba, vagy egy termék új kategóriába helyezése is megváltoztathatja az URL-ben az elérési utat. Ha lehet, ezt kerülje el, például manuális felülírással! Amennyiben elkerülhetetlen az URL megváltoztatása, gondoskodjon róla, hogy a régi, megszűnt URL a változtatás után a lehető legrövidebb időn belül 301 válaszkóddal irányítson át az új URL-re.

Mire ügyeljek tömeges URL-módosításkor?

Elsősorban itt is azt tanácsoljuk, hogy amennyiben nem kifejezetten szükséges, kerüljük az ilyen változtatásokat. Ha mégis megtesszük, az összes megszűnt URL egyesével legyen átirányítva 301 válaszkóddal az új megfelelőikre (ehhez természetesen használhatóak szabályok is, nem kell ténylegesen egyesével beállítgatni az átirányításokat). A helytelen kivtelezés, például eltérő HTTP-válaszkód használata, ne megfelelő cél-URL-re történő irányítás, megszűnt URL-ek közös aloldalra történő átirányítása indexelési és rangsorolási problémákat eredményezhet! Nem árt szem előtt tartani, hogy mivel a jelenlegi Google algoritmus a korábbiaknál szigorúbban szelektálja az indexelhető URL-eket, még a technikailag hibátlanul kivitelezett tömeges átirányítás esetén is előfordulhat, hogy az új URL-ek egy része már nem kerül indexelésre - különösen, ha azokon gyenge minőségű a tartalom, vagy ha a teljes webhelyhez negatív szignálokat rendelt a Google.

Domainek, aldomainek

Számít a domainnév a rangsorolásban?

Igen. A domainnév-kiterjesztés a regionális rangsorolásnál lehet fontos tényező, míg a domainnévben szereplő kulcsszó megkönnyítheti az arra történő rangsorolást.

Milyen a jó domainnév?

Bár a domainnévben szereplő kulcsszó továbbra is jelenthet rangsorolási előnyt, a gyakorlatban ennél hasznosabb lehet a márkaépítés szempontjait, a megjegyezhetőséget figyelembe venni. Az ékezetes, kötőjeles, speciális kiterjesztésű (.net .org, .info, stb.) domainek nehezen megjegyezhetőek. Korábban jellemzően a bennük szereplő kulcsszóból származó vélt, vagy valós előny miatt voltak elterjedtek, de megjegyezhetetlenségük miatt a potenciális látogatók egy része gyakran a hasonló nevű konkurens weblapján kötött ki. Ha sikerül egyedi, megjegyezhető domainnevet találnunk, és a visszatérő látogatók fontos közönséget jelentenek, érdemes rögtön a hasonló ékezetes és kötőjeles domainneveket is lefoglalni, nehogy ezt később a konkurencia tegye meg. Ilyen esetben a "tartalék" domainnevek 301 átirányítással mutassanak az elsődleges domainre, így a félregépelő felhasználók eljutnak a weblapra, viszont a duplikációból adódó Google-indexelési probléma elkerülhető.

Fontos, hogy kulcsszavas domaint használjak?

Ha van olyan egyetlen kulcsszó, amire erős a verseny, és a domainnévben szerepeltetése nem okoz megjegyezhetőségi problémát, akkor érdemes lehet ilyen domaint regisztrálni. A weblapok többségének azonban nem egyetlen kulcsszóra kell fókuszálnia, hanem sokra, és mindegyiket lehetetlen lenne a domainben szerepeltetni. A Google a 2012-es EMD (Exact Match Domain) algoritmusfrissítés óta hátrasorolja a gyenge tartalmú, pusztán a pontos kulcsszóegyezésű domainre építő webhelyeket, és azóta a tartalom sokkal fontosabb rangsorolási tényező a domainnévbe foglalt kulcsszónál.

Mi a TLD, és mi a hatása a keresőoptimalizálásra?

A TLD (Top Level Domain) a domainnév pont utáni kiterjesztése. Egy adott országban történő rangsorolásra pozitív hatással van az országhoz rendelt TLD használata (pl. Magyarországon a .hu domainvégződés). Az általános .com domainkiterjesztések is többnyire jól működik regionális szinten, az egyéb általános kiterjesztések (pl. .info, .net, .org, stb.) üzleti célú használata azonban nem javasolt - egyrészt a megjegyezhetetlenség miatt, másrészt azért, mert a múltban ezeket gyakran használták spam jellegű, vagy manipulatív tartalmakhoz, így egyesek szerint a Google algoritmusban enyhe negatív szignál kapcsolódik hozzájuk. Szintén nem ajánljuk más országok TLD-inek "frappáns" használatát, pl. a "profi" szó miatt a pro.fi domain regisztrálását - bár elsőre jópofa ötletnek tűnhet, a felhasználók számára ez is többnyire megjegyezhetetlen, az eltérő regionális TLD pedig rangsorolási hátrányt jelent.

Tartalomoptimalizálás

Mennyire fontos a tartalom a keresőoptimalizálásban?

Minden más szempontnál fontosabb. A jelenlegi algoritmusban a tartalomhoz kapcsolódnak a legerősebb rangsorolási tényezők.

Milyen a jó tartalom?

A klasszikus SEO-megközelítés szerint kulcsszavas, megfelelő terjedelmű és jól strukturált. Az utóbbi években azonban a Google-algoritmus rohamos fejlesztésével olyan, kevésbé kézzelfogható elemek is megjelentek a tartalmi rangsorolásban, mint az E-E-A-t, vagy a "hasznos tartalom" (useful content).

Mi az E-E-A-T?

Az "Experience, Expertise, Authoritativeness, and Trustworthiness" (tapasztalat, szakértelem, tekintély és megbízhatóság) rövidítése, a tartalmak minőségének meghatározására szolgál. Évek óta a Google keresési minőségellenőreinek szóló útmutató https://guidelines.raterhub.com/searchqualityevaluatorguidelines.pdf egyik legfontosabb eleme, a minőségellenőrök által adott visszajelzéseket folyamatosan használják a rangsorolási algoritmus pontosabbá tételére. Lényege, hogy az ellenőrizhetően hiteles és szakmai forrásból származó, megbízható információk magas, míg a kontár, megbízhatatlan, netán megtévesztő tartalmak alacsonyat - különösen szigorúan érvényesül ez az elv a felhasználók egészségére, anyagi biztonságára, jóllétére kiható, úgynevezett YMYL (Your Money, Your Life) témakörbe tartozó tartalmak esetén. Az E-E-A-T nem önálló rangsorolási tényező, ám a hasznos tartalom szempontrendszer fontos eleme, valamint időszakos algoritmusfrissítésekben is rendszeresen használják, melyek célja a nemkívánatos találatok eltávolítása a keresőből. Utóbbival eddig többnyire speciális pénzügyi témaköröket, egészségügyi információkat nyújtó oldalakat, felhasználói véleményeket, és hamis személyes tapasztalatot sugalló portálokat céloztak.

Mit jelent a Google szerint a hasznos tartalom?

A "helpful content" a Google legújabb tartalomminősítési koncepciója. Több időszakos algoritmusfrissítés után a 2024 márciusi core update-tel vált az alapalgoritmus részévé. A Helpful Content System nem önálló rangsorolási tényező, hanem több, különálló szignál együttesét veszi figyelembe. A korábbi, időszakos HCU-update-ek a teljes webhelyre kiterjedő szignált alkalmaztak a kvalifikáció végén, a jelenlegi alapalgoritmusban futó rendszer azonban a webhely-szintű mellett már aloldalanként önálló HC-szignált is használ. A Google definíciója szerint az a hasznos tartalom, amely a felhasználó számára részletes, minden fontos területre kiterjedő, eredeti információt nyújt.

A keresőmotornak, vagy a felhasználónak gyártsak tartalmat?

A "hasznos tartalom" algoritmus megjelenése óta ez nem lehet kérdés, hiszen a Google a felhasználónak gyártott, valóban értékes tartalmakat preferálja - és ezeket minden korábbinál pontosabban képes is azonosítani. Az "optimális" terjedelemre és kulcsszótartalomra épülő, valós értéket nem hordozó SEO-szövegek kora úgy tűnik, véget ért.

Érdemes ChatGPT-t, vagy más AI-eszközt használni a tartalomgyártáshoz?

Mi ezt többnyire nem javasoljuk jelenleg. A hasznos tartalom algoritmus bevezetésének egyik fő oka a mesterséges intelligenciára épülő eszközökkel tömegesen generált, a felhasználók számára értéktelen, vagy akár megtévesztő tartalmak tömeges megjelenése volt. Amennyiben biztos benne, hogy AI-eszközök használatával értékes, a "hasznos tartalom" definíciójának megfelelő tartalmat képes előállítani, akkor ez természetesen nem ütközik Google-irányelvbe, és remélhetőleg nem jár negatív következményekkel. Ha azonban csak azért használ AI-eszközt, hogy minél kevesebb befektetéssel tudjon jelentős mennyiségű "SEO-szöveget" előállítani, netán még a témában való jártassággal sem rendelkezik, akkor mi kifejezetten lebeszélnénk erről. Ez a fajta felhasználás már a Google spam útmutatójába is bekerült, a jövőben pedig várhatóan egyre gyakrabban és hatékonyabban fog fellépni ellene a Google mind az alapalgoritmusban, mind kifejezetten erre irányuló időszakos algoritmusfrissítésekkel. Az értéktelen AI-tartalmak SEO-célú használata még ha jelenleg járhat is rövid távú előnnyel, hosszú távon több kárt okozhat, mint hasznot.

Milyen tartalmi elemeket nem indexel a Google?

Bár triviális, muszáj megemlíteni, hogy a Googlebot az általa felfedezhetetlen, vagy feltérképezhetetlen oldalakon elhelyezett tartalmat természetesen nem képes indexelni. A Googlebot a feltérképezés során nem végez felhasználói interakciókat a weboldalon, ezért a csak meghatározott műveletre, például kattintásra betöltődő tartalmakat nem fedezi fel, és nem is indexeli. A mobile-first indexelés bevezetése óta a weblapok mobilnézetében megjelenő tartalom az indexelendő, tehát hivatalosan ha csak az asztali nézeten jelenik meg egy tartalomrészlet, az nem kerül indexelésre. Bár a videós és képi tartalmak értelmezése és feldolgozása minden korábbinál magasabb szintre lépett, a Google a képeken és videókban megjelenő szövegeket nem indexeli. Szintén nem kerülnek a weboldal részeként indexelésre a keretekben (frame, iframe) megjelenített tartalmak.

Mit jelent a duplikált tartalom?

A teljesen azonos, vagy nagymértékben hasonló, egyedi értékkel nem rendelkező tartalommásolatokat a szaknyelv duplikációnak nevezi. A Google-algoritmus működésének egyik alapja, hogy nem kíván egy adott keresésre több azonos, vagy rendkívül hasonló találatot kiszolgálni, mivel az ismétlődések nem nyújtanak új információt a keresést végző felhasználóknak. A duplikált tartalmakat tartalmazó oldalak közül egyéb rangsorolási szignálok alapján választja ki a keresőben megjelenítendő oldalt, a többi pedig nem kerül ki a találati listára, sőt, egyre gyakrabban indexelésre sem.

Mik a tartalomduplikáció leggyakoribb formái?

A tartalmat megjelenítő webhely alapján 2 csoportba sorolhatóak: amennyiben egy adott webhely aloldalain ismétlődnek a tartalmak, belső duplikációról, ha pedig más webhelyen jelenik meg az ismétlődő tartalom, külső duplikációról beszélünk. A külső duplikációk sajnos az esetek többségében tartalomlopásból erednek. Nem ritka azonban az az eset sem, amikor a weblap tulajdonosa üzemeltet több weblapot eltérő domainek alatt, és egyes tartalmak szándékosan, vagy figyelmetlenségből több eltérő domain alatt is megjelennek. Webáruház termékek esetén szintén gyakori, hogy több webshop is a forgalmazó által adott termékleírásokat és képeket használja. A belső duplikációk egy részét technikai beállítások okozzák, melyek következtében egyes tartalmak több, eltérő URL alatt is megjelennek. Webshopok esetén előfordul, hogy egyes termékcsoportok, vagy termékvariációk annyira hasonlóak, hogy a hozzájuk tartozó paraméterek, leírások, akár maga a terméknév is szinte teljes mértékben megegyezik. Duplikációnak tekintendőek a több aloldalon megjelenő, azonos tartalmú általános információblokkok (pl. szállítási információk, gyártóismertetők, stb.) is.

Okoz duplikációs problémát, ha a weblapomon ismétlődő tartalmak is szerepelnek?

A gyakorlatban a weblapok többsége tartalmaz ismétlődő tartalomblokkokat, anélkül, hogy ez rangsorolási problémát okozna. A Google a weboldal tartalmait elsődleges, vagy járulékos kategóriába sorolja. Az elsődleges kategóriába az a tartalom tartozik, amely közvetlenül szolgálja az oldal fő célját. A járulékos kategóriába tartoznak a navigációs, design, és egyéb kisegítő elemek, valamint az ismétlődő tartalomblokkok többsége is. Ha az elsődleges tartalom értékes és egyedi az oldalon, akkor az ismétlődő járulékos elemek nem okoznak duplikációs problémát - sőt, az elsődleges tartalomhoz, és a felhasználó céljához kapcsolódó hasznos és hiteles információk az E-E-A-T besorolást is javíthatják. Amennyiben azonban az elsődleges tartalom gyenge minőségű (vagy teljesen hiányzik az oldalról), és a tartalom nagy része ismétlődő elemekből áll, az erőteljes negatív hatással lesz az indexelésre és rangsorolásra. Amennyiben egy webhely többségében ilyen értéktelen tartalmú aloldalakból áll, az a teljes webhelyre ható negatív rangsorolási szignált eredményez, mely még a jó minőségű aloldalak keresőpozícióit is leronthatja.

Hogyan válasszak megfelelő céloldalt a kulcsszavakhoz?

A legfontosabb, hogy az oldal tartalma elsődlegesen kapcsolódjon a választott kulcsszóhoz, valamint a keresési lekérdezést végző felhasználó szándékához.

Mit jelent a kulcsszó-kannibalizáció?

SEO-koncepció, a Google hivatalos terminológiájában nem fordul elő. Lényege, hogy ha több aloldal azonos kulcsszóra van optimalizálva, azok "kannibalizálják" egymás keresőpozícióit, ezért vagy valamely fontos céloldal nem jelenik meg a találati listán, vagy az érintett oldalak pozíciói rosszabbak annál, mint amit egyetlen jól optimalizált oldal elérhetne. A gyakorlatban többnyire tévesen értelmezik a koncepciót, a SEO-szakmai csoportokban gyakran adnak erre alapuló helytelen tanácsokat a kérdezőnek. A valóság az, hogy egy jól optimalizált website esetén nem okoz kulcszó-kannibalizációt önmagában az a tény, hogy bizonyos kulcsszavak több weboldalon is a fontos tartalom részét képezik - sőt, ilyen esetben akár a webhely több releváns aloldala is megjelenhet egymás mellett a találati listán.

Milyen esetben okozhat valóban problémát a kulcsszó-kannibalizáció?

Ha a webhely több aloldala azonos keresési szándékot kiszolgáló, SEO-szempontból erőteljesen egyetlen kulcsszóra épülő aloldalt tartalmaz. Jelentősen rontja a helyzetet, ha ezen oldalakra azonos kulcsszót erősítő külső linképítés történik, valamint a belső linkstruktúra is következetlenül megoszlik a két oldal között. Ezek a tényezők azt eredményezik, hogy a Google-algoritmus számára nem egyértelmű, melyik aloldal a jobb választás a keresések kiszolgálására, a rangsorolásra ható fontos szignálok pedig megoszlanak az érintett aloldalak között, és valóban a lehetségesnél rosszabb keresőpozíciót eredményeznek. Ilyen esetben érdemes az adott kulcsszóra irányuló komplett SEO-tevékenységet a keresőben megjeleníteni kívánt aloldalra összpontosítani, a kannibalizáló aloldal(ak) tartalmát pedig más keresőkifejezésekhez, vagy keresési szándékokhoz igazítani.

Fontos a kulcsszósűrűség?

Abban az értelemben nem, hogy ma már nem létezik optimális kulcsszósűrűség, amely a lehető legjobb keresőpozícióhoz vezetne. Ha egy már megfelelő tartalomban tovább növeljük a kulcsszó előfordulási gyakoriságát, az nem fog további javulást előidézni a helyezésben. Ellenkező hatása azonban lehet, mivel a kulcsszóhalmozás továbbra is a Google spam elleni algoritmusának egyik fő célpontja, ezért a túlzásba vitt kulcsszavazás jelentős negatív hatással lehet a rangsorolásra! Fontos tudni, hogy ez nem csak pontos kulcsszóegyezés esetén igaz, de a ragozott, toldalékolt alakok, szinonimák túlzott használata is előidézheti a spam besorolást.

Érdemes SEO-céllal blogolni?

Amennyiben a felhasználók számára értékes céllal történik a blogolás (pl. információs szándékú keresési lekérdezések megválaszolása, vagy szakértői státuszépítés), a válasz egyértelműen igen. A megfelelő koncepció nélkül előállított, valójában értéktelen blogbejegyzések kizárólag SEO-célból történő publikálása azonban a gyakorlatban ritkán hoz számottevő előnyt - sőt, a Helpful Content algoritmus bevezetése óta akár a teljes webhely értékelésére, rangsorolására negatívan is hathatnak.

A saját domainen, vagy külső domainen érdemes a blogot elhelyezni?

Korábban bevált gyakorlat volt az optimalizált webhelyet támogató blogot eltérő domain alatt üzemeltetni, elsősorban linképítési célból. A mai algoritmus számára nem jelent jelentős hozzáadott értéket, ha egyetlen domain több aloldaláról is érkeznek linkek, önmagában emiatt tehát szinte biztosan nem térülnek meg a külső blog vezetésébe fektetett erőforrások. A saját domain alatt vezetett, a webhely fő témaköréhez szorosan kapcsolódó tartalmú blog a belső linkstruktúra erősítésén túl a szakértői státusz, autoritás erősítésével, a webhely tematikus relevanciájának növelésével, a látogatószám növelésével, és ideális esetben az értékesítés közvetlen támogatásával sokkal nagyobb előnyt jelent, ezért üzleti weboldalak esetén mi többnyire ezt javasoljuk.

A szövegen kívül milyen fontos elemei lehetnek a tartalomnak?

A szöveges tartalmakban megjelenített jó minőségű képek és videók előnyösen hathatnak a rangsorolásra.

Mik azok a kép altok és hogyan érdemes őket használni?

A képek beágyazására használt img HTML-tag alt attribútuma a képi tartalom szöveges leírására szolgál. Az alt-ban elhelyezett szöveg a weboldal normál szöveges tartalmához hasonlóan indexelésre kerül, és előnyös lehet a rangsorolásnál. Míg régen bevált SEO-praktikának számított a kulcsszavak kép altokban való többszörös elhelyezése, ma már ehelyett a természetes, valóban a képi tartalomra vonatkozó alt szöveg használata javasolt - természetesen továbbra is előny, ha ezek fontos kulcsszavakat is tartalmaznak.

Többnyelvű weboldalak

Mikor érdemes a tartalmat több nyelven megjeleníteni?

Csak abban az esetben javasoljuk, ha reális cél az idegen nyelvű, és/vagy más országban élő felhasználók számára történő értékesítés, vagy szolgáltatás - és ha egyébként ehhez minden szükséges feltétel rendelkezésre áll (pl. logisztika, ügyfélszolgálat, jogszabályi megfelelés, stb.). Azt is alaposan át kell gondolni, hogy lesz-e elég erőforrás a többnyelvű tartalmak előállítására (fordítás) és publikálására, és nem utolsósorban a népszerűsítésére (idegen nyelvű SEO, hirdetések, stb.). Sajnos gyakori hiba téves feltételezések - például "sok külföldi él Magyarországon, belőlük is vásárló lesz, ha angolul is elérhető a webáruházam" - alapján fellelkesülve belevágni a többnyelvűsítésbe, mely ilyen esetekben többnyire hamarosan félbe is marad, a hibásan implementált, félkész nyelvi verzió azonban a magyar nyelvű tartalmak rangsorolására is káros lehet!

Hogyan érdemes az idegen nyelvű tartalmat lefordítani?

Csábító lehet az automata fordítóprogramok használata, noha mindeki szembesült már vele, hogy ezek jó esetben is csak épp elfogadható eredményt képesek produkálni, rosszabb esetben pedig akár teljes zagyvaság is lehet az eredménye. Azon túl, hogy az ilyen tartalom eleve elriasztja a potenciális vásárlók egy részét, a minőségre fókuszáló rangsorolási algoritmusok sem fogják díjazni, kiemelkedő SEO-eredmények semmiképp nem várhatóak a használatuk mellett. Erősen javasolt tehát legalább a fontos általános információkat, a felhasználói élményt befolyásoló oldalelemeket, valamint a legfontosabb üzleti céloldalak tartalmát a szakterületet ismerő, emberi fordítóval lefordíttatni, ideális esetben pedig akár a célnyelvet anyanyelvi szinten beszélő személlyel lektoráltatni. Fontos, hogy az egyes aloldalakon megjelenő tényleges tartalom mellett a felhasználói felület elemei (például navigáció), valamint a SEO-szempontból fontos egyéb oldalemek, mint a title és meta description is fordításra kerüljenek. Az idegen nyelvű URL-ek fordítása is javasolt, elsősorban nem is SEO-szempontok miatt, hanem az idegen nyelvű felhasználók bizalmának növelése érdekében.

Több domain alatt, aldomainek alatt, vagy alkönyvtár alatt érdemes az eltérő nyelvű tartalmakat megjeleníteni?

Ha a célországoknak van saját TLD-je, akkor SEO-szempontból legelőnyösebb az egyes országok domainkiterjeszését használni. Aldomainek használata a jelenlegi Google-algoritmus szerint nem jár semmilyen rangsorolási előnnyel. Ha közös domain alatt jelennek meg az eltérő nyelvű tartalmak, a könyvtárstruktúra (pl. /hu/, /en/, stb.) használata javasolt - ilyen esetben hacsak nem kiemelt prioritású valamely nyelv/célország, országsemleges top level domain (p. .com, .eu) használata célszerű.

Érdemes eltérő nyelvű oldalakat létrehozni, amíg nem áll rendelkezésre a teljes tartalom az adott nyelven?

Röviden: nem. Azon túl, hogy az idegen nyelvű felhasználók számára zavaró a kevert nyelvű, részlegesen fordított tartalom, az idegen nyelvű URL-ek alatt megjelenő lefordítatlan tartalom duplikációs problémát is okozhat. Ha mégis emellett a megoldás mellett döntünk, még az idegen nyelvű aloldalak publikálása (és indexelése) előtt tiltsuk le ezek feltérképezését a robots.txt fájlban, és ezt a tiltást csak az elkészült fordítások publikálása után oldjuk fel. Amennyiben már indexelésre kerültek a részlegesen lefordított tartalmak, a helyesen implementált hreflang kódok használata csökkentheti, de nem zárja ki biztosan a duplikáció negatív hatását az eredeti tartalomra nézve.

Mi a hreflang attributum?

A link HTML-tag hreflang attributumával jelölhető, hogy egy adott tartalom eltérő nyelvű (vagy azonos nyelvű, de eltérő országban élő) felhasználóknak szóló változatai mely URL-ek alatt érhetőek el. Fontos tudni, hogy a Google kizárólag akkor veszi figyelembe ezt a jelölést, ha az egyes oldalpárok (vagy több nyelv esetén oldalkészletek) kölcsönösen, oda-vissza tartalmazzák az egymásra történő hreflang hivatkozást! Értékként a nyelv (ISO 639-1, pl. hu, en, fr, stb.), vagy a nyelv és a régió (ISO 3166-1 Alpha 2, pl. en-uk, fr-ch, de-at, stb.) kódja együttesen adható meg. Önmagában az országkód megadása érvénytelen! X-default értékkel jelölhetjük azt az alapértelmezett URL-t, amelyet a készletben felsoroltaktól eltérő nyelvű/régiójú felhasználóknak szánunk.

Mi történik egy hreflanggal összekapcsolt URL törlésekor, vagy noindexre állításakor?

Vigyázat: ez a készletben szereplő többi URL Google-indexből való törlését eredményezheti! Ha tehát egy hreflang jelöléssel ellátott oldalt egy adott nyelven törölni szeretnénk, miközben azt szeretnénk, hogy más nyelveken továbbra is elérhető maradjon, a törlés előtt mindenképp szüntessük meg a törlendő URL-lel a hreflang kapcsolatot!

Szeretné valóban tapasztalt szakértőkre bízni weblapja teljeskörű keresőoptimalizálását?