TYPO3

Core TCA defines any record type in code with a wide field set (input, text, number, datetime, email, link, color, json, slug, select, category, group, inline, file, flex, imageManipulation and, new in v14, country), and the group field can reference several tables, giving native polymorphic references. v14 adds record type specific labels, titles and TCAdefaults, and Content Blocks 2.x (extension, YAML definitions) targets v14.3 and makes new types far quicker to build. Not higher because there is no UI-only schema builder in core and defining types needs a developer.

Group, select and inline fields support one-to-many and many-to-many relations through MM tables, the MM_opposite_field setting makes a relation editable from both ends, and the core reference index tracks every reference for reverse lookup. Not higher because reverse traversal is not exposed through a delivery API without extensions and bidirectional setup needs explicit TCA configuration.

Inline relations (IRRE) nest child records to any depth inside an entry, content elements compose pages through backend layouts and columns with FlexForms for per-element settings, and v14 adds native content element restrictions per column plus the f:render.contentArea and f:render.record ViewHelpers for component style rendering. Not higher because nested content elements inside content elements still need the community container extension, and rich text is stored as HTML rather than a portable structure.

TCA offers required, unique and uniqueInPid, min and max length, number ranges, email and trim evaluations, file type and count limits, and custom evaluation classes, all enforced by DataHandler so imports and scripted writes are checked too; v14 also accepts Symfony validators in Extbase. Not higher because cross-field rules need PHP hooks or events and editors cannot add validation rules without a developer.

Core record history logs every change with user attribution, shows a field-level diff and restores any earlier state, the core Recycler restores deleted records, and Workspaces keep draft versions separate from live content until published. v14 adds a language selector in the history view, automatic history tracking for Extbase entities and a DataHandler discard command for workspace changes. Not higher because history is per record rather than a branchable content set, and retention depends on cleanup tasks the integrator configures.

System categories are core: a hierarchical tree, a category field type that can be added to any table, categories on file metadata, and backend group permissions that restrict which categories editors may use. Not higher because there are no synonyms or bulk reclassification tools, multiple controlled vocabularies are modelled as category subtrees, and API exposure needs EXT:headless.

Core page preview renders drafts in the real site theme, and in v14 workspace preview links extend to all records, a QR code button opens the preview on a phone, and the Layout module edits records contextually in a side panel. v14 core also ships the f:render.text and contentArea hooks that let the Visual Editor extension (FriendsOfTYPO3 1.10.4, supports 14.3) give click-to-edit, drag and drop and side-by-side multi-language editing on the frontend, working out of the box with the Camino theme. Not higher because frontend inline editing is still an extension rather than core and headless frontends need custom preview wiring.

CKEditor 5 ships in core (rte_ckeditor) with YAML presets per field, links to pages, records and files, paste from Word and custom plugins, and v14 adds an event to adjust RTE configuration at runtime. Not higher because output is HTML, embedding structured records inline needs custom plugins, and there is no Markdown mode.

The core File Abstraction Layer gives a file list with folders, metadata, alt text and file references that record where each asset is used, and the image editor supports crop variants per device with focus and cover areas. v14 adds synchronized editing of all crop variants, a configurable default image conversion (for example to WebP or AVIF), a core srcset ViewHelper and cache tag flushing on file operations. Not higher because transforms are rendered server side through ImageMagick or GraphicsMagick rather than URL parameters.

Core warns an editor when another user has the same record open, Workspaces carry comments with every stage change, and internal notes can sit on pages. Not higher because there is still no presence, co-editing, inline commenting or mentions in core in v14.

Core Workspaces support custom stages between editing and publishing, responsible users or groups per stage, email notifications with comments on each transition, publish-only-by-reviewer settings and a stage history, and v14 adds editor information in the Publish module plus custom actions and custom columns in the workspaces module. Not higher because stages are per workspace rather than per content type, and there is no conditional or parallel routing or due dates.

Every page and content record has native publish and expiry dates, and a workspace bundles many changes that publish together, with a scheduler task to publish a workspace at a set time; v14 moves scheduler tasks to a native table with a task wizard and priorities. Not higher because there is no publishing calendar view, and scheduled workspace publishing relies on a configured cron scheduler.

Languages are configured per site with multi-level fallback chains and strict, fallback or free modes, records translate in connected or free mode, per-field l10n_mode decides which fields are translated or inherited, and backend groups can be restricted to languages. v14 replaces the old localization dialog with a step-based translation wizard that only offers the mode matching existing translations, preventing mixed modes, and adds multi-language views in the page and list modules. Not higher because the connected and free model still needs editor training and locale-aware preview depends on workspace or site setup.

Backend groups grant access per table, per field (exclude fields), per page subtree, per language, per file mount and per workspace, one of the finest-grained core permission models among open-source CMSs, and v14 adds module access gates and a detail view for backend user groups. Not higher because SAML and OIDC SSO come from extensions (oidc, md_saml, miniorange) and there is no SCIM provisioning.

Core has no general content delivery API; JSON delivery comes from the headless extension (FriendsOfTYPO3), which renders pages and content as JSON with multilanguage, multidomain and workspace support, and GraphQL from community extensions. For v14 the headless extension is still a release candidate (5.0.0-rc2, September 2026) while the stable 4.8 line supports only v12 and v13. Not higher because filtering, sorting and pagination are defined in TypoScript per project and nothing ships in core.

The core caching framework with page cache and cache tags clears affected pages on publish (v14 also flushes tags on file and folder operations), and extensions such as staticfilecache and CDN purge integrations push content to Varnish or a CDN. Not higher because TYPO3 is self-hosted with no CDN of its own and edge delivery depends on what the hosting partner provides.

Core Webhooks send outgoing requests for triggers such as page and record changes, file events and login errors with HMAC signed payloads, managed in the new v14 Integrations module alongside core Reactions for incoming calls and a large PSR-14 event system. Not higher because delivery logs and retry handling are basic and there is no event streaming integration.

The record model is channel agnostic, and with the headless extension and the community nuxt-typo3 frontend TYPO3 can feed JavaScript apps. Not higher because TYPO3 is a coupled web CMS by default, rich text is HTML, there are no official SDKs, and the headless extension has no stable v14 release yet.

Core has no visitor segmentation beyond frontend user groups. On v14 the LUX extension (in2code, 44.4.1, supports 14) tracks and identifies leads with scoring and categories inside TYPO3, while Marketing Automation (Leuchtfeuer) personas and the Mautic adapter still only support v13.4. Capped at integration because all of it is TER extensions, with no named CDP connector such as Segment or Tealium.

Core only restricts pages and content elements by logged-in frontend user group. Persona-based restriction (Marketing Automation) and Mautic dynamic content blocks are v13-only, so on v14 visitor personalization comes from external SaaS such as the Personyze tag extension or LUX lead data. Not higher because there are no native per-segment variants or audience preview in the editor.

A/B testing comes from external SaaS loaded through an extension, such as the Personyze tag extension, or a testing tool added through tag management. Not higher because nothing in core or a maintained extension provides traffic allocation with significance reporting inside TYPO3.

Related content is built editorially with categories and record relations, and algorithmic recommendations only come from external services such as Personyze. Not higher because there is no built-in recommendation engine.

Core Indexed Search provides a full-text index and results page (v14 adds configurable pagination and a result-set event), and the widely used extensions ke_search (7.3.1, supports 14) and Apache Solr for TYPO3 (14.0.2 for v14.3) add facets, synonyms and autocomplete. Scored as basic native search; the faceted experience is extension assembly.

Aimeos (26.7.1, June 2026, supports 13.4 and 14.3) delivers a full shop inside TYPO3 with catalog, cart, checkout, B2B and multi-vendor features. Capped at integration because it is a third-party extension, not core.

No maintained TYPO3 v14 connector for Shopify, commercetools, Salesforce Commerce Cloud or SAP Commerce exists on Packagist; projects integrate external commerce through custom API work or storefront embeds. Not higher because there is no product picker or federation extension to point to.

Core ships a dashboard with operational widgets (v14 makes widgets configurable) but no content performance analytics. The LUX extension, which supports v14, adds page view, download and lead analytics modules in the backend. Low in the integration band because the analytics are lead-focused and come from a third-party extension.

GA4, Google Tag Manager and Matomo are added through TER extensions or TypoScript snippets, and consent managers such as sgalinski Cookie Consent (8.1.12) and mindshape Cookie Consent (5.0.2) gate tags. Not higher because nothing is first-party and there is no Adobe Analytics or Segment integration.

One TYPO3 installation and database runs many sites, each with its own site configuration, domains and languages, and site sets package shared settings for reuse (v14 adds route enhancers and sitemap configuration in site sets). Content is shared across sites with Insert Records and mount points under one permission model. Not higher because there is no content syndication workflow or central site catalog beyond the page tree.

v14 core replaces the old localization dialog with a step-based translation wizard across all backend modules and a localization handler registry for extensions, and DeepL Translate (6.0.7) plugs machine translation in. Localization Manager (l10nmgr) adds XML and Excel export for agencies, but its public release targets 13.4 and v14 builds are paid priority access. Not higher because no official Phrase, Smartling or Lokalise connector exists.

Brands run as separate site roots in one install with shared site sets, TypoScript and backend user groups that restrict editors to their own tree. Not higher because there is no cross-brand policy enforcement, brand-level component overrides or brand reporting.

The core File Abstraction Layer with file metadata gives a central library with categories, copyright and metadata fields and shows where each file is referenced. Not higher because there are no rights or expiry rules, approval workflow or asset versioning, and the maintained Bynder FAL driver (bynder2) still targets 13.4.

Core renders uploaded video and audio files with HTML5 players and handles YouTube and Vimeo as online media in the file list. Not higher because there is no transcoding, adaptive streaming or captioning workflow.

The core Layout module (renamed from Page in v14) composes pages from content elements in backend layout columns with drag and drop, an integrator-defined element palette and context-aware editing. The Visual Editor extension (FriendsOfTYPO3, 1.10.4, supports 14.3) adds in-page drag and drop and inline editing but is not core. Not higher because core composition happens in a backend grid, not a live visual canvas.

TYPO3 renders full sites natively with Fluid templates, TypoScript, routing and page caching, but the customer or an agency hosts it. TYPO3 GmbH sells ELTS and support, not hosting, so there is no vendor-operated site delivery.

The core Form extension gives editors a drag and drop form editor with multi-page forms, validators, honeypot spam protection and finishers for email, redirect and saving to the database, and v14 adds database storage for form definitions, rich text and date editors and multiple file upload. Not higher because there is no progressive profiling, form analytics or lead routing in core.

On v14 the Brevo extension (studiomitte/brevo 3.0.0, October 2026) connects TYPO3 to the Brevo ESP, while Luxletter newsletters and the Mautic form adapter still only support v13.4. Not higher because connectors for HubSpot, Marketo or Salesforce Marketing Cloud are not maintained extensions and there is no triggered send from CMS events.

LUX runs lead identification, lead scoring and activity tracking inside TYPO3 v14 with workflows in its commercial edition. The Mautic adapter for nurture campaigns has not been released for v14. Capped at integration because LUX is a third-party extension rather than core.

Core EXT:seo provides meta title and description with a snippet preview, Open Graph, canonical and hreflang tags and XML sitemaps for pages and records, and the core Redirects module handles regex, 301 and 302 redirects with automatic redirects on slug change. Not higher because structured data (brotkrueml/schema 4.4.0) and on-page recommendations (Yoast SEO for TYPO3 12.1.2) are extensions.

TER extensions add llms.txt and per-page Markdown on v14: LLMS TXT Generator (ai_llms_txt 0.3.0, October 2026) and llms-txt (rtfirst), and core site configuration serves a managed robots.txt. Not higher because the extensions are young, and there is no per-bot rate limiting or AI citation reporting.

The TYPO3 Extension Repository and Packagist hold thousands of extensions installed through Composer, with v14 releases for major ones (ke_search, Solr, Aimeos, LUX, schema, Yoast). Not higher because quality and maintenance vary, several common extensions (Mautic, powermail, femanager, Luxletter) have not reached v14 six months after its LTS, and some gate v14 builds behind paid early access.

Core Frontend Login (felogin) handles visitor login and password recovery, and frontend user groups restrict pages and content elements, so gated member areas work in core. Not higher because OpenID Connect federation (causal/oidc 6.0.1, supports 14.3) is an extension, self-registration (femanager) has not been released for v14, and there is no portal or consent center.

TYPO3 v14 LTS core still ships no content delivery API: the 14.0 to 14.3 changelogs add the internal Record API, content area rendering and many PSR-14 events, but no REST, GraphQL or OpenAPI endpoint. Headless delivery comes from the TER extension EXT:headless (friendsoftypo3/headless), which renders pages, content elements, navigation, metadata and forms as configurable JSON, and GraphQL only from separate community extensions. The JSON shape follows TypoScript page rendering rather than a resource oriented API design, so it scores below Drupal's core JSON:API.

Performance is whatever the customer's hosting delivers: the core caching framework offers tag-based page caching with database, file and Redis backends (v14 adds Redis authentication and cache tag flushing for file operations), but there is no vendor-run API, CDN-backed delivery tier, rate limiting or documented throughput ceiling. EXT:headless output reuses the page cache, which is efficient for page-shaped requests, but there is no sync or bulk export API for large datasets.

There are no official multi-language content SDKs from the TYPO3 Association or TYPO3 GmbH. The only notable consumer library is nuxt-typo3, a Vue/Nuxt frontend maintained by the TYPO3 Headless initiative alongside EXT:headless; other stacks call the JSON output with generic HTTP clients. Community-only tooling with a smaller audience than Drupal's equivalents.

The TYPO3 Extension Repository is a large, long-running ecosystem with mature extensions for search (Apache Solr for TYPO3), forms (powermail), news, events, frontend user management and headless delivery, plus Composer/Packagist distribution. Coverage of SaaS integrations (commerce, DAM, modern analytics, AI) is thinner and more agency-built than Drupal's module ecosystem, and quality varies, as the August 2026 batch of extension advisories shows.

Extensions can change every layer: PSR-14 events (v14 adds many more, including content area, live search and record rendering events), PSR-15 middlewares, Symfony dependency injection, TCA for custom records and fields, backend modules, Extbase/Fluid plugins, CLI commands and scheduler tasks as native TCA records. Core keeps incoming reactions and outgoing webhooks, and the Content Blocks extension simplifies YAML content type registration. A deep server-side model on par with Drupal, short of it only in modern frontend tooling.

Core ships backend MFA (TOTP plus recovery codes) with enforcement settings and a provider API, password policies, and in v14 a password generator and notifications to users on failed MFA attempts, with no licence gating. SSO via OIDC or SAML and passkeys are not in core and depend on community extensions such as the xperseguers OIDC extension, and core MFA still covers the backend only. Score reflects free but extension-dependent SSO.

Core access control is one of TYPO3's strengths: backend user groups combine module access, table read/write rights, field-level 'exclude field' permissions, per-page owner/group/everybody permissions, database and file mounts that scope users to page and folder subtrees, and language restrictions. This gives field-level and content-instance control without extensions, suited to large multi-site intranets and public sector sites.

As self-hosted open source, TYPO3 carries no SOC 2 or ISO 27001 certification of its own; compliance depends on the chosen host and agency. The EU base, on-premise option and strong data control make GDPR compliance straightforward to achieve, and accessibility work targets WCAG 2.1, but there is no certified vendor-run environment. Below Drupal, whose ecosystem includes certified PaaS hosts such as Acquia.

A dedicated Security Team handles coordinated disclosure, publishes advisories with CVEs for core and extensions, and announces through an RSS feed, mailing list and Mastodon, with synchronized patch releases for v14 and v13 (14.3.7 and 13.4.35 on 8 September, 14.3.9 on 13 October 2026). Core advisory volume is high in 2026 (TYPO3-CORE-SA-2026-024 by 13 October, including missing authorization in lowlevel commands), and the paid bug bounty has been discontinued, so the score sits in the 'clean history with basic disclosure' band.

Fully self-hostable on any PHP stack (Composer, Docker/DDEV, on-premise, any cloud), with many specialised TYPO3 hosts and agencies in the DACH region offering managed hosting. There is no vendor SaaS or vendor-run PaaS, so buyers wanting a turnkey managed platform must pick a third party. Flexible and suited to regulated or sovereign hosting requirements.

There is no vendor uptime SLA or status page because there is no vendor-run service; uptime is owned by the customer or hosting partner. TYPO3 GmbH's commercial offer covers support and ELTS security patches, not availability. Lower than Drupal, which has large dedicated PaaS vendors offering 99.9 to 99.95 percent SLAs.

TYPO3 is built for large multi-site, multi-language installations in a single instance, with a caching framework (Redis, Memcached and database backends), static file caching extensions and standard horizontal scaling behind reverse proxies and CDNs. It runs large public sector, university and corporate estates in DACH, but scale is an implementation outcome with no documented vendor limits.

Content lives in a standard MariaDB, MySQL, PostgreSQL or SQLite database plus file storage, so ordinary backups apply, and core Import/Export (T3D) moves page trees between instances, now including site configurations in v14. There is no built-in scheduled backup, documented RTO/RPO or multi-region failover; that is the host's responsibility.

DDEV is the officially 'highly recommended' local environment with a native TYPO3 project type, and a v14 site is up in six commands using the core 'typo3 setup' CLI. v14 adds shell auto-completion for the typo3 command, Fluid cache warmup and template analysis commands. Near-production container parity, matching Drupal.

Composer projects version code, extensions, YAML site configuration and site sets in git, and v14 adds CLI commands for system configuration, route enhancers in site sets and site configurations in import/export, making environment setup more scriptable. Schema is declared in TCA code and applied by CLI, but there is no content migration tooling, environment aliasing or branch-per-PR content environment; preview environments depend on the host.

docs.typo3.org is versioned per release, with the v14 changelog documenting every Feature, Breaking, Deprecation and Important change per minor release, and extension manuals rendered in the same system. Depth for PHP developers is strong, but there is no interactive API playground, headless and frontend framework guides live in community extension docs, and a fair amount of community material is German-language only.

TYPO3 is a PHP platform; core backend JavaScript is TypeScript and v14 adds XSD-based autocomplete for Fluid components, but there are no official types for content consumers and no type generation from the content model. Headless frontends rely on nuxt-typo3 or hand-written types. Comparable to Drupal.

TYPO3 ships on a fixed, published cycle: 14.0 (2025-11-25), 14.1 (2026-01-20), 14.2 (2026-03-31) and 14.3 LTS (2026-04-21) all landed on their announced dates, followed by roughly monthly patch and security releases on both the v14 and v13 LTS branches (14.3.9 and 13.4.36 in October 2026). The rhythm is predictable and both supported branches are maintained in parallel. Not higher because feature work is concentrated in the four sprint releases per major, with the LTS phase limited to fixes.

The core changelog on docs.typo3.org is one of the best structured in open-source CMS: every version gets separate Breaking, Feature, Deprecation and Important entries, each a standalone document with description, impact, affected installations and migration steps. Security releases are paired with dated TYPO3-CORE-SA advisories, and get.typo3.org exposes a machine-readable release API with release type and checksums. Not higher because the per-change documents are developer-facing and there is no consolidated editor-friendly release summary in core docs.

typo3.org publishes a development roadmap per major with dated milestones and a stated focus per sprint release, driven by a published CMS Product Strategy, and the Association runs member polls that fund community budget ideas. The v14 plan was delivered to the day. Not higher because no v15 roadmap was published as of this run (the public roadmap page still tops out at v14) and there is no feature-level voting portal.

Breaking changes are confined to the x.0 release of each major, deprecations are logged in the minor releases before removal, and every change carries a migration note. The core Extension Scanner flags deprecated API usage in installed extensions and the community TYPO3 Rector project automates much of the code migration. LTS windows are long: v13 is maintained until end of 2027 with ELTS from TYPO3 GmbH to 2030, v12 ELTS runs to 2030. Not higher because majors still arrive every 18 months and extension compatibility often lags each upgrade.

The GitHub mirror shows about 1.2K stars and 700 forks, but core development runs on Gerrit and GitLab rather than GitHub, so stars understate the base. Packagist is the better signal: typo3/cms-core has about 14.7M total installs and roughly 495K a month. The community is large in Germany, Austria and Switzerland and thin elsewhere, well below Drupal and WordPress.

Engagement is organised and steady: the October 2026 calendar lists a Community Sprint in Duesseldorf, an on-site certification day, agenturConnect and a presence at Open Source CMS 26 in Utrecht, and a Community Expansion Committee now funds outreach beyond DACH (a European Open Source Academy partnership from November 2026, a new community in Burundi). Members are voting on a new governance structure and budget ideas are chosen by member vote. Not higher because participation is still concentrated in a German-speaking core and English-language forum activity is modest.

TYPO3 GmbH runs a formal partner program with three tracks (Solution Partners for agencies, Consultant Partners for freelancers and trainers, Technology Partners for hosting and integrations) plus a tiered Association member directory. The listed agencies are established enterprise specialists such as 3m5., +Pluswerk, in2code and FGTCLB. Not higher because the network is heavily German and DACH-based, with no global SIs anchoring it.

Agency blogs (NITSAN/T3Planet, MaxServ, Netresearch, wacon) cover each major release with roadmaps and upgrade guides, and the official docs are extensive. Much of the independent content is in German, and international course coverage on Udemy or Pluralsight is thin next to Drupal or WordPress. Score inferred from search results rather than a content count.

A formal certification program exists (integrator, developer, editor and consultant certifications, with on-site exam days at community events), and the DACH market has a deep pool of TYPO3 agencies and developers. Outside German-speaking Europe and the Netherlands, experienced TYPO3 talent is scarce, which is a real constraint for international buyers. Not scored from job-posting counts.

TYPO3 has a large installed base in DACH public sector, universities and mid-to-large enterprise, v14 LTS shipped a modernised editor backend, and typo3.org keeps publishing agency case studies such as the Gerresheimer relaunch by KM2. No published customer counts, new-logo growth or rising review volume were found; G2 holds only 35 reviews. A mature, stable installed base rather than an expanding one.

The TYPO3 Association is a member-funded non-profit with a 2026 budget of about EUR 1M (about EUR 257K for product development, EUR 451K for innovation, events and education), and its wholly owned TYPO3 GmbH earns revenue from ELTS, certification and partner programs. Governance is transparent, with a Board and a Business Control Committee. Not higher because the budget is small next to commercially backed peers and depends on membership fees in one region.

TYPO3 positions as the licence-free enterprise open-source CMS for multisite and multilingual estates, with long LTS and ELTS as a stability argument, and that holds up in its DACH home market. It has no Gartner or Forrester recognition and little visibility in English-language buyer shortlists, and G2 comparisons rate it well below Umbraco on ease of use.

G2 rates TYPO3 3.9/5 on only 35 reviews and Capterra matches at 3.9/5 on 25 reviews, putting it in the lowest band of the rubric. Reviewers praise the modular design, security and open-source base and fault the steep learning curve, ease of use (Capterra 3.2) and the time needed for implementation and maintenance. Low review volume limits confidence either way.

TYPO3 v14 LTS is free GPL software with no license tiers, and the only vendor-sold product tied to the version lifecycle, TYPO3 GmbH's ELTS, is published per version with fixed terms and per-project annual prices. Third-party managed hosting is publicly priced (mittwald from 13 EUR/month). Not higher because agency project pricing, where most of the real spend sits, is quote-based.

No per-seat, per-API-call or traffic metering on the software; unlimited editors, sites and languages in one installation. The only recurring vendor charge is optional ELTS, a flat per-project annual fee for teams that stay on an expired version. Slightly below Joomla because each LTS's three-year free window ends in either an upgrade project or a roughly 3,200 EUR/year ELTS fee per project.

Every core feature (workspaces, multi-site, multilingual, permissions, scheduler, forms, SEO basics) ships free in the single GPL distribution; there is no enterprise edition. The JSON content API comes from the free community `headless` extension on TER rather than core, and paid gating exists only for ELTS on expired versions, a lifecycle service rather than a feature lock.

No vendor contract is required to run TYPO3; hosting and agency contracts are independent and switchable. ELTS is bought per project per year through My TYPO3 with no multi-year commitment, and Association members get discounts. Not higher because ELTS is annual-only.

The full product is free forever with no commercial-use or content limits. There is no official free hosted sandbox like launch.joomla.org, so trying it means a local DDEV install or a hosting trial (mittwald offers a free start). Not higher because the Composer-based install is heavier for hobbyists than one-click shared-hosting CMSs.

A local install takes minutes with the documented six DDEV commands, and site sets and frontend presets introduced in v13 shorten initial site setup. Getting a real site working still means learning TypoScript, Fluid templates, site configuration and backend layouts, which typically takes days for developers new to TYPO3. Comparable to or slightly below Drupal and Joomla.

German agency pricing guides put a basic corporate TYPO3 site from about 6,500 EUR and typical multilingual sites with integrations at 12,000 to 25,000 EUR, reaching six figures for portals, which implies weeks for simple sites and several months for enterprise builds. TYPO3 projects are usually agency-led with multisite, multilingual and ERP/PIM interfaces, so timelines run on the longer side of traditional CMS norms.

TYPO3 requires platform-specific knowledge (TypoScript, Fluid, Extbase, TCA) that general PHP developers do not have, and the talent pool is concentrated in Germany, Austria and Switzerland. German freelance TYPO3 day rates of roughly 750 to 810 EUR sit well above the national web-developer average, and buyers outside DACH face a thin agency market. Comparable to Joomla's scarcity problem, below Drupal's larger global pool.

There is no vendor-hosted edition, so all TYPO3 hosting is third party. A healthy German managed-hosting market exists, with mittwald plans at 13, 21 and 169 EUR/month, but Composer-based deployments and larger multisite installs push most production sites onto managed VPS or cloud tiers. Below Joomla because cheap generic shared hosting is a poorer fit for modern Composer installs.

Self-hosted ownership means applying roughly monthly patch releases (14.3.5 through 14.3.9 between July and October 2026) plus extension updates, backups and monitoring. Each LTS gets three years of free support, so teams face a major upgrade (v13 to v14 before 2027) or a paid ELTS contract on a fixed cycle. Managed hosts and agency maintenance plans (from ~79 EUR/month) reduce but do not remove this burden.

Content lives in a standard MySQL/MariaDB or PostgreSQL database under a GPL license, so there is no commercial vendor lock-in. Exit cost is still moderate: content is shaped by TYPO3-specific structures (tt_content records, FlexForm XML, TCA-defined tables, TypoScript-driven rendering) and there is no mature one-click migration path to other CMSs.

TYPO3 v14 still asks developers to learn many layered, TYPO3-specific concepts: the page tree and site configuration, TypoScript, page and user TSconfig, the TCA (Table Configuration Array), Fluid templates and components, Extbase, backend layouts, workspaces and site sets. v14 tidies some of this (route enhancers can ship in site sets, ext_tables.php is deprecated in 14.3) but removes none of the core layers. More concepts to learn than Drupal or Joomla, so it stays at the low end of the re-learning band.

The v14 Getting Started tutorial now opens with a Quickstart 'From zero to a basic website in TYPO3 v14' that installs core, adds the default Camino theme, creates a site and walks through adding content, subpages and theme settings, alongside prerequisites, concepts, installation, troubleshooting and next steps. TYPO3 GmbH runs four certification tracks (Editor, Integrator, Developer, Consultant) with mock exams. There is still no interactive sandbox or in-backend onboarding tour, so it stays in the docs-led band.

The base is mainstream PHP: Composer, PSR-15 middleware, PSR-14 events, Symfony components and Doctrine DBAL. Rendering and configuration still run through TypoScript, a proprietary configuration language, and Fluid templates; v14 improves Fluid tooling (component autocomplete via XSD, f:render.contentArea and f:render.record ViewHelpers) without changing the paradigm. Core ships no JSON content API for React or Next.js; that needs the TER `headless` extension (friendsoftypo3/headless), whose companion frontend is Vue/Nuxt.

v14.1 added Camino, an official default theme (typo3/theme-camino) that, with the base distribution and `typo3 setup --create-site`, yields a working themed site with a main menu and configurable site settings; the docs show how to copy or extend it in a site package, and the Site Package Builder at get.typo3.org still generates a theme extension. For decoupled builds there is no vendor starter for Next.js, Astro or SvelteKit; the only maintained frontend kit is the community nuxt-typo3. Good coupled starting point, weak headless one.

Local setup is a handful of DDEV commands ending in a non-interactive `typo3 setup --create-site` call with database credentials pre-filled, and with Camino the result is a working site whose colors and options are edited as site settings in the Sites > Setup module. Anything custom still means a site package with TypoScript, page TSconfig, backend layouts and config/system/settings.php, each with its own syntax; v14.2 adds CLI commands for system configuration but not a smaller surface. Faster to a first page than v13, still heavy next to modern CMSs.

Content types are modeled in TCA PHP arrays, core creates missing database columns from TCA, and the Analyze Database Structure tool and CLI apply schema changes, so evolution is manageable; v14 adds type-specific TCAdefaults, labels and titles and a report on content type usage. Defining content elements in raw TCA remains verbose; the Content Blocks extension (friendsoftypo3/content-blocks, YAML definitions and a kickstart command) simplifies it but is still an extension maintained by the Content Types Team, not core. Changing field types on live data still relies on upgrade wizards or custom migrations.

In a coupled build preview needs no frontend work, and v14 extends it: workspace preview links now cover all records, the Page module content preview was improved, the frontend preview has a QR code button, and 14.3 adds an editRecord ViewHelper argument for contextual editing links from the frontend. Full inline frontend editing is still not in core. For headless builds, preview of drafts and workspaces has to be wired through the `headless` extension and a custom frontend.

Productive TYPO3 work needs TypoScript, TSconfig, TCA and Extbase knowledge that does not transfer from other platforms, and TYPO3 GmbH sells separate Integrator and Developer certifications for exactly that split. Certification is not technically required, but TYPO3 says certified staff form part of the quality criteria in many tenders, and the skill pool is concentrated in German-speaking agencies. The Camino theme helps a generalist get a basic site up, but not build a custom one.

An experienced TYPO3 developer can build and run a small coupled site alone on standard PHP hosting. Typical projects split work between an integrator (TypoScript, templates, site package) and an extension developer, plus whoever applies the monthly patch releases, since there is no vendor-hosted option. Larger multisite builds need a full agency team, so this sits below Drupal-style solo builds.

Once built, editors self-serve well: they create pages in the page tree, place and reorder content elements, manage files, translate, and stage changes in workspaces, all in core, and v14.2 adds a guided new page creation wizard while theme options can be changed as site settings without code. New content element types, new page layouts and TypoScript-driven behavior still need a developer or integrator. Comparable to Drupal for day-to-day editor autonomy.

Major upgrades follow a fixed cadence (v13.0 Jan 2024 to v13.4 LTS Oct 2024; v14.0 Nov 2025 to v14.3 LTS Apr 2026) and every breaking change, deprecation and 'Important' note is catalogued in the official Core ChangeLog, with the Install Tool's upgrade wizards, extension scanner and database analyzer plus the community TYPO3 Rector project (3,000+ commits) automating much of the code migration. Still, each LTS jump means composer constraint bumps, TCA and TypoScript migrations (v13.4 deprecates $GLOBALS['TSFE'], INCLUDE_TYPOSCRIPT, plugin sub types), schema compares and waiting on TER extension compatibility. Comparable to Drupal: well tooled, but a real project, not zero-touch.

The TYPO3 Security Team publishes clear TYPO3-CORE-SA and TYPO3-EXT-SA advisories with an RSS feed, and security releases ship simultaneously across all supported branches on a published Tuesday schedule, with out-of-band releases when urgent. 2026 has been busy (TYPO3-CORE-SA-2026-024 by 13 Oct 2026, two core advisories on 8 Sept, and a 25 Aug batch of extension advisories covering solr, powermail, femanager and sf_event_mgt), and self-hosted teams must apply each patch themselves via composer and deploy, plus track extension advisories separately. Strong process, manual application keeps it below SaaS.

Each LTS gets three years of free official support (v13 security support until 31 Oct 2027; v12 free support ended 30 Apr 2026) and the roadmap is published years ahead, giving long, predictable notice. Teams that cannot move on schedule can buy ELTS from TYPO3 GmbH for up to three more years (four for partners), e.g. v12 to 2030-04-30, so the vendor's timeline is not truly forced, just paid to escape. Still a mandatory major every LTS cycle for anyone on free support, so not higher.

Composer manages a sizeable PHP stack (Symfony components raised to 7.4 LTS in 13.4.x, Doctrine DBAL, Fluid, CKEditor 5) on top of PHP, a database (MySQL/MariaDB/PostgreSQL/SQLite), a web server and image processing (ImageMagick/GraphicsMagick), and real sites add TER extensions with their own dependency trees. The core team now ships dedicated third-party dependency releases (v14.3.8, 9 Oct 2026), which helps, but the Aug 2026 extension advisory batch shows the extension layer is where much of the risk sits. Slightly better curated than Drupal's contrib sprawl, still a full self-hosted stack.

Core ships a Reports module with a status report (environment, PHP, database, security warnings, Scheduler health), the System Log and the frontend Admin Panel for per-request debugging, which covers basic health checks. There is no native APM, uptime alerting or observability dashboard; production monitoring comes from the hosting provider or external tooling. Sits in the self-hosted 30 to 45 band, slightly above bare minimum.

Core includes more hygiene tooling than most open-source peers: EXT:linkvalidator scans for broken internal and external links and can run on the Scheduler, the Redirects module tracks hits and auto-creates redirects on slug changes, the Recycler restores deleted records, and Workspaces adds staged review. There is still no content health dashboard, orphan detection or content-expiry workflow beyond start/stop dates, so governance leans on editorial discipline.

The core caching framework (page cache with cache tags, pluggable Redis/Memcached/database backends) gives good performance out of the box for cacheable pages, and static-file caching or a reverse proxy can be added. Uncached plugins, Extbase queries, TypoScript complexity and cache-tag header size still need developer tuning (13.4.x had to fix 'Premature end of script headers due to X-TYPO3-Cache-Tags'). Typical self-hosted 40 to 60 band, level with Drupal.

There is no vendor ticket support for TYPO3 core: TYPO3 GmbH sells ELTS, certifications, trainings and a partner integrations hub, while day-to-day support comes from contracted agencies and hosting partners, concentrated in Germany, Austria and Switzerland. Quality depends entirely on the agency contract, and the only 'official vendor support' is ELTS for out-of-free-support versions. Matches the rubric's 40 to 60 band for support that requires a paid arrangement.

The TYPO3 Slack workspace is the community's main channel, reachable via my.typo3.org, with core developers and the security team active in it, and docs.typo3.org is comprehensive and versioned. Much of the discussion, meetups and agency content is German-language and DACH-centred, and the English Stack Overflow footprint is far smaller than Drupal's or WordPress's, so non-German teams find less help. Active and team-staffed, below Drupal's breadth.

LTS branches receive monthly maintenance releases on a published Tuesday schedule (v13.4.36 on 9 Oct 2026, roughly 36 releases in two years), and regressions are fixed fast: v13.4.4 followed 13.4.3 within a week, and 13.4.7 and 13.4.8 followed 13.4.6 within a week. Non-critical bugs depend on volunteer contributors in Forge and Gerrit and there is no SLA without ELTS or an agency contract. Predictable and transparent, above Drupal's long-tail queue.

Editors build pages in the core Page module by adding, copying and drag-ordering content elements inside developer-defined backend layouts. v14 added context-aware editing in the layout module. A visual editor exists as an extension, but new grid layouts (backend layouts, containers) still need a developer, so marketers edit and assemble pages rather than design new layouts.

No campaign object, calendar or campaign analytics in core. Campaign timing relies on per-record start and stop times and on workspaces with scheduled publishing. Coordination across channels is out of scope.

Core ships the SEO extension (meta title and description, robots, canonical, Open Graph and Twitter card fields, hreflang, XML sitemap) and the redirects module with integrity checks. Schema.org structured data and Yoast-style content analysis come from well-maintained v14 extensions.

The core Form Framework gives editors a drag-and-drop form editor with finishers (email, redirect, save to database), and v14 added database storage for submissions. CTA management, UTM handling and conversion tracking require extensions such as LUX or tag integrations.

Core targeting is limited to frontend user group visibility on pages and content elements. Behavioral personalization comes from LUX (v14 compatible) or the marketing-automation and Mautic extensions, which only support v13. No native segmentation or real-time targeting.

No experimentation in core. The community A/B extensions found are not released for v14 (werkraummedia/abtest supports v13.4, dmk/mkabtesting v11.5). Testing in practice means an external tool injected via tag.

Editors can copy whole page branches, drag and reorder content, reuse records via references, and stage changes in workspaces with preview. v14 added recently used records in wizards and better page tree filtering. No template cloning gallery or true inline frontend editing in core.

TYPO3 is web-first: Fluid templates render HTML, with RSS/XML via page types. A JSON content API needs the community headless extension, whose v14 line (v5) is still a release candidate. No native email, social or push channels.

Core has a configurable backend dashboard but no content analytics. Matomo reports can be shown in dashboard widgets through a v14 extension, and LUX adds lead analytics. GA4 is tag-based through cookie-consent extensions.

Brand control comes from developer-owned Fluid templates and site packages: editors cannot change markup, and Page TSconfig can restrict which content elements and fields each backend group may use per page tree. There is no design-token editor or brand guardrail UI.

Core SEO fields include Open Graph and Twitter card title, description and image per page. Share buttons come from small extensions; there is no push-to-social or social scheduling.

The File Abstraction Layer offers a central file list with metadata, categories, image crop variants per usage and reference tracking. No rights management or video transcoding, and the Bynder connector has no v14 release.

Localization is a core strength: per-site language configuration, fallback chains, connected or free translation modes, and a modernized translation workflow in v14. DeepL integration and cookie-consent extensions handle machine translation and regional consent. No transcreation workflow or market-level campaign scheduling.

Core ships outgoing webhooks and incoming reactions, which give event triggers. Pre-built connectors are uneven: HubSpot form extensions support v14, while Salesforce form connectors and the Mautic extension lag behind (v11 to v13).

No product model in core; product content means generic records or a commerce extension. Aimeos (v14 compatible) and extcode/cart supply product, variant and attribute modeling inside TYPO3. Case studies show complex B2B product catalogs built on TYPO3 by agencies.

Core has no merchandising. Aimeos brings categories, product lists and promotions when installed; otherwise cross-sell and spotlights are curated manually with record relations.

No maintained connectors for Shopify, commercetools or SFCC. The Shopware connectors found target TYPO3 9 to 10. Integration with an external commerce engine is custom agency work.

Editorial pages can embed Aimeos or cart product plugins alongside content elements, so buying guides are possible, but shoppable inline product references are not a first-class authoring pattern.

When Aimeos or cart runs inside TYPO3, cart and checkout templates are Fluid and banners can be placed as content, but this is template work rather than editor-managed injection.

Order emails and confirmation pages belong to the commerce extension's templates. No event-tied post-purchase content management.

Frontend user groups gate pages, content and files per account group, and protected file delivery is available for v14. Aimeos offers B2B features. Agencies use TYPO3 for B2B product configurators, but quote flows are custom.

Core indexed search lacks facets. Apache Solr for TYPO3 (v14 release) and ke_search add faceting, synonyms and blended page, record and file results; search landing pages are built as regular pages.

Promo banners can be scheduled with start and stop times on any content element and targeted per site or language. No countdowns, promo codes or channel targeting in core.

One installation serves many sites with their own domains and languages, so storefront-specific editorial content is natural. Sharing product content across storefronts depends on the commerce extension (Aimeos supports multi-site).

Image galleries, crop variants and YouTube or Vimeo embeds in core. No 360-degree, AR or hotspot support without extensions.

Multi-author content via frontend user registration is possible, and the Aimeos distribution advertises marketplace use, but there is no seller profile or moderation tooling in core.

Strong core localization carries over to product records and editorial pages, with per-site regional content. Currency awareness and regulatory content depend on the commerce extension.

No link between content engagement and revenue in core. Conversion data lives in Matomo, GA4 or the commerce extension.

Frontend user groups restrict visibility per page, per content element and, with fal-protect, per file or folder. Backend groups control tables, fields, page tree mounts and languages. SAML and OIDC single sign-on extensions support v14; the popular LDAP extension does not yet.

Workspaces provide staged review and approval, every record has history and undo, and system categories give taxonomy. Lifecycle tooling is limited to end dates; no review reminders or knowledge base templates.

Staff portals are built from frontend login, the news extension and custom templates, as in hospital and laboratory case studies that serve staff alongside patients. No portal framework, notifications or personalized dashboards for frontend users.

News publishing with group-targeted visibility is easy; read receipts, acknowledgment tracking and mandatory-read workflows are absent.

Directories can be built as frontend user lists or address records; no org chart or HR integration.

Documents publish through the file list with metadata and access control, and pages go through workspace approval with history. Files are not versioned natively and there is no acknowledgment or expiry reminder.

Onboarding pages can be gated by group, but there are no journeys, checklists or HR triggers.

Solr for TYPO3 with Tika indexes pages, records and documents with facets and access-aware results. Federation with SharePoint or Confluence is custom.

Responsive frontends are standard; no native app, offline mode or push notifications.

No LMS integration or course tracking; training content is hosted as pages.

Comments with replies and votes, and polls, are available as v14 extensions. No forums, recognition or community spaces.

Core webhooks can post to Teams or Slack endpoints, but there are no maintained v14 extensions for Teams, Slack or Google Workspace cards or bots.

End dates auto-unpublish content and the link validator finds broken links; there are no review dates, stale-content flags or ownership assignment.

Matomo dashboard widgets show page views in the backend; no department-level analytics or failed-search reporting in core (Solr has its own statistics).

Multi-site is core: one installation hosts many sites with their own page trees, domains, languages and settings, and backend users can be confined to their tree. Sites share one database and codebase, so this is silo-style isolation rather than true multi-tenancy.

Site sets are reusable configuration bundles shared across sites, content elements and templates come from shared site packages, records can be referenced across trees, and FAL storages are shared. APCOA uses shared content libraries and a central media library across countries.

Central administrators manage all backend users and groups, enforce field and element restrictions via TSconfig, and define mandatory templates and page structures per site, as in the APCOA rollout. There is no cross-brand policy dashboard.

GPL with no per-site or per-brand licence; additional sites in one installation add hosting and implementation cost only.

Site settings, editable in the v14 settings editor, can drive colors, logos and template variants per site on a shared component base. Theming depth depends on how the site package exposes settings.

Each site defines its own languages, and backend groups can be limited to specific languages, so translators per brand and market are possible. Workflow stages are workspace-wide rather than brand-aware.

No portfolio analytics; each site is measured in Matomo or GA4 separately.

Administrators can create several custom workspaces, each with its own mount points, members and review stages, which gives brand-level approval chains. Auditing is via core logs and record history rather than a central workflow console.

Central content can be reused on other sites via record references and shortcut pages, which update everywhere. There is no syndication with local override points or push notifications.

Cookie consent extensions can be configured per site, and accessibility is achieved per project (APCOA reached WCAG 2.2 AA). No publishing guardrails for compliance rules.

Site packages and site sets are Composer packages with dependencies, so a core design system can be versioned centrally and extended per brand. Update propagation is a deployment step rather than a platform feature.

One central user base with groups scoped by page tree and language gives a central admin plus autonomous brand teams; cross-site backend login and SSO come from extensions.

Content types defined in TCA are shared across all sites, and TSconfig can hide fields or elements per site tree, giving limited per-brand variation without forking. Per-brand extensions of a base model need custom record types.

No executive or freshness reporting across sites in core or a common extension.

TYPO3 v14 core keeps privacy-oriented defaults: IP addresses stored through the core API are masked by default ([SYS][ipAnonymization] = 1, last IPv4 byte / IPv6 interface ID) and anonymization tasks can scrub stored logs (v14 moved that task's configuration out of $GLOBALS, Deprecation #107562). Because TYPO3 is self-hosted GPL software, neither the TYPO3 Association nor TYPO3 GmbH acts as a data processor, so there is no DPA, sub-processor list or SCCs; consent banners and data-subject request tooling come from TER extensions or the operator. Strong EU-centric project culture lifts it to the top of the no-DPA band, the absence of any platform DPA keeps it below 55.

No BAA is available from the TYPO3 Association or TYPO3 GmbH, and there is no healthcare or HIPAA guidance in the official documentation. The user and agency base is concentrated in DACH, so US healthcare deployments are rare and any HIPAA posture depends entirely on the hosting provider and implementation. Slightly below Drupal, which has a large US host offering a standard BAA.

No FedRAMP, IRAP, C5, PCI DSS or HITRUST coverage exists at the software or project level, and core has no CCPA, PIPEDA or LGPD specific tooling. TYPO3 is widely used by German public bodies, which drives attention to BITV and EU accessibility rules, and paid ELTS for v10 to v12 helps operators keep supported, patched software for NIS2 style obligations, but these are not regulatory certifications. Effectively GDPR-oriented only.

SOC 2 is an attestation for service organizations, and TYPO3 is open-source software with no vendor-run hosted service, so no SOC 2 report exists or applies. Operators must rely on their hosting provider or agency for SOC 2 coverage. Scored at the open-source self-hosted floor per scoring guidance.

No ISO 27001 or ISO 27018 certificate is published for TYPO3 CMS, the TYPO3 Association or TYPO3 GmbH. The TYPO3 Security Team runs a mature process (coordinated least-disclosure policy, [email protected] intake, bug bounty program, regular TYPO3-CORE-SA and TYPO3-EXT-SA bulletins), which is good governance but not a certified ISMS.

No PCI DSS, CSA STAR, ISO 42001, C5, ENS or Cyber Essentials certification applies to TYPO3 CMS. TYPO3 GmbH's certification program certifies people (integrators, developers, editors), not the product, so it earns no credit here. Security governance via a dedicated team and paid ELTS is real but is not a certification.

As self-hosted software with no vendor SaaS, TYPO3 lets operators place all content and personal data in any jurisdiction or on-premise, with no vendor data flows or sub-processors, which suits EU sovereignty requirements common among its DACH public sector users. There is no contractual residency guarantee from any vendor, and compliant residency depends on the operator's hosting and CDN choices, keeping it from the top band.

Core provides record deletion with a recycler, IP anonymization tasks for stored log data and scheduled table garbage collection, and the operator owns the database so a full export is always possible. There is no self-service data subject erasure portal, no automated retention policy across content and form data in core, and structured content export beyond database dumps relies on extensions such as the TER headless extension. Post-termination retention is not applicable in a self-hosted model and is operator-defined.

Core records backend user actions in the system log (Log backend module) and keeps per-record change history with user attribution, the PSR-3 logging framework ships writers for file, database and rsyslog targets so events can be forwarded to a SIEM, and v14 adds a 'Latest backend logins' dashboard widget and a logged-in users filter in the Backend Users module. There is no native SIEM push integration, no built-in compliance reporting and retention is operator-configured, so it stays in the basic-to-moderate band alongside Drupal.

TYPO3 has a dedicated Accessibility Team that cites WCAG, ATAG and BITV, but its page still states the authoring interface 'is not accessible yet'. v14 shipped incremental backend work (an accessible combobox pattern, modals migrated to the native dialog element for better focus handling), yet there is no WCAG 2.1 AA conformance claim for the v14 backend, so it remains below Drupal's documented Claro conformance at the upper edge of the no-commitment band.

No VPAT, ACR, Section 508 statement or ATAG assessment is published for TYPO3 CMS. The only official accessibility material is the community team page, which describes goals rather than conformance, so procurement teams have nothing formal to file. Slightly above the floor because the team page and its public statement of gaps exist.

TYPO3 core ships no AI by policy (the TYPO3 v14 AI article commits to interfaces, not built-in AI), so generation comes from TER extensions. The most mature is AutoDudes AI Suite (extension ai_suite, 14.6.2 October 2026, about 19K installs), which generates whole content elements in the new content element wizard, reworks copy in a CKEditor AI plugin, generates complete page trees from a prompt, and applies reusable prompt templates and global instructions per page tree as a house-style control. Above the plugin-only band because the extension is mature and governed, but it is a commercial third-party add-on and nothing ships in core.

With the AI Suite extension, editors generate images (GPT Image, Midjourney, Flux) straight into FAL as real sys_file records from image fields and the file list, and alt text, title and description can be generated per file, per folder in bulk, or automatically on upload with OpenAI Vision or Mittwald's Ministral vision model, queued for review. Core's file list and media handling has no AI. Integrated into the asset workflow, but only through a paid third-party extension, with no smart cropping or video AI.

AI Suite extends TYPO3's localization wizard to translate single records, whole pages, file metadata and FlexForm fields through DeepL, Google Translate, OpenAI, Anthropic or Mittwald models, with DeepL glossary sync and optional translate-on-save into every site language (capped per save). Netresearch's nr_llm also exposes a translation feature service that other extensions can call, and TER DeepL connectors are widely used in DACH projects. Core localization has no machine translation and there is no translation quality scoring, so this stays in the basic-MT band.

Core EXT:seo provides the SEO title, description and Open Graph fields but generates nothing. AI Suite fills them (SEO title, description, abstract, Open Graph and Twitter cards) for a single page or in bulk over a subtree, generates image alt text, and adds per-page SEO audits with a score tile in the page module and a dashboard widget. That covers most of the 70+ criteria, but only through one commercial third-party extension, so it is scored as extension-only partial automation.

AI Suite adds a WorkflowManager for mass metadata and translation runs, an asynchronous TaskEngine whose results come back as reviewable suggestions, auto alt text on upload, translate-on-save, and CLI and Scheduler commands for headless pipelines; nr_llm adds prepared AI Tasks that editors can run from a dedicated module. These are useful assists, but all come from third-party extensions, and there is no AI tagging, duplicate detection, smart scheduling or lifecycle automation in core.

Agentic options are still third-party and pre-1.0, but they now carry real governance. Netresearch nr_llm (v0.40.0, October 2026) runs an agent tool loop with built-in and MCP-imported tools, pauses runs for approval or input in an Agent runs inbox with a run timeline, and lets editors only run prepared tasks and approve suspended runs. AutoDudes ChEddi (0.4.0, October 2026, still marked beta) is a backend chat drawer that acts on pages, content, translations and metadata, with confirmation on writes and workspace drafts by default. No core agent framework or named production agent, so it sits at the low end of the early/beta band.

AI Suite's audit module covers question coverage for AI search (GEO), content gap, topic clusters and competitor analysis, stored per page and language. These run on the AutoDudes audit service per page rather than in a site-wide intelligence dashboard with performance or ROI data, and core offers only standard reports. Just above the floor, for extension-provided per-page analysis.

AI Suite runs SEO and WCAG accessibility audits per page and language, launched from the page-tree context menu, with a page-module score tile, a dashboard widget and CSV export, and its Easy Language assistant rewrites copy for accessibility. There is no brand-voice compliance or duplicate and thin-content detection, audits are page by page rather than at portfolio scale, and core has none of it. Below the band for one dimension done well at scale.

Core ships only keyword indexed_search. The de facto search extension, Apache Solr for TYPO3 (EXT:solr, 12.1 and 13.1), offers vector search that calls a connected LLM to generate embeddings at index and query time, and dkd sells Solr RAG as a partner add-on; nr_llm adds an embeddings service with a reranker. SEAL Search AI is still a proof of concept. Semantic search exists through extensions and a Solr backend, not natively.

TYPO3 has no personalization engine in core beyond user and group based content access, and no ML personalization extension appeared in TER or vendor sources. Recommendation extensions such as semantic_suggestion_solr give vector-based related content, not audience scoring or predictive segments. Minimal.

There is no official TYPO3 MCP server (the core AI initiative is only 'considering' MCP), but several community servers are maintained: in2code in2mcp (2.2.0, September 2026, TYPO3 13.4 and 14.3, official MCP SDK, read and write tools for pages, content, records and files within the backend user's permissions), hauptsacheNet's typo3-mcp-server (routes every AI edit through workspaces, with OAuth), ai_suite_mcp (beta) and T3Planet's AI Foundation MCP with OAuth 2.1. Adoption is small (in2mcp has about 120 installs) and none is vendor-backed, so it sits at the top of the beta/community band.

Netresearch nr_llm (v0.40.0, about 48K installs) configures providers once for every AI extension on a site, with encrypted keys and support for OpenAI, Azure OpenAI, Anthropic, Gemini, Mistral and local Ollama, so a self-hosted install can keep all inference on premises. AI Suite also supports BYOK for OpenAI, Anthropic, IONOS and Mittwald model hubs, DeepL and Midjourney with per-group key overrides and a GDPR mode, though its requests still pass through the AutoDudes server. Broad choice and real residency options, held below 75 because it is all extension-level and pre-1.0.

Core offers PSR-14 events, DataHandler hooks and a clean TCA schema that MCP servers expose (in2mcp get_schema), but no content delivery API; JSON output needs the TER headless extension. nr_llm gives extension developers an LlmServiceManager with streaming, tool calling, custom providers and injectable translation, vision, embedding and completion services, with a documented @api stability promise and a five-minute integration guide. There are no LangChain or LlamaIndex connectors or RAG delivery endpoints, so this stays at the top of the standard-API band.

Governance is extension-provided but now fairly deep. AI Suite gates every feature and model through backend-group permissions, returns bulk results as suggestions, lists everything an AI feature wrote, publishes an EU AI Act 'About this AI system' page and offers a GDPR mode. nr_llm adds isolation controls (trust zones, prompt injection scanning, audit), privacy retention settings, approval pauses on agent tool calls, and opens nothing to editors by default; ChEddi and the hauptsacheNet MCP server route AI writes into workspaces as drafts. No hallucination scoring or IP indemnification and nothing in core, so it stays below 50.

nr_llm now ships a usage analytics module (30-day cost, requests and tokens, KPI tiles, cost and request trends over a chosen date range), usage columns in its list views, TYPO3 dashboard widgets for AI usage and cost, and per-user AI budgets enforced before each call. AI Suite separately reports usage per month and per model and shows remaining credits in the toolbar. That reaches basic usage and cost visibility with per-user caps, but only for traffic routed through each extension, with no quality trend monitoring.