geo-optimizer-skill: A CLI That Scores Whether AI Engines Can Cite Your Site

The gap geo-optimizer-skill targets: ranking on Google while staying invisible to ChatGPT

Traditional SEO tooling answers a ranking question. The README frames GEO Optimizer around a different one: whether an answer engine can crawl, parse and cite a page when it composes a response. The project's own example is a mortgage calculator query where ChatGPT attributes a formula to a competitor, and the site that ranks first on Google never appears. That is the problem statement, and it is narrower than general SEO. The README cites an Ahrefs figure that 28.3% of ChatGPT's most-cited pages have zero organic visibility on Google, which is the strongest argument for treating AI citability as a separate axis rather than a byproduct of rankings. The intended users are developers and automation-minded SEO specialists: people who want a command that returns a number and a fix list, not a dashboard. The README lists the disciplines it covers under one tool (AEO, GEO, AI SEO, LLM SEO, AI visibility), which is mostly naming convenience. The underlying checks are the same set of technical and structural signals regardless of which acronym brought you there.

What the audit actually inspects: robots.txt bot rules, llms.txt, JSON-LD and citability patterns

The scoring model is described as 8 categories covering 47 methods, drawing on two papers the README links (Princeton KDD 2024 and AutoGEO ICLR 2026). The named signal families are specific: robots.txt permissions for AI crawlers, presence and depth of an llms.txt file, JSON-LD schema richness, brand entity coherence, multi-page topical authority, and content citability. That list matters because it tells you what the tool can and cannot see. It is a fetch-and-parse audit of publicly reachable artifacts, not a rendering engine and not a log analysis tool. If your schema is injected client-side, or your llms.txt is generated at request time behind auth, the audit sees whatever the fetcher receives. The README cites a Semrush test on GPT-4 claiming JSON-LD lifts LLM extraction accuracy from 16% to 54%, which is the justification for weighting structured data heavily. Treat that as a cited third-party result, not a measurement this project performed. The 47-method count is a claim from the README; the repository does not expose the weighting per method in the material available here, so the practical way to understand the score is to run it and read the JSON output.

Running an audit: uvx, geo audit, and the citation subcommand

The README's zero-install path is a single command: uvx --from geo-optimizer-skill geo audit --url https://yoursite.com. That requires uv on the machine. The package is also on PyPI as geo-optimizer-skill and declares Python 3.9 or newer. The second workflow the README documents is geo citations, which queries real answer engines with questions you supply and reports whether your brand is mentioned and your domain cited, plus which competitors appear instead. That subcommand is the part with an external dependency: it needs credentials for the engines it queries, and the README does not spell out the key names in the excerpt available here, so check the documentation site before assuming it runs unauthenticated. Beyond the CLI, the project ships four consumption modes: command line, Python library, MCP server, and an Astro integration. The README states 16 CLI commands and 7 output formats, which is what makes CI wiring plausible: you get machine-readable output rather than a terminal report only. The MCP server path matters if you drive Claude or another MCP-capable client and want the audit callable as a tool rather than a shell step.

The citation check is the weakest link, and the README is thin on it

Everything in geo citations depends on answer engines that change their models, their retrieval, and their API terms without notice. A brand mention today is not a stable metric, and the README does not describe how many queries per run, how results are deduplicated, or how it distinguishes a passing mention from a cited source. Those are the details that determine whether the output is a trend line or noise. The audit side has the opposite problem in miniature: it is reproducible because it parses static artifacts, but that also means it cannot tell you why a well-structured page is not being cited. A perfect score with zero citations is a possible outcome, and the tool does not resolve that tension for you. The README's own framing acknowledges the split, positioning the CLI as a local audit engine and the hosted GeoReady platform as the layer that adds monitoring, score history and regression alerts. That division is honest, and it is also the clearest statement of the CLI's ceiling.

Where a static analyzer loses to a rendering-aware crawler

The obvious alternative for the crawl-and-parse half is a general site crawler such as Screaming Frog or a Lighthouse-based pipeline, extended with custom rules for llms.txt and AI bot directives in robots.txt. The difference is architectural: a rendering crawler executes JavaScript and reports what a browser sees, while this tool's audit reads fetched documents. For server-rendered sites the two converge. For client-rendered sites they diverge sharply, and the divergence is exactly where AI crawlers also struggle, which cuts both ways: the tool may under-report your markup, but it may also be mirroring a real obstacle. On the citation side the alternative is manual spot-checking in ChatGPT, Perplexity and Gemini, which costs human time per query and cannot be scheduled. Neither alternative is strictly better. The general crawler gives you rendering and a broader technical SEO surface; this project gives you AI-specific checks and a single score you can gate a build on. If you already run a rendering crawler, the honest question is whether adding a second tool for six or seven AI-specific signals is worth the pipeline surface.

Maintenance, release cadence and what MIT means here

The release history is dense: v4.16.4 in mid-August 2026, v4.17.0 and v4.17.1 within days of each other at the end of that month, with the last push dated 2026-09-05. Patch notes mention dogfooding fixes, a check-drift command and schema templates. A cadence that tight means upgrade cost is real: pin the version in CI rather than tracking latest, because a scoring change can move your threshold and fail a build that passed the day before. The check-drift command name suggests the project expects its own checks to change over time, which is consistent with a field where the engine behaviour being measured is a moving target. The licence is MIT, which permits commercial use and modification with attribution and no warranty. That covers the CLI and the library. It does not cover the hosted GeoReady service, which the README prices from $19 per month for Pro, Studio and Agency tiers. If you need monitoring, score history and regression alerts, you are buying a subscription, not exercising the MIT grant. Nothing here is legal advice; read the LICENSE file and the platform terms separately.

Test count, research citations and other claims worth separating from evidence

The README leads with 1,720 tests in one place and 1,788 in another, alongside a badge claiming 1788 passed. That inconsistency is minor but worth noting, because it is the kind of thing that tells you the badges are maintained by hand. The academic citations (KDD 2024, ICLR 2026) support the method selection, not this implementation's correctness; the papers describe what tends to work, and the mapping from paper to the 47 methods is the project's own interpretation. The 28.3% and 16-to-54% figures come from Ahrefs and Semrush respectively, quoted secondhand. None of that undermines the tool, but it does mean the score should be read as a heuristic index built on published research, not as a calibrated measurement of citation probability. The most useful thing the project publishes is not the number. It is the fix list: robots.txt rules, an llms.txt, JSON-LD templates. Those are artifacts you can inspect, diff and commit, and they are where the tool's value survives a scoring change.

Editorial conclusion

Adopt geo-optimizer-skill if you already ship a site, want a repeatable AI-readiness check in CI, and are willing to verify the 0-100 score against your own crawl data before trusting it. Do not adopt it if you need guaranteed citation monitoring without configuring keys for OpenAI, Perplexity or Gemini, or if your site is a JavaScript-rendered single-page app whose HTML the fetcher cannot read. Before wiring it into a pipeline, run geo audit on one URL, read the JSON output, and confirm that the category weights match the signals you actually control.

Official sources

1. Auriti-Labs/geo-optimizer-skill on GitHub
2. License: MIT
3. Project website
4. README
5. Releases