WebmasterID logoWebmasterID
Search bots

axe accessibility scanner

axe is an open-source accessibility-testing engine from Deque Systems, embedded in browser extensions, CI pipelines, and tools that evaluate pages against WCAG accessibility rules. When run in an automated or hosted mode it fetches and renders a page to analyse its accessibility, rather than indexing content for search. It typically runs on your own pages, on demand, as part of accessibility QA.

Verified against primary sources

What this means

axe-core is a widely used accessibility-rules engine. It powers the axe browser extension and is embedded in test frameworks and hosted scanners, evaluating a rendered page for WCAG issues such as missing alt text, contrast problems, and ARIA misuse.

When run interactively in a browser, axe may not generate distinct server requests. In automated or hosted modes — CI runners, headless browsers, hosted scanning — it fetches and renders the page, which can appear in logs. This is accessibility analysis, not search indexing.

How it identifies itself

Automated axe runs typically use a headless browser, so the user-agent often reflects that browser plus any tool-specific token the runner sets. Match on your testing tool's configured identity and correlate with your QA/CI schedule rather than expecting a single fixed token.

Because user-agents are configurable and copyable, treat them as claims. An expected axe run should align with a test you scheduled.

robots.txt considerations

Accessibility testing is usually run against your own pages, so you may intentionally allow it regardless of robots.txt. Where a hosted scanner exposes a documented token, you can target it in robots.txt to express a preference.

robots.txt is honoured by compliant crawlers and is not an access control. For your own accessibility QA, restricting the tool would only hinder your testing.

How it appears in analytics and logs

An automated axe fetch means an accessibility test rendered and analysed your page against WCAG rules, usually as part of your own QA or CI. It is accessibility-testing bot traffic, not a human visit and not a search-index crawl.

Diagnostic use case

Recognise automated axe accessibility checks in logs, confirm they correspond to your own QA or CI runs, and distinguish accessibility analysis from search indexing.

What WebmasterID can help detect

WebmasterID classifies automated axe runs server-side as accessibility-testing bot traffic and surfaces them on the bot-intelligence surface, so QA checks stay separate from human analytics.

Common mistakes

Privacy and accuracy notes

Identification uses only the request user-agent and rendering context. No visitor identity is involved. WebmasterID records the fetch as a bot event, separate from human analytics, and never attaches it to a profile.

Related pages

Sources and verification notes

Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.