How This Site Implements AEO and GEO: A Technical Breakdown
Why this post exists
Every post in this cluster has argued that original, first-hand, checkable content outperforms generic explanation — the most direct way to practice that principle is to describe this exact site's own AEO/GEO implementation specifically, in enough technical detail that any reader can independently verify each claim by viewing the actual page source, the actual JSON-LD, or the actual files referenced.
The entity foundation
This site defines a stable Person entity (Sapun Lamichhane) and Organization entity (Arcetis), each with a consistent @id used identically across every page that references them, and sameAs links to verified external profiles. The full, dedicated entity graph is browsable directly at /entity, listing every defined entity and its relationships explicitly rather than leaving them implicit.
The structured data layer
Every page on this site emits a single linked JSON-LD @graph — not disconnected schema blocks — built by a shared buildGraph function so every page consistently includes Organization, Person, WebPage, and BreadcrumbList nodes, with FAQPage, HowTo, Article, Service, or ProfilePage nodes layered in depending on the page's actual content type. This is the exact pattern described generally in the companion post on structured data for AI search, implemented directly rather than just recommended.
The AI-crawler access layer
This site publishes an llms.txt and a more exhaustive llms-full.txt at the domain root, following the convention described in the companion post on llms.txt, formatted with real Markdown link syntax rather than bare URLs. robots.txt explicitly allows the major AI crawlers by name. An OpenAPI specification and a set of genuinely read-only, live API endpoints (documented at /docs) give any AI system or agent framework a structured, machine-readable way to query this site's facts directly, rather than only through page scraping.
The content architecture
This blog itself follows the pillar-cluster model described in the companion post on that topic — the /authority page is the pillar, and each blog post, including this AEO/GEO cluster, is cluster content going deep on one specific sub-topic, cross-linked back to the pillar and to related cluster posts. The frameworks, glossary, and entity pages elsewhere on this site follow the same knowledge-graph logic described in the companion post on building a knowledge graph for entity SEO.
What this site deliberately does not do
- No fabricated testimonials, statistics, certifications, or case study numbers — every claim of credential or achievement on this site is limited to what's independently checkable.
- No deprecated or redundant markup — a single JSON-LD @graph per page, not JSON-LD mixed with Microdata or RDFa.
- No superlative claims ("#1," "the best") anywhere on the site, including in this exact content cluster arguing for AEO and GEO adoption.
- No simulated or fake API endpoints — every endpoint documented at /docs genuinely returns live, real data when called.
The honest limitation, stated the same way it is elsewhere in this cluster
This implementation doesn't guarantee citation in any specific AI platform's output — as covered throughout this cluster, no legitimate technique does. What it demonstrates is a complete, working, independently verifiable example of the technical and content practices this cluster recommends, which a reader is free to inspect directly rather than take on faith — which is, in the end, the entire point of building content this way in the first place.
Frequently asked questions
Why publish your own technical implementation?
Because every post in this cluster argues that original, first-hand, checkable content outperforms generic explanation, and the most direct way to practice that is to describe this site's own implementation in enough technical detail that any reader can verify each claim independently — by viewing the actual page source, the actual structured data, or the actual files being referenced. A checkable example is worth more than a confident description.
How is the structured data on this site built?
Every page emits a single linked JSON-LD graph rather than disconnected blocks, built by a shared function so each page consistently includes Organization, Person, WebPage, and BreadcrumbList nodes, with FAQPage, HowTo, Article, Service, or ProfilePage layered in depending on the page's actual content type. It is the linked-graph pattern this cluster recommends, implemented directly rather than merely described. One graph per page, consistently, on every single page.
What does this site do for AI crawler access?
It publishes an llms.txt and a more exhaustive llms-full.txt at the domain root, formatted with real Markdown link syntax rather than bare URLs, and robots.txt explicitly allows the major AI crawlers by name. An OpenAPI specification and a set of read-only, live API endpoints give any AI system or agent framework a structured way to query this site's facts directly.
What does this site deliberately refuse to do?
No fabricated testimonials, statistics, certifications, or case study numbers — every credential claim is limited to what is independently checkable. No deprecated or redundant markup, meaning a single JSON-LD graph per page rather than mixed formats. No superlative claims anywhere on the site, including in this cluster. And no simulated endpoints; every documented one returns live, real data. Each of those refusals is verifiable by inspection.
Does this implementation guarantee AI citation?
No, and no legitimate technique does. The models are proprietary and their selection logic is not published anywhere. What this implementation demonstrates is a complete, working, independently verifiable example of the technical and content practices this cluster recommends, which a reader is free to inspect directly rather than take on faith. That inspectability is the entire point of it. Probability can be improved; certainty cannot be sold.
How is the blog itself structured?
As a pillar-cluster model, with an authority page serving as the pillar and each blog post going deep on one specific sub-topic, cross-linked back to the pillar and to related posts within the same cluster. The frameworks, glossary, and entity pages elsewhere on the site follow the same knowledge-graph logic, with entities defined once and then referenced consistently everywhere. The architecture is the argument, not a decoration on top of it.
Book a free 10-minute consultation
Sapun Lamichhane is a business growth analyst and founder of Arcetis, based in Pokhara, Nepal. If you want a second opinion on your account, your funnel, or whether a channel is worth your budget at all, book a free 10-minute call — no pitch, and a straight answer even when the answer is that you do not need help.
Direct: +977 9846162626 · lamichhanesapun2@gmail.com
This post supports the frameworks documented in full on the Authority page.