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

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

Каждый раз, когда SEO-спец дает техническое задание, возникает риск, что разработчик поймет его неправильно. Это как игра в "испорченный телефон": одно неверное слово – и результат совсем не тот. В итоге, вместо улучшения сайта, вы получаете дополнительные трудности и потери времени. А ведь время =деньги.

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

Разница в понимании задач

SEO-специалисты и разработчики часто говорят на разных языках. Сеошник говорит нужно сделать статичные страницы фильтрации. А у разработчика кипит мозг, ведь страницы фильтрации не могут быть статичными. Или сгенерируйте sitemap.xml – рекомендует seo-специалист. Разработчик настроит генерацию, но с кучей ошибок. Без понимания цели задачи ее результат будет сомнителен и не тот, который ожидается.

Отсутствие прямой коммуникации

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

Технические ограничения

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

Приоритеты и ресурсы

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

Неверное понимание задач

Часто разработчики не понимают, что именно требуется от них. Например, задача "устранить дубли страниц" может быть воспринята по-разному. Один разработчик удалит страницы с 404 ответом сервера. Другой – настроит 301 редиректы. Оба могут ошибаться. Может быть оптимальным решением было настроить canonical.

Несоблюдение сроков

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

Технические ошибки при внедрении

Ошибки в коде – обычное дело. Например, неправильное внедрение скриптов может привести к снижению скорости сайта. Или ошибка в коде может сделать сайт недоступным для поисковых систем.

Неактуальные ТЗ и противоречивые рекомендации

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

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

“Боль - старые неактуализированные ТЗ. Случалось, что в работу приходит старое ТЗ. Начинаешь смотреть - а половина уже не актуальна. Чтобы не путать разработчиков и не травмировать, было бы здорово древние ТЗшки, которые наконец согласованы, передавать seo-спецам на перепроверку и актуализацию.”

Александр Муценек, программист группы разработки RACURS

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

Александр Алексенко, руководитель группы разработки RACURS

“Не тратьте в ТЗ время на глубокую детализацию в формате, какой скрипт куда вставить и как сжимать изображения. Это не нужно и только отнимает лишнее время на изучение”

Александр Алексенко, руководитель группы разработки RACURS

“Мне очень не нравится когда тз имеет внутренние перелинковки с каким то другим тз. Например в пункте N какого-то тз есть ссылка на другое тз, в котором в пункте M описано что надо сделать с пунктом N).”

Олег Денисов, ведущий программист группы разработки RACURS

“Бывает так, что сео-спецы прикладывают список проблемных страниц из валидатора/лягушки/ещё откуда-нибудь, но не всегда проверяют его на адекватность и актуальность. Понятное дело, все страницы проверять вручную нет нужды. Но точечно проверить на 2-3 url, что проблема действительно есть, и это не ошибка парсера или данные по какой-нибудь древней закешированной странице. Еще хорошо бы сразу знать хотя бы примерное кол-во страниц с ошибками, потому что от этого будет зависеть оценка трудозатрат на старте.”

Александр Муценек, программист группы разработки RACURS

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

“Довольно трудно воспринимать информацию когда в тз явно не обозначены заголовки пунктов. Имею ввиду чисто визуальное выделение. Также порой пункты бывают пронумерованы, но бывает, что, например, есть два пункта с номером 10. Такие тз потом сложно обсуждать, т.к. непонятно про какой конкретно 10-ый пункт идет речь). Иногда пункты вообще не пронумерованы”

Олег Денисов, ведущий программист группы разработки RACURS

Постановка четких задач

Формулируйте задачи так, чтобы их понял любой. Например, вместо "устранить дубли страниц" пишите "настроить 301 редирект на страницу". Это исключит недоразумения и упростит работу.

Пункты ко внедрению должны быть конкретными и однозначными. Если seo-специалист пишет о том, что на страницах обнаружена ошибка в title, то следует привести список таких страниц или четко обозначить тип этих url (например, ошибка обнаружена во всех карточках товаров).

Если сеошник дает рекомендацию «оптимизировать alt и title изображений», то следует указать, что именно и для каких изображений следует прописать.

Если рекомендация подразумевает альтернативное решение, то можно прописать вариативность, но указать, как из вариантов в приоритете.

Формат ТЗ должен подразумевать два шага от разработчика

1. Бери

2. Делай

Приоритизация пунктов ТЗ

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

Регулярные встречи и обсуждения

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

Обучение команды

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

Встречное обучение должно быть и для seo-специалистов от разработчиков.

Постоянное сопровождение

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

Проверка и аудит выполненных задач

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

Совет: договоритесь о том, в каком формате вы отдаете правки на доработку в случае внедрения объемного ТЗ. Уважайте время ваших коллег и свое.

“Если ТЗ большое и в нем после проверки сео-специалист оставляет комментарии в файле на полях, это очень не удобно. Лучше, если после проверки будет прикладываться новый файл с оставшимися правками.”

Варвара Новченкова, ведущий программист группы разработки RACURS

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

P.S. Уважаемые программисты, поделитесь, чем вас раздражают “сеошные” ТЗ и какие советы вы можете дать, чтобы этого избежать?