В інтернет-магазину сотні або тисячі сторінок одного типу — категорії, підкатегорії, картки товару, сторінки фільтрів, — і загальний підхід до збору семантики для сайту послуг тут працює не повністю. Не тому що принципи інші, а тому що масштаб і повторюваність структури вимагають системи, а не ручного збору ключів під кожну сторінку окремо.
01 Чим семантика eCommerce відрізняється від звичайного сайту
Базові принципи збору ядра, описані в загальному керівництві зі збору семантичного ядра, залишаються чинними: маркерні запити, розширення, чистка, кластеризація. Різниця — в обсязі і повторюваності: та сама логіка підбору ключів застосовується не до десятка унікальних сторінок, а до сотень однотипних категорій і тисяч карток товару.
Це створює три специфічні для eCommerce завдання: потрібен шаблон, за яким семантика збирається для цілого класу сторінок, а не для кожної окремо; потрібно вирішити, що робити зі сторінками фільтрів, яких технічно може бути в тисячі разів більше, ніж товарів; і потрібно заздалегідь закладати захист від канібалізації, бо схожі товари і категорії закономірно породжують схожі, конкуруючі між собою запити.
02 Як зібрати ключі для категорій каталогу
Категорія каталогу — це, як правило, найкомерційніша сторінка розділу: саме вона зазвичай отримує основний трафік за загальними запитами на кшталт «купити кросівки» або «ноутбуки для ігор». Семантика для категорій будується на перетині назви товарної групи і типових уточнень покупця.
Джерела ключів для категорії: назва товарної групи у варіантах, якими її називають покупці, а не лише внутрішня назва в товарооблікові й системі; типові уточнення — бренд, ціновий сегмент, призначення, цільова аудиторія; і дані про те, за якими запитами конкуренти в топі отримують трафік саме на аналогічні сторінки категорій, а не на картки товару. Усі три джерела разом із загальною комерційною семантикою дають набір, який потім розподіляється між категорією і її підкатегоріями.
03 Як зібрати ключі для карток товару
Картка товару конкурує за інший пласт запитів — конкретніший, часто із моделлю, артикулом чи точною назвою. На відміну від категорій, тут немає сенсу збирати унікальну семантику для кожної одиниці каталогу вручну.
Практичний підхід: для товарів-локомотивів із високим попитом семантика збирається індивідуально, аж до синонімів і розмовних назв моделі; для основної маси каталогу використовується шаблон, який автоматично формує title і description із назви, категорії, бренду і ключових характеристик товару; а опис картки достатньо писати з урахуванням реальних питань покупців про товар цього типу, а не переписувати характеристики виробника слово в слово.
04 Робота з фільтрами і фасетною навігацією
Фасетна навігація — фільтри за брендом, кольором, розміром, ціною — технічно здатна генерувати майже необмежену кількість комбінацій URL, і більшість із них не має самостійної пошукової цінності. Відкривати для індексації все підряд — вірний спосіб створити тисячі тонких, конкуруючих між собою сторінок.
Рішення ухвалюється за комбінацією критеріїв: у комбінації фільтра є помітний самостійний попит у пошуку — наприклад, «кросівки nike жіночі» шукають окремо від загальної категорії; на сторінці достатньо товарів, щоб вона не виглядала порожньою; і комбінація не дублює за змістом уже наявну сторінку категорії. Якщо хоча б один критерій не виконується, сторінку фільтра логічніше закрити від індексації canonical-посиланням на батьківську категорію, а не залишати відкритою про всяк випадок. Офіційна позиція Google щодо об'єднання схожих і дублювальних URL описана в документації про канонічні адреси.
05 Кластеризація і розподіл ключів за сторінками
Після збору ключів для категорій, карток і фільтрів постає завдання не менш важливе, ніж сам збір: розвести зібрані запити за конкретними сторінками так, щоб кожна сторінка відповідала на свій, не перетинний із сусідами інтент.
Практичне правило розподілу: широкі загальні запити («купити взуття») закріплюються за найвищим рівнем категорії; уточнені запити з брендом, статтю, призначенням — за підкатегорією або відкритою сторінкою фільтра; а точні запити з моделлю чи артикулом — за конкретною карткою товару. Специфіка Google щодо структури каталогу інтернет-магазину і того, як пошуковик сприймає таку ієрархію, розібрана в керівництві Google зі структури сайту eCommerce.
06 Типові помилки: канібалізація і дублі змісту
Більшість проблем із семантикою інтернет-магазину виникає не на етапі збору ключів, а на етапі їхнього розподілу за структурою сайту, коли кілька сторінок виявляються націленими на один і той самий запит.
Найчастіші помилки: категорія і підкатегорія з майже ідентичним набором ключів і товарів, через що Google не може вирішити, яку сторінку показувати; сторінка фільтра, що дублює за змістом окрему категорію, яка вже існує в каталозі; і картки товару з однаковим описом у товарів-варіацій (різні розміри чи кольори однієї моделі), які через це конкурують одна з одною замість того, щоб об'єднувати вагу на одній сторінці з вибором варіанту.
07 З чого почати за великого каталогу: пріоритизація
Повне покриття семантикою каталогу з кількох тисяч товарів за один захід нереалістичне, і намагатися зробити це одразу — не найефективніше використання часу.
Розумний порядок роботи: почати з категорій верхнього рівня, які визначають структуру всього каталогу і отримують найбільший трафік; потім перейти до товарів і підкатегорій, які приносять найбільшу частку виручки чи маржі, а не йти за алфавітом каталогу; і лише після цього — до довгого хвоста рідкісних товарів і вузьких комбінацій фільтрів. Як ця робота вбудовується в загальну SEO-стратегію магазину, розібрано в піларній статті про SEO для інтернет-магазину, а схема перелінковки між категоріями, картками і статтями блогу — в керівництві з внутрішньої перелінковки. Якщо збирати і розподіляти семантику для великого каталогу самостійно немає ресурсів, цю роботу можна делегувати в межах SEO-просування.
Готова семантика розкриває весь потенціал тільки на платформі, яка не обмежує структуру URL і метадані категорій; на що звернути увагу під час вибору CMS для інтернет-магазину, розібрано в статті порівняння CMS для SEO.
08 Часті запитання
Чи потрібно збирати окремі ключі для кожного товару в картці?
Ні, якщо каталог великий. Для окремих ключів має сенс збирати семантику лише в товарів-локомотивів із найвищим попитом; для решти карток достатньо використовувати шаблон title і description, що автоматично підставляє назву, категорію і ключові атрибути товару.
Як зрозуміти, що два кластери запитів насправді канібалізують один одного?
Перевірити в Search Console: якщо за обома запитами ранжується то одна, то інша сторінка сайту, а не конкурент, — це ознака канібалізації. Ще один сигнал — обидві сторінки показуються за одним і тим самим запитом одночасно, але на низьких і нестабільних позиціях, бо Google не може визначити, яка з них релевантніша.
Чи варто відкривати для індексації всі комбінації фільтрів?
Ні. Відкривати варто лише ті комбінації фільтрів, у яких є реальний самостійний попит у пошуку і достатньо товарів, щоб сторінка не виглядала порожньою. Решту комбінацій логічно залишити лише для навігації користувача, закривши їх від індексації canonical-посиланням на батьківську категорію.
Що робити з категоріями, в яких менше 5–10 товарів?
Розмістити їх не як самостійну посадкову сторінку, а як підрозділ ширшої категорії, поки асортимент не виросте. Тонка сторінка з парою товарів і мінімумом унікального тексту погано ранжується сама по собі і може сприйматися як малокорисна для користувача.
Як розставити пріоритети, якщо каталог налічує тисячі товарів?
Почати з категорій і товарів, які приносять найбільшу частку виручки чи маржі, а не з алфавітного порядку каталогу. Повне покриття семантикою тисяч карток за один захід нереалістичне, але топ-20% асортименту зазвичай дає основну частину трафіку і продажів.
Чи можна використовувати ту саму семантику для сайту і для маркетплейсу?
Ключі за назвою і характеристиками товару — так, вони універсальні. А от структура сторінок і розподіл ключів за категоріями на маркетплейсі задаються правилами майданчика, а не вашою архітектурою сайту, тому карту релевантності для маркетплейсу доводиться будувати окремо.