"If our content lives in an API, can Google even see it?" is the question every team asks before going headless — usually prompted by someone who watched a client-side React app render an empty <div> for a crawler in 2019. The concern is outdated, but the question hides a real one: headless moves SEO responsibility from the CMS to you. This post is the map of what you now own.
The short answer
Search engines rank HTML served from URLs on your domain. They neither know nor care whether that HTML was assembled from a database, an API, or markdown files. A headless setup with server-side rendering produces exactly the same crawlable output as a traditional CMS — often better, because you control every byte of the page.
The catch is the conditional clause: with server-side rendering. Get the rendering model right and the rest is ordinary technical SEO.
Rendering: the one decision that matters
Three ways to turn API content into pages:
Client-side rendering (CSR): the browser fetches JSON and builds the page with JavaScript. Google can execute JavaScript, but rendering is deferred and other crawlers, link previews, and social scrapers vary. For content you want ranked, CSR is the risky choice.
Server-side rendering (SSR): your server fetches from the content API per request and returns finished HTML. Always crawlable; freshness is automatic; cost is a fetch per request (cached as you see fit).
Static generation (SSG): pages are built ahead of time and served as files. Fastest possible delivery; requires rebuilds or revalidation when content changes.
Any modern framework — Next.js, Astro, Nuxt, SvelteKit, TanStack Start — does SSR or SSG against a content API as its default happy path, with the API call in a loader or at build time. If you take one rule from this post: public content pages render on the server.
The domain advantage nobody mentions
Going headless is often an SEO upgrade for a structural reason: it puts content on your primary domain. Hosted blog and docs platforms live on subdomains or their own domains, and the authority your articles earn accrues there. With headless, /blog, /help, and /changelog are subdirectories of the domain your product lives on — every backlink to an article strengthens every other page you own. This single factor usually outweighs all the meta-tag details below.
The checklist you now own
A traditional CMS handles some of this invisibly. Headless hands it to you — a one-time setup in a helper function, since everything derives from the same API responses.
Per-page metadata
Title, meta description, Open Graph and Twitter tags, article timestamps. Author these as fields in the CMS alongside the content, and emit them in the document head from the same fetch that renders the page. A content backend that models SEO fields per entry (title, description, image) makes this a mapping, not a project.
Canonical URLs
Every page declares its canonical URL, computed from the entry's slug — never echoed from the request URL, which would canonicalize ?utm_source= variants and casing accidents. One function that maps an entry to its path, used by pages, sitemap, and feeds alike, guarantees they never disagree.
Real status codes
An unknown slug must return HTTP 404, not a styled error page with status 200. Soft 404s waste crawl budget and pollute the index. Similarly, if your server route cannot reach the content API, fail with a 5xx and Cache-Control: no-store rather than caching an empty 200 at your CDN.
Sitemap and feeds
Generate sitemap.xml from the same list endpoints your index pages use, with real lastmod from entry timestamps. Add RSS for blog and changelog — feeds are cheap and both readers and crawlers use them.
Structured data
Emit JSON-LD (Article for posts, FAQPage where it fits, Organization on the home page) from entry data. One subtlety when injecting JSON-LD from server code: escape every < in the serialized JSON as \\u003c so a stray </script> inside a title cannot break out of the script tag.
Noindex what should not rank
Search-results pages, preview routes, and paginated tag permutations often deserve noindex. If your platform offers a hosted portal on its own domain as well as API delivery, check how it handles indexing — Kookee's hosted portal pages are deliberately noindexed so your own domain's rendering of the same content is the only version competing in search, with no duplicate-content ambiguity.
Freshness and cache discipline
With SSR, published edits are live on the next request. With SSG, decide the staleness budget per content type: a blog rebuilds lazily; a changelog or status-sensitive page wants revalidation measured in minutes. Either way, cache at your CDN with intent — cache keys on the URL, sensible TTLs, and purge-on-publish if your platform supports webhooks or you trigger rebuilds on publish.
Multilingual content
If you serve multiple locales, headless again gives you the clean version: fetch the entry's translations from the API, serve each locale at its own URL, and emit hreflang alternates from the translation list. What it will not do is save you from machine-translating half-heartedly — only publish locales you maintain.
A test you can run today
Take your highest-value page and check, with JavaScript disabled: does the full text appear in the HTML source? Do title, description, and canonical reflect that page? Does a garbage slug return 404? Fetch sitemap.xml — is the page there with a plausible lastmod? Fifteen minutes, and it covers 90% of what goes wrong.
Headless does not hurt SEO. Unrendered JavaScript hurts SEO, wrong status codes hurt SEO, and vendor subdomains quietly tax it. Choose server rendering, derive every signal from the entry data you already fetch, and keep the authority on the only domain that should be earning it — yours.