Генератор Robots.txt и Sitemap.xml

Какие директивы используются в robots.txt?

Основные директивы определяют поискового робота и правила доступа к конкретным путям. Для большинства сайтов используются User-agent, Disallow, Allow и Sitemap. Их достаточно, чтобы создать понятную базовую конфигурацию и указать поисковой системе адрес XML карты сайта.

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

Перед публикацией полезно проверить несколько URL каждого типа. Такой подход быстрее выявляет конфликт между правилами robots.txt, canonical, noindex и фактической структурой сайта.

User-agent

User-agent определяет, к какому роботу относятся расположенные ниже правила. Значение * означает, что группа инструкций предназначена для всех краулеров, которые поддерживают стандарт robots.txt.

Пример базовой записи:

User-agent: *

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

При каждой технической правке нужно учитывать порядок и область действия правил. Если сайт использует отдельные настройки для Googlebot, других поисковых роботов или AI-ботов, их следует проверять отдельно.

Disallow

Disallow указывает путь, который выбранному краулеру не следует сканировать. Например, через эту директиву можно закрыть внутренний поиск, технические параметры или административный раздел, если они доступны по публичным URL.

Пример:

Disallow: /admin/

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

Если задача состоит именно в удалении страницы из поиска, нужно отдельно проверить возможность сканирования и директиву noindex. Блокировка в robots.txt и запрет индексации решают разные технические задачи.

Allow

Allow помогает разрешить обход конкретного пути внутри более широкого запрещённого раздела. Такая настройка встречается на сайтах со сложной структурой, где общий шаблон URL нужно закрыть, но отдельные ресурсы внутри него должны оставаться доступными.

Использовать исключения следует только после проверки реальных адресов. Чем больше пересекающихся правил Allow и Disallow, тем труднее поддерживать конфигурацию при изменении шаблонов URL.

После внедрения стоит проверить несколько разрешённых и запрещённых адресов. Такой тест показывает, совпадает ли фактическое поведение с ожидаемой логикой robots.txt.

Sitemap

Директива Sitemap сообщает роботу абсолютный адрес XML карты сайта. Обычно она размещается в robots.txt отдельной строкой и содержит полный URL с протоколом и доменом.

Пример:

Sitemap: https://example.com/sitemap.xml

Для крупного проекта вместо одного файла может использоваться Sitemap Index, который содержит ссылки на несколько XML-карт. Такой вариант удобен для больших каталогов, разделения товаров, категорий, статей или языковых версий.

После изменения адреса карты сайта нужно обновить robots.txt и данные в Google Search Console. Старый путь не должен оставаться единственным источником информации о sitemap.

Чем Disallow отличается от noindex?

Disallow относится к сканированию: робот получает рекомендацию не загружать страницу по указанному пути. noindex относится к индексации и сообщает поисковой системе, что доступную для обхода страницу не следует сохранять в поисковом индексе.

Если URL уже известен Google через внешние ссылки, внутреннюю перелинковку или старый sitemap, одного запрета в robots.txt может оказаться недостаточно для удаления адреса из выдачи. Робот видит сам URL, но не всегда может загрузить страницу и прочитать Meta Robots.

Поэтому сначала нужно определить задачу: сократить ненужный обход или убрать страницу из поиска. После этого выбираются robots.txt, Meta Robots, X-Robots-Tag, удаление URL, редирект или другой подход.

Что такое Sitemap XML и зачем нужна карта сайта?

Sitemap.xml содержит список URL, которые владелец сайта считает актуальными и доступными для поисковой обработки. Файл помогает поисковому роботу находить страницы без необходимости ждать, пока он обнаружит каждую из них через обычную внутреннюю перелинковку.

XML карта особенно полезна на новом сайте, где поисковая система ещё не знает большинство адресов. Она также нужна большим интернет-магазинам, каталогам, новостным проектам и сайтам с регулярно появляющимися страницами.

Для небольшого сайта sitemap тоже полезен как технический источник контроля. По нему легко сравнить список передаваемых URL с фактическими индексируемыми страницами, каноническими адресами и данными Google Search Console.

Какие данные содержит sitemap.xml?

Основная запись sitemap.xml содержит адрес страницы в теге loc. Дополнительно можно передавать lastmod, если сайт способен указывать реальную дату существенного изменения документа. Для Google именно эти данные имеют практический смысл при стандартной работе с XML Sitemap.

Поля changefreq и priority по-прежнему встречаются в старых генераторах и входят в исторически сложившийся формат Sitemap, однако Google их игнорирует. Добавлять их ради SEO или настраивать для каждой страницы нет необходимости. Это прямо указано в актуальной документации Google Search Central.

Актуальная базовая структура выглядит так:

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

loc

loc содержит абсолютный адрес страницы, включая протокол и домен. Для рабочего сайта желательно использовать канонический HTTPS-вариант без промежуточного редиректа и без лишних GET-параметров, если они не образуют самостоятельные индексируемые страницы.

В sitemap не следует смешивать HTTP и HTTPS, www и non-www версии одного сайта без реальной необходимости. Такая структура создаёт лишние URL и усложняет понимание основной версии страниц.

Google рекомендует указывать полностью квалифицированные абсолютные URL и включать в sitemap адреса, которые владелец хочет видеть в поиске. Для дублирующихся страниц предпочтительно передавать выбранную каноническую версию.

lastmod

lastmod показывает дату последнего существенного изменения страницы. Это может быть обновление основного текста, структурированных данных, ссылок, товара, характеристик или другой части документа, которая действительно изменила его содержание.

Не стоит ежедневно менять lastmod автоматически у всех URL, если страницы фактически не обновлялись. Google использует этот тег, когда данные остаются точными и могут быть проверены по реальным изменениям страницы.

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

Какие страницы нужно добавлять в Sitemap?

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

Каждый URL желательно проверять по нескольким признакам: ответ 200 OK, self-canonical, отсутствие noindex, доступность для обхода и соответствие основной версии домена. Такой подход делает sitemap полезным техническим источником, а не простым перечнем всех адресов CMS.

Для крупных сайтов список лучше формировать автоматически по единым правилам. Ручное обновление тысяч URL быстро приводит к устаревшим адресам и ошибкам.

Какие URL стоит включать?

В sitemap обычно входят канонические страницы, доступные для индексации и возвращающие корректный ответ сервера. Для интернет-магазина это могут быть основные категории, индексируемые подкатегории, товары и полезные информационные материалы.

Проверять стоит следующие характеристики:

• URL возвращает код 200 OK и открывается без промежуточного редиректа;
• страница имеет корректный canonical и не ссылается канонически на другой документ;
• Meta Robots или X-Robots-Tag не содержит запрета noindex;
• страница доступна для поискового робота и соответствует основной версии домена;
• URL нужен пользователям и имеет понятную роль в структуре сайта.

После формирования списка полезно сравнить его с краулингом сайта. Так можно обнаружить страницы, которые есть в sitemap, но отсутствуют во внутренней перелинковке.

Какие URL не нужно добавлять?

В карту сайта обычно не включают страницы с 301 или 302 редиректом, ошибки 404, noindex, технические дубли и URL с canonical на другой адрес. Не стоит передавать поисковой системе заведомо ненужные комбинации фильтров, сортировки и внутренних параметров.

Чаще всего исключаются:

• старые URL, которые перенаправляются на актуальные страницы;
• страницы поиска, корзины, авторизации и личного кабинета;
• технические фильтры и сортировки без отдельного поискового спроса;
• неканонические версии адресов, создающие дубли страниц;
• тестовые или закрытые материалы, которые не предназначены для органического поиска.

После удаления лишних адресов необходимо проверить внутренние ссылки. Если технический URL продолжает массово встречаться на сайте, одной очистки sitemap недостаточно.

Ограничения Sitemap XML

Один XML-файл не предназначен для хранения неограниченного количества страниц. Для стандартного sitemap действуют технические ограничения по количеству URL и размеру файла, поэтому крупные проекты используют несколько карт и отдельный Sitemap Index.

Ограничение важно учитывать ещё при проектировании генерации. Если интернет-магазин содержит сотни тысяч товаров, категорий и других индексируемых документов, один файл быстро перестанет соответствовать требованиям формата.

Практичнее разделять карты логически. Такой подход упрощает диагностику и помогает быстрее определить, в каком типе страниц появились ошибки.

Сколько URL можно добавить в один sitemap.xml?

Один sitemap.xml может содержать до 50 000 URL, а размер несжатого файла не должен превышать 50 МБ. Если достигается любое из этих ограничений, список необходимо разделить на несколько файлов. Эти ограничения сохраняются в актуальной документации Google.

Для большинства корпоративных сайтов такой предел недостижим. Ограничение становится актуальным для крупных маркетплейсов, интернет-магазинов, СМИ, агрегаторов и проектов с большим количеством динамических страниц.

Следить следует одновременно за числом URL и размером файла. Большие записи с дополнительными данными могут достичь лимита размера раньше, чем количество адресов достигнет 50 000.

Что делать, если страниц больше 50 000?

Если индексируемых страниц больше установленного лимита, создаются несколько sitemap.xml и Sitemap Index. Индексный файл содержит адреса отдельных карт, которые поисковая система затем обрабатывает отдельно.

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

Упрощённая схема выглядит так:

Sitemap Index → sitemap-products.xml → sitemap-categories.xml → sitemap-blog.xml → отдельные индексируемые URL.

При автоматической генерации нужно контролировать актуальность всех дочерних файлов. Удалённые карты не должны оставаться в Sitemap Index.

Куда загрузить robots.txt и sitemap.xml?

После генерации оба файла нужно разместить на доступных поисковому роботу адресах. Для стандартной конфигурации robots.txt находится в корне хоста, а sitemap.xml обычно размещают на основном домене по постоянному URL.

После загрузки файлы следует открыть в браузере и проверить ответ сервера. Поисковый робот должен получать содержимое без авторизации, ошибки 404, циклического редиректа или блокировки защитными системами.

Если сайт использует CDN, WAF или сложную серверную конфигурацию, дополнительно проверьте доступ для Googlebot. Иногда файл существует, но отдельные правила безопасности мешают его нормальному получению.

Где должен находиться robots.txt?

Для основного домена стандартный адрес выглядит так: https://example.com/robots.txt. Файл относится к конкретному хосту, поэтому правила главного домена автоматически не заменяют отдельный robots.txt для другого поддомена.

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

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

Где должен находиться sitemap.xml?

Типичный адрес XML карты сайта выглядит как https://example.com/sitemap.xml. Название может отличаться, если CMS создаёт несколько карт или Sitemap Index, однако используемый путь должен оставаться доступным и стабильным.

Если карта разбита на несколько файлов, нужно проверить каждый из них. В Sitemap Index не должны оставаться ссылки на удалённые или недоступные документы.

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

Как связать robots.txt с sitemap.xml?

В robots.txt добавляют отдельную директиву с полным адресом карты сайта:

Sitemap: https://example.com/sitemap.xml

Если используется Sitemap Index, лучше указать адрес индексного файла. Google, Bing и другие крупные поисковые системы поддерживают поле Sitemap в robots.txt. Адрес должен быть абсолютным, включая протокол и хост.

После изменения домена или протокола нужно проверить эту строку отдельно. Старый адрес sitemap в robots.txt часто остаётся незамеченным после миграции сайта.

Как добавить Sitemap в Google Search Console?

После публикации карты откройте нужный ресурс Google Search Console и добавьте актуальный URL sitemap в соответствующий раздел. Система обработает файл и покажет статус, обнаруженные страницы и возможные ошибки.

Наличие карты в robots.txt не мешает отдельно отправить её через Search Console. Панель удобна для диагностики, потому что показывает проблемы обработки и помогает отслеживать изменения после обновления структуры.

Не нужно отправлять один и тот же неизменённый sitemap многократно. Google отдельно рекомендует не пересылать один файл несколько раз в день без изменений.

Как проверить robots.txt и sitemap.xml после генерации?

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

Проверять лучше не только сами файлы, но и страницы, которых касаются их правила. Это помогает обнаружить расхождения между robots.txt, sitemap.xml, Meta Robots, canonical и реальными HTTP-ответами.

Для крупного проекта полезно автоматизировать такую проверку. Изменения структуры, CMS и шаблонов способны постепенно нарушить первоначально корректную конфигурацию.

Проверка robots.txt

Сначала убедитесь, что файл открывается по ожидаемому адресу и содержит актуальную версию правил. Затем проверьте главную страницу, основные категории, товары, услуги, статьи и технические разделы.

Особое внимание нужно уделить слишком широким запретам. Disallow: / закрывает обход сайта для соответствующего User-agent, а неточная маска способна затронуть больше URL, чем планировалось.

Дополнительно проверьте директиву Sitemap и доступность важных ресурсов. Если для отрисовки страницы нужны CSS или JavaScript, их случайная блокировка может ухудшить понимание страницы поисковым роботом.

Проверка sitemap.xml

В sitemap нужно проверить HTTP-статусы, canonical, noindex, редиректы, дубли и соответствие основной версии домена. Ошибки особенно заметны после миграций, массового изменения URL и переработки структуры каталога.

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

Также проверьте корректность XML и точность lastmod, если этот тег используется. Неверная дата, повреждённая разметка или недоступные дочерние карты способны снижать качество технических сигналов.

Нужно ли блокировать AI-ботов в robots.txt?

Некоторые владельцы сайтов отдельно задают правила для GPTBot, Google-Extended, ClaudeBot и других роботов ИИ. Решение зависит от того, хочет ли владелец разрешать таким системам получение контента и какие требования действуют для конкретного проекта.

Правила можно добавить отдельными группами User-agent. Перед этим желательно проверить актуальное название робота и официальную документацию соответствующего сервиса, потому что перечень AI-ботов и их назначение меняются.

Robots.txt работает как стандарт, который добросовестные краулеры добровольно соблюдают. Если требуется технически запретить доступ определённым клиентам, дополнительно применяются серверные ограничения, WAF, анализ запросов и другие механизмы контроля.

Для SEO не стоит массово блокировать неизвестных роботов без анализа. Некоторые краулеры связаны с поисковыми сервисами, мониторингом или инструментами, которыми владелец сайта пользуется сам.

Укажите домен, настройте правила обхода и создайте готовые robots.txt и sitemap.xml для вашего сайта.