The short answer: none of them solved the actual problem my clients had. The long answer is this article.

The Problem Isn't Technology. It's the Gap Between Tech and Business Reality.

Most SMBs come to me with a WordPress site that's accumulated 40+ plugins over five years. They can't update the German version without breaking the Italian one. They have a cookie banner nobody understands, a Google Analytics setup that's questionably GDPR-compliant, and a dev dependency on an agency for every content change. Their site is slow, their data is scattered, and they have zero visibility into what's actually happening.

The developer solution to this is usually: "let's go headless." Fair. But then you hand a business owner a Contentful account and a Next.js repo, and you've replaced one problem with three.

What they actually need is:

• A single source of truth for all company data

• True multilingual support (not a plugin bolted on top)

• No cookie banner — by design, not by consent management

• AI-readable content, not just human-readable

• Self-service editing without breaking anything

• A way to be found by ChatGPT, Perplexity, and Claude — not just Google

That last one changed everything.

The Architecture Decision: Headless + Opinionated

btlabs Core is a headless platform built on TypeScript, with a structured content layer that outputs to whatever frontend the project needs. The key architectural decision was to make it opinionated in exactly the places where generic headless CMS tools are intentionally flexible.

Content as Structured Data, Not Just Text

Instead of free-form rich text everywhere, every piece of business content is modeled explicitly:

// Company identity — not just a "page"
interface CompanyIdentity {
  name: Record<Lang, string>
  tagline: Record<Lang, string>
  vision: Record<Lang, string>
  usps: Record<Lang, string[]>
  notOffered: Record<Lang, string[]> // 👈 This one matters more than you'd think
  openingHours: WeeklySchedule
  locations: Location[]
  schema: LocalBusinessType // 69 options: Dentist, Hotel, Plumber...
}

That notOffered field? It's one of the most important things I added. When an AI assistant is asked "does this company offer X?", it shouldn't guess. If "X" is explicitly listed as something the company doesn't do, the AI gets a clear signal. It sounds minor. It isn't.

Multilingual as a First-Class Citizen

South Tyrol is German, Italian, and English simultaneously. WPML and similar plugins treat multilingual as a layer on top of a monolingual system — you end up with content parity issues, broken hreflang, and editors who can't tell what's been translated and what hasn't.

In btlabs Core, language is part of every content type:

type Lang = 'de' | 'it' | 'en' | string // up to 6 languages

// Every translatable field is structured this way
type LocalizedString = Record<Lang, string>

// The admin shows translation status per field, per language
// Missing translations are surfaced — not silently filled with fallback content

Every URL slug is language-specific. hreflang is generated automatically. AI translation fills empty fields without touching existing content. The translation dashboard shows per-page completion status across all languages.

Machine-Readable by Default

This is where btlabs Core diverges most from standard CMS thinking. The content layer generates not just a website, but a full set of machine-readable outputs:

/.well-known/llms.txt        # Primary AI discovery file
/ai.txt                      # AI bot permissions
/identity.json               # Structured company identity
/brand.json                  # Brand voice + tone
/openapi.yaml                # Auto-generated API spec
/mcp                         # MCP endpoint for AI agents

The llms.txt and identity.json files give AI assistants structured access to company data — services, team, pricing, FAQ, and crucially, what the company doesn't offer. The MCP endpoint exposes a controlled interface for AI agents to list content, search, and initiate contact — with authenticated, audited access.

// MCP tools exposed per installation
const mcpTools = [
  'list_services',
  'search_content',
  'get_opening_hours',
  'get_contact_info',
  'submit_inquiry',    // controlled, not open
] as const

This isn't "add an AI chatbot." It's making the business itself queryable from any AI-native interface.

The Features That Would Be Plugins Elsewhere

One of the core design principles: nothing that matters should be a plugin dependency.

The 2024 Wordfence Annual Report found that 96% of vulnerabilities in WordPress installations were in plugins, not core. Reducing plugin surface area isn't just cleaner architecture — it's a security decision.

The Privacy Architecture

No cookie banner is a product decision, not just a compliance checkbox. The path to get there:

Analytics: Self-hosted Umami — cookieless, EU-hosted, no third-party data sharing. No consent needed for analytics in most cases (verify with your legal team — this isn't legal advice).

IP handling: Daily one-way hash. Not reversible, not stored long-term.

EXIF stripping: All uploaded images have metadata stripped automatically.

Data retention: Configurable per data type (activity logs: 90 days, form submissions: 180 days, etc.)

AI training opt-out: TDM (Text and Data Mining) opt-out per EU AI Act included in robots.txt and ai.txt.

EU hosting: Every installation runs on a dedicated server (not shared infrastructure) in the EU. The business owns the data — not us, not a US cloud provider.

# ai.txt example output
User-agent: *
Disallow: /admin/
Allow: /llms.txt
Allow: /identity.json
Allow: /brand.json

TDM-Reservation: 1

The MCP Integration

This is the part I'm most interested in long-term. The MCP (Model Context Protocol) endpoint lets AI agents interact with the CMS directly — not through scraping, but through an authenticated, schema-defined interface.

What this means practically:

# A business owner can say to Claude or ChatGPT:
"Update the opening hours for the Bozen location to add Saturday 9-13."

# The agent calls the MCP endpoint:
POST /mcp/update_opening_hours
Authorization: Bearer <mcp-key>
{
  "location": "bozen",
  "day": "saturday",
  "open": "09:00",
  "close": "13:00"
}

No admin UI required. The MCP keys have scoped permissions — an agent can read everything but only write to specific content types. Every action is logged. The audit trail is queryable.

This isn't theoretical. The AI agent tracking built into the platform shows which AI crawlers are hitting the site, how often, and what they're querying (topic-level only — not raw content). Googlebot, GPTBot, ClaudeBot, PerplexityBot — all tracked, all distinguished by verified IP ranges.

Honest Trade-offs

I'd rather say this clearly than have someone discover it the hard way:

btlabs Core is not a SaaS product you can sign up for. It's a platform we deploy for clients. The codebase isn't open source. This means you're trusting us as the team. We've documented the migration path (the content model is exportable, structured data is open formats), but the dependency is real.

It's not the right fit if:

• You want a simple single-page site with no strategic intent

• Your team won't maintain content (the system helps, but it doesn't replace editorial discipline)

• You need a plugin ecosystem (there isn't one — everything is built-in or not available)

• You need guaranteed AI citations or ranking positions (nobody can promise that)

It works well when:

• You're managing a multilingual business with real content maintenance needs

• You want your site to be AI-native, not AI-adjacent

• Plugin maintenance and security patching are genuine pain points

• You want to own your data and your infrastructure

The Stack, for the Curious

• Backend/CMS: TypeScript, custom content layer

• Frontend: Next.js (ISR for sub-200ms delivery)

• Web server: Caddy (automatic HTTPS, reverse proxy)

• Analytics: Self-hosted Umami

• Email: Resend or SMTP (configurable)

• Auth: 2FA (TOTP + recovery codes), brute-force protection, rate limiting (token bucket per IP)

• Security: AES-256 for stored credentials, CSP headers, fail2ban, automated CVE scanning

• Backups: GPG-encrypted, 3-2-1 principle, 60-day retention, restore drills

• AI models: Pluggable (Claude, Gemini, DeepSeek — key optional, all features work without one)

• Hosting: Dedicated EU server per client

Where This Goes Next

The MCP endpoint is the piece I think has the most interesting long-term implications. Right now it's read-heavy — AI agents can query and contact. The roadmap includes structured booking, quote requests, and eventually transactional actions (within defined scope and with explicit user confirmation).

The broader thesis: a business website shouldn't just be a place people visit. It should be a queryable business entity — readable by humans through a browser, by search engines through structured data, and by AI agents through a defined interface. The technology to do this exists now. Most SMBs just don't have it yet.

btlabs Core → btlabs.dev

Built by Berger+Team, a freelance collective based in Bozen/South Tyrol. We've been doing this since 2018. Happy to answer technical questions in the comments.

Tags: #headlesscms #typescript #webdev #ai #mcp #multilingual #seo #dsgvo