Kentico Xperience 13

Page types are defined in the Page types application field editor with a broad set of data types (text, long text, integer, decimal, date/time, boolean, GUID, file, attachments) and form controls, plus custom tables and module classes for non-page data. The continuous integration feature serializes page types to files in the repository, which is a partial schema-in-source path, but types are still authored in the UI and there are no union or polymorphic fields. Adequate enterprise modelling, not a modern schema-as-code system.

Named page relationships link pages to pages and can be read from either side through the API, and linked pages place one page in several tree locations. Reverse lookups and many-to-many traversal need .NET code against the relationship API rather than a query language, and references are page-to-page only. Sits just inside the limited band because traversal is developer work.

Page builder composition uses sections, editable areas, zones and widgets with typed properties, and Refresh 9 added copy and paste of whole sections between pages. Structured pages keep content in fields, but rich text is stored as an HTML blob and widget nesting is limited to the section/zone model. Component support exists, portable structured rich text does not.

The field editor offers required, regular expression, min/max length and value range rules plus data type constraints, and custom form controls or validation rules can be coded in .NET. Validation is applied in the administration forms; API and REST writes rely on custom code to enforce the same rules. Standard built-in validation with code-level extensibility, no visual cross-field rule builder.

Pages under workflow get full version history with a compare view, rollback to any version and attribution of who changed what, objects such as templates and page types have their own object versioning, and deleted pages go to a recycle bin from which they can be restored. Version compare does not cover page builder widget content well and there is no branching or release mechanism. Solid adequate-plus history.

KX13 offers three taxonomy approaches: content tree placement with linked pages, hierarchical categories (global, site and personal) assignable via a Multiple categories selector field, and tags organised in tag groups. Refresh 12 added an external Azure OpenAI module that automatically selects categories for a page. Categories are reusable across page types and governed by permissions, but displaying or querying them on the live site requires custom MVC code and there are no synonyms or controlled-vocabulary governance workflows.

Because the admin renders the real MVC or ASP.NET Core site, Preview mode shows draft content as it will appear, including content in the current workflow step or with a future Publish from date, and the Page tab lets editors change page builder widget content in place on the actual rendering. Preview is per culture through the culture selector, but it lives inside the admin, structured fields are edited in a separate Content tab form, and forms cannot be submitted in preview. Good coupled preview with no headless story.

Rich text fields use a configurable WYSIWYG editor with toolbar customization, media and link insertion, and plugin support, and page builder has its own rich text component. Output is stored and delivered as HTML, with no portable AST, no custom marks and limited embedding of structured entries. Standard WYSIWYG band.

Media libraries and page attachments provide upload, folders, metadata, a built-in image editor, resize-on-upload and developer-defined responsive image filters, and Refresh 10 added SVG and WebP support. There is no focal point, no AVIF, no URL-based on-the-fly transform pipeline for modern formats (resizing of SVG and WebP via SizeConstraint is unsupported) and no usage tracking. Basic upload-and-serve with some resizing.

Content locking (check-in/check-out) prevents two editors from changing a page at once, but it is optional and only available for pages under workflow; otherwise edits are last-write-wins. Workflow steps carry comments, but there are no presence indicators, inline comments, @mentions or co-editing.

Basic and advanced workflows support custom steps, a graphical designer with conditional and multichoice branching, role and user-based step approval, email notifications, timeouts, and a full workflow history per page, and workflows are scoped by path, page type and culture. No due-date SLA management or modern task inbox, but the routing and audit trail meet the 70+ bar.

Every page has Publish from and Publish to fields plus a Redirect after unpublish target, and scheduling works together with workflow and versioning. There are no release bundles, no publishing calendar view and no atomic multi-item releases, though batch publishing exists in the Listing mode.

Sites are assigned cultures and each page has separate culture versions, with a site setting that falls back to the default culture when a translation is missing, culture-aware retrieval through IPageRetriever, per-culture preview and culture-scoped editing permissions. Localization is document-level only: individual fields cannot be marked shared or localized, and there are no multi-step fallback chains.

Global and per-site roles carry module, page type and page-level (ACL) permissions, UI personalization hides admin elements per role, and editing can be restricted per culture. Administration sign-in supports Windows AD, multi-factor authentication and custom external providers. There are no field-level permissions and no SCIM provisioning.

The REST service exposes pages and objects with GET/POST/PUT/DELETE in XML or JSON and supports where, orderby, columns and topn parameters, but it is disabled by default and doubles as the management API. There is no GraphQL and no separate delivery API. A generic data API rather than a purpose-built delivery API.

KX13 is self-hosted or partner-hosted; there is no vendor CDN. Media files can be stored in Azure Blob or Amazon S3 and served through Azure CDN by configuration, and output caching is available, but CDN purging on publish is custom work.

KX13 has no native outbound webhooks. Events are handled through .NET global event handlers and the Integration bus, whose outbound connectors are written in code, and the official Zapier modules have been archived. Comprehensive in-process events, but no signed, retried, logged HTTP webhooks.

KX13 is a coupled .NET platform where content is consumed by the MVC or ASP.NET Core site through the Xperience API; external channels use the generic REST service with no official client SDKs, and rich text is HTML. Below the traditional-CMS-with-API band because there are no SDKs and no delivery-specific endpoints.

Contact management builds first-party visitor profiles from tracked activities (page visits, form submissions, email interactions, purchases), and contact groups segment them with macro conditions alongside persona scoring; both are usable directly in widget personalization. Groups are recalculated in batch rather than in real time and there is no maintained external CDP connector. Native rule-based segmentation in the product, short of the 75+ bar.

Marketers create widget variants per condition (contact group, persona and other condition types) and preview them in the page builder, and developers can also personalize in MVC code. Personalization is limited to page builder widgets and new condition types must be coded, and it requires the Enterprise license. Native but narrower than full page-level variant management.

Page A/B tests split traffic across variants with included-traffic percentage, visitor targeting, conversion goals and a 'Chance to beat the original' statistical readout, and marketing emails have their own A/B testing. Page variants can differ only in page builder content and there is no multivariate testing. Genuine built-in experimentation, held below 70 by scope.

Algorithmic recommendations came only through the Recombee external module, which Kentico has archived as a read-only repository and which needs a separate Recombee subscription. Otherwise recommendations are editorial (related pages, categories). A frozen connector earns little.

Smart search ships Lucene.NET indexes for pages, custom tables and other objects with Lucene query syntax and search assistance features, and a native Azure Cognitive Search integration creates and maintains Azure indexes. The Algolia module is archived, faceting and relevance tuning are developer work and the Lucene version is old. Basic native search plus a native Azure option.

The E-commerce module covers products with options, variants, bundles and e-products, brands, collections and suppliers, cart and checkout APIs, payment methods, taxes, currencies, a rich discount engine (catalog, order, volume, buy X get Y, coupons, gift cards, free shipping), orders, customers and store reports. Checkout must be implemented by developers in the MVC site, and the module is frozen ahead of end of support.

No connectors for Shopify, commercetools, BigCommerce or SAP Commerce appear in the KX13 integration documentation; the platform assumes its own commerce module. External commerce means custom development against generic APIs.

Web analytics tracks page views, visits, conversions and campaigns with reports in the admin, and campaigns, email marketing and A/B tests have their own reporting. Data lives in SQL Server and performs poorly at high traffic, and there are no content lifecycle or author productivity metrics.

Because KX13 renders the site in the customer's MVC or ASP.NET Core code, GA4, Adobe Analytics or a tag manager are added by developers in the views; no first-party analytics connector is documented and the Zapier bridge is archived. Achievable, but only by building it.

One instance runs many sites, each with its own content tree, domains, cultures, settings and site roles, while page types, global roles, global categories and other global objects are shared across sites. Content reuse across sites is limited, so most sharing happens at the definition level rather than through shared content items.

Translation services are built in: Microsoft Translator and Google Translate for machine translation, an email-based human translation service using XLIFF export and import, translation submissions tracked in the admin, batch translation from the page listing, and an API for custom services. There are no maintained connectors to Phrase, Smartling or similar TMS and no translation memory.

Brands are modelled as sites with global versus site-specific roles, permissions and settings, giving organization-level control. There are no shared component libraries with brand overrides, cross-brand approval workflows or brand-level policy enforcement.

Media libraries give per-site folders, library-level permissions and file metadata, with external storage on Azure Blob or S3. There are no rights or expiry management, asset approvals, asset versioning or usage tracking, and the Bynder form-control module is archived. A basic library with no enterprise DAM features.

Video and audio files can be stored in media libraries and served as files, but there is no transcoding, adaptive streaming, thumbnail generation or caption management, so real video use usually embeds YouTube or Vimeo. Basic upload only.

The page builder lets marketers compose pages from sections, zones and widgets by drag and drop, with page templates, editable areas that restrict allowed widgets, section copy and paste (Refresh 9) and a widget search dialog (Refresh 11), all rendered on the real site. Every widget, section and template is developer-built in .NET, and brand guardrails depend on that implementation.

Rendering is native: the customer's ASP.NET MVC 5 or ASP.NET Core application renders pages with content tree routing. Hosting is the customer's or a partner's (on premises or Azure); Kentico does not operate KX13 sites, and the managed SaaS is the separate Xperience by Kentico product.

The Form builder offers drag-and-drop composition, visibility conditions, validation rules, smart fields for progressive profiling across submissions, autoresponders and notification emails, contact mapping and marketing automation triggers, and an August 2024 update added calendar components. Multi-step forms and spam protection beyond CAPTCHA need developer work.

The email marketing module sends newsletters and marketing emails from the platform with templates, an email builder, subscriber and recipient lists from contact groups, A/B testing, statistics and triggered sends from marketing automation. There are no maintained ESP connectors and sending runs on the customer's SMTP infrastructure.

Marketing automation processes are designed visually with triggers from activities, form submissions and scoring, steps for emails, waits, conditions and contact updates, plus contact scoring and ready-made process templates. Processing is batch-driven and channels are limited to email and contact data.

Pages carry title, description and keyword metadata, content tree routing generates slugs and redirects former URLs, and marketers can manage alternative URLs that either redirect to the main URL or serve the page. XML sitemaps, robots rules, hreflang and structured data are built by developers in the live site application, and there are no on-page SEO recommendations.

Nothing in KX13 addresses answer engines: no llms.txt, Markdown endpoints, AI crawler controls or AI referral reporting. Anything here is custom code in the live site application or CDN configuration, with no vendor guidance for v13.

Out of the box KX13 integrates with social media, Salesforce and SharePoint, and Kentico's external modules (Recombee, Bynder, Algolia, Intercom, Zapier) are now archived read-only repositories. Partner modules exist but the ecosystem is a small, shrinking directory as the product approaches end of support.

KX13 has a native visitor membership model: an ASP.NET Identity integration for live-site registration and sign-in, external authentication via Facebook, Google or OpenID, roles and page-level permissions to secure content, and visitors linked to contacts so personalization follows the signed-in identity. Developers must build the sign-in and account actions, and there is no portal framework or packaged CIAM federation.

Kentico Xperience 13 provides a CRUD-style REST service at `/rest` (disabled by default) supporting GET/POST/PUT/DELETE for pages and objects, plus a SOAP/WCF Staging Sync Server. No GraphQL — that capability is exclusive to the successor product Xperience by Kentico. No OpenAPI spec, no interactive playground, limited filtering compared to modern headless APIs. The headless delivery surface is the same generic REST service, not a purpose-built content delivery layer.

No CDN-backed content delivery layer — Azure CDN is configurable as a static-asset offload (CMSAzureCDNEndpoint web.config key) but not a native API delivery layer. No published rate limits, no response-time SLAs, no API performance benchmarks. The Staging Sync Server uses SOAP/WCF over HTTP. The REST service has no caching layer documented and no documented pagination ceiling or include-depth behavior.

Official .NET NuGet packages exist: Kentico.Xperience.Libraries (external app integration), Kentico.Xperience.AspNet.Mvc5 (MVC integration), and Kentico.Xperience.StoreApi (e-commerce REST). The .NET SDK is typed and functional. Zero official JavaScript, TypeScript, Python, Ruby, Java, or mobile SDKs for KX13 — JS consumers must make raw HTTP calls. Community modules on DevNet exist but are not first-party.

The integration set is shrinking as EOL approaches: Kentico archived its KX13 external module repositories (Recombee, Bynder, Algolia, Intercom, Zapier) between December 2025 and February 2026, and docs.kentico.com/13/integrating-3rd-party-systems now carries an 'Archived repositories' notice. The CRM connectors (Salesforce, Dynamics 365) and the built-in Azure Cognitive Search indexing still ship in the product, and the Integration Bus supports custom .NET connectors. There is no curated marketplace and AI, translation and CDN coverage has gaps, so the score falls below the <20-app band's midpoint.

Rich traditional DXP extensibility in .NET: custom modules via CMSModuleLoader, global event handlers for object lifecycle events (Insert/Update/Delete on any Xperience object), custom page types with full field definitions, macro expressions for runtime resolution, custom form controls for admin UI, and standard ASP.NET Core MVC patterns for the live-site layer with DI and middleware. No low-code extension path and no modern App Framework with sidebar widgets, but deeper than many traditional DXPs of this generation.

The administration app ships native TOTP multi-factor authentication (RFC 6238 authenticator apps, enabled per user or globally), but only for forms sign-in and not on the live site. Admin SSO is claims-based via Windows Identity Foundation/WS-Federation (ADFS, Azure AD) and supports SAML 1.0 tokens only. The docs say SAML 2.0 is not supported and IdPs such as OneLogin need a custom implementation. Windows AD authentication is available, and live-site OIDC comes through ASP.NET Core Identity. The REST service accepts only HTTP Basic or URL-hash authentication, with no token or OAuth management.

Full RBAC: roles aggregate permissions, users get permissions only through roles. Permissions enforced at module level (admin UI features), page-type level (all pages of a given content type), and per-page/section ACL (configured in Pages > Properties > Security). CheckPermissions() on DocumentQuery enforces read access on the live site. Page permission inheritance down the tree. No field-level permissions — granularity stops at content item/page.

Kentico Xperience 13 is on-premises software — SOC 2 Type II and ISO 27001 listed at the Kentico Trust Center apply to the SaaS product (Xperience by Kentico), not to KX13 running on customer infrastructure. GDPR compliance tooling is built in (consent management, data protection settings in admin UI). For KX13 deployments, all compliance certifications (HIPAA, FedRAMP, SOC 2, ISO 27001) are entirely the deploying organization's responsibility. The GDPR tools provide a foundation, but no vendor certification applies.

The 2025 cluster is still the defining event. CVE-2025-2746 and CVE-2025-2747 (CVSS 9.8) are unauthenticated bypasses in the Staging Sync Server, listed in CISA KEV as actively exploited, and they chain with CVE-2025-2748/2749 to reach RCE. More advisories followed: CVE-2025-5591 (stored XSS via a form component, published January 2026), and in December 2025 NVD backfilled 26 CVEs (2019–2024) for issues fixed in past hotfixes, many of them stored XSS. Kentico still ships hotfixes (13.0.216 is on NuGet), but all security support ends in December 2026.

Self-hosted on IIS + Windows Server is the primary deployment model; Kentico provides Azure App Service deployment documentation with ARM templates and autoscaling guides. Azure VM also supported. No Kentico-managed SaaS option for KX13 — that exists only in the successor product. No Docker or Linux support for the admin application due to .NET Framework 4.8 dependency (the live-site ASP.NET Core layer can run cross-platform without the admin). Flexibility is decent but platform-constrained.

Kentico gives no uptime SLA for KX13. It is self-hosted software, so uptime belongs to the customer or their hosting provider. The only vendor commitment left is security hotfixes, which stop at the end of December 2026 (about three months away). Customers on Azure App Service get Microsoft's 99.95% SLA, but that is Microsoft's commitment, not Kentico's.

Web farm support is built-in and well-documented: multiple IIS nodes share database and content storage, with session state options (InProc/StateServer/SQLServer) to support or avoid sticky sessions. Azure App Service horizontal autoscaling is documented. Azure CDN integration available for static content offload. Load balancers (IIS ARR, Azure LB) sit in front of web farm nodes. No published scale limits or enterprise-scale benchmarks. The operational complexity of managing IIS web farms is significant compared to SaaS alternatives.

No built-in backup or DR tooling in KX13 — disaster recovery relies entirely on SQL Server backup/restore and file system backups (project folder, assets folder). The Hotfix and Upgrade Utility creates a LocalDB backup before applying hotfixes, and Kentico documents the pre-upgrade backup procedure (SQL database + project folder + ~/assets). Objects Recycle Bin provides soft-delete recovery. No documented RTO/RPO targets, no vendor-provided DR solution, no geo-redundancy from Kentico.

Full local development is possible using IIS Express with SQL LocalDB (auto-installed by the installer) and Visual Studio 2019/2022. The live-site ASP.NET Core MVC project runs locally with hot reload. However, local development is Windows-only — the .NET Framework 4.8 admin application requires IIS on Windows. Mac/Linux developers cannot run the admin application locally. No lightweight emulator or containerized dev environment. Compared to modern platforms with `npm start` local dev, the barrier is high.

Built-in Continuous Integration module serializes object and configuration changes to XML files on the file system for source control (Git or TFS). However, the CI module must not run in production — it is a development-environment-only feature, adding operational friction. Content promotion between environments uses the Staging Sync Server (the same WCF service exploited by CVE-2025-2746/2747). No branch-per-PR content environment support. Standard Azure DevOps/GitHub Actions pipelines call MSBuild for deployment. CI serialization works but is cumbersome compared to modern migration CLIs.

docs.kentico.com/13 remains live and comprehensive as of mid-2026, covering developer, admin, and deployment scenarios with full feature coverage. API reference at docs.kentico.com/13api with code examples by feature area. DevNet hosts additional developer resources. Documentation is being maintained primarily with migration-path guidance to Xperience by Kentico now that the product is roughly six months from EOL. C#-only code examples throughout — no JavaScript, TypeScript, or multi-language samples. No interactive playground.

Zero TypeScript or JavaScript support for KX13 content delivery. No official JS/TS SDK, no generated API client, and no OpenAPI spec for the KX13 REST service. The npm packages associated with the Kentico name (kentico-cloud-delivery-typescript-sdk, @kentico/kontent-delivery) belong to Kontent by Kentico — a different SaaS product. Frontend developers consuming KX13 content must make raw HTTP calls with manually crafted request/response types. This is a fundamental architectural limitation of the legacy .NET Framework product.

KX13 ships more often than 'security-only' suggests: 17 hotfixes (13.0.199–13.0.216) went out between Jan 8 and Sept 24 2026, roughly every one to two weeks, and together they fixed about 36 security issues. The last feature release was Refresh 14 (Dec 4 2025), which added .NET 10 support and little else. This is patch cadence with zero functional change, so it stays well below the 50 line for platforms that have shipped nothing notable in 6+ months.

Two structured sources cover KX13 changes. Refresh release notes separate new features, updates, API obsoletions and fixed issues for all 14 Refreshes. The DevNet bug tracker has a per-issue security advisory for each fix, giving issue type, severity, affected version range, fixed version, date and reporter. Hotfixes that need manual steps are called out (e.g. the 13.0.203 ContinuousIntegration.exe fix). It doesn't score higher because the per-hotfix changelog is a large single page rather than versioned release pages, and there is no forward-looking change information.

Kentico is clear about how KX13 ends. The Dec 31 2026 EOL is stated on the lifecycle page and in a warning banner on the release notes, which also tells users to move off .NET 8/9 before Microsoft's Nov 10 2026 cutoff. Kentico has also said there will be no paid extended support after EOL. But the product has no roadmap beyond that date, and the roadmap.kentico.com KX13 tab only lists requests that will never be built. Transparency about the shutdown is excellent; there is no future direction to be transparent about.

Two 2026 hotfixes caused regressions. After 13.0.203, ContinuousIntegration.exe failed on assembly load; 13.0.204 fixed this only for new installs, so existing projects had to apply manual steps. Hotfix 13.0.206 stopped parts of the Page Builder UI from loading until 13.0.207 shipped a week later. On the plus side, Kentico kept up with the framework: it added .NET 10 support before .NET 8 reaches end of support and marks obsolete APIs in the release notes. The one-way move to Xperience by Kentico is still effectively a rebuild, with a Migration Tool but no in-place upgrade.

With about three months to EOL, the KX13 community keeps shrinking. The DevNet forums and the Stack Overflow 'kentico' tag still have a large archive, but few new questions are about KX13. Kentico now shows an Xperience by Kentico news tile on the KX13 admin dashboard, so the vendor is steering even existing users toward XbK. All community programmes (MVPs, Slack, Community Portal) are built around XbK.

Kentico's community investment (MVP programme, Community Leader awards, AI Development Hub, Slack) is almost entirely aimed at Xperience by Kentico. For KX13, the engagement that remains is migration help and legacy issue support. Outside researchers are still active: they reported the Sept 2026 IDOR and Host-header flaws. But nearly all new community content is partner-written migration guides.

Kentico's partner network of 500+ agencies still exists, and many partners keep KX13 skills to support existing clients. Their public focus has moved almost entirely to migration: BizStream, Cantarus, Luminary, Bluesoft and others publish KX13 EOL guides rather than new KX13 implementations. Kentico reports partner-driven growth for fiscal 2026, but that growth is on XbK.

Third-party KX13 content from 2026 is almost all EOL warnings, security-risk pieces and migration plans, not tutorials or courses. Older learning material from 2019–2022 (DevNet articles, blog series, YouTube) still exists but is dated. No new KX13 learning content is being produced.

KX13 developers can still be found on ZipRecruiter, Upwork and Toptal, mostly for maintenance and migration work. Hiring for new KX13 builds has essentially stopped. The live site runs on ASP.NET Core (.NET 8/10), so front-end skills carry over, but the admin application is still .NET Framework 4.8 WebForms, and that skill set is shrinking. Developers are moving their Kentico skills to XbK.

KX13 is in terminal decline, with a fixed EOL of Dec 31 2026, about three months away, and no paid extension. No new customers are starting KX13 projects, and Kentico now advertises its successor inside the KX13 admin UI. Kentico reports record ARR for fiscal 2026, but its new customers and projects are all on XbK.

Kentico is a stable company: privately held, backed by Expedition Growth Capital, $56.7M revenue in 2025, and record ARR with double-digit growth in the fiscal year ending June 2026. It is honouring its KX13 commitment with patches every one to two weeks. For KX13 itself, though, the support horizon is now about three months and Kentico has ruled out paid extended support. The strong vendor is heavily offset by the product's short remaining life.

KX13 is not a candidate for new projects and does not appear in current DXP evaluations. Analyst and review-grid coverage of 'Kentico' now means Xperience by Kentico, and Gartner Peer Insights lists KX13 separately as '(Legacy)'. The only choice KX13 customers face is when and where to migrate.

Gartner Peer Insights rates KX13 (Legacy) 4.3/5 across 200+ reviews, which reflects real satisfaction with editing and mid-market fit during its active years. Recurring complaints are recompile-on-change downtime, little improvement over Kentico 12, and backend dependence for page-type changes. Frustration over forced migration is growing, and the 2026 hotfix regressions add to it. The score is held below the 60–72 band because the review base is historical and no longer growing.

Partner and review sites publish concrete v13 tier rates: Business about $12,500/year and Enterprise about $22,300/year, with maintenance renewal at about 30%. That is clearer than fully opaque DXPs like AEM and Sitecore XP. Kentico's own how-to-buy page now promotes only Xperience by Kentico, so official v13 pricing takes a partner or sales contact. Mid-range: clearer than enterprise DXPs, less clear than SaaS with published tiers.

The annual subscription (all customers were moved off perpetual licenses by June 2024) has fixed tier costs, with no consumption metering or per-API charges, so spend is predictable. The forced 2024 conversion from perpetual licensing still draws complaints, and multi-server deployments need the Enterprise tier. Predictability is the strength; the rigid annual-only structure caps the score.

The Business tier covers the core DXP: full CMS, personalization, marketing automation and single-server eCommerce. Enterprise gates multi-server load balancing and advanced eCommerce. The feature set is frozen (Refresh 14 in Dec 2025 was the last feature release; 2026 brings security hotfixes only), so tier gating matters little for procurement because no tier gets new features. Moderate gating, offset by a frozen platform.

Annual subscription only, with no monthly billing and no published startup, nonprofit or education programs. EOL is about three months away, so a new v13 annual commitment makes no sense. Kentico's one flexibility is converting existing v13 licenses into an Xperience by Kentico subscription so migrating customers don't pay for both. Exit and early-termination terms are not publicly documented.

The only free option is a 30-day evaluation license from the Kentico Client Portal. There is no permanent free tier, community edition or open-source path, and the Business tier starts at $12,500/year. Paid licenses include development, staging and QA installations at no extra fee, which helps environment costs but is not a free route to production.

A v13 setup has two parts. The ASP.NET Core live site targets .NET 8–10. The administration app is ASP.NET Web Forms and needs .NET Framework 4.8, IIS with ISAPI extensions and filters in an Integrated app pool, a case-insensitive SQL Server, and a Client Portal license key before first run. From zero, an experienced .NET developer needs 1–2 days to get a working environment. That is much more friction than cloud-native or headless platforms, or than XbyK's dotnet new templates.

Small-to-medium v13 projects typically take 3–6 months and cost $25k–$50k. Enterprise projects with complex integrations or eCommerce take 6–12 months and $50k–$150k+. Starting a greenfield v13 build this close to EOL is not sensible, so nearly all current work is exit migration, which costs from a few thousand dollars for simple sites to $75k+ for complex ones. Timelines remain longer than modern alternatives.

Most live-site work uses mainstream ASP.NET Core (.NET 8–10) MVC skills, so general .NET developers can contribute. Customizing the admin (modules, UI extenders, macros) still needs .NET Framework 4.8 and Web Forms expertise, a legacy skill set. Kentico developers average about $123k/year (~$59/hr) in the US, and the v13 talent pool is shrinking as consultants move to migration work. The premium is moderate and rising, below AEM or Sitecore specialists.

The ASP.NET Core live site can run on Linux or in containers, but the Web Forms admin app still needs Windows with IIS, and both depend on SQL Server, which costs more than Linux or cloud-native stacks. SQL Server Standard is about $3,945 per 2-core pack, or about $73/core/month pay-as-you-go on Azure. Azure Hybrid Benefit can offset some of that. Self-managed v13 infrastructure typically costs $12k–$30k/year, and large deployments pass $50k.

Self-hosted v13 needs ongoing Windows Server and IIS patching, SQL Server maintenance and application monitoring. In 2026, Kentico shipped 17 security hotfixes (13.0.199–13.0.216), about one every two weeks, and two caused regressions: 13.0.203 broke ContinuousIntegration.exe and 13.0.206 broke the Page Builder. Microsoft also ends .NET 8/9 support on Nov 10, 2026, which forces a live-site move to .NET 10 just before EOL. From Jan 1, 2027 customers run fully unpatched software.

Every v13 customer has to leave by EOL, and application code (widgets, macros, custom modules, event handlers) is proprietary and must be rebuilt on any target. Data is less locked in than the code. Content sits in a customer-owned SQL Server database, and Kentico's MIT-licensed Migration Tool (v4.4.1, released Sept 25, 2026) moves data models and content to Xperience by Kentico and can be re-run with custom transformations. Moves to other platforms (Umbraco, WordPress) have no vendor tooling and are full rebuilds.

KX13 has a genuinely complex mental model. It runs two applications: an admin app on .NET Framework 4.8 and a separate ASP.NET Core or MVC 5 live site. The two share one SQL Server database and are kept in sync by web farm synchronization. Developers also have to learn the proprietary Page API (DocumentQuery, PageTypeInfoProvider), Page Types with generated classes, two routing modes (content tree-based and custom URL patterns), and Portal Engine-era admin customization. It is not as severe as AEM or Sitecore XP, but it is clearly more complex than modern platforms, and it scores below Xperience by Kentico because the legacy dual-app architecture cannot be hidden from developers.

The KX13 tutorial (docs.kentico.com/13tutorial) and the full v13 docs are still online, and the docs can be fetched as Markdown. However, the official Kentico/xperience-training-13 repository, the hands-on codebase behind the developer and marketer courses, is now archived and read-only (last push February 2024). All new training and learning-path investment goes to Xperience by Kentico, and KX13 reaches EOL on Dec 31, 2026, three months from now. The resources are adequate and docs-heavy but frozen, with no guided or in-console onboarding, so the score sits in the low-40s-to-50 band.

The live site is a standard ASP.NET Core app on .NET 8–10 (or legacy MVC 5), which modern .NET developers know. Everything else is unusual: the admin application is a .NET Framework 4.8 Web Forms-era app, the non-standard two-app deployment shares one SQL Server database with web farm sync, content access goes through proprietary DocumentQuery / PageTypeInfoProvider APIs, and personalization and workflow logic use the Kentico macro language. There is no GraphQL or first-class JavaScript framework story, so the platform stays in the proprietary-toolchain band.

The Windows installer can deploy the Dancing Goat sample site, a complete demo project with a content model, example content and Page Builder widgets, for either the ASP.NET Core or MVC 5 model. That is a real, vendor-maintained starting point with example content, so the previous claim that no example content is bundled was wrong. Against that: the only installation path is a Windows .exe with IIS, there are no dotnet-new templates (the Kentico.Xperience.Templates package is XbyK), the xperience-training-13 reference repo is archived, and there are no JS-framework starters or CI/CD configuration.

Going from zero to a working build means configuring two applications. The installer auto-registers only the admin app in IIS; the ASP.NET Core live site must be hosted manually. You also need connection strings in both apps, license keys per domain, the Presentation URL, web farm sync, SameSite cookie mode when the apps are on different domains, and CSP frame-ancestors for preview. Many settings also live in the database admin UI rather than in config files. This is a heavy surface of non-obvious values.

Page Types are defined in the admin UI and backed by SQL tables with generated C# classes, so each schema change means regenerating code and recompiling. Continuous Integration serializes object definitions to XML for source control, but Kentico says it should not be enabled on production, it misses changes made directly in the database, it cannot use shared file systems, and it conflicts with object versioning and locking. Adding fields is safe, but renaming or restructuring has no migration tooling.

With content tree-based routing, preview URLs work automatically, and the Page Builder gives in-context visual editing in an admin iframe, plus shareable preview links for unpublished pages. The setup still takes multiple platform-specific steps: the app must be coded to load the latest page versions in preview mode, SameSite cookies must be set for cross-domain setups, CSP frame-ancestors must be whitelisted, URL length limits raised, and UsePageBuilder/UsePreview wired up. Custom routing also needs URL patterns per page type, and there is no headless preview.

All live site and customization work requires .NET/C# plus Kentico-specific knowledge: the DocumentQuery/PageTypeInfoProvider APIs, Page Builder widget, section and property development, the macro language, and admin customization on the .NET Framework 4.8 app. Certification is optional, but the skill set is highly proprietary and the KX13 talent pool is shrinking as partners move to XbyK before the December 2026 EOL. TypeScript/React generalists cannot contribute to backend work.

A self-hosted or hosted-server KX13 build needs Windows/IIS hosting for the admin app, SQL Server administration, web farm setup, and hand-built deployment pipelines (Continuous Integration is dev-only, so deployment uses separate tooling). Production projects usually need a team of about 4–6 people: .NET developers, a Kentico-savvy architect, DBA or ops skills, and trainers for content authors. A solo developer can evaluate the platform with Dancing Goat but cannot realistically take it to production alone.

After go-live, marketers can compose pages from existing widgets in the Page Builder, build forms in the Form Builder, and run marketing automation, A/B tests, contact management and email campaigns without developers. Editors can also send preview links for unpublished pages. New widget types, page types or templates still need C# development, though, and the older admin UI takes more training than modern React admins, so operational friction stays moderate.

The official KX13 hotfix procedure has seven steps. You hotfix a local copy with Hotfix.exe, rebuild the solution in Visual Studio, and bump the live site's Kentico NuGet packages to the same version. Then you test, redeploy, and run the hotfix SQL script against production. Admin app, live site and database must all be on exactly the same version. Customized files come out as .new/.deleted conflicts that have to be merged by hand, and two 2026 hotfixes shipped regressions (13.0.203 broke ContinuousIntegration.exe; 13.0.206 broke Page Builder until 13.0.207). The only way forward is to replatform to XbyK, not to upgrade in place. Not lower because Hotfix.exe automates the admin-side steps and has a scriptable /deploy mode; not higher because every hotfix is a coordinated three-part deployment with a database migration.

In security-only mode, KX13 shipped 17 hotfixes in 2026, from 13.0.199 (Jan 8) to 13.0.216 (Sept 24), covering about 36 security fixes. Releases came about every two weeks early in the year and have slowed to monthly (13.0.215 on Aug 20, 13.0.216 on Sept 24). Each patch is a full hotfix deployment with a production SQL script and version-locked admin, live site and database, so it is not a drop-in library update, and 2026 shipped two regressions. The CVE record stays heavy: CVE-2025-2746/2747 (CVSS 9.8, in CISA KEV), CVE-2025-5591 (published 2026-01-05), and 26 historical KX13 CVEs NVD backfilled in Dec 2025. Not lower because fixes arrive regularly with dated DevNet entries; not higher because every self-hosted instance takes on the full deployment work for each patch.

Support ends December 31, 2026, about three months from now. Kentico offers no paid extended support, and running the product after that date is at the customer's own risk. The only path forward is a full replatform to Xperience by Kentico, where the content model, Page Builder widgets, custom code and integrations are all rebuilt. This continues a pattern of forced platform changes (Portal Engine removed in 13, then 13→XbyK). The MIT-licensed Kentico Migration Tool is actively released (v4.4.1 on 2026-09-25) and moves content and data but not code. Kentico also converts v13 licenses to XbyK subscriptions. Not lower because notice exceeded 12 months and there is migration tooling and license credit; not higher because the migration is mandatory, rebuilds everything, and comes with a hard deadline.

KX13 is two applications on two runtimes. The live site runs on ASP.NET Core (.NET 8/10, and can be hosted on Linux). The administration app must stay on .NET Framework 4.8 under Windows/IIS. Both share one SQL Server database that must match the hotfix version exactly. Customers own OS, IIS, SQL Server and .NET patching, and must track .NET LTS lifecycles themselves (.NET 10 support arrived in Refresh 14, Dec 2025). No Solr/Redis/xDB is required, so the stack is lighter than Sitecore XP's, and search can use the built-in Azure Cognitive Search integration. Not higher because there is no managed option and two runtimes must be patched in lockstep.

KX13 has a built-in Event log application and a System → Debug suite covering SQL queries, IO operations, event handlers, cache items, worker threads, hash tables, email and web farm debugging. The previous claim of 'zero built-in observability' was wrong. However, Xperience 13 removed the whole Health Monitoring feature (its Windows services and performance counters), and there is no APM, uptime alerting or dashboard, so production monitoring still means wiring up Application Insights or similar plus SQL Server and IIS monitoring. Not lower because the diagnostic tooling is real and useful; not higher because it is for troubleshooting in the admin UI, not for continuous monitoring.

KX13 has a link checker at Pages → Preview → Validate → Link checker that reports 404s and 301s with status codes. It runs manually on one page at a time; there is no site-wide scan and no scheduling. Pages also have Publish from/Publish to fields plus 'Redirect after unpublish', which gives a real content-expiry mechanism. The previous claims of 'no broken link checking' and 'no content expiry' were wrong. There is still no orphan or unused-content detection, no stale-content review workflow, and no content health dashboard. Not lower because the link validation and scheduled unpublishing are built in; not higher because hygiene across the site still depends on manual editorial discipline.

KX13 is fully self-hosted. Customers configure ASP.NET Core output caching and cache dependencies, tune SQL Server indexes and query plans, set up web farm synchronization for multi-instance deployments, and add their own CDN and load balancing. There is no auto-scaling or managed infrastructure. The built-in SQL query and cache debugs help with diagnosis, but all optimization is the customer's job. Not lower because the caching API and debug tooling are mature; not higher because every layer of performance is managed by the customer.

G2 reviewers consistently praise Kentico's formal support for fast responses from in-house engineers, and Standard and Premium 24/7 tiers carry SLA response times. Since January 1, 2026, KX13 support covers only security issues. Customization, performance and feature questions are out of scope and need paid consulting, and all support stops on December 31, 2026 with no paid extended-support option. Not lower because support is still responsive within its narrowed scope for now; not higher because that scope is narrow and ends in three months.

The DevNet Q&A archive is still a large body of historical KX13 answers, but the ecosystem is shrinking visibly. Kentico archived every KX13 external module repository (Algolia, Recombee, Bynder, Intercom, Zapier) between Dec 2025 and Feb 2026, and the official xperience-training-13 repo is archived. That leaves no maintained place for community fixes. Community and partner energy has moved to XbyK and migration content. Not lower because the DevNet archive and MVP knowledge base still answer most legacy questions; not higher because the active community is small and moving on, three months before EOL.

Security issues still get fixed. 2026 brought 17 hotfixes, roughly every two weeks and more recently monthly, each with dated DevNet entries, and the regressions they introduced were fixed quickly (the 13.0.206 Page Builder break was fixed in 13.0.207). Non-security defects are excluded under every support tier, so anything else found in 2026 will not be fixed, and nothing at all will be fixed after December 31, 2026. Not lower because critical CVEs and hotfix regressions have been fixed promptly and transparently; not higher because the product is frozen apart from security fixes and close to its final patch.

Kentico Xperience 13 has a mature Page Builder with drag-and-drop widget placement, section layouts, and reusable page templates — marketers can assemble landing pages from pre-built widget libraries without developer involvement once the library is established. The feature set is complete but frozen: the last feature release was Refresh 14 (Dec 2025) and 2026 has been security hotfixes only. Scores 65 rather than 70 because the aging tooling lacks modern UX refinements and the Dec 31 2026 EOL (about three months away) creates confidence risk for marketing teams planning new campaigns.

Mature campaign management: campaign tracking with content grouping and conversion goals, A/B testing for pages and emails, email marketing with drag-and-drop Email Builder, marketing automation (Contact Management), and web analytics with source/demographic reporting. Campaign features were a primary selling point and are well-integrated across the platform. No multi-channel social orchestration or advanced campaign calendaring, and no new development planned given EOL status.

KX13 covers redirect and URL hygiene natively. It stores former URLs automatically and 301-redirects them when a slug changes, supports alternative URLs with a redirect or show mode, and has settings for enforcing lowercase, trailing slashes, and unifying the home page URL with a 301. Pages carry meta title and description fields. However, XML sitemap generation is no longer built in. Xperience 13 dropped the Portal Engine, and with it the DocumentShowInSiteMap and DocumentSitemapSettings columns, so on MVC/Core live sites developers build sitemaps in code. There is also no structured-data authoring or SEO scoring, and the Google Search Console module is archived. The previous score of 62 credited a built-in sitemap module that does not exist in v13.

Built-in Form Builder with conditional visibility rules, field validation, and submission tracking. Campaign tracking logs a campaign activity and cookie when visitors arrive via campaign links, and conversions feed campaign reports. A/B testing covers pages and emails with configurable conversions. Native lead scoring (Enterprise) awards or deducts points for purchases, form submissions, newsletter subscriptions, page visits and profile attributes. It supports multiple independent scores and threshold notification emails, and marketing automation can act on scores. The previous run said there was no native lead scoring, which is wrong. The remaining gaps are no conversion-optimization recommendations and dated tooling.

KX13 personalization works only at the widget level. Marketers create personalization variants of a Page Builder widget and pick a condition type that decides which variant a visitor sees. However, developers must build the condition types first (the docs list 'Develop personalization condition types' as a setup step). Conditions typically key off contact groups, personas and contact activity from the contact database. Xperience 13 removed the page–persona binding and Portal Engine personalization variants, so there is no page-level variant model. The previous run credited page-level personalization and built-in geo/device/referrer conditions, which overstated the out-of-the-box capability. This is genuine rule-based behavioral targeting on a native contact database, but it needs developer enablement and has no AI or predictive component.

Native A/B testing for both pages and marketing emails: create test variants, configure conversion goals, run the test, and evaluate results via built-in analytics showing conversion rates and statistical comparisons. Winner selection is manual (the marketer reviews data and selects the winner), not automated. This is a complete A/B testing feature set for a platform of its era. No multivariate testing, no auto-winner, no integration with external experimentation platforms for feature flag testing.

Page Builder with template cloning and reusable widget library accelerates page creation once the initial developer investment is made. Inline editing in the live preview mode, content staging/preview before publish, and simple workflow shortcuts. Bulk operations on content items are supported in the administration. The bottleneck is that any new page layout or new widget type requires developer involvement — and with full EOL under six months away (Dec 31, 2026), organizations are pausing widget library expansion, which materially constrains net-new content velocity beyond existing templates.

KX13 delivers to web (primary) and email (built-in email marketing module), plus social posting to Facebook, Twitter and LinkedIn. Other channels get content through the legacy Xperience REST service, the Integration bus, or custom ASP.NET Web API endpoints. KX13 has no GraphQL or purpose-built headless delivery API; the previous evidence citing GraphQL was wrong. Page Builder content is stored as widget JSON tied to the MVC rendering, so it does not transfer well to non-web channels. The platform is web-first, and each extra channel needs custom developer work.

Built-in web analytics module with visitor tracking, campaign source attribution, page conversion tracking, and flexible dashboards — without requiring GA. Out-of-the-box social analytics (Facebook Insights, LinkedIn Stats, Twitter Analytics) surfaced in the platform UI. Google Analytics integration available via standard tag manager approach. Analytics is visible within the platform rather than purely external. No content decay reporting, no content performance scores, and the built-in analytics are less capable than dedicated tools.

Page Builder widgets provide component-based consistency — marketers choose from an approved widget palette rather than free-form HTML. Developers can lock widget properties or restrict widget availability per page type or page template. However, there are no design token management features, no global style system enforced at the platform level, and no automated brand compliance checks. Consistency is achieved through developer-constrained widget configuration, not system-level enforcement.

KX13 integrates social media out of the box. It can publish to Facebook pages, Twitter channels and LinkedIn company profiles, either manually or automatically when content is published, and it surfaces Facebook Insights, Twitter Analytics and LinkedIn statistics in the admin. The previous run said LinkedIn publishing was unsupported, which is wrong. OG and card tags are implemented in the MVC views rather than managed by a dedicated feature. Scores just under 60 because these integrations target social APIs as they stood in 2020–21 (Twitter/X API access has since tightened), there is no Instagram or TikTok support, and there is no UGC moderation.

Built-in media library with folder organization, image resizing/cropping on upload, and basic search. Media files are accessible across sites in a multi-site installation. The media library serves web content production adequately but falls short of DAM capabilities: no usage tracking (cannot see where an asset is used), no rights expiry management, no keyword/taxonomy-based asset search beyond folder browsing, and no video transcoding. For marketing asset volumes, most organizations integrate an external DAM.

Full multilingual content management: create language versions of pages with optional translation workflows, machine translation integration via built-in connector (Microsoft Translator) or custom integration, locale-specific URL management, and per-language campaign variants possible by creating locale-specific pages. Cookie consent and GDPR consent tracking built in at the platform level. The localization engine is mature and supports marketing workflows. Locale-specific campaign calendaring is achievable but requires manual page management per locale.

KX13's native Salesforce integration was updated to SOAP API v54.0. It synchronizes contacts and leads in both directions, and a Salesforce flow can push lead updates back to Xperience. Other connectors are all archived external modules: Microsoft Dynamics 365 Sales (contacts and activities), Zapier, Recombee recommendations and Bynder DAM. They still install from NuGet but no longer accept fixes. The Integration bus and REST service support custom event-driven sync. The earlier claims of HubSpot and Marketo connectors could not be verified in any official source and are no longer credited. There are no CDP or ad-platform connectors.

Kentico Xperience 13 has a mature built-in e-commerce module with full product catalog management: standard products, products with options, product variants as independent SKUs, brands/manufacturers/suppliers, inventory tracking by variant, and file/image attachments per product. Product taxonomy via categories. This is a genuinely mature product content system developed over many platform generations — better than early-stage or headless approaches. Not a full PIM and lacks advanced attribute modeling, but coverage is solid for SMB/mid-market commerce.

Legacy e-commerce module includes catalog discounts, order discounts, volume discounts (tiered pricing), Buy X Get Y promotions, product bundles, coupon codes, and free shipping rules — a more complete promotional toolkit than many DXPs of its era. Category management enables basic product organization. No search result merchandising, no AI-driven product recommendations, and no dedicated product spotlight widgets, but the discount/promotions engine covers standard merchandising scenarios.

Kentico Xperience 13 is a self-contained commerce platform — it does not integrate with Shopify, commercetools, BigCommerce, or Salesforce Commerce Cloud natively. The k13ecommerce GitHub package exists specifically to bridge legacy commerce data into Xperience by Kentico for migration purposes, not as a live integration. Any external commerce platform integration requires fully custom development. Scores 30 (webhook-only custom) because the platform's model is standalone commerce, not commerce synergy.

KX13's tightly coupled content + commerce architecture allows product listing pages and product detail pages to be managed as content pages, blending editorial copy with product data. Page Builder widgets can embed product listings or individual product cards within editorial pages. However, shoppable content is not a first-class authoring pattern — there is no built-in 'shop the look' template, no inline add-to-cart within editorial articles, and no lookbook page type. Buying guides and editorial commerce pages are achievable but require developer-built templates.

KX13's configurable checkout is part of the native commerce module — checkout steps are configurable and can be extended with custom .NET widgets. Trust badges, upsell banners, and cart messaging are achievable within the platform's checkout pages, which can reference Page Builder or custom templates. This is better than pure-commerce platforms because the checkout templates live in the CMS. However, it requires developer work to add CMS-managed promotional content to checkout flows rather than being marketer self-service.

Email marketing module can trigger transactional and promotional emails based on order events — order confirmations, shipping notifications, and follow-up sequences are achievable using the marketing automation and email marketing features. Order confirmation pages are CMS-templated and configurable. Post-purchase review solicitation requires marketing automation workflow configuration. All post-purchase content is technically manageable from the CMS but not as no-code functionality for marketers.

KX13 supports customer-specific pricing via customer discount groups and volume discount tiers. Registered user accounts with customer-specific catalogs can be scoped using the existing access control model. Quote request flows can be built using the Form Builder tied to product pages. Gated product documentation is achievable via page-level ACLs. These B2B primitives exist but they are not packaged as first-class B2B content features — they require assembly from generic platform capabilities rather than purpose-built B2B tooling.

Built-in Smart Search (Lucene-based) supports full-text search across content and products, with configurable search results pages and basic faceted filtering using search indexes. Product search within the e-commerce module. Content-product blended search results are achievable by configuring combined search indexes. No AI-powered relevance ranking, no synonym management UI, and no search analytics beyond basic query logging. Adequate for mid-market sites but not competitive with modern search platforms.

Time-based promotional content is achievable: page publishing/unpublishing can be scheduled for campaign start/end dates, discount codes with date ranges, and promotional banners managed via Page Builder widgets with scheduled visibility. The campaign module can group promotional pages with start/end dates. No countdown timer widget out of the box, no channel-specific promotional targeting, and tiered pricing tables require developer implementation, but scheduled promotional content management is a viable core capability.

Multi-site installation can serve multiple storefronts from a single KX13 instance, with shared product catalog data and site-specific editorial content managed in separate site content trees. Product types and catalog structure are shared across sites, but each site can have its own pages, promotional content, and design. Some content duplication is necessary for storefront-specific messaging, and the shared database constraint means absolute data isolation between storefronts is not achievable. Adequate for related brands sharing product data.

Product pages support multiple images per product, video embed widgets (YouTube/Vimeo iFrame), and basic image gallery widgets via Page Builder. Image transformations (resize, crop) are built into the media library. No 360-degree product views, no AR/3D model support, no image hotspot tooling, and no native zoom widget — these require third-party JavaScript integrations or custom widget development. KX13's visual commerce is basic image+video, typical of a platform from its era.

KX13 has no marketplace or multi-vendor content management capabilities. The commerce module is designed for a single-seller model — there is no seller profile management, no seller-contributed product descriptions, no multi-vendor content moderation, and no review aggregation by seller. Building marketplace functionality would require extensive custom development on a platform approaching EOL, making it an inadvisable investment.

KX13's multilingual engine applies to product content: product names, descriptions, and page-level editorial can have language versions. Currency management is native to the commerce module with multi-currency pricing. Locale-specific URL management for product pages. Translation workflow can be applied to product pages. Regional regulatory content (EU product labels) can be managed as locale-specific content variants. No structured data localization for attributes/specifications without custom development.

Campaign conversion goals can be linked to product page visits, add-to-cart actions, and order completions — providing some content-to-revenue attribution within the KX13 analytics module. The 30+ built-in store reports include sales by source and campaign performance. This is better than platforms with no commerce analytics, but revenue attribution at the content-item level requires custom configuration, and there is no out-of-the-box content-assisted conversion tracking across full customer journeys.

Page-level ACLs grant read, modify, create, delete and destroy permissions per role or user on content tree nodes and their children, which allows genuine department-level scoping. Users can hold multiple roles across sites. Claims-based SSO exists, but the docs say it supports only SAML 1.0, not SAML 2.0, so the previous claim of SAML 2.0 SSO was wrong. Modern IdPs are usually connected through custom ASP.NET Core external authentication (OIDC, for example) on the live site. The admin app has native TOTP MFA for forms sign-in. Contact-group personalization adds audience-based display on top of ACLs. Held just below the previous 65 because of the SSO correction.

Document versioning with comparison and rollback, workflow with approval states and email notifications, content taxonomy via categories and tags, and media library organization. These form a basic knowledge management foundation. No dedicated knowledge base templates, no content freshness/expiry tracking, no expertise mapping, and internal search requires Lucene-based configuration to be effective. Adequate for structured intranets but not purpose-built for knowledge management.

Kentico Xperience 13 removed its community features (forums, groups, blogs, message boards, polls and chat) that existed in KX12 and earlier, as well as content notifications. Its intranet capabilities are basic: content publishing, media libraries, workflow approval and page ACLs. There is no employee portal module, employee directory, push notifications or mobile app. With EOL about three months away (Dec 31 2026) and no extended support, KX13 is a migration source, not a build target, for employee experience.

Basic internal communications are possible with general features. News pages can be published to authenticated users behind page ACLs, contact-group personalization can target department-specific widgets, and the email marketing module can send announcements. Xperience 13 also removed the built-in content notification feature that previously alerted subscribers to new content. There is no acknowledgment tracking, no mandatory-read workflow, and no alerting for new content. Internal comms means repurposing marketing features.

KX13 has no native people directory, org chart, or HR integration capabilities. An employee directory could technically be built using custom page types and content items, but this requires significant developer effort on a platform approaching EOL. The contact database (used for marketing) stores external contacts, not internal employee profiles with skills/expertise. There is no Workday, BambooHR, or Active Directory org chart integration.

Basic document publishing with version control and workflow approval is achievable using KX13's standard content management: file attachments, content versioning, workflow states for review/approval, and role-based access control for policy documents. However, there is no mandatory acknowledgment tracking, no automated review-date reminder, no policy expiry enforcement, and no audit trail specific to policy compliance. The platform offers document publishing primitives but not a policy management system.

KX13 has no structured onboarding journey features. Basic onboarding pages could be built as content pages with role-based access for new hires, but there is no progressive disclosure mechanism, no task checklist widget, no HR system trigger for new-hire portal provisioning, and no 30/60/90-day content path tooling. With community features removed and EOL approaching, any onboarding content delivery on KX13 would require substantial custom development.

KX13 offers two built-in search options. Smart Search uses locally stored Lucene indexes, with search pages and faceting. Azure Cognitive Search is also integrated and can index content automatically, which scales better and adds Azure's relevance features. The official Algolia module is archived. The SharePoint Online integration can display SharePoint library data on pages, but there is no federated search across SharePoint, Confluence or drives, and no search analytics dashboard. This is adequate internal search for moderate volumes. It ranks slightly above the previous 36 because the Azure Cognitive Search integration was not credited before.

KX13 delivers responsive web content optimized for mobile browsers but has no native mobile application, no push notification capability, and no offline content access. The content management administration interface is desktop-focused and not mobile-optimized for on-the-go publishing. Frontline and deskless workers would access an intranet via mobile browser only with no app store presence. No kiosk mode or shared-device management.

KX13 has no native learning management features and no pre-built LMS integrations. Training content can be published as HTML pages with access control, but there is no course structure, no completion tracking, no certification management, and no integration with Cornerstone, Workday Learning, or other LMS platforms. Any learning functionality would require custom development against the KX13 API on a platform heading to EOL.

Xperience 13 removed its community and social features: blogs, forums, groups, message boards, polls, chat, content rating, events, and user badges and activity points. The only way to add commenting is the Disqus comments widget, an external module whose repository is now archived. It adds third-party comment threads to pages but no reactions, forums, polls, recognition or community spaces. This is near-total absence of a social layer.

KX13 ships one workplace integration out of the box: SharePoint Online. It can connect to SharePoint Online, display library data on the live site, and let editors manage SharePoint libraries from a dedicated admin app. The docs say the SharePoint integration is unsupported for ASP.NET Core sites, which are the recommended KX13 live-site model, and only SharePoint Online is supported. There are no Microsoft Teams, Slack or Google Workspace connectors, content cards or bots. The previous score of 18 missed the SharePoint integration, but its restriction to MVC 5 sites limits the credit.

Content versioning with comparison and rollback provides a basic archival history. Workflow states can include an 'archived' state for inactivating content. Content publishing schedule allows setting publish/unpublish dates — the unpublish date serves as a de facto expiry mechanism. However, there is no automated review-date reminder, no stale content flagging, no ownership assignment per content item for accountability, and no formal archival workflow distinct from deletion.

KX13's built-in web analytics provides page view counts and visitor session data, which can be filtered per site. Campaign-level analytics shows content engagement by source. However, there are no department-level analytics dashboards for intranet ROI, no failed internal search term reporting surfaced in the UI, no adoption/engagement heatmaps, and no intranet-specific content performance metrics. Analytics is oriented toward external marketing, not internal comms measurement.

Kentico Xperience 13 supports multi-site from a single installation (true multi-tenancy in vendor terminology), but all sites share a single database and application instance. Personal data cannot be completely isolated between sites in a shared installation — explicitly documented as a known limitation. Organizations requiring strict data isolation between brands must run separate installations. Silo-based via site permissions, not genuine tenant isolation. Scores 50 (low end of silo-based range) due to the shared-database data leakage risk.

Multi-site installation shares Page Builder widgets, page templates, media library, and content document types across all sites in the instance. Global shared content is achievable by placing documents in a shared site content tree. However, there is no brand-override system for shared widgets, no design token management, and no centralized governance over which sites can access shared components. The sharing model works for organizations that trust all sites to share the same asset pool.

Central admin interface manages all sites with per-site role assignments and content tree ACLs. Workflow with configurable states enables content approval at the page level across sites. Global administrator can manage all sites while site-specific admins are scoped to their site. No cross-brand approval hierarchies, no global content policy enforcement dashboard, and no automated compliance checks. The governance model is standard for a platform of this generation — functional but manual.

The on-premises license historically let an installation add sites for only infrastructure cost, not extra license fees, which gave a strong multi-brand cost case. With EOL on Dec 31 2026, about three months away and with no paid extended support, every brand on a KX13 installation must now fund a migration immediately. Kentico converts v13 licenses to Xperience by Kentico subscriptions, and the Migration Tool is free, which softens but does not remove that cost. Effective per-brand TCO is now dominated by migration. Lowered slightly from 54 as the runway shortened.

Xperience 13 removed the CSS Stylesheets application and site default stylesheet settings, and Portal Engine master pages no longer apply to live sites. Per-brand visual identity therefore lives in the MVC/Core live-site code: separate stylesheets, layouts and page templates per site, with templates optionally filtered per site. Brand differentiation is fully achievable but only through developer code and deployments. There are no design tokens, no theme inheritance, and nothing marketers can manage. The previous score credited admin-managed per-site stylesheets, which KX13 no longer offers.

Multilingual content management applies per-site with locale-specific content versions and translation workflows. Per-brand translation approvals are achievable by scoping translator roles to specific site content trees. Cookie consent and GDPR compliance settings are configurable per site. The combination of per-site permissions + multilingual workflow provides a workable brand-locale governance model, but it is managed through general permissions rather than a purpose-built brand-locale governance framework. No per-brand translation vendor routing.

Analytics in KX13 is per-site: each site has its own web analytics dashboard showing traffic, conversions, and campaign performance. There is no cross-site portfolio analytics dashboard comparing performance across brands. A global administrator can switch between site analytics, but no aggregated portfolio view exists. Cross-brand analytics requires exporting data to an external BI tool (Power BI, Google Looker Studio) via GA4 or custom export.

Workflow in KX13 is configurable per content type or per site, allowing different approval chains for different brand sites. Global administrators can audit workflow activity across all sites. Workflow steps, approvers, and email notifications are independently configurable per workflow scope. This provides genuine per-brand workflow independence. No central workflow audit dashboard showing cross-brand publishing SLA adherence, but individual workflow configurations are flexible and independently maintainable.

Shared content tree in multi-site installation allows a 'global' or 'corporate' site to hold content items that other brand sites can reference or display via widgets. Corporate-level press releases, legal disclaimers, and product announcements can be placed in a shared content area accessible to all sites. However, there is no controlled override model — child brands cannot adapt corporate content with local variants; they either use it as-is or duplicate it. Content syndication is push-only with no override governance.

Per-site GDPR consent management with cookie consent banners configurable per site. Data subject request handling is configurable per site. Accessibility settings and compliance-related page metadata can be managed per site. However, there are no publishing guardrails that prevent non-compliant content from going live, no automated accessibility checking, and no per-brand data residency controls (all data is in the shared SQL Server instance). Compliance is administered per-site but not enforced systemically.

KX13 has no centralized design system management capabilities. Shared Page Builder widgets constitute a de facto component library, but there is no versioning of the component library, no centralized change management for propagating widget updates to all brand sites, and no brand-extension model for customizing shared widgets. When a shared widget is updated in the codebase, all sites consuming it are affected with no staged rollout or per-brand override.

The Global Administrator role oversees all sites in the installation, and per-site roles let brand teams manage themselves. Users can hold roles on multiple sites. There is one sign-on for the whole installation, but built-in claims-based SSO is SAML 1.0 only (SAML 2.0 is not supported), so modern IdP federation needs custom external authentication. There is no automated per-brand provisioning or SCIM. This is functionally adequate central-plus-brand user management with a dated SSO story.

Shared page types (content types) in KX13 multi-site installations provide a global model inherited by all sites. Brand-specific field extensions require creating separate page type variants or adding optional fields to the global type — there is no formal per-brand extension model that preserves the base type cleanly. In practice, organizations using KX13 for multi-brand often create brand-specific page type copies, resulting in forked models. Shared models work when brands share identical content structure.

KX13 provides per-site analytics and reporting — each site has individual dashboards for web traffic, campaign performance, and e-commerce metrics. There is no portfolio-level executive dashboard aggregating content freshness, publishing SLA adherence, or capacity metrics across brands. The Global Administrator can switch between per-site reports, but there is no cross-brand roll-up view. Portfolio reporting requires data export to external BI tools.

Kentico Xperience 13 has built-in GDPR tooling: consent management, personal data collection/erasure APIs, and right-to-be-forgotten workflows — but the Data protection application requires the Enterprise license edition and developer implementation (by default Xperience provides no erasure functionality). As an on-premises product Kentico does not process customer data, so no vendor DPA is needed; the customer is data controller and processor. EU HQ (Brno, Czech Republic) gives organizational GDPR credibility. EOL Dec 31 2026 means no new compliance features — only security hotfixes through year-end.

Kentico does not offer a BAA and Kentico Xperience 13 is not HIPAA-certified. As an on-premises product, HIPAA compliance is entirely the customer's responsibility — the customer controls the hosting infrastructure and must implement appropriate safeguards. No healthcare-specific implementation guidance exists in v13 documentation. HIPAA compliance is implementation-dependent, not platform-provided.

GDPR tooling is built into v13 (Enterprise). CCPA can be addressed through the same consent management framework. On-premises deployment gives customers flexibility to implement regional requirements (PIPEDA, UK GDPR, LGPD) but Kentico provides no specific guidance or pre-built tooling for these. No FedRAMP, IRAP, C5, or HITRUST. EOL status means no new regulatory framework coverage will be added. Coverage is limited to GDPR tooling with no structured additional regional support.

Kentico's SOC 2 Type 2 attestation covers 'Xperience by Kentico' (the SaaS rewrite), not Kentico Xperience 13 (the legacy on-premises product). For an on-prem deployment no SOC 2 audit exists because Kentico does not operate the customer's hosting environment. The company's SOC 2-certified development culture provides indirect assurance of development security practices, but the attestation cannot be cited for regulatory procurement of v13 on-prem. Score reflects no applicable SOC 2 for this product.

Kentico holds ISO 27001 certification covering their ISMS and development organization, giving assurance that Kentico Xperience 13 was developed under ISO 27001-governed secure development practices. However, for on-premises deployments the ISO 27001 scope does not extend to customer hosting environments — the certification covers Kentico's operations, not the customer's deployment. No ISO 27018. Scores mid-range: more than 'no ISO 27001' since development practices are covered, less than infrastructure-scope coverage.

At the company level Kentico has a CAIQ Lite (CSA STAR Level 1 self-assessment) and an active HackerOne bug bounty program. These are company/SaaS-level attributes that provide partial relevance to v13's security posture. Not PA-DSS certified — the PCI compliance documentation explicitly states Xperience is not a certified PA-DSS application. No CSA STAR Level 2, FedRAMP, Cyber Essentials Plus, or HITRUST. CAIQ Lite plus HackerOne is a minimal additional cert portfolio.

On-premises deployment gives customers complete, contractual-free data sovereignty — data never leaves customer-controlled infrastructure. Customers can deploy to any datacenter, cloud region, or private environment. This is strong for data residency but lacks the structured vendor-managed multi-region SaaS options (the Azure region list belongs to the new SaaS product, not v13). No CDN residency leakage concerns inherent to the product. Score reflects high sovereignty capability without vendor-managed regional SaaS flexibility.

Built-in GDPR data erasure APIs and consent management with configurable retention exist in v13 (Enterprise license), but by default the product provides no erasure functionality — developers must implement it based on how their site stores personal data. Customers manage backup policies and retention in their own infrastructure — no vendor-managed backup SLAs apply. Content staging and database export tools provide data export capability. Right-to-erasure is API-based requiring developer implementation, not self-service for end users.

Kentico Xperience 13's system event log records user actions, security events and (optionally) object/page metadata changes, with a configurable size limit and simultaneous outputs to the database, a file on disk (App_Data/logEvents.log) and .NET trace, including a built-in Windows Event Viewer listener. Those file and Windows Event Log outputs let standard SIEM agents collect events without custom code, which is better than API polling alone. It stops short of 60+ because there is no native push connector, retention is a row-count cap rather than a time period, and roles with 'Clear log' permission can delete records, so the log is not tamper-evident.

Kentico Xperience 13's administration interface is built on older ASP.NET WebForms technology — not the modern React-based admin of the new SaaS product. The third-party page accessibility validation feature was deprecated and removed in May 2021 due to termination of the validation service. No formal WCAG 2.1 AA conformance report exists for the v13 authoring UI. No ATAG 2.0 assessment. EOL product status means no accessibility improvements are forthcoming.

No VPAT or ACR exists for Kentico Xperience 13. No Section 508 conformance statement applies to the current product. The only accessibility-related documentation is a 2009 DevNet article for an older CMS version (irrelevant) and the removal notice for the deprecated accessibility validation service. With EOL in December 2026 and security-only support, no VPAT will be produced. Score reflects complete absence of accessibility documentation for procurement purposes.

Kentico Xperience 13 has no generative AI for writing. The only official Kentico LLM module for v13 (Kentico/xperience-module-openai-azure) does page categorization only, not text generation. AIRA (generation, rewriting, summarization, AIRA Chat) is exclusive to Xperience by Kentico and was never backported to v13, which is in security-only support until the December 2026 EOL.

KX13 has no AI image generation, AI focal point or smart crop, and no automatic alt text. The Bynder DAM module only adds a picker, and its repository is archived. All of Kentico's AI media features (tagging, smart crop, alt text) are in AIRA for Xperience by Kentico.

KX13 ships built-in machine translation services for Microsoft Translator (Azure AI Translator) and Google Translate. You set them up by entering an API key under Settings → Content → Translation services. Machine services insert the translated text straight into the new page version. An advanced-workflow action step can send pages for translation automatically when the default-language version is approved, and a Creating machine services API lets developers add other engines. The previous score treated v13 as manual-only, which was wrong. It stays below 60 because the translation is classic neural MT: Enterprise license only, a 5,000-character limit per request, not usable in the submissions dialog, and no brand-voice or glossary controls and no quality scoring.

Kentico's official Azure OpenAI module (Kentico.Xperience.OpenAI.Azure.KX13 1.0.1, needs hotfix 13.0.142+) adds an Auto-Select button that picks the best-fitting categories for a page from its Text/LongText fields. That is AI taxonomy tagging, but it does not work on pages built only with Page builder. The repository was archived in February 2025 and the package has about 500 downloads. There is still no AI generation of SEO titles, meta descriptions or alt text, and v13 has no built-in XML sitemap.

KX13 has two lightweight AI assists, both official Kentico modules whose repositories are now archived: Azure OpenAI category auto-selection (archived February 2025) and Recombee recommendation routing (archived December 2025). Their NuGet packages still work, but Kentico takes no more issues or pull requests. KX13 has no smart scheduling, duplicate detection, bulk enrichment or AI-driven publishing triggers.

Kentico Xperience 13 has no agentic workflow capability. The AIRA agentic features (multi-step orchestration, approval gates) are exclusive to Xperience by Kentico. KX13's advanced workflows have action steps such as automatic translation and publishing, but no AI agent carries them out.

KX13 offers marketing reports, A/B test results with 'Chance to beat the original', and contact activity analytics. Contact scoring is rule-based, not ML. It has no AI content gap analysis, topic clustering, stale-content detection or editorial priority recommendations.

KX13 has no AI-powered content auditing. Its only quality tooling is the manual per-page Link checker and validation under Pages → Preview → Validate, and neither uses AI. Brand-voice and style compliance (AIRA Content Strategist) is exclusive to Xperience by Kentico.

KX13 has a built-in Azure Cognitive Search integration with scoring profiles and autocomplete, and there is an official Algolia module whose repository was archived in January 2026. The KX13 integration does not support Azure's semantic query type, vector fields or skillsets, so ranking stays keyword-based. Semantic or RAG search would need a fully custom external build.

The only ML personalization path is still the official Recombee module (Kentico.Xperience.Recombee.KX13), which recommends pages from each visitor's page views or from the content of the current page. Its repository was archived in December 2025. The packages still install, but the module now gets no fixes and needs a separate Recombee contract plus custom work, so it counts for less than before. Native KX13 personalization is widget-level and rule-based, with condition types that developers must build.

Kentico Xperience 13 has no MCP server, official or community. Kentico's MCP servers (Documentation, Content Types, Management API) all target Xperience by Kentico, and KX13 is not on the roadmap for one before its December 2026 EOL.

Every AI touchpoint in KX13 runs on the customer's own keys. The Azure OpenAI module has a Settings → Content → Azure OpenAI screen for your own endpoint, API key and model deployment name. The built-in machine translation takes your own Microsoft Translator or Google Translate API keys, and the custom machine-service API accepts any engine. It stays in the partial range because Azure OpenAI is the only LLM provider, it drives a single archived feature, and there is no multi-provider or data-residency configuration.

KX13 exposes a REST service, the Integration bus, custom Web API endpoints and the external Xperience API, all of which an AI integration could use. There is no GraphQL, agent-optimized endpoint, AI SDK or LangChain/LlamaIndex guide. KentiCopilot developer tooling targets Xperience by Kentico, apart from its KX13-to-XbyK migration help.

KX13's few AI touchpoints (machine translation, category auto-select) have no AI-specific governance: no prompt controls, AI audit trail, brand-safety filters or confidence scoring. The only human-in-the-loop review is the standard workflow approval. Machine-translated text lands in a new page version that can go through workflow before publishing.

KX13 has no AI usage dashboard, credit tracking or model analytics. Machine-translation errors such as bad credentials show up only in the generic Event log, and the character usage for translation or Azure OpenAI is visible only in the provider's own Azure or Google console.