Бюджет сканирования Google 2026: как ускорить индексацию интернет‑магазина на OpenCart

Google обновил документацию по бюджету сканирования в 2026-м: что изменилось на самом деле и почему ваш OpenCart‑магазин индексируется медленно

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

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

Все что описано в этой статье, применимо и для Яндекс.

Старт для всех один

Каждый новый сайт получает консервативный лимит сканирования. Одинаковый для всех. Не штраф. Просто гуглбот не хочет уронить ваш сервер на старте. Это объясняет, почему свежий магазин на 30 тысяч товаров индексируется неделями, а владелец психует. Месяц назад запускал проект на OpenCart 4 — каталог автозапчастей, полмиллиона позиций. В первые три недели индекс еле полз. Клиент слал ссылки на статьи про «санкции». Захожу в GSC, статистика сканирования — среднее время ответа 800 мс. Многовато. Лезу в slow log MySQL: запросы к oc_product_to_category с парой JOIN и сортировкой по sort_order висят по секунде. Индекса на category_id нет. Добавил. Время ответа упало до 200 мс. Через три дня гуглбот поднял темп. Без повторной отправки sitemap.

Нет смысла дёргать sitemap, пока сервер не научился отвечать быстро. Бюджет сканирования — это не количество URL, которые Google готов обойти. Это лимит одновременных запросов и времени, которое бот готов ждать. Медленный ответ — сигнал «сервер устал», и бот снижает нагрузку. В OpenCart проблема часто глубже, чем кажется: штатный код выборки товаров в категории (catalog/model/catalog/product.php) тянет подзапросы к oc_product_attribute и oc_product_to_store без форсирования индексов. На версиях до 3.0.3.8 это вообще боль. Лечится добавлением индексов и, при очень большом каталоге, кешированием результатов в Redis (вечно падающий Memcached я давно не использую).

Одна труба для всех ботов

Из обновлённой документации следует, что Googlebot-Image, Googlebot-Text, AdsBot и StoreBot делят один пул запросов. Не разные очереди с независимыми лимитами. Одна труба. И если вы запустили товарную рекламу через Merchant Center, Shopping crawler начинает активно обходить фиды. Одновременно картинки товаров — неоптимизированные, в исходном разрешении — жрут пропускную способность у Googlebot-Image. И вот в эту же трубу пытается протиснуться основной бот за новыми страницами каталога. Места нет. Вспоминаю магазин сантехники: подключили ремаркетинг, пошли лиды, всё хорошо. Но через пару недель новые товары стали индексироваться не за 6 часов, а за трое суток. В GSC разбивка по типам ботов — Googlebot-Image делает вдвое больше запросов, чем текстовик. Картинки отдавались в исходном размере, по 2-3 МБ каждая, серверный nginx ресайзил на лету, жрал CPU. После внедрения сжатия в WebP и ленивой загрузки ситуация выровнялась. Ни одного изменения в контенте — только работа с ресурсами.

Почему ваш sitemap врёт

Google снимает слепок содержимого и сравнивает с предыдущим. Нет изменений — перепроверяет реже. В видео с Alexis Sanders (оно прицеплено к официальной документации) сказано: вы можете помочь через Last-Modified, ETag и lastmod в sitemap. Но если lastmod обновляется каждый день, а контент стоит, Google перестаёт верить этому сигналу. Для всего сайта. OpenCart с этим справляется отвратительно. Стандартный генератор sitemap (модуль extension/feed/google_sitemap) ставит lastmod равным текущей дате при каждом вызове. Все 50 тысяч товаров якобы «обновились сегодня». Google заходит, видит ту же страницу, тратит бюджет и запоминает: в sitemap этого магазина lastmod — фейк. Потом перестаёт обращать на него внимание. Когда товар действительно меняется (цена, наличие), бот может прийти не скоро. Я всегда переписываю логику sitemap: lastmod обновляется только при реальном изменении полей в oc_product.date_modified или при ручной правке. Для статичных страниц (контакты, политика) ставлю фиксированную дату раз в год.

Код 304 — отдельная песня. Если страница не изменилась, сервер должен отвечать «304 Not Modified». Google получает лёгкий ответ, закрывает URL и идёт дальше. Экономит ресурсы. В стандартной поставке OpenCart поддержки ETag нет. Я добавил её на уровне nginx: etag on; if_modified_since before; плюс правильная настройка кеширования статики. Буквально в несколько строк. На магазине с 70 тысячами SKU доля ответов 304 в логах Googlebot выросла до 30%, а темп индексации новых страниц ускорился — бот меньше перепроверял каталог, который не менялся месяцами.

Дубли — вот где бюджет

Если у вас меньше миллиона страниц, документация говорит прямо: проблема не в бюджете, а в раздувании адресного пространства. OpenCart здесь — чемпион. Штатный фильтр добавляет параметры ?filter=, ?sort=, ?limit=. Модули вроде OCFilter или MegaFilter создают сотни тысяч комбинаций с человеко-понятными URL. SEO-расширения типа seo_pro пытаются это причесать, но часто ломают canonical: каждая страница фильтра заявляет «я — каноническая». Google видит 50 страниц с якобы уникальным содержимым, тратит бюджет на их обход, а потом помечает как «Дубликат, Google выбрал другую каноническую». Было дело: магазин обуви, MegaFilter генерировал /men/shoes/color/black/size/42/. Canonical вёл сам на себя. Плюс в sitemap попадали все комбинации — около 200 тысяч URL. Новые модели кроссовок индексировались по 5 дней. Исправили: canonical для всех фильтров жёстко прописали на основную категорию, в sitemap оставили только бесфильтровые URL плюс несколько действительно ценных посадочных (бренды). Параметры сортировки закрыли в robots.txt. Через две недели темп индексации новых товаров ускорился вдвое.

Модификаторы-убийцы

OCMOD/VQmod добавляют блоки JSON-LD для микроразметки. Видел, как после установки модуля «SEO-микроразметка» на странице товара выводилось три блока @type: Product, один из которых с битым синтаксисом (незакрытая скобка). Google тратил бюджет, пытаясь распарсить эту кашу. Проверяйте через Google Rich Results Test каждый раз после установки новых расширений. Это не совет. Это привычка.

Рендеринг тоже жрёт

JS, CSS, API-запросы — всё это расходует бюджет. Alexis Sanders говорит: Google кеширует ресурсы агрессивно, но при условии, что вы не меняете URL без причины. Типичная тема OpenCart подключает скрипты как catalog/view/theme/default/js/common.js?v=1.2.3. При каждом билде версию наращивают — и Google считает, что это новый ресурс. Используйте content hash в имени файла: common.a1b2c3d.js. Содержимое не изменилось — имя не меняется, Google использует кеш. С API ещё опаснее: корзина ходит через AJAX POST-запросами к index.php?route=checkout/cart/add. POST не кешируется. Если Googlebot доберётся до страницы с включённым JavaScript и начнёт слать эти запросы (а он может, если рендерит), бюджет утекает в корзину. Это не исправляется в два клика. Но хотя бы убедитесь, что страницы, где эти запросы инициируются, не попали в приоритет сканирования.

Миграция без фанатизма

Переезд на новый домен или сервер — момент, когда Google активно повышает crawl rate, чтобы быстрее всё переиндексировать. Если сервер не справляется, отдаёт 500-е ошибки, Google откатывает лимит. Я пережил миграцию магазина на OpenCart 3 с выделенного сервера на облачный кластер. Включили редиректы со старого домена, новый сервер сразу лёг под нагрузкой — скрипты миграции забыли повесить индексы на oc_product_reward и oc_customer_online (не спрашивайте, зачем они понадобились при редиректах). Googlebot начал долбиться, получал 503, снизил темп. Полторы недели индекс обновлялся черепашьими темпами. Правило: перед миграцией прогнать нагрузочное тестирование (Apache Benchmark, siege) на страницы категорий с фильтрацией и пагинацией. Потом уже менять DNS. И никогда не делать одновременно редизайн, смену CMS и структуры URL.

Хайп и реальность

На конференциях трубят про GEO, AI Overviews, оптимизацию под нейроответы. Я скептик. Если сервер не умеет отдавать 304-й и генерирует 200 тысяч дублей фильтрации, никакая оптимизация под ChatGPT не поможет. Сначала — база. Быстрый TTFB, чистые HTTP-заголовки, грамотный canonical, отсутствие битой микроразметки. Это инженерный фундамент. Когда он есть, можно экспериментировать. Без него — маркетинговый хайп.

Прямо сегодня откройте GSC, статистику сканирования, разбивку по ботам. Если Googlebot-Image жрёт больше трети — сожмите картинки. Проверьте логи сервера на 5xx. Если есть — скорее всего, дело в медленных SQL-запросах при фильтрации (загляните в oc_product_to_category и oc_product_filter). И отключите автоматическое обновление lastmod в sitemap, если контент не менялся. Три шага, которые не требуют модных инструментов. Только консоль, mysql slow log и руки. SEO в 2026 — это не магия, а инженерная дисциплина. Бюджет сканирования — не лимит на количество страниц, а ограничение пропускной способности сервера. Уберите мусор, ускорьте ответ — и Google сам найдёт ваш новый товар. Без паники. Проверено.