JavaScript і SEO ризикований коктейль Activis

JavaScript, який раніше обмежувався виключно інтерактивним використанням веб-сайтів, за останні роки зробив вражаюче повернення до того моменту, коли він став важливою мовою дизайну, зокрема, втіленою в популяризації останньої версії «PWA» (Прогресивна веб-програма). розроблений, щоб забезпечити безперебійну роботу незалежно від пристрою та типу використовуваної мережі.

ризикований

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

В основі проблеми: візуалізація сторінок

На відміну від традиційних візуалізацій, відомих як SSR (серверна візуалізація), коли сторінка повністю відновлюється при кожному натисканні користувача, візуалізації, створені в JavaScript, які називаються CSR (візуалізація на стороні клієнта), дозволяють легке завантаження сторінок і тим самим помітне покращення під час завантаження.

Практично прозора розробка для користувачів Інтернету, але не для пошукових систем, які змушені докорінно модифікувати своїх сканерів, щоб проіндексувати вміст сторінок і правильно класифікувати їх у своїх природних результатах.

Складності на всіх рівнях

Тому з боку двигуна головна перешкода полягає у розробці нових пристроїв індексації, здатних виконувати та інтерпретувати фреймворки JavaScript, вбудовані на веб-сайтах, що є складним і дорогим процесом.

По суті, для дослідження веб-сторінки не потрібен один, а два кроки:

  1. Відновлення HTML-коду сторінки традиційним сканером
  2. Виконання та інтерпретація коду JavaScript за допомогою розширення WRS (Web Rendering Service)

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

Що стосується SEO, то легко уявити холодний піт, що виникає під час оголошення проекту капітального ремонту КСВ ...

Нерівна підтримка двигунів

Його прямий конкурент, Bing, також, схоже, взяв цей стратегічний напрямок, але в цілому з меншою ефективністю.

В іншому світі Яндекс, Baidu та Naver продовжують не підтримувати сайти з КСВ.

Альтернативні рішення

Через відсутність простої та всебічної підтримки сьогодні перехід до архітектури КСВ є протипоказанням у багатьох випадках. На щастя, є альтернативні рішення:

КСВ із попереднім відтворенням (або динамічним відтворенням)

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

Цей метод, хоча технічно схожий на маскування та застарів Google

працює відносно добре, особливо в контексті міжнародної стратегії SEO. Єдиним недоліком є ​​необхідність у створенні та підтримці веб-сайту та його "резервної" функції, щоб уникнути втрати індексації з подальшим зниженням до сторінок двигуна.

Статична РСР

Рішення, що складається з використання фреймворку JavaScript (Angular, React або Vue.js) для генерації статичних сторінок, що обслуговуються як движками, так і користувачами Інтернету (наприклад, PHP або ASP.net на традиційних сайтах).

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

SSR з гідратацією

Рішення, фактично ідентичне Static SSR, але дозволяє оновити вміст на стороні користувача, викликаючи фреймворк JavaScript на статичній сторінці.

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

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

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