robots.txt і карти сайту

Дозвіл — це не те саме, що виключення

robots.txt відмовляє в дозволі завантажити адресу, і не більше. Google прямо каже, що це не механізм тримати сторінку поза пошуком. Ці дві думки постійно зливають в одну, і саме таке злиття породжує цілком конкретну, добре помітну поломку.

Заблокована адреса, на яку посилаються інші сайти, все одно може потрапити в індекс. Google знає, що адреса існує, бо хтось на неї послався; він просто не бачить, що на ній. Тож адреса може з'явитися взагалі без опису — найгірше з обох світів, адже сторінка публічно стоїть у результатах, а ви не керуєте тим, як вона виглядає.

Як читати й писати цей файл

Файл лежить у корені хоста і стосується лише цього хоста та цього протоколу. Правила згруповані за user-agent, і сканер виконує одну, найточніше дібрану для нього групу — а не кожну, під яку він міг би підпасти. Всередині групи Google розв'язує конфлікти конкретнішим правилом, а не порядком рядків.

User-agent: *
Disallow: /admin/
Disallow: /*.pdf$
Allow: /admin/public/

User-agent: Googlebot
Disallow: /drafts/

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

Дві деталі цього прикладу тримають майже всю плутанину. Рядок Allow конкретніший за Disallow над ним, тож /admin/public/ лишається доступним. А щойно з'являється група Googlebot, Googlebot виконує лише її — група із зірочкою його вже не стосується, тому тут /admin/ для Googlebot доступний. Це майже ніколи не те, що мав на увазі автор.

• Блокування шляху не прибирає вже проіндексовані адреси, а лише спиняє майбутні завантаження.
• Директива Sitemap не залежить від жодної групи user-agent і може стояти в будь-якому місці файлу.
• Помилка 5xx на самому robots.txt може змусити сканер відступити від усього хоста, тож віддавайте його з чогось надійного.

Де правило robots шкодить далеко від себе

Найдорожчі помилки в robots.txt — це не сторінки, які ви хотіли заблокувати. Це ресурси, потрібні сторінці, щоб відрендеритися. Пошукові системи рендерять сторінки перед індексацією, а рендеринг тягне скрипти, стилі та відповіді API.

Заблокуйте шлях зі скриптами чи маршрут API — і сканер усе одно чудово завантажить HTML. Далі він відрендерить майже порожню сторінку і проіндексує майже порожню сторінку. Жоден звіт не скаже, що сторінку заблоковано, бо сторінку й не блокували — заблоковано лише те, що їй було потрібно.

Карта сайту — пропозиція, а не черга

Карти допомагають знаходженню саме там, де перелінковка найслабша: великі сайти, зовсім нові сайти з небагатьма вхідними посиланнями та сайти, насичені медіа без природного тексту посилання. Google каже без манівців: перелічена адреса не гарантує ні сканування, ні індексації.

Власна настанова Google — що менший, добре перелінкований сайт може не потребувати карти взагалі, бо сканер знайде все, ідучи за посиланнями. Це варто взяти до уваги, перш ніж будувати інфраструктуру карт заради проблеми, яку краще розв'яже внутрішня перелінковка.

Які теги читаються, ігноруються або викликають недовіру

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

Кусається саме умова щодо lastmod. Якщо ваша збірка штампує кожну адресу часом розгортання, кожне значення водночас хибне й легко спростовне: сторінка не змінилася, і пошукова система це бачить. Щойно вона перестає довіряти полю, вона перестає його використовувати, і це залишає вас у гіршому становищі, ніж якби ви не надсилали lastmod узагалі. Видавайте його лише на справжні зміни основного вмісту й радше пропустіть, ніж вигадуйте.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/guides/indexing/</loc>
    <lastmod>2026-06-14</lastmod>
  </url>
</urlset>

Вибір правильного інструмента

Майже кожне питання в цій царині розв'язується, щойно ви розділите три роботи, які здаються схожими, а такими не є.