- Mobile-first
- Mobile-first timeline
- Що ж станеться з запуском мобільного індексу?
- рекомендації Google
- Як перевірити рекомендації?
- Налаштування Spider'a Screaming Frog
- Швидкі відповіді і додаткові елементи видачі
- Як потрапити в блок відповідей?
- структурні дані
- Як правильно використовувати розмітку для формату інтернет-магазину.
- голосовий пошук
- машинне навчання
- RankBrain
- Але працює він у нас?
Сьогодні ми поговоримо про тренди SEO в 2018 році.
Mobile-first
Для початку трохи статистичних даних.
Є ще цікава статистика. За останній рік частка мобільного трафіку в нашій частині Європи в сегменті e-commerce збільшилася практично на 30%. Якщо говорити конкретно, то на Prom.ua за останній рік мобільний трафік виріс на 13%. Ставати зрозуміло, чому пошукові машини приділяють так багато значанія мобільному трафіку.
Google робить все, щоб мобільний пошук став ще більш зручним і швидким для користувачів, тому переходить на Mobile-first-індексування. Це один із самих основних трендів seo в 2018. Якщо для вас важливо просування сайту на мобільних пристроях, то не забувайте про мобільний пошуку.
Mobile-first timeline
Що ми знали до сьогоднішнього дня?
Звичайно ж, ми знали, що Google використовує сигнали ранжирування, виходячи з даних, отриманих з деськтопной версії. У 2016 році Google повідомив про початок тестування мобільного індексу. І рівно через рік нова заява - поступовий перехід всіх сайтів на мобільний індекс.
Що ж станеться з запуском мобільного індексу?
В першу чергу будуть враховуватися результати роботи мобільної версії сайту.
У Google говорять, що якихось особливих зміни в ранжуванні не відбудеться. Але насправді варто розуміти, що індекс буде один. Результати видачі сайту на робочому столі будуть залежати від результатів мобільної версії. Відповідно, якщо ваш сайт довго завантажується, якщо він незручний або не має заголовків і важливих текстів, то це вплине на ранжування і на Мобайлі, і на робочому столі.
Покажу на прикладі.
Це десктопна версія одного з сайтів. І ми зараз проведемо пошук по шматочку тексту, зазначеного на скрині - пошук в мобільному Інтернеті.
Мобільна версія цього сайту виглядає наступним чином, і тексту в ній немає.
Проте сайт ранжируется і показується в мобільному Інтернеті на першому місці по цьому шматочку тексту.
Це говорить про те, що в першу чергу враховуються результати деськтопной версії. Але з іншого боку це несе незручність користувачеві, так як в сніпеті він бачить інформацію, розраховує побачити її на сторінці, переходить ... а інформації там немає.
Саме тому Google переходить на мобільний індекс.
Важливо розуміти, що mobile-first - це не Mobile ONLY. Якщо у сайту немає mobile-friendly-версії, в індекс буде включатися десктопна версія. Однак відсутність оптимізованої під мобільні пристрої версії може негативно позначитися на ранжуванні сайту, а ресурс, який буде більш зручним для мобільних користувачів, потенційно зможе отримувати більш високі позиції і в десктопном пошуку.
рекомендації Google
В кінці року Google надав свої рекомендації про те, що варто перевіряти вже зараз, щоб при включенні мобільного індексу у вас все було добре.
Важливо враховувати:
Швидкість завантаження. Google оновив свій інструмент PageSpeed Insights. Тепер він ще показує час завантаження сайту в реальному часі. І між іншим Prom.ua почав отримувати в оновленому інструменті більше балів за мобільну версію. Перевірте, можливо, в новій версії і ваш сайт отримує оцінки вище. Оптимізація швидкості завантаження дожна бути у вас в пріоритеті.
Зручність використання мобільної версії. Сторінки, незручні для користувачів, будуть отримувати рейтинг нижче. Або на них будуть проставлятися у видачі попередження про те, що з цієї сторінки незручно працювати.
Цікавий і якісний контент. Малося на увазі: на мобільній версії сайту, як і на деськтопной, повинні бути представлений основний контент. Такі дані як: метатеги, текст, основні картинки з атрибутами «alt», відео. Ну і звичайно ж, для магазинів - це товари і підгрупи.
Теги «canonical» і «alternate» рекомендували перевірити. Аlternate - це для тих сайтів, які використовують для мобільної версії інші URL. А canonical підійде для абсолютно будь-яких сайтів.
Перевірити атрибут hreflang для тих, хто використовує мовні версії.
Традиційно попереджає про те, що JavaScript CSS повинні бути відкриті для індексації пошуковим роботом.
З нововведень - структурні дані: мікророзмітки повинна бути як на мобільній версії сайту, так і на деськтопной.
Як перевірити рекомендації?
Вони це рекомендують, і що з цим робити, як це перевірити?
Перевірити це можна за допомогою такого інструменту, як Screaming Frog SEO Spider.
Я особисто використовую його, але є аналогічний інструмент від Netpeak. Порада: проскануйте сайт і отримаєте відповіді на ті питання, які рекомендував Google.
Налаштування Spider'a Screaming Frog
Зараз побіжно покажу налаштування скрипта Screaming Frog.
Спочатку нам потрібно зайти в налаштування самого робота, вимкнути check-бокси. Для того, щоб швидше пройшло сканування, і він не витрачав час на додаткові елементи. Сканування необхідно провести два рази. Один раз як звичайний Google-бот, другий раз - мобільний Google-бот.
Крім текстового контенту, повинні збігатися і на мобільній версії, і на деськтопной основні зображення з атрибутами Alt і основні відео. На всіх сторінках необхідні структурні дані, однакові метатеги, тобто title description. Зобов'язані бути h1, h2, canonical, hreflang, ну і звичайно ж, довжина контенту.
У першому і другому випадку ми робимо вивантаження в електронну таблицю і зводимо їх за допомогою функції VLOOKUP. Отримуємо приблизно таку таблицю.
Так, це неповна картина того, що показує ця програма. Але тим не менше навіть на цьому скрині можна побачити, що код відповіді на одній з мобільних версій не віддається, на одній немає тайтла і т. Д. Це початкове керівництво для оптимізації сайту.
Дуже часто при перевірці сайтів можна побачити, що мобільної версії віддаються неправильні коди відповіді. У багатьох випадках проставлений один і той же title на всіх сторінках, або h1 на всіх сторінках. Кожна стаття вашого сайту повинна мати унікальний заголовок.
Звичайно ж, варто перевіряти canonical, тому що на мобільній версії вони можуть вести на абсолютно різні, незрозумілі сторінки. Поки є час, необхідно провести перевірку, зібрати дані і віддати своїм програмістам або сеошників для подальшого виправлення.
Від редакції. Докладний SEO аналіз сайту або окремої сторінки можна отримати в такій програмі як SE Ranking. Як працювати на цій платформі читайте в статті «Гайд по SEO платформі SE Ranking» .
Тепер окремо хотілося б відзначити швидкість завантаження.
Фахівці Google провели дослідження і отримали такі кумедні дані. Середнє завантаження сайту (вони перевірили близько кілька десятків тисяч сайтів) становить 19 секунд. Але велика частина користувачів йде, якщо завантаження сайту перевищує 3 секунди. Три сайту з чотирьох вантажаться більше 10 секунд, але кожен другий користувач чекає швидкого завантаження.
Тому я рекомендую використовувати Accelerated mobile pages (AMP). Google займається нею вже 2 роки, активно просуваючи всюди. І вона дійсно покращує показники сайту. Спочатку вважалося, що AMP годиться тільки для новинних ресурсів і блогів. Але це вже давно не так! За допомогою таких компонентів, як AMP live-лист або AMP paint, можна створити сторінки з функціоналом інтернет-магазину і і використовувати їх.
Зараз існує 25 мільйонів сайтів, які використовують AMP. Створено 4 мільярди сторінок. І за даними Google, користувачі проводять в два рази більше часу на подібних сторінках. Це все призводить до збільшення конверсії і продажів. Як мінімум, рекомендую ознайомитися. Ресурсів, що дозволяють подивитися приклад і способи реалізації подібних технологій, багато.
Наприклад, ampbyexample.com , ampstart.com . І звичайно ж, в Developer, довідці Googlе, є окремий розділ, присвячений AMP. Дуже рекомендував би хоча б в новому році подивитися на цю технологію і реалізувати у себе на сайті.
Існує міф, що саме по собі використання AMP - це поліпшення ранжирування, якийсь бонус. Але насправді це не так.
Сама по собі технологія не дає бонус в ранжируванні, але AMP вирішує проблему користувачів зі слабким мобільним інтернетом. Відповідно, воно покращує швидкість завантаження. А ось сама швидкість завантаження є фактором ранжирування.
Відповідно, будь то ваша мобільна версія, будь то AMP або НЕ AMP, якщо швидко вантажиться, ви отримуєте якийсь бонус. Ви ранжіруетесь краще.
Самі представники Google, розповідаючи про AMP, показували забавний слайд з гоночними автомобілями на треку, і AMP був другим. Тобто вони пропонували використовувати AMP, як один з готових варіантів. Проте, якщо створити щось самостійно, це щось може бути швидше. Але потрібно розуміти, що це вимагає витрат, грошових і часових. У той час як AMP - вже готове рішення.
Швидкі відповіді і додаткові елементи видачі
Що таке швидкі відповіді?
Власне кажучи, це і є відповіді на запитання користувачів, що починаються зі слів: як, що, коли, де. Це самий верхній результат видачі, грубо кажучи, позиція № 0. Вже близько 30% запитів містить блок швидких відповідей. І цей блок поступово з'їдає CTR органічної видачі. Ось так він виглядає.
Існує кілька варіантів швидких відповідей, кілька видів.
Це параграф, список. Існують ще таблиці. Я часто чув, що в швидкі відповіді потрапляють виключно Вікіпедія і освітні сайти. Але насправді це не так. Як видно на прикладах, тут далеко не Вікіпедія, і потрапити в ці відповіді можливо.
Як потрапити в блок відповідей?
Google повідомляє, що немає якогось чіткого способу попадання в блок швидких відповідей. Але тим не менше, якщо структурувати свій контент, то потрапити туди дійсно можна.
Спочатку варто знайти запити, за якими вже показується подібний елемент. Використовувати можна Serpstat, у них є розділ контент-маркетингу, який дозволяє здійснювати пошук за такими запитами. Можна використовувати Ahrefs, Moz. Так чи інакше, після того, як ми виявили ці запити, нам потрібно створити контент з правильною структурою. Що я маю на увазі?
Питання користувача, сам запит, під який ми будемо оптимізувати контент, повинен міститися в форматі заголовка на початку сторінки. Я б рекомендував все-таки h2. Після нього повинен йти параграф з відповіддю, і ця відповідь не може перевищувати 58 слів. Це рівно та довжина, в якій розташовується текст в блоці швидких відповідей. Що стосується облікових відповідей, іноді виділені заголовком розділи і підпункти можуть бути використані пошукачем, як список.
Іноді ми відразу створюємо обліковий контент і кроки: зробіть це, це і це. І Googlе підбирає весь цей параграф, розміщує в блоці відповідей.
Але іноді кожен з цих підпунктів може бути доповнений параграфом тексту, в якому розписані додаткові відомості про те, що потрібно ще зробити. І в деяких випадках, досить поширених, Google ігнорує ці параграфи. Залишає тільки виділені підпункти, сам з них формує список і показує його в результатах пошуку.
AMP - це не зовсім конструктор. AMP - це видозмінена html, певна технологія написання коду сторінки, яка збільшує швидкість завантаження.
Сторінки з AMP у видачі позначаються окремим значком блискавки.
Для того, щоб показуватися в швидких відповідях, не обов'язково перебувати на першій позиції. Google дуже любить відповіді, що починаються зі слів, які логічно повинні нести відповідальність на це питання.
Ось приклад.
«Як встановити Windows 7?» - питання користувача. І початок: «Установка Windows 7 ...» і далі за текстом - «робіть те-то і те-то».
На цьому графіку видно, що далеко не кожен розширений відповідь показується з першого місця. Якщо у сайту, який займає першу позицію, не структурований контент, то пошукова система вибере ту сторінку, на якій контент структурований.
Звичайно ж, у великому процентному співвідношенні подібні блоки будуть показуватися з першого місця. Але за статистикою Moz, це відбувається далеко не завжди.
З приводу інших елементів видачі.
Власникам інтернет-магазинів можуть бути цікаві такі речі, як відео, додатки і локальний пошук. Для того, щоб потрапити в відео з цікавого запитом, якщо вони там дійсно є, необхідний свій YouTube-канал. Він теж повинен бути оптимізований.
Щоб потрапити в додаток по ASO, можна взагалі окремий вебінар робити. Але грубо кажучи, потрібно знайти запити, в яких вже показується даний елемент. Ці запити повинні бути розміщені в тексті вашого застосування в Play-маркеті. І при правильній оптимізації додаток буде показуватися в цій каруселі за запитом.
І звичайно ж, локальний пошук - додавання ваших компаній в Google-бізнес. Я б сказав, що це необхідна річ, так як потім за запитом, що стосується вашої діяльності, ви можете бути показані в подібному елементі. Відповідно, з вашим рейтингом це додаткове місце, з якого на ваш сайт можете отримати цільовий перехід.
В принципі, додаткових елементів у видачі, особливо в Мобайлі, насправді багато. І в залежності від того, який у вас сайт, блоки можуть бути такими: картинки, книги, підказки, історії, статті, каруселі картинок. Все залежить від тематики, в якій ви працюєте. Можна вивчати ці додаткові елементи і зробити так, що ваш сайт туди потрапить.
структурні дані
Представник Google, Гері Ілш, в кінці року заявив, що Google використовує структурні дані індексування і ранжирування сайту. Також структурні дані потрібні для відображень нових функції пошуку.
Він сказав про те, що необхідно використовувати не тільки ту розмітку, про яку написано в документації Google. Будь-який тип розмітки є на Schema.org. Проте, якщо використовувати розмітку, описану в документації Google, неправильно, то можна потрапити під санкції.
Як правильно використовувати розмітку для формату інтернет-магазину.
Тип розмітки - Product. У мікророзмітки є два плюси. Перший - це індексація і ранжування. А другий, якщо Google підтримує подібний тип розмітки, ви можете отримати гарний розширений сниппет в пошуковій системі. Будь то ціна, зірки, квитки, заходи і т. Д. Головне, використовувати всі за призначенням.
У жовтні минулого року Google оновив свою довідку, де вже чітко описують застосування розмітки Product для різних типів сторінки.
Якщо у нас є окрема сторінка, присвячена одному товару, ми можемо застосувати подібну розмітку. Якщо на цій сторінці користувач може поставити рейтинг цього товару, ми можемо застосувати ще розмітку Review. Відповідно, поставити собі зірки.
Якщо користувач не може фізично поставити рейтинг цього товару, є сутність відображення зірочок, але користувач з цієї сторінки фактично на це не впливає, то проставлення даного типу розмітки Review може спричинити санкції пошукової системи. Поки ви не знімете цю розмітку, сторінка пропаде з пошуку.
Також тип розмітки Product з відображенням в пошуковій системі (в сніпеті) може бути застосований до сторінці моделі. Тобто у нас є товар і є різні магазини, його продають. Можна застосувати в Product параметр «агрігейт оффер», в якому ми вказуємо High і low прайс. У видачі у нас буде проставлено розбіг цін «від» і «до».
В принципі, подібну розмітку можна застосовувати частково до категорії, лістингу товарів, де зібрана різнопланова продукція. Проте тут є певні хитрощі, тому потрібно бути акуратними.
Знову ж правильним використанням для лістингу є розмітка кожного окремого товару типу Product. При цьому Google не підтримує показ розширеного сниппета для категорій. Але бонус від цієї розмітки - це поліпшена індексація кожного окремого елемента. При цьому в довідці вказано важливий момент: якщо ви розмітили один елемент, то ви повинні розмітити всі подібні однотипні елементи на сторінці. В даному випадку це стосується не тільки Product, а й інших типів розмітки.
Ще раз повторюся, перш ніж намагатися впровадити якийсь із цих типів на своєму сайті, прочитайте довідку в Google. Там досить добре розписані обмеження, де не варто це використовувати. І дійсно загрожує санкціями. Дуже не хотілося б, щоб власники сайтів потрапляли в подібну ситуацію.
голосовий пошук
Фактично голосовий пошук - це заслуга асистентів, штучних інтелектів Google. Формуються відповіді в голосовому пошуку з блоків швидких відповідей (він не читає голосом відповідь, а просто показує на екрані).
Якщо будь-який голосовий асистент починає читати що-небудь, то, швидше за все, це відбувається з Google Knowledge Graph, з бази знань.
І впливати ми можемо на два типи таких відповідей:
Факти і інформація.
Локальний пошук.
Хоча насправді подібних типів відповідей там дуже багато. Аудиоинформация про фінанси і т. Д. Але вплинути на них ми не можемо. Тільки шляхом оптимізації свого контенту під швидкі відповіді ми дійсно можемо подати якісь інформаційні запити, що стосуються локального пошуку чогось у вашому регіоні.
Наприклад, «найсмачніша піца десь» або «в моєму районі».
Ви можете опинитися в блоці швидких відповідей, які показує голосовий пошук.
На Заході це стає все більш популярним трендом, бо люди все частіше використовують голосових асистентів. Оптимізуючи свій контент під швидкі відповіді, ми зможемо потрапляти в голосовий пошук.
машинне навчання
Одна з моїх улюблених тем останнім часом - RankBrain.
RankBrain
Один з трьох найбільш важливих факторів ранжирування у Googlе, в основі якого лежить нейронна мережа. Навчальна машина, яка повинна зрозуміти сенс запиту користувача і сенс сторінки, зіставити всі і дати відповідь.
За статистикою 15% Запитів, Щодня одержуваніх Google, нові. ВІН їх Ніколи НЕ бачив. Якщо уявити, що він обробляє мільярди запитів, то число 15%, яке здається невеликою, може виявитися в районі мільйонів нових запитів.
За допомогою математичних векторів, перетворень запитів і раніше заданих чисел і порівнювання таких чисел, Google може вивести змістову відповідність запитів вмісту сторінки. Сформувати видачу і показати її користувачеві.
Звичайно ж, спочатку даний алгоритм перевіряли люди. У нього була якась історія запитів. До нього потрапляв новий запит. Він порівнював з тим, що є у нього, формував видачу, показував, це перевіряли люди. Якщо відповідь влаштовував, то формувалася нова версія RankBrain, і вона виходила в світ.
Зараз він робить це більше автоматично. Є інформація про те, що інженерів Google попросили сформувати видачу за кількома запитами. Вони на 70% задовольнили підсумкового користувача. А RankBrain впорався на 80%, тому зараз більшою мірою він обробляє свої дані.
До чого це все? Що було до RankBrain?
Коли в Googlе не було подібного алгоритму, то його розуміння можна було порівняти, з розумінням трирічної дитини. Використовуючи досвід зарубіжних колег для того, щоб пояснити Google синоніми, нам би довелося створювати різні сторінки. У цих сторінках оптимізувати їх під прямі входження слів, і це виглядало б дуже роботизована.
Але Googlе підріс, йому виповнилося 19 років. І тепер він добре розуміє синоніми. Наприклад, сторінки, написаної під запит «Creepiest Photos» і слів «scary, forritying, terrifying», немає. Проте за будь-якими фразами, сполученням з цими словами в Googlе цей сайт ранжируется на високих позиціях. І це говорить нам про наступне. Що пошукова система за допомогою RankBrain пізнає зв'язок між словами, розуміє синоніми, групує слова в теми і розуміє сенс сторінки.
Google заявляє, що RankBrain працює на всіх мовах і у всіх країнах. Про 15% я вже говорив, і про його математичних векторах теж.
Найважливіший момент! RankBrain для визначення задоволеності користувача видачею використовує поведінкові чинники.
І ось статистика. 17 найважливіших факторів ранжирування за 2017 рік, які стосуються RankBrain, знаходяться на перших чотирьох місцях. Тобто прямі переходи з органіки, час на сайті, сторінок за сесію і показник відмови.
Значить, коли RankBrain сформував видачу, показав її користувачеві, він може зрозуміти, чи задоволений користувач видачею чи ні, тільки по поведінкових факторів.
Тобто, я зайшов в першу позицію видачі, не знайшов там потрібної інформації, практично відразу вийшов і зайшов на другу, третю. І ось коли я знайшов потрібний контент, побув на сайті якийсь певний час і зробив активні дії, то алгоритм зрозумів, що ось дійсно відповідь на моє запитання і два інших результату мене не задовольнили.
Якщо він збере таких даних більше, то з часом починає міняти позиції сайтів видачі. І по закордонних тенденціям чинники, який заміряє RankBrain, є основними в факторах ранжирування сайту.
Але працює він у нас?
Насправді Google гірше знає російську мову, ніж англійська. І якщо брати голосовий пошук, то наприклад, Google-асистент не розуміє російської. Є Google Now, який розуміє російську, але він дуже роботизований.
На західному ринку є приклади, коли слова міняються місцями. І в принципі, до RankBrain тут була різниця: відповіді змінювалися, але кількість - немає.
З появою RankBrain результати ідентичні.
Чи працює це у нас?
Для деяких типів запитів дійсно працює. Банально, часткова заміна запитів, кількість відповідей у видачі майже однакове, і більшість позицій у видачі однакове.
Але якщо говорити про якісь усталених комерційних запитах, типу ось таких: «купити ноутбук» і «ноутбук купити», то тут впливу RankBrain поки не помічаємо.
Зліва ви бачите позиції, і як вони змінювалися на правому скріншоті. Відповідно, велика різниця у відповідях і велика різниця в порядку.
Проте готуватися до того, що ситуація з російською мовою налагодиться, варто вже зараз.
А зараз в підборі запитів, крім стандартних, варто приділити увагу синонімів. І контент створювати саме з використанням синонімів. По-перше, він виглядає більш природно. По-друге, допомагає цим алгоритмом зрозуміти, що ви ранжіруетесь не тільки по одному запиту, а по групі схожих запитів. І він може згодом показувати вас за цими синонімів у видачі.
Зараз у західних фахівців пішла нова тема з приводу переміщення з низькочастотних запитів на середньочастотні. Це також пов'язано з машинним навчанням, так як вони хочуть описувати саме тематики. Конкретних кейсів роботи подібної стратегії у нас на даний момент немає, як і спростувань, що у нас це зараз не працює. І знову повторюся. Підбір із застосуванням синонімів і використання їх в тексті - це основна рекомендація щодо оптимізації свого сайту під даний алгоритм.
Запис вебінару:
Если Ви нашли помилки, будь ласка, віділіть фрагмент тексту и натісніть Ctrl + Enter
Що ж станеться з запуском мобільного індексу?Як перевірити рекомендації?
Вони це рекомендують, і що з цим робити, як це перевірити?
Як потрапити в блок відповідей?
Що я маю на увазі?
«Як встановити Windows 7?
До чого це все?
Що було до RankBrain?
Але працює він у нас?
Чи працює це у нас?