Draftbase runs its own marketing site on Draftbase
draftbase.co's blog, docs, and research content are stored and served through Draftbase itself. The reason isn't ranking tactics — a typed API and an MCP server make writing, editing, and extracting content faster, and search/answer-engine best practices come along as a byproduct.
Updated
1
Delivery API for the CMS and the marketing site
30
MCP tools available for editing content
0
Standing SEO workstream needed on top
0
Separate rendering path for "our own" content
Content lives in Draftbase, not in the repo
lib/cms/client.ts calls createClient() from @draftbase/sdk against the site's own delivery API — the identical client any customer installs. Blog posts, docs pages, cluster articles, and author profiles are typed Entry fields, fetched the same way a customer's app would fetch them.
import { createClient } from '@draftbase/sdk';
export const cms = createClient({
apiKey: process.env.DRAFTBASE_DELIVERY_API_KEY ?? '',
baseUrl: process.env.DRAFTBASE_CMS_API_URL || API_URL,
});
// toCamelCase(name) from template creation — no env var needed
export const TEMPLATE_IDS = {
author: 'author',
blogPost: 'blogPost',
docPage: 'docPage',
clusterArticle: 'clusterArticle',
pricingPlan: 'pricingPlan',
};The clearest instance is the headless CMS pricing database at /research/headless-cms-pricing: the dataset lives in Draftbase and renders through the same delivery API, with a public JSON endpoint alongside the page for anyone who wants the raw data.
Why editing is easy
Edit through MCP, not a separate admin flow
The same 30-tool MCP server a customer’s coding agent uses can create and edit entries, templates, media, and MDX components for the marketing site — no bespoke CMS workflow just for draftbase.co.
A typed schema, not a folder of files
A blogPost template defines fields once. Every entry moves through draft, review, and publish with full revision history and rollback — the same states any customer’s content gets.
Plain MDX, no rich-text AST
Authors write MDX strings, not a proprietary document tree, so the editing habit that works for a blog post works the same way for a docs page or a cluster article.
Why extraction is easy
One typed delivery API for every surface
Blog, docs, cluster articles, and the pricing research database all come out through the same read-only API — no bespoke integration per content type to pull any of them.
llms.txt generated from the real route list
app/llms.txt/route.ts builds its index from the same routes the site already maintains, so it can’t drift out of sync with what’s actually published.
The generator ships as a free tool too
/tools/llms-txt-generator packages the same capability so anyone can generate a valid llms.txt for their own site, Draftbase or not.
Best practices met as a byproduct
None of these needed a separate SEO project. Each one falls out of already having a typed, API-driven content layer instead of static files.
Dynamic sitemap
app/sitemap.ts pulls every URL from getAllSiteUrls() — the same source content is fetched from, so there’s no hand-maintained list to fall out of sync with what’s published.
buildPillarMetadata() and buildPillarJsonLd()
Shared helpers set canonical URL, OpenGraph, and FAQPage/BreadcrumbList schema from fields already on the entry — the FAQ schema and the FAQ a visitor reads are the same data.
AEO structure as a house rule
Answer-first paragraphs and question-phrased headings are written once in the copy guide and applied consistently, rather than decided per page.
IndexNow on deploy
scripts/indexnow.ts posts the sitemap on publish, so an edit gets picked up promptly instead of waiting on the next crawl — the same idea as a webhook notifying a downstream system.
Distribution
dev.to syndication. Teaser posts carry a canonical pointing back to draftbase.co, so a post exists in one canonical place even when it's shared in more than one.
r/draftbase_cms. A maintained subreddit with its own cadence, kept separate from the on-site copy guide.
Free tools at /tools. MCP Inspector, llms.txt Generator, JSON-to-TypeScript, Slug Generator, Alt Text Generator, Supabase RLS Checker, Key Scanner — each solves a manual step Draftbase automates for its own customers, shipped as something useful on its own.
Outcome
One content base, fetched through one typed delivery API, is easier to write for and easier to extract from — and because both of those are true, it keeps meeting search, answer-engine, and machine-readability best practices without a standing SEO workstream. The dogfooding isn't a marketing angle; it's the same product any customer gets, running its own site.
See the same delivery API in your own stack
The API serving draftbase.co's own blog, docs, and research pages is the same one every org gets on day one.
Hobby is free, no card. Startup is $49/mo when you outgrow it. The price is on the pricing page, where prices go.
No migration quarter, no kickoff workshop. Define a template and ship something today.