«Без воды» не означает «как можно короче». Статья может быть большой и плотной, если задача требует сравнения вариантов, расчёта, оговорок и доказательств. Короткий текст тоже может быть пустым, если он повторяет вопрос, перечисляет очевидности и отправляет читателя за настоящим решением в другое место. Поэтому редакции нужен не счётчик знаков, а контракт полезного результата.

Контракт начинается с одного предложения: «после материала читатель сможет сделать X в условиях Y и проверить результат Z». Это предложение задаёт границу. Если в него попали три разных результата, вероятно, нужен hub и самостоятельные материалы. Если результат нельзя наблюдать даже в учебном примере, вопрос сформулирован слишком широко.

Начните с одного вопроса

Запишите первичный вопрос словами читателя, а не названием вашей услуги. Рядом укажите ситуацию, ограничение и ожидаемое решение. «SEO» — тема. «Как объединить близкие запросы и назначить один целевой URL» — задача. «Как выбрать между rewrite и redirect, если две старые статьи пересекаются» — другая задача, которая требует самостоятельной логики.

Проверьте существующий сайт до нового brief. Если ответ уже есть, оцените, можно ли обновить его на прежнем URL. Новая формулировка запроса не является основанием для новой страницы. Самостоятельный материал нужен, когда меняются пользовательская задача, тип решения, evidence или следующий шаг. Это защищает библиотеку от каннибализации ещё до написания.

Дайте ответ до объяснения контекста

Первые абзацы должны позволить человеку принять начальное решение. Не начинайте с истории отрасли, определения общеизвестного термина или обещания «далее вы узнаете». Сформулируйте рекомендацию, назовите условия её применимости и перечислите ключевые действия. Контекст, механизм и доказательства идут следом и помогают проверить ответ, а не заменяют его.

Прямой ответ не обязан быть категоричным. Для меняющихся или чувствительных условий честная формулировка звучит так: «используйте этот порядок при таких предпосылках; если есть исключение, остановитесь на шаге три и получите профильную проверку». Точность лучше уверенного обещания, которого источник не поддерживает.

Редакционный шаблон и quality gate

Шаблон состоит из девяти блоков: вопрос; прямой ответ; кому и при каких условиях подходит; алгоритм; самостоятельный пример; evidence; риски; ограничения; практический следующий шаг. Порядок можно менять после прямого ответа, если этого требует жанр. Нельзя убирать блок только потому, что он мешает обещанию выглядеть простым.

Блок

Что должен доказать

PASS

HARD FAIL

Вопрос

граница задачи

один результат

несколько несвязанных интентов

Прямой ответ

начальное решение

доступен в начале

спрятан после вступления

Алгоритм

воспроизводимость

есть входы и критерии

общие советы без действия

Evidence

обоснование claims

источник поддерживает тезис

критический тезис без источника

Пример

применимость

показывает решение

вымышленный успех или цифры

Ограничения

границы

понятно, когда метод не подходит

условия скрыты

Следующий шаг

завершение задачи

конкретное действие

только рекламная ссылка

Hard fail означает возврат в работу, а не снижение балла. Суммарная оценка не должна позволять красивой обложке компенсировать неподтверждённый правовой тезис или отсутствие прямого ответа. Остальные свойства можно оценивать по шкале: ясность, полнота, пример, навигация, стиль и техническая готовность.

Стройте алгоритм вокруг решений

Инструкция полезна, когда на каждом шаге известны вход, действие, критерий завершения и ветвление. Вместо «изучите аудиторию» напишите, какие данные собрать, как отличить наблюдение от гипотезы и что делать при противоречии. Вместо «оптимизируйте заголовок» укажите, какой вопрос он обещает решить и как проверить отличие от соседних страниц.

Если процедура зависит от инструмента, отделите неизменный метод от кнопок интерфейса. Назовите дату проверки платформенных шагов, сохраните ссылку на официальную документацию и назначьте nextReviewAt. Тогда небольшое изменение интерфейса не разрушит весь материал, а редактор поймёт, какую часть перепроверять.

Подкрепляйте claims, а не украшайте текст ссылками

Сначала выпишите утверждения, которые могут повлиять на деньги, право, безопасность, здоровье или существенное решение. Для каждого назначьте критичность и источник. Официальная документация продукта подтверждает его условия; закон или регулятор — правовое правило; первичное исследование — собственные результаты и метод. Вторичный пересказ не должен подменять доступный первоисточник.

Источник должен поддерживать именно написанное. Ссылка на общую справку Google не доказывает гарантированный рост позиции после конкретного приёма. Описание метрики не доказывает причинность. Если источники расходятся, покажите конфликт и условия, а не выбирайте удобную цитату. Если evidence нет, сузьте тезис или поставьте MANUAL_REVIEW.

Создайте пример без выдуманного успеха

Пример нужен для переноса метода, а не для эмоционального подтверждения. Можно использовать явно обозначенную учебную ситуацию: редакция получила черновик о семантическом ядре. Вопрос сформулирован широко, прямой ответ начинается на пятом экране, а пример содержит неподтверждённую частотность. Quality gate возвращает материал по трём причинам и задаёт конкретные исправления.

Нельзя превращать пример в несуществующий кейс: не приписывайте компании рост трафика, выручки или конверсии, если нет реальных данных и разрешения. Условный расчёт помечайте как расчёт, показывайте формулу и допущения. Личный опыт пишите только при наличии автора и исходников, иначе используйте аналитический формат.

Реализуйте уникальный инструмент

Каждая статья должна давать переносимый артефакт: таблицу решения, шаблон, калькулятор, карту, сценарий проверки или чек-лист. Он обязан работать внутри материала и соответствовать вопросу. Декоративный список из общих советов не является уникальным элементом. В этом гайде таким инструментом служит таблица hard-fail gate, по которой можно вернуть черновик с наблюдаемой причиной.

Проверьте инструмент на одном реальном черновике. Заполните его без помощи автора и отметьте места, где критерий допускает две трактовки. Уточните формулировку и добавьте пример. Если артефакт нельзя применить без устного объяснения создателя, статья ещё не стала самостоятельной.

Сделайте структуру доступной

Используйте один H1, затем последовательную иерархию H2 и H3. Заголовки должны описывать раздел вне оглавления. Ссылки называют цель, а не «сюда». Таблица требует понятных заголовков столбцов; изображение — содержательный alt, если несёт информацию. Цвет не должен быть единственным способом показать PASS или FAIL.

Короткие абзацы помогают сканированию, но не дробите связанную мысль на десятки однофразовых строк. Термин расшифровывайте при первом значимом употреблении. Интерфейсные названия и англицизмы оставляйте там, где они необходимы для действия; иначе выбирайте понятный русский эквивалент.

Проверьте metadata как обещание

Title и H1 могут отличаться длиной, но должны обещать одну задачу. Уникальное description кратко объясняет, кому и чем поможет конкретная страница. Не перечисляйте ключи и не копируйте один шаблон на весь кластер. Поисковая система может выбрать другой title или snippet из видимого текста, поэтому начало статьи должно оставаться точным само по себе.

Structured data описывает видимую статью: реального автора, headline и честные даты. Не меняйте dateModified ради вида свежести, если содержание существенно не пересматривалось. Canonical указывает основной URL, но не исправляет разницу между обещанием metadata и слабым ответом.

Проведите выпускную проверку

Первый проход выполняет автор: проверяет контракт, источники и уникальный элемент. Второй — редактор без контекста производства: пытается завершить задачу только по странице. Третий — технический валидатор: ссылки, metadata, canonical, structured data, изображения и отсутствие запрещённых состояний. Для рискованной темы добавляется профильный fact-check.

Результат проверки храните рядом с материалом: дата, версия, список claims, статус каждого hard fail, владелец следующего review. PASS не означает бессрочную истинность. Меняющийся продуктовый интерфейс может потребовать проверку через месяц, устойчивый метод — через полгода. Срочный review запускается при изменении источника или обнаружении ошибки.

Отделите обязательное от улучшений

После hard-fail gate заведите второй список — улучшения, которые не блокируют выпуск: сократить повтор, упростить пример, добавить навигацию, уточнить иллюстрацию. У каждой записи есть владелец и срок, но она не маскирует обязательный дефект. Такое разделение защищает процесс от двух крайностей: бесконечной полировки безопасного текста и публикации критически неполного ответа под видом минимально жизнеспособной версии.

Если срок ограничен, сужайте обещание статьи, а не вырезайте доказательства. Лучше полноценно решить один подвид задачи и назвать границу, чем оставить широкий title с тремя поверхностными разделами. После выпуска новые наблюдения попадают в review, а не автоматически раздувают страницу: редактор решает, уточнить существующий ответ, создать самостоятельный spoke или честно отказаться от темы.

Ограничения и практический следующий шаг

Quality gate не гарантирует индексацию, позицию или трафик. Он также не заменяет профильного специалиста в чувствительной теме. Длина зависит от задачи; поисковая система может изменить представление title и snippet; автоматическая проверка не распознаёт все смысловые ошибки. Цель gate — не обещание результата, а прозрачная минимальная готовность материала.

Практический следующий шаг: возьмите один существующий черновик и заполните таблицу gate. Сначала исправьте hard fail: прямой ответ, source support для критических claims, ограничения и применимое действие. Затем удалите абзацы, которые не меняют решение читателя, и добавьте недостающее evidence. Только после этого редактируйте стиль и metadata.

Что читать дальше