/handbook/enterprise-consolidation/kentico-vs-wordpress/
What We Do
Digital Platform MigrationsKey SolutionsManaged ServicesStaffing SolutionsIndustriesProducts
Discovery
Strategic consultancy & project roadmap
Growth Services
On demand development & consultation
Site Maintenance
Annual maintenance. Done for you
QE Services
Testing across SDLC for assured quality
Hosting Migration
Move to a performant hosting with zero downtime
WooCommerce
Enterprise commerce delivered without lock-in
AI
Unlock real use cases and integrations
All Services
A suite of services for any need
Technology STACK
eCommerce
Scale your e-commerce with WooCommerce, integrations, and custom extensions for growth.
EasyEngine
Server management tool that makes using WordPress on Nginx easy.
Web Auditor
Performance Audit & Insights for your Website.
rtMedia
A complete media management plugin for WordPress.
Resources
About Us
CLEAR
Resources Enterprise website consolidation playbook WordPress vs Kentico
Topics
On this page
- Enterprise website consolidation playbook
- WordPress vs Kentico
- WordPress vs Sitecore
- WordPress vs AEM
- OnePress for unified WordPress
Multisite management in Kentico
Single instance, multiple sites (Multitenant)
Multiple single-site installations
Parallels with multisite setups in WordPress
Multisite orchestration: Kentico vs WordPress
Multibrand ecosystems: Kentico vs WordPress
Multilingual capabilities: Kentico vs WordPress
The bottom line
Last updated on May 26, 2026
Enterprise Multisite Consolidation: Kentico vs WordPress
While Kentico offers multisite orchestration, it’s often built as a complex, custom, Kentico-specific construct. This can result in a greater reliance on specialized talent, increased adaptability challenges, and higher costs when scaling or integrating new properties. Kentico is powerful but operates within its proprietary walls.
On WordPress, it’s different. Moreover, with solutions like OnePress, you get a system that’s flexible, cost-efficient, and ready to scale, without locking yourself into a proprietary ecosystem.
Let’s now examine how Kentico and WordPress compare in terms of multisite management, allowing you to make an informed choice.
Multisite management in Kentico
To truly understand Kentico’s multisite management, you first need to understand its basic models for handling multiple sites.
If you review Kentico’s official guidance, you’ll see that while “it depends” is the safe answer, they generally recommend going with multiple single instances of Kentico rather than a single shared instance serving various sites.
So what does “multiple single instances of Kentico” actually mean? And what’s the alternative?
Single instance, multiple sites (Multitenant)
Here, you can run all your websites under a single Kentico installation, sharing the same codebase, database, and admin interface. Each site is logically separated but resides in the same system. You can manage multiple domains and content trees, but without spinning up separate systems.
Multiple single-site installations
Here, each site runs in its own Kentico instance—separate codebase, separate database, separate admin UI.
If you’re considering how “multisite” the second model really is, it’s not “multisite” in the architectural sense; it’s “multi-site” only in the business sense. Kentico counts it as part of its multisite story because it positions it as another way to handle multiple properties. However, technically, it consists of numerous standalone environments.
So, yes, the second approach is technically “multisite” at the enterprise level, but only in terms of organizational strategy, not infrastructure. When Kentico recommends separate deployments, what they mean is: multiple multisite setups operating independently rather than one shared site cluster.
Parallels with multisite setups in WordPress
At rtCamp, we see WordPress multisite in two ways:
- Traditional WordPress multisite. Multiple sites in one shared WordPress installation (comparable to Kentico’s multitenant model).
- “Nontraditional” WordPress multisite. Multiple standalone WordPress sites that work together as a unified system.
When we handle enterprise consolidation projects, we often choose between these two approaches. And like Kentico recommends, many times it does make sense to have independent sites that operate in sync (sharing a design system, content hub, integration layers, governance models, workflows, and more) without really tying them into a single installation.
In WordPress, this involves having multiple standalone installs (often on the same server or hosting provider) with orchestration frameworks (like OnePress… more on this in just a bit) that enable them to behave like one cohesive ecosystem.
When you’re evaluating multisite, multibrand, and multilingual setups in a nontraditional multisite environment (i.e., multiple separate installations working together as one), “orchestration” encompasses everything you need to build, configure, and maintain to make those sites function as a single, coordinated system.
So, comparing Kentico and WordPress in this context is really about comparing how orchestration works for each.
Multisite orchestration: Kentico vs WordPress
In a “nontraditional” setup, “multisite” orchestration is about ensuring multiple installs talk to each other and share resources where it makes sense (content hubs, design systems, governance frameworks, features, integration layers, etc.).
When it comes to Kentico, there’s no single way to orchestrate such a setup. A Kentico development agency underlines that while there are many ways to create such a system with Kentico, “the most widespread solution is absolutely different websites with some functional parts, templates/layouts, page types that can be reused on each site, common users that can edit the sites, but with different content.” It further explains the different elements of such orchestration:
- ‘Shared Content’ site – stores all the shared content (news, articles, blog posts, etc.) that is used across multiple websites;
- ‘Site Template’ site – contains main structure that will be basis for all other websites;
- Sites themselves – initially created as a copy of ‘Site Template’, but updated with content that is only related to this site;
- Page templates/css stylesheets – define page structure and UI design;
- Custom Kentico modules – allow site pages management within the simplified interface;
Since multiple standalone Kentico Xperience installs don’t come with a built-in orchestration layer, teams that want them to share anything (content, assets, design systems, governance rules, etc.) must build it themselves. That typically means:
- Writing custom code/custom modules for synchronization and shared functionality.
- Using APIs (Kentico REST, GraphQL, or custom endpoints) to push or pull data between instances.
- Employing middleware (e.g., Azure Functions, custom microservices, or integration platforms) to support communications.
It’s “possible” because Kentico offers enough API surface and extensibility hooks to make it work, but it’s not native. You decide what’s linked, what’s independent, and how much effort you want to invest in keeping it all in sync.
While this approach works, it’s rigid and engineering-heavy.
Also, to be fair, Xperience by Kentico (the latest version) does enhance its multisite capabilities (through a shared content hub and more), but migration is a significant replatforming effort if you aren’t already on it.
Like Kentico, even in a nontraditional WordPress multisite model (where you’re not using built-in Multisite but separate WordPress installs), each site works independently.
And, again, like Kentico, you need to build the orchestration layer to make everything into a unified system. Something that we’ve done with OnePress.
For example, with OnePress, clients already syndicate content as needed across their family of websites via a shared content hub.
OnePress Central Content Hub in action
Enterprise websites also share design systems delivered and orchestrated through a dedicated plugin, enabling consistent branding and UI across sites:
Multibrand consolidation with WordPress
Custom features and functionalities are delivered smoothly within this framework.
Overall, enterprises using OnePress report savings of 50-80% in maintenance work, thanks to streamlined multisite orchestration and a scalable architecture.
Is OnePress the only way to achieve this?
No.
Can you build your own solution?
Absolutely.
But we already have this live multisite WordPress framework in production, supporting diverse enterprise needs across multiple sites and use cases.
If you’d like to explore how this can work for your organization, let’s discuss.
In all, while WordPress offers a rich ecosystem of APIs, hooks, and deployment workflows, connecting multiple standalone installs still requires intentional architecture — it’s just that it’s easier and simpler with WordPress.
Multibrand ecosystems: Kentico vs WordPress
In multibrand ecosystems, you want each brand to feel distinct (with its own visual identity, tone, and even unique features) while still benefiting from shared infrastructure.
With Kentico, getting your brands to work together requires a significant amount of custom work, including setting up this orchestration, also known as consolidation. While it supports brand differentiation well, maintaining distinct brand experiences across separate installations still requires heavier custom development.
- Each install runs independently, meaning brand-specific codebases and templates can diverge fast if not heavily governed.
- Brand guidelines and UI component libraries must be manually integrated into each site, with no “push once, apply everywhere” model, as a custom delivery pipeline is required.
- Design system reuse across separate installs usually means developer-heavy workflows.
With WordPress, this is a lot simpler:
With modern theming approaches (block-based themes, global style variations, and design tokens), you can create a brand-specific theme that inherits core layout and functionality from a shared framework, but swaps design and UX at the surface. In fact, this is precisely what we’re doing with our OnePress framework. OnePress
You can also handle governance through role-based controls and editorial workflows in each install, while still enforcing shared security, compliance, and performance standards centrally.
In all, scaling to new brands is faster: you can clone a baseline install, attach its shared resources, and have a production-ready brand site in days instead of weeks.
There are many benefits WordPress brings to multibrand ecosystems:
- Lower time-to-market for new brands with strong governance baked in.
- Lower ongoing design debt. It’s easy to maintain brand coherence without killing creative flexibility.
- No dependency on a specific dev team’s proprietary packaging workflow: brand orchestration can be done by in-house teams.
Multilingual capabilities: Kentico vs WordPress
When it comes to multilingual features, Kentico wins. It comes with native multilingual tools that work well in standalone sites. Kentico’s culture feature is definitely impressive.
However, across separate installs, you’re back to custom integration territory:
- You won’t get an automatic orchestration layer for synchronizing content or translations across sites.
- You’d need to build custom integrations or connectors to sync translation content between source and target sites.
- You’d have to manage language switchers and keep them aligned yourself.
All this integration work falls back on custom development.
To be fair, even with WordPress, you’re looking at all this work for setting up multilingual ecosystems.
That said, with WordPress, you’ve many mature multilingual solutions (WPML, Polylang Pro, MultilingualPress) that can be made to work across connected installs.
And in general, WordPress is easy to integrate with enterprise translation APIs (Smartling, Transifex) and to centralize glossary and memory across brands/sites.
Orchestration scripts can also be used to sync translated content across instances without breaking per-site independence.
Overall, while custom work is often necessary, WordPress’s flexibility, ecosystem, and integrations make multilingual enterprise setups more manageable and scalable over time.
The bottom line
In a nontraditional multisite world, where Kentico and WordPress must operate as a single, orchestrated ecosystem across multiple, separate installs, the real differentiator is how efficiently you can connect, govern, and evolve your different sites without introducing friction. In other words, the orchestration layer.
Kentico can deliver here, but the orchestration layer would be complex and not easily scalable.
WordPress, especially when paired with OnePress, thrives in this space because its ecosystem is inherently open, integration-friendly, and can adapt to work around the unique needs of your multibrand ecosystem.
Enterprise website consolidation playbook
PREVIOUS
Credits
Disha Sharma
Author
Disha Sharma
Author
Disha Sharma is a Content Writer at rtCamp with over a decade of experience at the intersection of technology, digital marketing, and enterprise content strategy. Her WordPress roots run deep, her …
Salman Ravoof
Editor
Salman Ravoof
Editor
Salman Ravoof is a Senior Technical Content Writer at rtCamp. He’s a self-taught developer who switched to writing, which means he’s actually built the things he writes about and broken a few produ…
Good Work. Good People.
Industry partnerships
Compliance certifications
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Company
Solutions
Subscribe to our newsletter and get a few email updates every month.
United States India
© rtCamp Inc. since 2009. All rights reserved.
Terms of Service · Privacy Policy · Trust Center
Cookie Consent
We value your privacy
We use cookies to give you the best possible experience. By clicking “Accept,” you consent to our use of cookies to improve site functionality, analyze usage, and personalize content and communications. Your privacy matters to us, and we are committed to handling your data responsibly and transparently. Please check our Privacy Policy for more details.
Manage PreferencesDon’t AllowAllow All
Why do we use cookies?
×
By clicking "Accept" or "Decline All" at the bottom, you consent to the use of cookies and other tools as described in our Cookie Policy in accordance with your settings and accept our Terms of Service.
Toggle EssentialEssential
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Geolocation Config
This cookie is used to store the consent settings based on the visitor's location.
30 days
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
Toggle CloudFlareCloudFlare
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
Name
Description
Duration
cf_clearance
Whether a CAPTCHA or Javascript challenge has been solved.
session
Toggle CommentsComments
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Toggle GodamGodam
GoDAM" is primarily a specialized WordPress plugin and media management service designed to enhance video hosting, marketing, and asset management directly within the WordPress dashboard.
Service URL: godam.io (opens in a new window)
Name
Description
Duration
user_image
Temporarily stores the path to the user's avatar or profile picture for quick rendering in the website header.
session
user_id
Stores the numerical ID of the logged-in user to maintain session continuity and basic site operations.
session
full_name
Stores the logged-in user's display name to personalize the site interface without needing database queries.
session
system_user
First-party cookie used to store basic application state identifying the current system user role.
session
sid
A generic session ID cookie used to maintain user state and functionality as the visitor navigates through the site.
session
Toggle Google reCAPTCHAGoogle reCAPTCHA
Google reCAPTCHA helps protect websites from spam and abuse by verifying user interactions through challenges.
Name
Description
Duration
_GRECAPTCHA
Google reCAPTCHA sets a necessary cookie (_GRECAPTCHA) when executed for the purpose of providing its risk analysis.
179 days
Toggle Google Tag ManagerGoogle Tag Manager
Google Tag Manager simplifies the management of marketing tags on your website without code changes.
Name
Description
Duration
cookiePreferences
Registers cookie preferences of a user
2 years
td
Registers statistical data on users' behaviour on the website. Used for internal analytics by the website operator.
session
Toggle StatisticsStatistics
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Toggle Factors AIFactors AI
Factors.ai is a B2B account intelligence and marketing analytics platform that helps Go-To-Market (GTM) teams identify anonymous website visitors, track buyer journeys, and measure the ROI of marketing campaigns.
Service URL: www.factors.ai (opens in a new window)
Name
Description
Duration
_fuid
It is sent to capture session details and track user behavior across your website to provide behavioral data and intent signals.
1 Year
Toggle Google AnalyticsGoogle Analytics
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
Name
Description
Duration
FPGSID
Stores a session or user identifier to track how visitors interact with a website. This helps Google Analytics measure website performance, user engagement, and usage patterns.
Session
FPLC
Used by Google Analytics to link visitor interactions and sessions across multiple related domains.
20 hours
FPID
A server-side Google Analytics cookie used as an alternative user identifier when third-party cookies are restricted.
2 years
_ga
ID used to identify users
2 years
_ga_
ID used to identify users
2 years
Toggle Jetpack StatsJetpack Stats
Jetpack's built-in visitor analytics. It records page views, referring sites, search terms, and outbound link clicks, and also carries the shared visitor-tracking library used by Jetpack Instant Search and WooCommerce Analytics.
Service URL: automattic.com (opens in a new window)
Name
Description
Duration
tk_aip
Stores a list of anonymous visitor IDs so they can be merged into one identity once a visitor is recognized.
Up to 5 years
tk_tc
Used once per page load to work out which cookie domain the Tracks library should use, then removed as soon as it's read back.
Session (deleted immediately after use)
tk_qs
Queues analytics events for Jetpack's Tracks library so none are lost if the page closes before they can be sent.
30 minutes
tk_ai
Stores a randomly-generated anonymous visitor ID so Jetpack's Tracks analytics library can link tracking events to the same visitor.
Session in wp-admin; up to 5 years on the frontend
Toggle Microsoft ClarityMicrosoft Clarity
Clarity is a web analytics service that tracks and reports website traffic.
Service URL: clarity.microsoft.com (opens in a new window)
Name
Description
Duration
CLID
Identifies the first-time Clarity saw this user on any site using Clarity.
12 months
ANONCHK
Indicates whether MUID is transferred to ANID, a cookie used for advertising. Clarity doesn't use ANID and so this is always set to 0.
Session
_clck
Persists the Clarity User ID and preferences, unique to that site is attributed to the same user ID.
12 months
_clsk
Connects multiple page views by a user into a single Clarity session recording.
12 months
Toggle Parse.lyParse.ly
Parse.ly is a content analytics platform that helps publishers optimize audience engagement and content performance.
Name
Description
Duration
cookies.js_dtest
This cookie determines whether the browser accepts cookies.
session
_parsely_session
JSON document storing information identifying a browsing session according to Parsely’s proprietary definition
30 minutes
_parsely_visitor
JSON document uniquely identifying a browser and counting its sessions
13 months
Toggle SalespanelSalespanel
Salespanel is a B2B marketing and sales software that identifies, tracks, and qualifies website visitors and leads in real-time using first-party data. It helps businesses monitor customer journeys, score leads based on behavior, and syncs this data with CRMs (like Pipedrive or HubSpot) to improve conversion rates.
Service URL: salespanel.io (opens in a new window)
Name
Description
Duration
track_uid
Identify and tracking a lead
12 moths
Toggle MarketingMarketing
Marketing cookies are used to follow visitors to websites. The intention is to show ads that are relevant and engaging to the individual user.
Toggle Bing / MicrosoftBing / Microsoft
Bing, powered by Microsoft, is a search engine providing web, image, video, and map search capabilities.
Name
Description
Duration
MR
Used to collect information for analytics purposes.
6 months
ANONCHK
Used to store session ID for a users session to ensure that clicks from adverts on the Bing search engine are verified for reporting purposes and for personalisation
10 minutes
SM
Used by Microsoft in synchronizing the MUID across multiple Microsoft domains to track users for advertising.
session
MUID
Identifies unique web browsers visiting Microsoft sites. These cookies are used for advertising, site analytics, and other operational purposes.
1 year
Toggle DoubleClick/Google MarketingDoubleClick/Google Marketing
A comprehensive digital advertising platform for managing campaigns, optimizing performance, and analyzing audience data.
Name
Description
Duration
IDE
This cookie is used for targeting, analyzing and optimisation of ad campaigns in DoubleClick/Google Marketing Suite
2 years
ar_debug
Store and track conversions
Persistent
Toggle LinkedInLinkedIn
LinkedIn is a professional networking platform for job seekers, employers, and industry connections.
Name
Description
Duration
bscookie
Used by LinkedIn to track the use of embedded services.
1 year
AnalyticsSyncHistory
Used to store information about the time a sync with the lms_analytics cookie took place for users in the Designated Countries
30 days
bcookie
Used by LinkedIn to track the use of embedded services.
1 year
li_sugr
Used to make a probabilistic match of a user's identity outside the Designated Countries
90 days
lidc
Used by the social networking service, LinkedIn, for tracking the use of embedded services.
1 day
UserMatchHistory
Used by LinkedIn Ads to synchronize and match user IDs across different ad networks and data providers.
30 days
Toggle LinkedIn InsightLinkedIn Insight
LinkedIn Insight is a web analytics service that tracks and reports website traffic.
Service URL: www.linkedin.com (opens in a new window)
Name
Description
Duration
li_sugr
Used to make a probabilistic match of a user's identity.
90 days
lidc
Used for routing and session management.
24 hours
Toggle LiveIntentLiveIntent
LiveIntent provides a platform for email advertising and identity-driven marketing solutions.
Name
Description
Duration
_lc2_fpi_js
Companion cookie to _lc2_fpi used by JavaScript to facilitate cross-domain ad tracking and user identification.
1 year
_lc2_fpi
First-party tracking cookie usually associated with LiveRamp to identify users across devices for targeted advertising.
1 Year
_li_ss
Sets a unique ID for the visitor, that allows third party advertisers to target the visitor with relevant advertisement. This pairing service is provided by third party advertisement hubs, which facilitates real-time bidding for advertisers.
1 month
lidid
Collects data on visitors' behaviour and interaction - This is used to make advertisement on the website more relevant. The cookie also allows the website to detect any referrals from other websites.
2 years
Toggle Cookie PolicyCookie Policy
You can find more information in our Privacy Policy.
Allow AllDecline All
Accept