Каталог на 100 000+ SKU: что ломает индексацию 1С-Битрикс

На каталоге 100 000+ SKU индексация ломает витрину, когда фоновые задачи и живой трафик делят одну базу: поиск, фасетный индекс, карта сайта, обмен с 1С и обход робота. Среднее время страницы за сутки при этом может выглядеть приемлемым. Падает конкретное окно, в котором всё стартует сразу, или ответ роботу, который открывает тысячи URL.

Это не то же самое, что «медленный умный фильтр» или «раздел открывается долго вечером». Фильтр разбирается отдельно: умный фильтр тормозит. Общая диагностика страницы — в «Тормозит каталог». Здесь — пересечение индексации, SEO и фона.

Что здесь называют индексацией

Слово путают три процесса, и чинить нужно тот, который реально идёт.

1. Поисковый индекс сайта — внутренний поиск Битрикс или внешний. Полный обход каталога читает свойства, цены, доступность.
2. Фасетный индекс умного фильтра — пересчёт, какие значения свойств доступны в разделе.
3. Индексация поисковиком — робот Яндекса или Google обходит URL из sitemap и ссылок. Ему нужны быстрые 200 без таймаута, стабильные каноникалы, актуальные товары.

На большом каталоге они усиливают друг друга: обмен обновил 50 000 остатков, фасеты и поиск пошли перестраиваться, в это же время робот выкачивает карту сайта. Покупатель и бот получают высокий TTFB. После окна «всё само проходит» — пока не совпадёт снова.

Почему порог около 100 тысяч SKU

На 5–10 тысячах позиций полный пересчёт часто незаметен. На 100 тысячах и выше полный проход по свойствам, ценам и URL уже минуты и часы, не секунды. Если этот проход случайно попадает в пользовательский хит или в час пик обмена, каталог «падает» без ошибки в PHP.

Не обязательно иметь миллион товаров. Достаточно большого числа SKU, свойств в фильтре и частых полных, а не инкрементальных, пересчётов.

На каталоге Geometria было 800 000 SKU. Ключевые страницы занимали около 8 секунд, параллельно тяжёлые запросы, кеш и индексация мешали друг другу. После поэтапной диагностики SQL, компонентов и фона ключевые страницы вышли примерно на 1,6 секунды, критичных срывов индексации после стабилизации не было. Это результат того проекта, не норма «ускорим любой каталог в пять раз».

Что обычно ломается в фоне

• Полная переиндексация поиска по расписанию «на всякий случай каждую ночь», хотя за день изменилась доля каталога.
• Пересчёт фасетов на хите, если индекс помечен неактуальным после импорта.
• Генерация sitemap одним запросом без порций: таймаут, 500, робот получает обрыв.
• Обмен 1С, поиск и бэкап в одном окне: диск и база заняты, PHP-FPM в очереди.
• Агент, который должен брать пачку, на деле обходит весь инфоблок на одном запуске.

Симптом снаружи: ночью или утром после обмена сайт «тупит», в Вебмастере растут ошибки обхода, в Метрике — просадка скорости разделов. Днём без фона всё приемлемо.

Робот — отдельный пользователь с худшим кешем

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

Проверьте:

• отдаёт ли sitemap только канонические 200, без фильтров-дублей и служебных параметров;
• не генерируются ли тысячи URL умного фильтра для обхода;
• не блокирует ли robots.txt нужное и не открывает ли бесконечные комбинации;
• совпадает ли время активного обхода с переиндексацией и обменом.

Цель — не «закрыть сайт от Яндекса», а не кормить робота взрывной комбинаторикой фильтра и не заставлять его ждать 8 секунд на карточке.

Как развести фон и витрину

Рабочая политика на большом каталоге:

1. Обмен пишет изменения пакетами, не обязательно полный каталог каждый цикл.
2. Поиск и фасеты догоняют изменения инкрементально, полный проход — редко и в известное окно.
3. Окно обмена, переиндексации и бэкапа не складывают в один час без необходимости.
4. Тяжёлые агенты не выполняются на пользовательском хите.
5. Кеш популярных разделов не сбрасывается целиком после обновления одного остатка.

Сначала график: когда деградирует TTFB, какие cron и агенты в это время, растёт ли I/O и число запросов к базе. Без графика любая «оптимизация индекса» — гадание.

Не увеличивайте железо вместо разнесения задач, пока не измерено, что упирается CPU, а не полный скан на каждом хите. И наоборот: если диск в 100% во время бэкапа, правки компонента каталога не помогут в это окно.

Связь с SEO, не только со скоростью

Срыв индексации для бизнеса — это не абстрактный «индекс Битрикс». Это выпавшие или долго обходящиеся карточки, устаревшие цены в сниппете, разделы, которые робот бросает по таймауту. На Geometria отдельно фиксировали, что после стабилизации не было критичных срывов обхода. Имеет смысл так же смотреть Вебмастер: код ответа, время загрузки, исключённые URL.

Если параллельно на витрине неверные цена и остаток, сначала расхождение с 1С. Индексация будет честно закреплять в поиске то, что сайт отдаёт.

Безопасный порядок

Замерить ключевые URL в спокойное окно и в окно обмена/переиндексации. Снять список агентов и cron. Выключить или сдвинуть полный пересчёт на копии и сравнить. Убедиться, что робот и покупатель не ждут один и тот же тяжёлый запрос. Менять код выборки и кеш — после того, как фон перестал наступать на витрину.

Формат такой работы — на странице ускорения каталога. Кейс с цифрами — Geometria.

Итог

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