Будзь адзін з гусенічным - Pt 1 - Nrwl

  1. 3 часткі
  2. Googlebot
  3. Тры часткі Гісторыя Googlebot
  4. Узрост старонак сервера
  5. Эпоха разумення разумення
  6. Узрост пісьменнасці
  7. Прагрэсіўнае павышэнне
  8. URL-адрасы і спасылкі
  9. Няма хэшаў
  10. Варыяцыі
  11. onclick 👎 <a href= „"> 👍
  12. пошук кансолі
  13. Правільныя робаты
  14. Будзь хуткім
  15. Як Googlebot скануе

Джэф Крыс з'яўляецца сузаснавальнікам nrwl.io , прадастаўленне вуглавога кансалтынгу для карпаратыўных груп. Раней ён быў у асноўнай камандзе Angular у Google, якая ўзначальвае каманду Angular Mobile. Джэф Крыс з'яўляецца сузаснавальнікам nrwl

Googlebot

3 часткі

Гэта першы з 3-х частак серыі, якая дазваляе Googlebot зразумець і праіндэксаваць прыкладанні Angular. У гэтым артыкуле мы разгледзім кароткую гісторыю эвалюцыі здольнасцяў Googlebot сканаваць прыкладанні JavaScript, а таксама разгледзім некаторыя лепшыя практыкі, якія тычацца прыкладанняў JavaScript у цэлым. Другая і трэцяя часткі будуць разглядацца з пункту гледжання вуглавых меркаванняў і карысных інструментаў.

SEO - гэта важная тэма для распрацоўнікаў, каб зразумець, калі яны датычацца прыкладанняў, якія залежаць ад трафіку пошукавых сістэм, таму што праблемы SEO вельмі складаныя і дарагія для ліквідацыі наступных фактаў, што можа патрапіць тыднямі ці месяцамі страчанага трафіку.

Googlebot

SEO - гэта шырокая тэма. У гэтым артыкуле прысвечаны адзін аспект SEO: сканаванне. Я арыентуюся толькі на адзін сканер, на Googlebot (гусенічны Google), і я засяроджаны толькі на сканаванні прыкладанняў JavaScript і Angular. Пад сканаваннем я маю на ўвазе працэс пераключэння Googlebot да загрузкі і аналізу старонак Googlebot. Я не буду разглядаць індэксаванне, рэйтынг або любыя іншыя цікавыя тэмы.

Тры часткі Гісторыя Googlebot

Да 2009 года (узрост старонак сервера), 2009–2015 гг. (Узрост аўтаматычнага разумення), 2015+ (эпоха пісьменнасці)

Узрост старонак сервера

Да 2009 года распрацоўшчыкі толькі прызналі, што калі б яны выкарыстоўвалі бібліятэкі jQuery, Backbone ці іншыя JS для адлюстравання сваіх прыкладанняў у браўзэры, пошукавыя сістэмы не змогуць зразумець іх змест. Такім чынам, старонкі павінны быць адлюстраваны на сэрвэры ў той ці іншай форме, а потым могуць быць палепшаны з дапамогай JavaScript у браўзэры. Паколькі фреймворкі JavaScript пачалі развівацца і выкарыстоўвацца для стварэння цэлых прыкладанняў - "Аднамесных прыкладанняў", Google бачыў неабходнасць забяспечыць распрацоўшчыкам магчымасць інструктаваць сканер пра змест сваіх прыкладанняў.

Эпоха разумення разумення

Так У 2009 годзе Google прапанаваў новы пратакол Выкарыстоўваючы камбінацыю мета-тэга, каб паказаць, што ваша праграма была дадаткам JavaScript, і канфігурацыя сервера служыць простай версіі змесціва старонкі, калі старонка будзе запытвацца з параметрам запыту _escaped_fragment_ .

На сённяшні дзень сайт дакументаў AngularJS рэалізуе гэты пратакол. Калі вы наведваеце https://docs.angularjs.org/api/ng/function/angular.bind Вы ўбачыце нармальную старонку.

Здымак экрана https://docs.angularjs.org/api/ng/function/angular.bind

Але калі вы зменіце URL, каб уключыць _escaped_fragment_ , https://docs.angularjs.org/ ? _escaped_fragment_ = api / ng / function / angular.bind , Вы ўбачыце тое ж змесціва ў значна больш простай, не стылі форме, без JavaScript, так што сканер можа лёгка зразумець змесціва старонкі.

Здымак экрана https://docs.angularjs.org/?_escaped_fragment_=api/ng/function/angular.bind

У гэты момант у кастрычніку 2009 года Googlebot павялічваў свае магчымасці для рэндэрынгу і аналізу прыкладанняў JavaScript. Падаючы опцыю _escaped_fragment_, распрацоўшчыкі могуць дапамагчы сканеру больш упэўнена ўтрымліваць дынамічныя старонкі.

Узрост пісьменнасці

Хутка перайшоўшы да кастрычніка 2015 года, Googlebot атрымаў значна больш прасунутыя магчымасці навігацыі і аналізу JavaScript-прыкладанняў. Пошук каманды абвешчана ў блогу Google Webmasters што папярэдняя прапанова па выкарыстанні _escaped_fragment_ зараз састарэла. Гусенічны досвед эвалюцыянаваў, каб мець магчымасць упэўнена і паслядоўна сканаваць прыкладанні на адной старонцы JavaScript.

Такім чынам, з дасягненнямі ў сканеры, распрацоўшчыкі JavaScript могуць распрацоўваць прыкладанні як звычайна, не турбуючыся аб магчымасці сканавання? Як правіла, так, але не без якіх-небудзь папярэджанняў, адмаўленняў ад адказнасці і зорачак. Каб растлумачыць бягучую рэкамендацыю па сканаванні прыкладанняў JavaScript, Джон Мюллер з Google размешчаны на Google+ з некаторымі кароткімі прапановамі. Джон таксама прадстаўлены на той жа тэме ў AngularConnect 2016 , уваходзячы ў крыху больш падрабязна, чым яго паведамленне ў Google+, але паўторна паўтараю шмат і тых жа момантаў. Я прапаную свой рэзюмэ гэтай пасады і прэзентацыі.

Прагрэсіўнае ўдасканаленне, URL-адрасы і спасылкі, пошукавай кансолі, правільныя робаты, хутка

Прагрэсіўнае павышэнне

Браўзэр, які выкарыстоўваецца сканерам для адлюстравання прыкладанняў JavaScript, не мае ўсіх функцый Chrome і іншых сучасных браўзэраў. На думку Джона ў верасні 2016 года, асобныя API, якія не падтрымліваліся, уключаюць ServiceWorker, Fetch, Promise, requestAnimationFrame і localStorage. Большасць прыкладанняў, напэўна, ужо запаўняюць большасць з іх, альбо, па меншай меры, маюць адкат. Калі які-небудзь з гэтых API выкарыстоўваецца для адлюстравання змесціва старонкі, важна, каб старонка не ўдалося вытанчана, і ўсё яшчэ можа адлюстроўваць змесціва ў адсутнасць.

URL-адрасы і спасылкі

Кананічныя URL-адрас

URL-адрасы вельмі важныя для індэкса Google. Усе дакументы ў індэксе Google падаюцца па адрасах URL. Таму важна, каб старонкі мелі адзін кананічны URL. Іншымі словамі, калі ў розных URL-адрасах даступная і тая ж старонка, у тым ліку ў тым жа шляху URL з рознымі параметрамі запыту, неабходна паведаміць Google, які правільны кананічны URL для гэтай старонкі.

Няма хэшаў

Google таксама мае моцную прадузятасць у адносінах да адрасоў, якія выкарыстоўваюць хэш (/ # /) унутры шляхоў. Калі Google бачыць спасылкі, якія ўтрымліваюць хэш, ён мяркуе, што змесціва пасля таго, як хэш нязначнае. Рэдка, што Google будзе праіндэксаваць адрасы хэшамі.

Варыяцыі

Калі старонка мае значныя змены аднаго і таго ж зместу, напрыклад, змесціва, перакладзенага на некалькі моў, для кожнай версіі старонкі павінен быць унікальны URL.

onclick 👎 <a href= „"> 👍

Googlebot не разглядае апрацоўшчыкі клікаў як спасылкі, таму важна, каб спасылкі на змесціва былі прадстаўлены ў атрыбуце href элементаў якара.

пошук кансолі

пошук кансолі прадастаўленая Google з'яўляецца важным інструментам для кіравання і кантролю адносін сайта з індэксам Google. Заўвага для распрацоўнікаў JavaScript з'яўляецца Атрымайце Google інструмент. Fetch as Google дазваляе распрацоўнікам запытваць Googlebot для атрымання старонкі, а потым адлюстроўвае некаторыя характарыстыкі старонкі, калі Google бачыў. Распрацоўшчыкі JavaScript жадаюць націснуць на кнопку "Fetch and Render", якая прымушае Googlebot аказваць прыкладанне JavaScript. Пасля сканавання будзе адлюстроўвацца скрыншот адлюстраванай старонкі.

Пасля сканавання будзе адлюстроўвацца скрыншот адлюстраванай старонкі

Выберыце як скрыншот Google з сайта nrwl.io

Гэта карысна, каб пераканацца, што змест старонкі з'яўляецца правільным, але, на жаль, у цяперашні час немагчыма ўбачыць метададзеныя старонкі (назва, мета-апісанне, кананічны URL). Калі вы хочаце ўбачыць гэтую інфармацыю, вам прыйдзецца падмануць і дадаць інфармацыю ў цела вашай старонкі дзе-небудзь, каб ён з'явіцца на скрыншоце.

Правільныя робаты

Robots.txt - гэта тое, як серверы могуць распавесці робатам, як Googlebot, які змест ім павінен і не павінен сканаваць. Часта гэтыя канфігурацыі выкарыстоўваюцца для прадухілення загрузкі пэўных актываў, якія не з'яўляюцца неабходнымі для адлюстравання кантэнту. Важна пераканацца, што robots.txt на вашым сэрвэры і серверах, на якіх вы залежаць, не блакуе важныя актывы, такія як бібліятэкі JavaScript, неабходныя для адлюстравання вашай старонкі.

Будзь хуткім

Googlebot можа быць проста робатам, але гэта не значыць, што ён мае неабмежаваную цярпенне. У нейкі момант, калі старонка займае занадта шмат часу, каб загрузіць Googlebot, альбо не разабраць старонку, альбо разабраць яе ў бягучым стане. Гэта можа прывесці да выдалення старонак з індэкса, калі яны паслядоўна займаюць занадта шмат часу, каб загрузіць. Дакладны момант, у якім Googlebot здацца, незразумелы, але агульнае меркаванне ў тым, што гэта каля 5 секунд. Таму важна ацэньваць усе запыты на блакіроўку і працу, якія могуць затрымліваць аказанне крытычнага зместу, альбо выдаліць менш важную працу, альбо адкладаць яе да таго часу, пакуль змесціва не будзе зроблена.

Як Googlebot скануе

Адзін важны момант ведаць пра Googlebot - гэта тое, што ён не націскае на спасылкі ў вашым дадатку. Замест гэтага, калі Googlebot разбірае старонку, ён збірае ўсе знойдзеныя гіперспасылкі і плануе спасылкі, якія будуць сканаваны пазней. Тады ў нейкі момант у будучыні, можа быць, адразу ці, магчыма, праз некалькі дзён, Googlebot выпусціць новы запыт для загрузкі старонкі. Іншымі словамі, засяродзіцца на тым, як працуе ваша старонка і адлюстроўваецца для пачатковай загрузкі маршруту.

У наступнай частцы гэтай серыі я буду засяроджвацца на канкрэтных меркаваннях, каб зрабіць прыкладанні Angular больш сканаванымі. Калі ў вас ёсць пытанні ці асаблівасці, якія вы хацелі б асвятляць, напішыце мне @jeffbcross ,

Джэф Крыс з'яўляецца сузаснавальнікам Nrwl - Прадпрыемства вуглавога кансалтынгу.

Org/?
Такім чынам, з дасягненнямі ў сканеры, распрацоўшчыкі JavaScript могуць распрацоўваць прыкладанні як звычайна, не турбуючыся аб магчымасці сканавання?