Коли PerplexityBot з'явився у логах вашого сервера, перед вами постає практичне питання: що з цим робити? Дозволити повний доступ, обмежити певні розділи, повністю заблокувати — чи навпаки, допомогти боту знаходити ваш контент швидше? Кожне рішення має свої інструменти, наслідки і підводні камені.
Важливий контекст перед початком: будь-яке блокування PerplexityBot має однозначний наслідок — ваш сайт повністю або частково зникає з видачі Perplexity. Якщо ви приймаєте це свідомо — добре. Але якщо блокування є випадковим або надто широким — ви просто відмовляєтеся від каналу трафіку, який ще не встигли освоїти конкуренти.
robots.txt — перший і найпростіший інструмент керування доступом краулерів. PerplexityBot у проактивному режимі офіційно дотримується його директив, що підтверджено у офіційній документації Perplexity. Синтаксис стандартний і аналогічний іншим краулерам.
Для повного блокування PerplexityBot достатньо двох рядків у robots.txt: директива User-agent: PerplexityBot і рядок Disallow: /. Це зупинить проактивний краулінг усього сайту. Наслідок однозначний — сайт повністю зникає з видачі Perplexity.
Для часткового блокування можна закрити лише конкретні розділи: платний контент, особисті кабінети, чернетки, архіви. Наприклад, закрити розділ /members/ і /drafts/, залишивши відкритим публічний блог. Це дозволяє контролювати що саме індексує Perplexity, не відмовляючись від каналу повністю.
Для явного дозволу при наявності загального блокування — наприклад, якщо у вас є правило User-agent: * / Disallow: / для всіх ботів — потрібно явно дозволити PerplexityBot через директиву Allow: /. Без цього бот вважатиме себе заблокованим навіть без явного правила для свого user-agent.
Важлива деталь щодо інших AI-краулерів: robots.txt є специфічним для кожного user-agent. Блокування GPTBot або ClaudeBot не впливає на PerplexityBot — і навпаки. Якщо ваша мета заблокувати всі AI-краулери одночасно, кожен потрібно вказувати окремо. Актуальний список user-agent рядків основних AI-краулерів: PerplexityBot, Perplexity-User, GPTBot, OAI-SearchBot, ClaudeBot, anthropic-ai.
Перевірити поточний стан вашого robots.txt можна за адресою https://yoursite.com/robots.txt. Для тестування правил — Google Search Console Robots Testing Tool підходить і для перевірки правил під інші user-agent, включаючи PerplexityBot.
Проблема тригерного режиму: чому robots.txt недостатньо
Тут починається найважливіший нюанс, який часто залишається поза увагою. PerplexityBot існує у двох режимах: проактивному (PerplexityBot/1.0) і тригерному (Perplexity-User/1.0). Проактивний режим офіційно дотримується robots.txt. Поведінка тригерного режиму щодо robots.txt — офіційно не підтверджена і залишається дискусійною.
У 2024 році низка видавців зафіксувала, що Perplexity-User продовжував відвідувати сторінки, заблоковані для PerplexityBot. Про це публічно писали видання Wired і Forbes. Perplexity офіційно не спростував цю поведінку, але і не підтвердив її у документації.
Практичний висновок: якщо вам потрібне надійне повне блокування Perplexity — robots.txt сам по собі є недостатнім інструментом. Для надійного блокування тригерного режиму потрібен WAF (Web Application Firewall) або серверні правила на рівні nginx/Apache, що фільтрують запити за user-agent рядком.
Якщо ж ваша мета — лише сигналізувати про небажані розділи, а не жорстко блокувати — robots.txt цілком підходить для проактивного режиму і є правильним першим кроком.
WAF: другий рівень контролю
WAF (Web Application Firewall) — це другий рівень захисту, який працює незалежно від robots.txt і блокує запити ще до того, як вони досягають вашого сервера. На відміну від robots.txt (який є лише рекомендацією, яку бот може ігнорувати), WAF блокує запит технічно — бот просто не отримує відповідь.
Більшість сучасних WAF-рішень — Cloudflare WAF, AWS WAF, Fastly, Sucuri — дозволяють створювати правила фільтрації за user-agent рядком. Правило для блокування обох режимів PerplexityBot виглядає як умова: якщо заголовок User-Agent містить рядок PerplexityBot або Perplexity-User — блокувати запит або повертати статус 403.
Cloudflare є найпоширенішим рішенням серед власників сайтів. У Cloudflare Dashboard правило створюється у розділі Security → WAF → Custom Rules. Умова: User Agent contains "PerplexityBot" або User Agent contains "Perplexity-User". Дія: Block або Challenge. Важливо: вказати обидва рядки окремими правилами або об'єднати їх через оператор OR у межах одного правила.
Перевага WAF перед robots.txt у тому, що він блокує технічно — незалежно від того, чи вирішить бот ігнорувати robots.txt. Недолік — WAF-правила вимагають технічного доступу до налаштувань хостингу або CDN і не підходять для користувачів на спільному хостингу без доступу до WAF.
Альтернатива для серверів без WAF — правила на рівні nginx або Apache, які перевіряють user-agent і повертають 403 для запитів від PerplexityBot. Це дає той самий результат, але вимагає доступу до конфігурації веб-сервера.
Важливе застереження: при блокуванні через WAF або серверні правила переконайтеся, що ви блокуєте лише конкретні user-agent рядки, а не широкі IP-діапазони AWS. PerplexityBot використовує AWS-інфраструктуру, і блокування AWS-діапазонів може ненавмисно заблокувати легітимні сервіси, включаючи інші хмарні інструменти вашого власного сайту.
Crawl-delay: зниження навантаження без блокування
Якщо ваша мета не заблокувати бота, а лише знизити навантаження на сервер — директива Crawl-delay у robots.txt є правильним інструментом. PerplexityBot підтримує цю директиву, на відміну від Googlebot, який її офіційно ігнорує.
Значення Crawl-delay вказується у секундах і означає мінімальну затримку між послідовними запитами від краулера. Значення 10 означає не більше одного запиту кожні 10 секунд. Для більшості сайтів значення від 5 до 30 секунд є розумним балансом між доступністю для індексації і навантаженням на сервер.
Якщо PerplexityBot відвідує ваш сайт дуже активно і це помітно у статистиці навантаження — почніть з Crawl-delay 10. Якщо навантаження зберігається — збільшіть до 30. Повне блокування через Crawl-delay неможливе: це лише регулятор швидкості, а не вимикач.
Crawl-delay впливає лише на проактивний режим (PerplexityBot/1.0). Тригерний режим (Perplexity-User/1.0) запускається синхронно у відповідь на запит користувача і не підпорядковується Crawl-delay. Якщо тригерний режим створює навантаження — потрібні WAF-правила, а не Crawl-delay.
Як прискорити індексацію: sitemap, RSS і структурні сигнали
Якщо ваша мета протилежна — не заблокувати бота, а допомогти йому знаходити ваш контент швидше — є кілька практичних інструментів, кожен із яких дає відчутний ефект.
XML Sitemap з актуальними датами lastmod. Це найважливіший інструмент прискорення індексації. PerplexityBot активно моніторить sitemap в пошуку нових і оновлених сторінок — свіжість є одним із ключових сигналів для розподілу crawl budget. Дата lastmod у sitemap має оновлюватися автоматично при кожній публікації або суттєвому оновленні статті. Якщо ваша CMS не оновлює lastmod автоматично — це варто виправити через плагін або кастомний скрипт генерації sitemap. Офіційна специфікація XML Sitemap доступна на sitemaps.org.
RSS-стрічка з повним текстом статей. Perplexity активно моніторить RSS авторитетних видань і використовує його як сигнал для пріоритизації сканування нових публікацій. Ключова деталь: стрічка має містити повний текст статей, а не скорочені анонси. RSS лише з заголовками або першим абзацом дає значно слабший сигнал, ніж стрічка з повним контентом. Якщо ваша CMS за замовчуванням публікує скорочений RSS — змініть це налаштування. У WordPress це робиться через Налаштування → Читання → "Для кожної публікації у фіді показувати: Повний текст".
Логічна структура URL. PerplexityBot витрачає більше crawl budget на URL, які виглядають як контентні сторінки, і менше — на технічні. Структура URL типу /blog/nazva-statti/ або /research/tema/ є прозорим сигналом для бота. Сторінки з URL типу /tag/, /page/2/, /author/ або з довгими рядками параметрів отримують нижчий пріоритет. Якщо ваші контентні сторінки мають чисті описові URL — це вже добре. Якщо URL містять динамічні параметри — розгляньте canonical теги або переписування URL через mod_rewrite.
Внутрішні посилання з авторитетних сторінок. PerplexityBot, як і Googlebot, знаходить нові сторінки через посилальний граф — переходячи за посиланнями з уже відомих і авторитетних сторінок. Якщо нова стаття не має жодного внутрішнього посилання з популярних сторінок сайту — бот може знайти її лише через sitemap або RSS, що сповільнює індексацію. Додавання посилань на нові матеріали зі сторінок із найбільшим трафіком прискорює їх виявлення краулером.
Поширення у соціальних мережах і зовнішніх джерелах. Perplexity моніторить активність навколо тем, які цікавлять його користувачів. Публікація нової статті у LinkedIn, Twitter/X або отримання посилань із авторитетних сайтів у перші години після публікації підвищує ймовірність швидкого виявлення ботом — особливо якщо тема є актуальною для поточних запитів у Perplexity.
Structured data: як допомогти RAG-системі читати контент
Структурована розмітка schema.org — це не лише інструмент для Google rich snippets. Для PerplexityBot вона має пряме функціональне значення: допомагає RAG-системі краще класифікувати тип контенту і витягувати найбільш релевантні фрагменти для відповідей.
За даними дослідження Search Engine Land (2025), сторінки з коректною schema.org розміткою цитуються AI-системами на 34% частіше, ніж схожий контент без розмітки. Це суттєва різниця, яка досягається відносно невеликими технічними зусиллями.
Найбільш практично цінні типи розмітки для Perplexity:
Article з datePublished і dateModified. Це базова розмітка для будь-якої статті або новини. Атрибути дати є особливо важливими для Perplexity: вони надають системі точний сигнал свіжості, незалежно від того, що написано у тексті. RAG-система використовує ці дати при вирішенні питання пріоритетності між кількома джерелами на одну тему. Також важливий атрибут author із посиланням на профіль автора — це сигнал E-E-A-T.
FAQPage. Це найбільш "RAG-дружний" тип розмітки. FAQPage явно структурує контент у форматі питання-відповідь, що є ідеальним для витягування фрагментів. Кожна пара питання-відповідь у розмітці FAQPage є самодостатньою одиницею інформації, яку RAG-система може використати безпосередньо. Якщо ваша стаття містить розділ з частими питаннями — додайте FAQPage розмітку для цього розділу. Специфікація доступна на schema.org/FAQPage.
HowTo. Для покрокових інструкцій тип HowTo дозволяє явно розмітити кожен крок з його описом. RAG-система може витягувати окремі кроки як самодостатні відповіді на питання типу "як зробити X". Особливо корисно для технічних матеріалів, рецептів, інструкцій.
Dataset. Для сторінок із дослідженнями, статистикою або структурованими даними тип Dataset сигналізує системі, що контент містить верифіковані числові дані з джерелами. Це підвищує довіру до матеріалу при цитуванні в контексті фактологічних запитів.
Важлива практична деталь: розмітка schema.org не замінює якісний текстовий контент — вона його доповнює. Якщо текст є нарративним і не містить самодостатніх фрагментів, навіть ідеальна розмітка не зробить його "RAG-дружним". Правильна послідовність: спочатку структурований контент, потім розмітка.
Зведемо все до конкретних дій залежно від вашої мети.
Якщо ваша мета — дозволити і прискорити індексацію: переконайтеся, що robots.txt не містить випадкового блокування PerplexityBot; налаштуйте XML Sitemap з автоматичним оновленням дат lastmod; увімкніть RSS з повним текстом статей; додайте schema.org розмітку Article з датами на всі ключові матеріали; розгляньте FAQPage для статей із розділом частих питань; перевірте TTFB сторінок і переконайтеся, що він нижче 800 мс.
Якщо ваша мета — часткове обмеження: додайте директиви Disallow у robots.txt для конкретних розділів (платний контент, чернетки, особисті кабінети); переконайтеся, що правило стосується лише PerplexityBot, а не всіх краулерів; якщо потрібне надійне блокування тригерного режиму — додайте WAF-правило для Perplexity-User.
Якщо ваша мета — повне блокування: додайте повне Disallow у robots.txt для обох user-agent рядків (PerplexityBot і Perplexity-User); для надійного блокування тригерного режиму — створіть WAF-правило у Cloudflare або на рівні веб-сервера; прийміть усвідомлено: ваш сайт повністю зникає з видачі Perplexity.
Якщо ваша мета — знизити навантаження без блокування: додайте Crawl-delay 10–30 у robots.txt для PerplexityBot; якщо навантаження від тригерного режиму — потрібен WAF з rate limiting, а не Crawl-delay.
Регулярно перевіряйте серверні логи на присутність обох user-agent рядків — це дозволяє відстежити чи дотримується бот ваших директив і чи не з'явилися нові патерни поведінки після оновлень платформи Perplexity.
У 2026 році питання «ти людина чи бот?» перестало бути технічною формальністю і стало інфраструктурною проблемою інтернету. Генеративний ШІ знищив більшість методів верифікації, розроблених за останні 25 років. Ця стаття — аналіз того, чому це сталось, що пропонує ринок і де проходить межа між...
Сканування райдужки — технічно один із найзахищеніших методів біометричної верифікації. Але технічна захищеність і відсутність ризиків — не одне і те саме. У цій статті ми розбираємо, що насправді відбувається з вашими даними, де архітектура World Orb дійсно захищає — і де залишаються відкриті...
Три системи збирають біометричні дані. Всі три стверджують, що захищають приватність. Але вони принципово різні за архітектурою, метою і моделлю загроз — і «безпечніша» система залежить від того, від чого саме ви захищаєтесь.
Коротко: ця стаття — аналітичне порівняння трьох моделей...
За 30 секунд сканування Orb виконує чотири складні операції: знімає райдужку в інфрачервоному діапазоні, перетворює її на числовий код, перевіряє унікальність серед мільйонів записів — і робить все це так, щоб ніхто, включно з самою компанією, не міг встановити вашу особу.Коротко: ця стаття —...
Уявіть: ви підходите до металевої кулі розміром з боулінговий м'яч, дивитесь у неї кілька секунд — і отримуєте цифровий паспорт, який підтверджує, що ви реальна людина, а не бот.
Коротко: World Orb — це біометричний пристрій, який сканує райдужку ока і генерує унікальний цифровий...
Ви хочете мобільний додаток, але не знаєте, чи варто витрачати місяці на розробку під iOS та Android,чи можна обійтися Progressive Web App. Це питання, з яким стикається кожен бізнес та розробник-одинак.Спойлер: для 70% проєктів PWA — це швидше, дешевше та достатньо, але є сценарії,де без нативного...
