Одна из самых частых проблем (именно проблем, а не задач), с которой к нам приходят, звучит примерно так: «У нас трафик просел. Посмотрите, пожалуйста, что не так». О том, что обычно бывает «не так», мы сейчас и расскажем. Но ключевое слово тут не «бывает», а «обычно». Но не забывайте, что «обычно» - это далеко НЕ всегда.

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

1. «Не сезон»

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

Второй пример «не сезона» - отопительное оборудование. В частных домах отапливать начинают примерно с сентября-октября. И вот тут Вы, конечно же, догадались, что это и есть самый «жаркий» сезон с точки зрения продаж. И если Вы догадались именно так, то… То Вы догадались неправильно. Сентябрь-октябрь – это время, к началу которого система отопления уже должна быть полностью готова к запуску. А самый «жаркий» сезон – это июль-август. Т.е. если магазин торгует исключительно отопительным оборудованием, то резкая просадка трафика в сентябре-октябре (в зависимости от региона) – это очень даже норма.

2. Robots.txt (наш кейс)

Стопэ, не закрываем.

Разумеется, большинство из Вас уже подумало, что мы будем говорить про директивы, про «случайно закрыли весь сайт от индексирования» и т.д. И вот тут «палка о двух концах». С одной стороны – да, потому что проблемы с robots.txt бывают достаточно часто. А с другой - нет, ибо у нас есть кейс поинтереснее.

В нашей практике был случай, когда индексированию сайта в ПС Google мешал robots.txt, который, на первый взгляд, составлен правильно, а мешала индексированию, как ни странно, UTF BOM. Как мы это выяснили? А вот как.

Постучался к нам заказчик со словами «упал органический трафик, посмотрите, пожалуйста». Первым делом сканируем сайт Screaming Frog’ом с настройкой «respect robots.txt», а также предварительно выставив смартфонный гугл бот, и сравниваем количество просканированных страниц с количеством проиндексированных Google’ом (Почему не Яндексом? Потому что сайт казахский) и результаты таковы – в индексе Google проиндексированных страниц не было вообще.

Смотрим robots.txt и видим, что с ним проблем на первый взгляд нету. Чтобы не тратить зря рабочее время, запросили у заказчика информацию о том, что в последнее время делали с сайтом + заодно повторно запросили доступы в Search Console. Оказалось, что вносились изменения в robots.txt. И несмотря на то, что robots.txt вроде бы как живой и здоровый, решили его перепроверить. Идём в Search Console и проверяем – таки-ругается Консоль на роботс.

Т.е. Фрог под видом гугл бота сканирует нормально, сам роботс тоже составлен вроде как корректно, но Консоль на него один фиг ругается. Не состыковочка, однако. Но раз Консоль ругается именно на Роботс – в его сторону и копаем.

Проверяем Роботс штатным инструментом Консоли и видим, что ВСЕ 26 СТРОК ПОМЕЧЕНЫ КАК ОШИБОЧНЫЕ.

Эй! Какого йода?!

А проблема оказалась, как ни странно, в самой первой строке – там какой-то непечатаемый символ, который Google не понимает.

Удаляем этот символ и ошибки пропали со ВСЕХ строк.

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

На возражение заказчика «так они же одинаковые» мы тут же ответили «нет, не одинаковые – смотрите на размер».

Разница всего в 3 байта – 554 у того, что было, и 551 у того, что сейчас. После замены robots.txt страницы начали возвращаться в поисковую выдачу.

Кстати, а вот и те самые 3 байта, которые были удалены из файла. И увидеть их нам удалось только в HEX-редакторе. Ни в Блокноте, ни в Notepad++ эти символы не отображались.

Вот так вот всего 3 байта, содержимое которых еще и хрен увидишь, выбили из поисковой выдачи ВЕСЬ САЙТ.

Оказывается, robots.txt нужно проверять куда тщательнее, чем многие думают!

3. Массовое изменение УРЛ

Чаще всего данная проблема наблюдается при переезде на новую CMS, при изменении структуры каталога, либо при переходе на ЧПУ (Человеко-понятные УРЛы). Коротко рассмотрим все 3 варианта.

Переезд на другую CMS

При переезде на другую CMS УРЛ могут изменить свою структуру адреса. Например:

было – https://site.xyz/demontazh-sten-uznat-czeny-i-rasschitat-stoimost-demontazhnyh-rabot-na-sajte-ooo-treshaut-sankt-peterburg/

стало – https://site.xyz/services/demontazh-sten/demontazh-sten-uznat-czeny-i-rasschitat-stoimost-demontazhnyh-rabot-na-sajte-ooo-treshaut-sankt-peterburg/

То, что выделено красным, уже добавила сама CMS. А если конкретнее – данные изменения в УРЛ появились при переносе сайта с WordPress’а на 1С Битрикс.

Изменение структуры каталога

В предыдущем примере мы рассмотрели пример, когда УРЛ изменился, но сохранилась структура каталога. Здесь обратная ситуация – CMS одна и та же, но зато изменилась структура каталога.

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

Ниже приведен как раз такой пример – батарейки в разделе «Оборудование для розлива воды».

В этом случае при переносе карточки из раздела в раздел УРЛ тоже меняется:

было - http://site.xyz/catalog/oborudovanie_dlya_rozliva_vody_/pompy_i_aksessuary_/element_pitaniya_d/

стало - http://site.xyz/catalog/elementy_pitaniya/batteryes/element_pitaniya_d/

Переход на ЧПУ

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

было - http://site.xyz/catalog?id=1548522

стало - http://site.xyz/catalog/elementy_pitaniya/batteryes/element_pitaniya_d/

Решение

Решение тут вполне очевидное:

все изменения вносим на тестовом домене, а именно – настраиваем переадресацию с кодом ответа 301 со старых УРЛов на новые, но без учета домена;
сканируем основной домен с помощью Screaming Frog’а, включаем отображение только HTML-документов;
копируем список полученных УРЛов и меняем в нем основной домен на тестовый;
загружаем обновленный список в Screaming Frog и сканируем с целью выявления битых ссылок.

Если битых ссылок нет и везде код ответа 301 – значит все сделано правильно. Ну а если 404 – надо дорабатывать сайт.

Последствия

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

Ну а если допустить кучу ошибок (например, настроить только часть редиректов, или настроить все редиректы, но неправильно) – упомянутого выше времени потребуется еще больше.

4. Невозможность проиндексировать УРЛ

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

Настройка редиректов со старых адресов на новые - это лишь «одно из», ибо этого может оказаться недостаточно. Крайне важно, чтоб еще и сама перелинковка была настроена корректно, т.е. в коде сайта должны быть правильные УРЛы, чтобы при клике по ссылкам код ответа был 200, а не 301, 302 и т.д.

Такие поправки необходимо вносить еще на стадии, когда обновленный сайт находится на тестовом домене.

ВАЖНО!!!

Очень многие допускают ошибку, настраивая 301 редирект с «битого» адреса на правильный. Такое решение, конечно, допустимо, но крайне нежелательно. Гораздо правильнее заменить «битый» адрес непосредственно в документе-источнике. Чем меньше будет редиректов внутри сайта – тем лучше, причем как для пользователей, так и для социальных сетей.

5. Невозможно просканировать документ

Здесь всё просто – для поисковых роботов и для пользователей страница должна отрисовываться одинаково, ибо отработка скриптов JavaScript нередко влияет на отображение контента. Последствия – поисковый робот может отрисовать страницу неправильно => поисковик увидит страницу тоже неправильно.

Проверить «одинаковость» отрисовки предельно просто:

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

Если изменилось – значит проблема как раз в том, что поисковый робот не в состоянии отрисовать страницу правильно – ему мешают скрипты JavaScript.

6. Были внесены изменения в шапку или меню

И в данном случае вопрос даже не в корректности ссылок в шапке или в меню, а в их… НАЛИЧИИ. Например, часть ссылок (или того хуже – ВСЕ ссылки) могут слететь просто потому, что Вы поменяли шаблон оформления сайта.

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

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

7. Теги, категории, фильтры и т.п.

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

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

Но как убедиться, что проблема именно в этом? Очень просто.

1) Заходим в Яндекс.Метрику => Стандартные отчеты => Содержание => Популярное.

2) Указываем временной интервал. Длина – произвольная, 3-5 дней для крупных сайтов может быть достаточно. Для мелких сайтов лучше указать хотя бы недели 2-3 или даже месяц. Сам же период должен начинаться и заканчиваться ДО того, как начались просадки.

3) Под графиком раскрываем чек-бокс и экспортируем в ёксель список УРЛов, выбираем из них наиболее посещаемые. Иногда в УРЛах будет отсутствовать домен – в этих случаях его будет необходимо добавлять вручную (либо через Ctrl+H с использованием символа ^, либо в том же ёкселе через формулу =сцепить).

4) Проверяем коды ответа. УРЛов с кодом ответа 404 быть не должно. Если есть – значит перенесено не все – упущены те самые теги, быстрые фильтры и т.д. и их надо восстанавливать в гипер-экстренном порядке. Коды переадресации (301, 302 и т.д.) допустимы, но крайне нежелательны. При их наличии необходимо вручную проверить, насколько корректно настроена переадресация. На нашей практике не было еще ни одного случая (разумеется, в рамках данного пункта), когда все УРЛы с кодами ответа 301 / 302 и т.д. были настроены корректно.

8. Поведенческие факторы

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

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

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

9. Кривая адаптивная верстка

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

налезать друг на друга, мешая восприятию контента;
менять зону «клика» (т.е. кликаем на один элемент, а срабатывает другой);
вылезать краями за пределы видимой области;
полностью вылезать за пределы видимой области;

и т.д.

Ничего из вышеперечисленного выше быть не должно.

10. Смешанное содержимое (http + https)

Формально работа по http допускается. Более того, до сих пор http-сайты можно найти в ТОПе (хоть и редко). Тем не менее, мы настоятельно рекомендуем переводить сайты на https, даже если они не коммерческие. И ни в коем случае не допускается, чтобы одни элементы сайта были доступны по http (например, картинки), а другие – по https (например, код сайта). К слову, именно подобная «комбинация» и называется «смешанным содержимым».

Исключение (причем условное) из этого правила, пожалуй, составляет только robots.txt и sitemap.xml, поскольку это просто текстовые файлы, т.е. их нельзя загрузить частично по http и частично по https. Однако, крайне желательно, чтобы они были доступны как по http, так и по https, причем без каких-либо редиректов.

Иных исключений из этого правила нет и быть не может.