ШІ-краулери та короткі посилання: що насправді роблять боти

До ваших посилань звертаються три різні типи автоматизованих агентів, і кожному з них потрібне своє. Один збирає текст для навчання моделі. Інший отримує сторінку прямо зараз, бо людина поставила запитання. Третій будує пошуковий індекс. Вони приходять із різними user agent, дотримуються різних правил і заслуговують на різні відповіді.

Домен для редиректів - незвичне місце, куди їх спрямовувати, адже там немає контенту. Кожен запит - це лише пошук і заголовок Location, тож краулер для навчання не отримує нічого корисного, а фетчер у реальному часі отримує лише один зайвий перехід на шляху до сторінки, яку хотів. Саме ця асиметрія робить рішення щодо політики простим, щойно ви розділите класи агентів. Якщо вас цікавить маркетинговий бік питання, а не технічна механіка, оптимізація відповідей (AEO) розповідає, що насправді змушує сторінку бути процитованою.

Три класи, а не один

Краулери для навчання. Вони збирають контент для навчання моделей. OpenAI документує своїх ботів з окремим user agent для кожного завдання, а Anthropic документує свій краулер і правила, яких він дотримується, у тому ж дусі. Google вирішує еквівалентну задачу через токен robots, а не через окремий краулер, що описано в його огляді краулерів поруч із пошуковими агентами.

Фетчери в реальному часі. Вони спрацьовують, коли людина запитує щось в асистента, і асистент вирішує прочитати сторінку. Perplexity явно документує цей розподіл: один агент для індексування, інший - для запиту, ініційованого користувачем. Ця відмінність важливіша за будь-який інший момент у цій статті: фетч у реальному часі - це людина, лише на один крок віддалена.

Пошукові індексатори. Найстаріший клас, і той, чия поведінка щодо редиректів вивчена найкраще. Вони йдуть за постійним редиректом, приписують контент цільовій сторінці й трактують короткий домен як вказівник.

Та сама інфраструктура, три різні цілі. Універсальне правило для всіх них майже завжди є хибним рішенням.

Що відбувається, коли один з них звертається до редиректу

Механіка тут нічим не примітна. Агент запитує коротку URL-адресу, редирект відповідає кодом 301 або 302 і заголовком Location, і агент переходить за ним, якщо взагалі переходить за редиректами. HTTP-семантика редиректів для цього не змінювалася, і жодної спеціальної обробки для ШІ-агентів у стандарті немає.

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

Найчастіша помилка - те, на якому хості діють правила. RFC 9309 визначає robots.txt як прив'язаний до повноваження (authority): схема, хост і порт. Правила на example.com/robots.txt керують лише example.com і нічим більше. Ваш домен для редиректів - це інший хост, тому йому потрібен власний файл, який віддає той сервіс, що відповідає на цьому хості. Чимало коротких доменів взагалі не віддають robots.txt, а агенти трактують це як відсутність обмежень.

Що це робить із вашими лічильниками кліків

Автоматизований трафік - це передусім проблема вимірювання, а вже потім проблема політики.

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

Elido відкидає відомих автоматизованих агентів до того, як клік буде записано, а не після, тож панель показує людей. Це та поведінка, якої варто прагнути, і її варто перевірити в будь-якому інструменті, яким ви користуєтеся, бо сирий лічильник сприймає хвилю краулерів як сплеск трафіку. Аналітика коротких посилань: що вимірювати охоплює різницю між відфільтрованими та сирими даними, а кліки проти сеансів GA4 розповідає, з чого складається залишковий розрив.

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

Що вказати в robots.txt на домені для редиректів

Коротка, обґрунтована позиція для хоста, призначеного лише для редиректів.

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

Рішення щодо краулерів для навчання приймайте з принципу, а не з розрахунку на ефект, адже на домені для редиректів немає нічого, на чому можна навчати модель. Якщо у вашої організації є позиція щодо навчання моделей, застосуйте її й тут заради послідовності - і не очікуйте вимірних змін у жодному з варіантів.

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

І пам'ятайте, чого robots.txt не робить. Це прохання, а не контроль доступу, і він жодним чином не впливає на те, чи працює редирект для людини. Рядок Disallow не ламає ваші посилання - він лише просить сумлінного агента їх не запитувати. Усе, що ігнорує robots.txt, - це вже інша проблема, яка потребує інших інструментів.

Керуєте посиланнями на домені, який належить вам і який ви хочете контролювати? Власні домени Elido дозволяють вам обслуговувати цей хост, а це - обов'язкова передумова для того, щоб хоч якесь із цих правил взагалі діяло.

Чи коштує коротке посилання вам цитування?

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

Що справді коштує вам - це тертя на переході. Ланцюжок із двох-трьох редиректів перед контентом, розв'язання, що залежить від JavaScript, повільна відповідь або цільова сторінка, яка відповідає проміжною сторінкою. Кожен із цих факторів - це шанс, що фетч буде перервано, а перерваний фетч - це сторінка, яка не потрапила у відповідь.

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

Вимірювання трафіку, що повертається

Частина цього трафіку видима. Асистенти, що надсилають referrer, з'являються як звичайний рядок реферального трафіку, а один із них додає власний параметр кампанії, тому chatgpt.com іноді з'являється у звітах як джерело. Решта надходить як прямий трафік, оскільки чат-інтерфейс не зобов'язаний себе ідентифікувати.

Сприймайте видиму частку як нижню межу, а не як загальну суму. Якщо реферали від ШІ достатньо важливі, щоб про них звітувати, чесна версія - це напрямний тренд із джерел, які ви бачите, плюс застереження, що реальна цифра вища. Кожен, хто наводить точний відсоток ШІ-реферального трафіку, насправді наводить лише ту частину, яку зміг виміряти.

Читайте серію ключових матеріалів

Ця стаття належить до кластера інженерії. Короткі посилання як Terraform - наріжний матеріал про керування інфраструктурою посилань як кодом, а оптимізація відповідей (AEO) охоплює контентний бік того, як отримати цитування.

Пов'язані публікації в блозі

• Оптимізація відповідей (AEO): як отримати цитування від ШІ
• Агентна комерція: посилання, створені для використання ШІ-агентами
• Аналітика коротких посилань - що вимірювати, а що ігнорувати
• Кліки короткого посилання проти сеансів GA4: чому вони ніколи не збігаються
• Чи шкодять сервіси скорочення URL SEO? Чесна відповідь