SEO-шник vs программер: как руководителю разрешить конфликт и прирастить трафик | SEO кейсы: социалки, реклама, инструкция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ежели в компании есть таск-трекер, добавьте отдельный статус «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 экране.

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

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

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

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

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

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

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

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

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

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

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

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

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

На второстепенные задачки необходимо много времени

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

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

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

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

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

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

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