AI can only fix what it can see

Why? Because an AI can only diagnose the evidence available to it. If it sees a stale crawl, a partial export, or raw HTML without the rendered page, it can produce a polished answer while missing the problem that users and search engines actually encounter.

Every SEO platform shipped a chat window in the last 18 months. The demos look the same: ask a question about your site, get a confident paragraph back. The differences between these assistants have almost nothing to do with which model sits behind the text box. They come down to what the model can see, and what it can do about what it sees.

Most of them see an API export. A crawl from last week, a rank table, aggregated metrics with the page itself long gone. An assistant working from that is commenting on a photocopy. It can be articulate about the photocopy. It cannot tell you what is on the page right now, because it has never seen the page. And when it guesses, it guesses fluently, which is worse than not answering.

What the work needs to see

SEO diagnosis has a short list of inputs, and they resist being exported.

The rendered DOM, not the HTML source. Modern frameworks rewrite titles client-side, inject canonicals during hydration, set meta robots from application state, and render body content only after a JavaScript bundle executes. A raw HTML fetch tells you what the server sent. It does not tell you what Google's renderer or a user ends up with. Anyone who has diffed view-source: against the elements panel and found two different canonical tags knows the gap is not theoretical. An AI that audits the HTTP response is auditing a document nobody ranks.

The SERP as a person sees it. Rank trackers scrape from clean datacentre IPs, logged out, with no history and no location. That result set exists for nobody. The SERP that matters is localised, device-specific, and carries the real feature mix: AI Overviews, People Also Ask, local pack, shopping units. If you have ever screen-shared with a client and watched them pull up a page-one result you could not reproduce, you already understand why a sanitised scrape is a weak substitute for a real session.

Search Console data next to the page. GSC tells you a query lost clicks. The page tells you why. The current workflow is two tabs and correlation done in your head. The data means more when it sits beside the thing it describes.

The live page. A recommendation you cannot verify against the current deploy is a guess with formatting. Crawl data starts ageing the moment it is collected.

The browser holds all of it at once

The browser is the one runtime that has all four simultaneously. It executes JavaScript, so it has the rendered DOM. It carries a session, cookies, and a location, so it can show the SERP a real user gets; SERP Lens emulates 50+ geolocations for exactly this reason. It authenticates to Search Console. And it is always pointed at the current deploy of whatever tab is open.

This is why SEO work already happens in a browser regardless of tooling. The stack has always been extensions, DevTools, a VPN, and several Chrome profiles. The browser was never the bottleneck. The bottleneck was that nothing inside the browser could reason about what it was looking at.

So rather than exporting the page to where the model lives, we put the model where the page lives.

Inside the panel

SERP Lens is a desktop app built for SEO work. The AI panel is a pane inside it. When you open the panel on a page, the model starts with that page's full analysis already in context: the results of the rule engine (316 rules at the time of writing, including structured data validation), the rendered DOM, and the SERP data from your session. No retrieval step, no "please paste the URL", no token-innefficient multi-step process and 5 minute wait time for a full audit of the page.

We provide the AI real tools that gives it this structured information without it having to figure it out on its own. It can run an audit, read the rule results, read the SERP data, and check an element on the live page. Ask why a page lost its featured snippet and it re-runs the audit, reads what changed, and inspects the paragraph in question as rendered, not as served.

An SEO's default posture toward a tool that claims to "handle it" is suspicion, and that posture is correct. The panel earns trust through legibility: you can watch what it read before you decide whether to believe what it wrote.

The same tools, pointed outward

The panel's tools are also exposed over MCP. npx @serplens/mcp starts a standalone MCP server and CLI, so Claude Desktop, Claude Code, ChatGPT and Cursor can run SERP Lens audits directly, and the CLI can run the same checks in CI.

There are two modes, with different guarantees.

Standalone fetches raw HTML over HTTP. No browser, no JavaScript execution. Rules that depend on the rendered DOM are skipped, and the output states which rules were skipped and why. It is fast, runs anywhere, and needs nothing installed beyond Node.

Bridge connects to a running SERP Lens browser and audits the rendered page in your actual session. The full picture, at the cost of needing the app open.

The explicit labelling matters more for machine consumers than human ones. An LLM handed partial data with no provenance will reason from it at full confidence. Handed a result that says "source: raw HTML, 12 DOM-dependent rules skipped", it can caveat correctly or request the bridge. We would rather an agent report "the server-rendered canonical looks fine, rendered state unverified" than assert a clean bill of health it cannot back.

Where this does not help

A browser-resident AI sees one page at a time, in depth. It is not a crawler. For site-wide questions, orphan detection, or log analysis across a million URLs, a crawler remains the right tool and we are not claiming otherwise. Standalone MCP mode exists partly as an admission of this: sometimes raw HTML at scale is what the job calls for, and the honest move is to say so in the output rather than pretend the rendered picture was there.

What the AI stands on

"Does it have AI" stopped being an interesting question about the time it stopped being a differentiating one. The question worth asking of any SEO tool now is what the model stands on when it answers. A cached crawl. An exported table. Or the page as it exists right now, in a real session, in the market you care about.

We think the model should stand on the same thing your users and Google's renderer stand on: a real browser. Everything else in SERP Lens follows from that one decision.