Роли и ответственность, чтобы SEO не превращалось в бесконечные “рекомендации в стол”.
SEO ломается не на “ключевых словах”. SEO ломается на фразе: “Мы вам рекомендации отправили”.
И всё. Дальше рекомендации лежат в столе, сайт не меняется, поисковик не видит прогресса, а вы платите за процесс без результата.
Поэтому вопрос “кто внедряет правки” — это не организационная мелочь. Это половина успеха. Давайте разложу роли и ответственность так, чтобы SEO не превращалось в бесконечный сериал “в следующей серии мы точно внедрим”.
1) Какие правки вообще бывают (и почему тут нельзя “ну как-нибудь”)
Для SEO почти всегда нужны изменения трёх типов:
- Технические правки
скорость, редиректы, индексация, дубли, микроразметка, шаблоны, фильтры, пагинация (особенно в магазинах). - Контент и структура
новые посадочные страницы, тексты на услуги/категории, FAQ, обновление старых материалов, перелинковка. - Коммерческие и конверсионные элементы
первый экран, оффер, цены/условия, формы, доверие (отзывы/кейсы), удобство мобильной версии.
И вот тут ключевой момент: SEO-подрядчик может всё это придумать идеально. Но без внедрения это остаётся красивым документом.
2) Три модели внедрения: кто делает и чем это заканчивается
Модель A: Внедряет подрядчик (или подрядчик + свой разработчик)
Когда хорошо:
- вы хотите “под ключ” и не хотите быть диспетчером задач;
- у вас нет сильного внутреннего разработчика;
- сайт на CMS, где подрядчик умеет работать (и имеет доступы).
Плюсы:
- быстрее цикл “нашли → сделали → проверили”;
- меньше потерянных задач;
- ответственность более цельная: меньше “это не мы, это они”.
Риски:
- доступы и безопасность (нужны процессы, права, бэкапы);
- подрядчик может “делать как умеет”, а вам важно “как принято в вашей архитектуре”.
Как должно быть оформлено:
- список типов правок, которые подрядчик делает сам;
- регламент: где создаются задачи, кто принимает, как откатываем;
- сроки реакции по критичным багам.
Модель B: Внедряет ваш разработчик (а SEO-подрядчик даёт ТЗ и контроль)
Когда хорошо:
- у вас есть разработчик/IT-отдел и вы хотите держать код у себя;
- проект сложный (интеграции, кастомные модули), и внешний подрядчик туда лучше не пускать.
Плюсы:
- контроль качества, единые стандарты разработки;
- меньше рисков по доступам;
- правки можно делать “правильно”, а не “быстро и кое-как”.
Риски:
- разработчик всегда занят “более важным”;
- SEO превращается в “мы отправили рекомендации”, потому что внедрения не приоритет.
Как не сломать SEO в этой модели:
- SEO-подрядчик обязан давать ТЗ в формате, удобном разработчику (с примерами, приоритетами, критериями готовности);
- у вас должен быть выделенный слот разработки под SEO (хотя бы несколько часов в неделю);
- обязательно — контроль внедрений со стороны SEO (проверка после релиза).
Модель C: Внедряете вы сами (или ваш контент-менеджер)
Когда работает:
- простые CMS (где можно менять тексты, мета-теги, добавлять страницы, перелинковку);
- вы хотите экономить и готовы руками делать часть задач;
- правки в основном контентные, без тяжёлой технички.
Плюсы:
- скорость: “увидела → сделала”;
- дешевле по деньгам;
- вы лучше чувствуете продукт и язык клиентов.
Минусы:
- можно нечаянно поломать структуру/шаблоны/URL;
- часто не хватает дисциплины и времени;
- сложные технические задачи всё равно упрутся в разработку.
Как безопасно:
- заранее определить, что вы трогаете, а что — нет;
- иметь резервные копии и доступ к специалисту на подстраховку;
- работать по чек-листам и не “улучшать всё сразу”.
3) Кто за что отвечает: чтобы не было “мы думали, это не наша зона”
Вот нормальное распределение ответственности, которое я бы хотела видеть в любом проекте:
SEO-подрядчик отвечает за:
- аудит и приоритеты (что делать сначала, что потом);
- стратегию страниц “под спрос”;
- ТЗ на внедрения (понятное и проверяемое);
- контроль качества: внедрено или “сделали вид”;
- аналитику и выводы (что сработало/что нет/что дальше).
Разработчик отвечает за:
- техническую реализацию правок;
- корректность работы сайта после внедрений;
- скорость/стабильность/безопасность.
Собственник/менеджер со стороны клиента отвечает за:
- принятие решений по спорным вопросам (цены, оффер, регионы, приоритет услуг);
- выделение ресурса на внедрения (время разработчика/контентщика);
- согласование материалов в срок (иначе SEO стоит).
Если это не проговорено в начале — проект почти гарантированно уедет в “рекомендации в стол”.
4) Как организовать процесс, чтобы SEO двигалось
Вот рабочая схема без лишних церемоний:
- Единая доска задач (Trello/Jira/Битрикс/что угодно)
Не “в переписке”, а списком: задача → приоритет → дедлайн → ответственный. - Спринт на 2 недели
SEO даёт список задач на 2 недели, вы подтверждаете приоритет, разработчик делает. - Критерии готовности
Например: “страница отдаёт 200, редирект работает, в индексе нет дубля” — чтобы не было “ну мы вроде сделали”. - Контроль после релиза
SEO проверяет, что внедрение реально работает, а не “сломало половину сайта”. - Еженедельный короткий созвон 15 минут
Только статус: что сделано, что блокирует, что в следующей очереди. Без философии.
5) Как понять, что вы в зоне риска “рекомендаций в стол”
Тревожные признаки:
- нет единого списка задач и приоритетов;
- подрядчик присылает файлы, а не управляет внедрением;
- разработчик не понимает, зачем это делать;
- внедрения реже, чем раз в 2–3 недели;
- отчёты выглядят как “мы работали над улучшениями”.
Что выбрать в реальности
Если у вас есть хороший разработчик и вы хотите контроль — модель B обычно лучшая.
Если разработчика нет/он перегружен — выгоднее и быстрее модель A (подрядчик внедряет сам).
Если проект простой и вам важна скорость — можно часть задач закрывать моделью C (вы/контентщик), а техничку — отдавать разработчику.
Главное — не кто именно делает, а чтобы было: ответственный, срок, контроль, факт внедрения.
Если хотите, напишите, на чём у вас сайт (CMS), есть ли свой разработчик и как сейчас устроены согласования. Я предложу оптимальную схему “кто делает что”, чтобы SEO не стояло на месте из-за организационных мелочей.