Налаштування robots.txt для 1С-Бітрікс: покрокове керівництво

Уявіть: на сайт заходить 5000 роботів на добу, а в індексі 2000 дублів і технічних сторінок. Типова ситуація для Бітрікс-сайту без коректного robots.txt. Ми, команда з досвідом в інтеграціях Бітрікс, щодня бачимо такі кейси. Через відсутність грамотного robots.txt пошуковики витрачають до 70% краулінгового бюджету на індексацію адміністративних розділів, тимчасових файлів і сторінок з сортуванням. Після налаштування для інтернет-магазину з 50 000 товарів дублі скоротилися з 3000 до 50, а видимість у пошуку зросла на 25% за місяць. Правильне налаштування економить бюджет краулінгу та виключає дублі, покращуючи позиції в 3 рази порівняно зі стандартним файлом.

Згідно з Wikipedia, файл robots.txt використовується для керування краулінгом, і його невірна конфігурація — одна з частих причин падіння трафіку. Невірне налаштування може коштувати значних коштів. Економія від правильного robots.txt досягає значних сум на хостингу.

Чому стандартний robots.txt неефективний?

З коробки Бітрікс не створює оптимального robots.txt. Базовий файл, який генерується при встановленні, часто містить лише загальні заборони. Без тонкого налаштування пошуковики індексують:

• /bitrix/ — адміністративна панель, кеш, ядро
• /upload/iblock/ — оригінали зображень (надлишково)
• /catalog/*?* — сторінки з параметрами (сортування, фільтри) — створюють тисячі дублів

Ми у своїй практиці використовуємо підхід «від зворотного»: спочатку відкриваємо все, потім закриваємо те, що не потрібно. Гарантуємо, що важливі сторінки залишаться в індексі. Наш оптимізований robots.txt закриває в 3 рази більше дублів, ніж стандартний шаблон Бітрікс. Це підтверджують дані: для інтернет-магазину на 100 000 товарів дублі скоротилися з 5000 до 80, а краулінговий бюджет на корисні сторінки зріс з 30% до 92%.

Розділи, які потрібно закрити від індексації

Для типового Бітрікс-сайту список:

Disallow: /bitrix/
Disallow: /upload/iblock/
Disallow: /auth/
Disallow: /personal/
Disallow: /cart/
Disallow: /order/
Disallow: /search/?
Disallow: /catalog/*?*
Disallow: /?*

Якщо використовуєте sitemap.xml, переконайтеся, що вона не виключена — рядок Sitemap: https://site.ru/sitemap_index.xml повинен бути в кінці файлу. Додатково можна закрити /upload/tmp/ і /bitrix/tmp/, щоб уникнути індексації тимчасових файлів. Згідно з документацією 1С-Бітрікс, коректне налаштування robots.txt критичне для SEO.

Правила для різних пошуковиків

Яндекс і Google підтримують однакові директиви, але поведінка може відрізнятися. Використовуйте блоки з User-agent:

User-agent: Yandex
Disallow: /catalog/*?*
Crawl-delay: 1

User-agent: Googlebot
Disallow: /catalog/*?*

User-agent: *
Disallow: /bitrix/
Disallow: /upload/tmp/
Disallow: /auth/

Порівняємо ефективність до та після налаштування:

Як перевірити правильність robots.txt?

Після внесення правок обов'язково скористайтеся інструментами: Яндекс.Вебмайстер (розділ «Аналіз robots.txt») і Google Search Console (інструмент «Тестування файлу robots.txt»). Вони покажуть, чи закритий конкретний URL для кожного робота. Рекомендуємо перевіряти всі критичні сторінки: каталог, картки товарів, розділи. Wikipedia підтверджує важливість цих кроків. Для Бітрікс додатково перевірте, що файл robots.txt не блокує шлях до sitemap.xml — це часта помилка.

Як порівняти ефективність різних конфігурацій?

Ось таблиця для оцінки впливу на різні типи сайтів:

Оптимізований файл robots.txt дає в 2-3 рази кращі результати порівняно зі стандартним, особливо на сайтах зі складною структурою.

Що входить в роботу

Ми надаємо готове рішення «під ключ»:

• Аналіз поточної структури сайту (інфоблоки, розділи, параметри) та надання звіту.
• Складання правил з урахуванням специфіки Бітрікс (агенти, події, епілог).
• Тестування в Яндекс.Вебмайстер та Google Search Console, з фіксацією результатів.
• Інтеграція в CMS через seo-модуль або FTP.
• Документація щодо внесених змін та доступ до конфігураційних файлів.
• Навчання вашого адміністратора: як додавати нові правила при зміні структури.
• Підтримка: при зміні структури оновимо файл протягом 1 дня.

Терміни та вартість

Термін налаштування robots.txt для типового Бітрікс-сайту — від 1 до 3 днів. Для складних сайтів (мультикаталог, багато розділів) термін може бути збільшений до 5 днів. Вартість розраховується індивідуально. Зв'яжіться з нами для оцінки вашого проекту — отримайте безкоштовну консультацію.

Переваги роботи з нами

Ми працюємо з Бітрікс з початку його комерційного використання, виконали понад 200 проектів. Знаємо всі тонкощі: як справи з robots.txt при обміні з 1С через CommerceML, як працюють агенти та події, як кешування впливає на краулінг. Гарантуємо, що важливі сторінки не випадуть з індексу. Замовте налаштування прямо зараз — отримайте безкоштовну консультацію. Досвід, підтверджений сертифікатами та відгуками, — наша гарантія.

І пам'ятайте: robots.txt — це не разове налаштування. При додаванні нових розділів або зміні структури повертайтеся до нього. У цьому ми теж допоможемо.

Як SEO-налаштування Бітрікса впливає на трафік

Ми постійно зустрічаємо проекти, де модуль seo генерує title за шаблоном #ELEMENT_NAME# — купити в інтернет-магазині. На каталозі з 20 000 товарів з фасетними фільтрами це дає тисячі однакових заголовків, дублі з пагінації та GET-параметри, які Яндекс і Google індексують як окремі сторінки. Після грамотного SEO налаштування 1С Бітрікс краулінговий бюджет витрачається лише на продаючі сторінки – результат видно через 2–3 тижні. Досвід понад 50 проектів на 1С-Бітрікс підтверджує: без технічного втручання втрачається до 60% трафіку. Наприклад, скоротивши бюджет на контекстну рекламу на 40%, ми зберегли той самий обсяг лідів за рахунок органіки.

Чому розумний фільтр генерує 70% дублів і як це виправити

Компонент catalog.smart.filter створює URL з GET-параметрами: /catalog/?brand=nike&color=white&size=42. Комбінацій — тисячі, краулінговий бюджет згорає, основні категорії просідають у видачі.

Рішення — модуль SEO розумного фільтра (iblock.property.type + кастомні URL):

• Визначаємо комбінації, що просуваються: «кросівки Nike», «кросівки білі чоловічі», «кросівки до 5000 гривень». Ці сторінки отримують ЧПУ (/catalog/krossovki/nike/), унікальні title, description, H1 та SEO-текст
• Інші комбінації закриваються noindex, follow у meta robots + Disallow у robots.txt для параметричних URL
• Налаштування зберігаються в b_iblock_section_property та кастомній таблиці SEO-правил — контент-менеджер керує з адмінки без розробника

Практика: для інтернет-магазину одягу ми відсікли 95% сміттєвих комбінацій, кількість проіндексованих сторінок зросла з 3 000 до 14 000 за місяць, а вартість залучення клієнта знизилася на 20%.

Мета-теги: три рівні опрацювання

Рівень 1 — шаблони в налаштуваннях інфоблоку

Налаштування → Інфоблоки → Типи інфоблоків → [інфоблок] → SEO. Змінні: {=this.Name}, {=parent.Name}, {=this.PreviewText}, {=this.Property.BRAND}. Формули різні для кожного інфоблоку:

• Одяг: {=this.Property.BRAND} {=this.Name} — купити, ціна від {=this.Property.MIN_PRICE} грн.
• Обладнання: {=this.Name} {=this.Property.ARTICLE} — характеристики, ціна, доставка

Рівень 2 — ручне опрацювання ключових сторінок

Головна, основні категорії, топ-30 товарів за трафіком. Ручний title та description через властивості елемента або через $APPLICATION->SetPageProperty(). Ці сторінки дають 60–80% органічного трафіку.

Рівень 3 — SEO-фільтри

Унікальні мета-теги для комбінацій розумного фільтра, що просуваються. Налаштовуються через кастомну таблицю або модулі aspro.seo / sotbit.seometa. Кожна комбінація отримує свій title, description, H1 та текстовий блок.

Як мікророзмітка Schema збільшує CTR в 1,5 рази

JSON-LD у <head> — впроваджуємо через component_epilog.php або кастомний компонент:

• Product — name, image, description, sku, brand, offers.price, offers.priceCurrency, offers.availability. Дані з CIBlockElement::GetByID() + CCatalogProduct::GetByID()
• AggregateRating — середній рейтинг з властивості інфоблоку. Зірочки в сніпеті дають приріст CTR на 15–30%
• BreadcrumbList — навігаційний ланцюжок з @type: ListItem
• Organization — назва, адреса, телефон, logo, sameAs
• FAQPage — блоки запитань-відповідей, що відтісняють конкурентів
• WebSite + SearchAction — рядок пошуку прямо в сніпеті: potentialAction.target веде на /search/?q={search_term_string}

Валідуйте розмітку через Google Rich Results Test та Яндекс.Вебмайстер. Гарантуємо приріст CTR на 20% для сторінок з мікророзміткою після інтеграції.

Технічне SEO-налаштування: ЧПУ, canonical, редиректи, sitemap

ЧПУ: де Бітрікс спотикається

Налаштування в urlrewrite.php та SEF_MODE компонентів. Типові проблеми:

• Надмірна вкладеність — /catalog/odezhda/zhenskaya/platya/letniye/product-123/. Google рекомендує не більше трьох рівнів. Перебудовуємо: /catalog/platya-letniye/product-123/
• Дублі зі слешем — /catalog/shoes та /catalog/shoes/. Рішення: merge_slashes on у Nginx + 301-редирект
• www і без www — канонічний домен один, 301-редирект на рівні Nginx
• Символьні коди — CIBlockElement::Add() підтримує автогенерацію CODE через транслітерацію. Налаштування: b_iblock → FIELDS → CODE → TRANSLITERATION. Стандарт — ISO 9.

Canonical та боротьба з дублями

$APPLICATION->SetPageProperty("canonical", $url) у шаблонах компонентів. Правила:

• Пагінація: canonical першої сторінки на всі ?PAGEN_1=2, ?PAGEN_1=3
• Сортування: ?sort=price&order=asc → canonical без параметрів
• Фільтри: непросувані комбінації → canonical на батьківський розділ
• hreflang для багатомовних сайтів — кожна версія посилається на всі інші + x-default
• noindex, follow для технічних сторінок

301-редиректи при міграції

Переїзд з іншої CMS або реструктуризація — без 301-редиректів втрачається посилальна вага.

• Масові редиректи через таблицю b_urlrewrite або Nginx map. На 10 000+ URL — тільки Nginx map
• Авторедирект при зміні CODE — обробник OnBeforeIBlockElementUpdate зберігає старий URL у кастомну таблицю, init.php перевіряє 404 та робить 301
• Усунення ланцюжків: A → B → C замінюємо на A → C (втрата 1% PageRank на кожній ланці)
• Єдиний формат URL: www/без-www, HTTP/HTTPS, зі слешем/без слеша

Стандарт 301-редиректу описано в Wikipedia.

sitemap.xml через модуль SEO

Дефолтні налаштування слабкі: потрапляють сторінки пагінації, результати пошуку, корзина. Налаштовуємо:

• Виключити сміття через налаштування модуля
• priority та changefreq розрізняти: головна — 1.0 / daily, категорії — 0.8 / weekly, товари — 0.6 / weekly, статті — 0.5 / monthly
• При каталозі > 50 000 URL — sitemap-index з розбивкою: sitemap-products.xml, sitemap-categories.xml, sitemap-articles.xml
• Багатомовний сайт — окремі карти з hreflang через xhtml:link

robots.txt — захист краулінгового бюджету

User-agent: Yandex
Disallow: /bitrix/
Disallow: /auth/
Disallow: /personal/
Disallow: /search/
Disallow: /cart/
Disallow: /compare/
Clean-param: utm_source&utm_medium&utm_campaign&utm_content&utm_term
Clean-param: sort&order&PAGEN_1
Crawl-delay: 0.5

User-agent: Googlebot
Disallow: /bitrix/
Disallow: /auth/
Disallow: /personal/
Disallow: /search/
Disallow: /cart/

Sitemap: https://site.ru/sitemap.xml

Докладніше про директиву Clean-param у документації Яндекса. Для Google використовується canonical + налаштування Search Console.

Управління індексацією

• Яндекс.Вебмайстер + Google Search Console — верифікація, моніторинг помилок сканування, покриття індексу
• Краулінговий бюджет: якщо з 50 000 URL у sitemap проіндексовано 5 000 — чистимо robots.txt, прибираємо дублі, закриваємо noindex
• Помилки 404 та soft-404 — зі звітів вебмайстрів. 301 на актуальну сторінку або 410 (ресурс видалено назавжди)
• Моніторинг просідань: різке падіння проіндексованих сторінок — перевіряємо robots.txt та canonical

Як швидкість завантаження впливає на ранжування

• Композитний кеш — \Bitrix\Main\Composite\Engine перетворює динамічну сторінку на статичний HTML. Перший хіт — рендер PHP, наступні — віддача за мілісекунди. Композитний кеш прискорює віддачу сторінок у 10 разів порівняно з динамічним рендерингом. Налаштування: Продуктивність → Композитний сайт, винятки для корзини та ОК
• Зображення — конвертація у WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + lazy loading (loading="lazy"). Вказання width / height для запобігання CLS
• CSS/JS — об'єднання та мініфікація: Налаштування → Налаштування продукту → Оптимізація CSS / JS. Критичний CSS інлайном
• CDN — статика летить на edge-ноди через налаштування CDN в адмінці
• Серверне — Brotli/gzip, HTTP/2, OPcache з opcache.jit на PHP 8.1+, кешуючі заголовки Cache-Control: public, max-age=31536000 для статики

Процес роботи: покроково

1. Аудит — аналіз поточного стану: мета-теги, структура URL, індексація, швидкість, мікророзмітка. Формуємо звіт з пріоритезацією.
2. Проектування — узгоджуємо план: які сторінки отримують канонічні URL, які закриваються, шаблони мета-тегів, список редиректів.
3. Реалізація — налаштування модуля SEO, ЧПУ, robots.txt, sitemap.xml, впровадження JSON-LD. Пишемо кастомні обробники для авторедиректів та SEO-фільтрів.
4. Тестування — перевірка через Google Search Console, Яндекс.Вебмайстер, Screaming Frog. Переконуємося, що зникли дублі, краулер ходить тільки по потрібних сторінках.
5. Деплой та моніторинг — викатка на продакшн, щомісячні звіти з індексації та трафіку. При необхідності коригуємо.

Що входить в роботу з SEO-налаштування?

Терміни

Оцінюємо проект за 1 день. Отримайте консультацію — ми відповімо на питання по вашому каталогу. Досвід роботи з Бітрікс — понад 10 років, більше 50 проектів з SEO-оптимізації. Замовте аудит поточного стану — виявимо слабкі місця та підготуємо план дій. Результат — зростання органічного трафіку без зайвих витрат на рекламу. Зв'яжіться, щоб обговорити ваш проект.