Кейс: потеря краулингового бюджета на собственной системе аналитики

Кейс: потеря краулингового бюджета на собственной системе аналитики

#кейс_из_жизни @productseo - под данным тегом буду публиковать интересные, по моему мнению, случаи из своей практики аудитов. Все кейсы будут анонимизированы без возможности “опознать” сайт, но с полным перечнем данных, которые будут нужны для понимания проблемы и решения.

Дано

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

Многие сайты такого размера не могут поместить все данные в Google Analytics из-за ограничений бесплатной версии (ссылка) и им не выгодно покупать GA 360, а потому они идут зачастую двумя путями:

1. разбивают свой сайт на разные GA Property;

2. работают над своей системой аналитики.

В этом кейсе ребята решили пойти по пути 2) и взяли стандартную идею пикселей для создания своей внутренней аналитики.

Техническая составляющая

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

1. Для клиентов, которые могут выполнить JS;

2. no js через “картинку” (<img src=“domain .com/pixel?get=”) с get параметрами.

Если мы говорим о части <script>, то ее можно вынести в отдельный файл и закрыть от GoogleBot любым способом (хотя бы от сканирования через robots.txt) или же надеятся на то, что Google поймет, что это аналитика: “Googlebot and its Web Rendering Service (WRS) component continuously analyze and identify resources that don’t contribute to essential page content and may not fetch such resources. For example, reporting and error requests that don’t contribute to essential page content, and other similar types of requests are unused or unnecessary to extract essential page content.” (cсылка). Вот только до сих пор их алгоритм не точен, а потому советую не надется на него и закрывать самим.

Остается вторая часть с “картинкой” и тут Google разгулялся. Для него это была просто картинка и он постоянно ее запрашивал через GoogleBot Image. В данном кейсе повезло, что внутренняя статистика не всегда меняла get запросы, а потому к концу месяца суммарные затраты краулингового бюджета в пустую равнялись бюджету одного дня (и это только одна проблема аналитики). Поскольку система аналитики была на том же домене, то решили проблему через запись в robots.txt Disallow: /pixel?get= . Если бы такие внутренние ресурсы хранились на субдомене или отдельном домене, то можно было бы закрывать через Disallow:/ . Напоминаю, что для каждого субдомена нужно делать свой robots.txt

Вывод: важно смотреть в логи 🤗

P.S. Несколько лет назад у меня был похожий кейс и в ЛУН Поиске (теперь flatfy.ua), когда аналитиками к каждой ссылке на объявления (карточки) о продаже квартир были добавлены custom параметры, условно говоря, stats_position=. Они записывали с какой позиции был клик на карточку и на тот момент совпали звезды, что реализация этого параметра не попала ни под одну маску из robots.txt 😂 Одним словом, я проснулся и увидел +2млн страниц в индексе.

Источник новости https://t.me/productseo/10...