Думаєте, Google не може впоратися з JavaScript? Подумайте ще раз. Адам Одетт ділиться результатами серії тестів, проведених його колегами в Merkle | RKG, щоб вивчити, як Google сканує та індексує різні функції JavaScript.

Ми підготували переклад його статті про результати серії тестів, важливих для сучасних оптимізаторів.

Коротко про результати:

1. Ми провели ряд тестів, які підтверджують, що Google здатний обробляти і індексувати JavaScript з безліччю реалізацій інтерфейсу. Ми також переконалися, що Google здатний візуалізувати цілу сторінку і читати DOM, таким чином, індексуючи динамічно генерується контент.

2. SEO-сигнали в DOM (заголовки сторінок, метаописания, метатеги і т.д.) заохочуються. Динамічний контент в DOM також сканується і індексується. Більш того, в деяких випадках DOM-сигнали можуть навіть взяти верх над суперечливими інструкціями в вихідному коді HTML.

Ми виявили, що Google не тільки обробляє різні типи подій JavaScript, але і індексує динамічно генерується контент. Як? Google читає DOM.

Що таке DOM?

Мало SEO-фахівців розуміють, що таке Document Object Model (Об'єктна модель документа), або DOM.

Що відбувається, коли браузер запитує веб-сторінку, і як в цьому бере участь DOM

Таблиця: Коли браузер запитує веб-сторінку:

1. Початкове з'єднання і браузер запитують веб-сторінку.
2. Сервер відправляє HTML-сторінку браузеру.
3. Браузер аналізує HTML-документ і формує DOM.
4. Браузер відправляє запит на додаткові ресурси.
5. Сервер (а) відправляють ресурси назад браузеру.
6. Браузер відображає сторінку.

Використовуваний в веб-браузерах DOM, по суті, - інтерфейс прикладного програмування, або API для розмітки і структурування даних, таких, як HTML і XML. Це інтерфейс, який дозволяє веб-браузеру складати структуровані документи.

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

DOM - це «міст», який з'єднує веб-сторінки і мови програмування: HTML піддається аналізу, JavaScript обробляється. Контент на веб-сторінці - це не тільки вихідний код, а й DOM, і цей факт робить його досить важливим.

Як JavaScript працює з інтерфейсом DOM

Серія тестів, які були проведені, і їх результати

Ми створили серію тестів, щоб вивчити, як різні функції JavaScript скануватимуться і індексуватися, якщо ізолювати Googlebot. Система управління була створена так, щоб переконатися, що дії по відношенню до URL будуть зрозумілі і в цьому випадку.

Давайте розглянемо декілька найбільш цікавих результатів детально:

Приклад однієї сторінки, використовуваної для тестування здібностей робота Googlebot в розумінні JavaScript

1. Переведення в JavaScript

Ми тестували поширені JavaScript-редіректи, змінюючи відображення сторінки, використовуючи для цього функцію window.location. Провели два тести: в тесті А використовувався абсолютний атрибут URL в window.location, в тесті B - відносний.

Результат: Google швидко слідував переадресації. З точки зору індексації, вони були інтерпретовані як 301 редирект - кінцевий URL-адресу в індексі Google замінили переслані посилання.

У наступному тесті ми використовували сторінку з хорошим авторитетом і реалізували переадресацію JavaScript на нову сторінку на сайті з точно таким же змістом. Оригінальний URL з'явився на першій сторінці Google популярних запитів.

Результат: як і очікувалося, Google пішов переадресації і оригінальна сторінка випала з індексу. Нова сторінка була проіндексована і негайно з'явилася у видачі на тих же позиціях за однаковими запитами. Схоже, це вказує на те, що з позиції ранжирування JavaScript редирект може (іноді) поводитися так само, як і постійний 301 редирект.

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

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

2. Посилання в JavaScript

Ми протестували різні типи посилань в JavaScript, написані різними типами кодів.

Один із прикладів - меню, що випадає з посиланнями. Зазвичай пошукові системи не переходили по цих посиланнях послідовно. Наш експеримент повинен був визначити, чи буде перехід за подією OnChange (подія при виборі опції зі списку). Важливо відзначити, що це специфічний тип виконання: ми просимо виконати дію, щоб змінити щось, а не примушуємо, як при переадресації JavaScript.

Приклад випадає вікна з вибором мови в Google для робочої сторінки

Результат: посилання були повністю просканувати і проіндексовані.

Ми також тестували стандартні посилання в JavaScript. Це найбільш поширений тип посилань, які оптимізатори традиційно радили змінити в звичайний текст. Ці тести включали посилання з такими атрибутами:

• Функція поза href пари «атрибут-значення» AVP (Attribute-Value Pair), але в межах а-тега ( "onClick");
• Функція всередині атрибута href AVP ( "javascript: window.location");
• Функція поза тега a, але названа всередині атрибута href AVP ( "javascript: openlink ()") і т.д.

Результат: посилання були повністю просканувати і проіндексовані.

Наш наступний тест був присвячений вивченню подальших обробників подій, як у випадку з onchange. Зокрема ми розглядали ідею використання рухи мишки як обробника подій і далі приховували URL змінними, які оброблялися після виникнення події (в цьому випадку onmousedown і onmouseout).

Результат: посилання були повністю просканувати і проіндексовані.

Пов'язані посилання ( Concatenated links ): Ми знали, що Google може обробляти JavaScript, але хотіли переконатися, що він розуміє змінні всередині коду. У цьому тесті ми конкатеніровалі рядок так, щоб URL виглядав так само, як і в разі звичайного побудови посилань, без використання JavaScript.

Результат: посилання були повністю просканувати і проіндексовані.

3. Динамічно додається контент

Це очевидно найважливіший пункт: динамічно додається текст, зображення, посилання і навігація. Якість текстового контенту важливо для розуміння змісту сторінки пошуковими системами. У зв'язку з поширенням динамічних сайтів оптимізаторів важливо розібратися в цьому питанні.

Ці тести були розроблені з метою перевірити динамічно додається текст в двох ситуаціях:

1. Тестування можливості пошукової системи враховувати динамічно додається текст, коли він знаходиться всередині HTML-коду сторінки.

2. Тестування можливості пошукової системи враховувати динамічно додається текст, коли він знаходиться поза HTML-коду сторінки (в зовнішньому файлі JavaScript).

Результат: в обох випадках текст сканувався і індексувався і сторінка ранжувати по контенту.

Також ми протестували глобальну навігацію клієнта, яка була розроблена на JavaScript, з усіма посиланнями в функції document.writeIn, і переконалися, що вони повністю індексуються. Слід зазначити, що саме цей тип функціональності в Google пояснює, як сайти, побудовані з використанням AngularJS framework і HTML5 (рushState), можуть бути відображені і проіндексовані Google, ранжуючи так само добре, як і звичайні статичні HTML-сторінки.

Ось чому важливо не блокувати для Googlebot доступ до зовнішніх файлів і засобів JavaScript.

Ймовірно, тому Google йде від підтримки принципів Ajax для SEO. Хто потребує HTML-знімках, якщо ви можете просто відобразити всю сторінку?

Наші тести показали однаковий результат незалежно від типу контенту. Наприклад, зображення були просканувати і проіндексовані при завантаженні в DOM. Ми навіть створили тест, де динамічно згенерували хлібні крихти за допомогою розмітки data-vocabulary.org і вставили його в DOM. В результаті хлібні крихти успішно досягли сниппета у видачі Google.

Відзначимо, що Google в даний час рекомендує розмітку JSON-LD для деякої структурованої інформації.

4. Динамічно додаються метадані та елементи сторінки

Ми динамічно додали в DOM різні теги, які мають критичне значення для SEO:

• Title сторінки
• Description
• метатег robots
• Атрибут rel = "canonical"

Результат: у всіх випадках теги добре сканувалися і вели себе так, як і повинні вести себе елементи в вихідному коді HTML.

5. Важливий приклад з тегом rel = "nofollow"

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

Наш тест в порівнянні вихідного коду і генерації анотації в DOM

Nofollow в вихідному коді працював так, як і очікувалося (посилання не індексувалася). Nofollow в DOM не спрацював (був перехід по посиланню, і сторінка проіндексувалася).

Причина тому - модифікація елемента a href в DOM сработалa занадто пізно: Google вже просканував посилання і поставив URL в чергу, до того, як була виконана функція JavaScript, яка додає тег rel = "nofollow". Як би там не було, якщо цілий a href елемент з атрибутом nofollow додати в DOM, nofollow відображається в той же час, що і посилання (і її URL), і таким чином обробляється.

висновки

Історично рекомендації оптимізаторів оберталися навколо використання «простого тексту» всюди, де це можливо. Динамічно генерований контент, Ajax і JavaScript посилання шкодили оптимізації під основні пошукові системи. Очевидно: це більше не стосується Google. JavaScript-посилання працюють так само, як і прості HTML-посилання (щодо їх ваги - ми не знаємо, що відбувається всередині алгоритму).

1. Переведення в JavaScript трактується так само, як і простий 301 редирект.

2. Динамічно додається контент, і навіть такі метасігнали, як rel canonical annotations, трактуються, як і HTML код, або запускаються після того, як вихідний HTML проіндексований з JavaScript в DOM.

3. Тепер Google повністю відображає сторінку і бачить DOM, а не просто вихідний код (пам'ятаєте, що потрібно давати доступ роботу Googlebot до зовнішніх файлів і засобів JavaScript).

Оригінал статті - http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157.