How to Tell If a Website Uses Contentful

Contentful is one of the leading headless content management systems — an API-first CMS that stores content centrally and delivers it to any front end via API. Because it is headless, it leaves no traditional CMS markup on the public site, so detecting it relies on a different kind of signal: assets served from images.ctfassets.net and API calls to cdn.contentful.com. This guide explains those signals, why headless detection works differently, and what a Contentful build reveals about the team.

What is Contentful?

Contentful is a cloud-based, API-first headless CMS founded in 2013. Unlike a traditional CMS that both stores content and renders the website, Contentful does only the first job: editors manage structured content in Contentful, and developers pull that content via API into whatever front end they choose — a Next.js site, a mobile app, a digital sign, an in-store kiosk. This decoupling of content from presentation is the defining idea of the headless and "composable" architecture movement, and Contentful is one of its flagship products alongside Sanity, Strapi, Prismic and Storyblok.

For detection, the crucial consequence is that there is no CMS fingerprint in the rendered markup — no generator tag, no /wp-content/-style path, no admin route on the public domain. The website could be built with any framework and hosted anywhere. What does remain visible are the parts of Contentful that the browser still touches: the asset CDN that serves images and files, and, on client-fetching sites, the Content Delivery API. Contentful is a premium, paid platform aimed at mid-market and enterprise teams, so finding it signals a developer-led organisation that has invested in a modern, decoupled architecture.

How Contentful delivers content and assets

Contentful exposes two browser-visible systems. The first is its asset domain, ctfassets.net: images are served from images.ctfassets.net, other files from assets.ctfassets.net, videos from videos.ctfassets.net and downloads from downloads.ctfassets.net. These URLs follow a consistent structure that embeds the space ID and the asset ID — for example https://images.ctfassets.net/<spaceId>/<assetId>/<hash>/filename.jpg — often with Contentful's Images API transformation parameters (?w=, ?h=, ?fm=webp, ?fit=) appended. Because almost every Contentful-powered site serves its images this way, the ctfassets.net domain is the single most reliable signal.

The second system is the Content Delivery API at cdn.contentful.com (with preview.contentful.com for draft content and graphql.contentful.com for GraphQL). Whether you see calls to it depends on the rendering strategy: a client-side React or Vue app may fetch content from cdn.contentful.com live in the browser, which is directly visible in the Network tab; a server-rendered or statically generated site (the more common pattern) calls the API at build or request time on the server, so you will see only the resulting HTML and the ctfassets.net asset URLs, not the API calls. Understanding this distinction tells you where to look.

How to tell if a website uses Contentful

Confirm at least one strong signal (the asset domain is usually sufficient).

1. Inspect image sources. Open the Network tab or right-click an image and check its URL. Media served from images.ctfassets.net (or assets.ctfassets.net) is the clearest Contentful signal. The space ID is the path segment right after the domain.

2. Watch for API calls. In the Network tab, filter for contentful. Calls to cdn.contentful.com, preview.contentful.com or graphql.contentful.com confirm a live, client-side Contentful integration.

3. View the page source. Search the HTML for ctfassets.net and contentful. Even on server-rendered sites, image URLs and sometimes inlined data reference the asset domain.

4. Look for Images API parameters. Contentful asset URLs commonly carry transformation query parameters like ?w=800&fm=webp&q=80, which are characteristic of its Images API.

5. Read the space ID. The path segment after ctfassets.net/ is the Contentful space ID, which identifies the specific content space and confirms the integration.

What the Contentful signals look like

GET https://images.ctfassets.net/abc123spaceid/4xY.../hash/hero.jpg?w=1200&fm=webp&q=80
GET https://cdn.contentful.com/spaces/abc123spaceid/environments/master/entries?...   (client-side fetch)
HTML: <img src="https://images.ctfassets.net/abc123spaceid/.../cover.png?w=800" ...>

Assets on ctfassets.net are conclusive on their own; a cdn.contentful.com API call confirms a client-side integration and reveals the space.

Contentful versus other headless CMSs — avoiding false positives

Because headless systems all hide behind APIs, the right approach is to match the asset and API domains exactly. Contentful uses ctfassets.net and cdn.contentful.com; Sanity uses cdn.sanity.io and *.api.sanity.io; Prismic uses images.prismic.io and *.cdn.prismic.io; Storyblok uses a.storyblok.com (and a-us.storyblok.com); Strapi typically serves uploads from /uploads/ on a first-party or cloud domain. Each has a distinct asset CDN, so a single image URL usually identifies the platform. The main subtlety is server-side rendering: when content is fetched at build time, you will not see cdn.contentful.com calls in the browser, so do not conclude "not Contentful" from the absence of API traffic — check the image URLs, which still point at ctfassets.net.

How reliable is each Contentful signal?

Assets on ctfassets.net are definitive — the domain is specific to Contentful and the URL embeds the space ID. Calls to cdn.contentful.com, preview.contentful.com or graphql.contentful.com are equally conclusive and additionally prove a client-side integration. The Images API transformation parameters are strong corroboration. The weakest situation is a site that proxies or rewrites asset URLs through its own domain to mask the CDN, which is uncommon but does happen on sophisticated builds; there, build-time integration leaves few browser signals and you may need deeper inspection. As a rule, a single ctfassets.net image URL settles it.

What a Contentful build reveals about an organisation

Contentful is a premium, API-first platform, so finding it signals a modern, developer-led organisation that has deliberately adopted a headless or composable architecture — content managed centrally and delivered to one or more decoupled front ends. That profile correlates with mid-market and enterprise companies, digital product teams, and brands that publish across multiple channels (web, app, in-store). It also implies a real engineering team, since headless requires developers to build and maintain the front end. If you sell developer tools, hosting (especially edge and Jamstack hosting), front-end frameworks, search, personalisation or DXP services, a Contentful site marks a technically sophisticated, budget-bearing account. The space ID in the asset URLs can even help you recognise when several brands or sites share one Contentful space, indicating a consolidated content operation.

Contentful in a composable stack

Contentful is the content layer of a broader composable stack, and finding it should prompt you to map the rest. The front end is typically a modern framework — Next.js, Nuxt, Gatsby, Astro or similar — hosted on an edge or Jamstack platform like Vercel or Netlify. Composable builds often pair Contentful with a dedicated search provider (Algolia), a commerce engine (commercetools or Shopify in a headless configuration), a digital-asset or image service, and analytics. Because the architecture is API-first, you will frequently see other third-party APIs called client-side. For an auditor, the valuable details are the space ID, whether content is fetched client-side or at build time, the front-end framework, and the hosting platform; together these reveal the shape and maturity of the company's composable architecture, not just that it uses Contentful.

A quick Contentful confirmation walkthrough

Open the site with developer tools on the Network panel and reload. Sort or filter by domain and look for requests to images.ctfassets.net or assets.ctfassets.net — any such request confirms Contentful. Click one and read the path segment after the domain to capture the space ID. Filter for contentful to see whether cdn.contentful.com is called client-side, which indicates a client-fetching front end. If you see only ctfassets.net images and no API calls, the site is almost certainly server-rendered or statically generated from Contentful at build time. Either way, the ctfassets.net asset URL is your conclusive signal.

A quick Contentful detection checklist

• Check image URLs for the images.ctfassets.net / assets.ctfassets.net domain — conclusive on its own.
• Filter the Network tab for contentful to spot cdn.contentful.com client-side calls.
• Read the space ID from the path segment after ctfassets.net/.
• Note Images API parameters (?w=, ?fm=webp) as corroboration.
• Identify the front-end framework and host to map the composable stack.
• Don't rule out Contentful just because no API call is visible — build-time fetching hides it.

Detecting Contentful at scale

Checking one site is quick, but mapping headless-CMS adoption across many domains — to find composable, developer-led companies — calls for automation. StackOptic detects Contentful via its asset and API domains, alongside thousands of other technologies, from a real browser, so it catches both client-side and server-rendered integrations. For related reading, see our guide to telling what CMS a website is using and the full Contentful technology profile.