A JavaScript megértése és annak potenciális hatása a keresési teljesítményre a modern SEO szakember egyik legfontosabb készsége. Ha a keresőmotorok nem tudnak feltérképezni egy webhelyet, vagy nem tudják megérteni és megérteni a tartalmat, semmit nem fognak indexelni, és a webhely nem fog rangsorolni. A JavaScripthez kapcsolódó legfontosabb kérdések: Lehet, hogy a keresőmotorok megtekintik a tartalmat és megragadják a weboldal élményét? Ha nem, milyen megoldásokat lehet kihasználni a probléma megoldásához? alapjai Mi a JavaScript? Modern weblap létrehozásakor három fő összetevő található: HTML – A Hypertext Markup Language a gerince vagy a tartalom szervezője a webhelyen. A weboldal szerkezete (például címsorok, bekezdések, listaelemek stb.) És a statikus tartalom meghatározása.
CSS – A Cascading Style Sheets a weboldalon megjelenő design, glitz, glam és stílus. Ez teszi ki az oldal megjelenítési réteget.
JavaScript – A JavaScript az interaktivitás és a dinamikus web magkomponense.
Tudj meg többet Weboldal fejlesztés És hogyan kell kódolni az alapokat JavaScript .
Kép források: 1 , 2 , 3
A JavaScript vagy a HTML dokumentumba kerül JavaScript könyvtárak és keretek: Mi az AJAX? Az AJAX vagy az aszinkron JavaScript és XML egy olyan webes fejlesztési technikák egy csoportja, amelyek ötvözik a JavaScriptet és az XML-t, amely lehetővé teszi a webes alkalmazások számára, hogy a háttérben lévő kiszolgálóval kommunikáljanak anélkül, hogy zavarják az aktuális oldalt. Az aszinkron azt jelenti, hogy más funkciók vagy kódsorok futtathatók a aszinkron Parancsfájl fut. Az XML az elsődleges nyelv volt az adatok átadásához; Az AJAX kifejezést azonban mindenféle adatátvitelre használják (beleértve a JSON-t is, úgy gondolom, hogy az “AJAJ” nem tűnik olyan tisztanek, mint az “AJAX”. Az AJAX gyakori használata a weboldal tartalmának vagy elrendezésének frissítése, anélkül, hogy teljes oldalfrissítést kezdeményezne. Általában, ha egy oldal betöltődik, az oldalon lévő valamennyi elemet fel kell kérni és fel kell kérni a kiszolgálóról, majd az oldalon megjelenik. Az AJAX-szal azonban csak azokat az eszközöket kell betölteni, amelyek különböznek az oldalak között, ami javítja a felhasználói élményt, mivel nem kell frissíteni az egész oldalt. Az AJAX miniszteri hívásokra gondolhat. Az AJAX jó példája a Google Térkép. Az oldal frissítése teljes oldali újratöltés nélkül történik (azaz a mini szerver hívásokat használják a tartalom betöltésére, ahogy a felhasználó navigál). Kép forrás
Mi a dokumentumobjektum-modell (DOM)? SEO szakemberként meg kell értened, hogy mi a DOM, mert a Google a weboldalak elemzésére és megértésére használja. A DOM az, amit látsz, ha a “Elem ellenőrzése” egy böngészőben. Egyszerűen fogalmazva, úgy gondolhatja a DOM-ot, mint a böngésző lépéseit, miután megkapta a HTML-dokumentumot az oldal megjelenítéséhez. A böngésző első dologja a HTML dokumentum. Ezt követően elkezdi feldolgozni a dokumentumon belüli tartalmat, és további forrásokat, például képeket, CSS-t és JavaScript fájlokat keres. A DOM az információ és erőforrások elemzéséből adódik. A weblap kódjának strukturált, szervezett változatára gondolhatunk. Napjainkban a DOM gyakran különbözik a kezdeti HTML-dokumentumtól, mivel a közösen hívják Dinamikus HTML . A dinamikus HTML az a képesség, hogy egy oldal megváltoztassa tartalmát a felhasználói bevitel, a környezeti feltételek (például a napi idő) és más változók függvényében, a HTML, a CSS és a JavaScript használatával. Egyszerű példa a Tag, amely a JavaScripten keresztül települ:
HTML forrás

DOM

Mi a fej nélküli böngészés? A fej nélküli böngészés egyszerűen a weboldalak lekérdezése a felhasználói felület nélkül. Fontos megérteni, mert a Google, És most Baidu , Fejlessze a fej nélküli böngészést, hogy jobban megértse a felhasználói élményt és a weboldalak tartalmát. PhantomJS és Zombie.js Olyan szkript nélküli headless böngészők, amelyeket általában webes interakciók automatizálására használnak tesztelési célokra, és statikus HTML-pillanatképeket készítenek a kezdeti kérelmekhez (előzetes megjelenítés). Miért lehet a JavaScript kihívás a SEO számára? (És hogyan oldja meg a problémákat) Három (3) elsődleges ok van arra, hogy aggódj a JavaScript webhelyén: Feltérképezés: A robotok képesek feltérképezni webhelyét.
Megvalósíthatóság: A botok információhoz való hozzáférési lehetősége és a tartalom elemzése.
Perceived site latency: AKA kritikus renderelési útvonal.
Crawlability A botok képesek-e URL-címeket találni és megértik webhelye architektúráját? Két fontos elem van itt: A keresőmotorok blokkolása a JavaScriptből (akár véletlenül is).
Helyes belső összekapcsolás, a JavaScript-események kihasználása helyett a HTML-címkék helyettesítésére.
Miért blokkolja a JavaScript ilyen nagy ügyletet? Ha keresőmotorok vannak Blokkolva a JavaScript bejárásától , Nem fogják megkapni webhelyének teljes élményét. Ez azt jelenti, hogy a keresőmotorok nem látják, amit a végfelhasználó lát. Ez csökkentheti webhelye vonzerejét a keresőmotorokhoz, és végül úgy is tekinthető álcázásnak (ha a szándék valóban rosszindulatú). Keresd meg a Google-t És a TechnicalSEO.com robots.txt és Fetch és Render A teszteszközök segítenek azonosítani azokat a forrásokat, amelyekkel a Googlebot blokkolva van. A probléma megoldásának legegyszerűbb módja az, hogy a keresőmotorok hozzáférjenek ahhoz a forráshoz, amelyre szükségük van a felhasználói élmény megértéséhez. !!! Fontos jegyzet: Fejlesztési csapatával dolgozzon annak meghatározásához, hogy mely fájlok legyenek és nem érhetők el a keresőmotorok számára. Belső összekapcsolás A belső összekapcsolást rendszeres horgonycímkékkel kell végrehajtani a HTML-ben vagy a DOM-ban (a HTML-címke), szemben a JavaScript-funkciók kihasználásával, hogy a felhasználó átkeresse a webhelyet.
Lényegében: Ne használja a JavaScript onclick eseményeit a belső összekapcsolás helyettesítőjeként. Bár a végső URL-ek találhatók és feltérképezhetők (a JavaScript-kód vagy az XML-webhelytérképek sztringjein keresztül), ezek nem lesznek összekapcsolva a webhely globális navigációjával. A belső összekapcsolás erős jelzés a keresőmotoroknak a webhely architektúrája és az oldalak fontossága tekintetében. Valójában a belső kapcsolatok olyan erősek, hogy (bizonyos helyzetekben) felülbírálhatják a “SEO-tanácsokat”, például a kanonikus címkéket. URL-struktúra Történelmileg a JavaScript-alapú webhelyek (más néven “AJAX-oldalak”) URL-eken belül töredékazonosítót (#) használtak. Nem ajánlott:
A Lone Hash (#) – A magányos font szimbólum nem kiabálható. A horgonyhivatkozás azonosítására szolgál (aka jump linkek). Ezek azok a linkek, amelyek lehetővé teszik, hogy az egyik oldalra ugorjon. Bármi, amint az URL egyszeri hash részét nem küldi el a kiszolgálónak, és az oldal automatikusan az első elemhez gördül a megfelelő azonosítóval (vagy az első Elem az alábbi információk nevével). A Google azt ajánlja Elkerülve a “#” URL-ek használatát.
Hashbang (#!) (És escaped_fragments URL-ek) – A Hashbang URL-ek egy csapást jelentenek a robotok támogatására (a Google el akarja kerülni, és csak a Bing támogatja). Sok hónappal ezelőtt a Google és a Bing egy bonyolult AJAX megoldást fejlesztettek ki, amelyhez egy elégséges (#!) URL az UX-szel együtt létezett, ezzel egyenértékű escaped_fragment HTML-alapú élmény a robotok számára. A Google azóta visszavágta ezt az ajánlást, inkább a pontos felhasználói élményt részesíti előnyben. A megszökött töredékekben két élmény van itt: Eredeti tapasztalat (más néven Pretty URL): Ennek az URL-nek akár #! (Hashbang) az URL-ben, jelezve, hogy létezik egy szökési fragmentum vagy egy metaelem, amely jelzi, hogy létezik egy megszökött fragmentum ( ).
Elhagyott töredék (más néven Ugly URL, HTML pillanatkép): Ez az URL helyettesíti a hashbangot (#!) A “_escaped_fragment_” paranccsal, és a HTML pillanatképet szolgálja ki. Ezt a csúnya URL-nek hívják, mert hosszú és úgy néz ki (és minden szándékra és célra) egy hack.

Kép forrás
Ajánlott:
PushState History API – A PushState navigációs alapú és része a History API-nak (gondolom: internetes böngészési előzményeid). Lényegében a pushState frissíti az URL-t a címsávban, és csak az oldalon változtatni kell. Lehetővé teszi a JS-oldalak számára a “tiszta” URL-ek kihasználását. A PushState jelenleg A Google támogatja , Amikor támogatja a böngészõ navigációt kliens oldali vagy hibrid rendereléshez. A pushState jó használata a végtelen görgetéshez (azaz, amikor a felhasználó új oldalrészeket talál, az URL frissíteni fog). Ideális esetben, ha a felhasználó frissíti az oldalt, a tapasztalat pontosan ugyanabban a helyszínen lesz. Azonban nem kell frissíteni az oldalt, mivel a tartalom frissül, miközben lefelé görget, míg az URL frissítésre kerül a címsorban.
Példa: A Google John Mueller (go figure) által létrehozott, keresőmotor-barát, végtelen lapozást végrehajtó példa jó példa itt . Technikailag kihasználja a replaceState () függvényt, amely nem tartalmazza ugyanazt a visszaállító funkciót, mint a pushState.
Olvass tovább: Mozilla PushState History API dokumentumok

Obtainability A keresőmotorok kimutatták, hogy fej nélküli böngészést alkalmaznak annak érdekében, hogy a DOM jobban megértse a felhasználó tapasztalatait és az oldal tartalmát. Ez azt jelenti, hogy a Google feldolgozhat néhány JavaScriptet, és a DOM-ot használja (a HTML-dokumentum helyett). Ugyanakkor vannak olyan helyzetek, amikor a keresőmotorok küzdenek a JavaScript megértésében. Senki sem akarja Egy Hulu helyzet Hogy megtörténjen a webhelyükön vagy egy ügyfél webhelyén. Fontos megérteni, hogy a robotok hogyan működnek együtt a helyszíni tartalomkal. Ha nem biztos benne, próbáld ki. Feltéve, hogy egy olyan keresőmotorról beszélünk, amely végrehajtja a JavaScriptet, néhány fontos elem van a keresőmotorok számára, hogy tartalmat szerezzenek: Ha a felhasználónak valami tűzzel kell érintkeznie, a keresőprogramok valószínűleg nem látják. A Google lusta felhasználó. Nem kattint, nem görget, és nem jelentkezik be. Ha a teljes UX igényli a felhasználó intézkedését, különleges óvintézkedéseket kell tenni annak biztosítására, hogy a botok egyenértékű élményt kapjanak.

Ha a JavaScript a JavaScript betöltési esemény után + 5 másodperces + tüzelés után jelentkezik, a keresőmotorok esetleg nem látják. * Említette John Mueller Hogy nincs meghatározott időtúllépési érték; Azonban a helyszíneknek öt másodpercen belül kell betölteniük.
* Screaming Béka tesztek Öt másodpercre korrelációt mutat a tartalom megjelenítéséhez.
* A betöltési esemény plusz öt másodperc, amit a Google PageSpeed ​​Insights, a Mobile Friendliness Tool és a Get as Google használ; Nézd meg Max Prin tesztelési időzítője .

Ha a JavaScripten belül hibák vannak, akkor mind a böngészők, mind a keresőmotorok nem lesznek képesek átmenni és esetleg hiányozhatnak az oldalrészek, ha a teljes kódot nem hajtják végre.
Hogyan győződjön meg róla, hogy a Google és más keresőmotorok megkapják a tartalmat? 1. VIZSGÁLAT A JavaScript megoldásának legelterjedtebb megoldása valószínűleg nem old meg semmit (megragad egy kávét, és hagyja, hogy a Google algoritmikus ragyogását használja). A Google ugyanolyan élménnyel jár, mint a keresők A Google preferált forgatókönyve . A Google először bejelentette, hogy képes “jobban megérteni a webet (azaz a JavaScriptet)” 2014. május . Az iparági szakértők azt sugallták, hogy a Google a bejelentést megelőzően képes lenne bejárni JavaScript módját. Az iPullRank csapat 2011-ben két nagyszerű darabot ajánlott fel: A Googlebot a Chrome és Milyen okosak a Googlebots? (Köszönöm, Josh és Mike). Adam Audette A Google bejárhatja a JavaScriptet, és kihasználhatja a DOM-ot 2015-ben megerősítette. Ezért, ha megtekinti a tartalmat a DOM-ban, akkor valószínű, hogy a tartalmadat a Google elemzi. Nemrégiben Barry Goralewicz végzett Egy hűvös kísérlet, amely különböző JavaScript könyvtárak és keretek kombinációját teszteli Hogy meghatározza, hogyan működik a Google az oldalakkal (például URL-t vagy tartalmat indexel? Hogyan működik együtt a GSC? Stb.). Végül megmutatta, hogy a Google képes együttműködni a JavaScript számos formájával, és talán még nagyobb kihívást jelentett bizonyos kereteket. John Mueller még egy JavaScript-keresőcsoportot is indított (Amit olvastam, meglehetősen terápiás). Mindezek a tanulmányok csodálatosak, és segítenek a SEO-nek megérteni, mikor kell aggódniuk, és proaktív szerepet kell vállalniuk. Azonban, mielőtt megállapítaná, hogy a helyes megoldás a helyén, javaslom, hogy alaposan óvatosak legyenek a kis részekkel történő kísérletezéssel. Gondolj: Jim Collin “golyója, majd ágyúgolyó” filozófiája a könyvéből Kiváló választás : “A golyó empirikus teszt, amelynek célja, hogy megtanulja, mi működik és megfelel három kritériumnak: a golyónak alacsony költségű, alacsony kockázatú és alacsony zavaró hatásúnak kell lennie … A golyók használata empirikusan érvényesíti, hogy mi fog működni. Ennek az empirikus érvényesítésnek az alapján koncentrálják erőforrásaikat egy ágyúgolyó tűzre, amely lehetővé teszi a nagy hozamokat a koncentrált fogadásokból. ” Tekintse meg a tesztelést és a felülvizsgálatot az alábbiak szerint: Ellenőrizze, hogy a tartalma megjelenik-e a DOM-ban.
Ellenőrizze az oldalak egy részhalmazát, hogy meggyőződhessen arról, hogy a Google indexelhet-e tartalmat.
Manuálisan ellenőrizze árajánlatok tartalmáról.
Keresd meg a Google-lal és nézd meg, hogy megjelenik-e a tartalom.
A Google-lal való lekérés feltételezhetően a terhelési esemény vagy az időtúllépés előtt jelenik meg. Ez egy nagyszerű teszt annak ellenőrzésére, hogy a Google képes lesz-e látni a tartalmát, és hogy blokkolja-e a JavaScriptet a robots.txt-ben. Bár a Google lekérése nem bolondbiztos, jó kiindulási pont.
Megjegyzés: Ha nem ellenőrzött a Főtitkárságnál, próbálkozzon A Technicalseo.com megragadja és megjeleníti az összes Bot eszközt .
Miután mindent teszteltél, mi van, ha valami nem működik, és a keresőmotorok és a botok megpróbálják indexelni és szerezni a tartalmat? Talán aggódsz az alternatív keresőmotorok miatt (DuckDuckGo, Facebook, LinkedIn stb.), Vagy talán olyan metaadatokat használsz, amelyeket más botok, például a Twitter összefoglaló kártyák vagy a Facebook Open Graph tagek segítségével kell értelmezni. Ha valamelyikét a tesztelés során azonosítják, vagy aggodalomra ad okot, HTML-pillanatkép lehet az egyetlen döntés. 2. HTML PILLANATLAPOK Mi a HTmL pillanatfelvételek? A HTML-pillanatképek egy teljesen renderelt oldal (a DOM-ban látható), amelyet vissza lehet küldeni a keresőmotorok számára (gondolom: a statikus HTML-verzió a DOM-nak). A Google bemutatta a HTML pillanatfelvételeket 2009-ben , Elavult (de még mindig támogatott) 2015-ben , És félénken említette őket Egy elem, amely “elkerülni” 2016 végén. A HTML-pillanatképek vitatható témát jelentenek a Google-lal. Fontos azonban megérteni, mert bizonyos helyzetekben szükség van rá. Ha a keresőmotorok (vagy olyan webhelyek, mint például a Facebook) nem tudják megragadni a JavaScriptet, akkor jobb, ha egy HTML-pillanatképet visszaküld, mint hogy a tartalmát egyáltalán nem indexeljük és értjük. Ideális esetben a webhely kihasználná a kiszolgálóoldali felhasználói ügynök-felismerés valamilyen formáját, és visszaadná a HTML-pillanatképet a bothoz. Ugyanakkor fel kell ismerni, hogy a Google ugyanazt a tapasztalatot szereti, mint a felhasználó (azaz csak a Google számára nyújt HTML-pillanatképet, ha a tesztek szörnyűek és a JavaScript keresőcsoport Nem tud támogatást adni a helyzetednek). szempontok A HTML pillanatfelvételek figyelembe vételével figyelembe kell vennie, hogy a Google elvetette ezt az AJAX ajánlást. Bár a Google technikailag továbbra is támogatja ezt, a Google azt javasolja, hogy elkerülje azt. Igen, a Google megváltoztatta a gondolatait, és most ugyanazt a tapasztalatot szeretné kapni, mint a felhasználó. Ez az irány értelme, mivel lehetővé teszi a bot számára, hogy olyan élményt kapjon, amely jobban igaz a felhasználói élményhez. Második megfontolási tényező az álcázás kockázata. Ha a HTML-pillanatfelvételeket úgy találják, hogy nem képviselik a lapon tapasztalt élményt, akkor ez egy álcázási kockázatnak számít. Egyenes a forrásból: “A HTML pillanatképnek ugyanazt a tartalmat kell tartalmaznia, mint amit a végfelhasználó a böngészőben lát. Ha ez nem így van, akkor az álcázásnak tekinthető. ” – Google Developer AJAX feltérképezése GYIK
Előnyök A megfontolások ellenére a HTML-pillanatképek nagy előnyökkel járnak: A tudás, hogy a keresőmotorok és a robotok képesek lesznek megérteni a tapasztalatokat. Bizonyos JavaScript-típusok nehezebbek lehetnek a Google számára (köhögés … Szögletes (szintén beszélgetésképpen AngularJS 2) … köhögés).

Más keresőmotorok és robogók (gondolom: Bing, Facebook) képes lesz megérteni a tapasztalatokat. A Bing, többek között a keresőmotorok között, nem állította, hogy képes feltérképezni és indexelni a JavaScriptet. A HTML-pillanatképek lehetnek az egyetlen megoldás a JavaScript-nehéz webhely számára. Mint mindig, tesztelje, hogy ez a helyzet a búvárkodás előtt.

A webhely latenciája Ha a böngészők HTML-dokumentumot kapnak, és létrehozzák a DOM-ot (bár van bizonyos szintű előzetes szkennelés), akkor a legtöbb erőforrás betöltődik, ahogyan a HTML dokumentumban megjelenik. Ez azt jelenti, hogy ha egy óriási fájl a HTML dokumentum tetejére irányul, akkor a böngésző először betölti ezt a hatalmas fájlt. A Google kritikus renderelési útvonalának koncepciója a lehető legrövidebb időn belül kell betöltenie a felhasználók igényeit, amelyeket le lehet fordítani a következőre: → “mindent felhajtva a felhasználó előtt, ASAP”. Kritikus rendering elérési út – optimalizált renderelés fokozatosan ASAP:
Kép forrás
Ha azonban szükségtelen erőforrásokat vagy JavaScript fájlokat blokkol az oldal betöltési képességével kapcsolatban, a “renderelt blokkoló JavaScriptet” kap. Jelentése: a JavaScript blokkolja az oldal potenciális megjelenését, mintha gyorsabb lenne (más néven: perceived latency) . Render-blokkoló JavaScript – Megoldások Ha az oldal sebességének eredményeit elemzi (olyan eszközökkel, mint például Page Speed ​​Insights eszköz , WebPageTest.org , CatchPoint stb.), És meghatározza, hogy létezik render blokkoló JavaScript-probléma, itt három lehetséges megoldás létezik: Inline: Adja hozzá a JavaScriptet a HTML dokumentumban.
Async: Make asynchronous JavaScript (vagyis add hozzá az “async” attribútumot a HTML taghez).
Halasztás: A JavaScript helyének a HTML-ben való elhelyezésével.
!!! Fontos jegyzet: Fontos megérteni, hogy a szkripteket sorrendben kell rendezni. A fent említett tartalom betöltéséhez használt parancsfájlokat prioritásként kell kezelni, és nem szabad elhalasztani. Továbbá bármely más fájlra hivatkozó parancsfájl csak a hivatkozott fájl betöltése után használható. Győződjön meg róla, hogy szorosan együttműködik a fejlesztői csapatával annak megerősítéséhez, hogy nincsenek megszakadások a felhasználó tapasztalataihoz. Olvass tovább: Google Developer gyors dokumentációja
TL, DR – A történet morálja A robotok és a keresőmotorok mindent megtesznek a JavaScript indulásához, végrehajtásához és értelmezéséhez, de ez nem garantált. Győződj meg róla, hogy a tartalmad bejárható, elérhető, és nem fejleszt a webhely késői akadályait. A kulcs = minden helyzet tesztelést igényel. Az eredmények alapján értékelje a lehetséges megoldásokat. Kösz: Köszönjük Max Prinnek (@maxxeight) a tartalom megtekintéséhez és a tudás, betekintés és bölcsesség megosztásához. Nem lesz veled nélküled.

Ha tetszett, kérlek oszd meg barátaiddal!