Структура блогу: рубрики й черга тем замість «будемо писати щотижня»

Прозорі етапи з погодженням на кожному кроці

Загальний строк:10–35 днів

1. 1

   Інвентаризація й вимір

   2–4 робочих дні

   Знімаємо, що фактично опубліковано, і звіряємо з тим, що бачить пошук. Обсяг розділу перевіряємо технічно: у WordPress кількість записів віддає заголовок X-WP-Total у відкритому REST API, без жодного доступу до адмінки. Далі — звіт Search Console за сторінками: скільки матеріалів мають покази, скільки не мають нічого.

2. 2

   Розбір попиту по напрямах

   3–7 робочих днів

   Збираємо питання, які ставлять вашій компанії, і звіряємо їх із тим, що люди шукають. Джерела: планувальник і підказки пошуку, звіт запитів у Search Console, журнал внутрішнього пошуку сайту й те, що найчастіше перепитують ваші менеджери. Останнє джерело зазвичай найкорисніше і майже завжди недооцінене.

3. 3

   Рубрикатор

   2–4 робочих дні

   Групуємо теми так, щоб у кожній рубриці набиралось 5–7 матеріалів. Рубрики з двома темами зливаємо або відкладаємо. Назви перевіряємо на впізнаваність: читач має побачити в назві своє питання, а не вашу внутрішню класифікацію послуг.

4. 4

   Черга тем і зв'язки

   3–7 робочих днів

   Кожна тема отримує позначку попиту, складності, автора й цільову комерційну сторінку. Теми без виходу в каталог або послугу або відкладаються, або тягнуть за собою створення сторінки — і це видно в плані одразу, а не через півроку.

5. 5

   Правила, шаблони й технічні вимоги

   2–5 робочих днів

   Структура матеріалу, бриф для автора, чекліст перед публікацією. Окремим списком — вимоги до розділу: карта сайту, пагінація рубрик, доля тегів і сторінок авторів, розмітка Article і хлібні крихти.

6. 6

   Передача й домовленість про квартал

   1–3 робочих дні

   Проходимо каркас із тим, хто писатиме, і з тим, хто вичитуватиме. Домовляємось, за якими саме числами звіряти чергу через квартал: покази по матеріалах, переходи в комерційні сторінки, частка рубрик, що набрали обсяг.

Повний перелік робіт і того, що ви отримуєте на виході

• Інвентаризуємо все, що вже опубліковано: скільки матеріалів, скільки з них отримує покази, які дублюють один одного. Далі рішення ухвалюються по списку, а не по пам'яті.
• Будуємо рубрикатор із попиту. У кожної рубрики є пояснення, звідки вона взялася, і перелік тем, які її наповнять.
• Складаємо чергу тем на 3–6 місяців з позначками попиту й складності — одразу видно, що можна віддати підряднику, а що вимагає вашого фахівця.
• Прив'язуємо кожну тему до комерційної сторінки: який матеріал куди веде і яким блоком. Тема без виходу в каталог чи послугу в чергу не потрапляє.
• Малюємо схему внутрішніх посилань: звідки на матеріал посилаються і що він піднімає. Стаття без вхідних посилань лишається островом.
• Пишемо правила оформлення: структура заголовків, орієнтовний обсяг, ілюстрації, авторство, дата оновлення. Наступний автор не вигадує формат заново.
• Задаємо технічні вимоги до розділу: карта сайту, пагінація рубрик, доля сторінок тегів і авторів, розмітка Article і хлібні крихти.
• Готуємо бриф автора під кожен тип матеріалу — інтерв'ю з фахівцем, розбір, порівняння, інструкція.
• Домовляємось про перегляд черги раз на квартал за фактичними даними: що зайшло — розвиваємо, що ні — не дописуємо.
• Віддаємо каркас документом, з яким можна працювати без нас: рубрики, черга, правила, чекліст перед публікацією.

Ситуації, у яких ця послуга дає результат

Безкоштовна перевірка стану блогу

Дивимось, що у вашому блозі вже опубліковано, скільки з цього має попит і чи бачить його пошуковик. Перевірка зовнішня: доступи потрібні лише для двох пунктів із семи, решта знімається з того, що сайт віддає всім. Найчастіший результат: розділ існує, публікацій одиниці, показів немає в жодної.

Що міряємо

• Скільки матеріалів опубліковано насправдіПеревіряємо технічно, а не за словами. У WordPress кількість записів видно ззовні за заголовком X-WP-Total у відповіді відкритого REST API. Реальний випадок: 26 опублікованих сторінок і рівно нуль записів у розділі публікацій.
• Скільки з них має показиЗа звітом Search Console за сторінками. Зазвичай виявляється, що працює менша частина матеріалів, і розвивати треба саме її, а не рівномірно все.
• РубрикаціяЧи є вона взагалі й чи відповідає темам, які цікавлять читача. Рубрики з двома матеріалами всередині — це порожні сторінки в індексі й зайвий рівень кліків.
• Зв'язок із комерційними сторінкамиКуди веде кожен матеріал і чи веде взагалі. Блог, з якого немає переходу в товар чи послугу, лишається вітриною: читач прочитав і пішов.
• Технічний стан розділуЧи потрапляють матеріали в карту сайту, чи коректна пагінація рубрик, чи не дублюються сторінки авторів і тегів. У виміряному нами сайті всі три можливі адреси карти сайту віддавали 404, а директиви Sitemap у robots.txt не було.
• Дати й авторствоЧи видно, хто написав і коли оновлено. Матеріал без дати старіє швидше, ніж матеріал із чесно проставленою датою перегляду.
• Хто пише й хто вичитуєРесурс усередині компанії — головне обмеження блогу. Чергу плануємо під нього, а не під ідеальний світ, де статті пишуться самі.

Чому дві однакові на вигляд задачі рахуються по-різному — і що саме ми міряємо на аудиті

• Кількість напрямівМагазин із трьома категоріями і клініка з десятком послуг — різні обсяги перевірки попиту. Кожен напрям розбирається окремо: спільного рубрикатора «на все одразу» не буває, і саме тут розтягується нижня межа строку.
• Скільки вже опублікованоПорожній розділ будується з нуля й швидко. Сотня накопичених матеріалів спершу вимагає інвентаризації: що працює, що дублює одне одного, що дешевше оновити, ніж писати заново. На великому архіві це найдовший рядок роботи.
• Доступ до Search ConsoleЗ доступом матеріал, який працює, відрізняється від просто опублікованого за годину. Без доступу лишається зовнішня оцінка попиту — це довше й менш точно, а частину висновків доводиться позначати як припущення.
• Глибина чергиТри місяці плану чи шість — різна кількість перевірених тем. Далі ніж на півроку планувати не радимо: черга старіє, а перший же квартал публікацій міняє уявлення про те, що заходить.
• Мовні версіїКожна мова — це окремий попит, а не переклад готової черги. Теми, які працюють українською, часто не мають попиту другою мовою, і навпаки; перевіряти доводиться двічі.
• Стан технічної частини розділуЯкщо карта сайту не віддається, пагінація рубрик плодить дублі, а теги конкурують зі статтями — у роботу додається технічний блок. У виміряному нами сайті клініки всі три адреси карти сайту відповідали 404.

Без цього не почнемо — краще підготувати заздалегідь

1. 1Доступ до Search Console. Без нього неможливо відрізнити матеріал, який працює, від просто опублікованого — лишається зовнішня оцінка попиту з відповідною точністю.
2. 2Чесна відповідь, хто всередині компанії писатиме або хоча б вичитуватиме матеріали й скільки годин на тиждень має. Від цієї цифри залежить уся черга, і завищувати її собі дорожче.
3. 3Перелік комерційних сторінок, на які блог має вести, з позначкою пріоритету за виручкою.
4. 4Доступ до CMS — подивитись, як улаштований розділ: пагінація, теги, сторінки авторів, карта сайту.
5. 5Одну людину з вашого боку з правом затвердити рубрикатор. Каркас, погоджений трьома відділами по черзі, перетворюється на список побажань.

Якщо чогось із цього немає — скажіть, підкажемо, як зібрати або зробимо самі окремою задачею.

Що зазвичай беруть разом із цією задачею

• інформаційна стаття для сайту
• Оновлення старого контенту — що входить
• FAQ під голосовий пошук: питання цілим реченням, відповідь у два рядки — терміни та умови
• не працює карта сайту
• SEO сайт послуг