JavaScript SEO: teljes útmutató

A JavaScript SEO a technikai SEO azon területe, amely azt biztosítja, hogy a JavaScripttel épített vagy JavaScripttel kiegészített oldalak tartalmát, linkjeit és jelzéseit a keresők feltérképezni, megjeleníteni és indexelni tudják. A kulcskérdés, hogy a lényegi tartalom mikor és hogyan kerül a HTML-be: már a szerver válaszában, vagy csak a böngészőben futó szkriptek után.

Alapfogalmak

A modern weboldalak jelentős része JavaScriptre épül. Van, ahol a szkript csak kiegészít: egy lenyíló menüt, egy képgalériát vagy egy űrlap-ellenőrzést működtet. Van, ahol viszont az egész oldal a szkriptből áll össze, és a szerver csak egy szinte üres HTML-vázat küld, amelyet a böngésző tölt meg tartalommal. A keresők szempontjából a két helyzet nagyon különböző. Az első esetben a tartalom már a kiinduló HTML-ben ott van, a másodikban csak a szkriptek lefutása után jelenik meg.

A JavaScript SEO célja nem az, hogy a JavaScriptet kerülje, hanem hogy a keresők ugyanazt lássák, amit a látogató. Ez három dolgon múlik: a kereső hozzáfér-e a szükséges fájlokhoz, le tudja-e futtatni a kódot, és a lefutás eredményeként kialakuló oldalon megvan-e minden, ami az indexeléshez kell, vagyis a szöveg, a linkek, a címek, a meta adatok és a strukturált adatok.

A legfontosabb fogalmak

Fogalom	Jelentés
Kiinduló HTML	A szerver által küldött válasz, még a szkriptek lefutása előtt
Renderelt HTML	Az oldal állapota a szkriptek lefutása után, ahogy a böngésző felépíti
Renderelés	A kód lefuttatása és az oldal megjelenítése, a kereső oldalán is
Kliensoldali renderelés	A tartalmat a böngészőben futó JavaScript állítja elő
Szerveroldali renderelés	A szerver kész HTML-t küld, a szkript utána veszi át az irányítást
Statikus generálás	A HTML előre, a közzétételkor készül el, és fájlként szolgálják ki
Hidratálás	A szerveren előállított HTML-hez a böngésző hozzárendeli a szkriptek működését

Miért külön terület?

Egy hagyományos, szerveren előállított oldalnál a kereső a lekéréssel már mindent megkap. JavaScript esetén a folyamat egy lépéssel hosszabb, és ez a plusz lépés hibalehetőségeket hordoz. A szkript letöltése meghiúsulhat, a kód hibára futhat, a tartalom egy olyan interakcióhoz köthető, amelyet a robot nem végez el, vagy a szkript egy olyan adatforrást hív, amely a robot számára nem érhető el. Ezeket a hibákat a látogató gyakran nem is látja, mert az ő böngészőjében minden működik.

Progresszív fejlesztés mint alapelv

A JavaScript SEO egyik legrégebbi és ma is érvényes alapelve a progresszív fejlesztés. Eszerint az oldal alapja egy önmagában is használható HTML, amely tartalmazza a szöveget, a linkeket és a navigációt, a JavaScript pedig erre épít rá kényelmi és interaktív funkciókat. Ha a szkript valamiért nem fut le, az oldal akkor is olvasható és bejárható marad. Ez nemcsak a keresőknek jó, hanem a lassú kapcsolaton vagy régebbi eszközön böngésző látogatóknak, valamint a segítő technológiákat használóknak is. Az alapelv nem tiltja az összetett alkalmazásokat, csak azt kéri, hogy a keresésből elérendő tartalom ne függjön kizárólag a szkripttől.

Hogyan működik?

A Google a saját dokumentációja szerint a JavaScripttel épített oldalakat három fő szakaszban dolgozza fel: feltérképezés, renderelés és indexelés. A feltérképezéskor a Googlebot lekéri az URL-t, és megkapja a kiinduló HTML-t. Ha a robots.txt engedi, a kiinduló HTML-ből ki tudja nyerni az ott szereplő linkeket, és azokat is sorba állítja. Ezután az oldal a renderelési sorba kerül.

A renderelést a Google egy rendszeresen frissített Chromium alapú motorral végzi. Ez lefuttatja a JavaScriptet, lekéri a szükséges erőforrásokat, és felépíti az oldalt, ahogy egy böngésző tenné. A renderelt HTML-ből a Google újra kinyeri a linkeket, és ezt használja az indexeléshez. A renderelés nem mindig azonnal történik meg a lekérés után: az oldal a sorban várakozhat, amíg a szükséges erőforrások rendelkezésre állnak.

Miben más a robot, mint egy látogató?

Nem kattint és nem gépel. Ami csak egy gombnyomásra, egy fül kinyitására vagy egy keresés elküldésére jelenik meg, azt a robot jó eséllyel nem látja.
Nem őriz állapotot. A Google leírása szerint a sütiket, a helyi és a munkamenet-tárolót oldalbetöltések között nem tartja meg, ezért minden oldalt úgy lát, mint egy első látogató.
Elutasítja az engedélykéréseket. Ha a tartalom például helymeghatározási engedélytől függ, a robot nem kapja meg.
A linkeket az <a href> elemekből gyűjti. A csak eseménykezelővel működő, href nélküli elemeket nem követi linkként.

A kiinduló HTML jelzései korán számítanak

Néhány jelzést a Google már a kiinduló HTML-ből kiolvas, és ezek befolyásolják a további feldolgozást. A legfontosabb a noindex. A Google leírása szerint ha a kiinduló HTML-ben noindex szerepel, a renderelés el is maradhat, így hiába távolítja el később a JavaScript, az oldal nem kerül indexbe. A meta robots és a canonical jelzéseket ezért a legbiztosabb már a szerver válaszában helyesen megadni, és nem szkripttel módosítani.

Más keresők és robotok

Nem minden robot futtat JavaScriptet. Egyes keresők és más feldolgozó rendszerek, például a közösségi oldalak előnézet-készítői, jellemzően csak a kiinduló HTML-t olvassák. Ha egy oldal címe, leírása vagy megosztási képe csak szkripttel kerül be, ezekben a környezetekben hiányozhat. Ez önmagában is erős érv amellett, hogy a lényegi tartalom és a meta adatok a kiinduló HTML-ben legyenek.

Fő módszerek

A JavaScript SEO legfontosabb döntése a renderelési stratégia megválasztása. Ez határozza meg, hogy a tartalom a kiinduló HTML-ben van-e, vagy csak a szkriptek után jelenik meg. A döntés a tartalom típusától, a frissülés gyakoriságától és a technikai környezettől függ.

A renderelési stratégiák összevetése

Stratégia	A tartalom a kiinduló HTML-ben?	Mikor jó választás
Statikus generálás	Igen	Ritkán változó tartalom: cikkek, dokumentáció, szolgáltatásoldalak
Szerveroldali renderelés	Igen	Gyakran változó, keresésből érkező forgalmat célzó oldalak
Kliensoldali renderelés	Nem	Bejelentkezés mögötti alkalmazásrészek, amelyeknek nem kell a keresőben megjelenni
Dinamikus renderelés	Csak a robotoknak	Átmeneti megoldás, amikor a renderelés nem alakítható át gyorsan

1. A tartalom legyen a kiinduló HTML-ben

A legbiztosabb út, hogy a keresésből forgalmat célzó oldalak lényegi tartalma, címe, leírása és belső linkjei a szerver válaszában szerepeljenek. Ezt statikus generálással vagy szerveroldali rendereléssel lehet elérni. A JavaScript ezután is hozzáadhat interaktív működést, de a kereső nem függ tőle.

2. Valódi linkek és valódi URL-ek

Minden olyan nézetnek, amelyet a keresőben is meg akarsz jeleníteni, saját, közvetlenül lekérhető URL kell. A navigáció <a href="/utvonal/"> formájú linkekkel történjen, és ne kettőskereszt utáni részekkel, mert a Google a kettőskereszt utáni részt nem kezeli külön oldalként. Az egyoldalas alkalmazások a History API-val tudnak valódi URL-eket kezelni.

3. Hozzáférhető erőforrások

A renderelés csak akkor sikerül, ha a robot letöltheti a szkripteket, a stíluslapokat és azokat az adatvégpontokat, amelyekből a tartalom érkezik. Ha ezek a robots.txt fájlban tiltva vannak, a Google hiányos oldalt lát.

4. Helyes státuszkódok

Az egyoldalas alkalmazásoknál gyakori, hogy a szerver minden címre 200-as kóddal válaszol, és a nem létező oldalt csak a szkript jeleníti meg hibaüzenetként. A kereső ezt soft 404-ként érzékelheti. A Google javaslata szerint ilyenkor vagy egy valódi 404-et adó URL-re kell átirányítani, vagy noindexet kell az oldalra tenni.

Döntési szabály

Az oldalnak keresésből kell forgalmat hoznia? Ha igen, a tartalom legyen a kiinduló HTML-ben.
Ritkán változik a tartalom? Statikus generálás.
Gyakran változik, vagy kérésenként eltér? Szerveroldali renderelés.
Bejelentkezés mögött van, vagy nem kell a keresőbe? A kliensoldali renderelés elfogadható.
A régi rendszer nem alakítható át rövid távon? Átmenetileg dinamikus renderelés, a végleges megoldás tervezése mellett.

Kidolgozott példa: webáruház kategóriaoldalai

Egy webáruház kategóriaoldalai kliensoldali rendereléssel működtek: a szerver egy üres vázat küldött, a termékek listáját a böngészőben futó szkript kérte le egy belső adatvégpontról. A Search Console URL-ellenőrzőjében a renderelt HTML-ben megjelentek a termékek, de az adatvégpont a robots.txt-ben tiltott útvonal alatt volt, így a renderelt nézet időnként üres listát mutatott. A csapat két lépésben javított. Először engedélyezte az adatvégpont lekérését. Ezután a kategóriaoldalakat szerveroldali renderelésre állította át, így a terméklista, a kategória leírása és a lapozó linkjei már a kiinduló HTML-ben szerepeltek. A szűrők továbbra is kliensoldalon működtek, mert a szűrt nézeteket nem akarták indexeltetni.

Gyakori hibák

A JavaScript SEO hibái közös tulajdonsága, hogy a böngészőben minden rendben lévőnek tűnik. A látogató látja a tartalmat, kattint a linkekre, minden működik. A hiba csak akkor derül ki, ha valaki a kereső szemével nézi az oldalt: a kiinduló HTML-t, a renderelt HTML-t és azt, hogy mi került az indexbe.

Tipikus hibák

Linkek href nélkül. Ha a navigáció egy kattintási eseményre épül, és nincs valódi href, a robot nem követi a linket, és a mögötte lévő oldalak felfedezése nehezebb.
Kettőskeresztes útvonalak. Ha minden nézet ugyanazon az URL-en, csak a kettőskereszt utáni résszel különbözik, a kereső egyetlen oldalnak látja.
Tiltott szkriptek és adatvégpontok. A robots.txt-ben tiltott erőforrások miatt a renderelt oldal hiányos.
Szkripttel eltávolított noindex. Ha a kiinduló HTML-ben noindex van, a renderelés elmaradhat, így a szkript hiába törli.
Interakcióhoz kötött tartalom. A csak kattintásra betöltődő szöveg vagy lista a robot számára nem létezik.
Mindenre 200-as válasz. A nem létező oldalak soft 404-ként jelennek meg.
Eltérő cím és canonical a két állapotban. Ha a kiinduló HTML-ben más a cím vagy a canonical, mint a renderelt változatban, a kereső vegyes jelzést kap.

Tévhit: a Google nem látja a JavaScriptet

Ez régen közkeletű vélekedés volt, de a Google ma rendereli a JavaScriptet, és a renderelt tartalmat indexeli. A probléma nem az, hogy a JavaScript láthatatlan, hanem hogy a renderelés további lépés, amelyben több dolog elromolhat, és amely nem mindig azonnal történik meg. A JavaScript SEO célja ezeknek a kockázatoknak a csökkentése, nem a JavaScript kiiktatása.

Ellenpélda: a dinamikus renderelés csapdája

Egy portál a robotoknak előre renderelt HTML-t szolgált ki, a látogatóknak pedig kliensoldali alkalmazást. Idővel az előrenderelő szolgáltatás gyorsítótára elavult: a robotok napokkal korábbi tartalmat kaptak, és néhány oldalon hibaüzenetet. A csapat csak akkor vette észre, amikor az URL-ellenőrzőben a renderelt oldal eltért a böngészőben látottól. A Google a dinamikus renderelést maga is kerülőmegoldásként írja le, nem hosszú távú javaslatként. A portál végül szerveroldali renderelésre váltott, így egyetlen változat maradt, amelyet mindenki ugyanúgy lát.

Tévhit: ha a böngészőben működik, a keresőben is működik

A böngésző és a robot más feltételekkel dolgozik. A böngészőben megmaradnak a sütik, a felhasználó kattint, görget, engedélyeket ad. A robot mindezt nem teszi. Egy oldal, amely a böngészőben hibátlan, a robot számára lehet hiányos, ezért a tesztelést mindig a kereső eszközeivel is el kell végezni.

Mérés

A JavaScript SEO mérése az összehasonlításról szól: mi van a kiinduló HTML-ben, mi van a renderelt HTML-ben, és mi került az indexbe. Ha a három között eltérés van, ott érdemes keresni a hibát.

Search Console URL-ellenőrző

A Search Console URL-ellenőrző eszköze a legfontosabb forrás. Az élő URL tesztelésével látható a Google által renderelt HTML, egy képernyőkép az oldalról, a betöltött erőforrások listája, és ha valamelyik nem tölthető be, annak oka is. A JavaScript-konzol üzenetei is megjelennek, így a szkripthibák azonosíthatók. Érdemes ellenőrizni, hogy a renderelt HTML-ben ott van-e a lényegi szöveg, a belső linkek, a cím, a meta leírás, a canonical és a strukturált adat.

A kiinduló HTML vizsgálata

A böngészőben a forráskód megtekintése a kiinduló HTML-t mutatja, a fejlesztői eszközök elemvizsgálója pedig a renderelt állapotot. A két nézet összevetése gyorsan megmutatja, mi érkezik a szerverről és mi a szkriptből. Egy parancssori lekérés, például curl, szintén a kiinduló HTML-t adja vissza, és segít megérteni, mit látnak azok a robotok, amelyek nem futtatnak JavaScriptet.

Feltérképező eszközök renderelési módban

A nagyobb SEO-feltérképező programok képesek JavaScript renderelésre. Egy renderelt és egy renderelés nélküli feltérképezés összevetése webhelyszinten mutatja meg, mely oldalakon hiányoznak linkek, címek vagy szövegek a kiinduló HTML-ből. Ez különösen hasznos, ha a hiba nem egy oldalt, hanem egy teljes sablont érint.

Ellenőrzőlista

Ellenőrzés	Hol nézed	Jó jel
Renderelt tartalom	URL-ellenőrző, élő teszt	A lényegi szöveg megjelenik a renderelt HTML-ben
Linkek	Renderelt HTML, feltérképező eszköz	Valódi a href elemek, valódi URL-ekkel
Erőforrások	URL-ellenőrző, robots.txt	Nincs tiltott szkript vagy adatvégpont
Meta jelzések	Kiinduló és renderelt HTML	Cím, canonical, robots egyezik a két állapotban
Státuszkódok	Nem létező URL lekérése	404 vagy noindex, nem 200-as üres oldal
Indexelés	Oldal-indexelési jelentés	A fontos sablonok oldalai indexelve vannak

Kidolgozott példa: sablonszintű hiba felderítése

Egy szakmai portál cikkeinek egy része lassan indexelődött. A renderelés nélküli feltérképezés megmutatta, hogy a cikkoldalak kiinduló HTML-jében a kapcsolódó cikkek blokkja és a kategórialinkek hiányoznak, mert ezeket egy szkript töltötte be. A renderelt feltérképezésben megvoltak, de a cikkek egy részéhez csak ezeken a linkeken át lehetett eljutni. A csapat a kapcsolódó cikkek blokkját a szerveroldali sablonba tette át. Ezután a kiinduló és a renderelt feltérképezés linkszáma közel azonos lett, és a Search Console oldal-indexelési jelentésében a felfedezett, de még nem indexelt cikkek száma fokozatosan csökkent.