Crawler documentation

Allowing KinyaBot

Allow KinyaBot in your CDN, WAF, host or plugin console: where the control lives in each product, what that control accepts, and how to match KinyaBot’s published dedicated egress /32 where the product allow-lists by address.

The string to match
KinyaBot/1.0 (+https://www.kinya.ai/bot)
robots.txt token
KinyaBot
Dedicated egress
2.28.52.200/32
Console guidance last verified
23 August 2026

Before you write the rule

A User-Agent is a claim, not proof. Anything on the internet can send KinyaBot/1.0 (+https://www.kinya.ai/bot). Where your provider offers a live verification method — a published address list, a forward-confirmed reverse-DNS name, or a request signature — use that in preference to a string match, for every crawler.

This is KinyaBot’s complete current dedicated egress list: 2.28.52.200/32. Customers and providers may match that exact /32 in addition to the exact User-Agent. Publishing the address proves origin by network address; it does not authorize us to crawl your site. Robots, rate bounds and customer authorization remain controlling. Address changes will be published before new production traffic uses them.

KinyaBot publishes no reverse-DNS name and no public signing key. Shopify merchant-issued headers, when privately configured, apply only to that exact storefront and are not a general KinyaBot identity. Two consequences for the rules below:

  • Match the published /32 where the console allow-lists by IP, and the exact User-Agent where it allow-lists by string. Several products below accept only one of those. HUMAN and Akamai require Web Bot Auth / public-key signing for central verification, which KinyaBot does not publish.
  • Keep a KinyaBot allow rule rate-bounded rather than an unconditional bypass, and scope it to the paths you intend. A User-Agent match is spoofable, so treat a string-only rule as “do not block, keep watching” rather than “trust completely”.

If you would rather not allow KinyaBot at all, you do not need a firewall rule. Adding User-agent: KinyaBot and Disallow: / to your robots.txt stops it from the next time it reads that file, and it does not work around a block.

We verified each path below against the provider’s own documentation on 23 August 2026. Console layouts change; the linked source is authoritative over the path written here.

Shopify

  1. Shopify admin
  2. Online Store
  3. Preferences
  4. Crawler access
  5. Create signature
  • Give the signature a name, choose the domain it covers, and choose how long it is valid for.
  • A signature is valid for at most three months, cannot be renewed — a new one has to be created — and covers one connected domain each. It does not grant access to Shopify Checkout.
  • A crawler holding a signature sends three headers on every request to that storefront: Signature-Input, Signature and Signature-Agent. Never paste the signature values themselves anywhere public.
  • After you privately configure these values in your Kinya account, KinyaBot sends them only to that exact storefront domain. They authenticate access to that Shopify store; they are not a public or global KinyaBot verification identity.

Shopify Help Center — Crawling your storeShopify changelog — bots and agents should identify themselves

Akamai Bot Manager

  1. Security Configuration
  2. Security Policy
  3. Bot management
  4. Custom Bot Categories
  5. Manage Bot Categories
  • Add a category there, create the bot inside it, and set that category’s action to Allow.
  • KinyaBot has to go in a customer-defined category: Akamai-defined bots cannot be added to Akamai’s own categories.
  • Match on the exact User-Agent string at the top of this page. Akamai has no operator submission route. Central verification requires Web Bot Auth / public-key signing, which KinyaBot does not publish, so there is nothing we can register centrally on your behalf.

Akamai TechDocs — bot detection methods

Imperva Cloud Application Security

  1. my.imperva.com
  2. Application
  3. Websites
  4. your site
  5. Website Settings
  6. Security
  7. Bot Access Control
  8. Good Bots
  • Adding a new entry to the Good Bots list requires an Imperva support request. The route a customer can complete alone is Bot Access Control › Add exception › Client app ID.
  • Imperva has no operator submission route. The request comes from you, as the account holder.

Imperva documentation — security settings and Bot Access Control

F5 Distributed Cloud Bot Defense

  1. Bot Defense
  2. Manage
  3. Bot Policies
  4. Bot Allowlist Policy
  • A Bot Allowlist Policy accepts an IP address, prefix or range only. Match KinyaBot’s complete current dedicated egress list: the exact /32 published in the identity record.
  • The other route is HTTP Load Balancer › Common Security Controls › Trusted Client Rules, which additionally accepts an AS number or an HTTP header match — Exact, Regex or Presence. A prefix match on the published /32 is the address-based control; a header match on the exact User-Agent remains available and remains spoofable on its own.

F5 documentation — Bot Allowlist PolicyF5 knowledge article — Trusted Client Rules

Netlify

  1. Extensions
  2. User Agent Blocker
  3. Block User Agents
  • The caution here is about what you switch on, not what you add: the User Agent Blocker’s SEO and search-crawler presets block general crawlers, and selecting one blocks KinyaBot along with them.
  • Netlify’s Firewall traffic rules allow by IP address or range only. Match the published dedicated egress /32 there.
  • Netlify categorises KinyaBot as a crawler in the Netlify-Agent-Category header it sets on requests.

Netlify docs — blocking crawlers with the User Agent BlockerNetlify docs — firewall traffic rulesNetlify docs — user agent categories

WP Engine

  1. User Portal
  2. Web Rules Engine
  • Web Rules allow by IP address only. Match the published dedicated egress /32.
  • WP Engine’s own caveat, verbatim: “IP that have been blocked for security reasons at a server level cannot be allowed using Web Rules … Reach out to Support”. A server-level block has to be lifted by WP Engine support, not by a rule you write.
  • WP Engine’s Global Edge Security is powered by Cloudflare, so a site on that tier is also governed by Cloudflare’s bot decisions. Cloudflare has not listed KinyaBot as a verified bot.

WP Engine support — Web Rules Engine

Azure Front Door / Application Gateway WAF

  1. WAF policy
  2. Managed rules
  3. Assign
  4. Additional rule set
  5. Bot protection rule set
  • With the bot protection rule set assigned, add a WAF custom rule that allows KinyaBot. Match the published dedicated egress /32, the exact User-Agent, or both, and evaluate the rule ahead of the Bot Manager managed rule set, otherwise the managed rules decide first.
  • Without such a rule an unclassified crawler is handled by the UnknownBots rule group rather than GoodBots. Microsoft curates those groups; there is no operator route to be added to them.

Microsoft Learn — configure bot protection for Front Door WAF

AWS WAF Bot Control

  1. AWS WAF
  2. Web ACL
  3. Rules
  4. custom allow rule ahead of AWS-AWSManagedRulesBotControlRuleSet
  • AWS Bot Control at the Common protection level labels bot traffic and blocks bots it cannot verify. A customer-owned allow rule that matches the published dedicated egress /32, evaluated ahead of the Bot Control managed rule group, is the control that works today.
  • AWS has no operator registry. Requesting a managed classification is a separate, optional support-case step for the account holder.

AWS documentation — Bot Control managed rule group

Wordfence

  1. WordPress admin
  2. Wordfence
  3. Firewall
  • Wordfence declines to allow-list by User-Agent in general, on the grounds that a User-Agent is spoofable. That position is correct: a string match alone is not proof of origin.
  • Rate Limiting is the practical control: it distinguishes crawlers from humans and lets you set what happens when a crawler exceeds a threshold. Throttling a crawler is safer than blocking it.
  • The IP allow list under Blocking is the unconditional bypass. Match the published dedicated egress /32 there. Keep it rate-bounded if the product lets you; an IP match proves origin, not authorization to crawl.

Wordfence documentation — Rate LimitingWordfence documentation — Blocking

Sucuri

  1. Firewall dashboard
  2. Access Control
  • Sucuri accepts CIDR blocks only at /24, /16 or /8. The published dedicated egress is a /32, so enter it address by address as 2.28.52.200, not as a /32 CIDR.
  • Access Control allows by IP address and by user agent. Match the published address; a user-agent match remains spoofable on its own. Keep the rule rate-bounded rather than an unconditional bypass.

Sucuri documentation — firewall access control