Checkout и корзина генерируют URL с session-id, UTM и шагами оформления — часть из них лезет в индекс как отдельные страницы. Noindex, disallow и canonical здесь не взаимозаменяемы: спутал один с другим — либо слил crawl budget на мусор, либо закрыл от Google страницу, которая нужна была живой. Ниже — что чем закрывать, и история про сорок тысяч дублей корзины, из-за которых Googlebot месяц игнорировал новые карточки товара.
Открой Google Search Console → «Страницы» → «Просканировано, не проиндексировано» и отфильтруй по /cart/, /checkout/, /basket/. Если там пусто — либо у тебя толковый robots.txt, либо ты туда никогда не смотрел. Из магазинов, которые я разбирал за последний год, пустым этот фильтр не был почти ни у кого.
Почему checkout вообще попадает в индекс
Никто специально не добавляет страницу оформления заказа в sitemap. Она залезает в индекс сама, и причины почти всегда одни и те же.
Кнопка «В корзину» без AJAX-перехвата добавляет параметр в URL и перезагружает страницу — получается новый адрес на каждый клик. Ссылки из email-рассылок тащат UTM-метки в корзину и чекаут, и каждая комбинация utm_campaign превращается в отдельный «уникальный» URL с точки зрения Googlebot. Промежуточные шаги оформления (выбор доставки, оплаты) при обрыве сессии остаются доступными по прямой ссылке и их индексирует, если на них случайно есть внутренняя ссылка. А на фронтендах с клиентским рендерингом без нормального контроля маршрутов всё это дополнительно плодится само.
Три инструмента, которые путают друг с другом
Noindex. Страница доступна, Googlebot её сканирует, но в индекс не кладёт. Годится для страниц, которые должны существовать и работать (например, подтверждение заказа — туда возвращается покупатель, туда ведут письма), но не имеют смысла в поиске.
Disallow в robots.txt. Страницу вообще не сканируют. Жёстче noindex — применяй только там, где сканирование само по себе не нужно и есть риск утечки чувствительных параметров (токены сессии, order_id в открытом виде).
Canonical. Для дублей с одинаковым контентом, но разными параметрами — sort, utm, affiliate-метка внутри самого checkout-флоу. Указывает Google, какая версия основная.
Путают их чаще всего так: ставят noindex туда, где нужен disallow (и Google продолжает тратить бюджет на сканирование мусора, просто не кладёт его в индекс), или ставят disallow туда, где нужен noindex — и тогда страница подтверждения заказа, на которую должен приходить трафик из писем, может повести себя странно в отчётах, потому что Google её вообще не видит.
Что конкретно закрывать
| Тип страницы | Что делать | Почему |
|---|---|---|
| /cart/ — пустая или с товарами | noindex, follow | нет уникального контента для поиска, но переходы внутри сайта терять не нужно |
| /checkout/step-2, step-3 (шаги оформления) | disallow в robots.txt | часто содержит персональные данные в параметрах, сканировать вообще не нужно |
| /order-confirmation/?order_id=XXXX | noindex + X-Robots-Tag | каждый заказ — уникальный URL, по сути бесконечное количество «страниц» |
| /cart/?utm_source=...&utm_campaign=... | canonical на чистый /cart/ | дубль контента, параметр нужен только аналитике, не индексу |
| /compare/, /wishlist/ (если публичные) | noindex, если страница не агрегирует уникальный контент | зависит от того, есть ли там что-то, кроме списка товаров без текста |
Это не «правильные» настройки на все случаи — это стартовая точка. На конкретном сайте разница в архитектуре URL может всё сдвинуть.
Своя ошибка: сорок тысяч дублей корзины
Разбирал интернет-магазин мебели — crawl stats в GSC стабильно показывали высокое число запросов Googlebot в день, а органический трафик стоял на месте уже третий месяц. Руками, не Screaming Frog, а по реальным access-логам сервера нашёл: треть обращений бота — это /cart/?added=1&utm_campaign=..., с десятками комбинаций параметров на один и тот же пустой экран корзины.
Кнопка «В корзину» в письмах рассылки вела прямо на страницу с добавлением товара через GET-параметр, без перехвата через AJAX. Каждое письмо — новая комбинация utm, каждая комбинация — новый «уникальный» URL для бота. За два года таких адресов накопилось больше сорока тысяч.
Поставили disallow по паттерну /cart/?*utm_* и canonical на чистый /cart/ для остальных вариантов. Через три недели crawl stats пришли в норму, и Googlebot наконец начал регулярно доходить до новых карточек товара — до этого на них банально не хватало бюджета сканирования, весь уходил на мусор.
Чеклист перед аудитом checkout-флоу
- Проверь, добавляет ли кнопка «В корзину» параметр в URL или работает через AJAX без смены адреса.
- Посмотри в GSC «Просканировано, не проиндексировано» — отфильтруй по /cart/, /checkout/, /order/.
- Убедись, что страница подтверждения заказа не кэшируется по общему URL и не отдаёт 200 для всех подряд.
- В robots.txt закрывай конкретные паттерны с токенами и order_id, а не весь раздел целиком — можно случайно закрыть страницу со статусом заказа по трек-номеру, которая реально нужна.
- Сверь canonical на страницах с UTM- и sort-параметрами внутри checkout — часто там его просто нет вообще.
Ты вообще смотрел, сколько URL с /cart/, /checkout/ или /order/ висит в твоём GSC-покрытии, или эта часть отчёта у тебя в вечном игноре, потому что «туда же никто не заходит из поиска»?
Checkout — не витрина, это инфраструктура. Чем меньше шума индексации вокруг него, тем больше бюджета сканирования достаётся страницам, которые реально продают.
Если не уверен, что твой checkout не генерирует десятки тысяч мусорных URL — смотри логи сервера, не только GSC. GSC показывает агрегаты с задержкой в несколько дней, логи — всё и сразу. Нужна помощь с разбором — пиши на mostlycorp@gmail.com.