Зробити просту і зручну карту релевантності сайту - DONE

Всі, хто працював з 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) - групуються

Ось, що потрібно від подання карти в розрізі сторінок:

  • Можна скопіювати сторінки списком (наприклад, для перевірки сторінок у сервісі перевірки унікальності);
  • Зазначити факт виконання будь-якої роботи, що відноситься до сторінки. Сюди можна додати все, що завгодно: «Перевірку на унікальність», «Перевірку оптимізації тексту», «Перевірку індексації сторінок» тощо. Перевіряєте тексти за Законом Ципфа або пропускаєте через сервіс Главред? Додайте нове поле і фіксуйте факт виконання;
  • Копирайтер видит требуемые страницы, по которым еще не написан контент.

Таким чином, в одному файлі всі учасники процесу бачать зроблене і заплановане.

Якщо ж нам знадобилося повернутися до подання «Один рядок - один запит», але ми тиснемо «Розгрупувати» і повертаємося до попереднього вигляду:

Що ми отримали в результаті?

У нас вийшла багаторівнева карта релевантності, яка:

  • Зберігається «в хмарі» і не потребує додаткової синхронізації;
  • Дозволяє зручно працювати спільно;
  • Дозволяє наочно бачити всю структуру сайту;
  • Дозволяє зберігати інформацію в розрізі запитів і одночасно з цим працювати в розрізі сторінок;
  • За допомогою скриптів можна змінювати подання даних залежно від потреб кожного учасника проекту;
  • За допомогою скриптів вказати дані, що відносяться до сторінки тільки один раз, а для кожного запиту цієї сторінки дані продублюються автоматично;
  • Спрощує діалогове вікно копірайтера. По суті карта є готовим ТЗ до кожної сторінки сайту;
  • дає всім учасникам процесу бачення загальної картини проекту.

А як ви працюєте з семантикою? У кожного свої методики - давайте ділитися.