I tried "GEO" on my indie tool — it was just SEO (here's the GSC data)

Every other newsletter this year told me my SaaS needed GEO — Generative Engine Optimization. Write an llms.txt . Add "AI-only" schema. Chunk your content for the models. So before sinking a weekend into it, I read one contrarian source, opened Google Search Console for my tool, and looked at the actual numbers. The verdict was boring and freeing: for Google, optimizing for AI answers is still just SEO . The real problem wasn't my markup — it was that almost nothing about my site was discoverable in the first place. Here's the data, the three fixes that mattered, and the two places I face-planted. Why I didn't buy the GEO hype I'm building Mimi Seed , an open-source MCP server that lets indie devs drive Play Store / App Store / Firebase releases from inside Claude Code or Codex. Classic indie-hacker situation: tiny audience, and a constant temptation to chase the shiny new growth lever. The single most useful thing I read was a curated list ( awesome-geo ) whose thesis is blunt: most "GEO" advice is repackaged SEO with a markup tax. Their reading of the primary docs: Google has publicly said optimizing for AI Overviews is the same SEO you already know. No special schema required. llms.txt is a community proposal. Google doesn't support it and has no plans to. Treating it as mandatory is hype. The one engine that does ask for special treatment is Bing/Copilot (FAQ markup, tables, IndexNow). The actual common denominator across every engine: clear authorship, a consistent entity identity, canonical URLs, and being cited by trustworthy external sources. That last bullet turned out to be the whole game. But I didn't take their word for it — I went to the data. What GSC actually told me My landing page lives on a subdomain. I didn't even have a dedicated Search Console property for it — it was rolled up under the parent domain property. So I queried the parent property and filtered to just my pages. Ninety days: One URL had any impressions: the homepage. 19 impressions, 0 clicks, average position 6.2. The query breakdown came back empty. Every one of those 19 impressions was below GSC's anonymization threshold — i.e., low-volume brand-ish searches. Zero non-brand discovery. URL inspection: the homepage was indexed, canonical correct, crawled fine. So indexing wasn't broken. Referring URLs: exactly one — libraries.io , an npm mirror. My entire backlink profile was an auto-generated package page. This reframed everything. My problem was never snippet wording or AI-readability. You can't optimize the click-through rate of a result nobody sees. The bottleneck was impressions — being found at all — and the lever for that, per the data and the contrarian list, is external citations , not markup. And one more thing I'd half-ignored: my sitemap had never been submitted to Search Console. It existed at /sitemap.xml , generated by the framework, registered nowhere. The three fixes that were actually SEO No llms.txt . No secret AI schema. Just hygiene: 1. A real entity graph. My JSON-LD was a lone SoftwareApplication object. I replaced it with a proper @graph tying together Organization + WebSite + SoftwareApplication , and — the part that matters for both SEO and "GEO" — a sameAs array linking the GitHub repo and both npm packages. { "@context" : "https://schema.org" , "@graph" : [ { "@type" : "Organization" , "@id" : "https://example.com/#organization" , "name" : "Mimi Seed" , "sameAs" : [ "https://github.com/jeonghwanko/mimi-seed-sdk" , "https://www.npmjs.com/package/mimi-seed" , "https://www.npmjs.com/package/@yoonion/mimi-seed-mcp" ] }, { "@type" : "WebSite" , "publisher" : { "@id" : "https://example.com/#organization" } }, { "@type" : "SoftwareApplication" , "publisher" : { "@id" : "https://example.com/#organization" } } ] } sameAs is the literal mechanism for telling a search/answer engine "the website, the GitHub org, and the npm packages are all the same entity." For a project that recently went through a rename, consolidating that i