Claude Code and Codex Can Help With GEO. They Cannot Measure It Alone.

At CiteSurge, we already do GEO work for UK companies, so I was talking recently with a UK friend about how companies in his circle approach it. He told me that they generally try to handle GEO themselves with Claude Code now.

I understand why that sounds plausible. Claude Code and Codex can inspect a site, change templates, repair canonical links, improve structured data, restructure a page around a direct answer, write collection scripts, connect APIs, and automate work that used to take a developer much longer. We use coding agents too. Ignoring that capability would be ridiculous.

But that work is implementation. It is not measurement.

And once you confuse those two things, you can make a lot of changes very quickly without knowing whether they improved anything, damaged something, or produced one interesting answer that disappears the next time you run the prompt.

What can Claude Code and Codex reliably do for GEO?

Anthropic describes Claude Code as an agentic coding tool that reads a codebase, edits files, runs commands, and connects to development tools. OpenAI describes Codex CLI around the same practical loop: inspect a repository, make changes, run local tools, automate repeatable work, and review the result.

That makes coding agents useful for work such as:

• inspecting crawl, rendering, canonical, schema, and internal-link implementation;
• changing page templates and content structures after the factual answer has been approved;
• writing collectors, data transformations, tests, and reporting code;
• connecting authorized APIs, services, and internal tools;
• analysing a supplied evidence set and challenging an interpretation;
• repeating a defined engineering workflow with human review.

Those are real GEO inputs. Some are basic. Some require serious engineering. None should be dismissed because an agent helped produce them.

But a coding agent only has the systems, access, evidence, and instructions you give it. A CLI can orchestrate infrastructure that already exists. It cannot conjure that infrastructure.

Why is GEO implementation different from GEO measurement?

Implementation asks whether a page, source, or technical system changed as intended. Measurement asks what multiple answer systems returned, under which prompt, market, location, account state, date, and availability conditions, and whether the resulting answer and citations were reliable enough to support a conclusion.

Those are different jobs.

Work	Coding-agent role	Reliable GEO requirement
Change a page	Edit content, templates, schema, links, and rendering	Approved facts, a defined success condition, and a later comparable observation
Run a prompt	Submit a question to an available model or interface	A declared prompt set, multiple answer surfaces, repeated runs, and preserved context
Collect an answer	Save returned text and visible source links	Availability rules, market and location scope, timestamps, normalization, and evidence storage
Classify a result	Apply supplied rules or assist a reviewer	Grounded criteria, source checks, abstention, adjudication, and accountability
Compare periods	Analyse two supplied datasets	A stable baseline, documented scope changes, and a boundary against false causal claims
Test a hypothesis	Help design the test and analyse evidence	Comparable observations, research discipline, and the time required for the outcome to exist

If you give Claude Code or Codex access to multiple answer systems, regional runners, scheduled jobs, a prompt registry, evidence storage, classification rules, review queues, and reporting, then it can operate parts of that system.

But look at what happened in that sentence. You supplied the system.

Once a company has built and maintains all of that, it has not solved GEO with one subscription. It has built an internal GEO platform.

Why is one prompt in one AI not a GEO measurement?

One answer is an anecdote about one run. It can be useful, surprising, wrong, unavailable tomorrow, or completely different in another answer product. It does not establish a stable market position.

A reviewable observation needs its prompt, answer surface, market, timing, answer, mention state, visible citation links, and availability state. If the program compares results later, it also needs to know whether those conditions stayed comparable.

The scale appears quickly. Take a purely illustrative scope:

• 30 tracked buyer questions;
• 7 answer surfaces;
• 3 markets;
• 4 weekly cycles.

That is 2,520 possible prompt-runs before controlled reruns, language variants, unavailable responses, verification, or deeper research. The number is not a recommended CiteSurge plan and it is not a promise that every surface returns evidence. It shows why "we asked Claude" is not a measurement method.

There is another problem: presence is not correctness. An answer can mention a brand and describe it inaccurately. A citation can appear without supporting the nearby claim. A model can classify another model's answer with complete confidence and still miss the point.

Reliable evaluation therefore needs explicit rules, preserved source evidence, recorded uncertainty, and human adjudication for material cases. If nobody can explain why an answer was marked correct, supported, inaccurate, or unavailable, the score is decoration.

Why do geography and infrastructure matter?

If a program claims to measure a market, it should declare where the observation was collected and which market it represents. A result collected from one place should not quietly become a claim about the United States, Europe, or the entire world.

CiteSurge operates distributed measurement infrastructure across multiple locations in the United States and Europe.

The existence of distributed infrastructure does not prove that geography changes every answer. It lets us test and preserve geographic scope instead of assuming it away. That distinction matters because reliable measurement records the conditions behind an observation, including when a provider or market did not return usable evidence.

One local CLI does not provide this. It can call regional infrastructure if you have already bought it, configured it, secured it, connected it, monitored it, and decided how its observations should be compared. Again, the agent can operate a machine you built. It is not the machine.

Why is crawler access only the starting point?

There are useful technical changes a coding agent can make here. OpenAI tells publishers not to block OAI-SearchBot if they want public content to be available for ChatGPT summaries and snippets. Anthropic documents separate controls for model development, user-requested retrieval, and search, and states that blocking its search or user agents may reduce visibility or retrieval.

Google's July 2026 guidance says that public crawlability, clear technical delivery, useful structure, and unique expert-led content matter for its generative Search features. It also says there is no special AI markup, artificial chunking method, or ideal page length that guarantees inclusion. Meeting every requirement still does not guarantee crawling, indexing, or serving.

That is the honest boundary. Technical access creates eligibility. It does not establish selection, citation, answer accuracy, or durability. A coding agent can help make the page accessible. Measurement begins after that work, when you observe what the answer systems actually do.

Why is a CLI not a research program?

This is the part almost every DIY argument skips.

At CiteSurge, we test hypotheses about questions such as how brand identity appears to persist, which source relationships remain stable, how citation patterns change, and what survives updates to models, indexes, and answer products. Some of our current hypotheses require 12 to 18 months of comparable observations before we can responsibly accept or reject them.

We do not know yet whether every hypothesis is correct. That is the point of doing the research instead of publishing an early pattern as a rule.

Some findings could materially change how we design and prioritise GEO work. But those findings only become useful if we preserve the conditions, repeat the observations, watch what changes, and remain willing to say that an attractive idea did not survive the evidence.

An agent can help design an experiment. It can write collectors, inspect anomalies, analyse the dataset, and argue against our interpretation. It cannot manufacture the dataset you never collected. It cannot recover a missing baseline. It cannot make month eighteen arrive in month one.

You cannot prompt your way into 18 months of evidence.

What does experienced human judgment add?

The people behind CiteSurge include machine-learning and AI experience from before the current LLM era, alongside experience shipping large technical systems, products, brands, and original intellectual property. I am not turning this article into a biography or publishing every affiliation. The relevant point is what that experience changes in the work.

GEO is partly a content problem and partly an engineering problem. It is also an evaluation problem. Someone has to decide what should be measured, whether two observations are genuinely comparable, whether a citation supports a statement, when an apparent pattern is noise, when the test design is broken, and when the correct conclusion is "we do not know yet."

You can give an agent base knowledge, documents, tools, methods, evals, and a large archive of recorded decisions. We do all of those things. But you cannot train it today on a proprietary 18-month result that does not exist yet, and you cannot instantly reproduce the institutional memory built by people who have designed systems, watched them fail, changed the method, and remained accountable for the conclusion.

An agent makes experienced people faster. It does not make experience unnecessary.

What would a company need to build GEO internally?

A large company can choose to build this capability. That may be the right decision when AI discovery is strategically important enough to justify a permanent internal function.

But the build decision should be described honestly. Reliable internal GEO measurement can require:

• authorized access to every answer surface in scope;
• maintained collectors and provider-specific fallbacks;
• distributed collection for declared markets and locations;
• prompt governance, versioning, scheduling, and cost controls;
• storage for answers, citations, metadata, availability, and later comparisons;
• classification rules, source verification, abstention, and human adjudication;
• dashboards and exports that keep observations separate from conclusions;
• researchers who can design tests and preserve long observation windows;
• engineers and operators who maintain the system as providers change;
• people who can turn evidence into approved content, technical, source, and brand work.

Claude Code or Codex can help build and operate pieces of that stack. The subscription is not the stack. The real comparison is a specialist GEO capability versus the cost and responsibility of creating an internal GEO platform and research function.

How can you test whether a GEO claim is reliable?

Ask for the measurement boundary:

1. Which answer surfaces were observed?
2. Which prompts, brands, markets, languages, and dates were in scope?
3. How many runs were available, unavailable, repeated, or excluded?
4. Were mentions, citations, answer accuracy, and referral events kept separate?
5. Were the answers and visible sources preserved for review?
6. How was correctness judged, and what happened when the evidence was ambiguous?
7. Which infrastructure collected the observations, and from which declared regions?
8. What changed between the baseline and later measurement?
9. Which conclusion is observed, which is interpreted, and which remains unproven?
10. What research history exists beyond the current prompt run?

If the answer is "we asked one AI and it gave us some recommendations," there is no reliable GEO measurement behind the claim. There is a spot check.

Use coding agents for what they are excellent at. We do. Let them inspect, build, test, connect, automate, and challenge the work.

But do not ask a code-editing tool to certify a market observation it was never equipped to make. A CLI can help build the machine. It is not the machine.

Limitations

No page, schema block, crawler rule, AI-readable file, coding agent, or GEO provider can guarantee that an answer system will crawl, retrieve, quote, cite, recommend, or retain a source. This article distinguishes controllable implementation and measurement practices from outcomes controlled by external systems.

Coding-agent capabilities and answer-product guidance change. The external product descriptions and crawler guidance cited here were reviewed on 22 July 2026. CiteSurge's exact infrastructure topology, collection methods, research designs, and provisional findings remain confidential. Distributed observation supports declared geographic scope; it does not prove that every answer varies by location. Current 12 to 18 month research windows describe CiteSurge's active research process, not validated results or a promised timetable for client outcomes.