Egyoldalas alkalmazás SEO: hogyan indexeltesd a SPA-t a Google-lel, és hogyan olvassa az AI

Az egyoldalas alkalmazás SEO azoknak a technikáknak az összessége, amelyek a React, a Vue, az Angular vagy a Svelte segítségével épített JavaScript-alkalmazást ugyanolyan könnyen feltérképezhetővé teszik, mint egy klasszikus weboldalt. A probléma jól dokumentált: a Google a JavaScript SEO alapjaiban elmagyarázza, hogy a JavaScriptes oldalakat három fázisban dolgozza fel (feltérképezés, renderelés, indexelés), és minden SPA-gyengeség valahol ebben a folyamatban van. Ez az útmutató az SPA-kra fókuszál; a JavaScript-oldalakról általában a JavaScript SEO útmutatónkban olvashatsz.

Mi az egyoldalas alkalmazás, és miért nehéz SEO szempontból?

A hagyományos weboldal minden URL-re egy teljes HTML-dokumentumot ad vissza. Egy SPA szinte ugyanazt a dokumentumot adja minden URL-re: egy üres <div id="root">-ot, néhány meta-címkét és egy nagy JavaScript-csomagot. A böngésző letölti a csomagot, meghív egy API-t, majd kirajzolja az oldalt. Amikor a látogató rákattint egy linkre, a JavaScript újratöltés nélkül cseréli ki a tartalmat.

Egy embernek, gyors telefonon, az eredmény azonnalinak érződik. Egy keresőrobot számára az első válasz egy üres váz: nincs címsor, nincs szöveg, nincs link. Minden azon múlik, hogy a robot végrehajtja-e a JavaScriptet, és ha igen, mikor. Ez az egyetlen tény megmagyarázza az SPA-SEO problémák nagy részét:

• Késleltetett vagy hiányzó tartalom: a szöveg csak a renderelés után létezik, amelyet a Google később végez el, más robotok pedig kihagynak.
• Egy URL sok nézetre: a régebbi SPA-k töredékekkel irányítanak (/#/pricing), a # utáni részt pedig soha nem küldik el a szervernek, így minden nézet egy URL-be esik össze.
• Azonos címek és leírások: a váz egyetlen <title>-t hordoz, és ha a router nem frissíti, minden oldal ugyanazt kapja.
• Linkek href nélkül: a gombok és az onClick kezelők a felhasználóknak navigálnak, de a robotoknak nincs mit követniük.
• Soft 404-es hibák: a szerver minden útvonalra 200-zal válaszol, a nem létező oldalakat is, így a hibanézetek vékony oldalakként indexelődnek.
• Nehéz JavaScript: a nagy csomagok lassítják az első megjelenítést és az interakciókat, ami rontja a Core Web Vitals mutatóit.

Hogyan térképezi fel és rendereli a Google az SPA-t?

A Googlebot először letölti a nyers HTML-t, és elolvassa az ott talált linkeket és utasításokat. A 200-as állapotú oldalak ezután a Web Rendering Service-ben várnak, amely egy fejnélküli Chromium. A Google szerint az oldal „akár néhány másodpercig is maradhat ebben a sorban, de ennél tovább is tarthat”. Miután renderelték, a kapott HTML-t újra feldolgozzák a tartalom és a linkek szempontjából, majd indexelik.

A Google dokumentációjából négy részlet fontos az SPA-k számára:

1. Csak a href-et tartalmazó <a> elemek megbízható linkek. A JavaScripttel beszúrt linkek rendben vannak, ha ezt a formátumot követik.
2. A töredékek nem különálló oldalak. A Google azt kéri, hogy a # útvonalak helyett a History API-t (pushState) használd. A régi AJAX-feltérképezési sémáját (a #! URL-eket) 2015 októberében elavultnak nyilvánította.
3. Az eredeti HTML-ben lévő noindex nyer. A Google a noindex láttán kihagyhatja a renderelést, így a későbbi eltávolítása JavaScripttel nem működik.
4. A renderelés gyorsítótárazott fájlokat használ. A Googlebot erősen gyorsítótárazza a JavaScriptet és a CSS-t, ezért használj ujjlenyomatos fájlneveket (tartalomhash a fájlnévben), hogy elkerüld az elavult csomagokat.

A gyakorlati következmény: a Google indexelhet egy kliensoldalon renderelt SPA-t, de minden oldalhoz hozzáadsz egy második lépést, egy késleltetést és egy hibapontot. Egy időtúllépés, egy blokkolt API-hívás vagy egy JavaScript-hiba a renderelés során üresen hagyja az indexelt változatot. Ellenőrizd, mit lát a Google a Search Console URL-vizsgálati eszközével, és ha az oldalak kimaradnak az indexből, olvasd el a Google indexelés működéséről szóló útmutatónkat.

Olvassa a ChatGPT, a Claude és a Perplexity a JavaScriptet?

Többnyire nem. A Vercel és a MERJ 2024 decemberében közzétett, a hálózatuk forgalmára épülő tanulmányában azt találta, hogy „a főbb AI-keresőrobotok egyike sem renderel jelenleg JavaScriptet”: a GPTBot, az OAI-SearchBot és a ChatGPT-User (OpenAI), a ClaudeBot (Anthropic), a PerplexityBot, a Meta-ExternalAgent és a Bytespider mind csak a nyers HTML-t olvassa. A JavaScript-fájlokat letöltik (a ChatGPT kéréseinek nagyjából 11,5%-a és a Claude-éinak 23,8%-a), de nem futtatják őket. Kivétel a Gemini, amely a Google renderelési infrastruktúráját használja, és az AppleBot, amely böngészőalapú keresőrobotot használ.

Egy kliensoldalon renderelt SPA esetén ez azt jelenti, hogy a ChatGPT-t, a Claude-ot és a Perplexityt tápláló AI-keresőrobotok egy üres oldalt látnak. A termékedet a Google rangsorolhatja, mégis láthatatlan lehet az AI-válaszokban, mert az asszisztens egyetlen szavát sem olvasta. Ugyanez igaz a közösségi hálózatok és üzenetküldő appok linkelőhelyes robotjaira is, amelyek a nyers HTML-ben lévő Open Graph címkéket olvassák. Amint a tartalom bekerült a HTML-be, ellenőrizd azt is, hogy a robots.txt engedélyezi-e a kívánt AI-keresőrobotokat.

Melyik renderelési stratégiát használjon egy SPA?

A megoldás az, hogy az első válaszban valódi HTML érkezzen. A Google a dinamikus renderelés dokumentációjában a dinamikus renderelést (amelyben csak a robotok kapnak előrenderelt pillanatképet) „megkerülő megoldásnak, és nem ajánlott megoldásnak” nevezi, és helyette a szerveroldali renderelést, a statikus renderelést vagy a hidratálást javasolja. Az alábbi meghatározások a web.dev Rendering on the Web anyagát követik.

A legtöbb modern keretrendszer útvonalanként keverhető stratégiákat tesz lehetővé: statikus a marketingoldalakhoz, szerveroldalian renderelt a katalógushoz, kliensoldalon renderelt a bejelentkezett alkalmazáshoz. Ez a hibrid felépítés teljes HTML-t ad a keresőrobotoknak ott, ahol a keresési forgalom van, és megtartja az SPA-élményt, ahol az értéket ad.

Keretrendszer-lehetőségek

Külön említést érdemelnek az AI-webhelyépítők által generált oldalak: sokan kliensoldalon renderelt React-alkalmazást exportálnak. Ha ilyennel építettél oldalt, a Lovable SEO és GEO jegyzeteinket nézd meg, mielőtt feltételeznéd, hogy a Google és a ChatGPT olvassa.

SPA-SEO ellenőrzőlista: mit javíts útvonalanként

1. Adj minden nézetnek tiszta, feltérképezhető URL-t

Használd a History API-t (/pricing, soha ne /#/pricing), tartalmanként egy URL-t, és ugyanazt az URL-t, akár közvetlenül érkezik a látogató, akár az alkalmazáson belüli navigációval. Minden URL-nek a megfelelő tartalmat kell betöltenie, ha új lapon nyitják meg, ez az a teszt, amelyet a robot elvégez.

2. Használj valódi linkeket

Minden olyan navigációs elem, amely indexelhető oldalra vezet, legyen <a href="/path">. A keretrendszer linkkomponensei (Link, NuxtLink, routerLink) ezt a jelölést adják ki; a div vagy button elemekre épített egyedi kattintáskezelők nem. A jó linkek a webhely-architektúrádat is hordozzák: ha egy oldal nincs linkelve, a robotok ritkán találják meg.

3. Frissítsd a címet, a leírást és a kanonikus címkét útvonalanként

Minden útvonalnak saját címe, meta leírása, kanonikus címkéje és Open Graph címkéi legyenek, lehetőleg szerveroldalon generálva. A meta-címkékről szóló oldalunk felsorolja, mit kell beállítani. Tarts meg egyetlen kanonikus címkét: a Google azt javasolja, hogy a HTML-ben állítsd be, és ha a JavaScript megváltoztatja, az eredmény nem mondhat ellent az eredetinek.

4. Adj őszinte állapotkódokat

A hiányzó termékek és a törölt cikkek ne adjanak 200-as választ hibaüzenettel. Szerveroldali renderelésnél a szerver adjon valódi 404-et vagy 410-et. Tiszta SPA-ban a Google két tartalék megoldást fogad el: JavaScripttel átirányítani egy olyan URL-re, amely 404-et ad, vagy egy noindex robots meta-címkét tenni a hibanézetre.

5. A fő tartalom és a strukturált adatok legyenek a HTML-ben

A címsorok, a főszöveg, az árak, a GYIK és a JSON-LD strukturált adatok legyenek a szerver válaszában, ne kattintás vagy görgetés után töltődjenek be. Az igény szerint renderelt füleken, illetve a „további betöltése” gombok mögött lévő tartalmat gyakran kihagyják.

6. Tartsd könnyűn a JavaScriptet

Bontsd a csomagot útvonalanként, halaszd el azt, ami az első nézethez nem kell, és kerüld az egész oldal újrarenderelését a hidratálás során. Vedd figyelembe, hogy a Chrome terepi adatai (CrUX) az alkalmazáson belüli navigációk mutatóit annak az URL-nek tulajdonítják, amelyet a látogató először betöltött, ezért a kulcsfontosságú sablonjaidat külön-külön teszteld.

7. Teszteld, mit kapnak a robotok

Hasonlíts össze három változatot minden kulcsfontosságú sablonból: a nyers HTML-t (a forrás megtekintésével vagy egy parancssori eszközzel letöltve az oldalt), a Google renderelt HTML-jét (URL-vizsgálat, majd „Feltérképezett oldal megtekintése”), és az oldalt JavaScript nélkül. Ha a fő szöveg csak a második változatban jelenik meg, az AI-keresőrobotok nem látják. Ingyenes AI-feltérképezhetőségi auditunk és az indexelhetőség-ellenőrzőnk bármely URL-en lefuttatja ezeket az ellenőrzéseket.

Honnan tudod, hogy az SPA-d SEO-problémával küzd?

SPA-SEO és GEO: megtalálhatóság a Google-on és idézés az AI-tól

Évekig a kliensoldali renderelés kezelhető kockázat volt, mert a Google végül renderelte a JavaScriptet. Most, hogy a felfedezés egy része a ChatGPT-ben, a Claude-ban, a Geminiben és a Perplexityben zajlik, megváltozott az ár: az az oldal, amely csak a JavaScript futtatása után létezik, hiányzik azokból a forrásokból, amelyeket a legtöbb asszisztens olvasni tud. A feltérképezhetőség a nyers HTML-ben a generatív keresőoptimalizálás első feltételévé vált.

Amint a HTML teljes, a többi a megszokott szabályokat követi: azok az oldalak, amelyek egy kérdésre világosan válaszolnak, forrásolt tényekkel és strukturált adatokkal, azok, amelyeket az asszisztensek idéznek. A Sorank GEO-optimalizálási funkciói segítenek ezt a tartalmat megírni és közzétenni, az AI-említéskövetés pedig megmutatja, hogy a renderelési javítás után idézi-e a ChatGPT, a Claude és a Gemini a márkádat.

Az egyoldalas alkalmazás SEO kulcsszabálya egy mondatba fér: mindennek, amit azt szeretnéd, hogy a Google rangsoroljon és az AI idézzen, benne kell lennie a szerver által küldött HTML-ben. Tartsd meg az SPA-t a bejelentkezett élményhez, a nyilvános oldalakat pedig rendereld szerveroldalon vagy építéskor, aztán minden kiadás előtt és után teszteld, mit kapnak a robotok.