Don't want to fix it yourself?

Check out Manicule.

Visit Manicule

Report/Jul 13

Browzer

trybrowzer.com

Manicule Score

0100

Pages read15

Critical2

Significant5

Minor2

Surfacetrybrowzer.com/docs

Verdict

“the pitch is docs that heal on every merge; the site's own docs haven't noticed the product changed”

Share on X

Browzer Documentation Audit

Browzer's documentation surface (/docs, /cli, /help, /changelog) is coherent and readably written for a browser-workflow-recording product — but the live homepage and pricing page now market a different product entirely (an "AI-native DevRel studio" that generates docs from GitHub repos), and the product docs have not been updated to match either the pivot or the last three months of shipped features.

1. The homepage and the product docs describe two different products (critical)

Location: https://trybrowzer.com/ vs /docs, /help, /cli

Problem: The live homepage (title: "AI-Native DevRel Studio for Self-Healing Docs | Browzer") pitches "Connect your GitHub repo. Browzer drafts your docs, guides, changelogs, and blog posts — and heals them on every merge," with a "Connect a repo" CTA and nav items "How it works / Content types / Pricing / FAQ / Blog." Its own footer links "Product Docs" to /docs — which documents a completely different product: "Browzer is a browser automation tool that records your browser workflows and transforms them into step-by-step documentation and one-click automations," built from a Chrome extension, a terminal-capture CLI, and a web dashboard. /help, /cli, /guides/browser-workflow-automation, and /changelog all document the recording product; nothing on the site documents the repo-connected DevRel product the homepage sells.

Consequence: A developer who lands on the homepage and clicks through to the documentation finds setup instructions for a Chrome extension screen recorder instead of anything about connecting a GitHub repo. There is zero documentation for the product currently being sold: no setup, no supported repo structures, no publishing flow, no PR-review model. AI agents indexing the site will confidently report contradictory answers to "what is Browzer?" depending on which page they read.

The fix: Ship documentation for the DevRel-studio product before (or alongside) the homepage pivot — or gate the new positioning until docs exist. At minimum, add a banner on /docs clarifying which product it covers and where docs for the new offering live.

2. Three-plus months of shipped features have no documentation at all (critical)

Location: /changelog (v0.0.11 – v0.0.17) vs /docs

Problem: The changelog announces, between v0.0.11 (April 15, 2026) and v0.0.17 (June 27, 2026): "MCP server integration — execute automations from AI agent workflows," "API key management page for programmatic and MCP access," QA test suites, "CI/CD integration — trigger QA suite runs from your pipeline," "CI token management," UI drift detection, replay automation with variable inputs, and a public help-center portal with custom domains. The /docs page contains none of it — a grep of its HTML for "MCP", "API key", "QA suite", "CI/CD", and "drift" returns nothing. /docs ends at Knowledge Graph, Security, Billing, and Troubleshooting.

Consequence: The most developer-facing features Browzer has shipped — programmatic access via API keys, the MCP server, and CI/CD-triggered QA runs — are undiscoverable and unusable from the docs. A developer wanting to wire suite runs into GitHub Actions has no endpoint, token format, snippet, or setup reference anywhere; the only trace is a marketing bullet in the changelog.

The fix: Add reference sections for MCP setup, API key creation/scopes, and CI/CD integration (including the "copyable workflow snippets" the changelog says exist in-app). Treat every changelog "New" item as requiring a docs anchor.

3. Pricing terminology and numbers contradict between /docs and /pricing (significant)

Location: /docs (section 11, "Plans & Billing") vs /pricing

Problem: /docs states concrete prices — "Pro ($20/mo)", "Business ($350/mo)" — and a feature row labeled "Automation credits." The live /pricing page shows no plan prices in its served HTML (cards are client-rendered), says "Start generating docs today," and its FAQ asks "What are generation credits? Each generation run consumes credits." An earlier crawl of the same pricing page read "Start automating today" and "What are automation credits?" — the copy was re-skinned for the new product while /docs still carries the old prices and the old credit name. The same drift shows up at parameter level: /docs describes schedules as "daily, weekly, or at custom intervals" ("Choose frequency (daily, weekly, custom cron)") while changelog v0.0.11 shipped them as "hourly, daily, or custom cron."

Consequence: A developer cannot determine what a credit is (an automation run or a generation run), whether the $20/$350 prices in /docs are current, whether hourly schedules exist, or what plan they are actually buying. Agents parsing the two pages will emit contradictory pricing answers.

The fix: Make /pricing the single source of truth, render prices server-side, pick one credit term, reconcile the schedule-frequency options, and update or delete the /docs billing table.

4. The bug bounty scope lists a desktop app that no documentation acknowledges (significant)

Location: /security ("Program Scope") vs /cli and /docs

Problem: The security page's in-scope assets include "Browzer Desktop App — macOS and Windows builds" and "Browzer API — Backend services and endpoints." No page on the site documents a desktop app, and /cli explicitly says "Windows support is not available yet... Requires a separate PowerShell installer and capture backend." The "Browzer API" is likewise undocumented anywhere (see issue 2).

Consequence: Security researchers are invited to test artifacts they cannot find or install, and developers reading /security get a product inventory that contradicts the platform matrix on /cli — including a Windows build the CLI page says doesn't exist.

The fix: Reconcile the scope list with reality: either document the desktop app and API surface, or remove/annotate them on /security.

5. /faq and /blog return 200 but serve an empty app shell (significant)

Location: /faq (linked from the Help Center as "Frequently Asked Questions→"), /blog

Problem: /faq returns HTTP 200 but the served HTML contains only "Loading..." twice and a logo — no FAQ content — under the title "Browzer — AI-native DevRel studio." /blog serves the same shell title.

Consequence: Anyone with JS disabled, any crawler, and any AI agent fetching the FAQ gets a blank page that claims success. The Help Center's troubleshooting path dead-ends silently — worse than a 404, because nothing signals the failure.

The fix: Server-render /faq and /blog (the rest of the site is SSR'd — /docs and /pricing render fine statically), or return a proper error until they do.

6. The linked Chrome Web Store listing hasn't been updated since March despite extension-affecting releases (significant)

Location: /docs ("Installing the Chrome Extension") → Chrome Web Store listing

Problem: /docs says "Click Download Extension to get the latest version, or install directly from the Chrome Web Store," presenting the two channels as equivalent. The Web Store listing shows "Updated March 14, 2026" — yet the changelog records extension-affecting changes shipped after that date (recording click callouts in v0.0.16, server-first recording sync and extension lifecycle tracking in v0.0.13–v0.0.15). The listing's version reads 0.0.1; whether the extension shares the platform changelog's v0.0.17 numbering is unconfirmed, but the three-month-old update date is not. The listing also still describes only "a one-click automation builder."

Consequence: A developer following the docs' "or install directly from the Chrome Web Store" path may get a build months behind the dashboard download, without the recording fixes the changelog describes — and no warning that the two channels differ.

The fix: Keep the Web Store build current, or remove the "or install directly" equivalence from /docs and state which channel is canonical.

7. Per-portal llms.txt exists, but Browzer's own product docs have none (significant)

Location: site root and /docs, vs /help/{portal}/llms.txt

Problem: The generated help portals ship excellent agent surfaces — /help/supabase/llms.txt, /help/supabase/llms-full.txt, /help/supabase/llms.json, and per-article .md routes all return 200. But the site root /llms.txt and /llms-full.txt both 404, and /docs and /cli — the actual product documentation — have no markdown or machine-readable export at all. /docs is one long JS-framework page with anchor sections.

Consequence: Browzer gives AI agents a better parsing surface for Supabase's and Exa's workflows than for its own product. An agent asked "how do I install the Browzer CLI" must scrape a rendered Next.js page rather than fetch a text export the platform demonstrably knows how to produce.

The fix: Emit a root /llms.txt indexing /docs, /cli, and /changelog, and expose the same .md/llms-full.txt routes for the product docs that the help portals already get.

8. sitemap.xml omits the changelog, security, legal, FAQ, and blog pages (minor)

Location: /sitemap.xml

Problem: The sitemap lists ~160 URLs — marketing pages, /docs, /cli, /help, and 150+ third-party portal articles — but omits /changelog, /blog, /faq, /security, /privacy, and /terms entirely.

Consequence: Crawlers and agents relying on the sitemap will miss the changelog (the only documentation of three months of features — see issue 2) and the security policy, deprioritizing exactly the pages that change most.

The fix: Generate the sitemap from the route table at build time so every public route is included.

9. The footer GitHub org is empty, and an unrelated "browzer-cli" squats the obvious search result (minor)

Location: site footer → https://github.com/BrowzerLabs

Problem: Every page's footer links to the BrowzerLabs GitHub org, which has 0 public repositories. Meanwhile a different, archived project ("browzeremb/browzer-cli" — a codebase-RAG tool at browzeremb.com, MIT-licensed, unrelated to Browzer Labs) is what GitHub search returns for "browzer cli," complete with its own curl | sh installer at a different domain.

Consequence: A developer who searches GitHub instead of trusting a curl -fsSL https://trybrowzer.com/cli/install.sh | sh one-liner (a reasonable instinct — the install page promises checksum verification but the published first-stage script is just a nested curl | sh from services.trybrowzer.com) finds an empty official org and a plausible-looking impostor CLI with install instructions.

The fix: Publish at least the CLI install script, checksums, and release artifacts in the BrowzerLabs org, or remove the footer link; add a note on /cli disambiguating from the similarly named project.

What they do well

The generated help portals are genuinely agent-friendly: per-article .md routes plus llms.txt, llms-full.txt, and llms.json per portal, all returning clean markdown.
The /cli page is the strongest doc on the site: explicit platform matrix (with honest "Windows: not available"), what-the-installer-does disclosure, and a complete command reference with troubleshooting.
The changelog is detailed and dated, with clear New/Improved/Fixed/Security tagging.

Top 3 recommendations

Resolve the product-identity split: document the DevRel-studio product the homepage sells, or clearly scope /docs to the recording product until those docs exist.
Document the developer surfaces the changelog already announced — MCP server, API keys, CI/CD tokens and snippets — as real reference pages.
Give the product docs the same machine-readable treatment as the generated help portals: root llms.txt plus markdown exports for /docs and /cli.

Code Verification

Runtime snippet checks

Completed

Total

PASS

FIXED

SKIP

FAIL

Failing pages

https://trybrowzer.com/docs
https://trybrowzer.com/cli

Summary

13 documented snippets/endpoints checked from Browzer's public docs (/docs, /cli, help-portal machine-readable endpoints): 6 PASS, 4 SKIP, 3 FAIL.

The headline failure: the canonical install one-liner curl -fsSL https://trybrowzer.com/cli/install.sh | sh — documented on both /docs and /cli — downloads, checksum-verifies, and installs the CLI successfully, but then exits 1 with an unhandled Python traceback because the pairing step calls https://services.trybrowzer.com/api/v1/auth/cli/init, which returns 404. Separately, browzer version --check and browzer update both fail against a missing update manifest (https://api.trybrowzer.com/install/manifest.json → 404), so the documented self-update path is broken end to end. Core local commands (browzer status, browzer version, browzer install) work as documented, and the help-portal llms.txt/llms.json endpoints serve valid content.

No requester credentials were provided, so account-dependent commands (browzer login, browzer start, browzer stop) were skipped; notably, browzer login crashed with an unhandled httpx.HTTPStatusError traceback (401 from https://api.trybrowzer.com/api/v1/auth/cli/init) before ever opening the documented browser pairing flow.

Required credentials

Browzer account (browser pairing flow) — needed for browzer login, browzer start, browzer stop. Not provided.

Pages

https://trybrowzer.com/docs (Installing Browzer CLI / Troubleshooting)

Snippet	Status	Notes
`curl -fsSL https://trybrowzer.com/cli/install.sh \| sh`	FAIL	Binary installs and SHA256 verifies, but process exits 1: pairing step calls `services.trybrowzer.com/api/v1/auth/cli/init` → HTTP 404, unhandled `httpx.HTTPStatusError` traceback. Diagnosis: the installer-bundled CLI targets an auth endpoint that no longer exists (the installed binary uses `api.trybrowzer.com` instead). Suggested solution: update the packaged CLI / install script to the current auth host, or restore the endpoint.
`browzer status` (verify step 4)	PASS	Exit 0, prints "Not logged in. Run `browzer login`." — reports login state as documented.

https://trybrowzer.com/cli (CLI commands / Get set up / Troubleshooting)

Snippet	Status	Notes
`curl -fsSL https://trybrowzer.com/cli/install.sh \| sh`	FAIL	Same run as /docs row above (identical snippet documented on both pages).
`browzer status`	PASS	Exit 0, correct "Not logged in" state output.
`browzer version`	PASS	Exit 0, prints "browzer 0.1.0". (Note: CLI reports 0.1.0 while the site changelog is versioned v0.0.17 — different scheme.)
`browzer version --check`	FAIL	Exit 1: "Failed to check for updates: Client error '404 Not Found' for url 'https://api.trybrowzer.com/install/manifest.json'". Diagnosis: update manifest endpoint missing. Suggested solution: publish the manifest at the documented host or fix the URL baked into the CLI.
`browzer update`	FAIL	Exit 1, same 404 on `api.trybrowzer.com/install/manifest.json`; documented "Download and install the latest packaged CLI" cannot complete.
`browzer update --enable-auto`	SKIP	Not run separately — depends on the same update manifest endpoint that 404s.
`browzer install`	PASS	Exit 0; rewrites `~/.browzer/hook.zsh` and `hook.bash` as documented.
`browzer login`	SKIP	Requires a Browzer account and interactive browser pairing (credentials unavailable). Observed before skip: unhandled `httpx.HTTPStatusError` traceback on 401 from `api.trybrowzer.com/api/v1/auth/cli/init` instead of a graceful prompt.
`browzer start`	SKIP	Credentials unavailable; exits 1 with graceful "Not logged in. Run `browzer login` first."
`browzer stop`	SKIP	Requires an active logged-in recording session.
`source ~/.zshrc` or `source ~/.bashrc`	PASS	`source ~/.bashrc` exits 0 in the sandbox (zsh not installed; bash variant verified).

https://trybrowzer.com/help/supabase (machine-readable endpoints)

Snippet	Status	Notes
`GET /help/supabase/llms.json` ("JSON index - Machine-readable article index")	PASS	HTTP 200; parses as valid JSON with keys `canonical_base_url`, `categories`, `description`, `llms_full_txt`, `title`.
`GET /help/supabase/llms.txt` and `/llms-full.txt` ("Full context")	PASS	Both HTTP 200, well-formed markdown with resolving per-article `.md` links.

Target history

Prior reports

Loading history.

Sources