Katana v1.7.0 covers both HTTP and browser crawling
Katana v1.7.0 is built for endpoint discovery rather than general web indexing. Standard mode fetches pages without a browser, while the experimental headless mode executes JavaScript and can collect XHR requests. Both feed a command-line pipeline that accepts one URL, lists, or stdin and emits plain URLs or structured JSON Lines. The same engine is available as a Go library with result callbacks, which makes Katana useful before scanners, inventory checks, and manual application testing.
The feature set goes beyond following links. Katana can parse JavaScript, extract forms, detect technologies, inspect robots.txt and sitemaps, and apply custom regex fields to responses. Optional knowledge-base classification labels pages such as login, error, captcha, or parked, then can identify endpoint types and possible secrets. That classifier downloads a model on first use. Secret validation is more consequential: the README says it sends live API calls to providers, so it should be enabled only on data you are authorized to test.
A 150-request default makes scope controls part of setup
Katana defaults to 10 concurrent fetchers, 10 parallel inputs, and a global limit of 150 requests per second. Those defaults are energetic enough that a responsible run starts with ownership, scope, and rate decisions. Root-domain scoping is enabled by default, with regex inclusion and exclusion for tighter boundaries. Operators can also cap pages per domain, ignore query-value variants, and filter similar URL paths so generated identifiers do not expand one route into an endless queue.
Rate controls are unusually practical for shared automation. A run can set requests per second or minute globally, apply a separate per-host ceiling, and add delay between requests. The README says Katana backs off with exponential delay and jitter after HTTP 429 or 503 responses. None of that grants permission to crawl a target, and a bad scope expression can still cross a boundary. Treat the emitted URL set as sensitive too, especially when it contains internal paths, query values, or discovered secrets.
What happened when we ran it
Our sandbox installed commit 430318a in 58 seconds and pulled 357 packages. The build finished successfully in 111 seconds. Go test then completed in 64 seconds with 46 passed and 0 failed out of 46. That clean result matters for a tool intended to sit early in a security pipeline, where malformed output or a crawler crash can quietly remove coverage from everything downstream.
The checkout itself was compact: 189 files, about 21,353 lines of source, and 1.5 MB before installation. We found 12 CI workflow files and a Dockerfile, though no tests directory. Go projects often keep test files beside their packages, so the directory signal is less useful than the command result here. Our measurement setup proves that the supplied commit installed, built, and passed its available Go tests in the stated fresh container; it does not measure crawl speed or target coverage.
One of Katana's two crawl modes is still experimental
Katana v1.7.0 is safer to start in standard mode when server-rendered links are enough. Headless mode adds JavaScript execution, DOM interaction, XHR extraction, automatic form filling, and connection to an existing Chrome debugging session. It also adds browser state and another failure surface. The README labels both headless crawling and automatic form filling experimental, and the Ubuntu instructions install Google Chrome alongside the Go toolchain.
Issue 1756 gives embedded users a concrete reason to add an outer deadline. Its reporter found that cancelling Options.Context did not stop a hybrid crawl blocked inside a Chrome DevTools Protocol call, with the goroutine still blocked 12 minutes later. Issue 1825 describes another library-only edge: leaving TimeStable at zero can reach time.NewTicker(0) and panic from a Rod goroutine. The CLI supplies a default, but code constructing options by hand may not.
Two authenticated routes still depend on session handling
Katana v1.7.0 documents two ways to crawl protected pages: pass a manually exported cookie or header, or attach headless mode to a browser where the user has already logged in. That is honest, workable plumbing for a tester. It is not an identity workflow. Session renewal, multi-factor prompts, account locking, secret storage, and deciding which user role should be crawled remain the operator's responsibility.
Browser reuse also has limits. The README warns that a custom Chrome data directory does not save a cookie whose lifetime is only the active session. It separately says raw response storage is unavailable in headless mode. Teams that need replayable evidence from an authenticated JavaScript application must capture traffic elsewhere or accept Katana's JSON output without a raw-response archive. For simple header-based access, a file keeps the secret out of shell history, but that file still needs restrictive permissions and cleanup.
The September 10 push and v1.7.0 show current maintenance
GitHub recorded Katana's last push on September 10, 2026, and listed 17,449 stars plus 26 open issues and pull requests. Open issue 1825 was filed and updated that same day, while issue 1756 was updated on September 8. That combination supports a judgment of active maintenance and active scrutiny. The combined open count is not a count of confirmed bugs.
Release v1.7.0 arrived on August 5, 2026. Its notes include lifecycle context support, headless callbacks, similarity-based content deduplication, and fixes for look-alike-domain scope boundaries and concurrent map access. The open cancellation report concerns that newer context control, which is exactly why release recency cannot substitute for reading issue activity. Katana is mature enough to adopt for standard crawling today. Browser-backed library users should wrap it as a process they can terminate, then test their own option construction and session behavior before trusting a long run.