NewLaunching String Web Access APIRead the manifesto →
← Blog

How to build your own GEO engine

Bruce Magness · August 26, 2026

Welcome to The Growth Diaries: a series on the things we're building and the lessons we're learning as we scale the Web Access API. We're a small team running GTM across a broad TAM for the first time, and there is a lot to learn. Hopefully these posts are useful. First up: the GEO tracker and improvement engine we built ourselves.


We built our own GEO tracker instead of outsourcing it to another company. Here's how.

When we launched our Web Access API, we knew we would have to learn some new skills. The vast majority of our clients have come from our Managed Services business. They are hedge funds and PE / VC firms. Now, this API solves problems for any company that uses web data as core to their product, meaning our TAM has expanded massively.

Being listed as a result in Claude and ChatGPT has become crucial. GEO (Generative Engine Optimization) is the process of trying to show up in those results. There are lots of companies out there who build solutions to solve this problem; we wanted to build our own and use our API to do it.

We did so with two agentic skills built as Claude Code routines - a daily tracker and a weekly review - alongside a bank of questions our buyers actually ask (both built using our Web Access API). Out of the questions we asked, we were only appearing in 0.07% of answers. This makes sense; the incumbents in the space had invested in their content. We had yet to.

A GEO platform is, at its core, a loop: ask the engines, see what they cite, fetch those pages, learn, and ship.

Why build this ourselves?

When you work at the company with the most accurate Web Access API on the market, there are a lot of tools you can build instead of buy. This looked like one of them. A GEO platform sends questions to LLMs, sees what's working, and then suggests (or makes) changes to your web presence so you get listed where it matters.

We realized we could get there by sending requests through both the APIs and the consumer interfaces, seeing what the bots source, fetching those pages, and learning from them. Building it internally was simpler than outsourcing it to a costly provider.

The engine is built on two skills, which we've open sourced here: the GEO Daily Tracker and the GEO Monday Review. The tracker gathers the data on who's getting listed. The review is the decision-maker: it reads the tracker, tells us what we're doing, what our competitors are doing, and what to change.

Both skills are informed by a sentiment scrape we run weekly across Reddit, GitHub, and Stack Overflow, which tells us what people in our market are actually discussing. That, plus what we hear on sales calls, determines which questions the engine asks.

Step 1
Measure
200 questions, 9 surfaces, every day
Step 2
Assess
Rates, coverage, and page-level opportunity
Step 3
Suggest
A priority-ranked queue every Monday
Step 4
Draft
One 6am draft per weekday, human-shipped
The loop. Measurement runs daily; the review turns it into work every Monday.

Step 1: Measure

The tracker has a bank of 200 questions that it tests across 9 surfaces: 50 questions daily, and the full set of 200 weekly. The surfaces:

  • GPT, Claude, Perplexity, and Gemini APIs
  • Google AI Mode and Google AI Overviews via a hosted CDP browser
  • The ChatGPT, Claude, and Perplexity consumer apps
The daily tracker ping in Slack: engines 200/200 clean, per-surface pass counts, and the mention rate for the run
The daily run reports into Slack when it finishes - this is the real ping from the morning we published this post. It posts this run in Slack, and then a larger PDF is sent to me over email containing all of the details behind the run. This screenshot just verifies that things work!

From the answers, we work through three categories of questions:

1
Who are the AI engines listing, and how are they finding them?

If it's not us, who is it? How are the engines talking about our competitors, and which sites are competitors getting mentioned on?

2
What are competitors publishing?

We compare every competitor's sitemap against last week's copy. New pages show up here before a single citation is earned, and we can publish our own answer for the engines to crawl.

3
How are we doing in classic search?

We pull Google Search Console weekly: which queries show our pages, at what position, how many people saw us, and how many clicked. So the GEO engine also does SEO.

The end product looks at mention rate and citation rate, split by category (third-party, competitor-owned), theme (price, features), and surface (Reddit, YouTube, blogs). It also tracks competitor intel and on-site coverage: which tracked questions we've answered fresh on our own site, and which ones have gaps.

Step 2: Assess

The next agent calculates our mention rate and citation rate per surface and builds a trendline, so we can see how we compare week over week.

The summary section of a real weekly GEO report: citation and mention rates, site coverage, and per-surface tables
The top of a real Monday review, from the August 24 run. Yeah yeah, our mentions are low. We just launched the engine! Give it some time and we'll get those numbers up.

The most valuable piece is content coverage. The engine looks at the 200 tracked questions and scores which ones our site answers fully, partially, or not at all. That tells us where to invest our energy.

It then ranks every page on our site by opportunity: how many additional clicks could we get by fixing it, based on where it ranks and the click rate we should expect at that position? Pages with too few impressions get dropped, because any estimate built on thin data is mostly noise.

We also give special weight to near-miss queries: searches where Google already ranks us on page one or two, but we don't have a dedicated page. Those are usually the quickest wins available.

Finally, there's a refresh queue that flags our own pages as they go stale. Refreshes are scheduled by content type, then pulled forward when a page's numbers start dropping.

Step 3: Suggest

Now we take the analysis and get a list of suggested content to create, changes to make to the site, or platforms (Reddit, YouTube) to try to get mentioned on. These have gotten very concrete as we've refined the skill each run. “The title here is different from what's getting cited - match it” is much better feedback than “Change your post titles to better match these themes.”

Each proposal gets scored across both channels: search clicks and AI citations. A page that helps both outranks one that only helps one. The Monday review turns this into a priority-ranked queue of suggestions waiting for me at the start of the week.

Step 4: Draft and send

Every weekday at 6am, an agent takes the next item from the queue and writes a full draft using a locked template: direct answer at the top, benchmark data from our own published runs, and every price verified with a note showing where the number came from.

The draft arrives as a Gmail draft with a Slack ping. It cannot publish. I rewrite it in my own voice, and only my version ships.

The day an edit or new page goes live, it gets enrolled for measurement: a before snapshot, then new readings at 28 and 56 days. Results are adjusted against the rest of the site, so a general rise in traffic doesn't get counted as a win.

Then, bang. You're done.

How can I build my own GEO engine?

You can, probably! I have no coding experience (I'm just a silly ex-consultant) and put this together using our Web Access API and Claude Code, with one of our engineers running the market sentiment scrape that informs the question list. You don't strictly need the scrape - you can come up with the key categories for your own version yourself.

Part of the fun of the Chief of Staff role at String is seeing what we can build without any technical expertise. The Web Access API makes this possible. Fork the repo, see if it's valuable to you, and email me at bruce@usestring.ai - I'm always happy to talk through any of it.

Cheers,
String team

Get your API key →Explore the Web Access API
© 2026 StringEU and UK GDPR Article 27 representative — appointment verified by EuverifyBuilt in New York City 🗽 🍎