Ядро (в каждой статье)
- H1. Содержит основной запрос и обещает результат. Формулы: «Как [сделать] в [системе]», «[Проблема]: причины и что делать», «Способы [сделать что-то]: сравнение».
- Короткий ответ (2-4 предложения). Идёт сразу под H1 и заменяет вступление. Он должен быть понятен без чтения статьи и пригоден для цитирования в AI-ответах. Никакой воды и истории вопроса.
- Основная часть. Зависит от типа статьи (см. ниже).
- Частые вопросы (3-6). Только реальные вопросы клиентов и менеджеров. Каждый ответ самостоятельный, 1-3 предложения.
- Итог (2-3 предложения). Кому и что нужно сделать. Без пересказа статьи.
- CTA. Одно следующее полезное действие, связанное с темой статьи (см. ниже).
- Автор и доверие. Имя, должность, реальный опыт в одну строку, дата публикации, дата обновления, ссылки на первичные источники.
Тип A. Гайд / инструкция
Примеры: «Способы проверки контрагента», «Как передавать заказы из amoCRM в МойСклад».
- Что понадобится / для кого (1-3 строки, только если есть условия или ограничения).
- Способы или шаги. Каждый способ или шаг отдельным H2 в виде вопроса или утверждения. Внутри: что делать, где нажать, скриншот, результат.
- Сравнение способов. Таблица: способ, для кого, плюсы, ограничения. Нужна, если способов больше двух.
- Типичные ошибки. Формат «ошибка → почему → что делать». Включать только реальные ошибки из поддержки, без выдуманных.
- Когда этого недостаточно. Один блок, и только если это правда (нестандартные статусы, несколько складов и т.д.). Не продавать разработку искусственно.
Вариант для troubleshooting («Почему не совпадают остатки»): вместо шагов идут симптом, причины (механизм → как исправить) и как проверить, что исправлено.
Тип B. Кейс / разбор из практики
- Клиент и задача. Тип бизнеса, исходные системы, объём (только реальные цифры).
- Что было не так. Что делали вручную, где возникали ошибки.
- Что сделали. Схема обмена, правила, что настроили, какие ограничения обнаружили.
- Результат. Цифры до и после. Если цифр нет, писать без них, а не придумывать.
- Что из этого применимо вам. 2-4 пункта, как проверить, подходит ли вам такое решение.
Здесь можно коротко описать методологию («как мы решаем такие задачи»), но только здесь, а не в каждой статье.
CTA
- Гайд: ведёт на ближайший полезный шаг. Если у вас есть инструмент по теме (например, проверка контрагента), то на него. Иначе на короткую консультацию.
- Кейс: «Опишите, какие системы используете и где возникает ручная работа. Разберём процесс и предложим вариант автоматизации».
Продажа только в CTA и, для кейса, в его собственном блоке. В основной части гайда услуг быть не должно.
Правила заголовков и текста
- H2 должен быть понятен вне контекста, как самостоятельный запрос или утверждение. «Преимущества» и «Особенности» не годятся.
- Ключи ставим там, где они нужны естественно, плотность не считаем. Основной ключ в H1, title, первом абзаце и slug.
- Короткие абзацы, причина → следствие, конкретика вместо эпитетов. Определения и историю темы не пишем.
- Списки и таблицы там, где данные однородны (сравнение, шаги, статусы).
Технический чеклист под Тильду
- Title (до ~60 символов), description (до ~160), slug латиницей, один H1 на страницу.
- Один эталонный шаблон страницы, который дублируется. Заранее собранные блоки: «Короткий ответ», таблица, FAQ, карточка автора.
- Разметка Article и Person через HTML-блок в шаблоне.
- Внутренние ссылки: минимум 2-3 на связанные статьи и 1 на страницу услуги или продукта.
- Правило обновления даты: кто и когда меняет, и только при реальном изменении содержания.
- Alt у изображений, подписи к скриншотам.
Чеклист перед публикацией
- Один основной интент, ответ виден в первых 3-4 строках.
- Все факты, цифры, сроки и штрафы сверены с первоисточником, ссылки стоят.
- Нет ни одного факта, который нельзя подтвердить (кейсы, цифры, ошибки).
- Скриншоты сделаны на реальном процессе.
- FAQ из реальных вопросов.
- Есть автор и даты.
- Продажа не мешает содержанию.
Правило для Gemini (важно для теста)
В промпт вместе с шаблоном подаются входные данные: ссылки на первичные источники, скриншоты, реальные вопросы клиентов и комментарий эксперта. Добавьте жёсткую инструкцию: «Используй только факты из входных данных. Если данных для блока нет, напиши "НЕТ ДАННЫХ", ничего не придумывай. Кейсы, цифры и ошибки не выдумывать». Готовую статью до публикации проверяет человек по чеклисту выше.
Могу оформить это в документ для маркетолога или сразу написать промпт для Gemini под тест на теме «Проверка контрагента». Что предпочтёшь?