Нижче представлені найбільш поширені помилки, яких припускаються при складанні семантичного ядра.
Підбираються порожні запити, не виконується перевірка на повноту
Якщо уважно прочитати допоміжний розділ цього сервісу, то можна, зокрема, дізнатися, що за запитом видається не точне значення кількості звернень по ньому за місяць, а сума звернень на всі запити, що містять даний.
Хочу повідомити про вельми цікавий факт. У багатьох тематиках частка запитів, які в принципі неможливо знайти за допомогою систем Яндекс Вордстат і ін. Досягає 50% і більше, тобто 50% трафіку приходить за запитами, які вводили рідше, ніж 1-2 рази на місяць. Найбільш видатний випадок, з яким мені довелося зіткнутися, показував 80% трафіку по рідкісним запитам.
Приклади порожніх запитів:
- «Квартири під ключ»
- «Білі діаманти»
- «Сайт кредит»
Перевірка виконується досить просто. Якщо ми візьмемо запит в лапки, то дізнаємося значення тільки тих похідних запиту, які містять тільки слова, що містяться в запиті, але з урахуванням словоформ. Таким чином, за запитом «кондиціонери» ви дізнаєтеся суму звернень за місяць за всіма його словоформам «кондиціонер», «кондиціонери», «кондиціонером» і т.п. але втятий запити, що містять будь-завгодно інші слова. Наприклад, такі запити не будуть враховані: «купити кондиціонер», «кондиціонери daikin».
Приклади порожніх запитів:
- «Квартири під ключ» 281 vs квартири під ключ 19581
- «Білі діаманти» 35 vs білі діаманти 5671
- «Сайт кредит» 17 vs сайт кредит 23286
Зліва я вказав значення частотності точного входження запиту, введеного в лапках, а праворуч значення звернень за стандартним запитом. Таким чином, ми бачимо по відношенню і значенням запитів, що просувати їх сенсу ніякого немає - в дійсності запити порожні і їх ніхто не шукає.
«Квартири під ключ» - це частина запиту «ремонт квартир під ключ», а «білі діаманти» - частина запиту «кільця з білого золота з діамантами». Порожні запити важливо перевірити, щоб переконатися, що вони порожні - якраз описаним вище способом, тобто знайти запит, точний, який має більше звернень, але містить більше слів.
При цьому важливо не переплутати так звані порожні запити з псевдо-порожніми запитами. Так, наприклад, запит «вікна» при підрахунку відносини точного до загального теж має великий перекіс в пропорції (2 338 557/21 906), тим не менш, цей запит дійсно шукають 22 тисячі осіб. Тут немає стандартного шаблону, важливо звертати увагу як на пропорцію, так і на точне значення.
запити дублюються
При підборі запитів неминуче виникає ситуація, коли один і той же запит дублюється в семантичному ядрі кілька разів. Типовий випадок - підбирається спочатку одна група товарів, наприклад дивани, потім інша група - ліжка. Запит диван-ліжко потрапляє в обидві групи, чого, звичайно, не помічає фахівець-семантик. Ще один випадок дублювання - порядок запитів, коли в семантичне ядро потрапляє і запит «купити шафи купе в москві» і «шафа купе купити в москве».
Виявити і усунути цю помилку досить просто, для цього потрібно в Excel виконати перевірку на дублікати. Іноді це ускладнюється тим, що в семантичному ядрі всі запити збудовані в різних стовпчиках, тоді як перевірка на дублікати виконується в рамках одного стовпчика.
Давайте трохи розберемося, ніж нам шкодять дублікати запитів в семантичному ядрі. Семантичне ядро згодом використовується для написання текстів і написання анкоров для покупки посилань, а так само визначення вхідних сторінок. Це може призводити до проблем, коли ви будете перевитрачати контрольний бюджет, просуваючи різні сторінки з одного й того ж запиту.
Нетематічние і інформаційні запити
При складанні семантичного ядра неминуче поява нетематічних і нецільових запитів. Нецільовим запитом може бути, наприклад, інформаційний запит для комерційного сайту і комерційний запит для інформаційного сайту.
Запит «транспортні шини медичні» нічого очікувати бути цільовим, якщо ми просуваємо магазин автозапчастин. А, наприклад, запит «синій діамант» не є цільовим для магазину ювелірних виробів, оскільки це інформаційний енциклопедичний запит. За цим запитом у видачі ми побачимо 10 інформаційних сторінок.
Так само хотілося б виділити такий момент. Просування інформаційних запитів будується по відмінному алгоритму, ніж просування комерційних запитів, посилання з SAPE в цьому випадку абсолютно марні. У будь-якому випадку, якщо навіть подібні запити потрапляють в семантичне ядро, їх важливо розмежовувати і виносити окремо. Таким чином, перевірка проводиться таким чином:
- За запитами, які вам здаються не цільовими, виконується ручна перевірка - вбиваєте їх в Яндексі і дивіться результати видачі. Якщо там не цільові сторінки, запит виключається.
- За запитами, які вам здаються не цільовими (тобто не інформаційними для інформаційного сайту або комерційними для комерційного сайту), виконується ручна перевірка - вбиваєте їх в Яндексі і дивіться результати видачі. Якщо там не цільові сторінки, запити виключаються.
Незв'язані з вхідний сторінкою запити
Дуже важливо кожен запит вести саме на ту сторінку, де людина може дізнатися те, що шукає або купити те, що він хоче. Іншими словами, досягнення цілей відвідувачів повинно відбуватися на тій сторінці, яку ви просуваєте по цьому запиту.
Якщо на інших сайтах можна натиснути кнопку «купити» на вхідній сторінці, а на вашому потрібно ще побродити по сайту в пошуку цієї кнопки - можете бути впевнені, що конверсія у вас буде значно нижче і це неминуче негативно позначиться на просуванні.
Значить, необхідно виконати перевірку семантичного ядра на відповідність запитів змістом вхідних сторінок. Типовий приклад помилки - просування запитів назв товарів на сторінки списку товарів, замість сторінки картки товару, наприклад «купити ноутбук ASUSee312 black» на сторінку списку ноутбуків ASUS. Така перевірка займе не так багато часу, як може здатися на перший погляд:
- Необхідно перевірити, чи коректно виконана угруповання запитів, чи немає в групах зайвих і нецільових запитів, чи не ведуть на одну сторінку відразу і інформаційні та комерційні запити.
- Виконати перевірку питанням «чи зможе відвідувач, що прийшов на цей запит на цю сторінку, отримати на неї потрібну інформацію». Якщо відповідь так - все в порядку, якщо відповідь немає - треба щось міняти вхідні сторінку.
Групи запитів можна уточнити глибше
З попереднього пункту в якості логічного продовження випливає наступна можлива помилка - при розбитті запитів на групи співробітник недостатньо глибоко пропрацювала список запитів, об'єднавши в одну групу запити, які можна виділити в окремі групи.
Тут доречно зробити пояснення щодо принципу розбивки запитів на групи. Розбивати запити на групи потрібно слідуючи двом принципам: розбивати групу потрібно тільки в тому випадку, коли вийшли частини зможуть скласти унікальний контент, який не є синонімом або дублікатом; якщо більшу групу запитів можна розбити на кілька маленьких, це потрібно зробити. Покажу на прикладах.
- «Автоматичний парасольку»
- «Синій автоматичний парасольку»
- «Подарунковий автоматичний парасольку»
Приклад 2. Неправильна угруповання запитів, які можна було рознести на більш точні групи. У наведеному нижче прикладі дві групи запитів, «вікна kbe» і «вікна rehau», помилково об'єднані в одну. Зрозуміло, що відвідувачі за запитами «вікна kbe» очікують побачити зовсім не те, що очікують побачити відвідувачі за запитами «вікна rehau».
- вікна kbe
- пластикові вікна kbe
- вікна пвх kbe
- вікна rehau
- пластикові вікна rehau
В одному блоці більше 20 запитів
Запити розбиті нелогічно по групам
При складанні семантичного ядра дуже важливо дотримуватися логіку, описану в концепції семантичного ядра. Проте, трапляються окремі огріхи, наприклад можна при угрупованню запитів в одному випадку віддати пріоритет першою ознакою, в іншому другого. Ці похибки важливо помітити і виправити, щоб у людей не виникало логічного конфлікту.