SEO26.09.2026·18 мин

Sitemap.xml и robots.txt на Битриксе: настройка без копипасты шаблонов

Порядок действий такой: закрыть служебные разделы Битрикса, разобрать параметры умного фильтра по логам, отдать в sitemap.xml только каноничные активные URL и проверить результат в Яндекс.Вебмастере и Google Search Console. Универсального robots.txt для Битрикса не существует: мусорные адреса генерирует не CMS, а конкретный умный фильтр, сортировки и пагинация вашего проекта.

Собрать реальные GET-параметры сайта по логам ботов.
Закрыть /bitrix/, /local/, /auth/, /personal/, /cart/, /order/, /search/.
Оставить открытыми CSS, JS и /upload/iblock/.
Прописать Clean-param для Яндекса, canonical для обоих поисковиков.
Открыть фасетные посадочные, закрыть остальные комбинации фильтра.
Пагинацию оставить открытой со self-canonical.
Настроить генерацию sitemap через cron, разбить на файлы.
Принять работу по чек-листу через 7 и 14 дней.

Важная оговорка: robots.txt не удаляет страницы из индекса Google, это инструкция о сканировании. Статья для владельцев каталогов от 1 000 до 100 000 URL, SEO-специалистов и разработчиков, которым прилетела задача «настрой robots».

Зачем эти два файла в 2026 году: краулинговый бюджет вместо «запрета индексации»

Эти файлы решают не одну задачу, а три разные, и их постоянно путают. Запрет сканирования, это robots.txt; запрет индексации, это meta noindex и X-Robots-Tag; склейка дублей, это canonical и Clean-param.

Что на самом деле делает robots.txt

Он экономит обход. Если бот тратит большую часть визитов на адреса вида ?sort=price&order=asc, новые товары ждут индексации неделями. На каталоге из 300 товаров это почти не важно, на 40 000 критично.

Sitemap.xml, подсказка о приоритете и свежести

Карта не гарантирует индексацию, она сообщает боту список важных URL и даты изменения. Гарантий нет ни у одного поисковика, но без карты глубокие товары находятся заметно дольше.

Как это связано с заявками

Медленная индексация новых SKU и посадочных, это недополученный трафик и обращения. Ориентир для проверки: «Статистика обхода» в Вебмастере и «Статистика сканирования» в GSC, смотрим соотношение полезных и мусорных URL.

Почему готовый robots.txt для Битрикса из интернета не работает на вашем сайте

Шаблоны из выдачи написаны под дефолтный «Магазин» из маркетплейса и не знают параметров вашего фильтра. Три типовые поломки от копипасты: закрыты собственные фасетные посадочные, закрыт /upload/ вместе с картинками товаров, при этом генератор бесконечных URL своего фильтра остался открытым.

Плюс сам Битрикс изменился: код проекта живёт в /local/, а не только в /bitrix/templates/, умный фильтр умеет ЧПУ-адреса вида /filter/brand-bosch/apply/, у разработчиков свои компоненты и параметры. Поэтому сначала собираем список реальных параметров сайта, потом пишем правила.

Шаг 0: собираем список реальных мусорных URL своего сайта

Начинать надо не с файла, а с выгрузки: что бот реально обходил за последние 30 дней. Источников четыре.

Логи nginx или Apache. Топ обходов ботов:

grep -iE 'YandexBot|Googlebot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -200

Только имена параметров:

grep -iE 'YandexBot|Googlebot' access.log | awk '{print $7}' | grep '?' | cut -d'?' -f2 | tr '&' '\n' | cut -d= -f1 | sort | uniq -c | sort -rn

Вебмастер: «Страницы в поиске» и «Статистика обхода».
GSC: отчёты «Проиндексировано, несмотря на блокировку» и «Обнаружено, не проиндексировано».
Краулер (Screaming Frog или site-audit) по своему домену.

Результат сводим в таблицу: параметр, сколько URL плодит, нужен ли в поиске, решение (Disallow, Clean-param, canonical, оставить). На боевом проекте обычно выходит 15-40 уникальных параметров, из которых в поиске нужны два или три. Сигнал утечки бюджета: доля обходов URL с параметрами и пагинации выше 50%. Отдельно выпишите адреса, которых нет ни в меню, ни в карте, это следы старого фильтра или кривой перелинковки.

Базовый robots.txt для 1С-Битрикс: разбираем построчно

Каркас состоит из четырёх директив: User-agent задаёт робота, Disallow и Allow задают правила, Sitemap указывает карту и работает глобально, вне зависимости от блока. При конфликте побеждает более специфичное (более длинное) правило, поэтому Allow для стилей сильнее общего Disallow на каталог.

User-agent: *
Disallow: /bitrix/
Disallow: /local/
Disallow: /auth/
Disallow: /personal/
Disallow: /cart/
Disallow: /order/
Disallow: /search/
Disallow: /upload/tmp/
Disallow: /upload/1c_exchange/
Disallow: /*?login=yes
Disallow: /*?backurl=
Disallow: /*clear_cache
Disallow: /*set_filter=   # ЗАМЕНИТЬ под свой фильтр
Disallow: /*arrFilter    # ЗАМЕНИТЬ под свой фильтр
Allow: /bitrix/js/
Allow: /bitrix/templates/*.css
Allow: /bitrix/templates/*.js
Allow: /local/templates/*.css
Allow: /local/templates/*.js
Allow: /upload/iblock/

User-agent: Yandex
# продублировать ВСЕ правила из блока выше
Clean-param: sort&order&utm_source&utm_medium&utm_campaign&utm_term&utm_content&yclid&gclid&from&r1

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

Строки с пометкой «ЗАМЕНИТЬ» и список Clean-param берутся из вашей таблицы из Шага 0, а не из шаблона. Allow нужен чаще, чем кажется: /bitrix/ закрыт целиком, но стили и скрипты шаблона обязаны отдаваться роботу.

Служебные разделы Битрикса: /bitrix/, /local/, /auth/, /personal/, /upload/

Служебку закрывают не ради «защиты», а чтобы бот не тратил обход. Единственное исключение, файлы, участвующие в рендеринге: их надо открыть явным Allow.

Раздел	Закрывать	Почему и исключения
/bitrix/, /local/	Да	Служебный код. Открыть .css, .js, шрифты, картинки шаблона
/auth/, ?login=yes, ?register=yes, ?backurl=	Да	Плодят дубль любой страницы
/personal/, /cart/, /order/	Да	В поиске не нужны, обход тратить незачем
/upload/	Точечно	Закрыть /upload/tmp/, /upload/1c_exchange/, бэкапы. /upload/iblock/ оставить открытым
/search/, /ajax/, /include/, /bitrix/rk.php, /bitrix/redirect.php	Да	Результаты поиска и технические переходы

Закрытие CSS и JS даёт битый рендер: Google не понимает основной контент и мобильную пригодность. На поле CrUX это не влияет напрямую, на оценку страницы роботом влияет. Личные разделы закрывают именно в robots.txt, а не noindex: их не нужно ни сканировать, ни индексировать.

Параметры и дубли: sort, PAGEN_N, set_filter, arrFilter, utm. Disallow, Clean-param или canonical

Правильный ответ почти всегда комбинация, а не один инструмент. Canonical работает в обоих поисковиках, Clean-param только в Яндексе, Disallow оставляем для параметров, которые плодят бесконечность и не имеют ценности.

Инструмент	Яндекс	Google	Когда применять
canonical	Учитывает	Учитывает как рекомендацию, сигналы переходят на канонический URL	Базовый слой для всех дублей
Clean-param	Склеивает быстро, экономит обход	Игнорирует	Блок User-agent: Yandex, метки и сортировки
Disallow по параметру	Не сканирует	Не сканирует, но URL может остаться в индексе без сниппета	Только для бесконечных мусорных URL, которых ещё нет в индексе

Disallow на уже проиндексированный адрес, ошибка: бот не зайдёт и не увидит ни canonical, ни noindex, страница застрянет в индексе. Метки utm закрывать не нужно, достаточно canonical плюс Clean-param, иначе теряются данные и обход рекламных лендингов. Битрикс-специфика имён: sort, order, PAGEN_1..PAGEN_5, set_filter, del_filter, arrFilter_*, clear_cache, bitrix_include_areas, from, r1, ymclid.

Пагинация PAGEN_N: закрывать или нет после отмены rel=prev/next

По умолчанию пагинацию не закрывают: это путь бота к товарам вглубь каталога. rel=prev/next больше не учитывается, поэтому задачу решают canonical и настройка мета-тегов.

Три варианта и последствия. Первый, открыть пагинацию со self-canonical на каждой странице, это рабочий дефолт. Второй, canonical со всех страниц на первую, распространённая ошибка: товары со второй страницы и дальше перестают обходиться, на каталоге в 40 000 SKU так обрывается путь к большей части ассортимента. Третий, Disallow на PAGEN, оправдан только если у товаров есть другой полноценный путь (полная карта плюс перелинковка), а пагинация даёт десятки тысяч мусорных URL.

Рекомендация: пагинация открыта, self-canonical, в title и description добавлена «Страница N», SEO-текст только на первой странице. Отдельный нюанс Битрикса: адрес с PAGEN_1 дублирует раздел, его склеиваем canonical на URL без параметра.

Умный фильтр и фасетная навигация: как не закрыть свои же посадочные

Если вы делаете на фильтре посадочные, глушить его целиком нельзя. Нужна выборочная схема: открыть нужные комбинации, закрыть остальные.

Два режима фильтра

GET-параметры (?set_filter=y&arrFilter_...) и ЧПУ через SEF_MODE (/filter/brand-bosch/apply/). Для посадочных нужен второй режим.

Критерий отбора

Есть частотный спрос по Wordstat, в выборке достаточно товаров, и фасет один или два (бренд, тип, размер), а не пять.

Технически

Allow для конкретных ЧПУ-паттернов посадочных, Disallow для /*set_filter= и /*arrFilter, на многофасетных комбинациях noindex, follow. Пустая выборка должна отдавать noindex, а не мягкий 404 с индексацией. Заголовок, title и описание задаём через SEO-настройки умного фильтра, иначе посадочные окажутся дублями раздела.

И главное: фасетные посадочные обязательно попадают в sitemap.xml и в перелинковку, иначе бот найдёт их только случайно. Механика такая: открыли полторы-две сотни отобранных комбинаций, закрыли остальное, обход перераспределился в пользу товаров и посадочных.

Разные правила для Яндекса и Google: что нужно разделять, а что миф

Отдельный блок User-agent: Yandex нужен ровно для одной директивы, Clean-param. Всё остальное для обоих поисковиков почти всегда одинаково.

Критично помнить правило чтения: если блок User-agent: Yandex существует, Яндекс читает только его, а общие правила из User-agent: * игнорирует. Их надо продублировать целиком, иначе робот спокойно пойдёт по всей служебке. Это источник половины поломок на аудитах.

Мифы. Host отменён, зеркала задаются 301-редиректом и настройкой в Вебмастере. Crawl-delay Яндекс не учитывает (скорость обхода настраивается в Вебмастере), Google её никогда не поддерживал; смысл остаётся только против сторонних агрессивных краулеров. Отдельные блоки Googlebot-Image и Googlebot-News типовому каталогу не нужны.

Как редактировать robots.txt в админке Битрикса и не потерять правки

Путь: Маркетинг, Поисковая оптимизация, Настройка robots.txt. Модуль пишет в физический файл в корне сайта, а при многосайтовости в корень выбранного сайта.

Если бот видит не то, что в админке, проверяйте по порядку: физический файл по SSH, правило в nginx или .htaccess, которое отдаёт свой robots.txt, композитный кеш и CDN, код ответа и Content-Type, перехват запроса модулем ЧПУ. Диагностика одной командой:

curl -A 'Mozilla/5.0 (compatible; YandexBot/3.0)' -i https://site.ru/robots.txt

Правки «теряются» по трём причинам: обновление шаблона или модуля, деплой без robots.txt в репозитории, восстановление из бэкапа старше изменений. Держите файл под git, меняйте через задачу, а не руками в проде, и фиксируйте дату правки комментарием внутри файла.

Sitemap.xml в Битриксе: настройка штатного модуля по вкладкам

Маркетинг, Поисковая оптимизация, Настройка sitemap.xml. Создаём отдельный набор настроек под каждый сайт.

Настройки: имя файла, индексный файл, тип генерируемых карт, ограничение размера.
Файлы: включать только публичные каталоги и нужные расширения, служебку и /upload/tmp/ исключить.
Инфоблоки: отметить разделы и элементы, включить фильтр по активности и датам публикации, а шаблон ссылки указать ровно такой, как в DETAIL_PAGE_URL инфоблока. Иначе в карте окажутся URL, отдающие 404.
Форумы: обычно выключаем, пользовательский контент в карте не нужен.
Переиндексация: настроить автоматическое обновление (см. раздел про cron ниже).

Priority поисковики фактически игнорируют, а lastmod имеет вес только если он честный: одинаковая дата генерации на всех URL обесценивает карту. После генерации проверьте /sitemap.xml в браузере, права на запись в корень, и обязательно добавьте карту в Вебмастер и GSC вручную плюс строкой Sitemap в robots.txt.

Какие URL должны попасть в карту сайта, а какие никогда

Мнемоника простая: в sitemap только то, что вы готовы увидеть в выдаче как отдельную страницу.

Должны быть: каноничные страницы разделов, активные товары, доступные к заказу, отобранные посадочные умного фильтра, статьи блога, коммерческие статические страницы.

Не должно быть никогда: URL с параметрами, страницы пагинации, всё закрытое в robots.txt, редиректы 301 и 302, 404, страницы с canonical на другой адрес, страницы с noindex, /personal/, /cart/, результаты поиска.

Неактивные и удалённые товары попадают в карту по типовым причинам: переиндексация не запускалась, агенты не выполняются, товар скрыт по нулевому остатку, а не деактивирован, генерация упала и оставила старый файл. Проверка после каждой генерации: прогнать все URL из карты краулером в режиме списка. Норма, 100% кода 200 и self-canonical.

Автообновление карты: агенты, cron и что делать, когда генерация падает

Если генерация вешает сайт на 40 000 товарах, причина почти всегда одна: агент выполняется на хите пользователя, упирается в max_execution_time и memory_limit и начинается заново с нуля. На низкотрафиковых сайтах та же механика даёт другую проблему: агенты вообще не доходят до конца.

Перевести агенты на cron: BX_CRONTAB в настройках, задание в crontab, запуск ночью.
Дать cron-процессу отдельные лимиты памяти и времени выполнения.
Разбить карту на файлы по 10 000-20 000 URL с индексным sitemap.
Генерировать во временный файл и подменять через rename, иначе бот заберёт недописанную карту.
Для очень больших каталогов написать свой скрипт: постраничная выборка CIBlockElement::GetList и потоковая запись, без накопления массива в памяти.
Частота по реальным изменениям: каталог с ежедневными поступлениями, каждую ночь; статика, раз в неделю.

Мониторинг: лог генерации, mtime файла, число URL. Алерт, если карта не обновлялась заданное число дней или количество URL просело более чем на 10%.

Когда штатного sitemap мало: динамическая генерация и разделение карт

Разделять карты стоит раньше, чем вы упрётесь в лимиты. Главная причина практическая: Вебмастер и GSC показывают статистику по каждому файлу, поэтому по разделению видно, какой именно тип страниц не индексируется.

Рабочая схема: /sitemap.xml как индекс, внутри sitemap-catalog-1.xml, sitemap-sections.xml, sitemap-filters.xml, sitemap-blog.xml, sitemap-static.xml. Динамическая генерация на лету нужна при сотнях тысяч URL, частой смене наличия и мультирегиональности на поддоменах; обязательно кешировать результат и отдавать gzip, иначе каждый визит бота превращается в нагрузку. Отдельный image-sitemap имеет смысл там, где трафик по картинкам реально конвертирует: мебель, декор, одежда.

Лимиты и индексная карта для каталогов от 50 000 URL

Жёсткие лимиты одинаковы у Яндекса и Google: 50 000 URL и 50 МБ в несжатом виде на один файл, до 50 000 файлов в одном индексе. Gzip разрешён и снижает вес при передаче, но ограничение по несжатому размеру остаётся.

Индекс нужен либо когда URL больше 50 000, либо когда вам нужна диагностика по типам страниц, и второе наступает раньше первого. Практичный размер одного файла, 10 000-20 000 URL: быстрее генерируется, проще искать ошибки. В robots.txt указывается только индексный файл. Вложенность индексов больше одного уровня недопустима: индекс не может ссылаться на другой индекс.

Многосайтовость и регионы: отдельные robots.txt и sitemap для поддоменов

robots.txt читается по каждому хосту отдельно: msk.site.ru/robots.txt и spb.site.ru/robots.txt, это разные файлы. Если поддомены смотрят в один DOCUMENT_ROOT, все получат один файл с директивой Sitemap чужого хоста, и такая межхостовая карта игнорируется.

Решение первое: многосайтовость Битрикса с разными корнями, свой физический robots.txt в корне каждого сайта. Решение второе, при общем корне: отдавать robots.txt скриптом с подстановкой Sitemap по $_SERVER['HTTP_HOST'] либо правилом nginx с map по хосту. Для каждого региона нужна своя карта только со своими URL.

Проверка занимает минуту: curl по robots.txt каждого поддомена, сверить строку Sitemap и убедиться, что поддомен добавлен в Вебмастер как отдельный сайт.

Проверка и сдача: валидаторы, Вебмастер, GSC, логи

Приёмка идёт в четыре шага, и каждый даёт проверяемый результат.

Сервер: файл отдаётся с кодом 200 и Content-Type text/plain, без BOM и с переводами строк LF.
Вебмастер, «Анализ robots.txt»: прогнать заранее подготовленный список из 30 реальных URL (по 3 на тип: товар, раздел, фасетная посадочная, пагинация, сортировка, корзина, личный кабинет), ожидаемый результат выписан до проверки.
Карта: «Анализ файлов Sitemap» в Вебмастере и отчёт Sitemaps в GSC без ошибок. В «Проверке URL» смотрим строки «Сканирование разрешено», «Индексирование разрешено» и выбранный Google канонический URL.
Логи через 7 и 14 дней: доля обходов мусорных URL падает, доля обходов товаров растёт.

Сроки: robots.txt Google обычно перечитывает в пределах суток, Яндекс за несколько дней; смена маршрута бота видна в логах через 1-2 недели, переиндексация крупного каталога занимает 4-8 недель. В отчёте фиксируем число URL в индексе по типам, распределение обходов и число ошибок в карте, до и после.

Типичные ошибки на проектах Битрикс: 12 случаев из практики

Disallow: / на проде, забытый после переноса с тестового сервера. Обнаружение: curl по файлу.
/bitrix/ закрыт целиком: Google не видит CSS и JS. Проверка в «Проверке URL», скриншот рендера.
Закрыт /upload/: из индекса выпали картинки товаров. Видно по трафику из поиска по картинкам.
Блок User-agent: Yandex без дублирования общих правил: Яндекс обходит всю служебку. Видно в «Статистике обхода».
Canonical с пагинации на первую страницу: товары глубже второй страницы не обходятся.
Disallow вместо noindex на проиндексированных URL: страницы застряли в индексе без сниппета, отчёт «Проиндексировано, несмотря на блокировку».
В карте URL, отдающие 301 на тот же адрес со слешем. Краулер по списку.
Неактивные и удалённые товары в карте: переиндексация не запускалась месяцами.
Агенты на хитах: карта обрезана, например 12 000 URL из 40 000. Сверить число URL с числом активных элементов.
Один robots.txt на 12 региональных поддоменов с картой главного домена.
robots.txt отдаёт 404 из-за правила nginx или перехвата модулем ЧПУ.
Файл с BOM и CRLF: первая директива игнорируется. Проверка: file и hexdump первых байтов.

Как закрыть тестовую копию сайта от индексации так, чтобы это работало

Основная мера, HTTP-авторизация (basic auth на уровне nginx): бот получает 401 и не индексирует ничего. Disallow: / недостаточно, ссылки на тестовый домен попадают в индекс без сниппета, а сам файл при синхронизации с продом легко перезаписывается.

Второй уровень защиты: заголовок X-Robots-Tag: noindex, nofollow от nginx на весь тестовый хост, он работает независимо от файлов Битрикса. Disallow: / в robots.txt оставляем как дополнение, не как основную меру. При копировании прода на тест не тащите туда prod-robots.txt и карту с prod-URL, и отключите отправку карты в панелях.

Если тест уже в индексе, порядок обратный: снять блокировку в robots.txt, отдать noindex или 410, дождаться переобхода и только после исчезновения из индекса закрывать авторизацией.

Чек-лист внедрения и что контролировать через 2 недели

Перед правками зафиксируйте «до»: число страниц в поиске по Вебмастеру, число проиндексированных по GSC, распределение обходов бота по типам URL из логов, число URL и ошибок в карте. Без этих цифр эффект нечем измерить.

Внедрение: каждый пункт формулируем как проверяемый результат, не «настроить robots», а «curl отдаёт 200, в файле есть строка Sitemap и нет Host». Так же по остальному: служебка закрыта, CSS и JS открыты, Clean-param собран из своей таблицы, посадочные фильтра открыты и в карте, пагинация со self-canonical, генерация на cron с атомарной подменой файла, карта разбита на файлы, обе панели подтвердили обработку.

День 7: robots.txt подхвачен обеими панелями, карта обработана без ошибок, в логах виден новый маршрут бота. День 14: доля обходов мусорных URL снизилась, новые товары индексируются быстрее, отчёт «Проиндексировано, несмотря на блокировку» не растёт. День 30-60: растёт число полезных страниц в поиске, появляются фасетные посадочные, и только потом смотрим трафик и заявки по этим типам страниц. Сигнал отката: падение числа страниц в поиске более чем на 10% без объяснимой причины.

Частые вопросы

Почему страница закрыта в robots.txt, но висит в поиске Google?

robots.txt запрещает сканирование, а не индексацию. При наличии ссылок Google держит URL в индексе без сниппета. Порядок: убрать Disallow, дать увидеть noindex или 410, дождаться переобхода.

Clean-param или canonical, если нужны оба поисковика?

Оба. Canonical понимают Яндекс и Google, Clean-param работает только в Яндексе, но склеивает быстрее и экономит обход. Disallow, только для бесполезных бесконечных URL.

Надо ли закрывать пагинацию?

По умолчанию нет. Self-canonical на каждой странице, «Страница N» в title, SEO-текст только на первой, PAGEN_1 склеен с URL раздела.

Нужно ли закрывать /upload/?

Целиком нельзя: в /upload/iblock/ лежат изображения товаров. Закрывайте подпапки: tmp, 1c_exchange, support, выгрузки и бэкапы.

Почему в карте оказываются неактивные товары?

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

Сколько файлов sitemap нужно?

Лимит 50 000 URL и 50 МБ, но индекс делают раньше, ради диагностики по типам страниц. Практичный размер файла 10 000-20 000 URL.

Нужны ли Crawl-delay и Host в 2026 году?

Нет. Host отменён, зеркала решаются 301 и Вебмастером. Crawl-delay Яндекс не учитывает, Google не поддерживал никогда.

Один robots.txt на все поддомены, это ошибка?

Да, если в нём карта главного домена: межхостовый sitemap игнорируется. Файл читается по каждому хосту отдельно.

Что будет, если удалить robots.txt совсем?

Сайт останется полностью доступным для сканирования. На маленьком сайте почти ничего, на крупном каталоге бот уйдёт в сортировки и фильтры. Важно: отсутствующий файл должен отдавать 404, а не 5xx.

Как закрытие CSS и JS влияет на рендеринг?

Google рендерит страницу перед индексацией и при заблокированных файлах видит неотформатированный документ. Поэтому при закрытом /bitrix/ обязательны Allow для *.css, *.js, шрифтов и изображений шаблона.

Нужна помощь с техническим SEO на Битриксе

КлиентЛаб работает с 2012 года: SEO и реклама в Яндекс Директ и Google Ads, специализация, e-commerce на 1С-Битрикс, B2B и промышленность, медицина. Результат считаем в заявках и стоимости обращения, без обещаний позиций и гарантий топа.

В технический аудит Битрикса входит сбор реальных параметров по логам, схема robots.txt плюс canonical плюс Clean-param под ваш проект, настройка генерации sitemap на больших каталогах, отбор фасетных посадочных и приёмка по чек-листу.

Что сделать на этой неделе:

Выгрузить обходы ботов за 30 дней и посчитать долю URL с параметрами.
Проверить curl, что robots.txt совпадает с админкой и отдаёт 200.
Прогнать все URL из sitemap.xml краулером по списку.
Убедиться, что CSS, JS и /upload/iblock/ открыты.
Проверить, есть ли посадочные умного фильтра в карте сайта.

Пришлите адрес сайта, и мы бесплатно сделаем экспресс-аудит: разберём текущий robots.txt и sitemap, покажем, что закрыто лишнего и где утекает краулинговый бюджет.

Материалы по теме

ДД

Дмитрий Дмитриев

Head of SEO / Founder KlientLab · в интернет-маркетинге с 2012 года

Специализируюсь на белом поисковом продвижении, AEO/GEO в нейросетях и сквозной аналитике для B2B и медицины.

Остались вопросы по теме статьи?

Напишите нам: проанализируем ваш сайт и подскажем, как применить описанные решения на практике.

Разберём проект до созвона

Заполните бриф: сайт, ниша, задача и конкуренты. Посмотрим спрос и текущие кампании заранее, чтобы прийти с цифрами.

Заполнить бриф