Why I Turned My Open-Source GEO Audit CLI Into a SaaS Monitoring Platform

I did not start GEO Optimizer as a SaaS.

I started it as a CLI.

A small, local, inspectable Python tool with one basic question:

Can we audit whether a website is technically and semantically ready to be cited by AI search engines?

That was the first layer.

Run a command.

Get a score.

Read the findings.

Fix the obvious problems.

Run it again.

For developers, that workflow makes sense.

Developers like tools that are local, scriptable, versionable, and easy to inspect. A CLI can be added to CI. It can run inside a terminal. It can produce JSON. It can be tested without a dashboard. It does not need a sales call or an enterprise plan.

That is still the part of the project I care about most.

But the more I worked on GEO Optimizer, the clearer one thing became:

A one-time GEO audit is useful, but AI search visibility is not a one-time problem.

That is why I started building GeoReady.

Not as a replacement for GEO Optimizer.

As the continuity layer on top of it.

The CLI gives control. The SaaS gives continuity.

The CLI is still the core.

It is open source, MIT licensed, and designed for developers who want to audit websites locally.

The SaaS exists because a different problem appears once the first audit is done.

A team does not only need to know:

What is our GEO score today?

It also needs to know:

Did our score drop after the last redesign?

Did a CMS update break structured data?

Did a robots.txt change block an AI crawler?

Did a content refresh improve citation readiness?

Which recommendations were fixed, ignored, or regressed?

Is the site becoming more understandable over time, or just changing?

That is not a CLI-only problem anymore.

That is a monitoring problem.

A CLI can tell you what happened when you ran it.

A SaaS can tell you what changed when nobody was watching.

GEO is not only about being cited once

One of the mistakes I see in early GEO conversations is treating AI search visibility like a fixed ranking position.

It is not.

LLM outputs are unstable.

They are prompt-sensitive, model-sensitive, time-sensitive, retrieval-sensitive, and often non-deterministic.

That does not make measurement useless.

It makes measurement harder.

A single AI answer snapshot is evidence.

It is not the whole truth.

If a model cites your site once, that is useful to know.

If it does not cite you, that is useful too.

But the more important question is usually deeper:

Which underlying signals make a website more likely to be selected, cited, trusted, and reused across changing answer environments?

That is the layer I want GEO Optimizer and GeoReady to focus on.

Not magic citation promises.

Not "rank #1 in ChatGPT."

Not a fake deterministic score for a non-deterministic environment.

The practical layer is signal readiness:

• can the site be crawled?
• can the content be parsed?
• are entities clear?
• is structured data useful?
• are important claims grounded?
• are sources visible?
• is the content extractable?
• are AI discovery paths available?
• are there negative signals?
• can regressions be detected over time?

This is why the SaaS matters.

The CLI can audit those signals.

GeoReady can track them as an operational system.

The problem with one-time audits

A one-time audit is a snapshot.

Snapshots are useful, but they age quickly.

A website changes constantly:

• marketing teams rewrite pages;
• developers ship redesigns;
• plugins update markup;
• CMS editors change headings;
• image alt text disappears;
• canonical tags break;
• structured data becomes stale;
• robots.txt rules change;
• JavaScript rendering assumptions shift;
• landing pages are duplicated;
• product pages lose factual density;
• internal linking gets weaker;
• schema is added but no longer matches the visible content.

In classic SEO, these regressions are already painful.

In GEO, they become even more subtle because the problem is not only ranking.

It is interpretability.

A page can remain online and still become less useful to an AI answer engine.

It may still load.

It may still look good.

It may still rank.

But it may become harder to cite because the source clarity, factual grounding, or semantic structure got weaker.

That is the kind of regression a single audit cannot catch.

What GeoReady adds on top of GEO Optimizer

GeoReady is the web and SaaS layer built around the open-source audit engine.

The public web audit is designed to make the first step easy:

• enter a URL;
• get a 0-100 GEO score;
• see top recommendations;
• inspect part of the signal breakdown;
• decide whether the site is worth improving.

No account is required for the free audit.

That matters because friction kills technical products.

If someone has to create an account before understanding the problem, many people will leave before seeing the value.

The free audit answers:

Is this site visibly weak or reasonably prepared?

The SaaS layer answers a different question:

Is this site improving or regressing over time?

That is why the product direction includes:

• full 8-category reports;
• weekly monitoring;
• score history;
• regression alerts;
• PDF exports;
• API access;
• multi-domain monitoring;
• competitor comparison;
• team workflows;
• AI search snapshots;
• citation quality scoring.

Not all of that should live in the CLI.

Some of it requires storage.

Some of it requires scheduled runs.

Some of it requires account-level history.

Some of it requires alerts.

Some of it only becomes useful when a team can look back and see how the site changed over time.

Keeping the core open source

This was important to me from the beginning.

I do not want GEO to become a black box category where every tool says:

Trust our proprietary score.

That is not healthy for developers, SEO specialists, founders, agencies, or content teams.

If we are going to build tools that evaluate AI search visibility, the methodology should be inspectable.

The scoring logic should be discussable.

The assumptions should be visible.

The false positives should be debuggable.

The CLI should remain useful even if someone never becomes a SaaS customer.

That is why the core remains open source.

GEO Optimizer is the engine.

GeoReady is the operational layer.

The distinction matters.

The open-source project is for local audits, CI/CD workflows, experimentation, research, and transparency.

The SaaS is for continuity: monitoring, history, alerts, reports, exports, and team workflows.

That is the model I am trying to build.

Not open source as a marketing trick.

Open source as the foundation.

Why the JSON contract matters

One of the less glamorous but very important parts of the 4.12.x series is the JSON contract.

As soon as a CLI becomes the foundation for a web product, the output cannot be casual anymore.

A command-line report can be flexible.

A web platform needs stable data.

The frontend needs predictable fields.

API users need predictable fields.

Tests need predictable fixtures.

Reports need stable structures.

Monitoring needs comparable values over time.

If the audit response shape changes randomly, everything above the engine becomes fragile.

That is why the JSON contract matters.

In the 4.12.x series, the audit API response now includes a schema version and a more stable structure for score breakdowns and checks.

This is not the kind of feature that gets attention on social media.

But it is the kind of feature that makes the product real.

A SaaS cannot be built on vibes.

It needs contracts.

It needs regression tests.

It needs compatibility rules.

It needs stable boundaries between engine, API, frontend, and reporting.

That was one of the main lessons from turning the CLI into a platform.

Why v4.12.2 matters

v4.12.2 is not a flashy release.

It fixes a CI/PyPI publishing blocker related to FastAPI imports in tests.

That may sound small, but it matters because it unblocked the 4.12.x series on PyPI.

It also means the package can ship with the important 4.12.0 work included:

• Google AI scoring realignment;
• JSON contract v1;
• frontend redesign;
• safer web/API contract behavior.

The Google AI scoring realignment is especially important.

I do not want GEO Optimizer to reward signals for Google AI that Google does not claim to use.

So the Google AI lens was adjusted away from rewarding AI-specific files such as llms.txt or ai.txt for Google AI, and toward signals that are more aligned with Google's documented guidance: freshness, server-rendered accessible content, descriptive alt text, schema, and entity clarity.

That is a practical example of how I want this project to evolve.

Not by adding fashionable checks.

By making the scoring more defensible.

GEO and SEO are converging

I do not think GEO replaces SEO.

I think GEO makes SEO more layered.

A user may ask an AI system:

Is this product any good?

Then they may verify the answer on Google.

They may check reviews.

They may open the website.

They may compare competitors.

They may look for documentation, pricing, schema-rich snippets, author information, support pages, and reputation signals.

If a brand is visible in AI answers but weak in classic search, the citation may not convert.

If a brand is strong in SEO but absent from AI-generated answers, it may lose the first-answer layer.

The same content pipeline increasingly needs to serve both:

• traditional crawlability;
• structured data;
• helpful content;
• entity clarity;
• citation readiness;
• factual grounding;
• AI answer extractability;
• trust and verification signals.

That is why I do not see GeoReady as a traditional SEO tool.

It is not trying to replace rank trackers, backlink tools, or keyword research platforms.

It is trying to answer a more specific question:

Can AI answer engines read, understand, trust, and cite this site?

And then:

Is that readiness improving or getting worse over time?

The SaaS is not only a dashboard

It would be easy to build a dashboard that displays a score and call it a SaaS.

That is not enough.

A score is only useful if it leads to action.

For GeoReady, the product loop I care about is:

1. audit the site;
2. identify weak signals;
3. prioritize fixes;
4. apply changes;
5. re-audit;
6. compare the difference;
7. monitor the domain;
8. alert when regressions happen;
9. report progress to a client, team, or founder.

That loop is much more valuable than a static number.

The score is the entry point.

The workflow is the product.

Where this is going

The near-term direction is straightforward:

• improve the public audit experience;
• make recommendations more actionable;
• strengthen report clarity;
• keep the CLI reliable and free;
• improve the web platform;
• expand monitoring and history;
• make alerts useful instead of noisy;
• expose better API workflows;
• support agencies and consultants managing multiple domains;
• keep the scoring methodology transparent.

The longer-term direction is more ambitious:

• compare AI search snapshots across systems;
• score citation quality, not just citation presence;
• detect factual accuracy risks;
• track brand/entity representation;
• connect audit results with content workflows;
• support CI/CD checks for AI search readiness;
• make GEO measurable without pretending it is deterministic.

That last part matters.

I do not want to pretend that AI search works like a stable list of ten blue links.

It does not.

But I also do not believe the correct response is to stop measuring.

The correct response is to measure differently.

The product principle

The principle I keep coming back to is this:

Open source for trust. SaaS for continuity.

The open-source engine keeps the methodology visible.

The SaaS turns the audit into an ongoing operational workflow.

That is the balance I want.

A local CLI is perfect for developers who want control.

A web audit is perfect for fast diagnosis.

A SaaS monitoring layer is useful when the problem becomes continuous.

Those are not competing products.

They are different layers of the same system.

Try it

You can try the public audit here:

https://geoready.dev?utm_source=dev.to&utm_medium=dev.to&utm_campaign=dev_to_saas_article&utm_content=dev_to_article_saas_ded

You can create an account for the platform here:

[https://app.geoready.dev?utm_source=dev.to&utm_medium=dev.to&utm_campaign=dev_to_saas_registration&utm_content=dev_to_article_saas_ded_reg]https://app.geoready.dev

You can inspect the open-source engine here:

https://github.com/Auriti-Labs/geo-optimizer-skill

You can install the CLI with:

pip install geo-optimizer-skill==4.12.2

Or with the web extra:

pip install "geo-optimizer-skill[web]==4.12.2"

If you are building in SEO, GEO, AI search, content operations, or developer tooling, I would be especially interested in feedback on one question:

What should a GEO monitoring platform help you fix after it tells you that your site is invisible or weak?

Because that is the part I think matters most.

Not only tracking visibility.

Improving the signals behind it.