How We Made GEO Encyclopedia AI-Discoverable in One Week — a Site-Owner Playbook

Suppose you run a site with 47 well-written articles. You ask ChatGPT about your topic — and the assistant answers using a competitor's thinner page, with no reference to you at all.

That is the exact situation we started from. GEO Encyclopedia already had the content; it was not discoverable as an AI-ready entity.

This article is the honest version of what we changed in the following week — 18 commits, five workstreams — the crawl data behind each change, and the seven-step playbook any site owner can copy.

---

Why Did a Content-Rich Site Still Need GEO Work?

Content alone does not make a site AI-discoverable. Answer engines need to find you, understand your structure, and trust your entity before they can quote a single sentence.

Before the sprint, this site had the headline pieces in place: Article JSON-LD with dates, an llms.txt, clean URLs and a sitemap. What it lacked was the machine-readable perimeter that AI tooling and audits check first: the well-known endpoints, the AI-facing JSON summaries, and a verifiable freshness trail across all 48 pages.

We kept tripping the same signals in external GEO audits — missing discovery files, stale dates, no FAQ markup on entry pages. None of those require more essays. They are engineering tasks, which is why the whole pass took a week rather than a quarter.

The three principles we fixed first, in order: access (can a bot reach and read you?), then orientation (does it know which pages matter?), then entity (does it trust what it sees?). Everything below follows that order.

How Do You Make a Site Discoverable to AI Tools?

AI discovery is a file problem before it is a content problem. Audit tools probe a fixed set of machine-readable paths, and an empty one is a loud "not ready" signal.

We had two discovery layers in place and added a third:

Layer	Files	Why it matters
Well-known	/.well-known/ai.txt, ai.json, ai-plugin.json, openapi.json	Standard paths new AI tools probe first
Orientation	/llms.txt, /sitemap.xml, /robots.txt	Direct crawlers to the pages worth citing
AI-facing JSON	/ai/summary.json, /ai/faq.json, /ai/service.json (added this week)	Machine-readable answers about the site itself

The /ai/ endpoints were genuinely missing — request one before the sprint and you got a 404. They describe the site as data: what it covers, the questions it answers, and how to reach the editors. That is the difference between a site an audit can summarize and one that forces an audit to guess.

We also normalized llms.txt to the lowercase spec with a title, a summary blockquote, and sectioned links — the shape that manifold readers and crawler tooling expect.

Which Content & Schema Changes Move the Needle?

Schema moves the needle in an indirect but measurable way: valid structured data lets an answer engine disambiguate your brand and pull clean facts, while inconsistent naming makes you look like several fragments instead of one entity.

This week we made four small but visible moves:

• Homepage FAQ. The entry page gained a FAQPage JSON-LD block with six honest questions — a quotable answer surface where crawlers land first.
• Brand coherence. English branding was unified across titles, Open Graph tags and schema so the entity looks identical everywhere.
• Structured entry list. The homepage now carries an ItemList of the nine chapters, so a crawler can navigate the whole knowledge base in one pass.
• Fresh new community articles. Two case-driven pieces went live, proving the publishing pipeline on real pages.

Notice what we did not do: we did not rewrite 40 old articles or renumber their headings. Churn is not progress; new pages follow the better template, and old pages keep working.

How Do We Keep Dates and Freshness Honest?

Freshness is a quiet but real signal — answer engines prefer an answer that looks maintained. The trap is silent staleness: a page edited last week still advertising an old dateModified.

We ran a site-wide pass that synced three things at once:

• dateModified in every Article JSON-LD block, set to the real last-edit date.
• The matching <lastmod> in sitemap.xml.
• Kept datePublished untouched as the creation day, forever.

Then we wired the discipline into our tooling so it cannot silently lapse again: a pre-publish check now fails a build if dateModified disagrees with the file's actual last-modified date. Freshness became a checked contract, not a good intention.

What Does Crawler Observability Reveal?

You cannot manage what you do not measure. This site records every request in a database via a small worker — user agent, resolved crawler name, path, status code, and the referrer host when one exists.

One week of that telemetry changed our picture of the site:

Metric	Observed value
Total requests logged	2,335
Top AI crawlers	GPTBot 72, Googlebot 49, Applebot 46, Bingbot 38, PerplexityBot 18, ChatGPT-User 13, ClaudeBot 12
External referrers	google.com 29, chatgpt.com 1
New article on launch day	crawled 6 times by GPTBot, ClaudeBot and others
Attack noise	264 requests to paths like /wp-admin/install.php and /xmlrpc.php, all 404

Three useful findings came out of that table. First, the big crawlers already visit regularly — the intake pipeline works. Second, a freshly published article gets crawled the same day, which validates the sitemap-and-orientation work. Third, a large share of the daily traffic is scanner noise against nonexistent paths; harmless, but worth knowing so you do not confuse 404 noise with reader churn.

What Should You NOT Do When Optimizing for AI?

The fastest way to lose credibility with an answer engine is to attach fake signals. Two temptations we explicitly avoided:

• Fabricated sameAs links. Linking an Organization block to Wikipedia or Wikidata pages that do not exist points AI at nothing and poisons the entity you are building. We keep sameAs empty rather than fake it.
• Exposing private telemetry. The stats page is real and useful for us, but it is not content for AI: see the Citation Share article for what belongs in front of a crawler versus what belongs in an ops dashboard. We block it in robots, mark it noindex, and keep it out of sitemap and llms.txt.

The same discipline applies to robots rules and analytics tags: they are operating infrastructure, not SEO levers to clear for a score.

How Can You Run the Same Playbook on Your Own Site?

Seven steps, in priority order. The first two gate everything else — do them before touching schema or content:

1. Confirm access. Your AI crawlers must be allowed in robots.txt, and your pages must load without JavaScript.
2. Publish orientation files. A lowercase llms.txt with a title, a summary blockquote and sectioned links, plus a clean sitemap.
3. Expose discovery endpoints. /.well-known/ai.txt plus /ai/summary.json, /ai/faq.json and /ai/service.json with real, honest content.
4. Validate and enrich schema. At minimum Organization, WebSite and Article with dates; add FAQPage where genuine questions exist.
5. Sync freshness. Set dateModified to real edit dates, mirror them in <lastmod>, and automate the check so it cannot drift.
6. Add observability. Log crawler requests so "did they find the new page?" is a query, not a guess.
7. Re-audit and iterate. Re-run your audit after each pass; AI behavior shifts, and so does the score.

One honest caveat: access and orientation earn more than decoration. A bare site with these seven steps beats a beautiful site with none.

FAQ

Does adding an /ai/summary.json actually help with AI citations?

It helps with discovery, not citation directly. Tools like GeoReady probe machine-readable endpoints to decide whether a site is crawlable and well-oriented. An absent /ai/summary.json simply reads as "not AI-ready"; having one removes a failure signal and points crawlers at your structure.

Why is stats.html hidden from AI crawlers if discovery is the goal?

The stats page is operational telemetry full of private crawl numbers, not content an answer engine should quote. We block it in robots.txt, mark it noindex, and keep it out of sitemap.xml and llms.txt. Discovery should point AI at the pages you want cited — and protect what you do not.

Should I add sameAs links to Wikipedia or Wikidata even if my brand has no page there?

No. Faking knowledge-graph links points AI at pages that do not exist and erodes the trust you are trying to build. Add sameAs only for real assets — a real LinkedIn, a real press page, a real Wikidata item.

How do you know a specific new article was crawled?

Our worker logs every request into a database, so we can filter by path and date. On the day we published a new article, the logs show GPTBot, ClaudeBot and others hitting that exact URL — directly from real crawler traffic.

Can a small site realistically do all of this in one week?

Most of it, yes. The expensive parts are audits and structured data on existing pages. The endpoints, robots rules, llms.txt and freshness pass are file edits that take a day in total. Do the top of the checklist first — access and orientation beat decoration.

Primary Source

This playbook was also published as a discussion thread on r/GenEngineOptimization, where the same crawl numbers and step-by-step process are open for community verification and debate.