• Документирование своих замыслов. Если есть замысел, то его необходимо извлечь из головы, зафиксировать все пожелания и требования на бумаге и запустить в производство. Это совместная работа, которая строится на основе регулярных интервью с заказчиком и последовательных согласований.
• Понять реальный объем и стоимость работ, а так же сроки исполнения.
• Иметь чёткий план тестирования и приёмки результатов проекта.
• Убедиться в компетенции исполнителя до начала финансирования работ по проекту. Если техзадание полно и четко отражает замысел проекта, доверие к исполнителю усиливается и поиск нового можно прекратить. В противном случае можно продолжить поиск нового исполнителя.

• Четкие и понятные руководства к действию.
• Согласованное расписание работ по проекту.
• Чёткий план тестирования и приёмки результатов проекта.
• Страховка от того, то заказчик может изменить согласованный объем работ по проекту на этапе исполнения.

Вообще техзадание может составить кто угодно. «Нужен интернет магазин для продажи автозапчастей» — чем не техзадание? Но будет ли такое ТЗ руководством к действию для исполнителя? Вряд ли.

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

Но это не означает, что заказчик не принимает ни какого участия в разработке ТЗ для собственного сайта. Он так-же участвует в процессе, но в роли интервьюируемого эксперта со стороны заказчика.

Очевидно, что ТЗ представляет собой вполне определенную ценность как для заказчика, так и для исполнителя. А раз так, то за неё должен кто-то платить.

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

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

С одной стороны, вполне очевидно, что платить должен заказчик, и если заказчик уже имел ранее положительный опыт работы с исполнителем-разработчиком ТЗ для сайта, тут не возникает вопросов. Но если у заказчика нет опыта, или хуже того, есть отрицательный опыт, как тут быть? Ни кто не хочет брать "кота в мешке". Это понятно.

С другой стороны, со стороны исполнителя, есть риск выполнить работу, которая полностью или существенная часть которой перекочует затем в другую веб-студию, а от туда в третью и т.д., пока у заказчика не выкристаллизуется идеальное ТЗ для его сайта, при этом абсолютно бесплатно.

В различных веб-студиях есть свой подход к этому вопросу, у нас выработался свой компромиссный вариант - для новых заказчиков, заказчиков без рекомендаций, прежде чем приступить к работе над описанием ТЗ, в зависимости от предварительной оценки объема проекта, мы берем символическую предоплату (депозит) от 10 000 до 50 000 руб. Если дело доходит до окончательного согласования ТЗ и подписания договора на его исполнение в нашей студии, сумма депозита учитывается в общем бюджете проекта. В противном случае депозит не возвращается.

Готовое решение (тиражное решение, отраслевое решение и т.д.) это готовый сайт – плод работы большой проектной команды специалистов (маркетологов, программистов, аналитиков, дизайнеров, SEO и прочих профессиональных экспертов web-индустрии), созданный однажды для крупного клиента, скрупулёзного, с изысканными требованиями. Бюджет на создание таких сайтов может достигать несколько миллионов рублей. После того, как проект сдается заказчику, исходники проекта модифицируются (весь контент, включая картинки переписывается в нейтральный, обезличенный, но основной функционал остается), выпускается демонстрационный сайт, затем он пакуется и выкладывается на Маркетплейс для всех желающих приобщится к прекрасному за небольшие деньги.

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

Например решение для создания интернет-магазина. Заказчик изучает демо-сайт, как упаковку для своих товаров, оценивает удобство для совершения покупки, дизайн и прочие детали, если все устраивает, покупает решение. Затем изменяет демо-контент включая демо-картинки на свои и вуаля - получает современный технологичный интернет-магазин по приемлемой цене. Именно это и называют «Готовым решением».

Другими словами, вы получаете полноценный работающий сайт с проработанным дизайном и набором модулей, именно такой, каким вы его видите в демо-версии.

1. Если у вас еще нет лицензии Системы управления сайтом «1С-Битрикс», то вам предстоит её купить; 
2. Если у вас еще нет договора с хостинг провайдером на размещение вашего веб-сайта в его дата-центре, вам предстоит его заключить;
3. Если у вас еще нет домена (веб адреса) в интернете для вашего сайта, вам предстоит его зарегистрировать.
4. Если у вас нет квалифицированного специалиста, который поможет вам все установить и настроить, вам предстоит его нанять.
   

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

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

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

Структура может быть и индивидуальной (отличной от конкурентов), но обязательно она должна быть удобной для людей, отвечать их логике, а значит логике и поисковых систем и такой, чтобы можно было охватить все тематические слова. Она должна быть лучшей и удобной!

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

Мы спарсили запросы и у нас получился список различных слов. В нем конечно же присутствуют нужные слова, а так же и мусорные – пустые, не тематические, не актуальные. Поэтому их надо почистить.

Такие слова не удаляем, а перемещаем их в отдельные группы, потому что:

1. Они в дальнейшем могут стать пищей для размышления и приобрести актуальность.
2. Исключаем вероятность случайного удаления слов.
3. При парсинге или добавление новых фраз, они не будут добавляться, если поставить галочку

Сбор частотностей

Собираем у всех слов через direct, базовую частотность [W] и точную [“!W”].

Все что не собралось, дособираем через wordstat.

Чистка однословников и не формат

Фильтруем по однословникам, смотрим их и убираем не нужные.

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

Так же смотрим, по каким словам не собралась частотность – это либо в словах содержатся спец символы, либо слов в запросе более 7. Переносим их в неформат. Малая вероятность что такие запросы вводят люди.

Чистка по общей и точной частотности

Все слова с общей частотностью [W] от 0 до 1 убираем.

Так же убираем и все от 0 до 1 по точной частотностью [”!W”].

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

Значение от 0 до 1 тоже берется исходя от тематики, если ключевых слов много, то можно фильтровать и от 0 до 10. То есть все зависит от широты  тематики и предпочтений.

Чистка по полноте охвата.

Теория здесь такова: например, есть слово – “форум”, его базовая частотность составляет 8 136 416, а точная частотность 24 377, как видим отличие более чем в 300 раз. Поэтому можно предположить, что данный запрос пустой, он включает очень много хвостов. Поэтому, по всем словам, я расставляем, такое KEI: Точная частотность / Базовая частотность * 100% = полнота охвата.

Чем меньше процент, тем больше вероятность того, что слово пустое.

В KeyCollector эта формула выглядит вот так: YandexWordstatQuotePointFreq / (YandexWordstatBaseFreq+0.01) * 100. Здесь тоже все зависит от тематики и количества фраз в ядре, поэтому можно убирать полноту охвата меньше 5%. А где ядро большое, то можно не брать и 10-30%.

Чистка по неявным дублям.

Чтобы почистить неявные дубли, нам необходимо по ним собрать частотность Adwords и ориентироваться по ней, потому что она учитывает порядок слов. Экономим ресурсы, поэтому будем собирать этот показатель не у всего ядра, а только у дублей. Таким способом мы нашли и отметили все не явные дубли. Они у нас в рабочей группе. Теперь отобразим только их, потому что съем параметров происходит только тех фраз, которые у нас показаны в группе на данный момент.

И только потом запускаем парсинг. Ждем, когда Adwords снимет показатели и заходим в анализ неявных дублей. Выставляем параметры умной групповой отметки и нажимаем – выполнить умную проверку. Таким способом у нас в группе дублей не отметятся только самые высокочастотные запросы по Adwords.

Чистка по стоп словам

Стоп слова тоже делим на группы. Отдельно заносим города. Они могут пригодится в дальнейшем, если мы надумаем делать каталог организаций. Отдельно заносим слова содержащие в себе слова фото, видео. Вдруг они когда-нибудь пригодятся. А так же, “витальные запросы”, например википедия, относим сюда и форум, а так же в мед. теме сюда могут относится – малышева, комаров и т.д. Все зависит от тематики. Можно еще делать отдельно и коммерческие запросы – цена, купить, магазин.

Чистка накрученных слов

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

Чистка по гео

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

Ручная чистка

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

1. Стоит покопаться, можно найти слова на будущее.
2. Могут пригодиться, если будем расширять сайт новыми сервисами.
3. Не пригодятся.

Конкуренция по количеству документов, title, главных страниц

Это все легко снимается через KEI в KeyCollector.

Получаем данные по каждому запросу, сколько документов найдено в поисковой системе, пример в Яндексе. Сколько главных страниц в выдаче по этому запросу и вхождений запроса в заголовок.

Конкуренция по биржам ссылок

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

Собираем данные по биржам и выводим средние показатели и уже ориентируемся по ним.

Обычно мы собираем по 2-3 биржам. Главное чтобы все запросы были собраны по одним и тем же биржам и выведено среднее число только по ним. А не так, что какие то запросы собрали одними биржами, а другие другими и вывели среднее.

Для более наглядного вида можно применить формулу KEI, которая покажет стоимость одного посетителя исходя из параметров бирж:

KEI = AverageBudget / ( AverageTraffic +0.01)

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

Конкуренция по мутаген

Сервис мутаген создан специально для анализа конкуренции информационных запросов. Работает с 2011 года, принцип алгоритма не разглашается, но вполне себе годно рассчитывает. Конкуренция рассчитывается по 25 баллам. Чем больше балл, тем больше конкуренция: 1-7 низкая конкуренция, 8-15 средняя, 16 и выше, высокая. Тут сразу показываются просмотры по вордстату, ключи хвосты, клики в яндекс директ.

В KeyCollector есть возможность массового сбора по мутаген.

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

При группировке семантического ядра мы руководствуемся здравой логикой, сравнивая её с выдачей.

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

Итак, в KeyCollector у нас есть чистенький список запросов и мы собрали по нему данные из поисковой выдачи. Чтобы облегчить работу, группируем ядро средствами KeyCollector.

Заходим в анализ групп, ставим по поисковой выдаче Яндекс, сила 2. Обновляем группировку и экспортируем результаты в Excel.

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

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

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

Смотрим первую группу:

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

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

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

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

KEI1 (полнота охвата) выводим по уже известной нам формуле:

["! W"]/[W]*100

Получается вот такая красота:

Данные по "рубрике рецепты блинов на молоке" еще не суммируем, потому что скорее всего туда добавятся еще запросы. Но и не исключено, что в “простой рецепт блинов на молоке” тоже еще добавятся запросы.

В дальнейшем, мы находим еще похожие запросы в нашу группу с простым рецептом, которые содержат дополнение “фото”. Фото, видео – это все дополнительные запросы их кидаем в одну группу со смежными запросами. Нет же смысла делать отдельно страницу только с фотками и только с видео? Это мать его, дубли получатся.

Видим, что и “легкий” сюда пожаловал. Простой и легкий – это одно и тоже же? Конечно же, да. Добавляем это все в нашу группу и получаем еще красивее, не забываем просуммировать новые данные.

Дальше встречаем запрос “рецепт блинов на молоке и воде”.

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

К тому же тут еще и затесался запрос с “тонкие блины”. Его тоже отдельно, он будет страницей к рубрике “рецепт блинов на молоке и воде”

И таким вот способом перерабатываем все ядро, в итоге получается вот так:

Красным шрифтом помечены дополнительные фразы, которые имеют приставки фото, видео. Для нас это не совсем актуальные фразы. Эти фразы конкурируют с сервисами поисковых систем и трафику по ним очень мало. Но эти фразы подходят по нашему смыслу, поэтому мы их добавляем в группу.

Каждая группа помечена своим цветом. Цвет является структурой сайта, то есть уровнем вложенности страницы.

Например, если бы у нас был запрос “простой рецепт блинов на скисшем молоке”. То он бы уже шёл, как подгруппа к группе “блины на скисшем молоке” и естественно был бы выделен другим цветом. Выглядело бы это вот так:

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

Новые или измененные разделы добавляем в нашу структуру в xmind.

В общем, чтобы нормально разгруппировать ядро необходимо мыслить логически, вставать на место посетителя, отвечать на вопрос – что он хочет увидеть, введя этот запрос? А также смотреть выдачу по этому запросу и принимать решение, как поступить наилучшим образом.