Latest Javascript SEO Best Practices & SPA With Martin Splitt – Обзор

На 20 март 2019 година се проведе епизод от серията уебинари SerpAsk с една знакова личност в SEO средите и по-точно – изработката на сайтове с Javascript и тяхната правилна оптимизация за Google – Martin Splitt – Webmaster Trends Analyst в Google.

Мартин сътрудничи и допринася на платформите и frameworks с отворен код. Той е и уеб-евангелист от Цюрих с десетилетия опит в софтуерното инженерство в множество области. Работи като Webmasters Trends Analyst / Developer Advocate в Google и уеб екосистемата. Той помага на хората да създават приложения или да публикуват съдържание в мрежата, за да бъдат успешни, продуктивни и видими. Мартин вярва в уеб платформата и работи с най-новите технологии, които ще позволят на мрежата да просперира.

Никола: Здравей, Мартин, радваме се, че си тук с нас! Моля те, разкажи ни повече за забележителния ти опит и как започна с Гугъл.

Мартин: Аз съм професионален разработчик от вече 12 години и съм правил много различни неща, но вярвам, че уеб е страхотна платформа, в която можеш да правиш нещо, което да споделиш с всички или почти всички. Разработвал съм за Плейстейшън, но не всеки има тези устройства. Правил съм и вградени разработки за определени хардуерни устройства в индустрии, но не всеки има достъп до тези устройства, затова трябва да се споделят данните, събрани от този хардуер или някого, за да се създаде и уеб интерфейс. Затова уеб винаги е моят избор за платформа. Така продължих и със застъпническа работа, като помагах на другите да бъдат успешни в уеб разработките като уеб разработчици, но поглеждах и от другата страна. Участвал съм и в инженеринг за рекламни платформи за малки и големи компании.

Видях уеб от бекенд и фронтенд перспектива и това, което забелязах да се случва, и с малки и с големи компании, може би нещо, което не очаквате е, че те се борят за това тяхното съдържание да бъде видяно. Уеб е гигантски и това е страхотно, но ако никой не намери твоята страница – това е проблем! Разбира се, има различни канали – може да се използват реклами, но това изисква бюджет, може да се използват и социални мрежи, но там контролът е по-малък, освен ако нямате някой, който наистина е добър в това, може да използвате и свързани мрежи, но това обикновено не носи резултата, който бихте искали, и накрая остава органичният трафик – търсещите машини. Това се оказа нещо мистериозно от гледна точка на уеб разработчиците.

Работил съм с фантастични SEO специалисти, които имат много опит, както и с други SEO специалисти и за мен беше интересно защо има такава разлика, но по-точно имаше разлика в това как ги виждам аз по отношение на това как си вършат работата. Постепенно се появи и възможността да започна да работя за Гугъл с фокус върху по-добрата работа между разработчиците и SEO специалистите, и то най-вече по отношение на това как Googlebot се справя с Javascript и как се справя с рендерирането на модерните сайтове.

Никола: Първият ни въпрос към теб е много прост – защо Javascript?

Мартин: Хаха това е толкова базов въпрос, но и в същото време може да има толкова дълбок и разнообразен като отговор. За мен Javascript e част от уеб платформата. Както знаем имаме HTML, CSS и Javascript, като три главни технологии, а всичко останало е просто като допълнение около тях. Ако погледнете бек-енд технологиите, те нямат такова голямо значение за фронт-енд-а или потребителя.

Това е същото като въпроса – защо HTML? HTML ни дава възможността да представим съдържанието си по експресивен начин, CSS му придава стил и вид и това е всичко, от което имаме нужда, за да представяме информация, която другите могат да приемат от нас.

Но с времето уеб започна да става все по-мощен, изискванията на потребителите се повишиха, започнахме да виждаме потребителски генерирано съдържание, през 2005-2006та, когато видяхме повече форуми, повече уеб приложения, видяхме повече комуникация между сървър и клиент. Проблемът тук е, че ако потребителят е просто един терминал, а цялата логика се случва на сървъра, то потребителят и сървърът се намират в един постоянен цикличен контакт. В днешно време мрежите стават все по-бързи, което е страхотно.

Когато излязоха смартфоните, кое беше основното предимство? Това, че приложенията работят и офлайн. Ако цялата логика се намира на сървъра, мобилен телефон няма как да работи със съдържание, когато не съм на линия. Така имахме нужда от технология, която да придаде поведение, динамично съдържание, начин за интеракция с уеб съдържанието, което отива извън пределите на “просто четене на информация от уеб страница и обработката на информацията в съзнанието ни”.

Така се появява Javascript – скриптиращ език, който ни дава възможност да toggle-нем нещо, да обработваме интеракции на потребителя като кликове и скролове и какво ли не, но веднъж, като имаме възможността да изпращаме мрежови заявки на заден план, нещата станаха още по-интересни. Сега можем да направим огледално копие на това, което приложението прави – ако кликнем при приложение на телефона си и в десктоп среда, те не чакат контакт с мрежата, а извършват промяната веднага, по едно и също време. И така, тъй като имаме възможността да изпращаме данни към сървъра, то можем да позволим и на потребителя да прави каквото иска в сесията си, без да я нарушаваме, но без да нарушаваме и работата на приложението. Ако имаме приложение за мигновени съобщения, най-често виждаме, че съобщението е изпратено, дори и в дадения момент да не е и Javascript да го изпрати на заден план.

Javascript ни дава възможността да правим това, което native applications правят, можем да създаваме по-добро потребителско преживяване и ангажираност, потребителски генерирано съдържание, в уеб платформата. Затова го имаме и в това е добро, ако се използва правилно!

Никола: Ок, но как да сме сигурни, че Гугълбот рендерира правилно нашия уебсайт? Един горещ въпрос в днешни дни!

Мартин: Това е един от най-обсъжданите въпроси, които получаваме най-често в днешни дни, определено! Ние работим постоянно по обновяването към най-новата версия на Googlebot, която нашите инструменти използват. Не мога да дам крайни дати за това, но нашият екип работи. Към момента Mobile Friendly Test Tool-a е този, който е важен за разработчиците, за да проверят дали съдържанието е видимо, защото показва рендерирания HTML, който ние ще използваме за обработка при индексиране. Така ако виждате съдържанието си там, то всичко е наред, но ако не, то трябва да погледнете нещата по-внимателно. Както казах, все още актуализираме инструментите да използват последните версии на Googlebot, затова ако използвате ES6 или някоя друга API базирана услуга, Mobile Friendly Test Tool-a може да не я разпознае.

Никола: Защо Javascript SEO е толкова различно от регулярното такова? Какви са най-често срещаните проблеми?

Мартин: Традиционната оптимизация е повече насочена към стратегирането и показването на определено съдържание за комуникация с аудиторията. Тоест, искаме да покажем това на потребителя и той да попълни формата или да кликне там и тн. Когато обаче имаме повече потребителска ангажираност, потребителски генерирано съдържание, и искаме потребителят да създава съдържание, да има добро потребителско преживяване. Така въпросът става как да поставим акцента на потребителското съдържание, защото е страхотно, когато доведем много потребители на страницата, но това няма как да се случи, ако Javascript страницата ни зарежда 20 мегабайта код. Тук вече се появява техническата страна на нещата или техническата оптимизация, защото колкото и добре написано съдържание да имаме, ако не бъде видяно, то губи своята стойност. Ето защо е важна работата с разработчиците! Добрите разработчици се грижат за това, разработеното им приложение да е видимо за потребителите и да работи, но те не познават добре стратегирането. Макар да се разочароват при лоша работа на приложението им, те не знаят, че това би довело до ниски стойности на CTR, приходи или conversion rate.

Разработчиците не са толкова наясно със стратегическата маркетингова страна и обратното. Затова е важно да маневрираме между двете звена – маркетинг и техническа оптимизация. Добре е да знаем какво нашите разработчици трябва да правят, да ги подкрепяме в работата им, да им помагаме да имплементират, от друга страна те знаят какво трябва да фиксират, но не могат, защото трябва да се знае каква ще бъде инвестицията в това и дали може да бъде направена.

Никола: Да, но може би най-често срещаните проблеми са свързани, имам предвид от скорост на зареждане та до вътрешните линкове, тагове и тн. Каква да бъде първата ни стъпка, за да идентицираме какъв проблем имаме?

Мартин: Да, това е много добър въпрос! Какви стъпки да предприемем, за да открием потенциалните проблеми, които имаме. Аз мисля, че е важно да бъдете добри в анализа на данни от инструментите, които имате – Google Analytics, Search Console, Server logs, за да идентифицирате какво се случва по страниците на сайта ви. Може би проблемът е, че никой не посещава страницата ви и нямате импресии в органичното търсене – може би имате проблем с обхождането, или проблем със сървъра, който пропада, преди ботът да прихване съдържанието. Ако сървър лог файлът изглежда добре, съдържанието ни се обхожда, но нямаме импресии, сега е моментът да проверите какво ботът на Гугъл вижда с URL Inspection инструментът в GSC или Mobile Friendly Tool-a. Ако виждате бяла страница, значи точно това е нещото, в което трябва да се убедите – че Гугълбот вижда съдържанието на страницата ви правилно.

Особено важна е приоритизацията по отношение на откриваемостта, защото ако виждате, че страницата не се обхожда, а е достъпна за бота, може би имате проблем с нещо, което изразходва бюджета на обхождане, или сървърът отново пропада, или имате услуга от трети страни, която отнема много време, за да върне отговор и да подаде необходимите ресурси. При тази ситуация е добре да редуцирате бюджета на обхождане малко.

Възможно е и вътрешната линк структура на страниците ви да не е добре и да не можем да прихванем релевантността на страниците.

И така ако всичко друго е наред, но Аналитикс показва, че за платения трафик потребителите не се задържат дълго, може би е добре да се погледне скоростта на зареждане с PageSpeed Insights или Lighthouse, защото много хора изоставят страници ако не зареждат бързо.

Основно вие имате голямо “дърво от решения”, които да вземете, за да прецените къде хората са “заклещени” по страниците ви и къде прости изчезват. Дали проблемът е преди потребителите да дойдат на страницата от търсенето с мета описанията и заглавията, защото ако имате много импресии, но никакви кликове, то мета описанията и заглавията не са много добри. Ако имате малко импресии, може би съдържанието не е добро и ние не го класираме високо.

Никола: И може би можем да сравняваме между мобилна среда и десктоп. Ти спомена лог файлове, там можем да сравняваме между бота за мобилни устройства и десктоп среда.

Мартин: Определено можете да го направите, но за да направите живота си по-лесен, се убедете, че имате респонсив сайт, който работи на десктоп и мобилна среда. Обърнете внимание на това дали в десктоп среда всичко е ок, а в мобилна имате проблеми, защото много често това е свързано с проблеми при скоростта на зареждане.

Serpact: Какъв е текущият прогрес на рендирането на Javascript от Googlebot? В нашия първи уебинар, John Mueller каза, че постоянно подобрявате това. Какъв е текущият прогрес?

Мартин: Най-последните новини са преминаването на Гугълбот към версия 74 на Google Chrome. Скокът, който направихме е наистина голям – от версия 41 на Хром до 74. Подобрена е скоростта на самото рендиране, а не времето на рендиране, така ще могат да бъдат рендирани повече страници. Освен това, новата версия ни даде достъп до пълен списък от APIs на JS базирани услуги. Предполагам, сте забалязали, че този ъпдейт ни отне много време – това е, защото искаме да сме сигурни, че ще можем да преминем към тази схема на постоянно актуализиране от сега нататък.

Към момента работим над по-добра интеграция между рендериране и индексиране, както и по прихващането на User-Agent стринга, който да рефлектира текущата версия на Хром, но всичко това е все още в прогрес.

Никола: Ок, много Javascript frameworks следват най-добрите практики днес за SEO. Трябва ли да ползваме някоя от тях или можем да създадем наша собствена framework и да създадем сайта си на нея. Какво мислиш?

Мартин: Едва ли бихте имали човешката мощ и мозъчен капацитет, за да създадете цял framework на нивото на другите frameworks с отворен код онлайн, защото те имат големи общности. Ако създам такъв framework и го споделя публично, тогава няма да имам същият интерес за поддръжка от страна на разработчици, какъвто имат те. Това, което забелязвам е солидния интерес към SEO от всички frameowkrs и покриването на най-добрите практики и имплементирането им по подразбиране в тези frameworks.

Аз самия ще продължавам да работя по подобрението на тези frameworks заедно с общностите им. Както казах – SEO е повече стратегия – за съдържание, за потребителя и потребителското преживяване, маркетингови тактики и тн. Когато обаче има такова решение от-до е добре и за самите SEO и маркетинг специалисти. Към момента работим с общностите, все още не сме стигнали това ниво, но вървим напред.

Никола: Един свързан въпрос – задават ли въпроси разработчиците на frameworks? Получават ли съпорт от страна на Гугъл по определени въпроси?

Мартин: Гугъл инженерите за Angular, Polymer и тн. използват същите канали за комуникация, както всички останали. Ние имаме нещо като “бъди честен с нас” политика и смятаме за нечестно определена група от разработчици да получават специално отношение. Няма значение дали това е супер голям клиент, или най-големият издател някога, добре плащащ в рекламите потребител или framework – това няма значение!

Никола: Благодаря, Мартин, за изясняването на това! Важно е да се знае, че правилата за всички са еднакви и няма специално отношение!

Serpact: Client-side rendering or Server-side rendering?

Мартин: Рендиране на сървъра, защото така съдържанието е вече в HTML и се показва по-бързо. Линковете също ще работят добре и ще бъдат открити бързо, а и това работи бързо за потребителя, така че не виждам защо да не го използвате. Имайте предвид, че това изисква бюджет за разработчици, който често не се предвижда по подразбиране, така че на това трябва да се обърне внимание!

Никола: Правилно ли е да прихванем Гугълбот като използваме User Agent и да му подаде пре-рендирано съдържание с HTML & CSS?

Мартин: Да, наричаме го динамично рендиране и е напълно ок. Не го отчитаме като cloaking щом съдържанието е малко или много същото. Като под “малко или много” същото имам предвид не напълно еднакво, а дори и с малки разлики. Например моят мобилен сайт изглежда малко различно от този за десктоп.

Serpact: Напоследък много хора започнаха да говорят за технологии като prerender.io. Какво мислиш ти?

Мартин: За да бъда максимално ясен – когато казах пре-рендеринг имам точно определена специфична архитектура наум. Пре-рендеринг означава…ако имаме блог или маркетинг страница и знаем много добре предварително кога съдържанието ще се промени, защото съдържанието на моя блог се променя, когато кача нов блог пост, то можем да го пре-рендираме в статичен HTML и не виждам защо да не се направи. 

Когато говорим за prerender.io или други услуги, това е повече като динамичното рендиране, където се сервира само пре-рендираното съдържание към crawlers, и тук ще кажа отново – ако можете да инвестирате в рендиране на сървъра – направете го! Тези услуги, обикновено стартират браузър с празен код, прихващат кода, който не е предвиден да е рендиран на сървъра и създават статичен HTML чрез зареждане в браузъра. И това наподобява някой, който за да достъпи сайт, го отваря в браузъра, чака страницата да се зареди, прави скрийншот и ви го дава. Това е фундаментално по-бавно в сравнение с доставянето на HTML директно.

Serpact: Виждали сме много хора да говорят за кеша на Гугъл. Влияе ли той на класирането на сайтовете и в частност на тези базирани на Javascript?

Мартин: Категорично не! Дори и да липсва съдържанието там или да е напълно счупен, това не оказва влияние върху обхождането, индексирането и класирането. Кешът е просто опция за удобство. Често рендираме добре страниците, но кешът е счупен, това се случва.

Serpact: Хората понякога са много притеснени за това, че дадени ресурси не се зареждат.  Как това влияе на SEO като цяло?

Мартин: По отношение на ресурсите, зависи! Ако те са критични, ние ще опитаме отново. А при този цикъл от обхождане и индексиране не се е получило, ще опитаме пак, може би ще чакаме повече. Ако страницата е нова, ще отнеме повече време да бъде индексирана, а ако е текуща най-вероятно няма да заредим актуализираната версия на страницата. Често проблемите с незаредените ресурси идват от неща, които не са критични като тракери, рекламно съдържание, аналитикс. Ако тези услуги не заредят, аз не бих се притеснявал, щом съдържанието се показва в HTML, ще го индексираме.

Serpact: Значи повече да се притесняваме за това, че снимките ни не зареждат например?

Мартин: Ако снимките ви не зареждат заради 404 или 500 грешка, тогава това е проблем, но ако е поради друга причина – не бих се притеснявал за това.

Никола: Какво ще кажете за рендеринга в <noscript> тагове като някои големи JS форум двигатели правя? Дали това е легитимен начин за Google?

Мартин: Когато обработваме Javascript ние пропускаме това, което е в <noscript> с изключение на снимките, защото допускаме, че може да използвате lazy loading. Извън това не бих ползвал този таг.