4 SEO-тактики, неофіційно підтримувані Google

1. Що Google неофіційно підтримує?
2. Канонічні теги, впроваджувані за допомогою JavaScript
3. Атрибути h reflang в анкорний посиланнях
4. Схема сканування AJAX
5. Що Google не підтримує
6. Директива c rawl d elay в файлі robots. txt
7. атрибути мови
8. Атрибути change frequency і priority в файлах Sitemap
9. Cookies
10. HTTP / 2
11. Підведемо підсумки

Автор - Сем Марсден (Sam Marsden), SEO та контент-менеджер в DeepCrawl

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

Застереження про відповідальність (щоб очистити свою совість, якщо ви вирішите впровадити щось із згаданого в даній статті): ці тактики не гарантують результат, але хоча б частково працюють.

Що Google неофіційно підтримує?

1. Директива n oindex в файлі robots. txt

Метатеги noindex, використовувані на рівні сторінки, - це перевірений і надійний спосіб закрити сторінки від попадання в пошукові індекси. Однак Google також враховує більшість директив у файлі robots.txt, включаючи noindex.

Офіційно співробітник Google Джон Мюллер заявив , Що не варто покладатися на директиву noindex в файлі robots.txt. Однак наше тестування в DeepCrawl показало , Що цей метод закриття сторінок від індексації і раніше працює.

На відміну від метатега noindex, директива noindex в файлі robots.txt надає більш точний і керований спосіб повідомити Google про те, що сторінка не повинна індексуватися. Цей метод прибирає плутанину в тому, які директиви мають більшу вагу, оскільки директиви в robots.txt важливіші, ніж директиви на рівні URL.

Використання noindex в robots.txt також переважно тому, що в даному випадку ви можете блокувати від індексації відразу групи URL, а не закривати їх по одному.

Як і будь-яку іншу директиву в robots.txt, ви можете протестувати noindex за допомогою Інструменту перевірки файлу robots.txt .

1. Канонічні теги, впроваджувані за допомогою JavaScript

На конференції Google I / O в травні Том Грінуей (Tom Greenaway) заявив , Що Google обробляє rel = canonical тільки при первісному отриманні сторінки. Якщо ж сайт покладається на рендеринг на стороні клієнта, то цей атрибут буде пропущений.

Якщо це правда, то тоді у SEO-фахівців, які вносять зміни через Диспетчер тегів Google, можливі проблеми.

Джон Мюллер повторив точку зору Грінуея в Twitter :

Власне, все зрозуміло, чи не так? Ні не зовсім.

Іоган Хенн (Eoghan Henn) і команда searchViu провели тестування , Яке показало, чому не варто вірити Google на слово.

Після додавання rel = canonical через Диспетчер тегів Google, Хенн виявив, що пошуковик враховує ці атрибути і правильно визначає канонічні сторінки. Отримані результати явно суперечать рекомендаціям Google.

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

Отже, який висновок можна зробити?

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

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

1. Атрибути h reflang в анкорний посиланнях

Зазвичай посилання з hreflang розміщуються на початку сторінки, заголовку відповіді або в файлах Sitemap, але чи підтримує Google ці атрибути в анкорний посиланнях?

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

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

Даний веб-сайт не додавав hreflang більше ніде, крім анкорний посилань, і в Search Console ми бачили, що десятки тисяч з них були враховані.

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

Зараз ми продовжуємо проводити тестування, щоб зрозуміти, чому одні атрибути підхоплюються, а інші - ні.

1. Схема сканування AJAX

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

Даний підхід передбачає використання #! для вказівки параметра, який дозволяє пошуковим системам переписувати URL-адресу та запитувати контент зі статичної сторінки.

На більшості AJAX-сайтів це рішення було погано реалізовано, але, на щастя, сьогодні такі рішення, як HTML5 History API дозволяють мати і динамічно завантаження контент, і нормальні URL. Крім того, Google також не стоїть на місці. В останні роки пошуковик значно поліпшив свої можливості в області сканування AJAX і необхідність застосування спеціальної схеми відпала. Підтримка цього рішення повинна була бути відключена до кінця другого кварталу 2018 року.

Зараз ми вже в третьому кварталі, а Джон Мюллер недавно заявив , Що пошуковик вже практично відмовився від схеми сканування AJAX. Тобто, хоча схема сканування AJAX офіційно скасована, але повністю Google від неї поки не відмовився.

Що Google не підтримує

У цій частині статті ми розглянемо зворотну сторону - ті речі, які Google насправді не підтримує. Принаймні, поки що.

1. Директива c rawl d elay в файлі robots. txt

На зорі інтернету було корисно використовувати директиву crawl delay у файлі robots.txt, щоб вказати, скільки секунд пошукові роботи повинні чекати перед відправкою кожного наступного запиту.

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

Якщо ж ви хочете змінити швидкість сканування сайту, то це можна зробити на вкладці «Налаштування сайту» в Search Console.

Варто зазначити, що не всі пошукові системи відмовилися від підтримки директиви crawl delay. Так, Bing і раніше її враховує.

1. атрибути мови

Google повністю ігнорує атрибут lang. Замість цього він використовує власну систему і визначає мову сторінки, аналізуючи текст.

1. Атрибути change frequency і priority в файлах Sitemap

Атрибути change frequency (частота оновлень сайту) і priority (пріоритет індексації сторінок) - ще один приклад ініціативи, покликаної поліпшити сканування, але не дала очікуваного результату через погану реалізації веб-майстрами.

Ідея полягала в тому, щоб вебмастера могли задати значення для кожного URL, яке б визначало, як часто вони повинні скануватися щодо інших URL на сайті в діапазоні від 0.0 до 1.0.

На жаль, поширеною практикою серед вебмайстрів був вибір найвищого пріоритету (1.0), що зробило всю цю систему марною.

Співробітник Google Гері Ілш недавно підтвердив , Що пошуковик не звертає уваги на значення priority, задані в файлах Sitemap, а замість цього покладається на власну логіку того, як часто повинна індексуватися сторінка.

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

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

1. Cookies

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

Google може використовувати cookies тільки в одному випадку: якщо контент не працює без них.

1. HTTP / 2

Впровадження HTTP / 2 може значно підвищити швидкість сайту. Однак в очах Google це не дає видимих ​​переваг, оскільки пошукова система використовує в скануванні HTTP / 1.1. Тому, на даний момент, впровадження HTTP / 2 вигідно тільки з точки зору поліпшення користувацького досвіду.

Підведемо підсумки

Безсумнівно, є й інші приклади, які тут не відображені. Але у мене і не було мети зробити цю статтю вичерпної.

Основні висновки:

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