Возможные ошибки при продвижении. Глава из новой книги

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

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

Книга появится в продаже до конца года. 

Социальные сети и путь клиента

Рано или поздно приходит время обновить сайт. Это может произойти, если дизайн сайта морально устарел и перестал соответствовать современным требованиям, стал слабо отражать суть бренда или возникла необходимость изменить концепцию представления бизнеса в Интернете и так далее.

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

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

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

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

Представим себе, что корпоративный сайт или магазин был создан 3—4 года назад и прожил это время в старом дизайне, а затем компания решила обновить сайт.

Разработчик — не важно, будет ли это штатный сотрудник или компания-подрядчик — с вероятностью 99,9% заявит о необходимости сменить систему управления сайтом (content management system или CMS).

Как мы уже говорили, CMS — это «движок сайта», система для создания, управления и показа посетителям содержимого сайта. Иными словами, это ядро сайта, состоящее из набора скриптов, интерфейса административной панели, базы данных и т.д. Поэтому, рекомендуя изменить CMS, разработчик может быть в принципе прав, поскольку старый движок сайта может уже не соответствовать современным требованиям веб-разработки и не позволит реализовать все те изменения, которые запланированы в ходе обновления сайта.

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

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

Давайте чуть подробнее остановимся на этих рисках.

Изменение структуры сайта

В ходе редизайна часто происходит изменение структуры сайта. Само по себе изменение структуры не опасно. Другое дело, если меняется логика каталога товаров или главного меню сайта. В этом случае для ряда страниц меняется уровень вложенности — число кликов от главной страницы, за которое посетитель (и поисковый робот) может достичь страницы.

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

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

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

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

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

В этот период можно наблюдать колебания позиций. Эти колебания будут сильно зависеть от того, как сильно меняется структура сайта в ходе его обновления.

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

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

Изменение адресации страниц

Эта проблема куда серьёзнее предыдущей. Сохранить структуру сайта приблизительно в том же виде — важно, но вызываемой сменой структуры «турбулентностью» можно и пренебречь.

Куда важнее не допустить кардинального изменения адресации страниц сайта.

Под адресацией мы понимаем URL страниц сайта, например: http://site.ru/path/folder1/page

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

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

Для наглядности разберём пример.

Допустим, раздел «Новости» был ранее внутри раздела «Компания» и имел адресацию:

http://site.ru/o-kompanii/novosti

В новой версии сайта после редизайна «Новости» выносятся в головное меню в один ряд с разделом «Компания». Меняется положение страницы в структуре сайта и адрес меняется на http://site.ru/novosti.

Было: http://site.ru/o-kompanii/novosti
Стало: http://site.ru/novosti

То есть, в новой версии сайта страница «Новости» вошла в основное меню. Она изменила свое положение в структуре и одновременно с этим изменила адресацию.

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

А пока это происходит, все старые страницы удаляются из индекса, а значит — снижаются позиции сайта в результатах поиска и теряются посетители/клиенты.

Пример типичного редизайна:


Внешний вид сайта mkb.ru до редизайна



Внешний вид сайта mkb.ru после редизайна

Однако не спешите откладывать редизайн сайта. С проблемой смены адресации можно справиться путём настройки перенаправления со старого адреса на новый адрес — то есть с помощью редиректов.

Редиректы

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

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

Такое перенаправление не только позволяет указать новый адрес страницы для поисковой системы, оно говорит «теперь все то же самое находится здесь». Поисковая система буквально склеивает два этих адреса, считая их одним. Это позволяет сохранить, или, как было бы правильнее сказать, передать вес (важность) от старой страницы к новой.

Примерно то же самое происходит с позициями и трафиком по запросам. Старая страница уступает место новому адресу в результатах поиска.

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

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

Здесь следует придерживаться лишь одного принципа: каждая старая страница, которая в новой версии сайта изменила свой адрес, должна содержать редирект с кодом 301 на новый адрес.

Для рассматриваемого выше примера страница по старому адресу http://site.ru/o-kompanii/novosti должна содержать перенаправление с кодом 301 на адрес http://site.ru/novosti.

То есть, если страница http://site.ru/path/folder1/page изменила адрес на http://site.ru/page, то при заходе на старый адрес http://site.ru/path/folder1/page пользователь (и поисковый робот) должен автоматически оказаться на новом адресе страницы http://site.ru/page.

Наличие настроенного 301 редиректа необходимо проверить после завершения «переезда» сайта на новую версию.

Проверить это можно вручную, например, с помощью сервиса «Проверка ответа сервера» в Яндекс.Вебмастере или с помощью массовой проверки, например, в программе Screaming Frog SEO Spider Tool & Website Crawler.

Можно также использовать онлайн-сервисы, которые позволяют проверить быстро и бесплатно несколько адресов, например Проверка ответов сервера.

Стоит учитывать, что сменой адреса страница следует считать даже малейшее изменение в URL. Например, если все страницы сайта были с завершающим слешем «/» на конце (напр., http://site.ru/o-kompanii/novosti/) а после редизайна стали иметь адреса без «/» (напр., http://site.ru/o-kompanii/novosti) это уже повод настроить 301 редирект.

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

В качестве примера можем привести наш корпоративный сайт «Ашманов и партнеры». Ранее у нас была разработана программа SiteAuditor, информация о ней размещалась на странице http://www.ashmanov.com/services/siteauditor, но со временем поддержка программы была прекращена, проект закрыт. 

При смене дизайна было принято решение удалить данную страницу из структуры сайта, а пользователей со старого адреса страницы перенаправлять на наиболее подходящий по смыслу раздел — https://www.ashmanov.com/tech-i-services/ в котором находятся другие наши сервисы, помогающие решать смежные задачи.

Таблица соответствия адресов 

Перед запуском («выкаткой») нового сайта, когда у вас уже есть доступ к новой версии на тестовом домене, а на основном домене ещё работает текущая версия сайта, необходимо составить таблицу соответствия адресов страниц текущей версии сайта и страниц в новой структуре. Например, это может выглядеть следующим образом:

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

Использование JS и AJAX в новом дизайне

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

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

Самой частой ошибкой является использование в новой версии сайта элементов на скриптовых языках Java Script и/или AJAX или, что ещё хуже, реализации на этих скриптах всего контента обновлённого сайта.

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

Но не о том, как это все будет реализовано технически, на каком движке, с какой технологией и методами вывода контента. Заказчик обычно не разбирается в этих вопросах и предполагает, что уж технически-то всё будет сделано «как следует».

Обычно это приводит к проблемам с поисковым продвижением, общей видимостью нового сайта, потоком потенциальных клиентов.

Дело в том, что JS / AJAX — это техника публикации контента, которая поисковыми системами воспринимается очень плохо. Скрипты выводят информацию со страницы сайта в браузер пользователя, так что пользователь (в том числе заказчик сайта) её прекрасно видит, а поисковый робот может и не увидеть ее. 

Если содержимое страницы выводится исключительно скриптами Java Script или AJAX, поисковые роботы в некоторых случаях посчитают страницу пустой!

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

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

В конце данной главы приводятся ссылки на рекомендации по данному вопросу для вебмастеров от самих поисковых систем.

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

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

Проверить наличие скриптов Java Script или AJAX можно на этапе разработки сайта самостоятельно. Когда разработчик новой версии сайта завершит разработку и предоставит доступ к тестовой версии сайта:

1. Откройте страницу в браузере;
2. Выберите в разных частях страницы несколько уникальных словосочетаний в 2-3 слова, например, заголовок, словосочетания или слова из контентной части страницы, запомните или выпишите их;
3. Откройте исходный код страницы в браузере (комбинация клавиш Ctrl+U в большинстве браузеров или соответствующий пункт меню браузера, наподобие «Дополнителььные инструменты/Код страницы»);
4. Поищите в коде выбранные слова и словосочетания (для поиска используйте стандартную комбинацию клавиш Ctrl+F);
5. Повторите поиск для всех типов страниц сайта (главной, страницы головного меню, страницы рубрики каталога, карточки товара и т.д.)
6. Если в коде страницы не удаётся найти словосочетания, которые вы видите в браузере при просмотре страницы, значит, этот текст, скорее всего, генерируется на лету, то есть выводится с помощью скриптов и будет не виден поисковым системам.

Слишком позднее оповещение о редизайне

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

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

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

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

Смена домена 

Несмотря на то, что смену домена можно считать частным случаем смены адресов страниц, её стоит рассмотреть отдельно. 

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

С технической точки зрения делается это ещё проще, чем с редиректами отдельных страниц сайта. Достаточно разместить несколько строк в служебном файле .htaccess, который есть на всех веб-серверах под управлением .nix систем (основанных на UNIX): 

RewriteCond %{REQUEST_URI} (.*) RewriteRule ^(.*)$ http://novyj-site.ru/$1 [L,R=301] 

Если новый домен использует протокол HTTPS, то последняя строчка должна содержать протокол HTTPS при указании нового домена. 

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

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

Главное, от чего нам хотелось бы предостеречь — это совмещать редизайн сайта и смену структуры или адресов сайта со сменой домена (или протокола). 

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

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

Смена протокола 

C 2017 года Интернет живет в условиях «переезда на защищенный протокол HTTPS». Поисковые системы выступают за необходимость размещения сайтов на протоколе https://, если на странице есть функционал личного кабинета, оплаты или любых других форм ввода чувствительных личных или платёжных данных. Это обеспечивает сохранность и безопасность личной информации пользователей вашего сайта. 

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

Во избежание потери позиций и видимости следует настроить 301 редирект со всех страниц на протоколе http:// на соответствующие им страницы на протоколе https://.

Смена подрядчика по SEO 

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

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

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

Логины и пароли для доступа. Если не вы сами регистрировали сайт в таких сервисах от поисковых систем, как Яндекс.Вебмастер, Google Search Console и Кабинет вебмастер Mail.ru, то запросите доступы к ним. Получив доступ, необходимо сменить пароли и убедиться, что никаким лишним аккаунтам не разрешен доступ для просмотра и не делегированы права на редактирование информации. Сделать это можно в настройках аккаунта данных сервисов. В случае, если регистрацию проводили вы и подрядчику предоставляли лишь просмотр данных вашего аккаунта, то лучше всего удалить такую возможность. 

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

То же самое касается и установленных систем аналитики — Яндекс.Метрики или Google Analytics.

Доступ к аккаунтам ссылочных бирж. Если подрядчик по поисковому продвижению проводил работы по расстановке ссылок в соответствующих биржах или сервисах (например., miralinks.ru, sape.ru, linkbuilder.su и др.) следует попросить либо предоставить доступы к этим аккаунтам, если они создавались специально для вашего проекта, либо зарегистрировать самостоятельно свои аккаунты в соответствующих биржах и сервисах, и совместно с бывшим подрядчиком провести перенос проектов с аккаунта их агентства на ваш собственный аккаунт через поддержку сервиса.
Данные о закупленных и проставленных ранее ссылках и контроль за ними (возможность снять их, например) — крайне важны и помогут избежать возможных неприятностей в будущем.

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

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

Выводы

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

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

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

Полезные ссылки

Справочная информация от поисковых систем по индексированию сайтов, использующих JS и AJAX:

• Индексирование AJAX-сайтов — инструкция Яндекса по решению проблемы индексации сайтов, которые используют JS и AJAX для вывода контента на страницах.
• Сайты, использующие AJAX — справочная информация по индексированию сайтов на AJAX от Google.

Примеры программ и сервисов, которые проверят наличие редиректов по списку адресов страниц:

• Screaming Frog SEO Spider Tool & Website Crawler — программа-парсер сайта, в функционале которой есть возможность проверить коды ответов сервера по указанному списку адресов страниц.
• Проверка ответов сервера — веб-сервис, показывающий ответы сервера по списку адресов.
• Проверка ответа сервера — сервис от поисковой системы Яндекс, позволяющий проверять ответы адресов страниц поштучно.

Кабинеты вебмастеров от поисковых систем, доступы к которым необходимо иметь и контролировать:

• Яндекс.Вебмастер.
• Google Search Console.
• Кабинет вебмастера Mail.ru.

Информация от Яндекса для вебмастеров по процедуре переезда сайта с протокола http на https.

Главу подготовил Александр Козориз, Head of SEO, «МедиаНация».