$ man geo/shawnos-geo-case-study

ShawnOS.ai runs on a monorepo architecture with three Next.js sites sharing a common content layer. The main site hosts the wikis, blog, and landing pages. Two additional sites handle specialized content verticals. All three sites pull from the same TypeScript data layer in a shared packages directory. This architecture matters for GEO because it creates a unified content graph across multiple domains while sharing entity signals. Every wiki entry, every blog post, and every landing page is defined as a typed object in a TypeScript file. The rendering layer reads from these typed arrays, and all GEO signals - schema markup, RSS feeds, llms.txt, sitemaps - are generated from the same source data at build time. When a new wiki entry is added, it automatically appears in the RSS feed, the sitemap, the llms.txt file, and the schema markup without any manual steps.

PATTERN

The core GEO driver is the wiki system. Each wiki - Clay, Content, GEO, How-To - covers a specific topic cluster with 15 to 30 entries. Each entry has multiple sections, and each section is structured as an answer block with a clear heading and front-loaded content. This creates hundreds of individually citable content blocks across a relatively small number of pages. The wiki entries are cross-referenced through related arrays, creating a navigable knowledge graph. When an AI engine lands on one wiki entry, the related links let it discover connected concepts. The section type system - prose, pattern, code, anti-pattern, pro-tip, formula - means different types of content are clearly distinguished, which helps AI engines understand what kind of information each section provides. The result is a content surface area that is disproportionately large relative to the number of pages because each page contains multiple extractable, citable sections.

CODE

The site implements the full stack of technical GEO signals. Each page has Article schema generated from the wiki entry data - headline, description, author as a Person entity, dateModified set to the build timestamp, and publisher as an Organization entity. The llms.txt file at the site root provides AI assistants with a structured overview of the site, listing every wiki, its purpose, and links to key entries. The RSS feed at /feed.xml includes every blog post and wiki update with full content bodies, not excerpts. The robots.txt allows all major AI crawlers - PerplexityBot, ChatGPT-User, ClaudeBot, and Googlebot - full access. The sitemap includes every wiki entry and blog post with lastmod dates that update on every build. Internal links between related wiki entries and between wikis and blog posts create a dense link graph that reinforces topical associations.

PRO TIP

The key lessons from building this system. First, TypeScript-defined content eliminates an entire class of GEO bugs - missing schema fields, broken cross-references, forgotten sitemap entries. The compiler catches mistakes before they deploy. Second, the wiki format produces more citation surface area per page than traditional blog posts because each section is an independent answer block. Third, cross-referencing between wikis and between wikis and blog posts creates the topical depth signals that AI engines use to evaluate authority. Fourth, build-time generation of all GEO signals from a single data source means every deployment is GEO-consistent - there is no drift between your content and your technical signals. Fifth, the monorepo architecture lets multiple sites share entity signals and content while maintaining distinct domains and purposes. The biggest mistake early on was treating blog posts and wiki entries as separate content systems. Unifying them under the same TypeScript data layer and cross-referencing between them dramatically improved both traditional SEO and AI citation rates.