Generative UI: What it is, how it works, and when to use it

Somewhere between a prospect Googling your company and a prospect never visiting your site at all, a new kind of visitor showed up.

It doesn't click. It doesn't scroll. It doesn't show up in Google Analytics. But it scans your website, decides what matters, and quietly influences whether your business gets mentioned the next time someone asks ChatGPT, Perplexity, or Google's AI Overviews for a recommendation.

We had no real way to know what these AI bots were finding on our own site. So, before telling anyone else what to do about it, we built something to find out for ourselves.

The blind spot in your analytics

Google Analytics tracks human sessions, not server-side crawler activity. That's the blind spot. A person searches, sees a list of links, clicks one, lands on your site; that's the journey it was designed to track.

That journey is changing. Fewer people start their research by typing a query into Google and scanning ten blue links. Most of them are asking an AI assistant directly: "who are good software partners for X," "what's the best tool for Y," and trusting the shortlist it hands back. To build that answer, the AI first sent something to read the web on its behalf: a bot with a name like GPTBot, PerplexityBot, or ClaudeBot, crawling pages much like search engines have for decades.

None of that shows up in your dashboards. Those bot visits don't count as sessions, don't trigger conversion tracking, and don't appear anywhere you're already looking. If your site is hard for those bots to read, poorly structured, or quietly blocking them without anyone realizing it, you're not losing a ranking position. You're being left out of a conversation you never knew was happening. It's a new kind of competitive risk. Not "we got outranked," but "we were never in the running, and nothing told us."

That's the gap we set out to close, starting with our own site.

Are AI bots even visiting our site? We stopped guessing.

Inside our Innovation Hub, the group that experiments with new tools and workflows before we bring them into client work, someone asked a simple question: are AI bots even visiting our site? And if they are, what are they actually able to see?

Nobody could answer that with confidence. Not because it's a hard problem to reason about, but because the tool to answer it didn't exist among the tools we already had. So instead of guessing, or buying something built for someone else's website, we built a small internal dashboard for our own.

What we built: a dashboard that tracks AI bot visits

The idea is simple, even if getting there wasn't: a small piece of code sits quietly in front of our website and notes every time a known AI bot stops by. It records which one it was, which page it looked at, whether it got a clean response or hit an error, and how deep into the site it went.

Right now we're tracking bots from OpenAI (the ones behind ChatGPT), Anthropic (Claude), Perplexity, Google, Microsoft's Bing, Meta, and Apple. That list will keep growing. New AI crawlers show up faster than anyone can keep a definitive catalog.

All of that gets pulled into a dashboard the team can check the same way we'd check any other business metric: how much of the site is actually getting crawled, where bots are hitting dead ends, whether they're respecting the instructions we leave for them, and how that changes over time.

What the dashboard caught in the first two weeks

We didn't have to wait long to see the point of building this. Two things came up in the first few weeks alone.

The file we thought was working

An llms.txt is a simple file some AI models look for to understand what a site is about. Like a lot of sites getting ready for an AI-driven web, we added one, checked it was live, and moved on, assuming that box was checked.

The dashboard said otherwise. Weeks in, not a single bot had requested it.

So we went digging, and read that crawlers rely on robots.txt to know an llms.txt file exists in the first place, and ours didn't reference it. We added the missing line. Bots still weren't picking it up.

Third attempt: we added plain, visible links to the file in the site's header and footer, the same way we'd link to any other page. That's what did it. Two weeks of zero requests, and on the exact day we shipped that change, the file got six requests from five different AI companies.

The detail we only noticed because the dashboard breaks bots down by type: those six requests were all from indexer and training bots, the ones that crawl the web to build a general picture of it, not yet from retrieval bots, the ones that fetch a page in real time to answer someone's specific question right now. That's a useful distinction. It's the difference between "we're now on the map" and "we're being pulled up live," and it tells us what to check for next.

None of that would have surfaced anywhere else. Not in Analytics, not in Search Console. We would have gone on believing the file was doing its job, simply because we remembered adding it.

The high-value pages AI bots were quietly skipping

The second finding was less comforting: several of our most important pages, the ones describing what we actually do, were barely being crawled at all. Not blocked, not broken. Just quietly skipped by many bots.

We built a graphic on the dashboard specifically for this: crawl coverage per bot, broken down page by page. Now, instead of assuming coverage is even across the site, we can see exactly which high-value pages each AI bot is actually reading, and which ones it's ignoring.

We're still working on closing that gap. The first fix we tried didn't move things the way we expected, so for now the coverage graphic itself is doing the real work: telling us, page by page and bot by bot, whether the next attempt actually helps instead of just hoping it does.

Neither of these was something we could have reasoned our way into. We only found them because we were finally looking.

Before you optimize, measure

It's tempting to jump straight to fixes: restructure content, add an llms.txt file, rewrite pages to be more "AI-friendly." We did some of that too. But our own llms.txt sat unused for weeks and we had no idea, because we had nothing telling us otherwise. Without a baseline, you can do all the "right" things and still have no idea whether any of them worked.

Our approach here mirrors how we tend to approach any technology problem: understand what's actually happening before deciding what to change. It's a small dashboard, built quickly, answering one honest question. It's already paid for itself twice over, and we're still early.

We'll keep sharing what we find as the picture gets clearer. If you're curious what your own numbers might look like, that's a conversation we're happy to have.

A while ago we noticed something pretty common: everyone wanted to share more knowledge internally, but nobody wanted another heavy corporate ritual.

Internal talks usually start with good intentions and slowly disappear. They take time, preparation, and energy. And at some point people start feeling like they need to be experts before presenting anything.

So we tried the opposite.

15 minute talks.

Small topics.

Low pressure.

And one important rule: every session had to leave something useful behind. A tool, a workflow, an idea, a shortcut, a new way to approach a problem. Something people could actually use after the talk ended.

We didn’t want theory that went nowhere.

Somehow, that ended up working much better than we expected.

The idea was to reduce friction

Tiny Knowledge Bytes is intentionally simple:

• anyone can suggest topics
• anyone can end up presenting
• you don’t need to master the topic
• talks can come from experiments, client problems, tools or random discoveries
• sessions should leave something practical behind
• if nobody volunteers, the system picks someone for us

The goal was making knowledge sharing feel lightweight instead of exhausting.

Some of the best talks start with:

“I tried this yesterday and it was weird.”

The topic pool started growing on its own

Over time, topics started coming from everywhere.

Sometimes someone took a course and used a Tiny Knowledge Byte as a way to give something back to the team. Other times, a client problem triggered research into new tools, workflows or AI approaches.

A lot of sessions start from curiosity or necessity more than planning.

The pool slowly filled up with things like:

• Synthetic Users
• Google AI Studio
• Design.md
• Computer Vision
• MCP + Figma
• V0 workflows
• AI orchestration
• Figma plugins
• comparing AI tools using the same prompt

And honestly, the mix is part of what makes it interesting.

Sometimes a UX session drifts into Computer Vision. Sometimes someone technical shares a visual workflow that half the design team ends up adopting later.

There’s not much curation. It behaves more like a constant exploration system.

Then another problem appeared: choosing who presents

And this is where things became unnecessarily dramatic.

Nobody wanted to be “the person who chooses”. So we started adding absurd layers of randomness until we somehow ended up building a full internal app called 2FS.

Two Factor Sorteo.

Yes, it’s real.

The wheel proposes. The oracle decides.

The logic is simple.

First, a wheel picks someone.

Then a Magic 8 Ball decides whether destiny approves the selection.

If the oracle rejects the person, the process starts again.

That’s it.

The app accidentally became part of the learning loop too

2FS originally started as an excuse to experiment with:

• Claude Code
• Claude Design
• design systems
• editorial interfaces
• motion and microinteractions

Eventually those same explorations turned into future Tiny Knowledge Bytes.

The tool we used to select speakers started generating new topics itself.

The system started feeding itself

One of the most interesting side effects is that people started building things outside their usual role because of previous Tiny Knowledge Bytes.

2FS itself is a good example. A designer saw sessions about Claude tooling and AI workflows and thought:

“Maybe I can actually build this.”

What started as a ridiculous speaker selection tool became a real product experiment involving Claude Code, interface systems and interaction design.

Then it came back into the Tiny Knowledge Bytes circuit as a new talk.

That loop became surprisingly valuable:

someone learns something,

tries it,

builds something with it,

and eventually inspires someone else to do the same.

What ended up mattering most

Over time we realized knowledge sharing works much better when:

• it doesn’t require huge preparation
• it’s allowed to be imperfect
• it mixes different disciplines
• it leaves something practical behind
• and somehow involves a mystical wheel connected to a Magic 8 Ball

At that point, it stops feeling like another internal obligation and starts feeling like something people genuinely want to keep alive.