How We Implemented GEO on Our Own Site

Before offering AI search optimisation (GEO) as a service, we applied it to our own site. This article documents what we actually put in place on seoforge.fr: every point is verifiable online, in our robots.txt, our llms.txt or the source code of our pages.

The principle of GEO fits in one sentence: for an AI assistant to cite you, it must be able to read your site, understand who you are and repeat your information. Here is, item by item, what that meant for us.

Opening the site to AI crawlers, correctly

Our robots.txt allows fifteen AI crawlers by name: GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, Google-Extended, GoogleOther, CCBot and the rest. The detail that matters: they all share a single rule group with the asterisk. The robots.txt standard (RFC 9309) says a crawler obeys only the most specific group naming it; separate per-bot groups with a bare "Allow: /" would have cancelled, for those bots, the disallow rules protecting the admin and technical pages.

The file alone is not enough: the CDN has a say. Cloudflare blocks AI crawlers by default, above robots.txt. The permission must therefore also be granted in the dashboard, and verified from the outside with the actual user agents.

Disambiguating the entity: SEOForge is not SEOForge

At least two products unrelated to us are also called "SEOForge". Without a clear signal, language models merge the entities - and attribute to one what the other does. Our answer is machine-readable: a complete Organization schema on every page, with the registered company name, the SIRET as identifier, the VAT number, the INSEE creation date, the founder and the official LinkedIn page in sameAs. The description itself states "not to be confused with similarly named SaaS products", visibly and in structured data.

An llms.txt that is generated, never stale

Our llms.txt sums up the agency, the services, the public prices and every blog article, in French and English. It is not a static file: it is generated on request from the site's routes and the article list, like the sitemap. A new service appears, a renamed link follows; a test walks every listed URL and fails if one of them stops responding.

Honest dates, not fresh dates

Answer engines take freshness into account - and detect simulated freshness. On a zip deployment, the file modification date becomes the deployment date: every page would look updated on every release. So we generate, in continuous integration, a manifest of each template's real git dates; it feeds the sitemap, the visible "Last updated" lines and the dateModified in the structured data. And when no trustworthy date exists, the rule is simple: show nothing.

The same principle worked against us: our ten blog articles shared an identical update date, left by a bulk edit. Rather than publish that false signal, dateModified was removed from the markup until the real per-article dates were restored.

What code cannot do

Part of GEO happens off the site: official profiles completed under an identical name (LinkedIn, Google Business Profile, registries such as Pappers), a Wikidata entry, reviews on third-party platforms, brand awareness in searches. That is entity work, not code - and it appears as such in our recommendations, for ourselves as for our clients.

What we're measuring

Honestly: it is too early to quantify them, and GEO measurement is still immature. What we track: AI crawler visits in the server logs, referral traffic from assistants, and what ChatGPT or Perplexity answer when asked about our market. What we will not do: invent percentages. When we have data, it will be published with its method, in a follow-up article planned within roughly 90 days.

Discover the AI Search Optimisation (GEO) service