DEV Community: Juan Camilo Auriti

My CI hadn't run a single one of those tests in two months and stayed green the whole time

Juan Camilo Auriti — Wed, 23 Sep 2026 11:00:00 +0000

I added a dependency to a test helper and forgot to declare it in the dev extra. Locally it was already installed, so everything passed. In CI it wasn't, and the tests that needed it did not fail.

They skipped.

Skips exit 0. The checkmark stayed green for two months.

Why it skips instead of failing

The pattern is one line, it's in every codebase, and it's usually correct:

aiosqlite = pytest.importorskip("aiosqlite")

That line means: this test needs something optional, and if it isn't here, move on. Which is right when the dependency is genuinely optional — a test for the Postgres backend on a machine with no Postgres shouldn't fail the build.

The problem is what it looks like from outside. importorskip is a decision that the test is optional, taken at import time, and the only place it surfaces is a number in a summary line nobody reads:

1284 passed, 168 skipped in 42.11s

168 skipped. Two months earlier it was 6. Nothing in that output tells you which number is the anomaly, and the exit code is 0 either way.

After declaring the dependency, the same suite reported 1452 passed. The 168 hadn't been slowly rotting. They'd stopped running all at once, on a specific commit, and the build had been green through every one of them.

The part that stung

I had a suite I trusted. I merged on green. The whole point of the suite was to tell me when I broke something, and for two months it had quietly stopped being able to.

Nothing was misconfigured. No warning. No deprecation. CI did exactly what it was asked. The failure mode was that the number of tests it ran was never something anyone asserted on.

The guard

There is no --min-tests flag. There is a hook, and it's eight lines:

# conftest.py
MIN_TESTS = 1400

def pytest_sessionfinish(session, exitstatus):
    collected = session.testscollected
    if collected < MIN_TESTS and not session.config.option.collectonly:
        session.exitstatus = 1
        print(f"\nFAIL: {collected} tests collected, floor is {MIN_TESTS}. "
              f"Did a dependency stop resolving?")

Three notes on that, all learned by getting it wrong.

testscollected, not passed. You want to catch tests that vanished, and a skipped test still counts as collected — so this alone would not have caught my bug. Which brings me to the second guard, below. Use the floor to catch tests that disappear from collection entirely (a broken import in a conftest, a renamed directory, a bad -k), because that's the failure that turns a 1452-test suite into 3 without a word.

Guard collectonly. Without it, pytest --collect-only in a subset trips your own floor and you'll waste twenty minutes.

Set the floor slightly below current, and raise it. Not at current — every new branch that hasn't added a test yet will fail. Below, and bump it when it drifts far.

For the skip case specifically, the guard is different and simpler:

# pytest.ini
[pytest]
addopts = -rs

-rs prints the reason for every skip. It doesn't fail anything — it just puts SKIPPED [168] tests/conftest.py:14: could not import 'aiosqlite' in the log where a human can see it. Two months of my logs had that line. I never read them, because they were green.

If you want it to actually fail, the strict version:

def pytest_sessionfinish(session, exitstatus):
    skipped = len(session.config.pluginmanager.get_plugin("terminalreporter").stats.get("skipped", []))
    if skipped > MAX_SKIPS:
        session.exitstatus = 1

I don't use that one. It fights with legitimately environment-dependent tests and I got tired of tuning MAX_SKIPS. The floor plus -rs was enough.

The real fix was upstream of all of it

The guards catch the symptom. The cause was that a dependency my tests could not run without was declared as though they could.

# before — aiosqlite nowhere, importorskip papers over it
[project.optional-dependencies]
dev = ["pytest", "pytest-cov", "ruff"]

# after
dev = ["pytest", "pytest-cov", "ruff", "aiosqlite"]

And then delete the importorskip for it. If the suite requires it, importorskip is a lie that makes the requirement look like a preference.

That's the rule I took away: importorskip is for dependencies you have decided the test can run without. If you haven't made that decision deliberately, you've made it accidentally.

Check yours in one command

If you have a CI suite you trust, this tells you the number you've never looked at:

pytest --collect-only -q 2>&1 | tail -1

Compare it to what you'd have guessed. Then run the real suite with -rs and read the skip reasons — all of them, once. Mine had a two-month-old import error sitting in plain text under a green checkmark.

The uncomfortable general version: every green build asserts that the tests that ran, passed. None of them assert that the tests ran.

example.com and example.com/ were two rows, and 86.9% of my database was one bug

Juan Camilo Auriti — Tue, 22 Sep 2026 11:00:00 +0000

A scheduled job re-audited domains on an interval. Cheap, idempotent, ran for weeks without complaint.

Then I looked at row counts. One domain had 1831 audit rows. It should have had a few dozen.

The bug

Two rows in the domains table:

example.com
example.com/

A unique index on the URL column. Both rows satisfy it — they're different strings. The database was doing exactly what I asked.

The job then did roughly this: take a domain, run the audit, write the result keyed by the URL the audit resolved to. The audit followed redirects and normalized. So it read example.com and wrote example.com/.

Next tick: example.com still has no recent result — the result went to the other row. Audit it again. Write to the slashed row again.

Nothing errored. Every individual run was correct. The loop simply never converged, because the key it read by and the key it wrote by were never the same key.

Across the table, rows attributable to this were 86.9% of all audit rows. Not 86.9% of one domain. Of the table.

Why it stayed invisible

Every signal I had was pointed the wrong way.

No errors. Each audit succeeded. Logs were clean.

The unique index looked like protection. I had convinced myself duplicates were structurally impossible, so when I saw two similar rows my first thought was that I was misreading the query.

Cost looked like growth. Audit volume climbing looked like the product being used. It was the same handful of domains being re-audited forever. That one stings — I had a metric moving in the right direction for entirely the wrong reason, and I felt good about it for weeks.

Per-domain views looked fine. Open one domain, see a sane history. The pathology only appears when you group by normalized key and compare against raw key, which is not a query anyone writes by accident.

The fix

Normalize at the boundary, once, before anything touches storage.

import re
from urllib.parse import urlsplit

SCHEME_RE = re.compile(r"^[a-z][a-z0-9+.\-]*://", re.I)

def normalize(url: str) -> str:
    url = url.strip()
    if not SCHEME_RE.match(url):
        url = "https://" + url
    p = urlsplit(url)
    host = (p.hostname or "").lower()
    if host.startswith("www."):
        host = host[4:]
    if not host:
        raise ValueError(f"no host in {url!r}")
    port = f":{p.port}" if p.port and p.port not in (80, 443) else ""
    path = p.path.rstrip("/") or "/"
    return f"{p.scheme.lower()}://{host}{port}{path}"

Two load-bearing details, and I got one of them wrong the first time I wrote this out.

rstrip("/") or "/". Strip the trailing slash, but if that leaves an empty path, put one back — so the root is always exactly / and never the empty string. Without the or "/" you've just invented a third spelling of the same page and replaced the bug with a subtler one.

The scheme has to go on before urlsplit, not after. urlsplit("example.com") does not give you a host. With no //, it reads the whole string as a path — hostname comes back None. My first version handled that with p.hostname or "", which silently produced a URL with no host in it at all, for the single most common input a user types by hand. The SCHEME_RE prepend fixes it; the raise makes sure that if a host is still missing, I hear about it instead of storing something shaped like a URL.

That second one is the same class of bug as the story above: a value that's wrong but well-formed enough to store, so nothing complains.

Two rules that matter more than the function:

One normalizer, called at the boundary. Not in the job, not in the API handler, not in the audit. In the one place a URL becomes a record. Every additional call site is a chance for two of them to disagree, which is the bug again wearing a different hat.

Normalize before the uniqueness check, not after. A unique index only protects the shape you hand it. Mine was enforcing uniqueness on a key I hadn't canonicalized, which is enforcement theater.

Then backfill: normalize existing rows, merge collisions, keep the earliest created_at and the most recent result. The 1831-row domain came out at 19.

Careful with `www` and `rstrip`

Two things in that function are opinions, not facts, and you should hold them deliberately.

Dropping www treats www.example.com and example.com as the same entity. Almost always what you want, because almost every site redirects one to the other. Not universally true — if a host serves genuinely different content on the two, this merges two things that aren't one.

Stripping the trailing path slash treats /about and /about/ as the same page. Also almost always right, also not guaranteed by HTTP. Two different resources at those two paths is legal and rude, and it exists.

I took both trade-offs on purpose. The cost of merging two things that were actually one is a slightly wrong row. The cost of not merging is what I just described.

The transferable part

The trailing slash isn't the lesson. The lesson is the shape: a loop that reads by one key and writes by another will never terminate, and will never raise.

If you have a scheduled job that's supposed to converge, the question to ask isn't "is it erroring." It's: is the key I select by byte-identical to the key I write by? If a normalizer, a redirect, or a .lower() sits between the read and the write, the answer is no, and the job will run forever while every individual execution looks correct.

Cheapest check available — group by normalized key, count distinct raw keys:

SELECT lower(rtrim(url, '/')) AS norm, count(DISTINCT url) AS spellings, count(*) AS rows
FROM domains GROUP BY 1 HAVING count(DISTINCT url) > 1 ORDER BY rows DESC;

If that returns anything, you have the bug. It took me weeks to think of running it.

Tomorrow, outside this series: my CI hadn't run a chunk of my test suite in two months, and the checkmark was green the whole time.

Your JSON-LD is probably inside a @graph, and most parsers don't look there

Juan Camilo Auriti — Mon, 21 Sep 2026 11:00:00 +0000

There are two shapes a page can hand you its structured data in, and if you only handle the first one you will report that a correctly marked-up page has no structured data at all.

Shape one, the one every tutorial shows:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "..."
}

Shape two, the one a large share of the real web actually emits:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "name": "..." },
    { "@type": "WebSite", "url": "..." },
    { "@type": "WebPage", "@id": "..." },
    { "@type": "Article", "headline": "..." }
  ]
}

Shape two has no top-level @type. A check written as data['@type'] == 'Article' returns false. Not "malformed" — false. The page looks empty.

Who emits shape two

Yoast SEO and RankMath both do, by default, and they don't offer a flat-output mode. Between them that's a very large fraction of every WordPress site with an SEO plugin, which is a very large fraction of the web.

And it's the better shape. The @graph form lets nodes reference each other by @id — the Article points at the WebPage it lives on, which points at the WebSite, which points at the publishing Organization. One entity graph instead of four disconnected islands repeating the same publisher name. Both plugins are right to emit it.

Which makes a parser that can't read it entirely the parser's problem.

It also makes shape one — the shape in every tutorial — the shape almost nobody's CMS actually produces. Including in my own writing: I've handed out Organization + WebSite JSON-LD templates twice on this site, in How to Make Your Site Quotable by AI in 30 Minutes and in The 4-Layer Model for AI Search Readiness, and both are flat. They're correct — a flat block is valid, and if you're adding JSON-LD by hand to a page that has none, it's the right thing to write.

They just aren't what you'll find when you go read a page that already has markup. If you followed either of those posts on a WordPress site with Yoast installed, your plugin was already emitting a @graph and your hand-written block landed next to it, which is a different situation than the one I described. That's on me, and it's the gap this post exists to close.

How many parsers get it wrong

I tested twelve structured-data detectors — validators, audit tools, citability checkers, some open source and some hosted — against the same page, once with flat JSON-LD and once with the same types wrapped in a @graph.

Nine of the twelve reported no structured data on the @graph version.

Including mine. My own tool had this bug, which is the only reason I went looking. A page I knew had good markup was scoring zero on schema, and my first assumption was that the page was broken.

The fix is boring

Flatten before you inspect. Once, at the parse boundary, so no downstream check has to know about either shape:

def iter_nodes(data):
    """Yield every schema.org node, flat or @graph, at any nesting depth."""
    if isinstance(data, list):
        for item in data:
            yield from iter_nodes(item)
    elif isinstance(data, dict):
        if "@graph" in data:
            yield from iter_nodes(data["@graph"])
        if "@type" in data:
            yield data

Three things worth pointing out.

data can be a list at the top level. A page is allowed to ship several <script type="application/ld+json"> blocks, and some CMSes put an array in one block. Handle it or you'll drop everything after the first.

The @graph check runs before the @type check, and both run — not elif. A node can legitimately carry its own @type and nest a @graph. Using elif there is how you silently drop half a graph.

Recursion, not one level of unwrapping. I have seen @graph inside @graph. Rare, but it costs nothing to handle.

Then every check downstream stops caring:

types = {n["@type"] for n in iter_nodes(payload) if isinstance(n.get("@type"), str)}

The isinstance guard is there because @type is allowed to be an array — "@type": ["Person", "Organization"] is valid, and a bare set comprehension will throw an unhashable-type error on it the first time a real page hands you one.

Check your own page in ten seconds

Paste into the console on any page you own:

[...document.querySelectorAll('script[type="application/ld+json"]')]
  .map(s => JSON.parse(s.textContent))
  .forEach(d => console.log(d['@graph'] ? '@graph, ' + d['@graph'].length + ' nodes' : 'flat, ' + d['@type']))

If it prints @graph, then any tool that told you your structured data was missing was telling you about itself.

Why I care about this beyond my own bug

The reason a parser bug is worth a thousand words: the check that's wrong is usually the one you trust to tell you something is wrong.

I spent a while assuming a page was badly marked up because a tool said so. The tool was the broken thing. That failure mode is much worse than a false negative on a real problem, because it points you at the wrong file and you fix something that was never broken.

So when an audit tool tells you a page has no structured data, and you can see the JSON-LD in the source with your own eyes, believe your eyes and check the shape first.

Next in this series: two URLs that differed by one trailing character, and the re-audit loop that ate 86.9% of my database.

A prompt told me my tool was built on a product that doesn't exist

Juan Camilo Auriti — Fri, 18 Sep 2026 11:00:00 +0000

I ran a comparison prompt against Gemini to see how it described the CLI I maintain. It came back with this:

a "Local SEO & AI Indexing" tool, built on top of Scrapeless

Two claims, both wrong. It isn't a local SEO tool, and there is no Scrapeless anywhere underneath it — no dependency, no API call, no mention in the repo. The model hadn't hallucinated freely, though. It had resolved an ambiguity, and picked the wrong branch.

I've written before that entity clarity is one of the things AI search actually optimizes for. That post made the case in the abstract. This is the same problem arriving on my own doorstep with a vendor name attached, which turned out to be considerably more instructive.

The ambiguity

The tool does GEO — Generative Engine Optimization. Getting pages cited by AI assistants.

GEO is also, to most of the indexed web, short for geographic.

I went looking for how the acronym actually appears in the corpus a model would have read, and the collision is everywhere. Repositories describe themselves with phrases like "SERP monitoring and GEO tracking" and "geographic research and AI indexing" — using GEO and geographic interchangeably, in the same sentence as SEO and AI. A model reading a bare GEO with no disambiguating context nearby has two live readings, and the geographic one has vastly more mass behind it.

Once it picks that branch, it needs a vendor that fits. So it attaches whichever product occupies the local-SEO-plus-scraping space. That's where Scrapeless came from. The model didn't invent a dependency; it filled a slot the wrong reading had opened.

The counter-evidence that told me it was fixable

Here's the part that turned this from "models are unreliable" into an actionable bug.

Prompts that already carried context — anything containing open-source, CLI, Python — described the product correctly. Same model, same product, same week. The difference was entirely in whether the surrounding tokens ruled the geographic reading out before resolution happened.

That reframes the problem. The model wasn't refusing to understand. It was resolving an ambiguity I had left open, and it resolved it against me whenever nothing nearby closed it.

Which means the fix isn't more content. It's adjacency.

The fix

I put the expansion next to the name in the places a model reads first, and nowhere else.

The hero paragraph. It now states what the thing is in a full sentence, in the first block of body text. This had a second benefit I hadn't planned: an entity-disambiguation check wants a definition sentence — subject, copula, category — somewhere in the content. The page didn't have one. Now it does.

The meta description. This one cost something. The description was already at the limit, so fitting the expansion meant dropping the list of supported engines. 152 characters now, under the 160 the tests enforce. I traded a feature list for a definition, deliberately.

The JSON-LD graph. Organization already carried the full name. WebSite and WebApplication didn't — they had the bare brand. A model walking the graph would hit two nodes that reintroduced the exact ambiguity the hero had just resolved. Both now carry it.

What I deliberately didn't touch

The titles. They sit at 57 characters against a 60-character cap. There is no room to add nineteen characters, and pushing the brand later in the title to make space costs more in the search result than the disambiguation gains. Titles stayed.

The README, the package description, llms.txt. All three already spelled it out. That's part of why this was confusing at first — the expansion existed in plenty of places. It just wasn't in the places that get read first, next to the name, on the page a model lands on.

That distinction is the whole lesson. Coverage isn't the metric. Position relative to the entity is.

What it measured

Measured on the built HTML, before and after:

check	before	after
entity disambiguation	1/3	3/3
citability score	60	62

Two points. I want to be honest about how small that is. The citability score moved barely at all, because a definition sentence is one signal among many and the page was already reasonable on most of them.

The score isn't the point. The point is that the specific failure — a model confidently naming a dependency that does not exist — has a specific, cheap cause, and the cause is an ambiguity you can close in three files.

If you have an acronym

Check whether it collides. The test is one prompt: ask a model to describe your product without giving it any context beyond the name, and see which sense it resolves to. If it picks wrong, you don't have a model problem, you have an adjacency problem.

Then check the four places, in this order:

First body paragraph — a real definition sentence, not a tagline. Subject, is, category.
Meta description — the expansion beats the feature list. It's worth the trade.
Every node in your JSON-LD — not just Organization. A WebSite with a bare brand name undoes the paragraph above it.
Titles — only if you have room under the cap. Usually you don't, and that's fine.

One thing I can't tell you yet: whether the fix propagated. Models don't re-read on your schedule, and I have no way to attribute a corrected description to a specific commit. I'll re-run the same prompt in a month and report the result either way, including if nothing changed.

Next in this series: the JSON-LD your CMS actually emits, and why most parsers — mine included, until I fixed it — don't look in the right place.

I almost started a Medium column about getting cited by LLMs. Then I read Medium's robots.txt

Juan Camilo Auriti — Thu, 17 Sep 2026 07:48:21 +0000

I was about to start a monthly column about AI search visibility — how to get your pages cited by ChatGPT, Perplexity, Google's AI Mode. Medium was the obvious venue. Big audience, publications that distribute for you, no infrastructure to run.

Before writing the first paragraph I ran the check I run on every client site:

curl -s https://medium.com/robots.txt

Medium disallows the crawlers I was writing about.

What's actually in the file

Checked 2026-09-17, HTTP 200. Alongside the usual * rules there's a second group:

User-Agent: Amazonbot
User-Agent: Applebot-Extended
User-Agent: Bytespider
User-Agent: ClaudeBot
User-Agent: FacebookBot
User-Agent: GoogleOther
User-Agent: GPTBot
User-Agent: meta-externalagent
Disallow: /
Allow: /about
Allow: /business
Allow: /earn
Allow: /gift
Allow: /membership
Allow: /partner-program
Allow: /verified-authors

Eight user-agents, Disallow: /, and an allow-list containing exactly the pages that sell Medium. Your post is not on that list.

That's a defensible business decision — Medium licenses its archive and doesn't want it taken for free. It's just the opposite of what I needed from the platform.

Blocked isn't the same as invisible

This is where most takes on this get sloppy, so it's worth being precise. "AI crawler" covers two jobs, and Medium only closes one of them.

Training and bulk collection — closed. GPTBot (OpenAI), ClaudeBot (Anthropic), Applebot-Extended (Apple Intelligence), meta-externalagent (Meta), Bytespider (ByteDance), Amazonbot.

Search-grounded retrieval — open. These are not in the blocked group, so the * rules apply and they're allowed:

user-agent	what it feeds
`Googlebot`	Google's index → AI Overviews, AI Mode
`Bingbot`	Bing's index → Copilot
`PerplexityBot`	Perplexity's own index
`OAI-SearchBot`	ChatGPT's search index
`ChatGPT-User`	user-triggered fetch when ChatGPT opens a link
`Google-Extended`	Gemini / Vertex training use of Google-crawled pages
`CCBot`	Common Crawl

So a Medium post can absolutely turn up as a cited source in Perplexity or an AI Overview. It reaches those engines through a search index, and those indexes are open.

Two of those rows deserve a second look.

Google-Extended isn't blocked. It doesn't crawl anything itself — it's the token that controls whether content Google already crawled may be used for Gemini training. Left unblocked, that path stays open while OpenAI's and Anthropic's equivalents are shut.

CCBot isn't blocked either. Common Crawl is a public archive that a lot of training corpora are built from. Blocking the labs' own crawlers while leaving the archive they can download open is a narrower measure than it first looks.

I don't read this as a loophole anyone left on purpose. I read it as the normal state of a robots.txt: a list of names, maintained by hand, always slightly behind a user-agent landscape that adds a new one every few months.

Six platforms, same check

Same command, same day:

platform	AI crawler rules in the `*` group
`medium.com`	separate group blocking 8 AI user-agents
`dev.to`	none — only `//actions_panel` disallowed
`hashnode.com`	none — `Allow: /`
`substack.com`	none — only `/action/` disallowed
`news.ycombinator.com`	none — open, `Crawl-delay: 30`
`reddit.com`	`User-agent: *` + `Disallow: /` — everything blocked

Reddit is the interesting one. It doesn't single out AI crawlers; it disallows all of them, then licenses the archive to Google and OpenAI directly. Reddit threads do reach those two models, but through a contract, not through a crawl. If you were counting a Reddit comment as third-party evidence any model could go verify, that's not what it is.

Why I cared enough to check

A model reading your own domain treats what it finds as a self-description. The same sentence on a domain you don't control reads differently — and that difference is the entire reason to publish somewhere other than your own site.

I have a concrete case. A comparison prompt to Gemini described my tool as a "Local SEO & AI Indexing" product "built on top of Scrapeless." There is no such product underneath it. The acronym did the damage: a lot of indexed repositories use GEO and "geographic" interchangeably, so a model reading a bare GEO with no nearby context can resolve it to the geographic sense and attach whatever vendor sits in that space.

The fix was boring. Put the expansion next to the name where a model reads first — hero paragraph, meta description, the WebSite and WebApplication nodes in the JSON-LD graph. On the built HTML, the entity-disambiguation check went from 1/3 to 3/3 and the citability score from 60 to 62.

But that fix only works on pages I own. The correction that matters more is the one on a domain that isn't mine — which is why the platform's robots.txt is a prerequisite, not a detail.

The rule

Before you commit a column to a platform, read the platform's robots.txt. It's one command, and it tells you which of the two channels you're buying.

Then be honest about which you needed:

Human readers and distribution → Medium is fine. It has the audience and the publications.
Corroboration a model can crawl → pick a platform that doesn't disallow the crawlers.

I wanted the second, so this column is on dev.to.

Three caveats worth stating plainly. robots.txt is a request, not enforcement — it tells you a platform's stated policy, not what every crawler does. The lists change; mine is a reading from one day, and yours should be your own. And a publication on a custom subdomain can serve a different file than its parent, so check the host you'll actually publish under.

If you want the same check across the AI user-agents on your own domain, that's the first thing the CLI I maintain does — geo access against your robots.txt. But you don't need it for this. You need curl and two minutes, on the platform you were about to hand your writing to.

How to Make Your Site Quotable by AI in 30 Minutes

Juan Camilo Auriti — Wed, 12 Aug 2026 12:59:55 +0000

A practical, copy-paste guide to the four infrastructure fixes that determine whether ChatGPT, Perplexity, and Google AI Overviews cite your site or skip it.

I audited 360 domains against an AI-search-readiness framework. The average score was 54.1 out of 100. Most sites fail not because of content quality, but because of four infrastructure issues that take 30 minutes to fix.

This is the quick version. Four steps, real code, in order.

Why 30 Minutes

AI search is a selection problem, not a ranking problem. A model receives a query, decides which sources to consult, extracts a passage, and either cites you or paraphrases without attribution. There is no page two.

Getting selected requires four things to work in sequence:

Access — the AI crawler can reach your content
Orientation — it can find what matters
Understanding — it can parse what you are
Quotability — it can extract a self-contained passage

Fix access before schema. Fix schema before content. Wrong order = wasted work. I saw teams rewriting content for "AI optimization" while their robots.txt blocked GPTBot.

Let's go.

Step 1: robots.txt (5 minutes)

There are at least 11 AI crawlers actively indexing the web. Each has a distinct user-agent token. Most sites block them by accident — a CMS, a security plugin, or a boilerplate template added Disallow: / and nobody reviewed it.

Check what you're serving right now:

curl https://yoursite.com/robots.txt

If you see Disallow: / under User-agent: *, you're blocking everything. If you see Disallow: / with no user-agent specified, same thing.

Here's a minimal robots.txt that explicitly allows the major AI crawlers while keeping private paths locked down:

# Allow major AI crawlers access to public content
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Googlebot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot
Allow: /

User-agent: CCBot
Allow: /

User-agent: Bytespider
Allow: /

User-agent: Diffbot
Allow: /

# Block private/admin paths from all crawlers
User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /api/internal/

# Sitemap
Sitemap: https://yoursite.com/sitemap.xml

Upload this to your site root. Done.

The Rendering Trap

One more thing on access: if your site is a SPA that returns an empty <div id="root"></div> on the initial HTML response, AI crawlers see nothing. GPTBot and PerplexityBot do not execute JavaScript reliably.

Check what a crawler actually sees:

curl -A "GPTBot" https://yoursite.com | grep -i "your main heading"

If that returns nothing, your content is invisible. You need SSR, SSG, or a prerendering layer. This is not a 5-minute fix, but you need to know about it now.

Step 2: llms.txt (5 minutes)

llms.txt is a plain-text file at the root of your site that gives AI crawlers a structured summary of your content. Think of it as a sitemap that a model can actually read.

In my audit, 54.2% of sites had a llms.txt file, but only 26.9% had a complete one. A broken llms.txt is worse than none — it sends a model a map with missing streets.

Here's a minimal template:

# Your Company Name

> Your Company builds [what you build] for [who you serve].

## Docs
- [Getting Started](https://yoursite.com/docs/getting-started): Quick start guide
- [API Reference](https://yoursite.com/docs/api): Full REST API documentation

## Product
- [Features](https://yoursite.com/features): Feature overview
- [Pricing](https://yoursite.com/pricing): Pricing tiers and FAQ

## Blog
- [Blog Index](https://yoursite.com/blog): Engineering and product blog

Key rules:

The # line is your site title
The > line is a one-sentence summary of what you do
## sections group links
Each link is - [Title](URL): Description — the description matters, it gives the model context about what's at that URL

Don't list every blog post. List the pages that answer "what is this site?" and "what does it do?"

Upload to https://yoursite.com/llms.txt. Done.

Step 3: Schema.org JSON-LD (10 minutes)

Schema is how you tell a model what your entities are: who you are, what your site does, what questions your pages answer.

In the audit, 75.6% of sites had some schema, but only 52.2% had Organization schema and 18.1% had FAQ schema. The gap between "has some schema" and "has the schema types that matter for AI citation" is where most sites lose ground.

Organization + WebSite Schema

Drop this in the <head> of your homepage. Replace the values with your real data.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://yoursite.com/#organization",
      "name": "Your Company",
      "url": "https://yoursite.com",
      "logo": "https://yoursite.com/logo.png",
      "description": "Your Company builds [what you build].",
      "sameAs": [
        "https://github.com/yourcompany",
        "https://x.com/yourcompany",
        "https://www.linkedin.com/company/yourcompany"
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "support",
        "email": "support@yoursite.com",
        "url": "https://yoursite.com/contact"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://yoursite.com/#website",
      "url": "https://yoursite.com",
      "name": "Your Company",
      "description": "What your site does, in one sentence.",
      "publisher": { "@id": "https://yoursite.com/#organization" },
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://yoursite.com/search?q={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    }
  ]
}
</script>

The @graph structure lets you declare multiple entities in one block and cross-reference them with @id. This is how you tell a model "this organization publishes this website."

FAQ Schema

If you have FAQ pages or pages that answer questions, add this on the relevant page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is AI search readiness?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AI search readiness is the degree to which a website can be discovered, understood, and cited by generative AI systems like ChatGPT, Perplexity, and Google AI Overviews."
      }
    },
    {
      "@type": "Question",
      "name": "How is GEO different from SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO optimizes for ranking positions on a search results page. GEO optimizes for selection and citation by generative models that synthesize answers from multiple sources."
      }
    }
  ]
}
</script>

FAQ schema is your direct line to question-answer extraction. When a model sees FAQPage with Question and acceptedAnswer pairs, it can pull those answers verbatim. That's why the 18.1% adoption number matters — it's the schema type most directly tied to getting quoted, and 82% of sites don't have it.

Step 4: Content Structure — BLUF (10 minutes)

The final step is editing, not infrastructure. A model can only quote you cleanly if your content is structured to be quoted.

BLUF: Bottom Line Up Front. Every page should open with a standalone answer to its core question. Details go below. The answer goes first.

Before: Narrative Structure (Hard to Quote)

# How Our API Handles Rate Limiting

When we first launched our API in 2023, we didn't have any rate limiting
in place. After a few incidents where a single client overwhelmed the
auth service, we realized we needed a more robust approach. We
experimented with token bucket algorithms, considered sliding window
loggers, and eventually settled on a fixed window counter approach
combined with exponential backoff. Here's how it works...

[800 more words of context, history, and implementation details]

A model reading this has to synthesize the answer from scattered sentences. It will paraphrase without citing, or skip this source for one that's cleaner.

After: BLUF Structure (Easy to Quote)

# How Our API Handles Rate Limiting

Our API enforces rate limiting using a **fixed window counter** with
exponential backoff. The default limit is **100 requests per minute**
per API key. When the limit is exceeded, the API returns HTTP 429 with
a `Retry-After` header indicating the wait time in seconds.

## How It Works

Rate limits are calculated per API key, not per IP address. Each
request increments a counter that resets at the start of each
60-second window. When the counter exceeds 100, subsequent requests
receive a 429 response until the window resets.

## Handling 429 Responses

Clients should implement exponential backoff: wait 1 second before
the first retry, then double the wait on each subsequent retry, up to
a maximum of 60 seconds. The `Retry-After` header provides the exact
wait time for the current window.

The first paragraph is self-contained. A model can extract it as a direct quote. It makes sense outside the context of the full page. That's quotability.

The Editing Rule

Go to your top 5 most important pages. For each one:

Find the core question the page answers
Write a 2-3 sentence answer that stands alone
Put it at the top, before any context or history
Move the details below

This is the step that takes the most effort but has the highest impact on whether you get quoted or paraphrased.

The Order Matters

I'll say it one more time because it's the most common mistake:

Access → Orientation → Understanding → Quotability

If your robots.txt blocks GPTBot, your llms.txt and schema are invisible. If your llms.txt is broken, your schema sends a model to dead ends. If your schema is missing, your content structure doesn't help the model understand what it's reading.

Fix the foundation first. Each layer enables the next.

What This Gets You

From the benchmark data:

Signal	With	Without	Gap
llms.txt	63.3	43.3	+20.0 pts
Schema	61.0	32.8	+28.2 pts

Sites with llms.txt score 20 points higher than sites without. Sites with schema score 28 points higher. The layers compound.

None of this requires a marketing agency. It requires 30 minutes and a text editor. The four files you need to touch:

/robots.txt
/llms.txt
Your homepage <head> (JSON-LD)
Your top 5 pages (content structure)

Go fix them.

The 4-Layer Model for AI Search Readiness: What I Learned Auditing 360 Sites

Juan Camilo Auriti — Mon, 03 Aug 2026 08:39:13 +0000

The 4-Layer Model for AI Search Readiness: What I Learned Auditing 360 Sites

I audited 360 domains against a structured AI-search-readiness framework. The average score was 54.1 out of 100. Only 24.7% reached "Good" or above. The first perfect 100/100 didn't appear until July 2026.

This post walks through the four-layer model I used — Access, Orientation, Understanding, Quotability — with real code examples for each layer, the benchmark data behind it, and the infrastructure mistakes I kept seeing.

If you're a developer or tech lead, this is the framework to operationalize before your marketing team asks why ChatGPT doesn't cite your docs.

The Core Thesis: AI Search Selects, It Doesn't Rank

Traditional SEO is a ranking problem: optimize pages, climb positions, compete for slots on a results page.

Generative search — ChatGPT, Perplexity, Google AI Overviews — is a selection problem. A model receives a query, decides which sources to consult, extracts a passage, and either cites the source or paraphrases without attribution. There is no page two. You are either quoted, or you are invisible.

Getting selected requires four things to work in sequence:

Access — the AI crawler can reach your content
Orientation — it can find what matters on your site
Understanding — it can parse what your organization and pages are about
Quotability — it can extract a self-contained passage to quote

The key principle: fix access before schema, fix schema before content. Wrong order = wasted work. I saw this pattern repeatedly — teams rewriting content for "AI optimization" while their robots.txt blocked GPTBot.

Let's go layer by layer with code.

Layer 1: Access — Can the AI Crawler Reach You?

Access is robots.txt, static HTML delivery, server response behavior, and rendering. It's the least glamorous layer and the most common failure point.

There are at least 11 AI crawlers actively indexing the web. Each has a distinct user-agent token:

Crawler	User-Agent Token	Operator
GPTBot	`GPTBot`	OpenAI
OAI-SearchBot	`OAI-SearchBot`	OpenAI (Search)
PerplexityBot	`PerplexityBot`	Perplexity
ClaudeBot	`ClaudeBot`	Anthropic
Claude-SearchBot	`Claude-SearchBot`	Anthropic (Search)
Googlebot	`Googlebot`	Google
Google-Extended	`Google-Extended`	Google (AI training)
Applebot	`Applebot`	Apple
CCBot	`CCBot`	Common Crawl
Bytespider	`Bytespider`	ByteDance
Diffbot	`Diffbot`	Diffbot

The benchmark found an average of 23.2 bots allowed per site — but that average masks a long tail of sites blocking exactly the crawlers they need.

robots.txt: Allow the AI Crawlers

Here's a minimal robots.txt that explicitly allows the major AI crawlers while keeping your private paths locked down:

# Allow major AI crawlers access to public content
User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Googlebot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot
Allow: /

User-agent: CCBot
Allow: /

User-agent: Bytespider
Allow: /

User-agent: Diffbot
Allow: /

# Block private/admin paths from all crawlers
User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /api/internal/

# Sitemap
Sitemap: https://example.com/sitemap.xml

The Rendering Trap

A subtler access issue: client-side rendering. If your site is a SPA that returns an empty <div id="root"></div> on the initial HTML response, many AI crawlers see nothing. GPTBot and PerplexityBot do not execute JavaScript reliably. They read the static HTML.

If your content lives behind a React/Vue/Svelte hydration step, you need either:

SSR (server-side rendering) or SSG (static site generation) so the HTML contains the content, or
A prerendering layer that serves cached HTML to bot user-agents

Check what a crawler actually sees:

curl -A "GPTBot" https://example.com | grep -i "your main heading"

If that returns nothing, your content is invisible to the crawler. Fix this before anything else.

Layer 2: Orientation — Can It Find What Matters?

Once a crawler reaches your site, it needs to know what's important. Orientation covers llms.txt, sitemaps, RSS feeds, and priority URL signals.

This was the worst-performing category in the entire audit:

AI Discovery adoption: 17.5%
AI Discovery efficiency: 10%

The llms.txt numbers tell a specific story:

llms.txt adoption: 54.2% — but down from 58.3% in June. Sites are removing it.
Full llms.txt: only 26.9% — the rest are partial or malformed.

A broken llms.txt is worse than none. It sends a model a map with missing streets.

Minimal llms.txt Example

The llms.txt standard is a plain-text file at the root of your site that gives AI crawlers a structured summary of your content:

# Example Company

> Example Company builds developer infrastructure for AI-powered search.

## Docs
- [Getting Started](https://example.com/docs/getting-started): Quick start guide
- [API Reference](https://example.com/docs/api): Full REST API documentation
- [SDK Guide](https://example.com/docs/sdk): SDK installation and usage

## Product
- [Features](https://example.com/features): Feature overview and comparison
- [Pricing](https://example.com/pricing): Pricing tiers and FAQ

## Blog
- [Blog Index](https://example.com/blog): Engineering and product blog

## Optional
- [About](https://example.com/about): Company background and team
- [Contact](https://example.com/contact): Contact information

Key rules:

The # line is the site title
The > line is a one-sentence summary
## sections group links
Each link is - [Title](URL): Description — the description matters, it gives the model context about what's at that URL

Don't list every blog post. List the pages that answer "what is this site?" and "what does it do?"

Layer 3: Understanding — Can It Parse What You Are?

A crawler has reached your site and found your priority content. Now it needs structured data to understand entities: who you are, what your site does, what questions your pages answer.

Understanding is Schema.org JSON-LD, meta tags, and entity signals.

Benchmark Data

Schema adoption: 75.6% — up from 70.1% in June. Trending positive.
Organization schema: 52.2% — barely half of sites tell crawlers who they are.
WebSite schema: 58.9%
FAQ schema: 18.1% — up from 13.2%, but still remarkably low for a schema type directly designed for question-answer extraction.

The gap between "has some schema" (75.6%) and "has the schema types that matter for AI citation" (52% / 59% / 18%) is where most sites lose ground.

Organization + WebSite JSON-LD Template

Drop this in the <head> of your homepage. Replace the values with your real data.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Company",
      "url": "https://example.com",
      "logo": "https://example.com/logo.png",
      "description": "Example Company builds developer infrastructure for AI-powered search.",
      "sameAs": [
        "https://github.com/example",
        "https://x.com/example",
        "https://www.linkedin.com/company/example"
      ],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "support",
        "email": "support@example.com",
        "url": "https://example.com/contact"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com",
      "name": "Example Company",
      "description": "Developer infrastructure for AI-powered search.",
      "publisher": { "@id": "https://example.com/#organization" },
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://example.com/search?q={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    }
  ]
}
</script>

The @graph structure lets you declare multiple entities (Organization + WebSite) in one block and cross-reference them with @id. This is how you tell a model "this organization publishes this website" — a relationship that matters for entity disambiguation.

For FAQ pages, add this on the relevant page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is AI search readiness?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "AI search readiness is the degree to which a website can be discovered, understood, and cited by generative AI systems like ChatGPT, Perplexity, and Google AI Overviews."
      }
    },
    {
      "@type": "Question",
      "name": "How is GEO different from SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "SEO optimizes for ranking positions on a search results page. GEO optimizes for selection and citation by generative models that synthesize answers from multiple sources."
      }
    }
  ]
}
</script>

FAQ schema is your direct line to question-answer extraction. When a model sees FAQPage with Question and acceptedAnswer pairs, it can pull those answers verbatim. That's why the 18.1% adoption number is so painful — it's the schema type most directly tied to getting quoted, and 82% of sites don't have it.

Layer 4: Quotability — Can It Extract a Self-Contained Passage?

The final layer is content architecture. A model can only quote you cleanly if your content is structured to be quoted: direct answers, bottom-line-up-front (BLUF), short self-contained paragraphs.

This is the layer most teams skip — they fix robots.txt, add llms.txt, implement schema, and then leave their content as 2,000-word narratives that bury the answer in paragraph five.

Before: Narrative Structure (Hard to Quote)

# How Our API Handles Rate Limiting

When we first launched our API in 2023, we didn't have any rate limiting
in place. After a few incidents where a single client overwhelmed the
auth service, we realized we needed a more robust approach. We
experimented with token bucket algorithms, considered sliding window
loggers, and eventually settled on a fixed window counter approach
combined with exponential backoff. Here's how it works...

[800 more words of context, history, and implementation details]

A model reading this has to synthesize the answer from scattered sentences. It will likely paraphrase without citing, or skip this source for one that's cleaner.

After: BLUF Structure (Easy to Quote)

# How Our API Handles Rate Limiting

Our API enforces rate limiting using a **fixed window counter** with
exponential backoff. The default limit is **100 requests per minute**
per API key. When the limit is exceeded, the API returns HTTP 429 with
a `Retry-After` header indicating the wait time in seconds.

## How It Works

Rate limits are calculated per API key, not per IP address. Each
request increments a counter that resets at the start of each
60-second window. When the counter exceeds 100, subsequent requests
receive a 429 response until the window resets.

## Handling 429 Responses

Clients should implement exponential backoff: wait 1 second before
the first retry, then double the wait on each subsequent retry, up to
a maximum of 60 seconds. The `Retry-After` header provides the exact
wait time for the current window.

The first paragraph is self-contained. A model can extract it as a direct quote: "Our API enforces rate limiting using a fixed window counter with exponential backoff. The default limit is 100 requests per minute per API key." It makes sense outside the context of the full page. That's quotability.

The rule: every page should open with a standalone answer to its core question. Details go below. The answer goes first.

The Correlation Data: What Actually Moves the Score

The audit measured not just adoption but impact. The correlations are the strongest evidence for the 4-layer model:

Signal	With	Without	Gap
llms.txt	63.3	43.3	+20.0 pts
Schema	61.0	32.8	+28.2 pts

Sites with llms.txt score 20 points higher than sites without. Sites with schema score 28 points higher. These aren't magic — a llms.txt file doesn't fix your server. But they show that the sites investing in orientation and understanding signals are the same sites that perform well across the board. The layers compound.

Common Infrastructure Mistakes

1. Blocking AI crawlers in robots.txt by accident. A CMS, security plugin, or boilerplate template added Disallow: / for GPTBot and nobody reviewed it. Check your robots.txt with curl https://example.com/robots.txt — actually read it.

2. Client-side rendering with no prerender fallback. Your SPA returns an empty shell. AI crawlers see nothing. Either use SSR/SSG or serve prerendered HTML to bot user-agents. Verify with curl -A "GPTBot" https://example.com.

3. Partial llms.txt. A llms.txt with broken links, missing sections, or only the homepage listed is worse than no llms.txt. The 27-point gap between adoption (54.2%) and full implementation (26.9%) means half the llms.txt files out there are broken maps.

4. Generic schema only. Article schema on blog posts is table stakes. The schema types that drive AI citation are Organization (who are you?), WebSite (what is this site?), and FAQPage (what's the answer?). Most sites have none of these.

5. Fixing content before access. I saw teams spend weeks rewriting content for "AI optimization" while their robots.txt blocked every AI crawler. The order is non-negotiable: Access → Orientation → Understanding → Quotability. Skip ahead and you're building on broken foundations.

Where the Benchmark Stands

360 domains audited. Average score 54.1/100. 75.3% at Foundation or Critical. The first 100/100 appeared in July.

The gap between traditional SEO and GEO is measurable and structural. It's not about keywords or backlinks — it's about whether an AI crawler can reach your content, orient itself, understand your entities, and extract a clean passage. Four layers, in order, each one enabling the next.

The good news for developers: every layer is fixable with infrastructure changes. robots.txt is a text file. llms.txt is a text file. JSON-LD is a script tag. BLUF is an editing pattern. None of this requires a marketing agency. It requires an engineer who knows the framework.

Now you do.

The full manual is 160 pages — 15 chapters covering all four layers in depth, 11 AI crawlers with user-agent tokens, 12 schema types with JSON-LD templates, 8 prompt injection attack vectors, and a citation measurement workflow. Free download at geoready.dev/geo-readiness-manual/

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

Juan Camilo Auriti — Thu, 04 Jun 2026 08:18:40 +0000

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:

audit the site;
identify weak signals;
prioritize fixes;
apply changes;
re-audit;
compare the difference;
monitor the domain;
alert when regressions happen;
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.

The Missing Layer in Google I/O 2026: Agent-Ready Websites

Juan Camilo Auriti — Wed, 20 May 2026 13:25:08 +0000

This is a submission for the Google I/O Writing Challenge

Everyone is talking about Gemini, Antigravity, AI Mode, and coding agents.

I want to talk about websites.

Because the Google I/O 2026 announcement that spoke to me most was not only a model announcement, an IDE update, or another productivity feature. It was the larger pattern behind several announcements: the web is becoming agentic.

That changes the job of a web developer.

For years, we built websites mainly for three audiences:

humans using browsers;
crawlers indexing pages;
search engines ranking documents.

After Google I/O 2026, I think we need to add a fourth audience:

AI agents that read, reason, compare, inspect, click, call tools, and act on behalf of users.

That does not mean we should stop caring about humans. Quite the opposite. The best agent-ready website is usually a better human website too: clearer, more semantic, more accessible, more stable, and less ambiguous.

But it does mean that “looking good in the browser” is no longer enough.

A website now has to answer a deeper question:

Can an AI system understand what this page means, verify what it claims, and safely act on what it exposes?

That, to me, is the missing layer in Google I/O 2026: agent-ready websites.

The announcement I am focusing on: WebMCP and the agentic web

Google I/O 2026 had many AI announcements. Google’s own I/O 2026 recap frames the event around more capable models, agentic experiences, Antigravity, Information agents in Search, Gemini Spark, Universal Cart, and broader Gemini integration across products.

But the announcement that feels most underrated for web developers is the Chrome team’s work around the agentic web, especially WebMCP and the broader set of Chrome updates announced in “15 updates from Google I/O 2026: Powering the agentic web”.

The key idea behind WebMCP is simple but powerful:

Websites should be able to expose structured tools that browser-based agents can use with more reliability, precision, and context.

Instead of forcing an agent to visually guess its way through a complex interface, WebMCP aims to let a website describe actions in a more machine-friendly way. The Chrome team describes it as a proposed open web standard for exposing structured tools such as JavaScript functions and HTML forms to browser-based agents.

That matters because it changes the role of the website.

A website is no longer only a set of pages.

It can become a set of understandable capabilities.

For example, instead of an agent trying to click through a travel booking flow step by step, a site could expose a structured tool for checking availability, comparing options, or building an itinerary. The user would still need control and approval where appropriate, but the interaction becomes more explicit and less fragile.

This is not just automation.

This is a new contract between websites and agents.

Why this matters beyond WebMCP

The important part is not only WebMCP itself.

The important part is the direction.

Google I/O 2026 repeatedly pointed toward AI systems that do not merely answer questions, but help users complete tasks. Google described Gemini 3.5 as a family of models combining “frontier intelligence with action”, with Gemini 3.5 Flash positioned for agentic and coding workflows. Google’s I/O 2026 collection also highlights Information agents in Search, Gemini Spark, Universal Cart, and an agent-first development platform in Antigravity.

In parallel, Google Search Central published guidance for optimizing websites for generative AI features in Search. That guide keeps SEO in the picture, but reframes the environment: generative AI features use techniques such as retrieval-augmented generation and query fan-out, and Google explicitly encourages clear technical structure, crawlability, unique non-commodity content, and agentic-experience awareness.

Then web.dev published guidance on building agent-friendly websites, making the point even more concrete: agents can interpret websites through multiple signals, including screenshots, DOM structure, and the accessibility tree.

For me, these announcements are connected.

Search is becoming more generative.

Browsers are becoming more agentic.

Developer tools are becoming more autonomous.

And websites are becoming inputs to systems that do not behave like traditional users.

That is a big deal.

The old web contract is changing

The old web contract looked something like this:

make the page discoverable;
make the content indexable;
make the interface usable by humans;
make the page fast enough;
make the content rank.

That contract still matters.

But it is no longer complete.

The new contract adds questions like:

can an AI system retrieve the correct information from this page?
can it distinguish primary content from decorative noise?
can it identify the purpose of a button, form, or control?
can it understand pricing, availability, dates, policies, constraints, and exceptions?
can it use the accessibility tree as a reliable functional map?
can it perform an action without guessing?
can it avoid dangerous or irreversible steps without user confirmation?

This is where agent readiness begins.

It is not “SEO with a different name”.

It is not “add one magic file and hope AI systems cite you”.

It is the discipline of reducing ambiguity across content, markup, interface behavior, and actions.

SEO is still relevant, but it is not the whole story

One of the most useful parts of Google’s new generative AI search guidance is its refusal to treat AI search as a completely separate universe.

Google says foundational SEO practices still matter because generative AI features in Search are rooted in core Search ranking and quality systems. That is important. Crawlability, indexability, technical clarity, helpful content, good page experience, and structured information are not obsolete.

But I do not read this as “nothing has changed”.

I read it as:

SEO remains the foundation, but AI agents add a new interaction layer on top of that foundation.

A page can be indexed and still be hard for an agent to use.

A page can rank and still expose a confusing form.

A page can have structured data and still hide critical context behind vague UI labels.

A page can be beautiful and still be functionally broken for non-human navigation.

This is especially true when the task is not “find a document”, but “complete a journey”.

Finding a hotel page is one thing.

Understanding room types, checking dates, comparing cancellation policies, selecting accessibility options, and preparing a booking request is another.

That second experience is where agent readiness matters.

My critique: the agentic web could reward clarity — or punish fragile websites

My biggest concern is that agentic browsing may widen the gap between well-engineered websites and fragile interfaces.

A clean, semantic, accessible website may become easier for agents to understand and operate.

A visually impressive but structurally confusing website may become less useful in practice, even if it looks good to humans.

That matters because many modern interfaces are optimized for visual polish but not for semantic clarity.

We use clickable divs instead of buttons.

We hide labels because the placeholder looks cleaner.

We build custom controls that look beautiful but expose weak roles and names.

We rely on hover states that do not translate well to automation.

We split critical information across modals, accordions, carousels, and animation-heavy layouts.

We make forms that humans can eventually understand, but machines must infer.

For humans, this is annoying.

For agents, it is brittle.

And for developers, it is a warning.

The agentic web will not only need better models. It will need better websites.

The Agent Readiness Stack

Here is the mental model I would use after Google I/O 2026.

I call it the Agent Readiness Stack.

It has five layers.

1. Crawlability

Before an agent can reason about your content, the content has to be discoverable and accessible.

This is the layer traditional SEO already knows well:

do not block important pages accidentally;
make critical content publicly reachable when it should be;
use sensible internal linking;
avoid unnecessary duplication;
keep JavaScript-rendered content accessible to search systems;
maintain clean status codes, canonical URLs, and sitemaps where appropriate.

This is not glamorous, but it is foundational.

If the page cannot be found, nothing else matters.

2. Content clarity

Generative AI search makes weak content easier to ignore.

Google’s guidance emphasizes unique, valuable, non-commodity content. That phrase matters because AI systems are increasingly good at summarizing common knowledge. If your page only repeats what everyone else says, there may be little reason to retrieve it, cite it, or send a user to it.

For developers and site owners, this means content should answer questions like:

what do we know from direct experience?
what can we explain better than generic sources?
what details would help a user make a real decision?
what constraints, trade-offs, edge cases, or risks should be visible?
what claims can be verified?

Agent-ready content is not necessarily longer.

It is clearer.

It makes the important facts explicit.

3. Semantic structure

HTML is not just a rendering target.

It is meaning.

When an interface is built with semantic elements, the browser, assistive technologies, crawlers, and agents have a better chance of understanding what is happening.

That means:

use real headings for structure;
use real buttons for actions;
use links for navigation;
connect labels to inputs;
expose names, roles, and states correctly;
avoid replacing native controls with fragile custom components unless there is a strong reason;
make important information part of the document, not only a visual decoration.

This is not about writing perfect HTML for its own sake.

It is about reducing interpretation errors.

A human can sometimes guess that a styled card is clickable.

An agent should not have to guess.

4. Accessibility tree quality

The accessibility tree may become one of the most important debugging surfaces for agent-ready websites.

web.dev describes the accessibility tree as a browser-native representation that distills the DOM into roles, names, and states of interactive elements. For assistive technology, it is essential. For agents, it can become a functional map of the page.

That means accessibility is not a separate checklist anymore.

It is part of AI usability.

If a button has no accessible name, a screen reader user suffers.

If a form field has no label, an agent may not understand what value belongs there.

If a custom control exposes the wrong role, automation becomes unreliable.

Accessibility work has always been about inclusion.

Now it is also becoming part of machine interpretability.

That should not reduce its human importance. It should increase its priority.

5. Action readiness

This is the new layer.

Can an agent safely act on the site?

Not every website needs this immediately. A blog post may only need to be readable and citeable. But ecommerce, travel, SaaS, local services, booking systems, dashboards, and support portals increasingly need to think about actions.

Actions require more than buttons.

They require intent, constraints, parameters, validation, and confirmation.

For example:

“Search rooms” is safer than “Submit”.
“Request booking quote” is clearer than “Continue”.
“Cancel subscription” must require explicit confirmation.
“Pay now” must never be hidden behind ambiguous automation.
“Compare plans” should expose plan names, prices, limits, and billing periods clearly.

WebMCP is interesting because it points toward a world where websites can expose those actions as structured tools instead of leaving agents to infer everything from pixels and DOM fragments.

That does not remove the need for UX.

It makes UX more explicit.

A small example: from a fragile form to an agent-readable form

Imagine a booking form.

A fragile version might look clean to humans but confusing to agents:

<div class="booking-card">
  <div class="field">Arrival</div>
  <input type="text" placeholder="Select date">

  <div class="field">Leaving</div>
  <input type="text" placeholder="Select date">

  <div class="fake-button" onclick="submitBooking()">
    Continue
  </div>
</div>

This may work visually, but it creates ambiguity:

the inputs do not have stable labels;
the fields do not have clear names;
the action is a clickable div;
the button text is generic;
the expected data format is unclear;
the user intent is hidden inside JavaScript.

A more agent-ready version starts with ordinary good HTML:

<form action="/booking/search" method="get" aria-labelledby="booking-search-title">
  <h2 id="booking-search-title">Search room availability</h2>

  <label for="check-in">Check-in date</label>
  <input id="check-in" name="check_in" type="date" required>

  <label for="check-out">Check-out date</label>
  <input id="check-out" name="check_out" type="date" required>

  <label for="guests">Number of guests</label>
  <input id="guests" name="guests" type="number" min="1" max="6" required>

  <button type="submit">Search available rooms</button>
</form>

This is not futuristic.

It is just clear.

But that is the point.

Agent readiness often starts with things web developers should already care about: semantic HTML, accessible names, explicit labels, stable actions, and meaningful copy.

If you later experiment with WebMCP, that same clarity becomes even more valuable. Current Lighthouse documentation for agentic browsing already points to schema validity concepts such as tool names, tool descriptions, input names, labels, and parameter descriptions.

The direction is obvious: agents need structured intent, not visual guesswork.

A practical checklist for developers

If I had to turn Google I/O 2026 into a practical checklist for everyday web work, I would start here.

Content

Do not publish generic summaries that anyone could produce.
Add first-hand experience, examples, constraints, and trade-offs.
Make claims easy to verify.
Keep dates, prices, availability, version numbers, and eligibility conditions explicit.
Use headings that describe the content, not vague marketing slogans.
Add useful images or diagrams when they clarify the topic.

HTML and interface structure

Use native buttons for actions.
Use links for navigation.
Avoid clickable non-interactive elements where possible.
Connect every form input with a visible or programmatically available label.
Use meaningful name attributes for form fields.
Make error messages specific and connected to the relevant fields.
Avoid hiding critical information only inside hover states or visual-only interactions.

Accessibility tree

Inspect the accessibility tree in Chrome DevTools.
Check whether every important action has a clear accessible name.
Verify that custom components expose correct roles, names, and states.
Test keyboard navigation.
Avoid layouts where the visual order and DOM order create confusion.

Agentic actions

Identify which actions an agent could safely help with.
Separate low-risk actions from high-risk actions.
Require explicit user confirmation for irreversible or sensitive actions.
Make action labels precise.
Consider whether structured tools, APIs, or WebMCP-like patterns could reduce ambiguity.
Log and monitor agent-triggered flows differently from normal user flows when appropriate.

Search and generative AI visibility

Keep foundational SEO healthy.
Make important pages crawlable and indexable.
Avoid manipulative “AI-only” content strategies.
Use structured data where it genuinely helps, but do not treat it as a magic solution.
Build content that deserves to be retrieved, summarized, and cited.

What I would test first

I am still in the first-look and reading-the-docs phase with WebMCP, so I do not want to pretend I have shipped it in production.

But if I were testing this today, I would start with a simple local service website or a booking flow.

For example, a small hotel or B&B website.

The task would be:

Can an AI agent understand the available rooms, compare the options, identify cancellation rules, check dates, and prepare a booking request without guessing?

I would audit the site in five passes:

Content pass: Are room types, prices, policies, services, accessibility options, and location details explicit?
HTML pass: Are headings, links, buttons, forms, and labels semantic?
Accessibility pass: Does the accessibility tree communicate the same intent as the visual UI?
Search pass: Are key pages crawlable, indexable, and structured enough for discovery?
Action pass: Which actions could safely be delegated to an agent, and which must require human approval?

That kind of audit is not just useful for agents.

It improves the site for everyone.

A clearer room page helps search engines.

A better form helps users.

A stronger accessibility tree helps assistive technologies.

A more explicit policy helps customers trust the business.

And if agents become a common interface to the web, the same improvements make the website easier for agents to operate.

That is why I think agent readiness is not a speculative idea.

It is a practical engineering direction.

Where I disagree with the hype

I do not think every website needs to rush into agentic automation tomorrow.

I also do not think every form needs to become a tool, every page needs an AI-specific representation, or every business needs to rebuild its interface around agents.

That would be premature.

There is also a risk that “agent-ready” becomes the next buzzword used to sell shallow checklists.

We should avoid that.

The best version of agent readiness is not hype.

It is not tricking AI systems.

It is not replacing human UX.

It is not publishing hundreds of pages for every possible query variation.

It is the disciplined work of making websites easier to understand, verify, and operate.

That work is boring in the best possible way.

It is labels.

It is headings.

It is clear content.

It is stable layouts.

It is accessible components.

It is explicit actions.

It is careful confirmation flows.

It is technical structure.

And that is exactly why developers should care.

The opportunity for developers

The developers who understand this shift early will have an advantage.

Not because they will chase every new AI feature.

But because they will build websites that are robust across interaction modes.

A good agent-ready website works for:

a human reading on mobile;
a keyboard user navigating forms;
a screen reader user exploring controls;
a crawler discovering content;
a search system retrieving information;
an AI assistant summarizing options;
a browser agent trying to complete a delegated task.

That is a powerful design constraint.

It brings together disciplines that are often treated separately:

SEO;
accessibility;
UX writing;
frontend architecture;
structured data;
performance;
content strategy;
AI product design.

Google I/O 2026 made this convergence much more visible.

The web is not becoming less important because of AI.

The web is becoming the environment where agents must prove they can act usefully, safely, and reliably.

That makes the quality of websites more important, not less.

Final thought

Google I/O 2026 made me think less about rankings and more about readiness.

Ranking is about being selected.

Citation is about being trusted.

Agent readiness is about being understood well enough to be used.

That is the missing layer.

The next web will not be won only by pages that look beautiful or rank well.

It will be won by pages that humans can trust, search systems can retrieve, and agents can operate without ambiguity.

For developers, that is both a challenge and an opportunity.

We do not only need better AI models.

We need better websites for AI to work with.

References

AI assistance disclosure

I used AI assistance to help organize research notes, refine the outline, and improve editorial clarity. The final angle, opinions, examples, and publishing decisions are mine.

Why Your Brand Is Invisible to AI Search (It's Not About Rankings)

Juan Camilo Auriti — Fri, 15 May 2026 15:58:22 +0000

A site can rank well on Google and still fail to appear in AI-generated answers. I keep seeing this pattern during visibility checks: strong organic presence, useful content, and weak or inconsistent citation across ChatGPT, Perplexity, Gemini, or Google's AI Overviews for comparable queries.

This is not a ranking problem. It's a visibility gap of a different kind, and fixing it requires a different approach.

Key Takeaways

Google rankings and AI search visibility are distinct systems with different citation logic

In AI search contexts, answer density often appears to matter more than traditional ranking signals alone

Explicit author attribution, structured content, and factual precision are practical GEO signals that traditional SEO tools usually don't measure

Citation behavior varies meaningfully across platforms: what works for Perplexity doesn't always transfer to ChatGPT or Gemini

Fixing AI invisibility requires a content audit targeting GEO signals, not an SEO ranking fix

The AI Search Visibility Gap Nobody's Measuring

Consider this scenario: a technical agency has spent two years building topical authority in their space. Top 3 rankings for their core keywords. A content library with solid E-E-A-T signals. Good backlink profile. By traditional metrics, they're doing the right things.

Then someone on their team starts checking AI search. They ask ChatGPT to recommend tools in their category. Then Perplexity. Then Google AI Overviews. The agency doesn't appear in any of them, not once across 15 queries covering topics they rank #1 for.

That's not a fringe case. It's a pattern I keep encountering when I start running visibility checks.

The reason it goes unnoticed is that traditional analytics don't capture it. Google Search Console doesn't report AI answer impressions. GA4 doesn't segment "traffic from AI citation." The gap is real but invisible to the dashboards most practitioners live in.

Why the systems are different

Google's search ranking logic and LLM citation logic have different optimization targets.

Google's ranking algorithm weights domain authority, backlinks, freshness, and relevance signals. It's a retrieval-and-ranking system designed to surface the most authoritative source for a query.

LLMs work differently. When generating an answer, a model doesn't browse the web in real-time (except in specific configurations like Perplexity's). It draws on its training data and, in search-integrated systems, on retrieved passages that match the query context. The retrieval step favors content that directly answers the question, content where the relevant information is dense, clearly structured, and attributed.

High domain authority helps at the margins, but it doesn't determine whether your specific content gets extracted. That's determined by whether the passage itself is answer-dense, factually precise, and structurally parseable.

What AI Search Actually Optimizes For

When I look at pages that consistently get cited versus pages that don't, the patterns that show up aren't about rankings. They're about a few specific content properties.

Answer density

The simplest way to describe answer density: how much of the user's likely question does this content resolve in a single chunk?

AI systems using retrieval-augmented generation (RAG) can evaluate content at passage level, not only page level. A 3,000-word article that buries the answer in paragraph 12 may be less useful for citation than a shorter page that resolves the query clearly in the first few sections, even if the longer article performs well in traditional search.

This is where SEO and GEO (generative engine optimization) diverge most sharply. Google's algorithm often rewards comprehensive coverage and depth. AI retrieval rewards directness and concentration. Content optimized for one isn't automatically optimized for the other.

The fix isn't to write shorter content. It's to restructure so each major section opens with a direct answer to the question that section implies.

Structural clarity

LLMs extract passages more reliably when the content is clearly organized. Headers that state what the reader is about to learn, not decorative headers, but functional ones, help retrieval systems understand where relevant content is.

Definition-first patterns work well. When introducing a technical term or concept, state the definition before unpacking it. "Answer density is the ratio of directly answerable content to total content in a given passage" is a better passage start than "To understand how content performs in AI retrieval, we need to think about the relationship between what users ask and what content delivers."

FAQ sections in Q&A format are reliable citation targets because they mirror the structure of how queries are posed. An H3 that says "How does citation quality scoring work?" followed immediately by a direct answer is the kind of passage LLMs extract cleanly.

Entity clarity

This one is underestimated. LLMs weight content differently depending on whether the source and context are clearly established.

Author attribution matters. In my observations across queries over several months, pages with visible author bylines and structured author metadata appear more frequently in AI-generated answers than comparable pages without them. I don't have access to the retrieval weighting logic, but the pattern is consistent enough to treat author attribution as a working GEO signal.

Beyond authorship, entity clarity means: is it clear what organization this is, what topic this covers, and when it was written? Publication dates in frontmatter, clear organizational affiliation, and explicit topic statements in the first paragraph all contribute.

Google's AI Overviews documentation discusses E-E-A-T in relation to search quality. Perplexity surfaces sources prominently, which makes author attribution, provenance, and content clarity easier to inspect during practical visibility checks.

Factual precision

LLMs are trained to avoid reproducing claims that are vague, unsupported, or potentially inaccurate. Content full of "studies show," "experts agree," and vague statistics without attribution is treated with caution by retrieval systems, and appropriately so.

Precision helps in two ways. First, specific claims are more extractable because they're more query-relevant ("citation rate increased 40% after adding author schema" matches a retrieval query better than "adding schema can help"). Second, attributed claims reduce the risk that the LLM generates a hallucinated version, if the claim is specific and sourced, there's less ambiguity.

The pattern I keep seeing: content that reads like a practitioner sharing observable evidence tends to be easier to evaluate than content that reads like a generic summary of general knowledge. The former has specific claims, hedged appropriately, with clear provenance. The latter looks like it could have been generated by the LLM itself.

Why Rankings Don't Transfer

A common response when I describe this gap is: "But we rank well, doesn't that mean AI trusts us?"

Partially. High-authority domains do appear more frequently in AI answers. But authority doesn't guarantee citation, and it doesn't determine which content from a domain gets cited. I've seen cases where a high-authority domain is cited for a secondary, less-optimized post while the primary pillar page, well-ranked, well-linked, gets no citation at all.

The reason is that passage relevance, not page authority, drives which content gets extracted. A high-DA domain with answer-dense, well-structured content will outperform its rankings in AI search. A high-DA domain with authority-heavy but answer-poor content will underperform.

There's also a platform divergence that complicates the picture. Perplexity, ChatGPT (when web-browsing), and Google AI Overviews have meaningfully different citation behaviors.

Across practical visibility checks, citation behavior can vary meaningfully by platform. Perplexity often makes source selection easier to inspect because citations are surfaced prominently. ChatGPT with browsing may combine known authorities with practitioner sources when the query requires recent or specific context. Google AI Overviews appears more closely tied to Google's broader search quality and source evaluation systems.

Same content, same domain, different citation behavior depending on where you query. Optimizing for one platform's behavior without understanding the others leaves significant visibility gaps.

What a GEO Audit Catches That a Standard SEO Audit Won't

A standard SEO audit checks keyword density, heading structure, page speed, internal links, meta elements. These are necessary for rankings. They're not sufficient for AI search visibility.

A GEO-focused audit covers different signals:

Answer density per section, Is each major H2 section self-contained enough to answer the question it implies? Can the section be extracted and stand alone as a useful passage?

Entity markup, Is Article or BlogPosting schema implemented with author, datePublished, and organization? Is the author a named individual or an anonymous entity?

Factual precision scan, Are there vague, unattributed claims that an LLM would flag as potentially inaccurate? "Many studies show" vs. "according to Google's 2024 AI Overviews documentation" is a significant difference in citation safety.

Citation structure, Are claims linked to sources? Is the content internally consistent? Does it avoid making absolute claims in areas where platform behavior is known to vary?

Structural patterns for LLM retrieval, Are there definition-first passages, Q&A sections, comparison tables? These structures extract cleanly from retrieval systems.

This is the gap I've been building GeoReady to address. GeoReady's GEO audit workflow analyzes pages against these signals: answer density, entity clarity, factual precision, structural clarity, and schema implementation. The output is designed to show which signals are present, which are missing, and which specific changes could improve citation quality.

The audit layer is running and producing data across test pages. I'm finding consistent patterns: pages that resolve the query density requirement and have clear author attribution score meaningfully higher on citation quality metrics than pages with equivalent Google rankings but poor GEO signal coverage.

The AI Search Visibility Monitoring Problem

Even if you fix your content's GEO signals, AI search visibility isn't stable. Citation behavior shifts with model updates, with changes in how retrieval systems weight sources, and with the competitive landscape as more content optimizes for AI retrieval.

I've been running answer snapshot tests, capturing AI-generated answers for target queries at regular intervals, and the citation drift is real. A source that appears in Perplexity's answers for a query in January may not appear in April. Sometimes this is because the source's content changed. Often it's because other sources got better, or because the model update shifted retrieval weighting.

Traditional SEO tooling tracks ranking changes over time. There's no equivalent mainstream infrastructure for tracking AI search citation changes with the same maturity. This is one of the things I'm working on with GeoReady's answer snapshot monitoring workflow: capturing citations over time so drift becomes easier to detect.

The practical implication: treating AI visibility as a one-time fix is wrong. It's a continuous monitoring problem, same as ranking monitoring, just for a different system.

Where to Start

If you want to diagnose your AI visibility gap, the sequence I'd suggest:

Run visibility checks across platforms. Query ChatGPT, Perplexity, and Google AI Overviews with the exact queries your target audience uses. Note which competitors appear and which of your pages, if any, get cited. Do this for 10-15 queries across your core topics.
Identify the citation pattern. Are there any of your pages that do get cited? What do they have in common structurally? This gives you a baseline for what's already working.
Audit your highest-value content for GEO signals. Focus on answer density and entity clarity first, these are the highest-impact signals I've found and they're directly actionable. Does each section lead with a direct answer? Is author attribution visible and marked up in schema?
Prioritize factual precision on pages making strong claims. Review pages with statistics, recommendations, or comparative claims. Add attribution where it's missing. Qualify claims that are really observations rather than established facts.
Track your changes. After making GEO improvements to a set of pages, run visibility checks again in four to six weeks. Note whether citation frequency changes. This is rough monitoring, but it gives you directional signal on what's working.

The underlying logic is the same as traditional SEO, understand the system's optimization target, align your content with it, measure the results. The system just has different optimization targets than Google's ranking algorithm.

What This Means for SEO Practice

AI search isn't replacing Google search. The traffic data doesn't support that, at least not yet. But AI-generated answers are increasingly the first touchpoint for queries across many categories, and the practitioners who build AI visibility now are building something that doesn't yet show up in standard analytics.

The good news is that GEO-optimized content is also good content by most reasonable standards. High answer density, clear structure, factual precision, explicit authorship, these make content better for human readers too. There's no adversarial tradeoff between optimizing for AI retrieval and optimizing for human engagement.

The bad news is that the tooling to measure and track AI search visibility is still catching up to the problem. Most SEO dashboards can't tell you whether you're appearing in AI answers, which queries are driving AI citations, or whether your citation rate is improving or declining over time.

That's the gap I'm focused on closing. The patterns are legible enough to act on. The data collection problem is solvable. And the practitioners who treat AI visibility as a separate, measurable problem, rather than assuming rankings transfer, will have a significant head start.

Juan Camilo Auriti is building GeoReady, a set of tools for GEO audits, AI search visibility monitoring, and citation quality analysis. He writes about AI search, GEO methodology, and what practical visibility checks reveal.

GEO Optimizer v4.10.0: AI Search Audits Need Signals, Not Checklists

Juan Camilo Auriti — Thu, 30 Apr 2026 06:32:49 +0000

I released GEO Optimizer v4.10.0.

The codename for this release is Veil.

Not because this version adds one huge visible feature, but because it focuses on something more important for the long-term direction of the project: making hidden signals easier to detect, classify, and reason about.

GEO Optimizer started as a simple idea:

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

That question looks simple.

It is not.

Classic SEO tooling is mostly built around crawling, indexing, ranking, metadata, schema, performance, content structure, links, and discoverability in traditional search results.

Those things still matter.

But AI search adds a different layer.

A page does not only need to be found.

It needs to be understood.

It needs to be trusted.

It needs to be extractable.

It needs to be citeable.

It needs to survive summarization without losing meaning.

It needs to expose enough structure for an AI system to decide, among many possible sources, that this page is worth using in a generated answer.

That is the problem GEO Optimizer is trying to measure.

Not perfectly.

Not magically.

But technically, iteratively, and in the open.

What GEO Optimizer is

GEO Optimizer is an open-source Python toolkit for Generative Engine Optimization.

The goal is to audit, optimize, and monitor whether a website is ready for AI search systems such as ChatGPT, Perplexity, Claude, Gemini, and similar answer engines.

You can run it from the CLI:

pip install --upgrade geo-optimizer-skill
geo audit --url https://example.com

You can audit a sitemap:

geo audit --sitemap https://example.com/sitemap.xml --max-urls 25

You can compare before and after versions of a page:

geo diff \
  --before https://example.com/page-old \
  --after https://example.com/page-new

You can track changes over time:

geo audit --url https://example.com --save-history --regression
geo history --url https://example.com

You can also generate files and structures that help AI discovery:

geo llms --base-url https://example.com --output ./public/llms.txt
geo schema --type faq --url https://example.com

The basic workflow is intentionally simple.

Give GEO Optimizer a URL.

It returns a score, findings, and recommendations.

The larger goal, however, is not to create another vanity score.

The goal is to build a practical audit layer for a new kind of visibility problem.

Why this release matters

v4.10.0 is not about adding more checklist items.

It is about refining the architecture of the signals.

That distinction matters.

A checklist asks:

Is there schema?
Is there a title?
Is there a meta description?
Is there an llms.txt file?
Are AI crawlers blocked?

Those questions are useful, but they are only the first layer.

A signal-based audit asks deeper questions:

Is the content actually reliable enough to cite?
Are claims supported or likely to trigger hallucinations?
Does the page satisfy the intent of AI search queries?
Is the site consistent across technical, semantic, and trust layers?
Can the content be interpreted without forcing an AI system to guess?
Can future audits compare signal movement over time?

That is the direction of v4.10.0.

It is less about surface-level optimization and more about operationalizing AI search readiness.

1. Hallucination Bait Detection

The first major addition in v4.10.0 is Hallucination Bait Detection.

This is one of the areas I care about most.

When people talk about GEO, they often focus on how to get cited by AI systems.

That is only half of the problem.

The other half is this:

What happens when your content gives an AI system just enough information to sound confident, but not enough information to be accurate?

That is hallucination bait.

A page can unintentionally encourage bad AI output when it contains content patterns such as:

unsourced statistics;
absolute claims without evidence;
speculative statements written as facts;
vague numerical ranges;
AI-generated language with no grounding;
self-citations used as proof;
missing units in measurements;
sensitive claims without proper context or disclaimers.

These patterns matter because AI search engines do not only retrieve text.

They interpret it.

They compress it.

They combine it with other sources.

They may cite it.

If your page contains unsupported or ambiguous claims, the problem is not only that the page may rank poorly.

The problem is that it may be cited incorrectly, summarized incorrectly, or avoided entirely because the trust signals are weak.

In v4.10.0, GEO Optimizer detects eight hallucination-bait patterns and assigns severity levels.

The goal is not to punish content.

The goal is to make risky patterns visible before they become reputation problems.

For example, consider this sentence:

This method improves AI visibility by 300% for every website.

That sentence has multiple problems.

It is absolute.

It is unsourced.

It uses a strong statistical claim.

It generalizes across every website.

It is exactly the kind of sentence that can look good in marketing copy and bad in an AI-generated answer.

A better version would be:

In our internal tests on selected pages, this method improved citation readiness scores by up to 30%, depending on content structure, schema quality, and source clarity.

Still not perfect.

But it is more bounded.

More specific.

Less likely to become hallucination bait.

That is the type of distinction GEO tooling needs to surface.

2. AI Search Intent Mapping

The second important addition is AI Search Intent Mapping.

Traditional SEO already works with search intent.

But AI search changes how intent is expressed and satisfied.

A user does not always type a short query anymore.

They may ask:

What is the best way to optimize a website so ChatGPT or Perplexity can cite it?

Or:

Compare the main tools for AI search visibility and explain which one is best for a developer workflow.

Or:

Give me a practical checklist to make my SaaS website more citeable by AI answer engines.

These are not just keywords.

They are tasks.

They combine research, comparison, recommendation, explanation, and action.

v4.10.0 analyzes content across four intent categories:

informational;
navigational;
transactional;
commercial.

The intent mapping works with pattern matching in both English and Italian.

This matters because many websites are technically optimized, but they do not clearly satisfy the type of question an AI system is trying to answer.

A page may be informative but not comparative.

A page may be commercial but not trustworthy.

A page may describe a product but fail to answer the actual buyer questions.

A page may have strong copy but weak extraction points.

For AI search, this is a problem.

Generated answers often need to map a user query to source passages quickly.

If your content does not expose its purpose clearly, the AI system has to infer too much.

That increases ambiguity.

And ambiguity is bad for citation.

In practical terms, AI Search Intent Mapping helps answer questions like:

What kind of AI search queries could this page satisfy?
Which intent categories are underrepresented?
Is the page useful for comparison-style queries?
Does it provide enough direct answers?
Does it contain actionable material or only generic positioning?
Does the content match the likely prompt patterns users will write?

This is the bridge between content strategy and technical GEO auditing.

3. HTTP retry with exponential backoff

The third addition is less glamorous, but important: HTTP retry with exponential backoff.

Audit tools live or die by reliability.

If a tool audits a website once and fails because of a transient timeout, a temporary 5xx error, a connection reset, or rate limiting, the result is not useful.

In v4.10.0, fetch_url() now retries transient failures with configurable attempts and backoff.

That includes:

timeouts;
5xx responses;
connection errors;
429 rate limiting.

This is not a flashy feature.

But it matters for real usage.

Especially when auditing:

client websites;
production sites behind CDNs;
large sitemaps;
staging environments;
slower CMS installations;
sites with intermittent network behavior.

A serious audit tool cannot treat every temporary failure as a final truth.

It needs to distinguish between:

a real accessibility problem;
a temporary network problem;
a server that is rate limiting;
a target that consistently fails.

That distinction becomes even more important as GEO Optimizer moves toward monitoring, tracking, and longitudinal analysis.

If the audit history is noisy, the insight becomes noisy.

Reliability is part of the signal architecture.

4. Telemetry System

v4.10.0 also introduces a structured telemetry system.

This is local telemetry, backed by SQLite in the user environment.

The goal is not surveillance.

The goal is operational visibility.

GEO Optimizer now tracks structured events with a geo_ prefix, including events such as:

geo_audit_run;
geo_score_improved;
geo_suggestion_applied;
geo_api_error;
geo_badge_generated.

This matters because audits are not one-time artifacts.

A single audit tells you where you are now.

Telemetry helps you understand movement.

What changed?

Which suggestions were applied?

Did the score improve?

Did errors increase?

Are badges being generated?

Are audits being repeated over time?

This is the foundation for more serious workflows:

dashboards;
regression detection;
client reporting;
CI/CD quality gates;
historical visibility tracking;
release impact analysis;
product analytics for the audit engine itself.

GEO is becoming less of a content trick and more of an operations problem.

Telemetry is part of that transition.

Why I am focusing on signals instead of checklists

The easy version of GEO is a checklist.

Add llms.txt.

Add schema.

Allow AI crawlers.

Write clearer headings.

Add sources.

Use statistics.

Create FAQ sections.

All of that can help.

But if GEO stops there, it becomes shallow very quickly.

A website can pass a checklist and still be weak for AI citation.

For example:

it can have schema, but poor entity consistency;
it can have citations, but cite low-quality or circular sources;
it can have long content, but no extractable definitions;
it can allow AI crawlers, but block important assets through CDN behavior;
it can publish many pages, but expose no clear topical authority;
it can use strong claims, but provide no verification path;
it can rank well in classic search, but be hard to summarize reliably.

This is why I am moving GEO Optimizer toward signal architecture.

A good GEO audit should not only ask whether something exists.

It should ask whether that thing contributes to citation readiness.

A title tag exists.

But does it clarify the page?

Schema exists.

But does it describe the right entity?

Sources exist.

But are they useful, traceable, and relevant?

Statistics exist.

But are they grounded?

The page has content.

But can a model extract a safe answer from it?

This is the difference between compliance and usefulness.

And AI search rewards usefulness much more than mechanical compliance.

Example workflow

A simple workflow looks like this:

pip install --upgrade geo-optimizer-skill
geo audit --url https://example.com --format rich

Then inspect the weak areas.

If the score is low because the site blocks AI crawlers, fix robots.txt.

If the score is low because schema is missing, add structured data.

If citability is low, improve definitions, source clarity, statistics, and content structure.

If hallucination bait appears, rewrite risky claims.

If intent mapping is weak, restructure the page around the questions users actually ask in AI search systems.

Then run the audit again:

geo audit --url https://example.com --save-history --regression
geo history --url https://example.com

That is the workflow I want GEO Optimizer to support:

audit the current state;
identify weak signals;
apply changes;
compare results;
monitor over time;
catch regressions before visibility drops.

Tests and reliability

This release also continues the focus on test coverage and mocked execution.

v4.10.0 ships with 1425 tests, all mocked, with zero network access during the test suite.

That is important for this kind of tool.

A GEO audit engine touches many unstable surfaces:

remote websites;
HTML parsing;
schema extraction;
robots rules;
HTTP behavior;
content heuristics;
scoring thresholds;
output formats;
local history;
telemetry;
API and CLI boundaries.

If tests depend on real websites, the test suite becomes unreliable.

A site changes and your test breaks.

A server times out and your CI fails.

A third-party page updates its markup and your expected output is no longer valid.

Mocked tests keep the engine deterministic.

For an audit tool, determinism is not a luxury.

It is part of trust.

The current CI path is also moving through ruff and gradual mypy, because the project is becoming large enough that type boundaries and static checks are no longer optional niceties.

They are maintenance infrastructure.

What this means for the roadmap

The public roadmap for GEO Optimizer is now more deliberate.

I do not want to ship noisy releases just to make the repository look active.

I want focused waves.

v4.10.0 is the signal refinement release.

The next direction is broader:

better retrieval surface analysis;
deeper scoring recalibration;
stronger structural pattern recognition;
clearer reporting;
better web experience;
more useful monitoring;
more reliable citation-quality analysis;
stronger factual accuracy checks.

The long-term goal is to move GEO Optimizer from a CLI audit tool into a broader ecosystem for AI search visibility.

That means:

CLI for developers;
web version for faster testing;
reports for teams and clients;
monitoring for change detection;
MCP integration for AI-assisted workflows;
structured outputs for CI/CD and automation;
open-source core for transparency.

I still think the CLI matters.

A lot.

Developers need local, scriptable, inspectable tools.

But not every useful GEO workflow should require living in the terminal.

That is why the web layer matters too.

The CLI gives control.

The web version gives accessibility.

The open-source engine keeps the system inspectable.

GEO is not “SEO is dead”

I do not believe SEO is dead.

I think SEO is becoming more layered.

Traditional search still matters.

Technical SEO still matters.

Content quality still matters.

Schema still matters.

Crawlability still matters.

But AI search introduces new questions:

Can this page be safely summarized?
Can this claim be verified?
Is the entity behind the content clear?
Does the page expose useful extraction points?
Would an AI answer engine cite this source?
Would it cite it accurately?
Would it choose a competitor instead?

That is the layer I am building for.

The future of organic visibility will not be only about being found.

It will also be about being understood, trusted, and cited.

Try it

Install or upgrade:

pip install --upgrade geo-optimizer-skill

Run an audit:

geo audit --url https://example.com

Try a richer output:

geo audit --url https://example.com --format rich

Explore the project:

GitHub: https://github.com/Auriti-Labs/geo-optimizer-skill
Web demo: https://geoready.dev
Documentation: https://auriti-labs.github.io/geo-optimizer-skill/
Release v4.10.0: https://github.com/Auriti-Labs/geo-optimizer-skill/releases/tag/v4.10.0

If you try it on your own site, I would be especially interested in feedback around:

hallucination bait findings;
intent mapping quality;
false positives;
confusing recommendations;
missing GEO signals;
reporting clarity;
CI/CD use cases;
web version usability.

GEO is still early.

That is exactly why open tools matter.

We need fewer vague claims about “AI visibility” and more inspectable systems that developers, founders, SEO specialists, and content teams can actually test.

That is what I am trying to build with GEO Optimizer.

v4.10.0 is not the final destination.

It is another step toward a more measurable, technical, and transparent approach to AI search visibility.

How I Use Multiple AI Models in Real Workflows

Juan Camilo Auriti — Tue, 28 Apr 2026 12:10:00 +0000

One model for everything is usually the wrong strategy.

A lot of people still ask:

Which AI model is the best?

After months of daily use, I think that question misses the real opportunity.

The better question is:

Which model is best for this specific task?

That shift changed how I work, build, write, and ship projects faster.

Instead of relying on one tool, I now use multiple AI models in a practical workflow.

Why One Model Usually Isn’t Enough

Different models have different strengths.

Some are better at:

reasoning deeply
planning systems
writing code
moving fast
summarizing large inputs
generating creative angles
running locally for privacy

Trying to force one model to do everything often creates friction.

You either lose quality, speed, or flexibility.

My Current Multi-Model Approach

I choose models based on the job.

1. Deep Thinking / Architecture

When I need:

strategy
technical planning
tradeoff analysis
system design

I use stronger reasoning models.

These are slower, but worth it for important decisions.

2. Coding / Iteration Speed

When I need:

component drafts
bug fixing
repetitive coding
quick iterations
code suggestions

I use faster coding-oriented models.

Speed matters here.

3. Writing / Content Structuring

When I need:

article outlines
title ideas
rewriting messy notes
organizing thoughts

I use models that are fast and clean with language.

4. Local Private Tasks

When I need:

privacy
offline use
experimentation
low-cost repetitive tasks

I use local models.

They are often underrated.

The Real Upgrade: Workflows

The biggest productivity jump did not come from a better prompt.

It came from chaining tools together.

Examples:

Content Workflow

Idea → Outline → Draft → Improve → Publish → Repurpose

Dev Workflow

Problem → Analyze → Plan → Code → Review → Refactor

Research Workflow

Question → Compare Sources → Summarize → Decide

That is where leverage appears.

Example: How I Build Faster

When working on a project, I often do something like this:

Use one model to analyze the task
Use another to generate implementation options
Use a coding model for execution
Use a stronger model for review
Save repeatable patterns for future tasks

This is much stronger than chatting with one assistant for hours.

What Most People Still Get Wrong

Many users still treat AI as:

a search engine
a toy
a rewrite tool
a novelty app

That leaves a lot of value unused.

The bigger opportunity is treating AI like a modular production system.

My Rules for Using Multiple Models

1. Match the tool to the task

Do not use one hammer for every problem.

2. Use expensive intelligence selectively

Reserve stronger models for higher-value decisions.

3. Use fast models for execution loops

Speed compounds.

4. Keep human judgment central

Models generate options. You decide.

5. Save successful workflows

If something works twice, systemize it.

What This Means for Developers

For developers, builders, and operators, AI usage is becoming a skill layer.

Not just prompt skill.

Operational skill.

The advantage is shifting toward people who know:

when to use which model
how to combine tools
how to remove friction
how to systemize wins

Final Thought

The future may not belong to people using the smartest model.

It may belong to people using multiple models intelligently.

DEV Community: Juan Camilo Auriti

My CI hadn't run a single one of those tests in two months and stayed green the whole time

Why it skips instead of failing

The part that stung

The guard

The real fix was upstream of all of it

Check yours in one command

example.com and example.com/ were two rows, and 86.9% of my database was one bug

The bug

Why it stayed invisible

The fix

Careful with www and rstrip

The transferable part

Your JSON-LD is probably inside a @graph, and most parsers don't look there

Who emits shape two

How many parsers get it wrong

The fix is boring

Check your own page in ten seconds

Why I care about this beyond my own bug

A prompt told me my tool was built on a product that doesn't exist

The ambiguity

The counter-evidence that told me it was fixable

The fix

What I deliberately didn't touch

What it measured

If you have an acronym

I almost started a Medium column about getting cited by LLMs. Then I read Medium's robots.txt

What's actually in the file

Blocked isn't the same as invisible

Six platforms, same check

Why I cared enough to check

The rule

How to Make Your Site Quotable by AI in 30 Minutes

Why 30 Minutes

Step 1: robots.txt (5 minutes)

The Rendering Trap

Step 2: llms.txt (5 minutes)

Step 3: Schema.org JSON-LD (10 minutes)

Organization + WebSite Schema

FAQ Schema

Step 4: Content Structure — BLUF (10 minutes)

Before: Narrative Structure (Hard to Quote)

After: BLUF Structure (Easy to Quote)

The Editing Rule

The Order Matters

What This Gets You

The 4-Layer Model for AI Search Readiness: What I Learned Auditing 360 Sites

The 4-Layer Model for AI Search Readiness: What I Learned Auditing 360 Sites

The Core Thesis: AI Search Selects, It Doesn't Rank

Layer 1: Access — Can the AI Crawler Reach You?

robots.txt: Allow the AI Crawlers

The Rendering Trap

Layer 2: Orientation — Can It Find What Matters?

Minimal llms.txt Example

Layer 3: Understanding — Can It Parse What You Are?

Benchmark Data

Organization + WebSite JSON-LD Template

Layer 4: Quotability — Can It Extract a Self-Contained Passage?

Before: Narrative Structure (Hard to Quote)

After: BLUF Structure (Easy to Quote)

The Correlation Data: What Actually Moves the Score

Common Infrastructure Mistakes

Where the Benchmark Stands

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

The CLI gives control. The SaaS gives continuity.

GEO is not only about being cited once

The problem with one-time audits

What GeoReady adds on top of GEO Optimizer

Keeping the core open source

Why the JSON contract matters

Why v4.12.2 matters

GEO and SEO are converging

The SaaS is not only a dashboard

Where this is going

The product principle

Try it

The Missing Layer in Google I/O 2026: Agent-Ready Websites

The announcement I am focusing on: WebMCP and the agentic web

Why this matters beyond WebMCP

The old web contract is changing

Careful with `www` and `rstrip`