Привожу техническую часть сайта на Bitrix в порядок для поисковых систем: проверяю canonical, title, description, Open Graph, sitemap.xml, robots.txt, редиректы, 404, дубли, микроразметку и сигналы, которые мешают важным страницам индексироваться.
В эту услугу входят диагностика и исправление технических причин: неверных адресов, запретов индексации, дублей и ошибок генерации страниц. Для каждой правки фиксирую исходный ответ и результат повторной проверки.
Можно делать отдельно или вместе с аудитом, ускорением и доработками шаблона.
На сайтах на Bitrix часто встречается одна и та же картина: страница существует, но поисковик видит не ее, а дубль, родительский раздел или URL без нормального контента. Причина может быть в шаблоне компонента, настройках ЧПУ, canonical, автогенерации мета-тегов, sitemap или старых редиректах.
Такие ошибки не всегда заметны владельцу сайта. В браузере все открывается, но в индексе появляется не та страница, сниппет подтягивает общий title, карточка не попадает в карту сайта, а параметры или технические URL создают лишний шум.
MAX
index.php, параметры, http/https, www, страницы фильтров, пагинацию и технические URL.lastmod, отсутствие мусорных страниц и конфликтующих запретов.В Bitrix SEO часто завязано не на одну настройку, а на связку инфоблоков, компонентов и шаблонов. Например, общий раздел может раньше текущей страницы задавать meta и Open Graph, детальная страница может наследовать canonical родителя, а sitemap — не учитывать новые элементы из-за настроек генерации.
Поэтому я смотрю не только результат в HTML, но и место, где он формируется: параметры компонента, шаблон, result_modifier.php, component_epilog.php, свойства инфоблока, наследуемые SEO-шаблоны и правила в .htaccess. Это позволяет исправить причину, а не вручную проставить несколько тегов на одной странице.
Сначала собираю список важных URL и смотрю публичный HTML: коды ответа, canonical, мета-теги, микроразметку, дубли, редиректы и карту сайта. Затем проверяю Bitrix-часть, где эти сигналы формируются, и составляю список правок.
После внесения изменений очищаю кеш и проверяю результат снаружи: страница должна отдавать 200, canonical должен вести на себя или на правильную целевую страницу, title и description должны соответствовать интенту, а sitemap и robots не должны конфликтовать с нужной индексацией.
На выходе важные страницы дают поисковикам однозначные сигналы: какая версия URL главная, какие страницы нужно индексировать, где находится карта сайта, какие данные использовать для сниппета и как связаны услуги, статьи, кейсы и хлебные крошки.
Если перед техническим SEO есть сомнения в состоянии проекта, можно начать с аудита сайта на 1С-Битрикс. Если проблемы связаны со скоростью, рядом обычно нужна оптимизация производительности. Если после диагностики нужны изменения в компонентах, это уже разработка на 1С-Битрикс.
При проверке df7.ru 5 сентября 2026 года в карте сайта нашлась страница /500.html. Она содержала сообщение об ошибке окружения, но по прямому адресу отвечала 200 и не имела запрета индексации. При этом Вебмастер не показывал ошибок обработки Sitemap: XML был корректным, проблема была в составе адресов.
Для исправления нужны два уровня. В настройках генератора Битрикса служебные файлы исключаются из обхода, затем существующая карта очищается от такого URL. На сервере шаблоны ошибок остаются доступны внутреннему обработчику, а прямые запросы к ним получают 404 и noindex.
Приёмка включает повторную генерацию карты, проверку конечного XML и ответов сервера. Если удалить только строку из готового файла, следующий запуск генератора может вернуть её обратно. Этот пример показывает, зачем проверять настройки источника и опубликованный результат вместе.
Если страница не попадает в поиск, сначала нужно понять, видит ли ее поисковик технически. Проверяю код ответа, canonical, robots, sitemap, title, description, дубли URL, мобильную доступность и последние события в Вебмастере. Если все сигналы корректные, проблема может быть уже не в технике, а в слабом или слишком похожем содержании страницы.
Такой разбор помогает не чинить несуществующую ошибку. Например, страница может отдавать 200, быть в sitemap и иметь self-canonical, но при этом отсутствовать в поиске. Пересечение с соседней услугой — одна из гипотез, которую нужно проверить по содержанию и запросам; код 200 сам по себе не объясняет решение Яндекса. Тогда нужна доработка контента, перелинковки и позиционирования, а не правка robots.txt.
После технических правок важно дождаться нового обхода и сравнить данные: дата обхода, статус URL, события APPEARED_IN_SEARCH или REMOVED_FROM_SEARCH, количество страниц в поиске, ошибки sitemap и выборку исключенных URL. Без этого легко принять старый статус за актуальную проблему.
Для df7.ru я обычно сверяю sitemap, публичный HTML и Яндекс.Вебмастер вместе: так видно, где страница действительно закрыта, где поисковик еще не дошел, а где нужна работа с содержанием. Если после диагностики выясняется, что проблема не техническая, дальше полезнее усилить страницу услуги или статью, чем продолжать менять настройки.
Если адрес закрыт ошибочным noindex, неправильным canonical или недоступен роботу, исправляется конкретная настройка. Если технических препятствий нет, а страница не отвечает самостоятельному запросу, нужна работа с содержанием и предложением. Статус «малоценная или маловостребованная» сам по себе не означает ограничений всего сайта — это поясняется в справке Яндекса.
Для магазина с несколькими типами страниц, как в OFFO, проверяю отдельно категорию, товар и информационный раздел. Исправление одного шаблона не подтверждает состояние остальных. Самостоятельную первичную проверку можно начать со статьи почему страницы Битрикса не попадают в поиск.
В задачах на Битриксе важно сразу уточнить, о каком поиске идёт речь. Если URL не появляется в Яндексе или Google, проверяются индексация, canonical, sitemap, robots.txt и дубли. Если тот же материал не находится в строке поиска самого сайта, нужна диагностика внутреннего поискового индекса.
Переобход в Вебмастере не исправит настройки компонента search.page, а полная переиндексация модуля поиска не устранит ошибочный canonical. Разделение этих цепочек экономит время и позволяет проверять результат в правильном инструменте.
Нет. Техническое SEO убирает препятствия для индексации и корректного обхода. Для роста позиций также нужны сильные посадочные страницы, контент, перелинковка и внешние сигналы.
Да, если она четко диагностирована: например, неправильный canonical, дубли Open Graph, index.php без редиректа или ошибка в sitemap. Но часто одна проблема тянет за собой соседние, поэтому лучше проверить цепочку целиком.
Для поверхностной проверки достаточно публичного URL. Для исправлений обычно нужны доступ в Bitrix и файлы проекта, потому что SEO-сигналы часто формируются в шаблонах компонентов.
Оставьте контакты, и я свяжусь с вами.