Innotek's Open Source Strategy: How We're Democratising GEO Tooling

This article explains what we built, why we built it in public, and what it means for the broader GEO ecosystem.

Why Innotek Chose Open Source

The GEO optimisation industry has a credibility problem. Platforms claim to improve AI discoverability, but the methods are opaque, the results are hard to verify, and the tooling is locked behind paywalls. When a platform like Innotek tells you to add structured data, generate an llms.txt file, and increase your fact density, you should be able to inspect exactly how those recommendations are generated.

Open source solves this in three ways:

Trust signal. When our methodology is in a public repository, it can be audited, forked, and independently validated. This is the same principle behind why Schema.org itself is open — structured data gains credibility from being inspectable.

Entity clarity signal. Three named public repositories on GitHub, each linked to the legal entity "Innotek Solutions Ltd", each with contributors and commit history, each discoverable via web search — this is a meaningful cross-platform entity presence. AI models trained on GitHub data will encounter Innotek's code alongside our name, strengthening the disambiguation signal across independent domains.

Community = citations. Every fork of an open source repository is a potential citation. Every issue filed, every pull request, every blog post referencing our tools — these are independent third-party mentions. This is the same mechanism that makes Wikipedia entries, Crunchbase profiles, and G2 reviews valuable for entity clarity: they are signals from sources external to our own domain.

The 3 Stats That Drove This Decision

We were the only major GEO platform without a public code presence. Publishing 3 production-ready repositories makes us the first.

Tool 1: innotekseo-cli

GitHub: https://github.com/innotekseoai/innotekseo-cli

The CLI is the entry point for developers and technical SEO practitioners who want to work with GEO tooling from the terminal. It does two things: generates llms.txt files from directories of Markdown and MDX content, and scaffolds new Next.js article sites with auto-generated navigation from .mdx files.

Key commands:

# Generate llms.txt from a content directory
npx innotekseo scan ./content/articles --url https://yourdomain.com

# Scaffold a new article site
npx innotekseo init ./my-article-site

# List articles in an innotekseoai site
innotekseo articles list --site-dir ./path/to/innotekseoai

# Add an MDX article to the site
innotekseo articles add ./my-article.mdx --site-dir ./path/to/innotekseoai

# Dry run — preview without writing
innotekseo articles add ./my-article.mdx --site-dir ./path/to/innotekseoai --dry-run

The scan command reads frontmatter from all .md and .mdx files and generates a correctly formatted llms.txt with title, URL, and excerpt entries. The init command scaffolds a complete Next.js application — drop any .mdx file into content/articles/ and it automatically appears in the nav and article list.

Who it is for: Developers who want to add GEO tooling to existing workflows without a full platform subscription. Content teams maintaining their own static sites. Agencies building client sites who want to generate llms.txt as part of their deploy pipeline.

Key stat: A developer with no Innotek account can run a GEO audit on their content directory in under 60 seconds from the terminal using this tool.

Tool 2: innotekseo-articles

GitHub: https://github.com/innotekseoai/innotekseo-articles

The articles repository is a production-ready monorepo containing an Astro static frontend, a Strapi CMS backend, and migration scripts for importing content from existing sources. This is the full content publishing stack that powers innotekseo-articles.com.

Architecture:

innotekseo-articles/
  web/        — Astro static site (SSG, trailingSlash: 'always')
  cms/        — Strapi CMS (SQLite, quickstart mode)
  scripts/    — Migration tooling for importing existing content

The Astro frontend connects to Strapi's public REST API to fetch article content. The design system is a full port of Innotek's mk-* CSS class pack, including glassmorphism cards, dark hero sections, Google Fonts (Syne, DM Sans, DM Mono via @import), and responsive grid layouts — zero external CSS frameworks.

The 3 HTML post-processors are what make this system unusually capable for a static article site:

1. transformStatsTables — Detects Markdown tables with Value|Metric|Notes headers and converts them into stat card grids with the Innotek visual style. A data table in your CMS becomes a visually engaging fact strip in the rendered page.

2. transformNumberedLists — Detects <ol> elements where every <li> opens with <strong> text and transforms them into numbered card grids. Step-by-step instructions become visual numbered cards with 01/02/03 numbering.

3. transformFeatureCards — Detects two or more consecutive h3 + p pairs and converts them into a 3-column feature card grid. A list of features in your CMS becomes a visual feature cards section.

Key stat: The full design system is implemented in web/public/styles/global.css with zero CSS framework dependencies — no Tailwind, no Bootstrap, no utility library.

SiteHeader is built as an Astro component that fetches the top 5 articles from Strapi at build time, automatically populating the navigation. Adding a new article in the Strapi admin instantly appears in the site nav on the next build.

Who it is for: Content teams who want a production-ready, self-hosted article CMS with a quality visual design. Agencies who need a template for client article sites. Developers who want a reference implementation of Innotek's design system on a different stack.

Tool 3: innotekseo-blogs

GitHub: https://github.com/innotekseoai/innotekseo-blogs

The blogs repository is a modular Node.js library for powering blog architectures with Astro. It bridges static generation and dynamic content management through a unified adapter interface — fetch content from local .md/.mdx files or headless CMSs (Strapi, Contentful) using the same API.

Package structure:

innotekseo-blogs/
  packages/
    core/        @innotekseo-blogs/core       — Adapters, ContentService, REST API, RSS, Search
    components/  @innotekseo-blogs/components — Astro UI components for MDX
    cli/         @innotekseo-blogs/cli        — HTML-to-MDX migration tool
  apps/
    test-innotekseo/  — Working Astro demo app with LocalAdapter

The ContentAdapter interface lets you switch from local file storage to Strapi to Contentful without changing any application code. The REST API layer (built on Hono) exposes POST /api/posts for external content pushes — an external system can push content via the API, which validates frontmatter and writes .mdx files through the adapter layer. An optional webhook fires on content changes to trigger static rebuilds.

Additional capabilities:

• RSS feed generation — automatic feed from any content source
• Client-side search — indexing and search without a server
• HTML-to-MDX migration CLI — migrate legacy blog HTML to MDX format using cheerio and turndown

Who it is for: Development teams building Astro-based blog systems who need a flexible content abstraction. Teams migrating from WordPress or other CMS platforms who want MDX-compatible output. Any project that needs a REST API bridge between content management and static generation.

4 Verifiable Facts About Our Open Source Work

Why Open Source Changes GEO

Traditional SEO has no meaningful relationship with open source. Page rank is opaque. Ranking factors are proprietary. Tool methodologies are trade secrets.

GEO is different. AI models are trained on publicly available content — and that content includes GitHub repositories. When an AI model encounters a reference to innotekseo-cli in a developer's blog post, or sees our repository listed in a GitHub Awesome list, or indexes the README for innotekseo-blogs, it is building a factual association between our legal entity name ("Innotek Solutions Ltd") and a verifiable, inspectable body of work.

Transparency = entity clarity. The @graph Organisation schema on our homepage claims that Innotek Solutions Ltd is a GEO optimisation platform. GitHub repositories corroborate that claim with independent, verifiable evidence — source code, commit history, issues, and forks created by real developers.

Community = sameAs links. If a developer writes a tutorial about innotekseo-cli on their personal blog, that article contains our product name and links to our GitHub. That is a sameAs-equivalent signal in the knowledge graph. It is the same mechanism that makes G2 reviews and Crunchbase entries valuable — independent third-party references to our entity.

Forks = citations. Every fork of our repository is an independent copy that GitHub indexes. Every star is a signal that a real account with its own entity presence found our work credible. In the AI training data that underpins modern language models, GitHub stars and forks function similarly to citations in academic literature.

Comparison: Open Source vs Closed Source GEO Platforms

How to Integrate These Tools Into a GEO Workflow

A practical 5-step process for content teams:

1. Install the CLI. Run npm install -g innotekseo or use npx innotekseo without installing. This gives you access to scan, init, articles, and blog commands immediately.

2. Generate your llms.txt. Run npx innotekseo scan ./content --url https://yourdomain.com --recursive. Review the output. This is your AI-readable site directory — the file that tells crawlers what your site is about in structured prose.

3. Scaffold a content site. If you are starting a new article or blog section, run npx innotekseo init ./my-site. The scaffolded site uses the Innotek design system and auto-generates navigation from .mdx frontmatter.

4. Connect Strapi. For teams that need a content management UI, deploy the innotekseo-articles monorepo. Configure the Strapi API URL in the Astro frontend config. Your editorial team gets a full CMS; your frontend gets statically generated pages.

5. Add the blog library. For teams building on Astro, install @innotekseo-blogs/core and implement the ContentAdapter interface. Switch between local files, Strapi, and Contentful without changing application code.

Conclusion

We are the first GEO platform to open source its entire content toolchain. Three repositories, MIT-licensed, production-ready, published in a single sprint.

This is not a side project. The CLI, the article CMS, and the blog library are tools we use to publish the content you are reading right now. They are the infrastructure behind innotekseoai.com's own content pipeline — which is why they work, and why the code is worth reading.

The broader point is this: GEO optimisation is about making entities inspectable. We are applying the same principle to our own tooling. When our source code is public, our methodology is transparent, and our entity signals are distributed across GitHub, developer blogs, and open source directories, we are doing exactly what we tell our clients to do.

Build in public. Cite verifiable facts. Create inspectable entities.

All three repositories are available at https://github.com/innotekseoai. Innotek Solutions Ltd, Company No. 06775387, Hertfordshire, UK.