§ 01 What it is
What Web Bot Auth actually is
Web Bot Auth is Shopify's implementation of HTTP message signatures for authorizing first-party automated tools. The mechanism uses cryptographic signatures attached to request headers — Signature-Input, Signature, and Signature-Agent — so Shopify's edge can verify the request came from a merchant-authorized tool. It is not a crawler. It is a way to let your own scripts, scanners, and automated tests authenticate against your storefront.
Per Shopify's Crawling-your-store doc1, the intended use cases (verbatim): "merchants who use automated first-party or third-party tools to access their online store for purposes of accessibility and SEO audits, automated testing, data analysis, and similar use cases." The underlying spec is HTTP Message Signatures3 — an IETF RFC describing how to attach cryptographic signatures to HTTP requests.
Common misunderstanding worth correcting: Web Bot Auth is not "Shopify's AI crawler control." It does not block GPTBot, ClaudeBot, PerplexityBot, or Google-Extended. It does not affect classical SEO crawl behaviour. It is a separate, narrower mechanism for first-party tool authentication.
§ 02 What it controls
What signatures control — and what they don't
Signatures control whether a specific automated tool can authenticate against your storefront with merchant-controlled credentials. They are scoped per connected domain (one signature per domain), carry a maximum expiration of 3 months (with automatic non-renewable expiration), and require all three required HTTP headers — Signature-Input, Signature, Signature-Agent — set to the correct values. What they do not control: Google indexing, Bing indexing, AI crawler access, or anything else SEO-adjacent. Per Shopify's verbatim statement, the store can be indexed by search engines and LLMs without signatures.
Signature-Agent is required to use the value https://shopify.com per Shopify's spec. The expiration cap (3 months) and the non-renewable expiration property are deliberate: Shopify wants signatures rotated regularly, not deployed once and left to drift. The one-signature-per-domain rule means a multi-domain store needs separate signatures for each.
The mental model: signatures are like API keys, but for first-party access to your own storefront, with cryptographic attestation. They earn their keep when an automated tool needs to crawl past Shopify's bot-mitigation layer to do something the merchant has authorized — not when a search engine or AI bot is just trying to crawl public pages.
§ 03 Mechanics
The signature mechanics
A Web Bot Auth signature is generated by the merchant (or the tool acting on their behalf), attached to each HTTP request, and verified at Shopify's edge. The three required headers are Signature-Input (which fields are being signed), Signature (the signature value), and Signature-Agent (must be https://shopify.com). Custom naming is supported per signature for merchant accounting. The signature expires automatically — there is no rolling-renewal mechanism.
Operationally, a merchant creates a signature in the Shopify admin (Settings > Bot management, or wherever Shopify exposes Web Bot Auth in the current admin surface), names it, picks an expiration up to 3 months, and downloads the credentials. The tool sending requests configures HTTP message signatures per RFC 9421, attaches the three required headers per request, and points at the merchant's domain.
The non-renewable expiration is the key operational constraint. After 3 months, the signature expires and the tool starts failing. The merchant must generate a new signature. This is by design — Shopify wants the signature surface to rotate regularly, not become a stale long-lived credential.
§ 04 Checkout
The checkout exclusion
Per Shopify's verbatim warning: 'Signatures don't grant access to your Shopify Checkout due to the additional layers of checkout security.' This is the hard constraint that determines what Web Bot Auth can and cannot be used for. A merchant building a custom automated test suite for the storefront can use signatures to authenticate page renders, navigation, search, and PDP interactions. The same suite cannot use signatures to drive the checkout flow — checkout has its own access controls that signatures don't unlock.
This matters in two operational scenarios. First: automated checkout testing. Merchants who want to run end-to-end tests through the checkout flow need to use Shopify's bot-mitigation-allowlisted infrastructure (test orders, Shopify's own QA tooling) rather than relying on Web Bot Auth. Second: third-party SEO auditors that want to verify checkout pages. They cannot. The checkout exclusion is non-negotiable.
§ 05 When to use
When to use Web Bot Auth on a Shopify store
Web Bot Auth earns its keep on three workloads. (1) Automated accessibility audits — running Axe, Lighthouse, or Pa11y against the live storefront on a schedule, where Shopify's bot mitigation would otherwise rate-limit the scanner. (2) SEO auditors crawling the full site for technical analysis — Screaming Frog, Sitebulb, or a custom crawler authenticated as merchant-authorized. (3) Data analysis tools pulling page content for monitoring (price comparison, inventory tracking, content drift). For everything else — Google indexing, Bing indexing, AI bot access — signatures are irrelevant. The SEO overview default settings already handle those.
The 3-month rotation discipline is the operational tax: every signature must be regenerated and redistributed to whatever tool consumes it on a quarterly cadence. Teams that automate this through their CI/CD pipeline have no problem. Teams that treat signatures as set-and-forget credentials get caught by the expiration and lose data for a few hours or days until someone notices.
For the orthogonal question of AI crawler control — which AI bots can crawl your store, and what to do about it — see /shopify-ai-search/ai-crawlers/ and /shopify-seo/robots-txt-ai-bots/. AI bots are controlled via robots.txt.liquid, not Web Bot Auth.
