For site owners and IT teams
About the limena crawler
If limena has appeared in your access logs, this page tells you what it was doing, how to recognise it, and how to stop it. If it still is not clear, write to us and a person will answer.
How to recognise it
Six jobs, one per kind of request, so a log line tells you which one you are looking at rather than just that it was us.
| User-Agent | What it is doing |
|---|---|
limena-accessibility-scan/1.0 | The audit itself. Loads a page in a real browser, runs the checks, takes a screenshot. |
limena-accessibility-review/1.0 | Reads the content of a page already scanned, to explain findings in plain language. |
limena-sitemap-discovery/1.0 | Fetches robots.txt and sitemap.xml to work out which pages exist. |
limena-cms-detection/1.0 | Looks at one page to identify the platform, so fixes can be offered in the right place. |
limena-site-analysis/1.0 | A single look at a public page, before any engagement, to see roughly where a site stands. |
limena-reachability-check/1.0 | Checks whether a URL responds at all, and whether it sits behind a password gate. |
Each one carries the same parenthetical: (+https://limena.app/bot; contact: ryan@limena.app).
How it behaves
We build accessibility tooling. Being a considerate visitor to someone else's server is the same discipline, so these are commitments rather than defaults we happened to inherit.
It identifies itself
Every request carries a User-Agent naming the job, this page, and an address that reaches a person. No limena traffic is anonymous.
It goes one page at a time
A single browser, in sequence. No parallel fan-out across your site, and a scan is usually a handful of page loads rather than a crawl of everything you have.
It backs off when told to
A 429 or 503 stops it. If you send Retry-After we wait exactly that long, up to ten seconds. Past that we give up and the scan fails, rather than holding a connection open or pushing through.
It stays out of anything private
It does not guess at logins, follow links behind a sign-in wall, or probe admin paths. Testing an authenticated app happens only when you hand us a session deliberately, and only against what that session can already reach.
It reads, with two exceptions the site owner sets
It posts no data of its own and never fills in a form it finds. Two things it will do, both configured by whoever commissioned the audit: enter a storefront password they supply to get past a pre-launch gate, and follow interaction steps they define, such as opening a menu, to reach a state that only exists after a click.
It is scoped to what was asked for
Before an engagement it looks at a public page or two, not the whole estate. A full crawl happens when someone with authority over the site asks for one.
Blocking it
You are entitled to. Add this to robots.txt and the discovery and analysis jobs will stop:
User-agent: limena
Disallow: /One honest caveat. A scan someone has commissioned for their own site is a tool they pointed at their own property, so it is not governed by robots.txt any more than their own browser is. If you believe limena is scanning a site on behalf of someone without the authority to ask, tell us and we will stop and look into it. That is the route that actually works, and we would rather hear from you than not.
Opting out entirely
Write to ryan@limena.app with the domain and we will stop. Being straight about the mechanism: today that is a person actioning it, not an automated blocklist the crawler consults. So you get a reply confirming it rather than silence, and if it ever happens again that is a bug worth telling us about.
Reporting a problem
If limena hit you too hard, reached somewhere it should not have, or ignored a 429, that is a bug and we want it. Include a few log lines with timestamps if you can.
Rather talk to a person?
Write to ryan@limena.app about crawler behaviour, or use the contact page for anything else.