Вся статистика в статье представлена только по нашему опыту и может расходиться с вашими данными (проанализировано 68 проектов на SEO, из них 26 — наша разработка и продвижение, а также 23 проекта, где разработка наша, а оптимизация — на стороне).
Web-разработчики очень не любят SEO-оптимизаторов. Естественно, основная проблема в генетически заложенной видовой ненависти, правда, есть и рациональные моменты. Но страдают-то от этого в первую очередь заказчики.
Давайте поговорим о том, к чему этот конфликт может привести и как этого избежать.
Итак, что может случиться с вашим проектом при таком конфликте:
- полный и окончательный провал: деньги потрачены (и немалые), а вместо результата — только неприятные последствия;
- падение продаж через сайт (даже если, проект формально успешен);
- проект успешен, даже продажи выросли, но расходы в несколько раз не вписались в смету;
- да, проект может завершиться благополучно, но это потребует от вас волшебных навыков менеджера и переговорщика.
Анатомия конфликта
Разработчики скажут вам, что «в большинстве своем SEO предлагают бредовые правки, которые _возможно_ улучшат позиции сайта, и требуют убрать ссылку на разработчика (якобы она портит позиции), при этом повесить свою — не стесняются».
SEO скажут, что: «разработчики просто не хотят вносить правки на сайт и не понимают, зачем они нужны, так как не разбираются в предмете. На самом деле — все делается элементарно, а безопасность правок зависит от опыта специалистов».
Вроде бы ситуация понятна, и конфликт неизбежен. Правда, он может быть смягчен, если seo-отдел и отдел разработки — это подразделения одной компании.
Взаимодействие разработчика с оптимизаторами обычно начинается, когда готово техническое задание (ТЗ) на поисковую оптимизацию сайта. Это такой документ, в котором sео-специалисты просят разработчика перекроить сайт под их требования. И тут для заказчика начинаются неожиданности.
В технических заданиях на оптимизацию сайтов обычно присутствуют требования довольно типовые и логичные. О них знают разработчики и предусматривают заранее это в коде. Но и тут бывают нюансы:
1. Задача: сделать «хорошие» адреса страниц (ЧПУ — на SEO-жаргоне).
Недостаточно квалифицированные оптимизаторы ограничиваются это фразой, а дальше по тексту ТЗ используют URL, которые сами придумали, не уточняя, какая страница должна оказаться с таким адресом. Специалисты же пропишут, во-первых, универсальный алгоритм построения ЧПУ для всех страниц сайта, а во-вторых, список страниц, для которых нужны особые адреса в формате «было-стало».
Но задача не всегда решается по-хорошему. Причем, даже для такой вроде бы беспроблемной CMS, как 1C-Битрикс (например, если основной контент сайта — каталог, в котором рубрики заданы выборками через фильтр).
2. Задача: прописать для заданных страниц заданные мета-теги (вроде просто, но снова вспоминаем каталог с фильтрами).
3. Задача: добавить на определенные страницы текстовые блоки. Проблемы могут быть те же. Еще тут заказчика подстерегает опасность со стороны SEO. Если в ТЗ написано «тексты будут предоставлены потом» — ни в коем случае не пускайте его в работу!
Мы рекомендуем сначала написать хорошие тексты, а уже потом решать вопрос с их установкой на сайт. Причины две: во-первых если вы будете подгонять дизайн блока под контент, это в итоге будет смотреться лучше, чем если контент запихивать в блок, не совсем подходящий по структуре для него.
Во-вторых, потому что оптимизаторы могут запросить тексты для сотни страниц. Если вы тексты не дадите — их заказывают у SEO-копирайтеров. Если вы будете их читать перед размещением — у вас может и получится согласовать штук десять за месяц (либо переписать самостоятельно). Если не будете — продвигать сайт бессмысленно, пользователи не станут делать заказы из-за низкого качества контента.
Дальше идут обычно требования к разметке страниц, названиям картинок, ссылкам, robots.txt и т.д. — в общем случае — ничего криминального. Что бывает совсем уж невменяемого (в наших ТЗ, слава Богу, не обнаружено):
- сменить адрес входной страницы («морды» — на SEO-жаргоне) с «sitename.ru» на «sitename.ru/product_name.html»;
- отломать из калькулятора автоподстановку данных из каталога, чтобы вход в калькулятор всегда был с нулевыми данными, и чтобы пользователи вбивали все значения с нуля руками;
- сделать на главной странице две колонки вместо трех (без пояснений, естественно, какой в этом сакральный смысл);
- генерировать заголовки страниц по какой-то экзотической схеме (уверяю вас, заголовки, написанные руками — рулят) и т.д.
Из личного опыта, когда проекты по поисковой оптимизации бывают успешны, а когда наверняка провалятся:
В SEO могут быть разные критерии успешности проекта, разные формальные параметры, но решающим параметром его успеха в итоге всегда является удовлетворенность клиента. Недовольный клиент, даже если выполнены формальные критерии и проект полностью оплачен — принесет компании только потери.
Когда разработчики получают SEO-ТЗ, они обычно находят проблемы с реализацией части требований, а по поводу откровенного бреда начинают задавать вопросы. Заказчик настаивает (на него же давят оптимизаторы) — разработчики выкатывают убедительный ценник.
Заказчик говорит про это оптимизаторам. Те начинают возражать — что сделать все можно элементарно. Естественно, крайним оказывается заказчик.
Варианты развития событий:
- Заказчик платит таки разработчику за реализацию технического задания. Результат: ТЗ сделано, но оптимизаторы все время находят, к чему придраться. Скорее всего, все выльется в конфликт. А заказчик останется с безрадостным чувством, что он переплатил. И из-за этого будет придираться к оптимизаторам. Проект в итоге провалится.
- Реализовать ТЗ вызываются сами оптимизаторы и заказчик идет на это в целях экономии. Результат: с большой вероятностью сайт ломается (даже если у оптимизатора хорошие программисты, сайт-то система сложная!). При этом все будут указывать на кривые руки соседа. Чинить придется заказчику за свой счет. Хорошо, если он не испортил к этому моменту отношения с разработчиком. Третьей командой делать это будет еще дороже и неприятнее. Отношения с командой оптимизаторов при этом также неизбежно портятся. Проект провалится.
Старая шутка
Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?
Программист: ну представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу, как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик ржевский умер.» Выясняется, что он в следующей главе облокачивается о столб, которого уже нет...
- Разработчик забирает к себе проект на SEO. Так тоже бывает, особенно если в первоначальном ТЗ были правки, которые и у заказчика вызывали сильные сомнения. Результат: у заказчика снова ощущение, что он платит дважды за одно и то же, и что его все пытаются обмануть. Проект скорее всего провалится. Вывозится хорошим руководителем проекта на стороне разработчика и то не всегда.
Получается, разрулить конфликт «разработчик-оптимизатор» можно, либо если они договариваются напрямую между собой, а не через заказчика, либо крутым менеджментом на стороне заказчика. Мы смогли это сделать, только начав брать на продвижение исключительно разработанные нами проекты, которые до этого никто, кроме нас, не успел оптимизировать.
Казалось бы, этот вариант идеальный, но даже такие проекты могут в итоге провалиться. Причины обычно — несоответствие ожиданий заказчика формальным критериям, отказ заказчика участвовать в процессе или форс-мажор (который в этой отрасли встречается несколько чаще, чем в остальных). Как бороться с этими проблемами — рассмотрим ниже. Все равно, доля успешных проектов — в разы больше.
Из личного опыта. Как таки вывести SEO-проект к цели с минимальными потерями
Мы выработали следующие рекомендации для заказчиков (тут я не буду говорить про SEO-уловки, все равно оптимизаторы смогут рассказать про них лучше, а коснусь только организационных моментов):
- Выбирая компанию для поискового продвижения, запросите коммерческое предложение и у разработчика. Работа с ним сэкономит вам определенную сумму на правках. Учитывайте это, сравнивая цены в предложениях. И это сэкономит всем кучу нервов.
- Если заказать SEO там же где и разработку невозможно, и у заказчика нет сил залезать в конфликт по уши и менеджерить обе команды — лучше связать их напрямую, пусть сами договариваются.
- Перед началом работ — выясните, есть ли у руководителя проекта по продвижению опыт управления проектами по разработке сайтов (или хотя бы просто опыт в web-программировании). Идеально, если у него также будет компетенция по юзабилити. Это защитит вас от пунктов ТЗ, которые невозможно или очень дорого делать, или которые ухудшат юзабилити сайта.
- При составлении технического задания на поисковую оптимизацию приоритет всегда должен быть за юзабилити. Если правка делает сайт менее удобным — она не нужна. Тем более, сейчас поисковые системы придают большой вес поведенческим факторам (позиции упадут, если пользователи будут очень быстро уходить с вашего сайта).
- Требуйте от SEO очень подробное, понятное и конкретное техническое задание. Оно должно быть понятно не только разработчику, но и заказчику. Там не должно быть обобщающих местоимений: все, каждый, любой и т.д. Только в этом случае отсутствие результата оптимизаторы не смогут списать потом на некорректное или неполное выполнение требований технического задания.
- Требуйте от разработчика оценки по каждому пункту техзадания, а не общей оценки на ТЗ. Во-первых, так сразу можно выявить неожиданно дорогие правки, а во-вторых, при изменении требований вам будет проще обсуждать новую сумму.
- Обсуждайте те пункты, где бюджет на правки вас беспокоит, не только с разработчиками, но и с SEO. Возможно, без этой правки можно обойтись или сделать по-другому. Если стоимость (трудоемкость) внесения правки на сайт больше, чем ожидаемая отдача от этой правки, значит ее делать точно не надо.
- Успешность проекта заказчик в первую очередь оценивает не по формальным признакам, а по количеству и качеству заявок. Поэтому оптимизатору необходимо думать сначала о конверсии, потом — о позициях. Если сайт устарел, там не хватает информации, и тексты писал кто-то
под травкойслишком креативный — надо исправлять! Совет заказчикам: опросите своих потенциальных клиентов, нравится ли им ваш сайт и удобно ли им пользоваться. Если негативные отзывы будут повторяться — повод задуматься и срочно это переделать. - Ну и еще момент. Когда заказчик жалуется на падение конверсии — оптимизаторы не должны пропускать это мимо ушей. Совет заказчикам: если вам кажется, что заявок стало приходить меньше (и это на самом деле так после подсчета), не стесняйтесь требовать от оптимизаторов анализа проблемы. Проект должен быть протестирован полностью, все метрики должны быть проанализированы. Обычно в таких случаях можно выловить неожиданные вещи, не относящиеся к SEO, но способные провалить проект. Например, заявки были, но не доходили на почту или вдруг все заказы стали падать в спам. Или проблема в смене новинок на сайте, потому что у них плохие фотографии. Короче, варианты бесконечны.
- Используйте альтернативные каналы привлечение трафика. Заказчикам психологически тяжело ждать эффекта от SEO, который, как известно, становится немножко заметным через полгода. Чтоб не казалось, что деньги берутся за воздух — параллельно стоит привлекать трафик через контекстную рекламу.
- Никогда, то есть совсем-совсем никогда, не заказывайте тексты у SEO-копирайтеров. Ни к себе на сайт, ни как статьи на внешние сайты, где покупаются ссылки. Если товар не копеечный, покупатель будет искать информацию о продавце через поисковики, по названию компании. И эти копирайтерские «тексты» окажутся в выдаче. Покупатель их прочитает, увидит неадекватность и с большой долей вероятности откажется от сделки.
- Помните, что PR-отдел окупается. Но только при условии, что копирайтеры не внештатные, а в офисе на полный день и уже разбираются в теме. Например, у нас в штате два копирайтера-pr-менеджера, которые 90% своего времени пишут на нас. Еще пишет статьи генеральный директор и иногда руководители проектов.
Конечно, подружить кошку с собакой можно. Если соблюдать эти правила — можно успешно провести проект, даже если стороны просто будут соблюдать вооруженный нейтралитет. Терпения всем участникам!
Автор: Sibirix