Зробити просту і зручну карту релевантності сайту — 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) — групуються

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


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

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


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


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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.