Як помирити програміста і SEO- шника, щоб збільшити пошуковий трафік. Інструкція для керівника

Як помирити програміста і SEO- шника, щоб збільшити пошуковий трафік. Інструкція для керівника

Приходить якось клієнт до оптимізатора, щоб просунути сайт недорого без ризиків і з гарантіями. Оптимізатор проводить аудит і віддає клієнтському програмістові доопрацювання, які треба впровадити. А програміст говорить:

- Я це робити не буду.

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

- Де мій трафік? Чому не виросли продажі?


А оптимізатор на це:

- А звідки трафік, якщо ви не впровадили рекомендації? У програміста запитаєте.

Врешті-решт клієнт втрачає гроші, а оптимізатор - клієнта. Усі розходяться розчарованими.

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

У статті ми орієнтуємося на компанії без відлагоджених процесів розробки, продукт- і проджект-менеджеров, відділів тестування. Загалом, поговоримо про "ризиковану модель розробки".

seo vs programmer

Програміст вніс неузгоджену зміну на сайт

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

Формально оптимізатор прав. Можна скільки завгодно лаяти програмістів, але на практиці це не захистить від подібних помилок в майбутньому. Краще розв'язати проблему системно:

  1. Попросити програмістів попереджати оптимізатора про зміни на сайті. Нехай ці зміни на перший погляд ніяк не пов'язані з 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

Розставляння пріоритетів SEO- завдань

Може виявитися, що другорядне завдання коштує занадто дорого і її взагалі не варто робити.

Саммари для ледачих

Три ради, як діяти у стані війни між програмістом або SEO- шником:

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

І та пребудет з вами експонента пошукового трафіку.