DEV Community: Juan Camilo Auriti

7 open-source AI visibility trackers launched on HN this year. Here's what each one actually does.

Juan Camilo Auriti — Sun, 01 Nov 2026 08:00:00 +0000

The AI visibility space has a paid side and an open-source side. The paid side is crowded: Otterly ($29/mo), Peec AI ($95/mo), Scrunch ($250/mo), Profound (enterprise), AthenaHQ ($295/mo), Semrush AI Visibility ($99/mo), and a dozen more. The open-source side is smaller but growing fast. Seven projects launched on Hacker News in 2026, each taking a different angle on the same problem: can you check your AI search visibility without paying a subscription?

Here is what each one does, what it costs to run, and what it leaves out.

1. Elmo

Elmo is a self-hosted AEO platform, MIT licensed. It tracks how your brand appears across ChatGPT, Claude, Gemini, Grok, Perplexity, Copilot, DeepSeek, Mistral, and Google's AI Mode and AI Overviews. You supply your own LLM API keys, so the cost is whatever the API providers charge per query. No per-prompt subscription.

What it does: brand mention tracking, citation tracking, competitor benchmarking, sentiment. Coverage is unusually wide for open source (9+ engines).

What it leaves out: site audit. Elmo tracks whether you appear in AI answers. It does not check whether your site is crawlable or parseable. You need a separate tool for that.

Cost to run: API costs only. If you run 50 prompts across 9 engines weekly, expect $5-15/week in API fees depending on which models you use.

2. Canonry

Canonry is a CLI that tracks how ChatGPT, Gemini, and Claude cite your site. Self-hosted on SQLite, config-as-code in YAML, CLI and API are first-class.

What it does: visibility scores, citation-readiness checks, brand accuracy across providers over time. Cross-references with Google Search Console and Google Analytics for a combined view.

What it leaves out: no site audit, no fix recommendations. It tells you what is happening, not what to do about it.

Cost to run: API costs for the LLM queries. SQLite is free.

3. Auto-geo

Auto-geo is a file-based GEO CLI from Shadow Inc, an AI PR lab. npm install or brew install.

What it does: prompt tracking (prompts discover reads your homepage and proposes queries), citation checking across ChatGPT, Claude, Gemini, Perplexity, and Grok, history diffs (which prompts you won or lost since last run), and a doctor command that audits pages for AI-citation readiness.

What it leaves out: the doctor audit is lighter than a full site audit. It checks structure and "chunkability" but does not check 27 AI crawlers or run a full scoring rubric.

Cost to run: API costs for the LLM queries. npm package is free.

4. Lettertrace

Lettertrace is a BYOK (bring your own key) library for tracking AI search, MIT licensed. It is a library, not a full platform. You embed it in your own codebase.

What it does: tracks how your brand appears in AI answers using your own LLM harness. Designed for developers who want to build visibility tracking into existing systems.

What it leaves out: no UI, no dashboard. It is a library. You build the interface.

Cost to run: API costs only.

5. CiteLadder

CiteLadder is an open-source AI search visibility tracker, recently launched on HN.

What it does: tracks whether your site gets cited by AI search engines. Details are sparse since the project is new.

What it leaves out: too early to assess. The repo is fresh.

Cost to run: not specified.

6. GetCito

GetCito is an open-source AEO tool, MIT licensed, run by a marketing agency.

What it does: AI Crawlability Clinic that checks how well AI bots can reach and parse your content.

What it leaves out: maintenance. The public repo has had a single substantive code commit since it launched in late 2025. It is run by an agency, not a dedicated product team. Do not expect ongoing fixes or new engine support.

Cost to run: free, but you get what you pay for in terms of maintenance.

7. Ansvisor

Ansvisor is an open-source, cloud-ready AI visibility platform. It tracks mentions, citations, competitors, and Share of Voice across ChatGPT, Gemini, Perplexity, Claude, Copilot, Google AI Overviews, and Google AI Mode.

What it does: separates owned citations, competitor citations, and third-party sources. Cross-platform monitoring with historical trends.

What it leaves out: no site audit. Like Elmo, it tracks visibility, not crawlability.

Cost to run: open source for self-hosting. Managed cloud option listed as coming soon.

Where geo-optimizer fits

GEO Optimizer is the only open-source tool in this list that does a deterministic site audit rather than citation tracking. The 16 CLI commands, 47 content checks, 27 AI crawlers, and 9 scoring categories check whether your page is reachable, parseable, and quotable. It does not track whether you appear in AI answers over time. That is what the monitoring layer on geoready.dev is for.

The distinction matters. Citation trackers (Elmo, Canonry, Ansvisor, Auto-geo, Lettertrace, CiteLadder) tell you whether you appear in AI answers. Site auditors (geo-optimizer, GetCito) tell you whether AI crawlers can read your page in the first place. You need both: audit to fix the foundation, monitor to track whether the fixes worked.

Comparison table

Tool	What it does	Audit or track	Engines	License	Maintained
Elmo	Brand tracking, citations, competitors	Track	9+	MIT	Active
Canonry	Citation tracking, GSC integration	Track	3	Open source	Active
Auto-geo	Prompt tracking, doctor audit	Both	5	Open source	Active
Lettertrace	BYOK tracking library	Track	Custom	MIT	Active
CiteLadder	Visibility tracking	Track	TBD	Open source	New
GetCito	Crawlability clinic	Audit	N/A	MIT	Stale
Ansvisor	Citations, competitors, SoV	Track	7+	Open source	Active
GEO Optimizer	Site audit, scoring, fixes	Audit	27 crawlers	MIT	Active (v4.19.5)

What none of them have done

None of these tools, including mine, has published a calibration study testing whether their scores or metrics predict actual citations. I did, and the result was null. That study is at github.com/Auriti-Labs/geo-optimizer-skill/tree/main/research/calibration-2026-10, with pre-registration hash and raw data.

If you use any of these tools, ask the maintainers to do the same. A score that has not been tested against reality is a number, not a metric.

If you want to run a free site audit, it is on geoready.dev. The CLI is on GitHub, 1,137 stars, MIT licensed, 2,000+ tests.

Google moved to inline citations in August. CTR quadrupled. Here's what to optimize for now.

Juan Camilo Auriti — Sat, 31 Oct 2026 08:00:00 +0000

In August 2026, Google changed how AI Overviews display citations. Instead of a source list at the bottom of the card, citations now appear inline, as numbered links embedded directly in the AI-generated text, next to the claim they support. Early data from publishers who shared Search Console numbers shows click-through rates roughly quadrupled compared to the old bottom-only format.

If you were optimizing for the old citation format, the target moved.

What changed

Before August 2026, AI Overviews displayed a text summary with a carousel or list of source links at the bottom. Users had to scroll past the AI text to find the sources. The Nielsen Norman Group had previously found that users exhibit "satisficing" behavior in search: they stop scanning once they find an acceptable answer. When all citations lived at the bottom, source pages received minimal traffic.

The new format places clickable references directly in the text. When the AI Overview makes a specific claim, a numbered link appears adjacent to that statement. Bottom citations still exist but serve as supplementary "additional sources" rather than the primary attribution mechanism.

First Page Sage's CTR data confirmed the shift: citation CTR roughly quadrupled between December 2025 and August 2026, coinciding with the inline format rollout.

The numbers

A study of 6,200 AI Overviews captured between August 12 and 28, 2026 measured citation placement patterns and early CTR data from 23 publishers who shared anonymized Search Console data:

Metric	Inline citations	Bottom-only citations
Median CTR	3.1%	1.1%
CTR range	2.4% to 3.8%	0.8% to 1.4%
Lift	2.8x	baseline

For comparison, traditional blue links in positions 1-3 below the AI Overview still get 4.2% to 8.7% median CTR. Inline citations in AI Overviews are now closer to that range than to the old bottom-only format.

What content gets inline placement

The study also broke down CTR by content type:

Content type cited	Inline CTR	Bottom-only CTR	CTR lift
Statistical data and research	4.3%	1.4%	207%
How-to instructions	3.8%	1.3%	192%
Product comparisons	3.2%	1.0%	220%
Definitions and explanations	2.1%	0.9%	133%
News and current events	2.9%	1.1%	164%

Statistical data and research content gets the highest inline CTR (4.3%) and the largest lift over bottom-only placement (207%). Pages with specific statistics, original research data, and factual claims that need sourcing are the most likely to earn inline placement and the most likely to get clicked when they do.

67% of inline citations in research-oriented queries pointed to original studies rather than secondary coverage. AI Overviews preferentially cite the source of data, not articles summarizing that data.

What this means for your content

Three concrete changes:

1. Put statistics and factual claims near the top of your content. The Babel42 study (October 2026) found that 67% of AI Overview quoted passages come from the first 30% of the page. If your key statistics are buried in the conclusion, they are less likely to be extracted. If they are in the first two sections, they are more likely to become an inline citation.

2. Cite your own sources inline. Pages that link to primary sources (studies, official documentation, government data) are more likely to be positioned as the "source of data" rather than a secondary summary. AI Overviews cite the source, not the article about the source. If you are the page that links to the original study, you become the intermediary. If you are the original study, you are the citation.

3. Structure factual claims as self-contained sentences. Inline citations attach to specific claims. A sentence like "78% of AI Overviews cite pages outside the top 10 organic results" is easy to attach a source link to. A paragraph of context without a discrete factual claim is harder to cite inline.

The limitation

The CTR data comes from 23 publishers who shared anonymized Search Console data. That is a small sample, and publishers who share data may skew toward those with better-than-average performance. The 2.8x lift is a median, not a guarantee. Individual results will vary by industry, query type, and position within the AI Overview.

The format change is also still rolling out. Some queries may still show the old bottom-only format. Google does not publish which queries use which format.

What to check

If you want to see how your pages score on the signals that correlate with AI Overview citation, run a free audit on geoready.dev. The audit checks content structure, schema markup, published dates, named authors, and canonical URLs, all signals the WashU study found associated with AI Overview citation. The same engine is available as a CLI on GitHub, open source, MIT licensed.

The audit tells you if your pages are structured for citation. It does not tell you if Google will cite them inline. But if your pages are missing the structural signals, inline placement is not even in play.

ChatGPT's Reddit citations dropped 88% in six months. The 'get mentioned on Reddit' advice is already obsolete.

Juan Camilo Auriti — Fri, 30 Oct 2026 08:00:00 +0000

Every GEO guide published in the last 18 months says the same thing: get mentioned on Reddit because LLMs pull from it. The advice was correct in early 2025. It is now wrong for ChatGPT, and the data proving it has been public since October 12, 2026.

The number

Ahrefs' citation tracking data, published October 12, 2026, shows ChatGPT's Reddit citations dropped 88% over six months, from March to September 2026. The data comes from their Brand Radar product, which tracked 2.4 to 3.8 million US ChatGPT answers per month across that period.

Reddit is still cited by ChatGPT, but at a fraction of what it was. The trajectory is downward, and it is steep.

Why it happened

The Ahrefs fan-out data explains why. ChatGPT's query behavior is shifting away from forums and aggregators toward primary sources. In August and September 2026:

"Official" appeared in 13.1% of English fan-out queries, up from 10.1% in August
"Price" rose 47% in relative terms (6.0% to 8.9%)
"Best" stayed flat at 5.3%

ChatGPT is increasingly searching for official brand sites, pricing pages, and specifications. It is searching less for Reddit threads, listicles, and aggregator content. The site: operator data confirms this: 75.9% of ChatGPT's site-specific searches target brand websites, not retailers, forums, or review sites. Reddit and Facebook together account for 1.9% of site: searches.

Of the 17 publishers with OpenAI licensing deals, only Reddit appears in the top 150 most site: searched domains. ChatGPT rarely looks it up directly.

Perplexity is the opposite

While ChatGPT's Reddit citations dropped 88%, Perplexity still cites Reddit in roughly 20% of its answers, according to Evertune's data. Reddit accounts for about 1 in 5 Perplexity citations. Wikipedia, ChatGPT's most-cited domain, tops out at about 5% on Perplexity.

The two engines are diverging. ChatGPT leans on training data and official brand sites. Perplexity leans on live web retrieval and community discussions. A Reddit strategy that is useless on ChatGPT may still work on Perplexity, and a brand-site strategy that works on ChatGPT may be less effective on Perplexity.

What the GEO guides missed

The "get mentioned on Reddit" advice was based on 2024 and early 2025 data, when ChatGPT was citing Reddit heavily. The advice spread because it was true at the time and because it was actionable: you can post on Reddit, you cannot easily get into an LLM's training data.

But the advice treated AI search as a static system. It is not. ChatGPT's retrieval behavior changed substantially between March and September 2026. The fan-out queries shifted toward "official" and "price." The Reddit citations dropped. The model is being tuned to prefer primary sources over community discussion, and the citation data shows it happening in real time.

This is the problem with tactics-based GEO advice. A tactic that works today may not work in six months because the underlying retrieval model changed. The data does not wait for the blog posts to catch up.

What to do instead

Three things that are more durable than "get mentioned on Reddit":

1. Be the primary source for something specific. ChatGPT's fan-outs increasingly look for official documentation, pricing, and specifications. If your page is the canonical source for your own product's features, pricing, or documentation, it is more likely to be retrieved than a Reddit thread discussing it.

2. Test on each platform separately. ChatGPT and Perplexity cite different sources from different retrieval mechanisms. Run your target queries on both. If you appear on Perplexity but not ChatGPT, your gap is in the training data or the brand-site retrieval path. If you appear on neither, your gap is in crawlability and content structure.

3. Monitor, do not assume. The Reddit citation drop happened in six months. If you built a strategy around Reddit mentions in March 2026, it was already eroding by June. Citation patterns are volatile. The Babel42 study found only 11% of Google AI Overviews cite the same sites two days in a row. A one-shot audit tells you where you are today. It does not tell you if that changed since yesterday.

If you want to check whether AI crawlers can reach your site, run a free audit on geoready.dev. The same engine is available as a CLI on GitHub, open source, MIT licensed.

The audit checks if you are reachable. It does not check if you are in the training data. Nothing checks that, except asking the model. And the model's answer changes every six months.

ChatGPT mentions 3.2x more brands than it cites. Google cites 2.4x more than it mentions. They disagree 62% of the time.

Juan Camilo Auriti — Thu, 29 Oct 2026 08:00:00 +0000

BrightEdge ran identical prompts across ChatGPT, Google AI Overviews, and Google AI Mode. The three platforms disagreed on which brands to recommend 62% of the time. Only 17% of queries produced the same brand recommendations across all three.

If you are optimizing for "AI search" as if it is one thing, this data says it is at least three different things, and they contradict each other more often than they agree.

The data

BrightEdge published the study analyzing tens of thousands of identical prompts across the three platforms using their AI Catalyst tool. The key numbers:

61.9% of queries get different brand recommendations across platforms
Only 17% of queries result in the same brands across all three
Only 33.5% of queries trigger brands from all three platforms at all
ChatGPT is silent on 43.4% of queries (no brand mentioned)
Google AI Overviews is silent on only 9.1% (it almost always mentions something)

The citation paradox

The most counterintuitive finding is how mentions and citations work on each platform:

Platform	Mentions per query	Citations per query	Ratio
ChatGPT	2.37	0.73	Mentions 3.2x more than cites
Google AI Overviews	6.02	14.30	Cites 2.4x more than mentions
Google AI Mode	1.59	9.49	Cites 6x more than mentions

ChatGPT names brands 3.2 times more often than it links to them. It says "you should look at Notion" without linking to notion.com. Google AI Overviews does the opposite: it links to 14.30 sources per query but only names 6.02 brands. Google cites more pages than it recommends.

This means two different things are happening. ChatGPT operates as a brand recommender that relies on training data and trust patterns. It knows what Notion is and says so, but does not always retrieve a source page. Google AI Overviews operates as a citation engine that retrieves pages and links them, but the pages it links are not always the brands it would recommend.

If your strategy is "get cited by AI," you need to know which game you are playing. On ChatGPT, the game is being in the model's knowledge. On Google AI Overviews, the game is being in the retrieved source pool.

Where the platforms agree

The disagreement is not uniform across query types. BrightEdge broke down alignment by query intent:

Query type	Same-brand agreement
"Compare" queries	80%
"Buy" queries	62%
"Where" queries	38%
"Best" queries	23%

Comparison queries produce the most agreement. When someone asks "X vs Y," all three platforms tend to name the same competitors. "Best" queries produce the least agreement. When someone asks "best tool for X," the three platforms recommend different brands 77% of the time.

This makes sense. Comparison queries have a finite answer set (the two things being compared). "Best" queries are open-ended, and each platform's ranking model fills the blank differently.

Industry breakdown

Disagreement rates vary by industry:

Industry	Disagreement rate
Healthcare	68.5%
Education	62.1%
B2B Tech	61.7%
Finance	57.9%
E-Commerce	57.1%

Healthcare has the highest disagreement. E-Commerce the lowest. If you are in health or education, assuming your visibility on one platform transfers to another is wrong 60-68% of the time.

What this means for your audit

If you run a single audit and call it "AI visibility," you are measuring one surface. The calibration study I published last week tested one engine (Perplexity) and found no relationship between the GEO score and citation. That result might be different on Google AI Overviews, where citation behavior is structurally different.

The practical implication: test your visibility on each platform separately. Ask ChatGPT "what are the best tools for [your category]" and see if you are mentioned. Ask Google the same thing and check the AI Overview sources. Ask Perplexity and look at the citations. They will give you different answers 62% of the time, and that 62% is where your gap lives.

If you want to check whether AI crawlers can even reach your site, run a free audit on geoready.dev. It checks 27 AI crawlers and tells you which ones can access your content. The same engine is available as a CLI on GitHub, open source, MIT licensed.

The audit tells you if you are reachable. It does not tell you if you are recommended. These are three different platforms, and being reachable on all three does not mean being recommended on any of them.

I pre-registered a study, got a null result, and published it anyway. Here's why

Juan Camilo Auriti — Wed, 28 Oct 2026 14:00:00 +0000

Last week I published a calibration study showing that my tool's GEO score does not predict whether Perplexity cites a page. The odds ratio was 0.9625, p = 0.7172. Nothing.

The study was pre-registered. I wrote the analysis plan before collecting the data, committed its hash to the repo, and ran the exact analysis I said I would run. No cherry-picking, no p-hacking, no "let me try a different model and see if it becomes significant."

This is how that worked and why I think every tool that sells a score should do the same.

What pre-registration means

Pre-registration is a commitment device. You write down what you are going to measure, how you are going to measure it, and what counts as a result, before you have any data. Then you collect the data and run the analysis you said you would. If the result is null, you publish a null.

In my case, the pre-registration was a markdown file in the repo. It specified:

The sample: pages from sites that publish a sitemap, reachable, English-language
The outcome: whether the page's domain appeared in Perplexity Sonar's sources for two question templates
The primary analysis: logistic regression of domain citation on score/10, log rank, and log words
The secondary analyses: each scoring category individually, with Holm correction
The sensitivity analysis: excluding pages on sites that block AI bots

The file's SHA-256 hash is 441fcbb422964fdf2bf2b63eb02181ccbea9e7c5590d3e770399d567cd373ff8. You can verify it yourself:

sha256sum PREREGISTRATION.md
# should output: 441fcbb422964fdf2bf2b63eb02181ccbea9e7c5590d3e770399d567cd373ff8

The hash proves the plan existed before the data. I committed it to the repo on the same day I started collecting data. The analysis results were generated on October 17, 2026, on the exact rank values, to four decimal places.

Why I did not pivot

When the primary result came back null, I had options. I could have:

Tried different outcome variables (page citation instead of domain citation)
Tried different regression specifications
Looked for subgroups where the score did predict something
Run it on a different engine and hoped for a better result
Not published it at all

I did run the secondary analyses, because they were pre-registered. None of them were significant either. Every Holm-corrected p-value was 1.0000.

I did run the sensitivity analysis, because it was pre-registered. Excluding blocked pages did not change anything (OR 1.0408, p = 0.7288).

The page-level analyses (whether the exact page, not just the domain, was cited) were also pre-registered as secondary outcomes. Those odds ratios were above 1.0 (1.0568 and 1.0478) but still not significant (p = 0.6434 and p = 0.6933).

None of these were the primary outcome. The primary outcome was domain citation on template A. It was null. That is the result.

Why publish a null

Three reasons.

1. The tool is open source. People can check the code. If I published a study that only showed positive results, someone would eventually run their own and find nothing. Better to publish the null myself and explain what it means than have someone else discover it and conclude I was hiding it.

2. Null results are informative. The null tells you that a 0-to-100 score based on technical readability does not predict citation. That is useful. It means the score measures what it measures (citability) and not what it does not measure (citation). Users of the tool should know that distinction. Agencies selling GEO services based on readability scores should know it too.

3. Every other tool should do this. There are at least 15 paid AI visibility tools on the market. Peec AI ($95/mo), Otterly ($29/mo), Scrunch ($250/mo), Profound (enterprise), Semrush AI Visibility ($99/mo), AthenaHQ ($295/mo), LLM Pulse (EUR 49/mo), and others. None of them have published a calibration study. None of them have tested whether their scores predict citations. They sell visibility scores and share-of-voice metrics without showing the validation data.

I am not saying their scores are wrong. I am saying I do not know if they are right, because they have not shown the work. The work is: pre-register the analysis, collect the data, publish the result, whatever it is.

What I learned from the process

The pre-registration forced me to think through the analysis before I had data. That is harder than it sounds. I had to decide what the primary outcome would be, what controls to use, what counts as a secondary analysis, and what sensitivity checks to run. All before seeing a single citation.

It also made the writing easier. When the result came back null, I did not have to decide how to frame it. The analysis was pre-committed. I ran it, reported it, and wrote up what it said. No decisions about what to include or exclude. The pre-registration made those decisions for me.

The limitation I acknowledge

The study has one engine (Perplexity Sonar), one date (October 17, 2026), and one model version. The question is built from each page's own headline, so it tests whether a page is cited when the question is literally about that page's topic. That is a generous test. A more realistic test would use generic queries about the topic, not the page's own headline.

The sample also favours reachable, English-language sites that publish a sitemap. That is not the full web. It is the part of the web that AI crawlers can easily find.

I plan to run the study again with ChatGPT and Google AI Overviews, and with generic queries instead of headline-based ones. If the score predicts citation in those settings, I will publish that. If it does not, I will publish that too.

The files

Everything is at github.com/Auriti-Labs/geo-optimizer-skill/tree/main/research/calibration-2026-10:

PREREGISTRATION.md: the analysis plan, with the SHA-256 to verify it existed before the data
results.csv: 341 rows, one per page, no domain or headline, shuffled
analysis-results.txt: the output of the pre-registered analysis

You can reproduce the primary result from the CSV. If you find something I missed, open an issue.

ChatGPT searched the web only 14.4% of the time across 66.6 million responses

Juan Camilo Auriti — Wed, 28 Oct 2026 08:00:00 +0000

Ahrefs analyzed 66.6 million free, logged-out ChatGPT responses from August and September 2026. Only 14.4% triggered a web search. The other 85.6% were answered from training data alone.

If your content strategy assumes ChatGPT will crawl your site and cite you in real time, this number should change how you think about it.

The study

Ahrefs published the analysis on October 12, 2026. They collected 66.6 million responses from free, logged-out sessions on the GPT-5.6 Luna model, across all countries, along with the 15 million fan-out queries those responses produced. A separate citation dataset from their Brand Radar product tracked which domains ChatGPT cited in US answers from March to September 2026, covering 2.4 to 3.8 million answers per month.

What the numbers say

14.4% of responses involved a web search. Six in seven prompts were answered without looking anything up.
When ChatGPT did search, it ran about 1.6 fan-out queries per searching response. Not a broad crawl. A targeted lookup.
6.8% of fan-out queries used the site: operator to search a single website. That is 6.8% of 14.4%, so about 1% of all responses involved a site-specific search.
75.9% of those site-specific searches targeted brand websites, not retailers, forums, or review sites. ChatGPT looks for apple.com, ikea.com, the official source. It does not look for your blog post about apple.com.

The shift toward primary sources

The words inside the fan-out queries are changing fast. Between August and September 2026:

Word in fan-out query	August	September	Change
2026	17.6%	22.9%	+5.2 pts
official	10.1%	13.1%	+3.0 pts
price	6.0%	8.9%	+2.8 pts
india	3.0%	6.2%	+3.2 pts
best	5.0%	5.3%	+0.3 pts

"Official" grew by 3 percentage points in one month. "Price" grew by 47% in relative terms. "Best" barely moved. ChatGPT is moving away from listicle-style queries ("best CRM for startups") toward primary-source queries ("apple.com official pricing 2026").

What happened to Reddit

ChatGPT's Reddit citations dropped 88% over six months (March to September 2026), according to Ahrefs' citation data. The common advice in the GEO community is "get mentioned on Reddit because LLMs pull from it." That advice is already outdated for ChatGPT. Reddit is still cited, but at a fraction of what it was.

Perplexity is a different story. Reddit accounts for about 1 in 5 Perplexity citations, roughly 20%, according to Evertune's data. The two engines are diverging. What works on one does not work on the other.

What this means for your content

If 85.6% of ChatGPT responses come from training data, the content that matters is content that was already in the training set. If your site was crawlable and well-linked when the model was trained, you are in there. If you launched after the training cutoff, or if you were blocked by robots.txt during training, live retrieval is your only way in, and it only fires 14.4% of the time.

Three things follow from this:

1. Being crawlable during training matters more than being crawlable now. If GPTBot crawled your site before the training cutoff, your content is in the model's parametric memory. No live search needed. If it did not, you are fighting for a spot in the 14.4%.

2. Primary-source content wins over summaries. ChatGPT's fan-outs increasingly look for "official," "price," and specific brand domains. If your page is the primary source for something (official documentation, pricing, specs), it is more likely to be retrieved than a blog post summarizing someone else's data.

3. Multi-platform strategy is not optional. ChatGPT and Perplexity cite different sources, at different rates, from different retrieval mechanisms. ChatGPT leans on training data and brand sites. Perplexity leans on live web and Reddit. Google AI Overviews lean on YouTube and their own index. A strategy that works on one engine may be invisible on another.

The limitation

The Ahrefs data covers free, logged-out ChatGPT. Logged-in users on paid plans may trigger more web searches, since OpenAI can afford more API calls per response for paying users. The 14.4% figure is a floor, not a ceiling, for how often ChatGPT searches. But the free tier is where most users are, so it is the number that matters for visibility.

What to check

If you want to know whether your site is reachable by AI crawlers, run a free audit on geoready.dev. It checks 27 AI crawlers, robots.txt access, and whether your content is in the HTML or hidden behind JavaScript. The same engine is available as a CLI on GitHub, open source, MIT licensed.

An audit tells you if AI crawlers can read your page. It does not tell you if you are in the training data. Nothing can tell you that, except asking the model itself.

I broke my own tool's scoring model and rebuilt it. Here's what changed in rubric v2

Juan Camilo Auriti — Tue, 27 Oct 2026 14:00:00 +0000

When I published the calibration study showing the GEO score does not predict citations, one question came up immediately: if the score does not predict citations, why did you just rebuild it?

The answer is that the score was never meant to predict citations. It measures citability, whether an AI crawler can reach, parse, and understand a page. The rebuild makes it better at that, and more honest about what it does not measure. Here is what changed.

The old rubric (v1)

The original rubric had 9 categories adding up to 100 points:

robots.txt and AI crawler access (10 pts)
llms.txt presence and validity (18 pts)
schema markup and structured data (10 pts)
metadata and Open Graph (8 pts)
content structure and readability (15 pts)
citation signals (quotable passages, statistics, quotes) (12 pts)
brand entity clarity (8 pts)
AI discovery signals (6 pts)
negative penalty for blocking, JS-only content, injection surfaces (13 pts deduction)

The problem was the weights. llms.txt carried 18 points, almost a fifth of the total. But Google's own guide, published in May 2026, says llms.txt does nothing for AI Overviews. The Babel42 study confirmed it: only 0.2% of sites have a valid llms.txt file, and AI Overviews cite those sites at the same rate as everyone else. The signal was over-weighted relative to its actual importance.

What changed in v2

Rubric v2 shipped in v4.19.0 (October 2026). Three structural changes:

1. llms.txt dropped from 18 to 6 points. The file is still checked. Some AI crawlers do read it, and 0.2% of sites use it. But it is not a top-3 signal for citability. Six points reflects that: present and valid gets you something, missing does not tank your score.

2. AI discovery dropped from 6 to 3 points. This category checked things like RSS feeds and sitemap references to AI-specific content. Useful but minor. Three points is honest.

3. New category: Google AI readiness (20 points). This is the biggest addition. It checks 8 signals specific to how Google's AI Overviews select and display sources:

G-INDEX: is the page indexed and canonicalized correctly
G-SNIPPET: does the page have a meta description and structured snippets
G-CANONICAL: is there a canonical URL and does it match
G-DATES: are there published and updated dates
G-BYLINE: is there a named author
G-LINKS: are internal links present and crawlable
G-VIEWPORT: is the viewport meta tag set (mobile readiness)
G-SITEMAP: is the page in a sitemap

These are the signals the WashU study (October 2026, 55,393 queries) found correlate with AI Overview citation: credible sources with clear authorship, dates, and canonical URLs. The category does not guarantee citation. It checks whether the technical prerequisites are in place.

The full v2 category list

Category	v1 points	v2 points	Change
robots.txt access	10	10	unchanged
llms.txt	18	6	-12
schema markup	10	10	unchanged
metadata	8	8	unchanged
content structure	15	15	unchanged
citation signals	12	12	unchanged
brand entity	8	8	unchanged
AI discovery	6	3	-3
Google AI readiness	0	20	new
negative penalty	-13	-13	unchanged

Total: still 100 points. The 15 points removed from llms.txt and AI discovery went into the new Google AI readiness category.

You can still use v1

If you have historical data on v1 scores, you do not need to re-audit everything. The CLI supports --score-version 1 for legacy comparisons. Drift and diff comparisons are gated to the same score version, so you cannot accidentally compare a v1 score with a v2 score and get a meaningless delta.

What the calibration study changed

The calibration study did not directly inform v2. The rubric was already designed and shipped in v4.19.0 (October 9). The study ran on October 17. But the study confirms the design philosophy: the score measures citability, not citation. The 9 categories check whether a page is reachable and parseable. They do not claim to predict whether it will be cited.

The null result is actually useful for the rubric. It means I should not inflate the score's claims. A 90/100 does not mean "you will be cited by ChatGPT." It means "your page is technically reachable and parseable by AI crawlers." That is a narrower, more honest claim.

What is next

The rubric will keep evolving. The Google AI readiness category is new and its 20-point weight is a starting estimate, not a final answer. As more calibration data comes in (I plan to run the study again with ChatGPT and Google AI Overviews, not just Perplexity), the weights may shift again.

If you want to see the full scoring rubric, it is in SCORING_RUBRIC.md on GitHub. The tool is free and open source. You can also run a free web audit on geoready.dev without installing anything.

I built a tool that checks whether AI cites your site. It had never cited mine

Juan Camilo Auriti — Tue, 27 Oct 2026 09:20:37 +0000

I maintain GEO Optimizer, an open-source CLI that audits whether ChatGPT, Perplexity, Claude and Google AI Overviews can crawl, understand and cite a website. The hosted version runs at geoready.dev.

I pointed it at itself, the way a customer would: ask the engines the questions a buyer asks, and count who gets cited.

The measurement

108 calls to Claude with web search on, across Haiku and Sonnet, three runs per prompt. Prompts like "best GEO optimization tool" and "What are the best GEO and AI visibility optimization tools?". The same prompts had already gone through Perplexity.

geoready.dev: 0 citations, 0 mentions. On both engines.

Otterly, Peec and Profound came up again and again. Fair enough, they're good products. But zero for a tool whose whole job is this number deserved a postmortem.

What it wasn't

The site itself passed. robots.txt allows every Anthropic, OpenAI and Perplexity crawler. llms.txt and llms-full.txt both return 200. The JSON-LD declares a Brand with alternateName and sameAs pointing to the GitHub repo and PyPI.

None of it mattered, because the engines never got to the site.

What it was

1. Retrieval. In 108 answers, geoready.dev never appeared among the search results Claude read, let alone the ones it cited. On Google it sits around positions 25–50 for "geo tools". The engines read roughly the first page. A page that isn't in the retrieved set can't be cited, however good its schema is.

2. The answer is someone else's listicle. The citations went to third-party "best GEO tools" articles. In my own tally of the 18 most cited pages, Otterly appears in 14 and my tool in none.

3. The awesome lists. On 26 October 2026 I checked eight GitHub lists on GEO, llms.txt and AI SEO. Otterly is in three of them. My repo, at 1.1k stars, is in none. I had submitted it to two of them and left it there: one pull request has been open since March, the other since last week, neither merged.

4. The name is taken, four times. At least four other GEO products are called GeoReady, on four other domains. Even when an engine saw "GeoReady", it had no way to know which one.

5. The two halves of the brand never met. This one surprised me most. "GEO Optimizer" was being named, in 10 answers out of 108, and the repo was cited 4 times. But the repo description, the PyPI summary and the README never said "GeoReady". And in this series I kept writing "the CLI I maintain" without naming it: one link to geoready.dev, in one post. The engines met two unrelated entities and credited neither.

6. Bing. I had never set up Bing Webmaster Tools for the site. Copilot retrieves from Bing, and so do other AI search products, so a site Bing doesn't index is missing from their results.

The fixes

In the order I'm doing them:

The repo description now says "GEO Optimizer, the open-source engine behind GeoReady (geoready.dev)". The README says it too, since the change was merged on 26 October. The PyPI summary changed with release 4.19.8, published the same day. This post exists partly for the same reason.
Pull requests to five awesome lists (GEO, llms.txt and AI SEO), one line each, in each list's own format. Two were already open, three are new. None is merged yet.
Outreach to the editorial listicles that the engines actually cite. On 27 October I sent three short suggestions to the authors of "best GEO tools" guides. No replies yet. I'm skipping the competitors' own listicles: they're not going to list me, and that's fine.
Never writing "GeoReady" on its own outside the site. Always "GeoReady (geoready.dev)", or next to the repo.
Bing Webmaster Tools: the site is verified and the sitemap has been submitted. IndexNow is still to do.

The lesson

On-site GEO is the floor. Everything I audit for (crawler access, schema, llms.txt, passage structure) decides whether you can be cited once you're retrieved. Whether you get retrieved is decided mostly by other people's pages: listicles, lists, forums, posts that name you next to the category.

The audit I'd run on a client now starts with one question: which pages do the engines read for your category, and are you on them?

I'll rerun the same 108 calls in a few weeks and post the numbers, zero or not.

GEO Optimizer is MIT-licensed: github.com/Auriti-Labs/geo-optimizer-skill. The hosted version, GeoReady (geoready.dev), is at geoready.dev.

Method note: the 108 calls, the 10 mentions of GEO Optimizer, the 4 repo citations, the 18-page tally and the Google positions are my own measurements, written up on 26 October 2026. The count of eight lists was re-checked on that date.

My calibration study found the GEO score doesn't predict AI citations. Here's the data

Juan Camilo Auriti — Tue, 27 Oct 2026 08:00:00 +0000

I built a tool that scores websites 0 to 100 on how visible they are to AI answer engines. Then I ran a study to check whether the score predicts anything real. It does not.

The result: an odds ratio of 0.9625 with a p-value of 0.7172. No significant relationship between the GEO score and whether Perplexity cites a page. I pre-registered the analysis plan before running it, and I am publishing the data anyway.

What I tested

I took 341 pages from sites that publish a sitemap, ran a GEO audit on each one (rubric v2, GEO Optimizer 4.19.3), and then asked Perplexity Sonar two questions built from each page's own headline:

Template A: "What are the most reliable sources on: [headline]"
Template B: "Explain this topic and cite your sources: [headline]"

I recorded whether the page's domain appeared among the sources Perplexity returned. Then I ran a logistic regression of citation on score, controlling for site popularity (Tranco rank) and page length (word count).

The base rate was 42.23% for domain citation on template A and 44.57% on template B. So Perplexity cited the domain behind a page about 42% of the time when asked about that page's own topic. That is the baseline the score had to beat.

The result

The primary analysis was logistic regression of domain citation (template A) on score divided by 10, log rank, and log words.

Odds ratio per 10 score points: 0.9625 (95% CI 0.7827 to 1.1836)
p-value: 0.7172
n: 341

The odds ratio is below 1.0, meaning higher scores were slightly less likely to be cited, but the confidence interval crosses 1.0 comfortably. The effect is indistinguishable from noise.

The descriptive statistic tells the same story. The mean score of cited pages was 65.5. The mean score of not-cited pages was 65.5. Identical to one decimal place.

I tested every category too

The audit has 9 scoring categories: robots.txt access, llms.txt, schema markup, metadata, content structure, citation signals, brand entity, AI discovery, and Google AI readiness. I ran each one individually against citation, with the same controls and a Holm correction for multiple testing.

None of them were significant. Every single Holm-corrected p-value was 1.0000. The closest was the Google AI readiness category (p = 0.1220 before correction, OR = 0.8345), which trends in the wrong direction.

The sensitivity check

About 26% of the pages in the sample were on sites that block at least one AI bot in robots.txt. I re-ran the primary analysis excluding those pages, leaving 253.

Odds ratio per 10 score points: 1.0408 (95% CI 0.8302 to 1.3048)
p-value: 0.7288

Still nothing. The odds ratio flipped above 1.0 but the confidence interval is wide and the p-value is unchanged.

What this means

The GEO score measures whether a page is reachable, parseable, and quotable by an AI crawler. It checks robots.txt access, structured data, content structure, metadata, and AI-specific signals like llms.txt. It does a good job of that. The score correctly identifies pages that AI crawlers can read.

But being readable is not the same as being cited. Perplexity's source selection depends on factors the audit does not measure: domain authority, topical authority, third-party mentions, and whatever Perplexity's ranking model does internally. A page with a perfect GEO score and no external authority will not be cited. A page with a terrible GEO score but massive domain authority might be cited anyway, if the crawler can get past the robots.txt.

This is the gap between citability and citation. The first is a prerequisite. The second is an outcome that depends on more than the page itself.

Why I published a null result

I could have not run this study. I could have run it and not published it. Most AI visibility tools have never published a calibration study, and I suspect some of them would not survive one.

I published it because the alternative is worse. If I sell a score and do not test whether it predicts anything, I am doing the same thing as the agencies selling GEO tactics that the data does not support. The whole point of building this tool was to move past "trust me" and toward "check the data." That has to apply to the tool itself.

The pre-registration is at github.com/Auriti-Labs/geo-optimizer-skill/tree/main/research/calibration-2026-10. Its SHA-256 is 441fcbb422964fdf2bf2b63eb02181ccbea9e7c5590d3e770399d567cd373ff8. The results CSV has 341 rows with no domain, address, or headline. You can reproduce the primary result from the published data.

What I am doing about it

The score still measures something useful: whether AI crawlers can reach and understand your page. That is a necessary condition for being cited. It is not a sufficient one.

The problem is that a one-shot audit tells you where you are today. It does not tell you whether you are cited, and it does not tell you whether that changes. Perplexity cited the same domain about 42% of the time in this study, but other research (the Babel42 AI Overviews study, October 2026) found that only 11% of Google AI Overviews cited the same sites two days in a row. Citation is volatile. An audit is a snapshot.

That is why I am building the monitoring layer. The audit tells you if your page is readable. The monitor tells you if it is being cited, and whether that changed since yesterday. The first is a checkbox. The second is the metric that matters.

If you want to run the audit on your own site, it is free and open source at github.com/Auriti-Labs/geo-optimizer-skill. You can also paste a URL into the free web audit on geoready.dev without installing anything. Same engine, no signup.

My VS Code setup went from 47 extensions to 6. My productivity went up.

Juan Camilo Auriti — Mon, 26 Oct 2026 08:00:00 +0000

I counted my VS Code extensions. There were 47. My editor took 8 seconds to start, lagged when I typed, and crashed once a week. I disabled 41 of them and kept 6. Here is what happened.

The problem

Extension creep is gradual. You install a formatter, then a linter, then a theme, then a snippet pack, then a language support extension for a framework you tried once and never used again. Each one seems small. Each one adds startup time, memory usage, and editor complexity.

My 47 extensions included:

5 formatters (Prettier, ESLint, Stylelint, Beautify, Rustfmt)
4 language packs (Python, Go, Rust, Java, only Python was active)
3 themes (one in use, two installed "to try later")
6 snippet packs (React, Vue, Python, Docker, Git, and a generic HTML one)
4 Git extensions (GitLens, Git Graph, GitHub Pull Requests, Git History)
3 AI extensions (GitHub Copilot, Codeium, Tabnine, all disabled in favor of Cursor)
22 others (Docker, YAML, TOML, markdown preview, CSV viewer, path intellisense, import cost, indent rainbow, bracket pair colorizer, and more)

Most of these I had installed once and forgotten about. They were running on every startup, consuming memory, registering commands, and contributing to the status bar.

What I kept

I went through each extension and asked: "Have I used this in the last week?" If the answer was no, I disabled it. Here is what survived:

1. Prettier. Code formatting. I use it on every file. Non-negotiable.

2. ESLint. Linting. Same as Prettier, I use it constantly. The two work together.

3. GitLens. I use the blame and diff features daily. The rest of GitLens (code lens, file history, commit search) I could live without, but the blame view alone justifies the extension.

4. Astro. Language support for Astro, which is my primary framework. Without it, .astro files are unstyled HTML.

5. Tailwind CSS IntelliSense. Autocomplete for Tailwind classes. I write Tailwind every day. Without this, I am guessing at class names.

6. Error Lens. Shows errors and warnings inline instead of requiring a hover. It is a small UX improvement that saves me hundreds of micro-interactions per day.

That is it. Six extensions.

What happened

Startup time: 8 seconds to 1.5 seconds. The difference is immediately noticeable. I open and close the editor many times a day, and the 6.5 second saving compounds.

Memory usage: 1.2 GB to 380 MB. VS Code went from being the heaviest application on my machine to being lighter than my browser. The lag when typing in large files disappeared.

Crashes: once a week to zero in six weeks. I cannot prove causation, but the correlation is strong. Extension conflicts are a known cause of VS Code instability, and removing 41 of them eliminated a lot of potential conflicts.

Productivity: up, measurably. I was spending time managing extensions: updating them, configuring them, disabling ones that conflicted, and debugging issues caused by interaction between them. That time is gone. The editor does what I need and gets out of the way.

What I learned about extension creep

Extensions are not free. Each one adds to startup time, memory footprint, and editor complexity. The cost is invisible until you remove them and feel the difference.

You do not use most of your extensions. 41 out of 47 had not been used in the last week. Some had not been used in months. They were running anyway.

The best extensions are the ones you forget you have. Prettier, ESLint, Error Lens: these work silently. They do not have popups, side panels, or status bar clutter. They do their job and disappear.

AI extensions are redundant when you use an AI editor. I was running Copilot, Codeium, and Tabnine inside VS Code while also using Cursor (which has its own AI). The AI extensions were disabled but still loaded. Removing them freed memory and removed a source of confusion about which AI was active.

The 2026 editor landscape

The choice in 2026 is not "which extensions should I install." It is "which editor should I use." The landscape:

VS Code remains the default. The extension ecosystem is the largest. With a minimal setup, it is fast and reliable.
Cursor is VS Code with AI built in. If you are paying for an AI assistant, Cursor replaces the need for AI extensions.
Zed is the performance option. Rust-native, fast startup, built-in collaboration. Smaller extension ecosystem.
JetBrains (WebStorm, IntelliJ) is the heavy option. Built-in tooling for everything, but higher memory footprint and per-seat licensing.

My current setup is Cursor (which is VS Code under the hood) with the same 6 extensions. The AI features are built into the editor, so I do not need AI extensions. The 6 extensions I kept are the ones that do work the AI cannot do: format my code, lint it, show Astro syntax, autocomplete Tailwind classes, and display errors inline.

If you want to try this

Open your extensions tab. Sort by "installed."
For each extension, ask: "Have I used this in the last week?"
Disable everything where the answer is no. Do not uninstall yet, just disable.
Work for a week. If you need an extension you disabled, re-enable it.
After a week, uninstall everything that is still disabled.
Measure your startup time before and after. The difference is your motivation to keep it lean.

The temptation to install will return. Every blog post about "10 VS Code extensions you must have" will add to your list. The discipline is not "never install." It is "install, try, and remove if you do not use it within a week."

I replaced npm with pnpm in a monorepo with 14 packages. Here's what actually broke.

Juan Camilo Auriti — Sun, 25 Oct 2026 08:00:00 +0000

I moved a Turborepo monorepo with 14 packages from npm to pnpm. The migration took a day and a half. Three things broke. Two things improved more than I expected. Here is what happened.

The monorepo

The project is a calculator hub built with Astro 5, React, shadcn/ui, and Tailwind CSS 4. The monorepo has 14 packages:

2 apps (the main site and a documentation site)
4 shared UI packages (components, theme, icons, utils)
3 tooling packages (eslint config, tsconfig, tailwind config)
5 feature packages (individual calculator modules)

Total dependencies: 847 unique packages across all workspaces. With npm, the node_modules directory was 2.3 GB. Install time on a clean cache: 4 minutes 12 seconds.

What broke

1. Hoisting differences broke two packages.

npm hoists all dependencies to the root node_modules by default. pnpm uses a symlinked structure where each package gets its own node_modules with symlinks to a shared store. This means packages can only access dependencies they explicitly declare in their package.json.

Two of my feature packages were importing a utility (clsx) that was not in their package.json. It worked under npm because clsx was hoisted to the root and accessible from anywhere. Under pnpm, the import failed with "Cannot find module 'clsx'".

The fix was to add clsx to the dependencies of both packages. This is the correct behavior: packages should declare what they import. But if you have been relying on npm's hoisting, pnpm will surface every undeclared dependency in your monorepo.

2. The Turborepo cache needed a reset.

After switching package managers, the Turborepo build cache was stale. Builds were passing but using cached outputs from the npm era, which meant the cache hits were masking potential failures. I had to clear the cache with turbo clean and run a full rebuild to get accurate results.

This is not a pnpm bug. It is a consequence of changing anything that affects the build inputs. But it is easy to miss if you assume the cache is still valid after the migration.

3. One postinstall script failed.

A package had a postinstall script that referenced ../../node_modules/.bin/something. Under npm, this path existed because of hoisting. Under pnpm, the binary is in the package's own node_modules/.bin, not the root. The script failed.

The fix was to use npx something or pnpm exec something instead of hardcoding the path. This is a best practice anyway, but legacy scripts that worked under npm's hoisting model needed updating.

What improved

1. Disk usage dropped from 2.3 GB to 410 MB.

pnpm's content-addressable store deduplicates packages across all workspaces. A package that appears in 10 workspaces is stored once on disk and symlinked. The 2.3 GB node_modules became 410 MB. On a CI runner with limited disk space, this alone justified the migration.

2. Install time dropped from 4:12 to 1:38.

On a clean cache, pnpm install took 1 minute 38 seconds versus npm's 4 minutes 12 seconds. On a warm cache (with the store already populated), pnpm install took 22 seconds. The speedup comes from the hard-linking strategy: packages that are already in the global store are linked, not downloaded.

In CI, where each run starts with a clean checkout but the pnpm store can be cached, the warm-cache install time is what matters. Caching ~/.local/share/pnpm/store in GitHub Actions reduced install time from 1:38 to 28 seconds.

3. pnpm why is better than npm ls.

Tracing why a dependency is installed is clearer with pnpm. pnpm why clsx shows the full dependency chain from root to the package that depends on it. npm ls clsx gives a tree that is harder to read in a monorepo with 14 packages.

The migration steps

If you are doing the same migration, here is what worked:

# 1. Delete npm artifacts
rm -rf node_modules **/node_modules package-lock.json **/package-lock.json

# 2. Enable pnpm
corepack enable
corepack prepare pnpm@latest --activate

# 3. Install
pnpm install

# 4. Fix undeclared dependencies (pnpm will tell you which imports fail)
# 5. Clear Turborepo cache
npx turbo clean

# 6. Full rebuild
pnpm run build

Step 4 is where most of the time goes. pnpm will fail on every undeclared import. Each failure is a package you need to add to a package.json that should have declared it in the first place.

What I would do differently

Run pnpm install --shamefully-hoist first to get a baseline. The --shamefully-hoist flag mimics npm's hoisting behavior, so the install will succeed without fixing undeclared dependencies. This gives you a working baseline. Then remove the flag and fix the failures one by one, testing after each fix.

Check postinstall scripts before migrating. Any script that references ../../node_modules paths will break. Find them with grep -r "node_modules" --include="*.js" packages/ and fix them before switching.

Cache the pnpm store in CI from day one. The install time difference between cached and uncached is 28 seconds vs 1:38. Over a week of CI runs, that is hours saved.

Is it worth it?

For a monorepo with 14 packages, yes. The disk space and install time improvements are immediate and significant. The migration cost is a day and a half of fixing undeclared dependencies, which is work that should have been done anyway.

For a single-package project, the benefit is smaller. The install time and disk improvements are proportional to the number of packages and the amount of dependency overlap. A single app with no shared dependencies will see a smaller speedup.

The undeclared dependency issue is the main friction. If your monorepo has been relying on npm's hoisting for years, pnpm will surface every place where a package imports something it does not declare. That is painful in the short term and correct in the long term.

git bundle without HEAD: the recovery commands I wish I'd known

Juan Camilo Auriti — Sat, 24 Oct 2026 07:00:00 +0000

A few weeks ago I wrote about a git bundle problem: git bundle verify reported "complete history," git clone exited 0, and the working tree was empty. The root cause was a missing HEAD ref in the bundle. The fix was to create the bundle with --all HEAD.

A commenter named SystemCraftDev added the recovery side: what to do if you already have a bundle without HEAD and cannot re-create it. Their commands work, and they deserve to be in the same place as the original post. Here is the complete guide.

The problem, in one paragraph

git bundle create transfer.bundle main creates a bundle with one ref (refs/heads/main) but no HEAD. When you clone from it, git tries to resolve HEAD, finds it pointing at a branch that does not exist (usually master), and checks out nothing. The clone succeeds with exit code 0. The working tree is empty. The objects are all there. There is simply no branch and no checkout.

Prevention: create the bundle with HEAD

git bundle create transfer.bundle --all HEAD

--all takes every ref. HEAD adds the one that makes it clonable. That bundle lists multiple heads including HEAD, and the clone checks out a working tree with a branch on it.

For a single branch:

git bundle create transfer.bundle main HEAD

Recovery: you already have a bundle without HEAD

If you cannot re-create the bundle, you can work around the missing HEAD by naming the branch explicitly during clone:

git clone -b main transfer.bundle restored

The -b main flag tells git which branch to check out, bypassing the HEAD resolution entirely. Git creates the local branch from the bundle's refs/heads/main and checks out the files.

This works because the objects and the ref are in the bundle. The only thing missing is HEAD, and -b lets you specify the branch directly instead of relying on HEAD to point to it.

Recovery: you already cloned and got an empty tree

If you already ran git clone transfer.bundle restored and ended up with an empty working tree, the objects are still there. You can recover in place:

git switch main

Git creates the local branch from the remote-tracking ref (origin/main) and checks out the files. No need to re-clone.

If you are not sure what branches are available in the broken clone:

git branch -r

This lists the remote-tracking refs. You will see origin/main (or whatever branch was in the bundle). Switch to it with git switch main or git switch -c main origin/main.

How to read the empty-clone symptom

The symptom that confused me was:

$ git -C restored symbolic-ref HEAD
refs/heads/master

HEAD points at refs/heads/master, which does not exist, because the bundle carried main. Git has nothing to check out. The warning on stderr (remote HEAD refers to nonexistent ref) is the only signal that something is wrong. Under set -e, the exit code 0 means nothing stops.

The HEAD ref in a bundle tells git which branch to check out after clone. Without it, git falls back to its default (usually master), and if the bundle does not contain master, you get an empty tree with no branch.

The complete decision tree

Situation	Command
Creating a bundle	`git bundle create transfer.bundle --all HEAD`
Cloning from a bundle with HEAD	`git clone transfer.bundle restored`
Cloning from a bundle without HEAD	`git clone -b main transfer.bundle restored`
Already cloned, empty tree, want to recover	`git switch main`
Not sure which branch is in the clone	`git branch -r`

Why this matters in automated workflows

The original problem surfaced in a transfer script. The script ran git bundle verify (exit 0, "complete history"), then git clone (exit 0), then checked for files (none). Under set -e, nothing stopped. The only evidence was a warning on stderr, which the script logged to stdout and never surfaced.

If you are writing a transfer script, check for the working tree, not the exit code:

git clone transfer.bundle restored
if [ -z "$(ls -A restored)" ]; then
  echo "Clone succeeded but working tree is empty"
  echo "Attempting recovery with explicit branch..."
  git -C restored switch main 2>/dev/null || git -C restored switch -c main origin/main
fi

This catches the empty-tree case and attempts recovery in place. It is not elegant, but it handles the one failure mode that exit codes cannot detect.

Thanks to the commenter

SystemCraftDev's comment on the original post added the recovery commands that I had not covered. The original post was about prevention (how to create the bundle correctly). The recovery side is equally important, especially for bundles you receive from someone else and cannot re-create. This article puts both sides in one place.