У світі миттєвого спілкування чат стає найкращим каналом зв'язку з клієнтами, але 45% компаній не просять користувачів навіть залишити відгук після завершення спілкування.
В наші дні найбільша проблема омніканального обслуговування клієнтів - це час відгуку. Клієнти очікують негайної реакції. Superoffice провела дослідження підтримки чатів на 1000 веб-сайтах з США і Європи. Чати оцінювалися тільки в години підтримки веб-сайту, причому питання задавалися по суті. Після завершення кожного чату оцінювалася якість за часом відповіді, часом очікування і загальним досвідом спілкування.
А що в результаті?
На 21% запитів в чаті підтримки не відповіли.
Середній час очікування реакції служби підтримки в чаті складає 2 хвилини 40 секунд.
55% компаній не пропонують відправити копію чату після завершення спілкування.
23% компаній не запитують контактну інформацію до початку чату.
Середній час обробки запиту в чаті становить 6 хвилин 50 секунд.
45% компаній не просять користувачів залишати відгуки після завершення чату.
Як перетворити чат в зручний і ефективний канал зв'язку з клієнтами
1. Якщо онлайн-чат є частиною вашої стратегії спілкування з клієнтами, важливо швидко реагувати на запити клієнтів. Якщо при використанні електронної пошти клієнти очікують відповіді протягом 6 годин, то в чаті - негайно. Найбільше розчарування клієнтів викликає звернення до компанії кілька разів з одного й того ж питання. На жаль, 1 з 5 чатів або 21% під час дослідження так і залишився без відповіді.
Пропонуйте чат як варіант спілкування, тільки якщо у вас є для цього ресурси. Хоча б просто вимикайте його, якщо немає кому відповісти. Чим більше запитів в чат ви ігноруєте, тим більше клієнтів ви втрачаєте.
2. Скоротіть час відповіді за допомогою заздалегідь написаних шаблонів. Люди терпіти не можуть чекати. Середній час очікування відповіді оператора після запуску чату становить 2 хвилини 40 секунд. Всього лише кілька операторів відповіли протягом 30 секунд (що забезпечило позитивний досвід клієнтів). Максимальний час очікування склав 9 хвилин.
Попередньо написаний шаблон скорочує час очікування відповіді, також можна, наприклад, створювати шаблони для найбільш поширених питань. І по можливості включіть посилання на більш детальну інформацію на своєму веб-сайті, наприклад відповіді на актуальні питання та бази знань, замість того, щоб вводити відповідь вручну. А найоптимальніший варіант це чатботи. Вони дійсно здатні змінити життя як бізнесу, так і клієнтів.
3. Персоналізуйте спілкування зі своїми клієнтами. Дивно, але до цього часу 23% компаній не запитують контактну інформацію до початку чату. Відсутність контактної інформації означає, що оператор чату не знає, з ким він спілкується. Попередній запит імені або адреси електронної пошти дозволить йому вибрати цінну інформацію з вашої CRM-системи заздалегідь для більш особистого обслуговування.
Згідно з дослідженням Economist Intelligence Unit, це призводить до скорочення часу обробки запиту і більш швидкому відгуку, що вважається найбільш важливим елементом для створення ідеального клієнтського досвіду.
4. Створюйте довгострокові позитивні враження. Після закінчення чату, замість того, щоб просто поставити галочку «виконано», відправте копію чату клієнту по електронній пошті. Наявність балки чату дозволяє клієнту продовжити спілкування в будь-який час. На жаль, більше половини (55%) чатів не пропонували таку можливість. А оператор легко може зробити копію розмови і відправити її клієнтові на email, але з 1000 компаній тільки одна виступила з такою ініціативою.
Пост-чат - також відмінний час, щоб запитати думку клієнтів про обслуговування. 45% компаній не запитували відгуки клієнтів після завершення чату. Чи був чат корисний? Чи були клієнти задоволені своїм досвідом? Якщо ви не запитаєте їх, ви ніколи не дізнаєтеся. Клієнти цінують, що їх просять дати зворотний зв'язок, але доступ до таких даних також допомагає виявляти проблемні місця, усувати і покращувати їх.
Важливо розуміти, що підтримка в чаті працює тільки в тому випадку, якщо за програмним забезпеченням стоїть хтось, хто відповідає клієнтам. Перш ніж вкладати гроші в чат, варто виділити ресурси для обробки запитів. В іншому випадку ви отримаєте порожній канал обслуговування клієнтів.
Текст про стереотипи і помилки, які побутують в ІТ. Про те, що розробник — це фахівець, який пише код, а тім лід — це не просто керівник групи.
Ми часто стикаємося з описом вакансій та запитами на кшталт «нам потрібен CPO у стартап». Після питання скільки в стартапі людей і продуктів, з'ясовується, що продуктів один або два, співробітників — не більше 30, а під CPO мається на увазі просто досвідчений менеджер продукту, який повинен працювати руками.
При цьому рекрутери покриваються холодним потом від пошуків, а стейкхолдери кричать, що їм потрібен саме CPO і чому його досі немає. Коли CPO знайдено, виявляється, що він зовсім не вирішує поточні завдання компанії, тому що, наприклад, відвик працювати руками.
Таку невідповідність реальної потреби та уявної ми зустрічаємо повсюдно.
Групи ролей
Ролі в ІТ можна розділити за кількома зрізами:
За активністю
За відповідальністю
За завантаженістю
Поділ за активністю:
Виробники
Управлінці
Перевіряючі
Поділ за відповідальністю:
Без відповідальності
З відповідальністю за якість
З фінансовою відповідальністю
Поділ за призначенням:
Наймані на позицію
Виховувані в колективі
Опис ролей
Назви ролей будуть використовуватись американські, звідки, по-суті, вони родом. Велика частина назв запозичена з англомовної спільноти.
Developer
Характеристики:
Займається виробництвом програмних алгоритмів
Не несе відповідальності за застосування результату і по фінансових ризиках
Розробник — це фахівець, який пише код, а тім лід — це не просто керівник групи
User Experience Designer (UX)
Характеристики:
Займається виробництвом карт користувацького досвіду
Несе відповідальності за застосування результату, але не несе відповідальність за фінансовими ризиками
Наймається на позицію
Ця роль вивчає і оцінює, як користувачі відносяться до розроблюваного програмного забезпечення. Вони виявляють простоту використання ПЗ, сприйняття цінності ПЗ, корисність ПЗ, ефективність ПЗ. Продумують і оцінюють процеси і сценарії використання ПЗ.
Помилково цю роль плутають, а часом і поєднують з роллю UI Designer (див. нижче). UX vs UI Designer відрізняються не тільки предметною областю, а й специфікою мислення. UX Designer більше про аналітику і систематизацію, ніж про ергономіку і естетику.
User Interface Designer (UI)
Характеристики:
Займається виробництвом графічної складової інтерфейсів
Не несе відповідальності за застосування результату і по фінансових ризиках
Наймається на позицію
Ця роль розробляє візуальну частину призначеного для користувача інтерфейсу. Основними цілями роботи UI дизайнера є: интуїтивність сприйняття, простота, юзабільність і естетика інтерфейсу ПЗ.
Quality Assurance (QA)
Характеристики:
Займається перевіркою результату
Не несе відповідальності за застосування результату і по фінансових ризиках
Наймається на позицію
QA займається тестуванням всього, як би дивно це не звучало.
Системний підхід фахівця QA дозволяє тестувати як програмний код, так і продуманість карт користувацького досвіду.
Фахівців на ринку праці в IT багато, а ось людей з системним підходом, необхідним багажем знань і умінь — одиниці
Також дуже важливий аспект роботи фахівця QA — планування, тобто вміння складати тест план, слідувати йому, готувати звіти згідно з підготовленим планом. Фахівців QA на ринку праці багато, а ось людей з системним підходом, необхідним багажем знань і умінь — одиниці.
Human Resource (HR)
Характеристики:
Займається первинним підбором кандидатів згідно вимог
Несе часткову відповідальність за результат, але не несе відповідальність за фінансовими ризиками
Наймається на позицію
HR займається первинним підбором кандидатів згідно вимог, забезпечує прозоре проходження всіх етапів співбесід при працевлаштуванні.
Обов'язки HR часто замішані з наступною роллю, яка на більшості ринків праці трактується так, як хочеться керівництву компанії.
Team Leader
Характеристики:
Відповідає за роботу групи фахівців
Несе відповідальності за командну роботу, не несе фінансових ризиків
Вирощується в колективі
Team Leader забезпечує комфортні умови роботи колективу і підтримує високий рівень її ефективності. Дана роль не зобов'язана знати специфіку роботи команди досконально. Для прикладу, якщо мова про Team Leader в групі розробників, то він не зобов'язаний бути програмістом, йому достатньо мати знання про організацію праці, процеси, що протікають під час виробництва. Але на практиці так історично склалося, що найбільш досвідчених програмістів ставлять на цю позицію, що є класичною помилкою управління.
Це важливо розуміти:
Team Leader завжди вирощується в середовищі, це єдиний спосіб заробити авторитет в групі людей; немає авторитету, ніхто не буде слухати Team Leader, процеси йтимуть своїм шляхом
Можна процес вирощування прискорити, найнявши одного з досвідчених Team Leader, але в колектив він повинен потрапити спершу як рядовий фахівець, заробити авторитет, тільки потім перейти на цільову позицію
Роль більше не про управління командою, не про виробництво, а про рішення проблем в роботі команди, налагодження комунікації всередині команди, вибудовування комфортних умов виробництва
Team Leader зобов'язаний володіти аналітичними навичками та системним поглядом; просто робити, щоб всім було "добре" мало, основне завдання — постійне вимірювання внутрішніх метрик команди, як соціальних, так і виробничих, зміна процесів для підвищення результативності
Чому досвідчений розробник флегматик або меланхолік не підходить на цю роль, думаю, тепер стало очевидним.
Tech Leader
Характеристики:
Відповідає за грамотний аргументований вибір технічних рішень
Несе часткову відповідальність за результат, але не несе відповідальність за фінансовими ризиками
Вирощується в колективі
Особливостей всіх ролей, в назві яких є слово Leader, є те, що всі вони вирощуються в колективі (див. вище).
Але дану роль ми вирішили виділити, так як, на практиці, її найчастіше плутають з роллю Team Leader.
Головною особливістю ролі полягає те, що на її позицію найчастіше потрапляють досвідчені програмісти рівня Senior
Tech Leader так само вирощується в колективі, команді потрібен авторитет, щоб впевнено доносити свої думки і рішення з технічних питань.
Tech Leader торкається таких аспектів роботи команди:
Відповідальний вибір стороннього ПЗ для проекту
Рекомендація по вибору конкретного алгоритму або архітектурного рішення при виробництві ПЗ
Визначення технічних особливостей в процесах виробництва
Головною особливістю цієї ролі полягає те, що на її позицію найчастіше потрапляють саме флегматики або меланхоліки. Так складається, що досвідчені програмісти мають саме цей тип темпераменту.
Scrum Master
З появою термінів Scrum, Agile, KanBan, гнучкі методології, і інші теоретичні знання, які вкрай не приносять користі без практики/досвіду, до команд розробки стали прикріплювати роль Scram Master.
Характеристики:
відповідає за грамотнє застосування тієї чи іншої гнучкої методології (буває, що навіть тієї, яка не стосується Scrum взагалі)
несе часткову відповідальність за результат, але не несе відповідальність за фінансовими ризиками
наймається на позицію
Чому ми вирішили описати дану роль? Так склалося, що цю роль часто плутають з Project Manager.
Давайте з'ясуємо ситуацію. Scrum Master — це фахівець, який допомагає команді застосовувати методологію Scrum правильно, пояснює правила методології, контролює їх виконання.
Важливим моментом тут є те, що фахівець не контролює виконання проекту, він контролює саме виконання правильної роботи з методологією, роблячи команду "гнучкою".
Project Manager (PM)
Характеристики:
відповідає за старт, ведення і здачу проектних робіт
несе повну відповідальність за результат, несе часткову відповідальність за фінансовими ризиками
наймається на позицію
Ця роль класичного управлінця процесами. Робота над проектом починається з Project Manager`а, ведеться (ставляться завдання), контролюється (контроль якості та ефективності), і здається теж ним. У більшості компаній Project Manager управляє проектним фондом. Про грамотний розрахунок по digital-проекту читайте в цій статті. Коли швидкість реалізації швидше планованих термінів проекту, проектний фонд утилізується не повністю, залишається частина грошей, які за результатом успішної здачі проекту розподіляється на премії учасників. Розподілом також займається Project Manager.
Семантичний кокон - це SEO-стратегія внутрішньої перелінковки, розроблена французьким дослідником Laurent Bourelly, спрямована на оптимізацію внутрішньої архітектури сайту шляхом семантичної класифікації контенту. При цьому сторінки сайту організовуються в ієрархічному порядку з використанням семантичної близькості сторінок і блоків контенту. Стратегія була розроблена в 2013 році у Франції, де отримала вкрай широке поширення, і є розвитком SILO-структури. За межами Франції концепція семантичного кокона слабо відома, незважаючи на те, що така структура показує значно кращі результати, ніж традиційна SILO архітектура сайту.
Концепція семантичного кокона
Концепція семантичного кокона - це стратегія перелінковки внутрішніх сторінок сайту і контекстуалізації редакційного контенту. Застосовується для кращого позиціонування сторінок по відношенню до запитів користувачів. Посилання проставляються таким чином, щоб була можливість зв'язати всі семантично однорідні сторінки кокона і гарантувати, що цільова сторінка, яка оптимізована під сильний високочастотний запит, просувається у видачі пошукової системи. Кінцева мета створення кокона - отримати точний цільовий трафік для кожної сторінки.
У якості відправної точки беруться до уваги запити користувачів Інтернету, які генерують найбільшу кількість цільового трафіку. При цьому необхідно передбачити майбутні запити, пов'язані з уже знайденими, під час пошуку ключових слів. Саме на цих запитах буде створена архітектура кокона.
Контент буде організований в бункерах, кожен з яких представляє собою гілку деревовидної структури, що складається з групи ієрархічних елементів семантично близьких один до одного. Бункер є ексклюзивним, так як різні теми будуть відокремлені одна від одної. Редакційний контент в кожному елементі бункера оптимізується під одне або кілька ключових слів, які відповідають на можливі запити користувачів. Контент має посилання, що ведуть до відповідей на запити, які знаходяться в тому ж бункері, вгорі, паралельно або знизу по ієрархії кокона.
Ефективність семантичного кокона повністю залежить від якості контенту та правильної перелінковки семантично близьких сторінок.
Архітектура звичайного сайту і сайту з семантичними коконами
Важливо: У будь-якого семантичного кокона є два важливих компоненти - структурна і смислова (семантична):
Структурний аспект - це ті посилання перелінковки, що видно на представлених вище зображеннях;
Семантичний (смисловий) аспект - для створення посилання необхідні вагомі підстави, наприклад семантична близькість контенту.
Без розуміння цих аспектів, цінність кокона буде прямувати до нуля. Він просто не буде працювати.
Класична структура кокона
Давайте розберемо як організована перелінковка в класичному семантичному коконі, поки не торкаючись смислових аспектів. Це необхідно для поетапного вивчення принципів побудови семантичного кокона на реальних сайтах.
Оскільки розробка кокона здійснена французами, то вони, як вкрай креативна нація, люблять давати всьому власні визначення та найменування. Наприклад, взаємозв'язок між окремими складовими кокона вони представляють як матріархальні взаємини.
Матріархальна організація
Зверху знаходиться цільова сторінка, зазвичай звана «мати». Контент материнської сторінки тісно пов'язаний з ВЧ ключами.
У кожної материнської сторінки є дочки - сторінки більш широко розкривають окремі аспекти материнської сторінки. Якщо обговорювати сторінки другого рівня, то між собою вони є «сестрами». Іноді, сторінки другого рівня називають «змішаними» сторінками.
У свою чергу у дочірніх сторінок другого рівня є власні дочірні сторінки (вже третього рівня). Вони також будуть сестрами для всіх сторінок третього рівня. Ще їх називають «додатковими» сторінками.
Наочно це представлено на малюнку.
Матріархальна структура семантичного кокона
Зміст змішаних сторінок
Розглянемо як організована сторінка другого рівня, дочірня для материнської.
Спочатку йде H1 - заголовок сторінки, на якій ми знаходимося.
Відразу після нього йде вступний абзац, який розкриває тематику сторінки в кілька рядків. Також з цього абзацу ставимо посилання на материнську сторінку з оптимізованим текстом прив'язки до батьківської сторінки (тобто на сторінку верхнього рівня). Текст посилання (якір) буде містити головне ключове слово батьківської сторінки.
Чим точніше буде спозиціоноване посилання на батьківську сторінку - тим краще. Тому можна використовувати якорі на материнській сторінці і посилання на поточній сторінці можна направити точно на потрібний шматок контенту батьківської сторінки (використовуючи на посиланні #).
Далі йде H2 - заголовок, який описує тему 1-й дочірньої сторінки для поточної (сторінка нижнього, 3 рівня).
Далі йде абзац, де в кількох рядках ви пояснюєте, що відвідувач знайде на 1-й дочірній (додатковій) сторінці. Це буде опис того, про що ця сторінка в цілому. У цьому невеликому абзаці ви також розміщуєте посилання на цю першу дочірню сторінку. Якір посилання буде описувати зміст 1-ї додаткової сторінки.
Далі йде текст, необхідний для часткового розкриття змісту поточної сторінки.
Після цього ставимо ще один H2 - заголовок, який описує тему 2-й дочірньої сторінки (сторінка нижнього рівня).
Ви знову пишете короткий виклад того, що буде змістом 2-й дочірньої сторінки нижнього рівня. Ви також розміщуєте в цьому абзаці посилання на цю другу дочірню сторінку.
Далі йде текст, необхідний для часткового розкриття змісту поточної сторінки.
Проставляємо знову H2 - заголовок, який описує тему 3-й дочірньої сторінки (сторінка нижнього рівня).
Як пояснювалося раніше, в одному абзаці уявіть вміст 3-й дочірньої сторінки. Ви вставляєте посилання на цю третю додаткову сторінку. Текст цього посилання повинен містити опис предмета даної 3-й додаткової сторінки.
Далі йде текст, необхідний для часткового або остаточного розкриття змісту поточної сторінки.
Ви робите стільки H2, скільки у вас є дочірніх сторінок (сторінок третього рівня).
Рекомендується мати, як мінімум, 5 дочірніх сторінок на 1 материнську сторінку, отже у вас буде 5 заголовків H2.
В самому кінці сторінки вам необхідно організувати перелінковку між сестринськими сторінками - тобто сторінками одного рівня. Як правило, для цього організовують блок «На ту ж тему» або «Дізнатися більше» і проставляються анкорні посилання з розведеними ключами (або просто найменуванням сторінки) на найбільш близькі за змістом (або на всі) сестринські сторінки.
В окремих випадках рекомендується дати опис в 1 реченні, що є на сестринській сторінці (15 слів до посилання і 15 слів після посилання) і використовувати більш оптимізовані ключі.
Зміст додаткових сторінок
Класична структура додаткової сторінки (сторінки 3 рівня) така.
H1 - заголовок сторінки, на якій ми знаходимося.
Далі йде вступний абзац, що розкриває тематику сторінки в декількох рядках. У цьому абзаці необхідно розмістити посилання з оптимізованим ключовим словом на батьківську сторінку (тобто сторінку першого рівня). Текст посилання (якір) буде містити головне ключове слово «материнської» сторінки.
Дехто ставить посилання не на сторінку-бабусю (сторінки першого рівня), а на материнську сторінку (сторінки другого рівня). Це теж є допустимим, в залежності від того де у вас розташовані блоки заклику до дії.
Інша частина контенту виглядає класично. Пишіть контент, розділяючи його на частини і структуруючи, використовуючи при цьому розмітку h2... h6. Додавайте медіа матеріали, списки, абзаци тощо. Створюйте зручний для читання і сприйняття контент.
Якість контенту має бути максимальною.
Внизу контенту знову зв'яжіть «сестринські» сторінки в блоці «Дивіться також» або «Матеріали на ту ж тему». Зверніть увагу, що ви можете пов'язувати не тільки «сестринські сторінки» (тобто не тільки сторінки 1.1., 1.2., 1.3,), але і сторінки, які мають іншого батька в межах кокона (тобто, наприклад, 2.1. , 2.2. або 2.4).
Ви можете інтегрувати в контент зовнішнє посилання, для підтвердження достовірності матеріалів. Розташовувати його слід в контенті після H2. Зовнішнє посилання повинно вести на сайт тієї ж тематики і надавати джерело додаткової інформації з даної теми.
Призначення сторінок семантичного кокона
Сторінки семантичного кокона, правильно перелінковані, з урахуванням семантичної близькості контенту, створюють дуже сильні зв'язки.
Батьківська сторінка (материнська/індексна/цільова сторінка) отримує вагу з дочірніх сторінок. Французи називають цей процес «висмоктуванням» змішаних сторінок.
Дочірня (змішана) сторінка виштовхує «батьківську» сторінку, при цьому «висмоктує» додаткові сторінки (Дочірні до неї) і зв'язується зі сторінками- сестрами.
Додаткові сторінки (внучки) вони «виштовхують» змішану сторінку (їхню мати) або батьківську сторінку і пов'язують між собою сторінки третього рівня (посилання між сестрами).
Приклад реалізації класичного кокона
Припустимо, ви є власником онлайн магазину з продажу взуття. Крім магазину на сайті є хороший блог з корисними статтями.
Припустимо, на сайт прийшов відвідувач, якому потрібна пара взуття для походів. Тобто він шукає собі міцне, непромокаюче в непогоду туристичне взуття для походів або активного відпочинку - трекінгу, хайкінгу, трейлраннінгу, водного або може гірського туризму.
Таким чином головне ключове слово нашого кокона буде «туристичне взуття» або «взуття для туризму». Ми маємо в своєму розпорядженні їх у верхній частині кокона, оптимізуємо сторінку під них. Нижче в коконі будуть знаходитись сторінки, де будуть розглядатися інші пов'язані запити, які значно посилюють і розкривають основну тематику (взуття для туризму). Така структура гарантує легке просування основної і підтримуючих сторінок у видачі ПС. При цьому основна сторінка підтримується не тільки транзакційними запитами, як середньочастотними так і низькочастотними, а й інформаційними запитами, заснованими на наміри відвідувача.
Наприклад, ми групуємо відміне взуття на сторінках нижчого рівня не за брендами і цінами, а за застосуванням. Тобто ми робимо сторінки для:
взуття для походів по горах - якщо наш відвідувач захотів стати альпіністом. Сторінки нижчого рівня цієї гілки можуть групувати і «продавати» взуття для високогір'я, або для подорожей по горах Криму, Карпат і ін.
взуття для походів по лісах - можливо відвідувач захотів зайнятися трекингом. Нижчі сторінки цієї гілки збирають і групують взуття для походів по лісах Полісся або вологих лісах з заболоченою місцевістю або по лісах Чернігівщини тощо.
взуття для зарубіжного туризму - можливо відвідувач хоче поїхати в Сахару і Антарктиду і ми групуємо взуття на сторінках нижчого рівня у вигляді взуття для походів по савані або взуття для Антарктиди, в кінці-кінців взуття для вилазок в гори Туреччини або для забігів з пірамід Єгипту.
Далі ми можемо підключити в кокон сторінки з інформаційними запитами, а також посилатися з кокона на якісь зовнішні корисні ресурси, наприклад за такими тематиками:
Ремонт і догляд за туристичним взуттям
Необхідні аксесуари для піших походів
Запобіжні заходи в походах
Як правильно вибрати розмір взуття
Як правильно сушити взуття в походах
Як уникнути травми ніг в походах
Цікаві маршрути для походів по Карпатах, Азії, Туреччини, Антарктиді
Посилання на туристичні клуби
Таким чином, ми демонструємо Google, що відвідувач і майбутній клієнт дійсно знайде собі пару туристичного взуття, тому що семантичний кокон розроблений з урахуванням вимог відвідувачів і вашого наміру вивчити потенційного клієнта, поступово з'ясовуючи реальну потребу відвідувача і, нарешті, надати відвідувачу товар, який йому дійсно підходить.
Фактично, семантичний кокон грає роль своєрідного продавця, який уважно вислуховує відвідувача і направляє покупця до потрібного відділу магазину, щоб він підібрав собі найбільш підходящий для нього товар.
Сучасні семантичні кокони
Семантичні кокони пройшли досить довгий шлях розвитку і вдосконалення. Класичні семантичні кокони побудовані на жорсткій ієрархії і вже потім на семантичних зв'язках контенту.
Сайт, побудований на класичних семантичних коконах
Сучасні семантичні кокони вже не мають ні материнських, ні дочірніх сторінок, тобто сталася повна відмова від жорсткої «підлеглої» архітектури. Сучасні кокони засновані тільки на ретельно розрахованих семантичних зв'язках.
Сайт, побудований на семантичних зв'язках
Такі зв'язки досить важко розраховувати і створювати руками. І тому ми переходимо до вивчення концепції метамотів.
Що таке метамот
Метамот - це чергове поняття, розроблене і введене в обіг французькими оптимізаторами. По суті - це такі собі семантичні сутності, що складаються з декількох нероздільних лексик (слів-сигналів).
Ці лексики в сукупності утворюють сигнал, що дозволяє Google оцінити актуальність і відповідність контенту певної тематики. Використання лексик, розрахованих на основі даних видачі Google дозволяє створювати вкрай релевантні сторінки.
Крім того, лексики дозволяють спрогнозувати з достатньою достовірністю необхідну перелінковку - тобто вказати які сторінки з якою ми можемо пов'язати.
Більш того, для підвищення релевантності зв'язків поблизу анкорів необхідно використовувати власні лексики, тематичні лінки сторінок.
Отже, метамоти необхідні для:
написання релевантних текстів
для розрахунку найбільш ефективних зв'язків у семантичному коконі.
Метамоти ніяк не впливають на SEO, не є сигналом ранжування. Вони тільки дозволяють максимально оптимізувати структуру перелінковки і «доводять» Google, що наші внутрішні посилання максимально актуальні і релевантні.
Детальніше про теорію метамотів ви можете почитати на cocon.se, там же є кілька робочих прикладів.
Розглянемо один з них, присвячений життю гігантських панд в США.
Архів з розрахованим семантичним коконом про життя гігантських панд в США
Ми скачали демо архів кокона, розміром в 500 з гаком сторінок і тепер давайте подивимося що вдають із себе ці метамоти.
Відкриваємо будь-яку з розрахованих сторінок.
приклад метамота
Перед вами приклад метамота, де є і редакційне завдання на створення контенту і розраховані сторінки, з якими необхідно залінкувати дану сторінку.
Тут:
тематика поточної сторінки
лексики, які потрібно вжити на сторінці (в розрахунку на 1000 слів)
розраховані посилання, які потрібно ставити в певному місці контенту
лексики, які потрібно вжити в абзаці з посиланням (15 слів до або після анкора посилання)
Власне, метамот цим не обмежується, там для кожної сторінки кокона даються рекомендації про те чи потрібно додавати зображення, відео або може бути посилання на вікіпедію.
Залишає це вам для самостійного вивчення на cocon.se.
Принципи семантичних зв'язків
Дві сторінки можуть бути пов'язані одна з одною, якщо деякі їх абзаци можуть доповнювати один одного. Сторінки не лінкуются, якщо контент цих сторінок розкриває одну і ту ж тему. Саме зміст повинен керувати перелінковкою, а не тематика.
Приклад: сторінка Моцарта може містити посилання на сторінку його рідного міста (Зальцбург). Але також необхідно, щоб на сторінці міста говорилося про те, що Моцарт народився в Зальцбурзі. Зверніть увагу, що тематики «композитор» і «місто» не збігаються, але сторінки доповнюють один одного за змістом.
Існує кілька правил використання метамотів. Наприклад:
Серед розрахованих лексик для посилань, потрібно використовувати мінімум 3, найбільш природні.
Посилання проставляються в одному абзаці разом з лексикою. Використовуйте в абзаці не більше 3-4 речень.
Відстань між посиланнями і лексика обмежена. Це максимум 15 слів по обидві сторони від посилання.
Ніщо не заважає мати 2 посилання в одному абзаці. Для цього вони повинні мати одні й ті ж лексики.
Точні анкори на посиланні не приносять користі при перелінковці семантичного кокона. Враховується тільки контекст (частиною якого є анкор). Посилання - це якась обіцянка, дана користувачу про зміст контексту. Користувач повинен чітко зрозуміти, що знаходиться по ту сторону посилання.
Посилання має бути націлене на конкретний абзац. Отже, використовуйте посилання-якоря (Посилання-якір - це звичайне посилання, в адресі якої використовується символ #, після якого йде ідентифікатор елемента. Ідентифікатор створюється за допомогою атрибута id у того тега, до якого треба перейти при натисканні на посилання.). Не змушуйте користувача читати всю цільову сторінку тільки для отримання додаткової інформації.
Висновок
Ми лише прочинили вам теорію семантичного кокона. Сподіваємося, що ви самостійно почитаєте літературу на цю тематику і, можливо, зважитеся на впровадження кокона на власному сайті.
Складається враження, що весь останній рік SEO-спільнота тільки і робить, що обговорює нову абревіатуру, створену Google, - E-A-T (компетентність, авторитетність, надійність).
З 1 серпня 2018 року Google почав випускати серію масштабних оновлень основного алгоритму, приблизно по одному кожні 3-4 місяці. Оновлення отримало неофіційну назву Medic update. Хоча Google випускає сотні оновлень алгоритму щороку, на основі Medic Update і наступних оновлень 2018 і 2019 років можна виділилися деякі чіткі закономірності. Весь цей час багато SEO-фахівців займалися вивченням даних і розробили теорію, згідно з якою E-A-T відіграють центральну роль в нових оновленнях. Саме відповідність цим критеріям робить одні сайти переможцями, а інші - переможеними.
Чому тема E-A-T викликає такі запеклі суперечки? Щоб зрозуміти E-A-T, важливо спочатку розібратися в концепції YMYL.
YMYL: Your Money Your Life («Гаманець або життя»)
Згідно з визначенням Гугл, сторінки або теми відносяться до категорії YMYL («Гаманець або життя»), якщо вони «можуть потенційно вплинути на майбутнє благополуччя, здоров'я, фінансову стабільність або безпеку користувачів» (Керівництво для асессоров Google). З огляду на те, скільки тем може потенційно вплинути на щастя і благополуччя користувачів, в категорію YMYL потрапляє величезна кількість сайтів. За великим рахунком, саме веб-сайти категорії YMYL (медичні, юридичні, фінансові, новинні і політичні ресурси) в повній мірі відчули вплив останніх оновлень.
Ось кілька прикладів того, як оновлення алгоритму вплинуло на сайти певної тематики:
Рис.1. Сайт про дієти.
Рис.2. Сайт про здоровий спосіб життя.Рис.3. Сайт про жіноче здоров'я.
Як бачите, ці екстремальні коливання алгоритмів привели до серйозних змін в органічній видачі і трафіку веб-сайтів категорії YMYL. Причому, дуже часто кожне нове оновлення зводило нанівець усі досягнення, отримані завдяки попередньому (або навпаки).
Чим викликані ці коливання в алгоритмі Google
Не секрет, що в останні роки Google та інші технологічні гіганти не раз опинялися в центрі уваги ЗМІ через низку вельми непристойних причин:
зростання дезінформації і «фейкових новин» (джерело)
критика якості медичної інформації в інтернеті (джерело)
роль дезінформації в поширенні захворювань (джерело)
Пошукові системи і оператори соціальних мереж під наглядом уряду
Хоча Google не підтвердив, що його недавні оновлення алгоритму безпосередньо пов'язані з увагою з боку ЗМІ, компанія повідомила про свою участь в декількох ініціативах, спрямованих на підвищення надійності інформації в інтернеті:
У 2016 році Google разом з «експертами Гарвардської медичної школи і клініки Мейо» приступив до роботи над створенням так званих «карт симптомів» (англ. Symptom Cards) - однієї з функцій бази знань Knowledge Graph. Мета проекту - надати «високоякісну медичну інформацію» про різні порушення здоров'я.
У 2017 році Google почав фінансування проекту Trust Project: «міжнародного консорціуму новинних організацій», мета якого - «стверджувати й розвивати прихильність журналістики таким цінностям, як прозорість, точність, залученість і справедливість». У блозі Google є запис про Trust Project. Автори стверджують, що будуть додавати до своїх новинним результатам «мітки і знаки», наприклад, Fact Check (укр. «Перевірений факт»), а також інформацію про видавців, наприклад, про отримані ними нагороди, і відгуки з незалежних джерел.
У 2019 Google представив на Мюнхенській конференції з безпеки проектний документ під назвою «Як Google бореться з дезінформацією». У ньому докладно пояснюються ініціативи компанії по боротьбі з «дезінформацією, брехнею і фейковими новинами», а також алгоритми просування «авторитетної, високоякісної інформації».
Зрозуміло, Google змушений підвищувати свої критерії якості і надійності контенту, оскільки він сам піддається посиленому контролю з боку ЗМІ, суспільства і урядів по всьому світу.
Google також чітко усвідомлює свою роль в боротьбі з дезінформацією, що стосується здоров'я. Наприклад, дослідження Ілая Шварца (Eli Schwartz), проведене в 2017 році, показало, що 77% американців використовували інтернет для діагностики клінічних симптомів. Більш того, багато хто пояснює найбільший за останні 25 років спалах кору в США тим, що люди користувалися недостовірною інформацією, знайденою в мережі.
У відповідь на ці та інші тенденції, пов'язані з дезінформацією, Google заявляє:
«Ми несемо велику відповідальність перед нашими користувачами і суспільством, протидіючи тим, хто прагне поширювати неправдиву інформацію на наших платформах». - Як Google бореться з дезінформацією, 2019.
Таким чином, E-A-T слід розглядати як головний критерій Google для аналізу надійності контенту, а також людей, які його публікують, покликаний запобігти поширенню дезінформації.
E-A-T продовжує бути суперечливою темою в SEO-спільноті. Різні фахівці дотримуються різної думки про E-A-T і про те, наскільки ці параметри важливі для пошукової оптимізації. Подібні розбіжності часто виникають через те, що досить складно уявити, як саме пошукова система враховує E-A-T в своїх алгоритмах. Нові параметри не такі прості, як попередні чинники ранжування, наприклад, швидкість сторінки, зовнішні посилання або відповідність HTTPS.
Проте Google згадує E-A-T 135 разів в поточній версії свого 167-сторінкового керівництва для асессорів. E-A-T підноситься як необхідний критерій якості і надійності ресурсу. Вже одне це підтверджує, що E-A-T - основний пріоритет оновленого алгоритму Google. Щоб до кінця прояснити ситуацію, Google опублікував в своєму блозі запис, присвячений річниці Medic Update. Стаття називається «Що веб-майстри повинні знати про оновлення Google», і в ній ще раз підтверджується важлива роль, яка відведена E-A-T в останніх оновленнях.
Через зростаючий інтерес до E-A-T виникає чимала кількість домислів і помилок про те, як це працює.
Ми вже чули багато розмов про те, чим є E-A-T. Але щоб краще прояснити ситуацію, давайте поговоримо про те, чим E-A-T не є.
1. E-A-T не є тим, що важливе абсолютно для кожного сайту
Ви можете оцінити, наскільки E-A-T важливий для вашого сайту, за допомогою «датчиків» на малюнку нижче. Для деяких сайтів хороший E-A-T - скоріше приємне доповнення, ніж обов'язкова вимога. Наприклад, ведення блогу про в'язання не вимагає від вас будь-якої особливої «компетентності» - для цього достатньо просто гаряче любити своє захоплення.
Така тема, як плітки про знаменитостей, може потребувати трохи більше спеціальних знань і відомостей про автора. Наприклад, як давно ви цікавитеся темою або де ще публікувалися ваші статті.
Якщо ж ваш контент зачіпає області категорії YMYL, такі як здоров'я домашніх вихованців або особливо лікування раку, відповідність E-A-T стає вирішальним фактором. Читачам важливо знати, хто ви і чому вашому контенту варто довіряти.
2. E-A-T не є однозначним і підтвердженим фактором ранжування
E-A-T збиває з пантелику тим, що Google ніколи не підтверджував, що цей критерій є фактором ранжування, на відміну від швидкості сторінки, HTTPS або наявності ключових слів в тезі title.
Зв'язок між E-A-T і рейтингом трохи більше опосередкований. Ось кілька цитат зі статті "Що веб-майстри повинні знати про оновлення Google" про те, як E-A-T впливає на алгоритм пошукової системи:
Алгоритми Google виявляють сигнали про сторінки, пов'язані з надійністю і авторитетністю. Найбільш відомий з цих сигналів - PageRank, який використовує посилання в інтернеті для визначення авторитетності.
Зібрані оцінювачами дані не використовуються безпосередньо в наших алгоритмах. Швидше за все, їхню роль можна порівняти з книгою скарг і пропозицій, які ресторан збирає у відвідувачів. Зворотній зв'язок допомагає зрозуміти, наскільки добре працюють наші системи.
3. E-A-T не є заміною технічної SEO-оптимізації
E-A-T і технічна SEO-оптимізація не виключають один одного. E-A-T - це лише один з факторів успіху. Його слід розглядати поряд з міцною технічною базою, авторитетними і актуальними зворотними посиланнями, відмінним контентом і користувацьким досвідом.
4. E-A-T не є єдиною причиною падіння рейтингу сайту після оновлення алгоритму
Звичайно, E-A-T важливо враховувати, намагаючись розібратися в причинах падіння рейтингу після оновлення алгоритму пошукової системи. Однак E-A-T - далеко не єдина можлива проблема. Технічні недоробки, незадовільний користувацький досвід, велика кількість відволікаючої реклами або проблеми з безпекою також є факторами, які можуть викликати падіння рейтингу.
5. E-A-T не є тим, що можна швидко і легко виправити
На жаль, для вирішення питань E-A-T панацеї не існує. Створення або поліпшення E-A-T вимагає часу, ресурсів і терпіння.
6. E-A-T не є інструментом SEO, який негайно дає результат
На відміну від виправлення пошкоджених канонічних тегів повторного ключення в індекс випадково не проіндексованих сторінок, всі маніпуляції з E-A-T, як правило, не приводять до негайного збільшення трафіку. Ваш бренд повинен, так би мовити, завоювати довіру пошукової системи (і користувачів). Хороша репутація, позитивні відгуки, значущі посилання і цитування вашого контенту - все це вимагає часу. Також вимагають часу дії пошукових систем по обробці й оцінці ваших результатів.
Тепер, коли ми зрозуміли, чим E-A-T не є, саме час розібратися, що значить мати хороші показники E-A-T. Для цього пропонуємо вашій увазі дуже показове дослідження.
Аналіз E-A-T: методологія
Було проаналізовано 64 сайти, як «переможців», так і «переможених», за період з 1 серпня 2018 р до кінця 2019 р
Використовувався індекс видимості Sistrix, який прогнозує органічні характеристики на основі обсягу пошуку та поточного рейтингу на Google.com.
Використовувався Archive.org (також відомий як Wayback Machine) для документування характеристик контенту в різні моменти часу.
Були зафіксовані характеристики 30 потенційних сигналів E-A-T на сторінці.
Невеликий розмір вибірки. Аналіз був проведений на невеликій вибірці, всього 64 веб-сайти. Аналіз сайтів вручну вимагає часу, і ми хотіли провести максимально докладне дослідження.
Кореляція не має на увазі причинно-наслідковий зв'язок. Наявність того чи іншого елемента сторінки на сайті, який «виграв» або «програв», не означає, що його рейтинг був обумовлений тільки цим фактором. Існують сотні факторів ранжування, і жоден окремий елемент сторінки не може відповідати за успіх/невдачу веб-сайту.
E-A-T аналіз - це рухома ціль. Сайти знаходяться в постійній зміні. Періодично виходять оновлення алгоритмів. Навіть Wayback Machine не може надати картину веб-сайту в кожен момент часу. Ця постійна динаміка може зробити аналіз дуже розмитим. Однак ми постаралися провести максимально точне дослідження.
Дослідження не претендує на науковість. Ми просто хотіли поділитися тим, що виявили у найбільш успішних сайтів з категорії YMYL і не знайшли на тих сайтах, які значно втратили видимість після оновлення Medic.
Як ми вимірювали «високоякісний» і «низькоякісний» контент. На щастя, у Google є багатосторінковий документ під назвою «Керівництво з оцінки якості», в якому детально описані критерії контенту високої та низької якості. Було ретельно порівняно власний аналіз з Керівництвом, щоб упевнитися, що ми мислимо як пошукова система.
Розбивка по категоріях
Протягом останніх років найбільших коливань рейтингу піддавалися сайти категорії YMYL, особливо пов'язані зі здоров'ям.
Найбільш успішні сайти (з проаналізованих) були присвячені таким темам:
Нижче представлені найменш успішні сайти, які значно втратили в рейтингу:
Результати дослідження E-A-T
1. 51% «переможених» веб-сайтів постраждали від так званого Безіменного оновлення (Unnamed Core Update), також відомого як Fred, ще в березні 2017 року.
Безіменне оновлення Google (або Fred Update) в березні 2017 року, судячи з усього, було націлене на веб-сайти з мізерним контентом, агресивною монетизацією, відволікаючою рекламою і незадовільним користувацьким досвідом. Деякі SEO-оптимізатори вважають, що це був один з перших випадків, коли Google намагався включити в свій алгоритм критерії E-A-T.
2. Компанії-переможці в сфері охорони здоров'я в середньому на 28 років старше, хто програв.
Сайти-переможці, присвячені здоров'ю, часто належать авторитетним компаніям або організаціям з багаторічним досвідом. «Ті, хто програв» в основному представлені новими блогами і сайтами, які спочатку створювалися для онлайн-публікацій.
3. Сайти-переможці на 16% частіше містять біографії авторів своїх статей.
4. Сайти-переможці на 258% частіше залучають для створення контенту справжніх експертів.
Хоча багато «переможених» веб-сайтів теж розміщують біографії авторів, докладне вивчення показує, що їм часто не вистачає кваліфікації та спеціальних знань, необхідних для надання медичних, юридичних, фінансових чи інших рекомендацій для категорії YMYL.
5. Сайти-переможці про здоров'я на 34% частіше залучають для своїх матеріалів медичних рецензентів.
6. Сайти-переможці на 45% частіше мають чітко сформульовану редакційну політику, викладену на сторінках ресурсу.
7. «Переможені» сайти медичної тематики на 433% частіше містять на сторінках заклики до дії.
8. Точно так само «переможені» сайти на 117% частіше мають партнерські посилання на контент категорії YMYL.
9. Компанії-переможці на 21% частіше мають інформаційну статтю на Вікіпедії.
10. Компанії-переможці на 850% частіше вказують на сторінці свої нагороди і розміщують позитивні відгуки.
«Кодекс поведінки фонду Health on the Net (HONcode) для веб-сайтів, присвячених медицині і охороні здоров'я, вирішує одну з основних проблем інтернету в цій області: надійність і достовірність інформації».
12. Компанії-переможці на 24% частіше використовують на своїх сторінках зовнішні посилання.
Під зовнішніми посиланнями ми маємо на увазі посилання на допоміжні ресурси або фактичний матеріал як в самому контенті, так і в списку джерел.
13. У сайтів-переможців на 1,9 бала вище середній рейтинг Trustpilot.
14. Не помічено чіткої кореляції між рейтингом BBB і характеристиками сайту: як «переможці», так і «ті, хто програв» в основному мають рейтинг A+, при цьому низький рейтинг зустрічається лише зрідка.
15. «Ті, хто програв» сайти на 94% частіше містять коментарі та інший користувацький контент за тематикою YMYL (і дозволяють пошуковим системам індексувати цей контент).
16. У сайтів-переможців рівень легкості читання по Флеш-Кінкейду в середньому на 0,7 бала вище.
17. Один з багатьох сервісів для аналізу тексту Readable показав, що сайти-переможці на 728% частіше використовують «офіційний» стиль викладу контенту категорії YMYL.
Кілька видатних прикладів E-A-T
Якщо ви хочете побачити, як виглядають ресурси з хорошим E-A-T, на наступних сайтах ви можете знайти зразкові сторінки, які вселяють користувачам почуття довіри і надійності:
Дослідження E-A-T показує, що компанії повинні обережно поєднувати рекламу з контентом категорії YMYL, особливо якщо це стосується питань здоров'я. Політика Healthline щодо реклами і спонсорства полягає в тому, що редакційні матеріали чітко розмежовані з рекламними. Тому користувачі можуть бути впевнені, що отримують достовірну і об'єктивну медичну інформацію.
Незмінний «переможець» всіх оновлень основного алгоритму eMedicineHealth містить сторінку, де перераховані «сертифіковані лікарі і фахівці в галузі охорони здоров'я», а також їх роль у створенні матеріалів.
3. Сторінка редакційної ради Recovery Village
Recovery Village, клініка реабілітації наркозалежних, містить сторінку редакційної ради, на якій перераховані приблизно 100 авторів із зазначенням їх відповідного досвіду, а також посилання на профілі в LinkedIn та інші актуальні онлайн-ресурси, які заслуговують на довіру.
Кето-дієта - спірна тема, тому ключові слова, пов'язані з кето-дієтою, стали основними жертвами алгоритмічної турбулентності. За допомогою Wayback Machine ми можемо побачити, що Diet Doctor постійно поліпшував і оновлював свою сторінку про кето-дієту. На сайт додавалося більше цитат, перевірених фактів, відміток про достовірність, медичних рецензій та інших показників надійності, щоб дати зрозуміти користувачам, що дане джерело заслуговує на довіру.
Висновки
При аналізі характеристик «переможців» і «переможених» стає очевидним, що після оновлення алгоритм Google працює таким чином, щоб винагороджувати ресурси категорії YMYL, що демонструють відмінний E-A-T. Нижче наведено 5 висновків, які не тільки маються на увазі в Керівництві Google, але і підтверджуються даними дослідження:
1. Контент категорії YMYL повинен бути обгрунтованим, об'єктивним, ретельно перевіреним.
2. Включіть у свій контент цитати і факти з перевірених джерел.
3. Однієї біографії автора недостатньо, в ідеалі автори повинні бути справжніми експертами (за темами YMYL).
4. Уникайте партнерських посилань або «продаючих» фраз в контенті категорії YMYL.
5. Дотримуйтеся редакційної політики і розкривайте інформацію про рекламу.
Розповідаємо про словники і синтаксис мікророзмітки, зібрали кілька плагінів та інструментів для створення і перевірки розмітки, розібрали по кроках один з плагінів. Розповідаємо про те, навіщо потрібна розмітка Schema.org, що вона з себе представляє і як її створювати без знання коду.
Навіщо потрібна мікророзмітка
Schema.org - стандарт семантичної розмітки даних, який допомагає пошуковим системам краще розуміти дані, представлені на сайті. Наприклад, за допомогою розмітки можна явно вказати пошуковим роботам, що на сторінці site.ua/product_page1 знаходиться товар, і передати основні параметри: назву, ціну, артикул, виробника і т.д. На основі цих даних пошуковики формують розширені сніппети та блоки відповідей в пошуковій видачі.
Крім Schema.org є інші види мікророзміток. У них різні призначення, тому коротко наведемо властивості основних видів, щоб не плутати:
Open Graph. Мікророзмітка Facebook, використовується для настройки правильного відображення публікації в соцмережах під час репосту статті з вашого сайту (заголовок, опис, правильна картинка). Спочатку розмітка була створена для Facebook, зараз підтримується і іншими соцмережами і мессенджерами (Твіттер, Телеграм і т.д.).
Мікроформати. Розробка W3C, створений в 2007 році. Підходить для розмітки товарів, відгуків, контактної інформації та інших видів контенту. Раніше використовувався більш активно, зараз має ряд недоліків, недостатньо швидко розвивається і поступається Schema.org.
Dublin Core. Цей словник розмітки використовують бібліотеки і музеї - дозволяє описувати книги і музейні експонати.
Різниця між словником і синтаксисом
Словник - це набір класів і властивостей, які описують тип вмісту сторінки і передають ключову інформацію. Словник можна порівняти з мовою - наприклад, англійською. Schema.org, Open Graph, Dublin Core - все це словники.
Синтаксис - це спосіб вказівки сутностей і властивостей словника в html-коді сторінок сайтів. Якщо словник - це англійська мова, то синтаксис можна порівняти з латиницею.
Варіанти синтаксису, які застосовуються для розмітки Schema.org:
мікродані;
мікроформати;
RDFa;
JSON-LD.
Детальніше про те, який синтаксис краще, поговоримо трохи пізніше.
Чим відрізняються сайти з розміткою і без неї
Сайти з реалізованою мікророзміткою видно по сніпетах на сторінці пошукової видачі. Ось приклад: у видачі два сниппета з одного і того ж сайту, перший - з мікророзміткою, другий - без неї.
А так виглядає сніппет сторінки з афішею кінофільмів, якщо на сторінці є мікророзмітка:
За допомогою мікророзмітки в сніппетах сторінок товарів відображаються ціни:
І ще один приклад: в першому сніпеті реалізована мікророзмітка хлібних крихт, а в другому такої розмітки немає:
Тут - види розширених результатів пошуку в Google (відображаються для сайтів з реалізованою мікророзміткою).
Що кажуть пошуковики
Google радить вебмайстрам і оптимізаторам впроваджувати мікророзмітку. Основна мотивація: впровадження мікророзмітки покращує сніпет візуально, а також підвищує якість пошуку (пошукові роботи при скануванні краще розуміють вміст сайту, на сторінках якого реалізована семантична розмітка даних).
Чим ще корисна мікророзмітка
Мікророзмітка вигідно виділяє ваш сніпет в пошуковій видачі на тлі конкурентів (якщо у них розмітки немає або реалізовано менше фіч). Навіть якщо ви показалися у видачі нижче конкурентів, ви можете отримати стільки ж кліків, а то і більше: ваш сніпет займає більше місця, містить більше корисної інформації для користувача.
І тут спрацьовує такий ланцюжок: привабливий сніпет → більше користувачів клацають і переходять на сайт → поліпшуються поведінкові чинники → ви ранжуєтесь краще і піднімаєтеся у видачі.
Також мікророзмітку використовують власні сервіси пошукових систем - наприклад, сторінка з реалізованою розміткою може потрапити в чаклунчики на пошуковій видачі (при цьому сам сайт не обов'язково повинен бути в ТОПі видачі).
Словник Schema.org
Словник мікророзмітки складається з сутностей (наприклад, ВВП) і властивостей, які описують параметри сутності (SKU, ціна, наявність і т.д.).
Весь список сутностей і документація - на офіційному сайті schema.org.
На скріншоті - частина сутностей (зліва) і властивостей сутності Thing (в правій частині скріншота)
Розповідати про всі сутності не будемо, наведемо приклади найпопулярніших:
Product - сутність, яка використовується для розмітки будь-якого товару або послуги. Наприклад, пара кросівок, квиток на концерт, оренда автомобіля і т.д. У сутності цього типу є багато властивостей, які дозволяють передати більше інформації про товар/послугу: назву, рейтинг, бренд, колір, категорію, ширину, висоту, вагу, SKU і т.д.
Event (подія). Сутність для опису подій, що відбуваються в певний час і в певному місці: концерт, лекція, фестиваль і т.д. Також в Schema.org є більш специфічні типи сутностей Event для різних видів подій. Наприклад, бізнес події (BusinessEvent), фестиваль (Festival), спортивна подія (SportsEvent).
Recipe - для розмітки рецептів. За допомогою властивостей сутності можна розмітити час приготування, калорійність, перелік інгредієнтів, покрокову інструкцію.
Review (відгуки). Властивості сутності - рейтинг і «тіло» відгуку.
Оптимальний синтаксис
Ми вже згадували про те, що для Schema.org підходять чотири види синтаксису:
RDFa;
мікроформати;
мікродані;
JSON-LD.
Перші три мають ряд недоліків і втрачають популярність, а останній (JSON-LD) - використовується все частіше.
Google рекомендує використовувати саме JSON-LD - він більш простий і компактний, на відміну від RDFa, мікроформатів і інших синтаксисів.
JSON-LD
Тепер про деталі. Поговоримо про те, як виглядає синтаксис і які правила в ньому діють.
JSON-LD в базовому вигляді виглядає так:
<script type="application/ld+json">
{
//тут містяться елементи
}
</script>
Ця конструкція - свого роду каркас, який завжди є за замовчуванням (як теги <html>, <head> і <body> в структурі будь-якої html-сторінки). Усередині каркаса розміщується безпосередньо код мікророзмітки, який містить необхідні дані: сутність, властивості і їх значення.
Зверніть увагу! Наявність мікророзмітки не гарантує того, що в пошуку буде виводитися розширений сніпет з усіма даними, зазначеними в розмітці. Проте, пошукові роботи все одно будуть враховувати передані дані і зможуть краще розуміти вміст сторінки.
Як робити розмітку JSON-LD
Ручна розмітка в JSON-LD (та й в будь-якому іншому синтаксисі) - рутинне завдання, забирає багато часу і завжди залишається ризик припуститися помилки. Спростити завдання можна за допомогою генераторів JSON-LD, ось кілька популярних:
technicalseo.com - простий генератор, в якому можна розмітити найбільш часто використовувані сутності (Стаття, Хлібні крихти, Подія, FAQ-сторінка, Товар і т.д.). Виберіть потрібну сутність зі списку і вкажіть потрібні значення властивостей.
schemaapp.com - просунутий інструмент для професіоналів (платний, є 14-денний пробний період). Підтримує всі сутності Schema.org.
hallanalysis.com - простий і безкоштовний сервіс. На момент написання статті в ньому можна створити розмітку для шести сутностей.
Перевірка валідності розмітки
При створенні мікророзмітки важливо, щоб синтаксис був правильним і без помилок. Навіть якщо ви генеруєте JSON-LD за допомогою спеціальних плагінів або сервісів, не поспішайте завантажувати код на сайт, спочатку перевірте його на валідність.
Для перевірки коду використовуйте валідатор Structured Data Testing Tool від Google;
Куди вставляти JSON-LD?
Якщо код валідний (валідатор не знайшов помилок) - можете сміливо додавати розмітку на сайт. Для цього код потрібно вставити між тегами <head> і </head> на цільовій сторінці.
Мікродані
У мікроданних використовується мова розмітки HTML (в JSON-LD - JavaScript). Працювати з цим синтаксисом складніше - код розмітки потрібно прописувати в тілі контенту.
В основі мікроданних - три атрибута:
itemscope - вказує, що в блоці (<div>...</div>) задається елемент (сутність);
Прописувати такий код вручну - досить трудомістка і рутинна робота.
Сервіси для генерації мікроданних
Хороша новина в тому, що для мікроданних також існують спеціальні сервіси-генератори:
webcode.tools - безкоштовний генератор, для розмітки доступно 14 сутностей. У сервісі також можна створювати розмітку в синтаксисі JSON-LD;
htmlstrip.com (підтримує 3 сутності: Місцевий бізнес, Персона, Вебсайт);
Local Business Schema Generator - вузькоспрямований генератор. З його допомогою можна згенерувати розмітку в форматі мікроданних або JSON-LD для однієї сутності - Місцевий бізнес.
Згенеруйте код і перевірте його на наявність помилок (тими ж сервісами).
Впроваджуємо мікророзмітку самостійно і без знання коду
Покажемо вам простий спосіб, як швидко і без єдиної строчки коду підключити мікророзмітку.
Автоматична розмітка сторінок за допомогою Маркера даних
Google розробив спеціальний інструмент для максимально простого впровадження мікророзмітки - Маркер даних.
Які переваги надає інструмент:
не потрібно писати код або користуватися генераторами, не потрібно перевіряти валідність розмітки;
ви розмічаєте одну сторінку, а Google автоматично реалізує розмітку для всіх сторінок сайту цього типу (наприклад, для всіх товарів).
Як користуватися
Переходимо в Маркер даних і вибираємо підтверджений ресурс;
Вказуємо URL типової сторінки сайту. Наприклад, для інтернет-магазину - вкажіть адресу сторінки товару. Якщо у вас блог або інформаційний портал - вкажіть адресу сторінки зі статтею. Система визначить сторінки схожого типу і об'єднає їх в групу. Ваше завдання - проставити розмітку для однієї сторінки, для інших вона проставиться автоматично.
Вибираємо тип інформації і натискаємо «Почати виділення».
В інтерфейсі інструменту завантажиться сторінка сайту. В області «Мої елементи даних» у правій частині екрану буде показаний список властивостей, які доступні для обраного типу сутності. Також тут вказується, які з доступних властивостей є обов'язковими. Виділіть елемент сторінки (наприклад, назва товару або заголовок статті) і виберіть потрібну властивість у спливаючому меню.
Подібним чином розмітьте усі обов'язкові і додаткові елементи. Потім натисніть «Готово». У спливаючому вікні інструмент запропонує вибрати групу схожих сторінок, підібраних системою, або створити свою групу. Виберіть потрібний варіант і натисніть «Створити групу сторінок».
На наступному кроці система запропонує перевірити коректність розмітки інших сторінок. Якщо схожих сторінок багато - система покаже кілька зразків сторінок. Перевірте розмітку і виправте помилки, якщо якісь елементи система розмістила невірно. Потім опублікуйте мікророзмітку.
Роботи Google просканують сторінки сайту і врахують задану мікророзмітку.
Як змінити або прибрати мікророзмітку
Відкрийте Search Console і перейдіть в розділ «Маркер». Виберіть групу сторінок, які ви додавали при розмітці. Відредагуйте їх або видаліть групу повністю.
Коли робот Google знову просканує сторінки сайту, розмітка перестане враховуватися і в пошуковій видачі будуть відображатися звичайні сніппети.
Сайт на CMS? використовуйте плагіни
Розглянемо найпопулярнішу CMS - Вордпресс. Для Вордпресс є кілька рішень, які допоможуть просто і швидко впровадити мікророзмітку. Ось огляд плагінів, потрібних для цього завдання:
Schema - All In One Schema Rich Snippets. Безкоштовний плагін, розмічає дані в форматі мікроданних. Плагін підійде для розмітки товарів, відгуків, кулінарних рецептів, подій і ще декількох часто використовуваних видів контенту.
WP SEO Structured Data Schema. Цей плагін також реалізує розмітку на основі синтаксису мікроданних. У плагіна є дві версії. У безкоштовної можна розмітити дані про організацію та локальний бізнес, товари, послуги, статті, відео, коментарі та ще кілька типів контенту. У платній версії - більше можливостей (коштує платна версія 49$).
Schema. За допомогою плагіна можна зробити розмітку в синтаксисі JSON-LD. У плагіна є безкоштовна і платна версії (від 99 $). Функціонал безкоштовної дещо урізаний - доступна розмітка для статей, блогу, хлібних крихт, хедера і футера сайту, відео і ще кілька елементів. Для розмітки товарів, послуг і інших сутностей Schema.org доведеться купувати платну версію.
Schema & Structured Data for WP & AMP.. Просунутий плагін для розмітки Schema.org за допомогою синтаксису JSON-LD. В плагіні можна використовувати 33 сутності Schema. Доступний у двох версіях: безкоштовна і Pro (від 49$).
Налаштування мікророзмітки в плагіні Schema: покрокова інструкція
Встановіть плагін і клацніть по розділу Schema, який з'явиться в бічному меню адмінпанелі. Перейдіть в розділ Settings → General. Виберіть тип сайту і завантажте логотип.
Збережіть зміни і перейдіть на другу вкладку - Knowledge Graph. Тут вам потрібно вказати, кого представляє сайт - виберіть Person, якщо це особистий сайт, або Organization (якщо просуваєте сайт компанії).
Перейдіть на вкладку Schemas. Виберіть з випадаючих списків сторінки «Про себе» і «Контакти». Якщо хочете підключити розмітку хедера і футера, хлібних крихт і інших елементів сторінок сайту - поставте галочки навпроти відповідних параметрів.
Також можна налаштувати автоматичне видалення мікророзмітки, якщо буде видалений плагін Schema. Для цього перейдіть на вкладку Advanced і поставте галочку навпроти «Delete Data on Uninstall».
Збережіть зміни. Перевірте вихідний код сторінок сайту - в розділі <head>...</head> з'явиться код мікророзмітки в форматі JSON-LD.
Спробуйте перевірити розмітку в валідаторі Google (про всяк випадок). Плагін працює коректно, тому помилок не повинно бути - сміливо завантажуйте код на сайт.
Приблизно так само будується робота з іншими плагінами для Вордпресс. Головна перевага - вам не потрібно розбиратися в синтаксисі і прописувати всі параметри вручну.
Коротко про головне
Schema.org - великий словник, за допомогою якого можна описати дані будь-якого типу і передати пошуковим роботам детальну інформацію про продукти, послуги та інші сутності.
Мікророзмітка покращує зовнішній вигляд сніпета в пошуковій видачі. Сніппет виглядає привабливо і інформативно → зростає CTR.
Якщо просувається тільки в Google - скористайтеся рекомендацією пошуковика і розмічайте дані в JSON-LD.
У Google можна і простіше. Маркер даних в Search Console допоможе реалізувати розмітку в кілька кліків (без коду, плагінів або сторонніх сервісів).
Не пишіть код вручну - використовуйте генератори. Це заощадить купу часу і вбереже від помилок.
Перевіряйте помилки за допомогою валідаторів.
Якщо у вас сайт на Вордпресс - поставте плагіни для мікророзмітки і використовуйте їх. Якщо сайт на інший CMS - пошукайте аналоги, скоріше за все вони є і вам не потрібно буде прописувати мікророзмітки вручну.
приєднуйтесь до нас