We Built Our Website. 30 Days Later, We Found a Bug We Never Saw Coming.

One in eight visitors couldn't read our site. We didn't suspect it. We measured it. And that's exactly where the story begins – the story that separates shipping software from shipping software that actually works.

What Happened

We launched our new website. Bilingual: German and English. On the homepage, an automatic language redirect: it detects where a visitor is coming from and routes them to the appropriate language version. Industry standard. Clean setup. Most teams would have checked that box and moved on.

We didn't. Instead, we spent 30 days systematically analyzing where our visitors came from, what they did, and where they dropped off. AI-assisted analysis, GDPR-compliant, no personal data collected. The results surprised us.

AI Search Engines Are Changing the Rules

First, the good news: AI search engines like ChatGPT, Perplexity, and others sent over 3,000 crawler visits to our site in the first 30 days. For context: 710 real human visitors in the same period. AI systems are actively indexing, referencing, and linking to subpages. This is no longer an experiment – it's reality.

Gartner predicted back in 2024 that traditional search volume would decline by 25% by 2026, driven by AI chatbots and virtual agents. That shift is happening right now. And it brings a problem that most people aren't paying attention to.

AI search engines behave differently from Google. They link directly to subpages. And they favor English-language versions, because their training data is predominantly in English.

The Twist: Our Language Redirect Wasn't Catching It

The language redirect worked perfectly – on the homepage. But AI search engines don't send users to the homepage. They send them to a specific subpage. The English version.

A concrete scenario: a German-speaking user asks ChatGPT about a topic we cover. ChatGPT returns an answer with a link. The link leads to our English subpage. The user clicks through, lands on an English page, may not fully understand it. What happens? They leave.

This isn't a hypothetical problem. We saw it in the data.

What the Numbers Say

Here's where it gets concrete:

28 percentage points. That's not a nuance – that's a chasm.

And the 1.2 pages per session for stranded German-speaking visitors tells its own story. These people didn't immediately click away. They tried. They looked at one page, maybe started a second. Then gave up. The mirror image played out in the other direction too: English-speaking users who landed on German subpages showed the same pattern.

Anyone looking only at pageviews would have declared success. The overall numbers looked fine. Only when we drilled down did it become clear that one in eight English-page visitors couldn't understand what they were reading.

Why This Is a Build-Measure-Learn Problem

Steve Blank and Eric Ries described the Build-Measure-Learn loop as the core of the Lean Startup methodology. The idea is simple: you build something, measure its impact, and learn from the gap between expectation and reality. Then you build again.

Simple in theory. Rarely practiced.

Most software teams treat the launch as the finish line. Feature complete, deployment done, ticket closed. What happens after that? That's the client's problem. Marketing's problem. Someone else's problem.

That's only half the work. The other half starts after go-live: Was our assumption correct? Are real users engaging with the product the way we intended? Where do they drop off? Why?

Our website example illustrates this perfectly. We had a reasonable assumption: a homepage language redirect is sufficient, because that's where users enter. That assumption was correct for Google traffic. For AI search traffic, it was wrong. Without measurement, we never would have known.

What We're Changing Now

The fix is surgical, not radical. The language redirect will be extended to every subpage – but with one clear condition: it only triggers on external entry points. Anyone arriving from ChatGPT, Google, or Perplexity on a subpage gets routed to the language-appropriate version.

Anyone who has actively chosen a language stays there. Anyone navigating internally won't be redirected. No one gets overridden.

Our hypothesis: the bounce rate for language-mismatched visitors will at least be cut in half.

The Loop Closes. And Opens Again.

Here's the part most teams skip. We're measuring this again in 30 days. If the hypothesis holds, we've solved a concrete problem. If it doesn't, we've learned something new. Either outcome moves us forward.

That sounds obvious. It isn't. The reality in most software projects looks different: feature built, marked as done, on to the next ticket. Whether the feature actually achieved its intended effect? Rarely checked. Even more rarely corrected.

Build-Measure-Learn isn't a buzzword. It's a craft. And craft reveals itself in the fact that you practice it even when no one is watching.

What This Means for Software Projects in General

Two takeaways from this experience that go beyond our own website:

AI search is changing how users arrive at websites. If you're only optimizing for Google traffic, you're building for a traffic pattern that's losing relevance. AI search engines link deeper, more specifically, and with their own language logic. Website architecture needs to be ready for that.

Measuring after launch isn't optional. It's the part of the work that makes the difference between "we built it" and "it works." We found this issue because we looked systematically. A standard analysis would have hidden it. Only by segmenting by language and traffic source did the problem become visible.

Building software is the easier half. Proving that it works is the harder half. And the more valuable one.

How We Work

This discipline is something we bring to every client engagement. Whether it's web platforms, e-commerce systems, or custom applications: we anticipate what users need before the build. We measure whether that holds true afterward. We learn from the gaps. And we course-correct with clear, testable hypotheses.

If you need that same discipline for your software, now you know what Golle IT stands for.