Skip to main content
SEOAI SearchContent SystemsAnalytics

How to build one visibility dashboard for SEO and AI search

Google now offers AI visibility reporting in Search Console, but SEO and AI search still belong in one operating view. Here is the dashboard I would build.

Niels KaspersNiels Kaspers
July 15, 2026
11 min read
How to build one visibility dashboard for SEO and AI search

TL;DR

The biggest AI-search reporting mistake right now is creating a separate AEO dashboard and pretending it lives outside SEO. The better move is one visibility dashboard that tracks retrieval, AI-feature visibility, route quality, and downstream action together.

If you want the short answer, I would not build a separate AEO dashboard.

I would build one visibility dashboard for SEO and AI search.

Google's own reporting and documentation now point in that direction. On June 3, 2026, Google launched dedicated generative-AI performance reports in Search Console for AI Overviews and AI Mode impressions. Then on July 10, 2026, Google published its AI optimization guide and made the underlying point even clearer: generative-AI visibility still sits on top of core Search systems, not outside them.

That matters because a lot of teams are about to make the same reporting mistake.

They are going to create one SEO dashboard, one AEO dashboard, one ChatGPT mention tracker, one GEO experiment board, and then spend the next three months managing labels instead of managing visibility.

I think that is the wrong operating model.

The better question is simpler.

Where can customers find, understand, trust, and choose you across classic search, generated answers, and the pages they hit after the answer?

That is one visibility problem.

Why this dashboard matters now

The live operator language on X has shifted fast in the last few days. The recurring point is not "AI killed SEO." It is that SEO and AI visibility should not live in separate reporting silos anymore.

That shift makes sense now that Google has a native generative-AI reporting layer in Search Console. The new Search Generative AI performance reports show impressions, pages, countries, devices, and time trends for AI features in Search. The companion help documentation confirms that the report covers AI Overviews and AI Mode, although it is still rolling out gradually and not every property has access yet.

At the same time, Google's guide says the work behind generative-AI visibility is still mostly the familiar work: crawlable pages, clear structure, useful non-commodity content, and a site that makes its value legible.

So the reporting layer should reflect that reality.

You do not need one dashboard for "old SEO" and another for the "new AI internet."

You need one operating view that shows whether the system is doing its job from retrieval to next action.

The mistake most teams are about to make

The common failure mode is treating AI visibility like a novelty channel instead of a connected layer.

That creates two bad outcomes.

First, the team starts chasing AI mentions without checking whether the cited pages are actually strong search pages or useful destination pages.

Second, the team keeps its SEO metrics in one place and its AI metrics in another, which makes it much harder to see whether the same page cluster is actually compounding.

This is exactly why I think the definitional debate matters less than the operating model. In AEO vs GEO vs SEO: what Google actually says in 2026, I argued that AEO and GEO are useful shorthand but not separate physics. This dashboard idea is the practical version of that argument.

If the underlying system is shared, the measurement layer should be shared too.

The dashboard I would actually build

I would organize the dashboard into four layers.

1. Retrieval and demand capture

This is the classic SEO layer, and it still matters because Google's AI features are grounded in the Search index.

I would track:

  • search impressions and clicks for the core page cluster
  • branded versus non-branded demand
  • ranking movement for the query families the cluster is meant to serve
  • page-level winners and losers by search intent

This is the floor, not the whole ceiling.

If the page cannot be indexed, understood, and shown through normal Search systems, the AI feature visibility layer is usually going to be weak too.

That is one reason the AI-search cluster on this site keeps routing back to structure. How to structure pages for AI citations and real conversions and Internal links matter more in AI search than most teams think are not side quests. They are inputs to the same visibility system.

2. Generative-AI visibility

This is the newest official layer.

Google's new report gives site owners a way to see how often their URLs appear inside AI features, which pages are showing up, and where that visibility is happening by country and device.

That is useful, but I would not mistake it for a complete answer.

For now, I would use it as a directional layer that tells me:

  • which page types are appearing in AI Overviews or AI Mode
  • whether visibility is concentrating on a few URLs or spreading across the cluster
  • whether the trend is rising, flat, or collapsing after a content or structure change

If your property does not have the report yet, I would still build this section and leave a placeholder for the native data once it arrives. The operating question still exists even when the report rollout is partial.

3. Route quality and page graph health

This is the layer most dashboards miss.

A page can earn impressions and still be weak at routing the visit forward.

That matters more now because a lot of AI-assisted visits happen later in the journey. The user already got the rough answer. The click only happens when they want proof, comparison, a product page, or the next useful step.

So I would track things like:

  • whether cited or high-impression pages link to the right proof or action pages
  • whether product pages, docs, or comparison pages are discoverable from the answer asset
  • whether the cluster has clear internal links instead of dead-end routes
  • whether the title, intro, and first sections answer the page job fast enough

That is the logic behind How I rebuilt nielskaspers.com as an AI landing page. A page that wins discovery but loses orientation is not really winning visibility. It is leaking it.

4. Downstream action and business value

This is where I think a lot of AEO discourse still feels incomplete.

Impressions are useful.

Citations are useful.

But the operating question is still whether the visibility moves someone toward something valuable.

Depending on the site, that might mean:

  • product page visits from informational clusters
  • newsletter signups or contact starts
  • branded search lift after a page wins answer visibility
  • demo, trial, or purchase assists from the cluster
  • improved discovery of strategic pages like docs, pricing, or comparison surfaces

If the visibility layer is growing but the downstream action layer is flat, the issue might not be discoverability anymore. It might be page job clarity, weak proof, or bad routing after the click.

That is why I would never let the AI visibility section live alone. It needs the business layer beside it.

What I would not put in a separate dashboard

I would not create a standalone "AEO dashboard" that only counts mentions, screenshots, or anecdotal citations.

I would also not create a dashboard that treats every AI-surface mention as equivalent.

The point is not to build a prettier scoreboard.

The point is to build an operating panel that helps you decide what to fix next.

That means the dashboard has to answer practical questions like:

  • which pages are doing the best retrieval work
  • which pages are doing the best citation work
  • which pages actually route people somewhere useful after discovery
  • which product or proof surfaces are still missing from the graph
  • where the visibility system breaks between answer and action

If the dashboard cannot help with those decisions, it is still too vanity-heavy.

The role of proof and entity clarity

Google's AI optimization guide keeps pushing toward unique, helpful, non-commodity content. I think the measurement layer should reflect that instead of only measuring demand and impressions.

On this site, the pages that travel best in AI-search and answer-led contexts are the ones with one clear job, visible proof, and an obvious next route. That first-party pattern matters more to me than any new acronym.

So I would add one qualitative section to the dashboard review process:

  • does the page have a strong first-party receipt or named source near the key claim
  • does the page make the entity clear enough that a citation still carries attribution
  • does the page route into another page that proves the claim or continues the job

That is not because every useful thing can be reduced to a metric.

It is because the team needs a way to inspect the system without pretending the model will grade the page honestly on its own.

Where browser-agent readiness fits

I would keep browser-agent readiness in the same operating system, but not in the same chart group.

Chrome's agent-ready toolkit and web.dev's agent-friendly websites guide are about actuation, not retrieval. They help answer a different question: can an agent actually use the site once it lands?

That is adjacent to visibility, not identical to it.

So if the site depends on agent-driven task completion, I would add a separate section for:

  • semantic actions and accessible labels
  • route stability and layout shift risk
  • product or form flows where machine actuation matters
  • pages where the next action is ambiguous or unsafe

That is the action layer sitting next to the visibility layer.

It should inform the same operating conversation without flattening everything into one generic AI bucket.

The scorecard I would review every week

If I were running this weekly, I would ask:

  1. Which pages gained classic search demand?
  2. Which pages gained generative-AI visibility?
  3. Which pages sent visitors or agents to the right next step?
  4. Which pages still lack proof, entity clarity, or strong internal routing?
  5. Which page type deserves the next content or structure fix?

That is enough to make the dashboard operational.

It turns the conversation away from "Are we doing AEO?" and toward "Which visibility system component is failing right now?"

A quick checklist I would use

Interactive

One visibility dashboard checklist

Use this before you split SEO, AEO, and AI-search reporting into separate silos.

Completion

0%0/5 done

This is the gap between understanding the article and actually using it.

  • Use this block as the practical summary, not just the article ending.
  • If one item feels vague, the article probably needs sharper guidance.
  • A short checklist beats a long recap when the reader needs to act.

My take

The reporting shift in 2026 is real.

Google gave site owners a new visibility surface. Operators are starting to talk about answer engines, citations, and agent discovery as real distribution layers. That part is worth taking seriously.

But the teams that benefit most will not be the ones who create the most dashboards.

They will be the ones who build one clean operating view across retrieval, answer visibility, route quality, and action.

That is the dashboard I would want.

Not because SEO and AI search are identical.

Because the customer journey is still one system, and the measurement layer should help you improve that system instead of fragmenting it.

FAQ

What should an AI-search visibility dashboard include?

At minimum, it should include classic search demand, generative-AI visibility, route quality across the page graph, and a business-value layer that shows whether the visibility leads anywhere useful.

Should SEO and AEO live in separate dashboards?

Usually no. Google now treats generative-AI visibility as part of the broader Search system, so splitting them too early often hides how the same page cluster performs across retrieval, answer visibility, and downstream action.

What if my site does not have Google's generative-AI report yet?

Build the operating model anyway. Leave a placeholder for the Search Console AI report, then use page-level visibility, route quality, and downstream action data until the rollout reaches your property.

Because AI-assisted visits often happen after the user already has the rough answer. Internal links and page routing determine whether the visit continues toward proof, product context, or conversion instead of ending on a dead-end page.

Is browser-agent readiness part of the same dashboard?

It belongs in the same operating system, but not as the same metric bucket. Visibility measures whether the page gets found and cited. Browser-agent readiness measures whether a machine can actually use the site once it lands.

Niels Kaspers

Written by Niels Kaspers

Principal PM, Growth at Picsart

More insight pages

Get in touch

Have questions or want to discuss this topic? Let me know.