На працягу доўгага часу, рэкамендацыі SEO былі сканцэнтраваны вакол якія маюць звычайны тэкставую версію кантэнту кожны раз, калі гэта магчыма, і пазбягаючы дынамічна кантэнту, Ajax і JavaScript. Гэта больш не павінна быць для асноўных пошукавых сістэм, асабліва Google. Ці гэта трэба?
Традыцыйна пошукавыя робаты глядзелі толькі на сыравіну тэкставага зместу, які змяшчаецца ў целе адказу HTTP і сапраўды не інтэрпрэтаваць тое, што тыповы браўзэр, які працуе JavaScript інтэрпрэтуе. Калі старонкі, якія маюць шмат кантэнту, вынесены JavaScript пачалі з'яўляцца, Google пачаў сканіраванне і індэксаванне яго яшчэ ў 2008 годзе, але ў даволі абмежаваным выглядзе. Ajax паўзе схема быў стандартны, хоць і нязграбным рашэнне гэтай праблемы да гэтага часу. Google змяшчаў шмат працы ў больш элегантны падыход да разумець вэб-старонкі лепш І, нарэшце, 14 кастрычніка, 2015 яны афіцыйна абвясцілі аб тым, што AJAX паўзком схема цяпер асуджаецца , Па іх уласным словам:
Мы больш не рэкамендуючы паўзе прапанову AJAX мы зрабілі яшчэ ў 2009 годзе.
Не больш непрадказальныя, мінімальны маштаб паўзе спробу. Гэта афіцыйна, яны зараз павінны падтрымліваць усе гэта. У рэшце рэшт, [некаторыя з падрабязных і ўсебаковых выпрабаванняў зробленыя амаль год таму] (( http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 ) Паказаў, што ў цяперашні час Google можа апрацоўваць JavaScript, як ніколі раней, у тым ліку пераадрасоўвае, спасылкі, дынамічна устаўленага змесціва, мета-дадзеных і элементаў старонкі. Так [мы можам давяраць Google] (( http://searchengineland.com/can-now-trust-google-crawl-ajax-sites-235267 ), Каб цалкам прасканаваць сайты Ajax-аснове? На жаль, адказ - не, па меншай меры пакуль.
Па нашаму вопыту, у той час як большасць функцыянальных магчымасцяў JavaScript на аснове цяпер зразумела, Googlebot, ён пастаянна не поўзаць ўтрыманне, атрыманае з дапамогай XMLHttpRequest API ад вонкавай крыніцы - або што-небудзь пабудаваны на вяршыні, або звязаныя з гэтым API. Такія паводзіны прысутнічае ў чыстым JavaScript, JQuery, AngularJS або іншых сучасных фреймворков. Кожны раз, калі вам трэба, каб выцягнуць змесціва з «вонкавага» URL або выкліку REST API канчатковай кропкі, каб прынесці некаторыя дадзеныя, ёсць верагоднасць, што яна не будзе сканавацца і індэксавацца правільна. Гэта ўносіць велізарныя наступствы для прыкладанняў, якія працуюць з любым выглядам Backend-як-паслуга (Баас) або аналагічнай інфраструктурай. Серверны рэндэрынгу спатрэбілася б вырашыць гэтую праблему, і ў той час як ён падтрымліваецца ў некаторых з фреймворков (напрыклад, рэагаваць ), Нам трэба ўніверсальнае рашэнне, пакуль ён не будзе даступны.
Вось прыклад. Зірніце на адзін з самых простых Baasic камплекты блог стартара , Ён пабудаваны з выкарыстаннем AngularJS і цягне спіс паведамленняў у блогу ад нашага API, што робіць яго ў межах простага макета. Здаецца, што ўсё ў парадку, ці не так?
Тым не менш, гэта тое, што адбываецца, калі мы спрабуем знайсці слова з асобнага паста ў выніках пошуку Google:
Статычнае змесціва самой старонкі індэксуюцца, але дынамічна генеравацца матэрыял адсутнічае - вось доказ, што:
Такім чынам, у той час як Google , як правіла , у стане вынесці і зразумець вашыя вэб - старонкі , такія як сучасныя браўзэры, ня ў цяперашні час ахоплівае ўсе магчымыя сцэнары. Гэта, відавочна, не з'яўляецца прымальным для вытворчай асяроддзя, так што давайце крок назад і перагледзець існуючы стандарт.
Ajax паўзе схема
Google і іншыя перадавыя пошукавыя сістэмы падтрымліваюць фармат URL hashbang (#!), Які быў арыгінальным спосабам стварэння пермалинки для прыкладанняў JS. Кожны раз, калі гусенічны бачыць URL, які змяшчае hashbang -
http://www.site.com/#!/some/page
ён пераўтворыць URL у
http://www.site/?_escaped_fragment_=/some/page
даючы вам ведаць, што вы павінны апрацаваць адказ па-рознаму ўнутры вашага прыкладання JS. У большасці выпадкаў, вы будзеце служыць HTML здымак папярэдне сфармаваны на гусенічны, ратуючы яго ад намаганняў разбору і выкананне JavaScript самастойна.
новы HTML5 PushState не працуе сапраўды гэтак жа, як гэта змяняе URL і гісторыю браўзэра. Калі вы выкарыстоўваеце PushState, вы павінны выкарыстоўваць наступны тэг ў загалоўку старонак:
<META NAME = "фрагмент" змест = "!">
Гэта сведчыць Googlebot , каб вярнуцца на сайт , выкарыстоўваючы? _Escaped фрагмент = ў URL.
Не варта блытаць, калі вы чыталі, што Google не падтрымлівае Ajax схемы сканавання больш. Яны не рэкамендуюць, але ён па - ранейшаму падтрымліваецца, і ён будзе заставацца такім чынам у агляднай будучыні.
З дапамогай аднаго з існуючых камерцыйных паслуг з'яўляецца самым простым спосабам, каб пачаць выкарыстоўваць гэты падыход у прыкладаннях JavaScript. Вось толькі некаторыя з іх:
Мы вырашылі запусціць спецыяльную паслугу папярэдняй візуалізацыі на нашых уласных серверах, выкарыстоўваючы Prerender.io.
Prerender.io
Агульная ідэя заключаецца ў тым, што прамежкавае праграмнае забеспячэнне Prerender.io устаноўлены на серверах візуалізацыі прыкладанняў. Прамежкавае гэта проста прыгожая назва для пакета або набору URL перапісвання правіл, якія правяраюць кожны запыт, каб убачыць, калі яна зыходзіць ад шукальніка. Калі гэта запыт ад шукальніка, прамежкавае праграмнае забеспячэнне будзе адправіць запыт у службу папярэдняй візуалізацыі для статычнага HTML гэтай старонкі.
Калі вы служыце прыкладання ад ASP.NET, прамежкавы пласт можа быць простым модулем HTTP , Тым не менш, мы, як правіла, выбіраюць той падыход, які выкарыстоўвае URL правілы перазапісу. Ён можа быць выкарыстаны з Apache, Nginx, або любым іншым серверам - фактычныя пакеты і інструкцыю можна загрузіць з тут ,
Цяпер нам трэба ўсталяваць службу Prerender.io на нашых серверах. Яго зыходны код знаходзіцца ў вольным доступе, але дакументацыя ўстаноўкі трохі негаваркі. Мы будзем весці Вас праз працэс у наступным пасце. У той жа час, калі ласка, падзяліцеся сваім вопытам са стратэгіямі SEO для прыкладанняў JavaScript.
Ці гэта трэба?Здаецца, што ўсё ў парадку, ці не так?
Site/?