Всі, хто працював з seo-просуванням ні раз чув твердження: «Сайту потрібно семантичне ядро (СЯ)», «Немає семантичного ядра - немає і просування», «СЯ - це основа сайту» і т. д. і т. п. Незабаром почали говорити, що СЯ - це, звичайно, добре, але потрібна ще й «карта релевантності» (вона ж карта перелінковки, карта входження ключових запитів). Але з визначенням цього поняття коїться якась плутанина. Навіть детальні гайди щодо складання карти релевантності від провідних агентств ясності не додають. Складно зрозуміти як з тим, що вони показують в прикладах можна працювати системно.
У статті ми поділимося нашим баченням цього інструменту і досвідом розробки.
Що про карту релевантності говорять в інтернеті?
Про цей інструмент написано мало, одне з найбільш повних визначень можна знайти на сайті агентства «Текстерра»:
"Карта релевантності - це файл у форматі .excel, який створюють наші фахівці відділу просування перед початком робіт з просування. Карта релевантності - це, по суті, семантичне ядро, натягнуте на структуру сайту. Крім цього, карта релевантності містить інформацію про:
Перелінковці, тобто внутрішніх посиланнях зі сторінки-донора на сторінку-акцептор (відображаються посилання, які вже існують і які тільки будуть проставлені під час робіт у майбутньому)
Релевантність таких елементів, як H1, Title, Description. " (Текстерра)
Ось як це виглядає у них:
Навіщо потрібна карта релевантності?
У тому ж джерелі читаємо:
"До цього документа постійно звертаються при роботі наші seo-оптимізатори і копірайтери. Завдяки йому не виникає плутанини і випадкових помилок, не з'являються розділи, релевантні тим чи іншим ключам, які повинні бути присутніми зовсім на інших сторінках. Наприклад, релевантної сторінки ще немає, але вона вже відображена в плані, і ми знаємо, що на іншій сторінці не можна "накачувати" текстову релевантність за ключами, які "заброньовані" іншою, поки ще не існуючою, сторінкою ". (Текстерра)
Все, що сказано вірно, але дивимося на приклад карти в скріншоті і абсолютно не розуміємо як з цим інструментом можна працювати системно:
- Як використовувати кільком співробітникам? Якщо це Excel, для синхронізації змін доведеться вводити окрему посаду «Синхронізатора».
- Як робити сортування і фільтрування? Сама структура документа не передбачає фільтрацій, адже це дуже важливо, коли працюєш з масивом даних.
- Як зрозуміти яка семантика до якого розділу сайту належить?
- Як виділити пріоритетні сторінки для роботи?
Загалом, питань більше, ніж відповідей. Ймовірно, стаття застаріла, або як приклад використовується спрощений варіант.
Наш варіант карти релевантності
Спочатку визначимося з тим, що нам потрібно в цьому документі:
1. Спільне редагування. Повинен мати можливість правки кількома співробітниками.
2. Фільтр. У карті представлено багато різних даних, а значить без фільтрації і сортування нікуди.
3. Наочність загальної структури сайту. Це означає, що в карті зрозуміло який запит до якого розділу і підрозділу сайту відноситься.
4. Повна інформація про семантику. Частотності, сторінки на сайті, метатеги, розташування згідно з розділами сайту - зручно все це бачити в одному місці.
Перша вимога вирішується легко за допомогою Google SpreadSheet. Чарівний інструмент для спільного редагування, робить майже все те саме що і Ексель, але ще і в режимі онлайн.
Відповідати іншим пунктам складніше. Для цього доведеться звернутися до теорії реляційних баз даних:)
Робота з фільтром
Щоб зручно працювати з фільтрацією (повторимося, без цього немає сенсу використовувати таблиці! Пишіть у блокноті - різниці не відчуєте) необхідно мати таблицю в нормалізованому вигляді, в даному випадку це «1 нормальна форма».
«Таблиця знаходиться в першій нормальній формі (1НФ) тоді і тільки тоді, коли жоден з її рядків не містить в будь-якому своєму полі більше одного значення і жодне з її ключових полів не порожнє».
Простіше кажучи, таблиця не повинна мати складових полів і порожніх важливих полів. У будь-якому рядку таблиці вам має бути зрозуміло, до чого відносяться відображені в ньому дані.
Це робиться легко, і виглядає приблизно так:
У цьому випадку ми можемо використовувати стандартну фільтрацію і сортування. Кожен рядок окремо містить всі необхідні дані для його ідентифікації. У виділеному рядку зрозуміло, що запит «бктп» відноситься до групи «БКТП», яка, в свою чергу, відноситься до розділу «Обладнання». Запит має частотність 255.
Наочність загальної структури сайту
Для цього побудували зведену таблицю за вихідними даними. Нижче представлений маленький її шматочок.
В агентстві ми постійно працюємо з картою, тому швидко зрозуміли, що такий варіант не варіант. І ось чому:
В одному документі потрібно зберігати багато різних даних, але всі вони відносяться до двох різних сутностей. Наприклад, частотність відноситься до кожного запиту окремо, а ось url сторінки відноситься до групи запитів. І щоб у таблиці все було правильно доводиться для всіх запитів, що відносяться до однієї сторінки, вказувати один і той же url. Копірайтеру і менеджеру проекту важлива карта в розрізі сторінок сайту, а для seo оптимізатора важливіші ключові слова. Коротше нестиковочка.
Виходить ось таке пекло.
Розриваючись між поданням даних «один рядок - один запит» або «один рядок - одна сторінка», ми знайшли ну просто дивовижне, на наш погляд, рішення. Об'єднавши два рівні абстракції в одній таблиці за допомогою скриптів, ми зробили нашу карту релевантності дволикою, так би мовити. З'явилося два варіанти подання карти, опишу кожен з них детально, щоб було зрозуміло як це зроблено і для чого.
Перше подання «Один рядок - один запит». Якщо ми працюємо на рівні запитів, то наша карта виглядає так:
Це подання «Один рядок - один запит». Вся інформація вказана для кожного конкретного запиту. Ми можемо сортувати фільтрувати їх, робити все що завгодно.
Тут є ряд фішок, які роблять її шалено зручною:
- Показано до 5 рівнів розділів/підрозділів (якщо потрібно, то можна і більше);
- на скріншоті нижче видно, що в першому рядку назву розділу візуально виділено, а наступні аналогічні назви затемнені. Такі виділення робляться автоматично за допомогою банального умовного форматування і значно спрощують сприйняття структури сайту;
- Можна відфільтрувати так, щоб відображалися запити тільки одного розділу, або будь-якого підрозділу;
- Є можливість відсортувати запити за частотністю;
- Можемо легко скопіювати список запитів і нам не доведеться тягнути за собою купу розрізнених, не пов'язаних між собою рядків. Зручно, наприклад, зібрати додаткову статистику в інших сервісах;
- Ви можете відфільтрувати запити, які стосуються лише однієї сторінки або групи сторінок.
Загалом фільтруємо все вздовж і поперек. Додаємо нові характеристики запитів, такі як частотність, title, description і взагалі все, що потрібно знати в розрізі запиту.
Перегляд «Один рядок - одна сторінка»
Повторюся, що попереднє подання чудово підходить для роботи із запитами, але як тільки нам необхідно додати дані, що відносяться до сторінки, то виникає незручність. І тут на допомогу приходить вистава «Один рядок - одна сторінка». Пишемо невеликий скрипт, вибираємо в меню Гугл таблиць пункт «Згрупувати».
Скрипт перебирає рядки в нашій таблиці і групує всі дані для кожного url. Виходить наступний вид:
У цьому вигляді дані вказані для кожного URL, тобто для кожної сторінки.
Тут:
Дані розділів (цифра 1) групуються
Дані запитів (цифра 2) - об'єднуються в одне поле через ком
Адреса сторінки URL (цифра 3) - групується
Дані сторінки (цифра 4) - групуються
Ось, що потрібно від подання карти в розрізі сторінок:
- Можна скопіювати сторінки списком (наприклад, для перевірки сторінок у сервісі перевірки унікальності);
- Зазначити факт виконання будь-якої роботи, що відноситься до сторінки. Сюди можна додати все, що завгодно: «Перевірку на унікальність», «Перевірку оптимізації тексту», «Перевірку індексації сторінок» тощо. Перевіряєте тексти за Законом Ципфа або пропускаєте через сервіс Главред? Додайте нове поле і фіксуйте факт виконання;
- Копирайтер видит требуемые страницы, по которым еще не написан контент.
Таким чином, в одному файлі всі учасники процесу бачать зроблене і заплановане.
Якщо ж нам знадобилося повернутися до подання «Один рядок - один запит», але ми тиснемо «Розгрупувати» і повертаємося до попереднього вигляду:
Що ми отримали в результаті?
У нас вийшла багаторівнева карта релевантності, яка:
- Зберігається «в хмарі» і не потребує додаткової синхронізації;
- Дозволяє зручно працювати спільно;
- Дозволяє наочно бачити всю структуру сайту;
- Дозволяє зберігати інформацію в розрізі запитів і одночасно з цим працювати в розрізі сторінок;
- За допомогою скриптів можна змінювати подання даних залежно від потреб кожного учасника проекту;
- За допомогою скриптів вказати дані, що відносяться до сторінки тільки один раз, а для кожного запиту цієї сторінки дані продублюються автоматично;
- Спрощує діалогове вікно копірайтера. По суті карта є готовим ТЗ до кожної сторінки сайту;
- дає всім учасникам процесу бачення загальної картини проекту.
А як ви працюєте з семантикою? У кожного свої методики - давайте ділитися.