ТЗ на SEO-текст

Происхождение и история

SEO-бриф можно рассматривать как применение более общего контент-брифа к задаче поисковой страницы. В справочнике The Language of Content Strategy, вышедшем в 2014 году под редакцией Скотта Абеля и Рэйчел Энн Бейли, контент-брифу посвящена отдельная глава Коллин Джонс. В опубликованной издателем веб-версии главы бриф описан как план проекта или его этапа: он связывает цель, аудиторию, исполнителей, сроки, форматы и устройство содержания. Это уже самостоятельный рабочий документ, а не только перечень тем для автора. ^[6]

Практику подготовки брифа именно для веб-страницы показывает инструкция NZ Digital Government с датой обновления 15 июня 2020 года. В неё включены название страницы, название для поиска, описание, адрес, тип страницы, автор, ответственный специалист и период пересмотра. ^[7] Такой образец соединяет редакционную организацию работы с поисковым представлением результата. Название для поиска в нём — поле задания, а не обещание, что поисковик воспроизведёт его буквально. ^{[3, 7]}

Эти документы показывают две формы развития практики: общий план работы с содержанием и подробное задание на отдельную веб-страницу. Отнесение SEO-брифа ко второй форме — вывод. Источники не устанавливают, что все организации прошли эти стадии в одном порядке, и не называют первого автора термина. Для читателя существенно другое: поисковые требования встроены в документ, который также согласует содержание и ответственность за него. ^{[6, 7]}

Как устроено задание

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

Следующий шаг — превратить цель в вопросы. Пожелание «написать полезно» трудно проверить. Требование «объяснить, чем отличаются варианты и кому подходит каждый» уже задаёт содержание. Для каждого существенного ответа стоит предусмотреть источник, собственное наблюдение или проверку. Такая работа согласуется с вопросами Google о полноте, оригинальном вкладе и достоверности материала. ^[1]

После этого составляется предварительный план. Рядом с разделами можно указать поисковые выражения, которыми читатели называют предмет. Google рекомендует употреблять такие слова в заметных местах страницы, включая название и основной заголовок. ^[2] В задании это удобно превратить в требование понятно обозначить тему, а не заставлять автора воспроизводить неудобную фразу без изменения.

Отдельно согласуются формат, срок, ответственный за проверку и допустимые изменения. Это организационные условия предлагаемого образца. Если найденный источник опроверг исходное предположение, автор сообщает об этом редактору; тот меняет вопрос или план. Задание сохраняет смысл, когда помогает проверить ответ, а не требует любой ценой подтвердить заранее написанный вывод.

Виды заданий

Для работы удобно различать три ситуации. Это классификация редакции по цели заказа.

Например, задание на обновление может касаться только изменившейся процедуры. Полное переписывание тогда не является самоцелью. В сравнении важно различать отсутствие сведений и отсутствие свойства: если характеристика неизвестна, автор не должен записывать её как недостаток варианта. Это правила предлагаемой редакционной методики, а не заявленная практика всех организаций.

Учебный пример применения

Редакция заказывает страницу «Как подготовиться к первому посещению городского архива». Это учебный пример, не описание реального проекта. Читатель ещё не знает, какое подразделение ему нужно. Цель задания — помочь ему подготовить обращение и проверить условия посещения.

Редактор фиксирует восемь вопросов: куда обратиться; какие сведения о поиске подготовить; какие документы предъявить; нужна ли предварительная запись; как узнать часы работы; какие услуги платные; где проверить ограничения; как уточнить порядок получения результата. Ответы предполагается искать в документах выбранного учреждения. Сами правила архивов этим примером не устанавливаются.

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

Для русскоязычной страницы полезно отдельно проверить формулировки запросов. Яндекс различает бессвязные списки поисковых фраз, искусственное раздувание текста повторами и уместные повторения в меню, каталогах или специальных текстах. ^[5] Поэтому условное требование повторить «архив документы запись» десять раз следует заменить содержательными вопросами о документах и записи. Число десять здесь — иллюстрация неудачного задания, не порог нарушения Яндекса.

Как проверить результат

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

Здесь A — число закрытых вопросов, N — общее число обязательных вопросов в согласованной версии задания, P — их доля в процентах. В учебном примере подтверждены семь ответов из восьми: P = 7 / 8 × 100% = 87,5%. Один вопрос остаётся открытым. При N = 0 показатель не рассчитывают: сначала нужно определить предмет приёмки.

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

Следующая проверка касается заголовков. WCAG — рекомендации по доступности веб-содержимого — в критерии 2.4.6 требуют, чтобы заголовки и подписи описывали тему или назначение. Официальное пояснение отдельно разграничивает ясность текста и правильную разметку. ^[4] В учебном примере «Что взять с собой» понятнее, чем «Важное», но само название ещё не проверяет оформление заголовка в коде и доступность всей страницы.

Наконец, проверяют представление страницы в поиске. Title — элемент с названием страницы; meta description — её краткое описание в коде. Google использует несколько источников для заголовка результата, а описание под ним, сниппет, обычно формирует из содержания страницы и иногда из meta description. ^[3] Поэтому задание может требовать точного описания материала, но не обещать неизменную формулировку будущего сниппета.

Ошибки и ограничения

Требование объёма имеет смысл как условие редакционного формата. Обосновывать его «предпочтительным числом слов Google» неверно: компания прямо отрицает такую универсальную величину. ^[1] Для учебной инструкции важнее закрыть вопросы без повторов, чем дописать абзацы до круглого числа знаков.

Выполнение задания также не гарантирует поискового результата. Google предупреждает, что соблюдение основных требований не обязывает систему сканировать, индексировать или показывать страницу. ^[2] Приёмка текста и последующее наблюдение за поиском решают разные задачи. Первое отвечает на вопрос о выполненной работе автора, второе — о фактической видимости опубликованной страницы.

Частые вопросы

Связанные термины

• seo-kopirayting
• semanticheskoe-yadro
• poiskovyy-intent
• teg-title
• zagolovki-h1-h6
• kontent-plan