Шість років у цифрах
Генератор Robots.txt та Sitemap.xml онлайн
Генератор robots.txt та sitemap.xml підходить для запуску нового сайту, перенесення на інший домен, зміни структури, додавання розділів та планової технічної перевірки. Готовий файл можна перевірити перед публікацією, завантажити, розмістити на сайті, а потім передати sitemap в Google Search Console.
Правильне налаштування не зводиться до створення двох файлів. Потрібно перевірити, які сторінки дозволені для обходу, які URL-адреси потрапили в XML карту сайту, чи немає серед них редиректів, помилок, дублів, noindex і неканонічних адрес.
Онлайн-генератор допомагає підготувати основні технічні файли без написання ручного директив і XML-розмітки. Користувач вказує домен, визначає правила доступу для пошукових роботів, додає потрібні URL і отримує готовий вміст robots.txt і sitemap.xml для подальшої перевірки.
Інструмент підходить для корпоративних сайтів, інтернет-магазинів, блогів, каталогів, сайтів послуг та невеликих проєктів. Після генерації файли необхідно перевірити з урахуванням реальної структури сайту, тому що автоматичне налаштування не знає бізнес-цінність кожної сторінки та її роль у пошуковому просуванні.
Схема роботи виглядає так:
Пошуковий робот → robots.txt → правила обходу → sitemap.xml → список URL → сканування сторінки → рішення пошукової системи про індексацію.
Ця послідовність допомагає зрозуміти основну різницю між файлами. Robots.txt регулює доступ краулерів, тоді як XML карта сайту передає список адрес, які пошукова система може виявити та обробити.
Що створює генератор robots.txt?
Генератор robots.txt формує текстовий файл із інструкціями для пошукових роботів. У ньому можна визначити, які розділи дозволено для обходу, які технічні шляхи бажано виключити та де знаходиться мапа сайту. Стандартна адреса файлу для основного домену виглядає як https://example.com/robots.txt.
Після створення файл слід перевірити вручну, особливо якщо сайт вже працює і отримує органічний трафік. Помилкова директива Disallow: / здатна закрити весь сайт від сканування, тому перенесення правил з тестового домену на робітник без перевірки створює серйозний ризик для індексації.
Для більшості сайтів достатньо кількох зрозумілих правил. Чим складніша структура інтернет-магазину, каталогу або мультимовного проєкту, тим уважніше потрібно перевіряти фільтри, параметри URL, службові сторінки та різні версії адрес.
Що створює генератор sitemap.xml?
Генератор sitemap формує XML карту сайту зі списком сторінок, які слід передати пошуковій системі для виявлення та обходу. У sitemap.xml бажано включати канонічні URL-адреси з відповіддю 200 OK, відкриті для індексації і доступні за основною версією домену.
Наявність сторінки в sitemap.xml не гарантує її індексацію та не впливає безпосередньо на позиції. Google самостійно оцінює вміст сторінки, canonical, Meta Robots, X-Robots-Tag, внутрішні посилання, HTTP-відповідь та інші сигнали перед тим, як залишити URL-адресу в індексі.
Карта особливо корисна для нових сайтів, великих каталогів, інтернет-магазинів та проєктів із глибокою структурою. Вона також допомагає швидше виявляти сторінки, на які поки що веде мало внутрішніх посилань, хоча нормальну перелінковку sitemap замінити не може.
Що входить
Генератор robots.txt
Генератор robots.txt онлайн для налаштування User-agent, Allow, Disallow та Sitemap. Створіть файл, перевірте правила та скачайте готовий robots.txt безкоштовно.
Генератор sitemap.xml
Генератор sitemap.xml для створення XML-карти вебсайту онлайн. Вкажіть URL, отримайте готовий файл Sitemap і додайте його до robots.txt та Google Search Console.
Часті помилки при налаштуванні Robots та Sitemap
Більшість проблем виникає після міграцій, зміни структури або автоматичного створення URL. Файли продовжують технічно працювати, але починають утримувати старі адреси, забороняти корисні розділи або передавати пошуковику сторінки, які вже не призначені для індексації.
Помилки краще шукати за шаблонами, а не за адресою. Якщо один фільтр потрапив у sitemap, ймовірно, аналогічна проблема є у всіх URL цього типу.
Регулярна перевірка особливо потрібна інтернет-магазинам та іншим динамічним проєктам. Їхня структура змінюється частіше, тому початкове налаштування поступово застаріває.
Випадкове блокування всього сайту
Найнебезпечніша помилка в robots.txt – директива Disallow: / для спільного User-agent на робочому домені. Вона часто залишається після перенесення проєкту з тестового середовища, де повна заборона сканування була виправдана.
Перед релізом потрібно окремо перевірити robots.txt через публічний домен. Перевірка локального файлу в репозиторії не гарантує, що сервер дає ту саму версію.
Після виправлення варто перевірити доступність основних сторінок та стан сайту в Google Search Console. Пошуковому роботу буде потрібно деякий час, щоб отримати оновлені правила та повторно обробити URL-адресу.
Додавання закритих сторінок до sitemap.xml
Карта сайту не повинна системно містити URL-адреси, які власник одночасно закриває від обходу без зрозумілої причини. Така конфігурація передає пошуковій системі суперечливі сигнали та ускладнює технічну діагностику.
Якщо сторінка не потрібна у пошуку, слід визначити правильний спосіб її обробки. Це може бути неindex, видалення, редирект, авторизація або виняток з генерації sitemap.
Після зміни правил перевірте джерело формування XML. Інакше видалена вручну URL з'явиться знову при наступному автоматичному оновленні карти.
Додавання редиректів та сторінок 404
Sitemap повинен містити кінцеві робочі URL-адреси, а не старі адреси з 301, 302 або помилкою 404. Наявність великої кількості таких сторінок говорить про те, що карта сайту не синхронізована з актуальною структурою.
Після міграції старі URL слід видалити з XML та замінити новими канонічними адресами. Сам редирект може залишатися робітником для користувачів та зовнішніх посилань, але в sitemap він зазвичай не потрібен.
Те саме стосується віддалених сторінок. Якщо URL повертає 404 і більше не має існувати, регулярно передавати його через картку сайту безглуздо.
Додавання неканонічних URL
У sitemap бажано використовувати ту ж версію URL, яку сторінка вказує через canonical. Розбіжності часто виникають між HTTP та HTTPS, www та non-www, адресами зі слешем і без нього, а також URL з параметрами.
Якщо XML має системно неканонічні адреси, потрібно виправляти сам механізм генерації. Ручне очищення файлу вирішить проблему лише до наступного оновлення.
Google враховує присутність URL в sitemap як один із сигналів при виборі канонічної версії, хоча остаточна canonical пошукова система визначає самостійно.
Використання Sitemap замість внутрішньої перелінковки
XML карта допомагає пошуковій системі виявляти сторінки, але нормальна структура сайту все одно повинна пов'язувати важливі документи внутрішніми посиланнями. Якщо цінна посадкова сторінка існує тільки в sitemap, варто перевірити її місце в архітектурі.
Внутрішні посилання передають пошуковій роботі додатковий контекст, анкори та зв'язок між розділами. Вони також дозволяють користувачеві перейти на сторінку звичайним способом.
Сторінки-сироти слід аналізувати окремо. Іноді відсутність внутрішніх посилань випадково, інколи ж URL взагалі не повинен брати участь у пошуковому просуванні.
Некоректний lastmod
Дата lastmod повинна відображати реальне суттєве оновлення сторінки. Автоматичне призначення поточної дати для кожного URL-адреси при кожній генерації створює постійний потік змін, яких фактично не було.
Google використовує lastmod, якщо значення залишається точним і відповідає реальним змінам. Оновлення основного контенту, структурованих даних або значущих посилань вважається суттєвим, а проста зміна дати у футері – ні.
Якщо CMS не зберігає надійну дату, необов'язкове поле не можна використовувати. Неточний сигнал не робить sitemap якіснішим.
Я рекомендую розглядати robots.txt і sitemap.xml як пов'язані, але різні частини технічного налаштування сайту. Robots.txt керує доступом краулерів, а sitemap.xml передає список URL, які хочемо показати пошуковій системі. Перед публікацією я перевіряю код відповіді, canonical, Meta Robots та доступність кожного типу сторінок. У sitemap залишаю loc і, за наявності точної дати, lastmod. changefreq та priority для Google не налаштовую, оскільки пошукова система їх ігнорує.
Як користуватися генератором Robots та Sitemap?
Почніть із основної версії домену та перевірте, який протокол використовується на сайті. Після цього налаштуйте правила robots.txt, додайте потрібні URL-адреси в sitemap.xml і перегляньте результат перед завантаженням файлів.
Генератор скорочує ручну роботу, але не ухвалює SEO-рішення замість власника сайту. Потрібно заздалегідь розуміти, які сторінки призначені для органічного пошуку, а які стосуються технічних, дублюючих або закритих розділів.
Після створення перевірте вміст обох файлів разом. Sitemap не повинен передавати пошуковій системі адреси, які одночасно закриті правилами обходу без зрозумілих причин.
Вкажіть домен сайту
Введіть основну версію домену з протоколом HTTPS, якщо вона використовується як канонічна. Наприклад, для сайту https://example.com не варто одночасно генерувати адреси http://example.com або https://www.example.com, якщо вони перенаправляються на основний варіант.
Перевірте єдиний формат URL до формування XML картки сайту. Особливо часто дублі виникають через кінцевий слеш, регістр символів, GET-параметрів і різні версії одного домену.
Якщо проєкт є мультимовним або працює на декількох піддоменах, правила потрібно складати з урахуванням архітектури сайту. Кожен окремий хост може мати свій robots.txt.
Налаштуйте правила robots.txt
Визначте, які URL пошуковий робот повинен обходити, а які технічні розділи можна виключити. Для базового налаштування використовуються User-agent, Disallow, Allow та директива Sitemap з повною адресою карти сайту.
Чи не копіюйте robots.txt іншого проєкту без перевірки структури. Одночасні назви CMS або шаблонів не означають, що сайти мають фільтри, сторінки пошуку, службові розділи та правила індексування.
Після налаштування перевірте головну сторінку, категорії, товари, послуги та кілька технічних URL-адрес. Такий набір швидко показує, чи не зачепила заборона корисні посадкові сторінки.
Додати URL для sitemap.xml
Додайте сторінки, які доступні за канонічною адресою, повертають 200 OK і призначені для індексації. Для sitemap для сайту важливіша якість списку, ніж максимальна кількість URL.
Не слід додавати адреси автоматично лише тому, що CMS може їх виявити. Фільтри, внутрішній пошук, тестові сторінки, дублі та технічні параметри часто не повинні потрапляти до XML карти сайту.
Перед масовою генерацією корисно перевірити шаблони URL за типами. Це знижує ризик появи тисяч непотрібних адрес у великих каталогах.
Налаштуйте параметри Sitemap
Для кожного URL необхідно передати коректну абсолютну адресу через loc. Тег lastmod варто додавати тільки в тих випадках, коли система зберігає точну дату останньої істотної зміни сторінки.
Налаштувати changefreq та priority для Google не потрібно. Їх значення ігноруються, тому поля не впливають на частоту обходу, індексування чи позиції сторінки.
Якщо точної дати оновлення немає, краще залишити lastmod порожнім. Чиста XML карта сайту з правильними URL корисніша за файл з формально заповненими, але недостовірними технічними параметрами.
Згенеруйте та скачайте файли
Після налаштування сформуйте robots.txt і sitemap.xml, а потім перегляньте вміст перед публікацією. Перевірте домен, протокол, основні директиви, список URL-адрес та відсутність очевидних технічних сторінок.
Готові файли можна завантажити та розмістити на сервері. Після завантаження обов'язково відкрийте обидві адреси в браузері та переконайтеся, що сервер повертає файл без помилки, авторизації або несподіваного перенаправлення.
Потім додайте sitemap.xml до Google Search Console і слідкуйте за результатом обробки. Помилки звіту допомагають виявити недоступні, неканонічні або некоректно сформовані URL-адреси.
Відповіді на ваші запитання
Чи можна створити robots.txt та sitemap.xml онлайн безкоштовно?
Так, базовий robots.txt онлайн та sitemap.xml онлайн можна сформувати без окремого програмного забезпечення. Для невеликого сайту достатньо вказати домен, налаштувати правила доступу та додати канонічні сторінки, які мають знаходитись у XML карті сайту.
Після генерації потрібна технічна перевірка. Інструмент формує файл за заданими параметрами, але самостійно не визначає, які категорії, фільтри або службові сторінки потрібні конкретному проєкту.
Перед завантаженням перевірте домен, протокол та основні шаблони URL-адреси. Особливо уважно ставтеся до існуючих сайтів, де помилка здатна вплинути на вже проіндексовані сторінки.
Чи потрібний sitemap.xml невеликому сайту?
Для маленького сайту sitemap.xml не вважається обов'язковою умовою індексації, якщо всі сторінки доступні через зрозумілу внутрішню перелінковку. Пошуковий робот здатний виявити такі URL звичайним обходом сайту.
При цьому картка залишається зручним технічним джерелом. Через неї можна передати актуальні URL-адреси і потім контролювати обробку файлу в Google Search Console.
На новому сайті sitemap особливо корисний після запуску. Він допомагає швидше показати пошуковій системі структуру проєкту, хоча остаточне рішення про індексацію кожної URL залишається за пошуковою системою.
Скільки URL-адрес можна додати до sitemap.xml?
Один стандартний sitemap може містити до 50 000 URL-адрес при розмірі стисненого файлу до 50 МБ. Якщо досягається одне з обмежень, адреси необхідно розподілити між кількома картами.
Для великого сайту зазвичай створюють окремі sitemap за типами сторінок. Наприклад, товари, категорії та статті можна розмістити у різних XML-файлах.
Всі ці карти потім зв'язуються через Sitemap Index. Пошуковій системі достатньо отримати індексний файл, щоб виявити решту карт.
Чи можна додати декілька файлів Sitemap?
Так, кілька карток використовуються на великих і структурно складних сайтах. Такий підхід допомагає дотримуватись технічних лімітів та спрощує контроль окремих типів сторінок.
Кожен дочірній sitemap повинен бути доступним і містити актуальні канонічні URL. Видалені картки слід вчасно виключати з індексного файлу.
Поділ також зручний для діагностики. Якщо Google повідомляє про помилки лише у карті товарів, можна швидше знайти проблему у відповідному шаблоні генерації.
Чи потрібно додавати sitemap.xml до robots.txt?
Вказати sitemap.xml у robots.txt рекомендується, тому що пошуковий робот отримує пряму адресу картки при зверненні до файлу правил. Для цього використовується директива Sitemap з абсолютною URL-адресою.
Додатково карту можна надіслати через Google Search Console. Ці способи не конфліктують та використовуються одночасно на більшості сайтів.
Після зміни домену перевірте обидва місця. Після завершення міграції стара адреса часто залишається в robots.txt або панелі вебмайстра.
Чи потрібні changefreq та priority у sitemap.xml?
Для Google ці параметри не потрібні. Пошукова система ігнорує значення <changefreq> та <priority>, тому вони не впливають на частоту сканування, індексацію або ранжування сторінок.
В актуальному sitemap достатньо передавати коректну URL через <loc>. <lastmod> має сенс додавати тоді, коли сайт здатний вказувати точну дату останньої істотної зміни сторінки.
Якщо старий генератор продовжує створювати зміниfreq і priority, це само по собі не робить файл помилковим. Для сучасного SEO-налаштування Google витрачати час на керування цими значеннями немає сенсу.
Чи можна закрити сторінку від індексації через robots.txt?
Використовувати лише robots.txt для видалення сторінки з індексу не слід. Disallow забороняє або обмежує сканування, тому пошуковий робот може не отримати доступ до Meta Robots і не побачити директиву noindex.
Для заборони індексації зазвичай сторінка повинна залишатися доступною для роботи і містити відповідну директиву. Конкретна схема залежить від поточного стану URL та завдання власника сайту.
Якщо сторінка вже знаходиться в пошуку, потрібно перевірити причини її появи та спосіб видалення. Просте додавання шляху до Disallow може не дати очікуваного результату.
Чи потрібно додавати до Sitemap сторінки з noindex?
Звичайна XML карта сторінок, що індексуються, не повинна містити URL з noindex. Додавання такої адреси одночасно повідомляє пошукову систему про сторінку через sitemap і забороняє її індексацію іншим технічним сигналом.
Якщо noindex встановлено тимчасово, потрібно розуміти подальший сценарій. Після зняття обмеження сторінку можна повернути до автоматичної генерації sitemap.
При масовій появі noindex-сторінок у XML краще виправити правило генерації. Ручне видалення окремих URL-адрес не усуне причину.
Як часто оновлювати sitemap.xml?
Карту слід оновлювати після появи нових сторінок, що індексуються, видалення старих URL і істотної зміни структури сайту. На динамічних проєктах цей процес краще автоматизувати через CMS чи серверну генерацію.
Не потрібно перетворювати файл для зміни дати без реальних змін. Якщо використовується останнійmod, дата повинна відповідати останнім істотним змінам сторінки, а не часу чергової генерації sitemap.
Після великих міграцій sitemap перевіряється окремо. У ньому не повинні залишатися старий домен, колишній протокол, редиректи та віддалені сторінки.
Докладніше: Генератор Robots.txt та Sitemap.xml
Що таке robots.txt і навіщо він потрібний?
Robots.txt зберігає інструкції для краулерів, які вимагають сторінки та інші ресурси сайту. Пошуковий робот зазвичай звертається до цього файлу перед обходом і перевіряє правила, вказані для свого User-agent. Файл розташовується в корені відповідного хоста.
Через robots.txt можна обмежити сканування технічних розділів, параметрів, внутрішніх результатів пошуку та інших URL-адрес, які не повинні витрачати краулінговий бюджет. При цьому заборону сканування не можна вважати надійним способом видалення відомої сторінки з індексу.
На невеликому сайті файл часто містить лише кілька директив. Для великого інтернет-магазину правила можуть бути складнішими через фільтри, сортування, пошук, особистий кабінет, кошики та різні технічні параметри.
Які директиви використовуються у 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. Додатково можна передавати останнійmod, якщо сайт здатний вказувати реальну дату істотної зміни документа. Для Google саме ці дані мають практичне значення при стандартній роботі з XML Sitemap.
Поля changefreq і priority, як і раніше, зустрічаються в старих генераторах і входять в формат Sitemap, що історично склався, проте Google їх ігнорує. Додавати їх заради SEO або налаштовувати для кожної сторінки немає потреби. Це прямо вказано у актуальній документації Google Search Central.
Актуальна базова структура виглядає так:
| Тег | Що містить | Як використовувати |
|---|---|---|
| loc | Абсолютна URL-сторінка | Вказувати основну канонічну адресу |
| lastmod | Дату останньої суттєвої зміни | Передавати лише за наявності точних даних |
Для звичайного 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 для вашого сайту.
Генератор Robots і Sitemap допомагає підготувати два базові технічні файли і відразу перевірити їх спільну логіку. У robots.txt задаються правила обходу, а sitemap.xml передаються актуальні канонічні URL, які пошукова система може сканувати і оцінювати для індексації.
Для сучасного sitemap орієнтуйтесь на коректні URL-адреси та точний lastmod, якщо система дійсно знає дату істотної зміни сторінки. Налаштувати changefreq та priority для Google не потрібно, оскільки їх значення пошукова система ігнорує.
Перед публікацією перевірте Disallow, noindex, canonical, HTTP-статуси, редиректи та основну версію домену. Після завантаження відкрийте обидва файли на робочому сайті та надішліть актуальний sitemap.xml до Google Search Console.
Відповідаємо протягом робочого дня. Без розсилок і дзвінків «просто нагадати».
Подивиться сайт сам, а не передасть менеджеру.