What Browseo does

Open a page and its report is ready: findings sorted by severity, each with its rule ID, the value found and a link to the documentation. The report refreshes on every navigation, and the inspector can move to its own window on a second screen.

• Tabs for overview, indexing, meta, headings, links, images, structured data, social, hreflang, sitemap, redirects, network, performance and source vs DOM.
• Problems can be outlined on the page itself, such as images without alt text and broken links.
• Export the full report as JSON, or findings, links, images and structured data as CSV.

Browseo keeps the HTML the server sent for the navigation separate from the DOM after JavaScript ran, and reports the fields JavaScript changed: title, description, H1, canonical and robots directives.

• The raw HTML is the body of the original navigation, not a second request.
• If the original HTML is not available, for example from a cache, the report says so instead of guessing.

Every hop of a redirect chain is recorded with its status and URL. Loops, chains of three or more hops and meta refresh are flagged, and a main document that answered with a 4xx or 5xx status is reported as critical.

• The network panel lists the requests of the page load, their transfer sizes, third-party hosts, and failed or error responses.

robots.txt, meta robots, the X-Robots-Tag header and the canonical (in the HTML and in the Link header) are read and shown on their own, and conflicts between them are flagged. Browseo never says a page will be indexed; the real status comes from Search Console on Pro.

• Examples of what it flags: noindex together with a robots.txt block, a canonical outside the head, JavaScript that changes the robots directives.

hreflang values are checked for valid codes, a link to the page itself, duplicates and x-default. The optional return-link check fetches each alternate page (public mode, no cookies, at most 50) and checks that it links back, returns 200, is indexable and points its canonical to itself.

Browseo finds the sitemaps declared in robots.txt (or tries /sitemap.xml and /sitemap_index.xml), reads index files and gzip, and tells you whether the page you are on is listed. If a sitemap could not be read completely, the answer is "unknown", not "not listed".

JSON-LD, microdata and RDFa are parsed: detected types, blocks that are not valid JSON, entities without @type and contexts that are not schema.org. Open Graph and Twitter card tags are checked too, with a share preview that is labelled as an approximation.

Link rules flag javascript: URLs, empty anchors and nofollow on internal links. Image rules flag missing alt text, missing width and height, and images far larger than they are shown.

• The link check is off by default. When you run it, it requests the linked URLs of the page (up to 500) from your computer in public mode, without cookies, and broken links can be outlined on the page.

The performance panel measures lab metrics for the page and lists requests, transfer size, third-party hosts and the largest transfers. Live Web Vitals shows LCP, CLS, INP, FCP and TTFB updating while you use the page.

• Everything here is lab data from your computer and is labelled that way. Field data (CrUX) only comes from PageSpeed Insights and is never mixed with it.

Load the same URL again in a hidden view with a fresh session (no cookies or logins from your profile) with JavaScript off, with a Googlebot user agent or as a mobile phone, and see which fields differ: status, title, description, canonical, noindex, lang, viewport, images and more.

• It is not Google's renderer, and the Googlebot option only changes the user agent.

Save the full report of a URL before a release and compare it afterwards: new findings, resolved findings and every changed field with its old and new value. Snapshots stay on your computer until you delete them.

• You can also capture a section of a page as a screenshot, saved to a file and copied to the clipboard.

Give each client a profile with its own cookies, sessions and history so they never mix. A private window writes no history, cookies or reports to disk.

• Features that must store data, such as snapshots and SERP analysis, are switched off in private windows.

Lighthouse lab measurements and CrUX field data are shown apart. On Free you enter your own Google API key and the request goes straight to Google. On Pro the request runs from our server, needs no key and has a monthly quota.

• The page URL goes to Google only after you allow it.

On a results page you opened yourself, each organic competitor's title, H1, canonical and schema appear above the result. Browseo sends no automated queries to the search engine and leaves ads out.

• Each competitor's robots.txt is checked before its page is loaded; a page it blocks is not loaded.

URL inspection and performance data next to the page you have open, with Google's chosen canonical compared to yours. Access is read-only: you give OAuth consent with your Google account, the token is stored encrypted on the server and you can disconnect at any time.

You pick which findings are sent and see the payload exactly as it will be sent before you confirm: the findings with their short evidence, and the page address as domain and path only, without query parameters. The request goes through api.browseo.app to Anthropic.

• No page HTML, cookies, headers or browsing history are sent, and page text is never run as instructions. A monthly quota applies.

Page analysis runs on your computer. The app sends no telemetry, and the Free plan needs no account. The four features that talk to other servers (PageSpeed Insights, Search Console, AI analysis and your account) send only what each one needs.

• Reports, snapshots, history and profiles stay on your computer, also if you leave Pro.
• Updates are checked by the app itself against a release list signed with Ed25519; if the signature does not match, nothing is installed.