5 неочевидных ошибок разработки, критичных для SEO

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

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

SEO — не наше дело, мы пилим функционал

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

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

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

Топ-5 ошибок разработки, которые могут убить все позиции сайта клиента

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

Ошибка № 1. Неверный перенос на другой домен

Клиент надумал «переехать», а в результате расстался с позициями. Что могло случиться:

  1. Купленный домен оказался с «сюрпризом» и раньше был под санкциями. Поисковики все ему припомнили и снизили выдачу.
  2. На новый адрес ведут некачественные ссылки с внешних источников, которые загубили оптимизацию.
  3. Домен слишком молодой, пока ему не положено быть даже в первой десятке выдачи.

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

Примечание. При смене домена позиции просядут так или иначе. Обычно на 10–30%. Но если вы заметили катастрофический спад, проблема была более глобальной.

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

Правильный перенос информации тоже имеет значение. Нужно прописать все редиректы, указать переезд в инструментах вебмастеров, перенести все SEO-элементы (метатеги, разметки и прочее). А еще лучше — проконсультироваться с оптимизатором до смены домена, чтобы не браться за голову после.

Наш опыт: к нам пришел клиент, который работает в автомобильной отрасли. Проблема — провалился трафик после переноса сайта. Причина оказалась в том, что разработчики не настроили правильные редиректы.

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

Ошибка № 2. Обновление сайта с заменой старых урлов на новые

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

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

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

Мы сделали следующее: создали структуру на основе фильтров, сохранив при этом старые урлы страниц, провели полную техническую оптимизацию, выполнили наращивание внешних ссылок. Так как клиент настоял на раннем переносе на основной домен, трафик немного просел. Но зато сайты не склеились, и потери оказались минимальными.

Ошибка № 3. Неверная реализация мультиязычности

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

Какие ошибки можно допустить в ходе создания мультиязычности сайта:

  • прямой перевод взамен локализации контента — материал не будет адаптирован под национальные, поведенческие и законодательные особенности страны. А это приведет к неверному восприятию информации;
  • отсутствие региональных нюансов языка — взять ту же разницу американского английского и британского английского. Или просто переведите автоматически с русского на английский слово «Статьи» (в нашем случае название раздела сайта). Articles? Американцы так не говорят. У них раздел называется Blog. Вот и ошибка;
  • адаптация только основного контента на сайте — кому нужны эти заголовки, подразделы и остальное? Нужны! Если делать перевод и адаптировать страницу, необходимо охватить весь материал;
  • перевод ключей для SEO — тоже плохо. Снова решает специфика использования слов, языковые нюансы. Дословный перевод — сомнительная идея. Нужно собирать ключи заново на другом языке.

Хорошо настроенная мультиязычность обеспечит правильную индексацию на каждом языке. А это уже в плюс общей цели продвижения.

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

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

Ошибка № 4. Проблемы в Geo разных версий сайта

Это тоже имеет связь с мультиязычностью. Точнее — с ошибками реализации hreflang и даже его отсутствием.

Немного теории. Атрибут hreflang показывает поисковой системе, что у сайта присутствует одинаковый контент на нескольких языках. Допустим, есть житель Испании, страница ресурса в выдаче на английском, а также испанском. Нужно сделать так, чтобы Google показывал испанцу страницу на родном языке. Для этого и существует hreflang.

Самые распространенные ошибки:

  • атрибут отсутствует полностью;
  • нет урл-адреса, ссылающегося на себя;
  • атрибута нет в заголовке;
  • hreflang не указывает на конкретную страницу;
  • неверно задан код страны.

Да, много топовых сайтов существует и вовсе без этого атрибута. Однако его отсутствие или ошибки реализации могут еще как повлиять на позиции. Зачем рисковать? Лучше все проставить сразу и спать спокойно.

Наш опыт: однажды мы имели дело с продвижением туристического сайта на зарубежные рынки. Логично, что вопросы с мультиязычностью и ГЕО были очень и очень важны. Тем более физически компания находилась в Украине, а основная аудитория — за рубежом.

После технического аудита мы обнаружили неверную реализацию мультиязычности. Нужно было показать поисковой системе, что каждая языковая версия ресурса разделяется в зависимости от региона. Для этого мы реализовали hreflang и добавили региональные подпапки. Тем самым сумели разделить ГЕО и добиться релевантной выдачи для каждого региона, интересующего клиента.

И немного для наглядности:

Ошибка № 5. Игнорирование адаптивности и скорости загрузки сайта

Это даже проблема № 1. Порой при разработке дизайна все силы уходят на десктоп, а адаптивная версия «и так сойдет». Но так нельзя, ведь поисковики дают низкие позиции в мобильной выдаче плохо адаптированным сайтам. В результате клиент теряет львиную долю пользователей мобильных устройств. Вот почему важно отдельно разработать дизайн мобильной версии, оптимизировать сайт под разные устройства и ОС, чтобы все на ресурсе отображалось корректно.

Еще одна боль — скорость загрузки. Если пользователь ждет дольше 3 секунд, пока страница откроется, он уйдет. Отсюда неприятности для SEO. Необходимо всеми доступными способами повысить скорость загрузки: убрать ненужные элементы, оптимизировать картинки и остальное. А если есть потребность в сложных элементах дизайна, больших объемах контента, нужно просто выбрать подходящий движок.

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

Разработка и поисковая оптимизация плечом к плечу

Создавая сайты, любой разработчик стремится учесть все моменты. Но у него есть свой фронт задач, которые порой совсем не учитывают потребности SEO. Как не создать проблемы для сайта клиента? Ответ — работать плечом к плечу с поисковым оптимизатором. Необязательно на каждом этапе создания сайта. Есть отдельные моменты (как вышеупомянутые), которые имеют прямое отношение к SEO. Даже если в штате нет оптимизатора, всегда можно обратиться к подрядчику или посоветовать клиенту сделать это. Подобный подход упрощает жизнь всем: и владельцу сайта, и SEO-специалисту, и разработчику.

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ещё +1 колоссальная ошибка, в частности начинающих seo-специалистов, это невнимательность, и не налаженность контроля за сайтом. Был такой случай у меня, моим сайтом занималась команда специалистов на фрилансе, тогда не особо были средства для обращения в серьезные рекламные агентства, и вот со временем, эти ребята разошлись, и стали работать кто на себя отдельно, кто на компанию, а над сайтом работы было всё меньше. Соответственно, так как seo нельзя забрасывать, временно нанял сеошника, чтоб занимался размещением статей. Всё бы ничего, если бы не возникли вопросы с отсутствием трафика на новых страницах, и заметного проседания общего трафика. В итоге, этот парниша так и не разобрался в чём дело. На тот момент, знал о компании web-promo.ua/seo , и об их именитых проектах Укрсиббанк, Новая Почта, и прочих. Решил обратится к ним, и проблема сайта оказалась в том, что специалист просто закрыл сайт от индексации в robots.txt. В итоге, подписал я договор с ребятами из webpromo, и уже 2-й год как сотрудничаем.

временно нанял сеошника
В итоге, этот парниша так и не разобрался в чём дело.
проблема сайта оказалась в том, что специалист просто закрыл сайт от индексации в robots.txt.

Нічосє сеошник

Крауд лінк?)
Яке посилання на Ваш сайт?
Це ця ТОВ? clarity-project.info/edr/21017192
Вказані інші особи як директори
Ваш відгук і кейс є в них на сайті?

В мене до вас такі два питання, буду радий вашій думці.

1). Як кролити сайти з lazy load за допомогою Screaming Frog? Зараз зіштовхнувся з тим, що не весь сайт прокролився. Sitemap багнутий, вся надія конкретно в моєму випадку тільки на внутрішню перелінковку і виявилося що SF не прокролив товарні сторінки, які підгружалися за допомогою lazy load.

2). Як ви диверсифікуєте сторінки для пошуку під різні локації але з однією мовою? Для наглядності приклад CA, UK, AU, US. Але конкретно в моєму випадку зіштовхнувся із сайтом, де для більшості країн локалізація англійською і сторінки відрізняються лише валютою та згадкою країни в meta title. hreflang, canonicals — з цим все в порядку. Ситуція така: із січня почалася міграція трафіку між локалями. Так, британський трафік перемістився на інші країни. Тобто в інших країнах почали з’являтися результати з британськими посадочними сторінками і ловити трафік там, втрачаючи його на локалі вказаній в hreflang. В Search Console бот повідомив що він вирішив визначити canonical tag не заявлений в коді, а той який сам вирішив. Як зробити так щоб Гугл правильно реагував на hreflang та canonical без опції перекладу сторінок?

Було б цікаво почути вашу думку з цих питань. Дякую!

І ще одне цікаве питання, пов’язане з SEO. Як ви вирішуєте проблему з індексацією контенту, якщо контент генерується динамічно, в браузері, а не поставляється статично сервером?
Так працюють багато SPA-додаткiв, наприклад, на Angular.

Клоакинг

Тут вже жартують на тему клоакінгу. Грубо кажучи в цьому щось є. Є спеціальні рішення, які роблять пререндер спеціально для пошукових роботів. Вони фільтрують запити від пошукових систем та повертають їм статичний HTML. Звичайним користувачам йде додаток для рендеру в браузері, а пошуковам системам вже «розжований» (відрендерений) HTML для їх індексу. Схема виглядає приблизно так. Ось вам почитати ще на цю тему. Загалом шукайте prerender solutions for SEO. Також можете встановити ModHeader та потестувати як це працює на практиці змінюючи запити.

роблять пререндер спеціально для пошукових роботів. Вони фільтрують запити від пошукових систем та повертають їм статичний HTML.

Це ж клоакінг в чистій формі. вроді же заборонений гуглом. Гугол час від часу заходить з під звичайного юзерагента і трекає це...

Ну ща модно SSR юзать. В целом гуглобот исполняет JS и индексирует страницы сгенеренные на клиенте, но это не так надежно как SSR.

У Angular є Angular Universal для SSR, але це не так просто реалізувати для не-Node проекту.

Вот почему важно отдельно разработать дизайн мобильной версии, оптимизировать сайт под разные устройства и ОС, чтобы все на ресурсе отображалось корректно.

Було б цікавіше більш конкретно почути про «різні пристрої і ОС». Для яких пристроїв і ОС ви тестируете свої сайти?

Создавая сайты, любой разработчик стремится учесть все моменты.

Знову ж таки, як ви радите робити? Щоб розробник займався SEO або окремий SEO-спеціаліст? Який підхід ви використовуєте в своїх проектах?

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

Що означає відкриється? Якщо ви маєте на увазі, що браузер отримає перші дані від сервера через 3 секунди, то це дійсно повільно. Або ви маєте на увазі, що сторінка закінчиться рендерится через 3 секунди.

У нас на проектах всегда работает команда и девы и сеошники, есть требования с точки зрения seo (которые прописываются в ТЗ проекта). Плюс на тесте все проверяется сеошником, чтоб без сюрпризов.

Якщо ви маєте на увазі, що браузер отримає перші дані від сервера через 3 секунди, то це дійсно повільно.

Именно так. В таких случаях у сайта будут оч плохие позиции, пусть даже супер контент на нем.

Для яких пристроїв і ОС ви тестируете свої сайти?

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

5 неочевидных ошибок разработки, критичных для SEO

Трохи неточна назва статті, виходячи з опису. Швидше це помилки роботи SEO-фахівця або того, хто відповідає за розгортання додатку, але не розробника.

Это о ситуациях, когда клиент не привлекает seo специалистов при доработках\переносах и тд.

Самая наипервейшая ошибка — когда сайт закрыт от индексации посредством robots.txt или тега robots в коде страницы из-за того что девелопер не понимал что это такое. А потом удивляются и спрашивают — а вы не могли бы посмотреть, почему это у нас сайта не видно в гугле.

Это даже не обсуждается)))

Еще одна боль — скорость загрузки. Если пользователь ждет дольше 3 секунд, пока страница откроется, он уйдет.

громкое заявления)

Ошибка 1 — А с чего это разработчик должен проверять что за новый домен купили? Его дело только перенести.

Вот это и есть боль темы: должен и хорошо бы для клиента — разные вещи.

Ну, для клиента может хорошо чтобы ещё и полы дома помыли. Нужно же разделять работу, кто и что должен.

У домена была своя история до меня? Я бы и не подумал о таком! Спасибо за статью!

Спасибо что зарегил новую учётку, чтобы сказать себе «спасибо». SEOшники такие SEOшники

Конечно) И еще одну — лайкнуть свой коммент))

Не понял что произошло, но очень интересно)))

Стати процесом? о_О

Обновление сайта с заменой старых урлов на новые

А якщо старі урли будуть на нові 302 то це ок для сео чи всеодно просяде?

Просядет, но не так сильно. Лучше конечно урлы сохранить

Не ок. 301 (постоянный) нужно, а не 302 (временный).

Підписатись на коментарі