Як перевірити robots.txt на заблоковані сторінки

Де має бути robots.txt

Він має лежати в корені хоста, як /robots.txt, у звичайному тексті UTF-8. Він застосовується рівно до однієї схеми, хоста й порту, тож https://example.com/robots.txt не керує нічим на https://shop.example.com і нічим на http-версії того самого хоста. Кожен піддомен, який ви хочете контролювати, потребує власного файлу.

Код статусу, який повертає файл, важливий не менше за його вміст. 404 читається як "жодних обмежень, скануй усе", і це цілком дійсний стан. Повторюваний 5xx читається як тимчасовий збій, і Google може призупинити сканування хоста замість того, щоб вважати, що можна продовжувати. 403 для цієї мети поводиться як помилка сервера. Якщо robots.txt ненадійний, сканування стає ненадійним разом із ним.

Синтаксис у п'яти рядках

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent відкриває групу. Disallow блокує префікс шляху, Allow вирізає виняток із блокування, * збігається з будь-яким набором символів, а $ прив'язує кінець URL. Sitemap незалежний від будь-якої групи й приймає абсолютний URL. Формат стандартизований як RFC 9309, тож описана тут поведінка не специфічна для якогось конкретного постачальника.

Два правила визначення розв'язують, що насправді відбувається. Краулер використовує лише найконкретнішу групу, що його називає, і повністю ігнорує групу *, щойно якась група називає його напряму. Всередині цієї групи перемагає найдовше правило, що збігається, а нічия йде на користь Allow.

Помилки, що блокують увесь сайт

• Disallow: /, що лишився від деплою на стейджингу. Один символ - і заблоковано весь сайт. Це потрапляє в продакшн точно так само, як і noindex на стейджингу: файл конфігурації, піднятий разом із релізом.
• Блокування CSS і JavaScript. Google рендерить сторінки, тож заблокована директорія ресурсів може змусити сторінку виглядати зламаною для краулера, тоді як вам вона видається нормальною.
• Очікування, що robots.txt прибере сторінку з пошуку. Він на це не здатний. Заблокований URL усе одно може бути перелічений через зовнішні посилання, зазвичай без сніпета, і оскільки краулер не може його отримати, noindex на цій сторінці ніколи не буде побачений. Щоб прибрати сторінку, дозвольте сканування і віддавайте noindex.
• Використання noindex: як директиви всередині robots.txt. Це ніколи не було частиною стандарту, і Google перестав це враховувати 1 вересня 2019 року. Сьогодні це мовчки ігнорується.
• Додавання групи для конкретного бота з очікуванням, що правила з вайлдкардом усе одно застосовуватимуться. Ні. Щойно з'являється User-agent: Googlebot, Googlebot читає лише цю групу і нічого більше, тож кожне спільне правило доводиться повторювати в ній.
• Порожній рядок усередині групи. Порожній рядок завершує групу, тож правила після нього не належать нікому, доки не з'явиться наступний рядок User-agent.
• Перелічення приватних шляхів. Файл публічний. Назвати в ньому /internal-admin/ означає опублікувати розташування того, що ви намагаєтеся приховати.

Як протестувати окремий шлях

Отримайте файл і спершу прочитайте групу, що застосовується до вас:

curl -s https://example.com/robots.txt

Тоді застосуйте правило найдовшого збігу вручну до шляху, що вас цікавить. З Disallow: /blog/ і Allow: /blog/public/ URL /blog/public/post дозволений, бо правило Allow, що збігається, довше. Для власності, якою ви володієте, звіт robots.txt у Search Console показує отриманий файл, коли його востаннє забирали, і будь-які помилки розбору, що є найшвидшим способом підтвердити, що краулер читає саме те, що, на вашу думку, він читає.

Підтвердьте, що він досяжний звідусіль

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

Спосіб це побачити - запросити файл з місця, яке не є вашим офісом. Спрямуйте безкоштовний інструмент HTTP-перевірки на https://example.com/robots.txt і прочитайте код статусу, повернутий із контрольних точок у різних країнах. 200 усюди - здорова відповідь; 200 удома і 403 з трьох регіонів - це вже знахідка. Щоб перевірити, чи правила блокують конкретну сторінку, безкоштовний тестер robots.txt перевіряє URL за групою для всіх краулерів і звітує, чи він перелічений у карті сайту. Robots.txt живе поза сторінкою, тож опція Indexability в HTTP-моніторі HostTracker його не читає: вона стежить за тегами noindex і canonical на самій сторінці, тоді як заплановане сканування, у бета-версії, звіряє кожну просканьовану сторінку з robots.txt. SEO-моніторинг пояснює, що з цього що охоплює.