База знань » Блог » SEO

SEO та рендеринг JavaScript — як виявити та вирішити проблеми

Оновлено: 2020-06-01  
(4 хвилин читання)
SEO-та-рендеринг-JavaScript
Спеціалісти починають все частіше говорити за вплив мови JavaScript на SEO-оптимізацію. Досить часто при аналізі сайту виникають проблеми з його візуалізацією. Мова йде не лише про перегляд контенту, доступного читачу завдяки JS, але й про завантаження решти вмісту від Google. У статті нижче ми пояснимо, що таке JavaScript, чому він може викликати проблеми та як ці проблеми вирішити.

зміст

Що таке JavaScript та нащо він потрібен на сторінках свого сайту?

JavaScript — це обов'язковий елемент веб-програмування. В DevaGroup ми можемо побачити наскільки часто він став використовуватись в інтернет-сервісах —це видно під час проведення SEO-аудитів. Це мова програмування широкого використання, яка потрібна для створення динамічного генерування даних на сайті. HTML та CSS досі лишаються основними для написання сайту, але без JS на них не було б динаміки у відображені даних.

Як ми можемо реалізувати JS на сайтах?

Одним з прикладів, може бути інформаційній сайт, який надає можливість перегляду прямих трансляцій. Як ви можете бачити нижче, там працює автоматичне оновлення. 
 

Yak my mozhemo realizuvaty JS na saytakh?

Джерело: www.wiadomosci.wp.pl

 

Інакший спосіб використання JavaScript — пряма трансляція спортивних подій (наприклад, футбольних матчів) або модуль для коментарів, який працює в режимі реального часу.  З розвитком веб-галузі росте кількість сайтів, що використовує мову JS. Окрім створення динамічного контенту, JS використовується для вилучення даних з сайту та відправки їх в аналітичні інструменти. Як розмістити JS-скрипт в коді сторінки?

Скрипти JS можуть бути розміщені:

  • Всередені коду HTML данної підсторінки

mistse dlya rozmishchennya kodu js

  • В окремому файлі *.js (Тоді в коді підсторінки потрібно вписати шлях до цього файлу)

mistse dlya rozmishchennya kodu js

  • На зовнішньому сервері (наприклад, коди для відстеження або віджети соціальних мереж)

mistse dlya rozmishchennya kodu js

Найменше всього ми контролюємо скрипти, які розташовані за межами серверу (скрипти третіх сторін). Ми фактично не маємо жодного впливу на їх будову чи режим роботи. Як покращити їх завантаження, я розкажу нижче у статті. Тепер давайте перейдемо до впливу кодів JavaScript на SEO.
 

Вплив присутності JavaScript на SEO сайту

Мабуть, ви не раз чули, що JS погано впливає на SEO-оптимізацію або взагалі унеможливлює читання сайту. Це не зовсім правда. Не існує чіткого зв'язку між наявністю JS-коду та неможливістю відобразити контент на сайті . Google постійно вдосконалює свою технологію та заявляє, що JS-коди не заважають роботі сайту. Якщо хочете бути в курсі того, як Google перевіряє сайти за допомогою JS-технологій, пропоную переглянути відео, зроблено безпосередньо працівником Google: 

 

 

Якщо Google працює з JS, чому тоді усі досі вважають, що проблема в SEO? Причиною проблем є те, що Google не завжди правильно читає цей скрипт.

Існує дві причини виникнення проблеми:

  • Google не може прочитати JS-скрипти
  • Google не може повністю завантажити JS-код
     

У цих двох випадках дійсно можуть виникнути проблеми з SEO сайту. Вищезазначені проблеми пошукової системи є наслідком того, як Google займається візуалізацією та індексацію.

Я думаю, що зараз краще згадати за WRS (web rendering service) та, як відбувається процес візуалізації сторінки.
 

WRS (Web Rendering Service)

Що таке WRS? Це система, яка відповідає за візуалізацію сторінок сайтів. Як працює WRS? Google базує свою систему візуалізації на движку браузера Chrome. Досить часто я чую поради, щоб дізнатись як відбувається візуалізація, потрібно завантажити Chrome версії 41. Це не так. Чому? Це не актуальна інформація. Ще в травні 2019 у Google заявили, що WRS базується на найновішій та найстабільнішій версії Chromium – www.webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html. Важливо те, що для випуску нових більш стабільних версій, було оголошено проведення постійних оновлень Chromium. Ось чому Googlebota назвали “evergreen Googlebot”.

Тепер повернемося до способу завантаження сайту, про який говорилось у відео вище. У випадку сайтів з чистим HTML i JS це працюватиме за наступною схемою:

skhema "spivpratsi" js ta html

Джерело: www.youtube.com/watch?v=LXF8bM4g-J4
 

Google зчитує HTML-код сайту та миттєво індексує його вміст. Але ситуація трохи інакша для сайтів, що використовують JS-код. В цьому випадку кроків більше.

skhema "spivpratsi" js ta html

Джерело: www.youtube.com/watch?v=LXF8bM4g-J4
 

Google працює так: спочатку завантажує контент, створений через HTML-код та індексує його, потім завантажує увесь вміст JS-файлів та намагається його прочитати. Саме на цьому етапі можуть виникнути проблеми з читанням файлів, в наслідок чого і проблеми з SEO.

Основні причини проблем Google з читанням та підтримкою JS-коду – як заявляє сама Google в своїх відео – такі:

  • блокування доступу до файлів *.js (наприклад, в robots.txt). 
  • JS-файл завантажується занадто довго, тому Google припиняє спроби його прочитати.

fetching google

Джерело: www.youtube.com/watch?v=rq8sFkl0KnI
 

Хоча, у випадку блокування JS-файлів в robots.txt усе зовсім просто – цього не потрібно робити, але якщо причина у перевищеному бюджеті для рендерингу, тема буде набагато складнішою. Чому Google створює ліміти ? Про це у наступній частині статті.

Варто зазначити, що Google досі працює над вдосконаленням свого сервісу та намагається навчити систему розпізнавати ресурси, які не впливають на візуалізацію сайту. Тому, з часом, опираючись на попередні аналізи, такі ресурси не будуть враховуватись. Це означає, що Google завантажує та читає далеко не всі ресурси сайту. Такі дії мають зменшити непотрібні витрати апаратних ресурсів пошуковою машиною.
 

Обмеження Google

Поговоримо про тему апаратних обмежень. Google не може дозволити собі чекати цілу вічність завантаження ресурсів, оскільки це сповільнить увесь процес та зменшить кількість наданних сторінок сайту. Візуалізація пошкоджених сайтів може нашкодити усій системі.

Які Google називає причини відмови від обробки JS, для захисту своїх ресурсів?

Офіційні причини:

  • Занадто велика кількість ресурсів для завантаження,
  • Занадто великий обсяг ресурсів,
  • Відсутність кешу для сайту (за даними Google це має великий вплив на час завантаження сторінки без преривання процесу).

Інформація про те, як Google підходить до візуалізації JS та збереження своїх ресурсів, наведено у відео:

 

 

Працівник Google розповідає в ньому про різні причини серйозних проблем з візуалізацією. Ми дізнались, що Google припиняє візуалізацію, коли:

  • Пошкоджений JS-файл зациклюється,
  • Використовуємо JS для приховування (показ одного контенту для Google, та іншого користувачам),
  • Сайт намагається таємно майнити криптовалюту.

Зовнішні ресурси – чи маємо ми вплив на них?

На початку статті я згадував про різіні способи реалізації JS-коду на сайті. У випадках його додавання до HTML-коду або через зовнішні посилання, ми маємо вплив на побудову ресурсів, тому можемо їх оптимізувати, об'єднати або розділити. У випадку, використання зовнішніх ресурсів, візуалізація сторінки гальмуватиметься – рекомендую вам пошукати інформацію про, так звані, third-party JavaScript. Якщо завантаження HTML заблоковано через занадто довгий процес читання ресурсів, ми можемо відкласти його на період після повного завантаження HTML-коду, завдяки спеціальним атрибутам.
 

Для чого потрібні атрибути async i defer?

При повільному завантаженні ресурсів, як я вже казав, існує ризик, що Google припинить процес візуалізації сайту, не дійшовши до кінця HTML-коду. Саме тому варто відкласти завантаження скриптів на потім, щоб переконатись, що HTML-код та його зміст завантажаться першими. 

atrybuty async i defer

Джерело: www.web.dev/efficiently-load-third-party-javascript/
 

Вибір вищезазначених атрибутів залежить від ситуації та місця, де ми їх будемо реалізовувати. Щоб з'ясувати, який атрибут підійде саме нам та в яких ситуаціях, давайте обговоримо принцип дії кожного з них.
 

Async

Скрипт з атрибутом async спрацьовує відразу після завершення завантаження сайту, але перед завантаженням, так званого, load event. Важливою інформацією також буде те, що такі скрипти можуть завантажитись не в тому порядку, в якому вони розташовані в коді HTML.

atrybut async

Джерело: www.web.dev/efficiently-load-third-party-javascript/

Використовуйте атрибут async, якщо хочете, щоб скрипти завантажувались під час завантаження сторінки. 
 

Defer

Скрипт з атрибутом defer запускається після аналізу синтаксису HTML, та перед виконанням DOMContentLoaded. Важливо, що скрипти, завдяки цьому атрибуту, будуть завантажуватись в тому порядку, в якому вони розатшовані в коді HTML. Цей атрибут забезпечує порядок скриптів (згідно їх порядку в коді HTML) та запобігає блокуванню аналізу HTML.

atrybut async js ta html

Джерело: www.web.dev/efficiently-load-third-party-javascript/
 

Використовуйте атрибут defer, якщо ресурс не має впливу на завантаження сайту i його можна спокійно завантажити пізніше. До цього відноситься, наприклад, відео-програвач.

Більше іноформації про ці два атрибути можна побачити за посиланням: www.web.dev/efficiently-load-third-party-javascript/ 
 

Як вберегтись від проблем з JS?

Найбезпечнішим рішенням буде завантаження контенту та внутрішніх посилань без використання JS. В цьому випадку, Google в першу чергу прочитає та проіндексує контент, а лише потім буде читати вміст, згенерований кодом JS. У випадку, якщо виникнуть проблеми з JS-кодом  – ми будемо хоча б мати індексований контент та внутрішні посилання.

Також варто запам'ятати, що Google працює на движку Chrome, але виглядає на так само, як у випадку використання самого браузеру. Якщо якась важлива частина контенту завантажиться лише після прокрутки сторінки, надання згоди на зберігання файлів cookie або надання згоди на визначення вашої геолокації – Google не зможе цього прочитати. Не клікне на кнопку, не прокрутить сторінку.

Рішенням для сайтів з використанням JS можуть стати звичайні поради:

  • Якщо використовуєте JS на сайті, проконтролюйте, щоб контент та посилання були завантажені через HTML – внутрішні посилання за допомгою команди <a href=”/adres”>link</a> (а не лише командою onclick),
  • Використовуйте кеш, щоб зменшити вплив JS на бюджет виділений для візуалізації,
  • Використовуйте асинхронне завантаження зовнішніх ресурсів,
  • Якщо JS впливає на контент та інші важливі частини сайту – не блокуйте доступ Googlebot до них,
  • Намагайтесь зробити генерування адрес читабельним – адреси підсторінок domena.pl/podstona-serwisu, а не domena.pl#podstrona.
     

Як перевірити, чи впливає JavaScript на SEO сайту?

Найкращий спосіб перевірити свій сайт у цьому аспекті - це перевірка ефектів візуалізації Google Search Console. Після перевірки URL-адреси ми можемо перевірити, як саме Google „бачить” наш сайт.

perevirka vplyvu javascript na seo
 

Також, ми можемо перевірити HTML-код та побачити, чи відображаються там контент та посилання з нашого сайту.

perevirka vplyvu javascript na seo
 

В тому коді потрібно перевірити наявність контенту з сайту. Це можна зробити за допомогою команди „site:” в пошуку.

komanda „site:” v poshuku
 

Проте, цей метод не такий точний, як перевірка URL-адреси. У випадку, якщо ми не маємо доступу до GSC, ми можемо проаналізувати візуалізацію JS на сайті за допомогою зовнішніх інструментів. Нижче я покажу вам два інструменти, якими користуюсь особисто я, для дослідження контексту та візуалізації сайту.
 

Зовнішні інструменти для аналізу візуалізації

Перш ніж починати перевірку візуалізації сайту на сторонньому програмному забезпечені, зверніть увагу, що воно не належить корпорації Google. Тому ми не можемо бути впевнені в його ефективності. З власного досвіду я знаю, що в реальності, на жаль, вони показують багато помилок. Я використовую їх лише для початкового аналізу (наприклад, сайту на тестовому сервері). У випадку відсутності там проблем – я все одно роблю ще один аналіз у GSC. Нижче я розповім, які інструменти можна використати для цього.
 

Screaming Frog

Моделювання візуалізації можна здійснити за допомогою Screaming Frog. Там потрібно встановити максимум 5 секунд на очікування ресурсів (це логічне та стандартне очікування). Термін очікування Google залежить від багатьох факторів, але його варто зменшити до мінімуму, оскільки тоді ми зменшимо шанс того, що процес візуалізації перерветься (через занадто довгий час очікування).

Screaming Frog
 

Після старту роботи робота SF та отримання результату потрібно перевірити не лише попередній перегляд сайту, але й заблоковані ресурси, розташовані на екрані внизу зліва.

audyt v Screaming Frog
 

Якщо ви там знайдете ресурси, які впливають на побудову та контент сайту, потрібно вияснити, чому ви не маєте до них доступу.
 

Technical SEO

Ще один онлайн-інструмент, що я використовую щодня –www.technicalseo.com/tools/fetch-render/. Тут також варто встановити 5 секунд очікування та включити файл robots.txt .

Technical SEO
 

Після візуалізації сайту ми побачимо код (як HTML, так і код, що візуалізується в останню чергу) та попередній перегляд сайту.

Pislya vizualizatsiyi saytu my pobachymo kod HTML
 

В нижній частині останнього скріншота ми бачимо інформацію про недоступні ресурси. Так само, як і у випадку з попереднім інструментом, ми маємо перевірити, чи є в тому переліку ресурс, важливий для роботи сайту.
 

Різні способи візуалізації сайтів

Під час обговорення впливу SEO на видимість сайту, не забудьте про різні методи візуалізації. Правильний вибір метода має величезний вплив на результати візуалізації сайтів з великою кількістю JS-коду.
 

Візуалізація на стороні користувача

Раніше, візуалізація на стороні користувача була стандартом (client-side rendering). Що це означає? Як браузер, так і GoogleBot повинні прочитати сайт, його ресурси та завершити його візуалізацію. Саме в цей момент великий вплив на правильність побудови ресурсів має їх розмір, відстуність доступу до них, тощо. Проте, це не єдиний спосіб візуалізації сайту.
 

Візуалізація на стороні серверу

Інакшим підходом до цієї теми є виконання візуалізації на стороні серверу (server-side rendering). Цей метод рекомендується, коли Google Bot не може впоратись з візуалізацією на стороні користувача.

Принципи цього рішення такі:

  1. Візуалізація проходить повністю на сервері.
  2. Сервер надсилає до браузера (або до Google Bot) контент у чистому HTML-коді.
  3. Google Bot та інші типи інструментів для соціальних мереж не мають проблем з читанням вмісту.

Варто зазначити, що це рішення сильно впливатиме на швидкість. Сервер відправляє дані до браузера один раз, де вони зберігаються у вигляді кешу, саме тому більше не буде потреби в опитуванні серверу повторно.

Більше інформаціх про SSR на різних движках:

Динамічна візуалізація

Ще один спосіб візуалізації, полягає у використані технології, яка називається „динамічна візуалізація”. В цьому випадку ми створюємо гібрид, який поєднює в собі обидва вищезазначені способи.

skhema dynamichnoho renderu

Джерело: www.developers.google.com/search/docs/guides/dynamic-rendering
 

В залежності від того, хто надсилає запит на адресу, обирається один з двох шляхів:

  • Якщо сайт викликається користувачем у браузері – вона завантажиться традиційним методом, тобто на стороні користувача. Надається повніст. функціональний сайт з усіма елементами, написаними на JS.
  • Якщо запит надійшов від Google Bot (та будь-яких інших ботів, наприклад, від соціальних мереж), візуалізація відбуватиметься на стороні серверу. Боти отримають статичний сайт HTML та, завдяки цьому, зможуть прочитати його вміст.
     

Трохи звучить як обман Google? Що ще ми робимо для користувачів, а що для Google? Усе прозоро. Пам'ятайте, що ідея цього рішення полягає у наданні однакового контенту, лише різними методами. Ми не брешемо боту, а лише допомогаємо йому зрозуміти наш сайт.

Google також рекомендує це рішення – детальніше в документації Google (www.developers.google.com/search/docs/guides/dynamic-rendering) або у відео нижче:


Більше інформації на тему можливих технологій для візуалізації сайтів можете переглянути за посиланням: www.developers.google.com/web/updates/2019/02/rendering-on-the-web. Також, рекомендую ознайомитись з основною інформацією про SEO в контексті технологій JS: www.developers.google.com/search/docs/guides/javascript-seo-basics

Обговорюючи динамічну візуалізацію, не можна забувати про використання більш популярного PWA (Progressive Web Apps) та повязані з ним правила, яких слід дотримуватись у контексті SEO.
 

PWA (Progressive Web Apps)

PWA (Progressive Web Apps) - це тренд, що набуває швидкої популярності у виробників веб-додатків. Це гібридна технологія звичайних сайтів та звичних функцій, для мобільних додатків. На такий сайт ми можемо зайти так само, як і на традиційний сайт, а потім запускається те, що стає можливим завдяки PWA – можливість завантажити додаток на головний екран телефону, оновлення фонової інформації та можливість роботи офлайн. Це лише декілька з основних переваг PWA.

Я не буду описувати в деталях ідеї та принципи роботи цієї технології, але запрошую вас прочитати про неї за посиланням – www.medium.com/@deepusnath/4-points-to-keep-in-mind-before-introducing-progressive-web-apps-pwa-to-your-team-8dc66bcf6011.

Давайте перейдемо до найважливіших аспектів, на які потрібно звернути увагу, щоб PWA та SEO здружились. Ось необхідні кроки:

  1. Ми надаємо Google можливість візуалізації та індексації.
  2. Ми використовуємо лише працюючі та дружні URL (тут приблизно ті самі правила для створення підсторінок domena.pl/podstrona, що і для стандартних сайтів на HTML).
  3. Ми використовуємо канонічні теги .
  4. Ми використовуємо рідні елементи HTML (наприклад, <button> замість <div class=”button”>).
  5. Ми застосовуємо прогресивне вдосконалення.
  6. Ми дбаємо про ефективність.
  7. Ми надаємо однаковий контент як користувачам, так і роботам Google.
  8. Ми використовуємо атрибут „scrset” для фотографій, щоб відрегулювати їх розміри.
  9. Ми використовуємо кеш.
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  

Також, варто використовувати додаткові теги:

  • Структурні дані Schema.org,
  • Теги Open Graph та Twitter Card.

Також, пропоную вам ознайомитись з інформацією, що надає Google у відео:



 

Висновок

JavaScript –  це невід'ємна технологія для створення сайтів, чиї можливості потрібно демонструвати. Найбезпечніше генерувати контент прямо у файлі з HTML і налаштувати ресурси так, щоб вони не блокували процес візуалізації елементів HTML. Якщо, незважаючи на оптимізацію та побудову сайту, Google далі не може впоратись з контентом на сайті, створеним за допомогою JS – потрібно розглянути можливість зміни технології візуалізації контенту.

Іноді, єдиним рішеням є надання чистого HTML-коду, який стане результатом візуалізації на стороні серверу. Бажаю удачі в проведені аналізу та перевірці впливу JS на SEO Вашого сайту! Якщо у вас виникли проблеми в цьому аспекті – просто повідомте нам і ми знайдемо рішення.

Автор:
Marek Stokowski
SEO-спеціалист в агенції DevaGroup
www.stokowski.eu

Щодня він бореться за створення видимості, як великих сайтів для е-комерцій, так і службових сайтів. Він обожнює SEO-аудити та аналіз вихідного коду. У вільний час він веде блог Stokowski.eu або відпочиває, приймаючи участь в експедиціях на мотоциклах.

Ваші коментарі (0)
Команда WhitePress® залишає за собою право видаляти коментарі, які не відповідають Регламенту публікації коментарів або суперечать законодавству та хорошим манерам.

Адміністратором персональних даних осіб, які користуються вебсайтом whitepress.com та всіма його підсторінками (далі: Сервіс), в розумінні Регламенту Європейського Парламенту і Ради (ЄС) 2016/679 від 27 квітня 2016 року про захист фізичних осіб у зв'язку з опрацюванням персональних даних і про вільний рух таких даних, та про скасування Директиви 95/46/ЄС (далі: ЗРЗД) є спільно „WhitePress” Spółka z ograniczoną odpowiedzialnością із зареєстрованим офісом у м. Бельсько-Бяла (43-300), вул. Легіонув 26/28, зареєстрована у реєстрі підприємств Державного Судового Реєстру Республіки Польща (KRS), котрий веде районний суд м. Бельсько-Бяла, 8-ий Комерційний відділ KRS, під номером KRS 0000651339, NIP: 9372667797 (номер податкової ідентифікації), REGON: 243400145 (номер у Реєстрі суб'єктів господарювання) та інші компанії з Групи WhitePress (далі разом: Адміністратор).

Підписуючись на ньюзлетер, ви даєте згоду на надсилання вам за допомогою засобів електронної комунікації, зокрема електронної пошти, комерційної інформації щодо прямого маркетингу послуг і товарів, які пропонує компанія WhitePress sp. z o.o. та її довірені комерційні партнери, зацікавлені у проведенні маркетингу власних товарів або послуг. Правовою підставою для опрацювання ваших персональних даних є надана згода (ст. 6 п. 1 літ. a GDPR (ЗРЗД) та ст. 11 ЗУ «Про захист персональних даних»).

Ви можете відкликати згоду на опрацювання ваших персональних даних з метою реалізації маркетингових цілей у будь-який момент. Докладніше про опрацювання персональних даних та правові підстави для опрацювання персональних даних компанією WhitePress sp. z o.o., зокрема про ваші права, читайте у нашій Політиці конфіденційності.

Читати повністю
До цієї статті ще немає коментарів.

Рекомендовані статті