Contentful

Founded in Berlin, Germany by Sascha Konietzke and Paolo Negri; company later moved HQ to San Francisco.

Proprietary SaaS content platform; not open source. Client SDKs and the CLI are open source (MIT-licensed on GitHub), but the core platform is closed.

Free plan (formerly 'Community'): 1 Starter Space, 10 users, 2 roles, 2 locales, 100K API calls/mo, 50 GB CDN bandwidth/mo, 25 content types, 2 environments, 10,000 records. No overages allowed on Free; hard caps.

There is no low-cost custom-domain tier; Contentful is API-only (no hosted frontend or 'domain' concept). The cheapest paid tier is Lite at $300/mo flat, billed monthly (no published annual discount found). The Free plan has no seat/feature gate tied to a domain since Contentful never serves a rendered site.

Lite ($300/mo) is Contentful's only fixed self-serve paid price point; above it, Premium/Enterprise plans are custom-quoted (contact sales), so no public 'most popular' number exists beyond Lite.

Not applicable: Contentful is a headless content platform, not a commerce platform. It has no native storefront/checkout; ecommerce data is modeled as content and stitched to a separate commerce backend (e.g., Shopify, commercetools) by the implementing developer.

Contentful never renders a public-facing site, so there is no 'Made with Contentful' badge to remove on any tier, free or paid.

No evidence of an introductory-vs-renewal price gap; Lite is a flat $300/mo, and Premium/Enterprise are individually negotiated contracts rather than teaser pricing.

No published money-back guarantee found on the pricing or legal pages; the 30-day free trial (no charge until you add a payment method) functions as the de facto risk-free window instead of a refund policy.

Contentful's own web app is a structured-data entry form.(fields defined by your content model), not a WYSIWYG page canvas. Actual page rendering is built and owned by developers on whatever frontend they choose; there is no default rendered preview of a 'site' inside Contentful itself. Contentful Studio (an add-on) layers an optional drag-and-drop visual page builder on top for pre-wired component-based frontends, but this is not the core editing model.

The core content-entry UI is form-based field editing, not drag-and-drop page layout. Drag-and-drop visual composition exists only in Contentful Studio, a separate paid add-on product with its own pricing, not part of the base CMS editor.

No click-to-edit rendered page in the base product, since Contentful does not render pages itself. Editors work in structured field forms inside the web app; on-page inline editing would require the developer to wire up Contentful's Live Preview / Studio SDK against their own frontend.

Entry versioning: every publish creates a snapshot, letting editors view prior published versions, see who published and when, diff against the current version, and restore all or selected changes. Versioning applies to the master environment.

Draft changes to entries are saved automatically as you type in the web app entry editor.

No official native mobile app for editing content was found in current Contentful docs/marketing pages; content management is web-app and API based.

Not applicable in the visual-builder sense: Contentful has no site 'templates' to switch between. Content types (schemas) can be changed, but altering a content type's fields is a content-modeling change that can break entries and requires migration, not a safe one-click switch.

Editorial judgment. Getting real value from Contentful requires someone to design a content model (content types, field relationships, validations) before any content exists, plus a developer to build the presentation layer against the API. There is no out-of-the-box site; both roles add ramp-up time compared to a builder that ships a working site by default.

Contentful ships no site templates or themes at all; it has no rendering layer. 'Content model templates' exist (reusable schema blueprints for content types, e.g. blog, product), which is a different concept from a visual site template.

Not applicable: Contentful has no design/rendering surface, so there is no concept of uploading a font to the platform. Fonts are entirely controlled by the developer-built frontend.

Not applicable in the visual-builder sense, but scored as full-control because responsive behavior is entirely up to the developer's frontend code with zero constraints imposed by Contentful, unlike a builder that limits breakpoint options.

Not applicable in the visual-builder sense (there is no in-app CSS editor), but scored as 'yes' because the frontend is 100% developer-built code with unrestricted CSS, since Contentful supplies no rendering layer to constrain.

Same as custom_css: the entire frontend, including all JavaScript, is written and hosted by the developer outside Contentful. No in-app restriction exists because there is no in-app rendering.

No native animation/interaction tooling in the CMS itself; any animation is implemented by the developer in the separately-built frontend. Contentful Studio (paid add-on) adds some visual composition tooling but that is a distinct product from the core CMS.

No design tokens or global style system in the base CMS; Contentful Studio (separate paid add-on) offers a design-tokens panel for teams using its visual builder, but this is not a core-product capability.

Editorial judgment, scored from the developer's perspective: since Contentful imposes no rendering layer at all, the frontend can be built with total design freedom (any framework, any CSS approach). This is the opposite of 'template-bound' but for a fundamentally different reason than a code-based site builder -- there's simply no visual product to constrain.

Contentful hosts and serves the content API and assets via its CDN, but it does not host or serve a rendered website. The frontend application must be hosted separately (e.g., Vercel, Netlify, AWS) by the developer.

Contentful is SaaS-only; the content platform itself cannot be self-hosted. (The frontend that consumes the API can of course be hosted anywhere, including self-managed infrastructure.)

Content Delivery API, GraphQL API, Images API, and the Asset CDN are served through Contentful's global multi-region delivery infrastructure (MRDI), covered by up to 99.99% availability SLA on qualifying plans.

Contentful's own API/CDN endpoints (cdn.contentful.com, images.contentful.com, etc.) are served over HTTPS by default; this does not extend to a customer's own frontend domain, which is hosted and certificated separately.

Not applicable: there is no rendered site inside Contentful to export as static files. Content itself can be exported (see ownership.content_export) and a developer's separate frontend/SSG could of course generate a static build, but that is outside Contentful.

HTTP Archive CWV Technology Report, latest month available (2026-05-01), 'overall' vital, desktop+mobile origins combined: 7,957 of 17,382 origins passing (45.8%). Split: desktop 52.5% (4,368/8,321), mobile 39.6% (3,589/9,061). Because Contentful is a headless CMS, this measures the Core Web Vitals of the developer-built frontends of sites that happen to use Contentful as their content backend, not any rendering performance of the Contentful product itself -- Contentful supplies no frontend at all.

Images API supports on-the-fly resizing, format conversion (JPG, PNG, WebP, AVIF, progressive JPG, 8-bit PNG), quality adjustment, cropping/focus area, and padding, delivered via URL query parameters against the asset CDN. Developers must actually call the Images API with the right parameters; it is not automatic/zero-config the way a site builder's image pipeline is.

Not a platform feature: Contentful serves image URLs via its Images API, but actual lazy-loading behavior (loading="lazy", intersection observers, etc.) is implemented by the developer in the frontend markup, not provided by Contentful itself.

The CDN-backed Content Delivery API and Images API are cached at the edge automatically; cache hits are not rate-limited (only requests that miss cache count against plan rate limits). Cache invalidation on publish is automatic, and developers can layer their own caching (ISR, ISG, ustom headers) in the frontend.

Not a built-in field; SEO title/meta description are ordinary custom fields the content modeler adds to a content type (e.g., a 'SEO' group with metaTitle/metaDescription text fields), then rendered by the developer's frontend into actual <title>/<meta> tags. Contentful supports this pattern natively via its flexible field types, including via AI Actions templates for meta description generation.

Slug is typically modeled as a Short Text field (often with a 'unique value' validation) on a content type; fully editable by content editors. URL construction from that slug happens in the frontend router, which Contentful does not control.

Contentful has no built-in redirect management feature (no hosting/routing layer to attach redirects to). Redirects must be implemented in the frontend host/CDN/edge layer (e.g., Vercel, Cloudflare, Next.js middleware) outside Contentful.

Not a dedicated Contentful feature; canonical URLs are typically stored as a plain text/URL field on a content type (or computed from the slug) and rendered into <link rel="canonical"> by the developer's frontend, which has unrestricted control.

Not applicable/no: Contentful serves no site, so it has no robots.txt to edit. robots.txt is a file the developer creates and serves from their own frontend hosting.

Contentful generates no sitemap. A developer must generate one in the frontend build (using the Content Delivery/GraphQL API to enumerate entries) since Contentful has no site-level awareness of published pages.

No automatic schema.org generation. Structured data must be modeled as content fields and/or hardcoded into the frontend template as JSON-LD by the developer; AI Actions can help draft structured-data-adjacent copy (FAQs, meta) but does not emit schema markup itself.

Contentful's locale system (multi-locale entries/spaces) supplies the underlying localized content and locale codes, but hreflang tags themselves must be rendered by the developer's frontend using that locale data; Contentful does not emit hreflang automatically since it renders no pages.

Same pattern as title/meta: OG image/title/description are typically modeled as fields (often reusing the SEO field group) and rendered into <meta property="og:*"> tags by the developer's frontend; fully controllable, just not automatic.

Achievable by adding a Boolean 'noindex' field to a content type and having the frontend conditionally render a <meta name="robots" content="noindex"> tag; not a built-in toggle since Contentful has no page/site concept, but fully supported via content modeling.

Every Asset has a built-in 'Description' field intended for alt text, settable per locale; the frontend is expected to render it into the <img alt> attribute. AI Actions offers an alt-text-generation template as well.

No prebuilt blog engine, post types, or listing/archive pages. A 'blog' is entirely a content model (e.g., a Blog Post content type) plus a hand-built frontend that queries and renders it; Contentful ships blog starter templates/repos on GitHub as a dev accelerator, but nothing is native out of the box.

This is Contentful's core strength: content types (schemas) are fully custom, defined per space, up to 50 fields each, with rich field types (short/long/rich text, number, date, boolean, location, JSON, media/entry references, arrays). Free plan allows 25 content types; higher plans raise the cap.

Tags (public/private, environment-level) for filtering and frontend navigation, plus a dedicated Taxonomy Manager (SKOS-aligned controlled vocabularies with hierarchy) that can be delivered via the Content Delivery API.

Native scheduled publish/unpublish per entry with timezone selection, plus 'Timeline' for staging multiple future versions of the same entry side by side; validation errors are checked at schedule time to prevent broken content from queuing.

See editor.undo_revision_history: automatic snapshotting on every publish, with diff/compare and restore of prior versions, on the master environment.

Up to 10 users on Free, 20 on Lite, custom scaling on Enterprise; multiple named roles (Admin, Editor, Author, Translator, Freelancer) support multi-author workflows out of the box.

No built-in RSS feed generation; Contentful has no page/site rendering layer to emit a feed from. A developer can generate RSS in their frontend build using the Content Delivery/GraphQL API.

Multiple first-class APIs: Content Delivery API (read published content), Content Preview API (read drafts/unpublished), Content Management API (full read-write CRUD on content types, entries, assets, roles, webhooks), and a GraphQL Content API auto-generated from the content model.

Contentful has no native commerce engine (no cart, checkout, product catalog, or payment processing). It is commonly paired with a separate commerce backend (Shopify, commercetools, BigCommerce, etc.) via its marketplace apps, with Contentful holding merchandising/marketing content rather than transactional commerce data.

Not applicable: no native product entities exist. If products are modeled as regular Contentful entries, they count against the plan's general 'records' limit (e.g., 10,000 on Free), not a dedicated product cap.

No native digital product delivery/licensing mechanism; would need to be built via content modeling plus an external commerce/fulfillment system.

No native recurring billing; Contentful is not a commerce or billing platform.

No native currency/pricing handling; multi-currency selling would live entirely in an integrated commerce platform, with Contentful at most storing display copy per locale.

No point-of-sale capability; not a commerce platform.

No cart concept exists in Contentful at all.

The CLI's `space export` command (folded into contentful-cli from the standalone contentful-export tool) dumps the full space: content model, entries, assets, roles/permissions, and webhooks, as JSON.

Not applicable: there is no design/site to export from Contentful, since it never rendered one. The 'design' lives entirely in the developer's own separately-owned frontend codebase, which was never inside Contentful to begin with.

Contentful has no concept of a bound domain at all (it serves an API, not a site), so there is no platform-side domain lock-in of any kind.

The frontend that consumes Contentful's API can run anywhere (any cloud, any host) by design; only the content backend itself remains SaaS-only on Contentful's infrastructure.

Content Management API provides full read-write access to every entry, asset, content type, and piece of metadata; Content Delivery/GraphQL APIs provide full read access to published content.

Editorial judgment. Content itself exports cleanly (JSON, full fidelity, open CMA), which is a real ownership advantage over closed hosted builders. But content-modeling decisions (field structure, reference graphs, rich-text format, locale architecture) are Contentful-specific and require nontrivial remapping to migrate to another headless CMS or self-hosted system; and the recent Salesforce acquisition adds roadmap/pricing uncertainty for existing customers to weigh.

Content Delivery API, Content Management API, Content Preview API, GraphQL Content API, and Images API are all public and fully documented.

Configurable per space (Settings > Webhooks) with custom headers, filters, and payload templates; pre-built webhook templates exist for destinations like Algolia and AWS. Content-event triggers include publish/unpublish/archive/delete on entries and assets.

Not applicable in the visual-builder sense (no page canvas to embed code into), but developers have unrestricted custom code in their own frontend, and the App Framework/UI Extensions SDK lets developers embed custom React-based fields and sidebar widgets directly inside the Contentful web app itself.

Official `contentful-cli` (npm) supports login/config, space import/export, content-type/space/environment management, and migration scripts; open source on GitHub.

Official Zapier integration (triggers on entry publish/update, etc.) connecting Contentful to thousands of Zapier-supported apps. No dedicated native Make (Integromat) app was confirmed in official docs; Make automation is typically done via Contentful's webhooks/API rather than a first-party Make connector.

No AI site/page generation exists because Contentful renders no sites. Contentful Studio (separate paid add-on) includes an AI Image Generator and AI content generator for populating components within its visual builder, but that is scoped to a distinct add-on product, not the core CMS.

AI Actions (Enterprise Platform plans) embeds generative AI into content workflows via natural-language prompts and pre-built templates for translation, SEO optimization, grammar correction, and custom prompt-based content generation; supports bringing your own model (OpenAI, AWS, Google) or using Contentful's default.

No native AI image generation/editing in the core CMS; an AI Image Generator exists specifically inside the separate Contentful Studio add-on, not as a base-platform feature.

AI Actions includes pre-built templates specifically for SEO tasks: keyword optimization, meta description creation, FAQ generation, and alt-text writing, in addition to general translation and content generation templates.

Five preset space roles (Admin, Editor, Author, Translator, Freelancer) plus fully custom roles with field/content-type/environment-level permission rules; custom roles and default-role editing are gated to Premium-tier plans and above (not available on Free or Lite).

Lite plan and above include 'live collaboration' per Contentful's pricing page; multiple editors can work in a space simultaneously with entry-level locking/awareness.

Native Workflows feature with configurable steps/stages and role-based workflow permissions, plus scheduled publish/unpublish and AI Actions-driven auto-routing through approval chains with Slack/email/Teams notifications.

Full sandbox Environments (clone of master or another sandbox) for isolating content-model/content changes, plus a dedicated Content Preview API (preview.contentful.com) for rendering unpublished drafts in a developer's own preview build.

Comments and task management are listed as Lite-plan-and-above features (not on Free) on the Contentful pricing page, enabling in-entry discussion threads.

Entry version history captures who published what and when (for entries); broader organization-level audit logging is part of Enterprise-tier governance/compliance features.

24/7 customer support is included specifically on Enterprise Platform plans per Contentful's pricing page; not available on Free or Lite, which have no guaranteed response times.

Editorial judgment: Contentful's developer docs are organized into clear Concepts/References/Tutorials/SDK sections with live API reference, per-language SDK guides, a searchable Help Center for non-technical admin/editor topics, and a public API changelog -- comprehensive and well-maintained compared to most CMS competitors.

No automatic scheduled backup product; backups are performed via the CLI's `space export` (full JSON dump of content model, entries, assets, roles, webhooks) run manually or scripted by the customer. Entry-level version history provides granular undo separately from full-space backup.

Locales are a first-class space-level concept (ISO codes like en-US, de-AT); every field can be localized. Free plan includes 2 locales, Lite includes 3, Enterprise offers a custom number. Multiple architectural strategies supported: field-level, entry-level, content-type-level, or space-level localization, chosen per project.

Dedicated Translator role for locale-scoped editing, locale-based publishing (publish one locale's changes independently of others so editors can work asynchronously), and AI Actions includes a translation template for automated first-pass translation.

Contentful supplies the locale-structured content and codes needed for per-locale URLs and hreflang, but actual URL routing and hreflang tag emission must be built by the developer's frontend, since Contentful renders no pages itself.

Not a special toggle; RTL languages (e.g., Arabic, Hebrew) are supported the same as any other locale (Contentful stores and delivers whatever text/locale is defined), with actual RTL layout/direction handled by the developer's frontend since Contentful does no rendering.