GEO case study: how Gemini came to cite OptimyCloud

In October 2026, a cloud engineer working on a GEO project asked Gemini to name ten companies specializing in the field. OptimyCloud came fourth. He then reached out to me on LinkedIn.

OptimyCloud is the static website of an independent consultant, with no agency and no marketing team behind it. This article walks through what was done on the site, month by month, with the real Google Search Console numbers. It also covers what it did not produce, because that is the most useful part for anyone considering GEO work.

Context

OptimyCloud is the consulting business of Alexandre Gillon, a freelance cloud and AI engineer. The site was created in August 2025: static HTML compiled with Tailwind, no CMS. That choice matters for what follows. Every page is served as is, with no JavaScript needed to display the content, which makes it readable by any crawler, AI crawlers included.

GEO (Generative Engine Optimization) covers the practices that make a site understandable and quotable by answer engines: ChatGPT, Gemini, Perplexity, Google AI Overviews. The ground rule for this site was simple: apply to it, first, everything I later recommend to clients.

Starting point

From September 2025 to February 2026, the site exists but Google hardly ever shows it: between 68 and 212 impressions a month, between 1 and 4 clicks. A clean, fast brochure site, but with no in-depth content, no connected structured data and nothing that sets it apart for a search engine.

What was done, in order

The dates below come from the site's Git history. Nothing was done in one go: each step is a dated, verifiable change.

1. August 2025

   Site created in static HTML, no CMS.

2. February 27, 2026

   AI services, a Projects section, the blog and a first llms.txt. The site stops being a plain brochure and starts publishing.

3. March 12, 2026

   Site-wide SEO audit fixes and a Schema.org @graph in JSON-LD: the Organization, Person and Service entities are linked to each other by identifier, on every page.

4. March 15, 2026

   The llms.txt guide is published, along with an llms-full.txt and a robots.txt that explicitly allows AI crawlers: GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended.

5. March 21, 2026

   E-E-A-T markers (author, credentials) and internal linking on every blog article.

6. February to April 2026, then July

   About a dozen practical articles: a WhatsApp AI assistant, EKS Auto Mode, the WordPress 500 error, FinOps audits, chatbot pricing, AI agents… Two more follow in July 2026.

7. June 8, 2026

   Full English version of the site, under /en/, with matching hreflang tags.

8. October 18, 2026

   OAI-SearchBot allowed, the GEO audit offer page published, the llms.txt guide refreshed.

Results: the Search Console numbers

Data from the sc-domain:optimycloud.com property, up to October 17, 2026. October is therefore a partial month (1st to 17th).

Three steps stand out in this table. In March 2026, the month of the SEO fixes, the Schema.org @graph and the llms.txt guide, impressions go from 212 to 719. In April, as articles pile up, they pass 2,000. In June, the month the English version went live, they more than triple, then peak at 14,728 in August.

The page carrying most of that visibility is the llms.txt guide: roughly 24,000 impressions across its French and English versions. It is by far the site's top page.

What it actually brings: citations, not clicks

124 clicks for 55,814 impressions is a click-through rate of about 0.2%. On its own, that figure is disappointing. It gets interesting when you look at who generates those impressions.

Out of about 900 distinct queries, 162 are clearly written by machines: long natural-language questions that AI assistants send to Google on behalf of their users. They add up to about 2,700 impressions. 66 of them are about GEO or llms.txt, often with an average position between 1 and 6, in English, French, German and Spanish.

Those 162 queries generated zero clicks. That makes sense: the assistant reads the results, builds an answer and hands it to the user, who never visits the page. The first query in the table says a lot. Someone asked their assistant to find an agency for this kind of work, and the assistant went looking on Google, where OptimyCloud ranked around second.

I cannot prove which specific signal led Gemini to pick OptimyCloud. What the data does show is that assistants query Google on this topic and that the site sits near the top of the results they read. Being in that pool of candidate pages is the precondition for being named in the answer. The rest, meaning the model's final choice, cannot be measured from the outside.

What I take away, and the limits

A case study that only shows the good numbers is useless. Here is what to keep in mind before drawing conclusions.

With those caveats, four lessons emerge.

• Publish first-party data. The site's most-viewed page is a practical guide that answers a precise question with concrete examples, which is why, in October 2026, we added our own Search Console numbers to it rather than a summary of what you can read elsewhere. An answer engine needs a source to cite; an original figure makes you one.
• Declare clear entities. Who the author is, what the organization is, which services it offers: the Schema.org @graph states it unambiguously, with the same identifiers on every page.
• Let the crawlers in. A robots.txt that explicitly allows AI crawlers, plus an llms.txt and an llms-full.txt that give them a usable summary. That is the minimum, and many sites still block these crawlers without knowing it.
• Write fact-dense content. Dates, numbers, precise configurations. Passages that answer a question in two verifiable sentences are the ones an assistant can reuse.