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, semmi nem fog 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ímek, 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 az oldal megjelenítési rétege.
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. Normális esetben, ha egy oldal betöltődik, az oldalon lévő összes eszközt fel kell kérni és fel kell venni a kiszolgálóról, majd az oldalon kell megjeleníteni. 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 Document Object Model (DOM)? SEO szakemberként meg kell értened, mi a DOM, mert a Google a weboldalak elemzésére és megértésére használja. A DOM az, amit látsz, amikor 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 dokumentumban szereplő 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ése. Ezt a weblap kódjának strukturált, szervezett változatára lehet gondolni. 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 napszak) é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 JavaScript használatával van feltöltve:
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éré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 vizsgálati célokra, és statikus HTML-pillanatképeket készítenek a kezdeti kérelmekhez (előzetes renderelé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 oka van annak, hogy aggódj a JavaScript webhelyén: Feltérképezés: a botok 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).
Helyes belső összekapcsolás, a JavaScript-események kihasználása helyett a HTML-címkék helyettesítésére.
Miért akadályozza a JavaScript ilyen nagy ügyletet? Ha keresőmotorok vannak Blokkolva a JavaScript bejárásától , Nem fogják megkapni a webhely teljes élményét. Ez azt jelenti, hogy a keresőmotorok nem látják, mit lát a végfelhasználó. 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ú). Fetch as Google És a TechnicalSEO.com robots.txt és Fetch és renderelés A tesztelési eszközök segíthetnek 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ésére. Bár a végső URL-címek 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ő kapcsolat erős jelzés a keresőmotoroknak a webhely architektúrájával és az oldalak fontosságával kapcsolatban. 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”) az URL-eken belüli töredékazonosítókat (#) 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 bejárók támogatására (a Google most már csak a Bing támogatja). Sok hónappal ezelőtt a Google és a Bing egy bonyolult AJAX megoldást fejlesztett ki, melynek köszönhetően egy szép (#!) URL az UX-szel együtt létezett, ezzel egyenértékű escaped_fragment HTML-alapú tapasztalat 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 ( ).
Kimentett töredék (más néven Ugly URL, HTML pillanatkép): Ez az URL helyettesíti a hashbangot (#!) A “_escaped_fragment_” -nel és a HTML-pillanatképet szolgálja. 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 az Előzmények API-nak (gondolom: internetes böngészési előzményei). 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. Jelenleg a PushState A Google támogatja , Amikor támogatja a böngészõ navigációt az ügyféloldali 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ül). Ideális esetben, ha a felhasználó felfrissíti az oldalt, a tapasztalat pontosan ugyanabban a helyszínen lesz. Az oldal frissítése azonban nem szükséges, 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, hogy a DOM jobban megértse a felhasználói élményt és az oldal tartalmát. Ez azt jelenti, hogy a Google feldolgozhat néhány JavaScript-et, é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 az ü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 JavaScript-böngészőből álló keresőmotorról beszélünk, néhány fontos elem van a keresőmotorok számára a tartalom megszerzéséhez: Ha a felhasználónak valami tűzzel kell működnie, 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éseit, 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 webhelyeknek ö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 Princ tesztidőzítője .

Ha a JavaScripten belül hibák vannak, akkor mind a böngészők, mind a keresőmotorok nem tudnak á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 tapasztalattal 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 (vagyis 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 látod a tartalmadat 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 szakaszok kísérletezésével. Gondolj: Jim Collin “golyók, majd ágyúgolyó” filozófiáját 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.
Vizsgálja meg 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 történik. Nagyszerű teszt annak ellenőrzésére, hogy a Google képes lesz-e látni a tartalmadat, és hogy blokkolja-e a JavaScriptet a robots.txt-ben. Bár a Fetch with the Google nem biztonságos, ez 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őprogramok 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 alapján 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 (gondoljuk: a statikus HTML-verzió a DOM-ban). A Google bemutatta a HTML pillanatfelvételeket 2009-ben , Elavult (de még mindig támogatott) 2015-ben , És kínosan említette őket Egy elem, amely “elkerülni” 2016 végén. A HTML-pillanatképek vitatható témák a Google-lal. Fontos azonban megérteni, mert bizonyos helyzetekben szükség van rá. Ha a keresőmotorok (vagy olyan webhelyek, mint a Facebook) nem tudják megragadni a JavaScriptet, akkor jobb, ha egy HTML-pillanatképet visszaad, mint egyáltalán nem indexelt és érthető. Ideális esetben webhelye 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ési 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ételek azt mutatjá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, más keresőmotorok között, nem állította, hogy képes feltérképezni és indexelni a JavaScriptet. A HTML-pillanatfelvételek 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), a legtöbb erőforrás betöltődik, ahogyan azok a HTML-dokumentumban jelennek meg. Ez azt jelenti, hogy ha egy óriási fájl van a HTML dokumentum teteje felé, 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ő leghamarabb betölteni 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 folyamatosan ASAP:
Kép forrás
Ha azonban felesleges erőforrásokat vagy JavaScript fájlokat elakad az oldal betöltési képességétől, akkor a “renderelt blokkoló JavaScriptet” kap. Jelentése: a JavaScript blokkolja az oldal potenciális megjelenését, mintha gyorsabban töltené (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ére a HTML alatt.
!!! 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 kijátszására, végrehajtására és értelmezésére, 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!