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-специалисту, и разработчику.