I tried "GEO" on my indie tool — it was just SEO (here's the GSC data) A developer analyzed Google Search Console data for their indie tool Mimi Seed and found that optimizing for generative engine optimization (GEO) is effectively just traditional SEO. The real issue was low discoverability due to lack of external citations and poor technical SEO hygiene, not missing AI-specific markup. After fixing the entity graph, sitemap, and Search Console property, the site saw immediate improvements. 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. I'm building Mimi Seed https://mimi-seed.pryzm.gg , 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 https://github.com/aldegad/awesome-geo whose thesis is blunt: llms.txt is a community proposal. Google doesn't support it and has no plans to. Treating it as mandatory is hype.That last bullet turned out to be the whole game. But I didn't take their word for it — I went to the data. 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: 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. 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 identity is the highest-leverage markup change you can make. 2. A sitemap that isn't lying. My generated sitemap listed anchor URLs — / install , / features , / cli . Here's the detail no tutorial mentions: Google strips the fragment. Every one of those collapses to the same canonical / . They add zero index coverage and just noise. Worse, the sitemap also listed /tool — which my robots.txt disallowed . That's a self-inflicted "Submitted URL blocked by robots.txt" warning. My landing is a single-page app, so the honest sitemap is exactly one URL. I trimmed it to that, then submitted it. Google fetched it within seconds: 0 errors, 1 URL — which is the fragment-dedup behavior proving itself. 3. A dedicated property. I added a URL-prefix property for the subdomain so its impressions/positions stop being averaged in with unrelated sites. Pure reporting hygiene, but you can't improve what you can't see cleanly. Two pitfalls ate more time than the actual SEO work. Next.js caches your public/ file list. Google's verification needed google