Опять эти правки! Учимся общаться с разработчиками и добиваться внедрения правок

Привет! Это Илья Русаков, CEO impulse.guru. За годы практики заметил, что взаимодействие с ребятами-seoшниками не всегда проходит гладко. Сегодня разберёмся в нуждах и потребностях команд, посмотрим на примеры их «противостояния», и попутно я буду рассказывать, как облегчить взаимодействие между разработкой и SEO. Что за противостояния, о чём вообще речь?

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

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

Вот что улучшают на сайте:

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

Бесполезные правки — это какие? Например, появилось новое ТЗ: «пропишите ALT к картинкам». Картинок на сайте тысяча, делать это нужно вручную. SEO-специалисты не задумались о ценности внедрения и о том, сколько ресурсов уйдёт на задачу. Итог: разработка не взяла задачу в работу.

Иногда дисконнект двух команд наносит урон компании. Пример из практики: разработка клиента обновила дизайн сайта, но нарушила структуру мета-тегов. Первые четыре месяца до этого был виден прогресс, а вот на пятом месяце, когда выкатили новый сайт, клиент потерял миллион рублей — обрушился трафик из поиска.

Из-за метания правками друг в друга компания потеряла деньги. Sеошники не объяснили, разработчики не захотели брать в работу.

А если бы SEO-команда поступила по-другому?

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

Обычно нужно несколько этапов — у всех по-разному. На схеме пример крупного проекта, с которым я сотрудничал. У них процесс внедрения правок разбит на 10 шагов.

SEO-результаты на 80% зависят от того, как команда разработки справится с внедрением рекомендаций. Но не все seoшники об этом помнят.

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

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

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

Практически в любой компании разработчики загружены на полгода вперёд. И они уверены, что их работа — самая важная. 😀 Поэтому когда кто-то врывается и кладёт на стол стостраничный отчёт со словами: «всё плохо, ничего не работает, исправляйте», разработка злится. Задача отправляется в ящик с такими же задачами, и вернутся к ней примерно никогда.

Чтобы правку взяли в работу, а не забивали на неё, нужно составлять прогноз. Уточнять, к чему приведёт, сколько денег и трафика принесёт. Когда разработчик видит прогноз, он начинает понимать её важность = охотнее берёт в работу.

Прогноз можно составить по воронке или спрогнозировать трафик по существующему спросу в Вордстате. Лучше это сделать до вложений.

А чтобы вообще порадовать разработчика, можно сделать матрицу приоритетов. Советую начать с критериев оценки. У каждого они могут быть свои.

Особенности критериев:

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

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

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

Любое действие нужно оцифровывать, чтобы:

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

Не будьте наивными, что наличие ТЗ — уже ценность и что все поймут, зачем нужны правки. Будьте предупредительны, заботливы, и будет вам счастье.