Как помирить программиста и SEO-шника, чтобы увеличить поисковый трафик. Инструкция для руководителя

Роман Прохоров

Сооснователь интернет-агентства Digital Strategy

– Я это делать не буду.

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

– Где мой трафик? Почему не выросли продажи?

А оптимизатор на это:

– А откуда трафик, если вы не внедрили рекомендации? У программиста спросите.

В конце концов клиент теряет деньги, а оптимизатор – клиента. Все расходятся разочарованными.

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

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

Программист внес несогласованное изменение на сайт

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

Формально оптимизатор прав. Можно сколько угодно ругать программистов, но на практике это не защитит от подобных ошибок в будущем. Лучше решить проблему системно:

1. Попросить программистов предупреждать оптимизатора об изменениях на сайте. Пусть эти изменения на первый взгляд никак не связаны с SEO. Для оптимизатора запустить эмулятор поискового робота и просмотреть результаты – это дело десяти минут.

Какие SEO-параметры нужно проверять на сайте каждый день.

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

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

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

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

Как изменить процесс:

1. Программист сообщает оптимизатору, когда новый функционал будет готов. Оптимизатор заранее резервирует время под тестирование новой версии. Чтобы настроить процесс, рекомендую чаще спрашивать программиста: «А ты предупредил SEO-шника?» или «С оптимизатором согласовано?».
2. После выкладки сайта на тестовый сервер оптимизатор начинает тестирование, через день (этот день нужно заложить в плане релизов!) оптимизатор возвращается с результатами SEO-тестирования.
3. После того как тестовая версия согласована, программист выкладывает функционал в продакшн. Оптимизатор в это время запускает повторное тестирование уже на рабочем сервере.
4. Запретить делать релизы в пятницу на уровне компании. Тому кто сделает… Чувствую себя Капитаном Очевидность, но такие ситуации до сих пор встречаются ¯\_(ツ)_/¯

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

Если в компании есть таск-трекер, добавьте отдельный статус «SEO-тестирование», чтобы нельзя было отправить сайт в продакшн без прохождения этого этапа. Иначе придется постоянно напоминать программисту, что нужно согласовывать изменения с SEO-шником.

Программист увидел новую интересную технологию и хочет внедрить ее на сайт

Программист ссылается на пресс-релиз Google, в котором поисковик сообщает о поддержке новой технологии. Мы работаем в России, для нас важен не только Google, но и Яндекс (а иногда даже Mail), поэтому любое техническое решение нужно проверять.

Раньше холивары вызывали SPA-сайты и «escaped_fragment», которые на первом витке развития плохо ранжировались в Яндексе. Сейчас с SPA все нормально, но аналогичная ситуация сложилась, например, с Lazy Loading Images and Video. Что делать руководителю:

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

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

Программист учит оптимизатора оптимизировать

Программист отказывается делать какую-то задачу и мотивирует это тем, что у кого-то из крупных сайтов сделано по-другому. Обычно это звучит так: «Да ну вот смотрите же, у них тоже есть битые ссылки, и ничего, нормально ранжируются». Чаще всего в качестве референсов предлагают условный Яндекс.Маркет, которому вообще не нужно думать о SEO, чтобы находиться в ТОПе Яндекса. Оптимизатор говорит «надо», программист говорит «не буду». Что делать:

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

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

Программист не понимает, что от него хочет оптимизатор

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

В общем случае в ТЗ оптимизатора должны быть:

1. Примерный прототип страницы, пусть даже на коленке в Paint или на салфетке или примеры подобного функционала на других сайтах.
2. Точные значения всех важных для SEO HTML-тегов (title, h1, ссылки...) и кодов ответа сервера. Описание того, как проверить корректность реализации.
3. Описание возможных изменений страницы после выкладки. Например, нужна ли оптимизатору какая-то админка для управления параметрами страницы.

Описание того, как хранить тексты в базе данных, макет страницы в формате PSD или рекомендации по правильной настройке CDN – это все явно выходит за рамки ответственности SEO-шника.

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

Программист говорит, что реализовать функционал невозможно

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

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

1. Оптимизатор предоставляет примеры реализации функционала на максимально похожих сайтах. Возможно, программист не очень хорошо понимает, что от него нужно.
2. Оптимизатор совместно с программистом ищут альтернативные варианты: как решить ту же задачу, но другим функционалом. Например, вместо создания полноценной админки можно реализовать импорт-экспорт CSV-файлов.
3. Возможно, лучше привлечь внешнего технического консультанта, если нет уверенности в экспертизе программиста.
4. Если решения нет, нужно ставить вопрос ребром: делать рефакторинг сайта или смириться с тем, что поисковый трафик будет расти медленнее чем ожидалось.

В SEO есть два подхода к постановке задач программистам:

• формирование приоритетных задач с подготовкой новых по мере внедрения;
• описание задач в процессе комплексного аудита сайта.

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

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

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

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

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

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

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

На второстепенные задачи нужно много времени

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

В этом случае мы советуем сделать таблицу с приоритетами и рассчитать стоимость каждой задаче. Вот таблица для примера:

Может оказаться, что второстепенная задача стоит слишком дорого и ее вообще не стоит делать.

Саммари для ленивых

Три совета, как действовать в состоянии войны между программистом или SEO-шником:

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

И да пребудет с вами экспонента поискового трафика.