UX és SEO: Hogyan tedd a SEO-t a legjobb barátoddá UX-esként?
A keresőoptimalizálást (SEO-t) jellemzően 3 nagy részre szokták osztani. Ezek közé tartozik a tartalmi-, a technikai SEO és a linképítés / online PR. A technikai SEO évekig nagyon fontos eleme volt a jó organikus pozíció elérésének. Ha jól volt az összerakva, az már fél sikernek jelentett. Ez főleg az 1990-es évekre és a 2000-es évek elejére volt igaz. Aztán valami megváltozott. Papp Gábor vendégcikke.
Aztán ahogy elkezdett egyre több előre gyártott CMS megjelenni, sokak számára úgy szorult háttérbe a weboldal kódjának technikai megfelelősége. Sokan úgy voltak vele, hogyha felraknak egy sima WordPress mondjuk, akkor a weboldal technikai részei kb kész is vannak. Ebben van egyébként igazság. De legalább ennyi veszély is rejtőzik benne.
Attól még, hogy maga a CMS “SEO barát” (SEO friendly) címkét kap még nem jelenti azt, hogy az adott template, vagy custom kód is az lesz, amit használsz. A legtöbb designer nem ért mélyen a SEO-hoz, ahogy a legtöbb fejlesztő sem. Ezért gyakran előfordul, hogy olyan hibákat vétenek egy-egy template kódolásakor, ami végzetes lehet SEO oldalról. És ez megjelenik a különböző UX megoldásoknál is.
Egy ügyfél jellemzően azért tervez egy új weboldalt, hogy:
- Szebb legyen az oldala
- Funkcionálisabb legyen (például mobilon)
- Többen látogassák
- Jobb konverziót érjen el vele.
Vagyis lehetőség szerint legyen jobb, mint a korábbi verzió. És itt szokott előjönni az, hogy főként a mobilos megoldások során több olyan UX tanács is érkezik akár az ügyfél, akár az ügynökség, fejlesztő részéről, ami teljesen logikusnak hangzik. De cserébe képes tönkretenni az oldal organikus forgalmát. Itt van néhány klasszikus hiba, amit UX oldalról sokan elkövetnek.
Belső kereső okozta problémák
Gyakran előfordul, hogy egy weboldalon van egy kereső, aminek segítségével különböző tartalmakat lehet megtalálni. Ez önmagában remek. De ennek a UX és technikai implementációja már egyáltalán nem mindegy. Ha ugyanis a kereső által visszaadott egyes tartalmak nem érhetőek el egyedi URL-en, vagy azt esetleg javascript rendereli csak, akkor az bizony nem lesz látható a Google számára.
Ez látható a money.hu oldalon (amit sokan Bankrációként ismerhetsz korábbról).
Az oldalon található egy Fogalomtár, ahol az adott fogalmat a keresőbe kell beírni. Ha ide beírom azt, hogy “pénz”, akkor az alábbi találatok jönnek fel:
Itt a “Lakás-takarékpénztári hozam” kifejezésre kattintva megjelenik az ide írt tartalom:
A gond csak az, hogy ez csak keresésre és kattintásra elérhető. Ráadásul az egész tartalom pontosan ugyanazon az URL-en tölt be mint a kiinduló állapot.
Bár a Google-nek megvan a technológiája arra, hogy ezeket a tartalmakat felfedezze és crawlolja, ezt sokszor mégsem teszi. Egészen egyszerűen azért, mert ennek a kivitelezése 20x annyi erőforrást igényel, mint egy sima html kód ellenőrzése.
A Google azért nem látja a fenti tartalmat, mert formázási hiba van a forráskódban. Így bár az egyedi URL-ek mégis léteznek, de azok nem szerepelnek a sitemapben. És nincs megfelelő belső linkelési struktúra sem.
Így simán találhatunk olyan URL-eket, amikre:
- nem mutat se belső link
- és nincsenek benne a sitemapben sem.
Így azt történik, hogy ezeknek a tartalmaknak a felfedezése vagy nem tud megvalósulni, vagy csak esetlegesen. Ezt pedig mindenképp el akarjuk kerülni.
Ez persze nem jelenti azt, hogy a fenti kereső működési elve jó lenne SEO oldalról. A bonyolultabb megoldások helyett már az is elég lehetne, ha a keresés során az egyes tartalmak kattinthatóak lennének a keresési találatokból.
Accordion-ok
Mobilon gyakori megoldás, hogy legördülő menüket alkalmaznak sokan, mert egyszerűen nem lehet extra hosszú szövegeket felrakni egy oldalra. Ugyanis senki nem fogja elolvasni. De ezzel is érdemes óvatosan bánni.
A fenti problémához hasonló helyzetbe lehet belefutni. Itt egy konkrét példa:
- A fogalomtárba (Glossary) tartalom ugyanazon az egy url-en található
- Így az adott tartamaknak nincs egyedi URL-je
- Pontosabban van, de az meg a keresőt hozza be
- Ahol hibásan van implementálva a rel canonical tag
De nézzük meg ezt a gyakorlatban először is, hogy mit jelent. Ha rákattintok bármelyik accordion elemre, akkor szép vizuális effekttel lenyílik az adott rész és el tudom olvasni az oda tartozó tartalmat. Mobolion ez a UX interakció teljes érthető is. Desktopon talán kevesebb szükség van rá. A problémát az okozza, hogy az összes tartalom egy URL-en érhető el.
Ez miért gond? Mert így ezeknek a tartalmaknak nincs egyedi azonosítója. Se egy egyedi URL, se egy anchored URL ezen a pagen belül.
Ez önmagában azért gond, mert a weboldal korábbi verziója bár vizuálisan kevésbé volt esztétikus, ott mégis helyesen voltak az URL-ek és a tartalmak kezelve.
Ezt jól lehet látni az Archive.org screenshotján:
És míg a régi verzió hozott organikus forgalmat, addig az új nem. Az alábbi grafikonon jól meg lehet tippelni, hogy mikor történt a domain migrációja. Ahol beesett az organikus forgalom. Egyik hónapról a másikra eltűnt az organikus forgalom több mint fele.
És ennek mi volt az oka? Pontosan, a fenti accordion bevezetése. UX oldalról jónak tűnt a döntés. A technikai implementáció viszont nem sikerült tökéletesen SEO oldalról.
Az URL-ek bontására egy jó megoldás például, amit ennél a fogászatnál lehet látni.
Ezen az URL-en elérhető az összes kérdés egyben. De minden egyes kérdésnek van egyedi URL-je:
A helyes technikai implementáció után pedig el is kezdett az organikus forgalom növekedni.
Dinamikusan generált tartalom
Egy másik hasonló hiba, amikor egy oldalon a tartalom valamilyen user interakcióra generálódik csak le. Erre jó példa nagyon sok kalkulátor vagy generátor. Itt a gyakorlatban egy lottószám generátort látunk.
Itt a gond az, hogy a zöld doboz alatt megjelenő tartalom nem található meg az oldal forráskódjában. Csak akkor generálódik le, amikor rákattintunk a “lottószám generálás” gombra.
Mivel egy csak kliens oldalon kerül renderelésre, ezért ezt a Googlebot bizony nem látja. Itt megoldás lehetne az, hogy a tartalmat CSS-sel hide-olja az oldal, egészen addig amíg a gombra nem kattint a user. Nem a legelegánsabb megoldás, de SEO oldalról jobb lenne.
Sokáig tartotta magát a mondás, hogy mobilon például nem lehet elrejteni CSS-sel sem semmit, mert akkor a Google ezt nem látja. Ez ebben a formában nem igaz. De az igen, hogy a CSS-sel történő hide-olás egy oldal esetében jobb megoldás, mintha Javascript renderelné az egészet. Ezt néhány hete John Mueller is megerősítette egy Google Webmester Hangout-ban.
A gyakorlatban tehát nem arról van szó, hogy mobilon és desktopon más-más tartalmat kéne adni. Hanem arról, hogy ezek párban mozognak. Egy olyan megoldás, ami mobilon jónak tűnik, az lehet nagyon jó desktopon is.
De azért, hogy egy-egy szépnek és hasznosnak tűnő UX megoldás vagy interakció ne okozzon konkrétan kárt, ahhoz érdemes egy SEO-ban is jártas személy véleményét kikérni. Ez főleg ott lehet kifejezetten hasznos, amikor egy már létező oldalt kell újraépíteni, aminek van organikus forgalma. Mert a fenti példák jól mutatják, hogy egy-egy apróságnak tűnő (és alapvetően jó szándékú) megoldással is mekkora károkat lehet okozni.
Papp Gábor
Online marketing és SEO szakember, a The Pitch alapítója. Szakterülete a keresőoptimalizálás és az üzleti modellek. Ügyfelei között van több hazai és külföldi multinacionális vállalat, technológiai cégek, de dolgozik együtt New York Times Bestseller íróval is.