Начало разработки сайта: что необходимо продумать и сделать перед тем, как перейти к дизайну и программированию

«Мне нужен сайт по химическому сырью. Сколько это будет стоить?» — спросить о бюджете можно и в самом начале. Но чтобы оценить работу в часах и деньгах, нужно понять, о каком сайте идёт речь: какие задачи он решает, что на нём будет и кто им станет пользоваться. Иначе заказчик представляет один проект, а исполнитель оценивает другой.

Для того чтобы и заказчик, и исполнитель одинаково понимали, о чём именно идёт речь, проекту нужно описание требований. Подробное ТЗ (техническое задание) пишется уже тогда, когда есть детальное понимание структуры, функционала и особенностей сайта. Нужен ли вам сайт-каталог или интернет-магазин, предполагаются ли внешние интеграции и какие именно, будет ли онлайн-калькулятор или возможность записи онлайн?

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

Цели сайта и целевая аудитория

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

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

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

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

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

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

Анализ конкурентов в топе поисковой выдачи

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

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

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

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

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

Составьте простую таблицу наблюдений. Для каждого сайта запишите:

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

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

Анализ seo запросов в рамках вашей специфики

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

Для этого нужно проанализировать поисковые запросы пользователей в Яндекс Вордстате (Wordstat). Продумайте формулировки, которые могли бы вводить ваши потенциальные клиенты, и проверьте их в сервисе. Вордстат показывает статистику запросов к Яндексу, динамику популярности и различия между регионами. Фантазия здесь помогает составить исходный список, а данные — проверить предположения.

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

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

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

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

Именно поэтому ядро SEO-запросов стоит обсуждать ещё на этапе структуры. В нашей студии структура под SEO закладывается при разработке сайта. Но результат такой работы — не просто длинный список ключевых слов, а понятное распределение тем по страницам и план их наполнения.

От запросов к структуре и содержанию

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

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

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

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

Референсы

Итак, вы примерно определились с тем, что будет на новом сайте. Теперь нужно разобраться, как это презентовать: выбрать стилистическое направление и объяснить его дизайнеру.

Светлая или тёмная тема? Лаконичность или брутализм? Подчёркнутый профессионализм или уютная дружелюбность? Изящные или массивные рубленые шрифты? Много широкоформатных изображений, чтобы в деталях рассмотреть каждое, или мозаика фотографий для общего впечатления? Свёрнутое меню в формате бургера или подробная карта сайта? А как насчёт анимаций и эффектов при наведении: «всё летает и трансформируется» или вы предпочитаете традиционные сайты, где ничего «не дёргается»?

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

Подберите 2–3 удачных референса — сайта, которые нравятся вам по внешнему виду. Это могут быть проекты из вашей продуктовой ниши или совершенно другой сферы. Сами примеры тоже не обязаны быть похожими: у одного может нравиться типографика, у другого — фотографии, у третьего — ощущение пространства.

Некоторые клиенты избегают предоставления референсов, мотивируя отказ тем, что не хотят копировать другие сайты, а хотят получить полностью индивидуальный дизайн. Однако референсы нужны не для копирования, а для того, чтобы студия понимала, что вы подразумеваете под стильным дизайном и какое настроение кажется вам наиболее близким собственному проекту. Если ориентиров нет, подрядчик может предложить что-то на свой вкус, что вам не понравится: вкусы у всех разные.

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

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

Подготовка ТЗ / Бриф

Когда есть чёткое понимание, как на рынке продают подобные услуги и товары, как потенциальные заказчики ищут компании и как примерно вы хотели бы выглядеть в интернет-пространстве, можно переходить к созданию ТЗ на сайт. Здесь пригодятся задачи, аудитория, наблюдения о конкурентах, структура и референсы.

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

В брифе дайте пояснения по следующим вопросам:

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

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

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

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

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

Не стоит делать за веб-дизайнера всю его работу, но и отказываться от содержательных требований не нужно. Бриф задаёт контекст, а ТЗ фиксирует согласованный объём и поведение сайта. Конкретное визуальное решение удобно согласовать в прототипе и макетах, сохраняя обязательные требования к содержанию и сценариям.

Что превратить в проверяемые требования

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

Для интеграции мало строки «связать с CRM» или «сделать обмен с 1С». Перечислите, какие данные передаются, в какую сторону, что запускает обмен и кто разбирает неудачную передачу. Согласуйте, где меняют цену, остаток, статус заказа и описание. Если схема ещё неизвестна, выделите обследование интеграции в отдельную задачу перед её оценкой.

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

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

Ведите список открытых вопросов: что неизвестно, кто выясняет и к какой дате нужен ответ. Изменения после согласования тоже записывайте — вместе с влиянием на объём, стоимость и сроки. Тогда фраза «мы вроде это обсуждали» не станет единственным основанием для приёмки.

Нейминг

Иногда компания начинает обсуждение сайта без названия: «придумается позднее». Для исследования аудитории и структуры это не препятствие. Но перед утверждением визуальной концепции мы бы рекомендовали определиться с названием: его написание, длина и ассоциации нужны для обсуждения логотипа и характера оформления.

Связка здесь такая: название помогает сформулировать образ бренда, фирменные решения задают ориентиры для сайта. Если нейминг идёт параллельно, прямо обозначьте, какие решения временные и к какому этапу появится окончательный вариант. Не нужно останавливать подготовку, но и рассчитывать, что любая замена пройдёт без пересмотра макетов, не стоит.

Аналогия — платье на заказ: без мерок можно выбрать ткань и обсудить фасон, а точную посадку проверить позже. Так и с сайтом: анализ и содержание можно готовить заранее, но размеры надписи, знак и визуальные акценты нужно проверить на окончательном названии. Если оно появится после согласования дизайна, заранее включите повторную проверку макетов в план работ и назначьте ответственного.

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

Домен обсудите вместе с названием. Зафиксируйте желаемый адрес, кто проверяет его доступность и кто будет администратором. Рекомендуем оформлять управление на владельца проекта и сохранять у него возможность восстановления доступа. Доступность адреса и допустимость использования названия — отдельные вопросы, которые не стоит смешивать.

Логотип, фирменный стиль, цветовая гамма

Следом за названием идёт фирменный стиль компании, который определяет цветовые решения, шрифты, характер используемых в оформлении визуальных элементов и пропорциональное соотношение между элементами на разных носителях. Если правила уже есть, передайте дизайнеру исходники и руководство по применению, а не только картинку логотипа из переписки.

В идеале разработка дизайна сайта должна отталкиваться от фирменного стиля: это помогает создать единый целостный образ компании, который будет транслироваться онлайн и офлайн. Наличие фирменного стиля даёт ориентиры дизайнеру и заказчику. Однако оно не гарантирует, что сайт сразу понравится всем: структуру, содержание и конкретные макеты всё равно нужно обсуждать и проверять.

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

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

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

Бюджет, сроки и границы первого запуска

Ещё до выбора подрядчика обозначьте доступный бюджет и желаемую дату запуска. Если точного лимита нет, попросите варианты состава работ с объяснением различий. Фраза «скажите, сколько стоит сайт» становится предметной, когда рядом есть цели, структура и список функций.

Разделите расходы по назначению. Так проще увидеть, что действительно входит в предложение и какие задачи остаются на стороне заказчика:

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

Уточните, какие платежи разовые, какие повторяются, кому принадлежат лицензии и кто их продлевает. Не закладывайте универсальный процент «на непредвиденное»: обсудите конкретные неизвестные задачи и порядок их оценки. Для сложной интеграции разумнее сначала понять объём, чем прятать неопределённость в общей строке.

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

Срок полезно привязать к причине: выставке, сезону, открытию направления. Затем отметьте зависимости: кто согласует структуру, когда появятся фотографии, кто предоставит тестовый доступ к учётной системе. Дата в плане должна учитывать эти договорённости, а не только пожелание «как можно скорее».

Сравнивая сметы, смотрите на одинаковый состав работ, количество шаблонов, наполнение, интеграции и условия приёмки. Уточняйте, включены ли мобильные версии, обучение редактора, перенос материалов и проверка после размещения. Если чего-то нет в предложении, попросите зафиксировать, кто это выполняет и как оценивается.

Доступы и ответственность за сайт

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

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

Договоритесь о безопасном способе передачи секретов и о восстановлении доступа у владельца проекта. Не отправляйте общий пароль всей команде и не смешивайте тестовые настройки с рабочими. После завершения этапа пересмотрите выданные права, отзовите лишние и зафиксируйте передачу результата.

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

Выбор студии

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

• Проанализируйте сайты конкурентов в поиске и запишите полезные решения без догадок о причинах их позиций.
• Составьте примерную карту поисковых запросов, чтобы понять, как клиенты формулируют свою задачу.
• Подберите 2–3 референса из любой сферы и подпишите, что именно вам нравится.
• Утвердите название, подготовьте логотип и фирменный стиль либо запишите, когда и кто определит визуальные ориентиры.
• Подготовьте ТЗ либо краткое описание вашего проекта для понимания сути задачи: целевая аудитория, функционал, особенности сайта и предполагаемая структура.
• Добавьте список контента, бюджетные ограничения, сроки, ответственных и перечень нужных доступов.

С таким пакетом можно обращаться в студии для предметного обсуждения проекта и оценки его стоимости. Договоритесь о следующем шаге: какие вопросы нужно закрыть, кто готовит требования и когда можно согласовать объём разработки. Уточните у подрядчика, когда его команда сможет приступить к работе. После этого выбор подрядчика опирается на конкретное предложение.

Вот несколько советов на предмет того, как выбрать хорошую веб-студию. Для подготовленного проекта попросите кандидатов объяснить состав работ, этапы согласования, результат каждого этапа и правила внесения изменений. Сравнивайте эти ответы вместе с работами и условиями договора.

Разумеется, приведённый список не является жёстким: если что-то из вышеперечисленного у вас отсутствует, этот вопрос можно включить в подготовку проекта. Для начала работ потребуется его прояснить и назначить ответственного. Необязательно приходить с полностью готовой структурой и написанным ТЗ — нужно понимать, что уже решено, а что вы ожидаете проработать вместе с подрядчиком.

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

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

Можно ли обращаться в студию без готового ТЗ?

Да. Подготовьте краткий бриф: чем занимается компания, кому нужен сайт, какое действие он должен помогать выполнить, какие функции вы предполагаете. Добавьте ограничения по бюджету и срокам, а неизвестные вопросы вынесите отдельно. Затем договоритесь, кто и в каком объёме готовит подробное ТЗ.

Нужно ли сначала написать весь контент?

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

Обязательны ли название и логотип до начала работы?

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

Сколько референсов нужно подготовить?

Для начала можно взять 2–3 сайта и объяснить, что нравится в каждом. Важнее ясность комментария, чем количество примеров. Необязательно искать только в своей отрасли: композицию, типографику и настроение можно обсуждать на разных проектах.

Нужна ли отдельная страница под каждый поисковый запрос?

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

Какие доступы передать подрядчику сразу?

Для первоначального обсуждения подготовьте список сервисов и контакты их администраторов. Рабочие доступы выдавайте под согласованные задачи, отдельными учётными записями и с нужными правами, где это возможно. Восстановление доступа должно оставаться под контролем владельца проекта.

Источники

• Как устроено ранжирование и почему позиция не раскрывает один «секрет успеха» — Google Search Central, «Руководство по системам ранжирования Google Поиска».
• Назначение статистики поисковых запросов — Яндекс, справка Директа, «Сервис подбора слов».
• Ограничения на создание дорвеев и практически одинаковых страниц — Google Search Central, «Правила в отношении спама для веб-поиска Google», раздел «Дорвеи».
• Описание задач пользователя и критериев приёмки — GOV.UK Service Manual, Writing user stories, обновление от 23 мая 2016 года.
• Принцип минимально необходимых прав — OWASP Cheat Sheet Series, Authorization Cheat Sheet, раздел Enforce Least Privileges.