Download Docket for Mac

Docket is $149, paid once, for macOS 12 or later on Apple Silicon. 17 MB. No subscription, no crawl credits, no per-seat pricing — audit as many sites as you like, for as long as you like. There is no account to create, no licence server to phone, and no telemetry.

v0.1.0 is free. The beta downloads without payment and keeps working; the $149 applies from v1.0. Said plainly because a price on a page beside a button that charges nothing is the kind of thing this tool exists to flag.

Download Docket v0.1.0 for Mac

Apple Silicon · macOS 12+ · 17 MB · all releases

What it will crawl

Up to 20,000 pages per crawl, 200 by default, to a depth of 5 clicks. There is also a 15-minute wall clock: a crawl that hits it stops and tells you it stopped, with everything it found so far, rather than pretending it finished.

If your site is larger than that, say so plainly to yourself and use Screaming Frog — it crawls without a ceiling and that is a real reason to pick it. Docket is built to read a site closely rather than to survey one at that scale. These numbers are generated from the shipped build, not typed here, so they cannot drift from what the app does.

What it costs over three years

$149 once, against a subscription. The arithmetic, from the prices on the comparison pages:

Docket costs less than a year of the cheapest alternative and nothing after that. That is the whole pricing argument and it does not need help: the tools above are not overpriced for what they do, they are simply rented rather than owned.

Opening it

Double-click it. Docket is signed with a Developer ID and notarised by Apple, so macOS opens it without a security warning and without any of the right-click or Terminal workarounds that unsigned software needs.

What happens on first launch

Docket opens, starts its local audit engine, and shows a single field. Type a domain, press Run audit, and watch it crawl. There is no onboarding, no project setup and no plan selection, because none of those are necessary for the thing you came to do.

The first launch takes a few seconds longer than later ones. It used to say "while the engine unpacks itself" — that was an explanation nobody had measured, and timing the CLI out of the shipped bundle put its startup at a fifth of a second with no unpacking step to be found. The delay is real and the reason given for it was invented, so the reason is gone.

There is no security prompt to get past: the app is notarised, so macOS verifies it with Apple and opens it.

The command line

The same engine ships as a CLI inside the app bundle. It is the whole product, not a cut-down version, and it has six subcommands.

docket audit — the full audit

docket audit example.com
docket audit example.com -o audit.pdf -n 500
docket audit example.com --render 10        # run each page's JavaScript first
docket audit example.com --offline          # no third-party calls at all
docket audit example.com -f json --no-pages | jq '.score.overall'

It exits with status 2 when it finds a critical issue, so it can gate a deployment. Running it in CI against a staging URL fails the build if someone ships a noindex, which is a mistake that otherwise gets found weeks later by a traffic graph.

There is a full walkthrough for that on running Docket in a deploy pipeline — where the binary lives inside the bundle, a working GitHub Actions job, how long an audit actually takes, and what a macOS runner costs you per pull request.

--fail-on sets the bar. The default is critical, deliberately: almost every real site has HIGH findings, and a gate that fails on ordinary work gets wrapped in || true within a month.

docket audit https://staging.example.com --fail-on critical   # default
docket audit https://staging.example.com --fail-on high
docket audit https://staging.example.com --fail-on never      # report, never fail

Three exit codes, and they are a contract — a pipeline depends on them not moving:

A site that does not answer is 2, not 1: Docket ran fine, the site was not there, and a staging URL that does not respond should stop a deploy. Keeping those two apart matters more than it sounds — "your site is broken" and "the tool is broken" need opposite responses from whoever reads the log, and a gate that confuses them stops being trusted.

That case took a real fix. Auditing a domain that does not resolve used to report three critical issues: that robots.txt blocked Googlebot, that the site was not served over HTTPS, and that no pages could be crawled. Only the last was true — there was no robots.txt and nothing was served, because there was no site. A DNS blip in a pipeline would have failed the build with two invented criticals and sent somebody hunting for a robots.txt problem that never existed. When nothing at all can be read, Docket now reports that and stops.

docket diff — what this deploy broke

docket diff https://example.com https://staging.example.com
docket diff https://example.com https://staging.example.com --fail-on medium

Audits both with identical settings and reports what the second one changed. This is the better deploy gate, and the reason is arithmetic: every real site carries standing findings, so a severity threshold tight enough to catch a regression fails every build, and one loose enough to pass catches nothing. A deploy is only answerable for what it changed.

Regressions are new findings and ones that got worse — a check that was MEDIUM before and is HIGH now did not appear or disappear, and it is exactly what you want to know. Improvements never fail a build, however many there are. The default threshold is high rather than critical, deliberately: a standing HIGH finding is somebody's backlog, and a HIGH finding that arrived with this deploy is this deploy's fault.

If the two crawls reach very different numbers of pages, Docket refuses to compare them and exits 1 — not 0. A build that goes green because the comparison was impossible is worse than one that fails, because the team believes the gate ran.

docket logs — what Googlebot actually fetched

docket logs access.log
docket logs access.log.gz --url https://example.com
docket logs access.log --verify           # confirm the bot really was Google

A crawl tells you what a search engine could reach. A server log tells you what it did reach, how often, and what it wasted requests on. Point Docket at a Common or Combined format access log and it reports the response codes Google actually received, the paths it fetched most, and how much of its budget went on redirects and errors. Add --url and it crawls the site too, then shows the two ways the sets differ: pages you link to that Google did not fetch in that period, and pages Google fetches that the crawl never found — orphans, retired URLs still being retried, or sitemap-only pages.

A user-agent is a header anybody can send, and scrapers claim to be Googlebot constantly. Everything is reported as "claimed" until you pass --verify, which does the reverse-DNS-then-forward-lookup check Google documents. It is off by default because it is a DNS round trip per distinct IP. Lines that are not in a recognised format are counted and reported rather than skipped, because a parser that quietly drops a third of a file produces confident numbers about the rest.

Screaming Frog sells a dedicated Log File Analyser as a separate product at $139 per year, free up to 1,000 log events. It is a much deeper tool than this — a real interface, saved projects, and far more than a set difference against one crawl. What Docket gives you is the comparison that answers "is Google spending its time on my important pages", included in the one-time price rather than as a second subscription.

docket attack — where a competitor's authority does not protect them

docket attack yoursite.com theircompetitor.com
docket attack yoursite.com theirs.com --demand "emergency plumber"

Audits both sites, compares their link-graph authority, and returns the openings ranked by how winnable they are rather than how large they are. An older, better-linked competitor is unbeatable on the pages it has held for years and beatable on the ones it never wrote — and that distinction is the only part of a competitive analysis that changes what you do on Monday. Add --demand and it pulls what people actually search for from Google's public autocomplete, then reports which of those questions neither site answers.

docket backlinks — authority without a subscription

docket backlinks yoursite.com competitor.com
docket backlinks yoursite.com --referring

Domain authority from Common Crawl's public hyperlink graph, which covers 117,963,409 domains. --referring streams the 9.8 GB graph to list the domains linking in; it takes minutes and writes nothing to disk.

docket checks and docket serve

checks prints every check the engine runs with its lane and severity. serve runs the local API the desktop app talks to, on 127.0.0.1, which is also how you would drive Docket from your own scripts.

Requirements and limits

• macOS 12 or later, Apple Silicon. There is no Intel or Windows build.
• An internet connection to the site you are auditing. Nothing else.
• Crawls are bounded by page count, depth, wall-clock time and response size. The defaults are deliberately polite; you can raise them.

What happens to your data

Nothing leaves the machine. The only network requests Docket makes are to the site being audited, and it identifies itself honestly in its user-agent rather than impersonating Googlebot — a spoofed user-agent gets a different, sometimes cloaked response, which would make every finding a lie.

Audit history is stored in ~/.docket/ as plain JSON. Delete the folder and it is gone.