dotCMS Content Engineering: The Multi-Site Strategy Deep Dive

When you’re building and managing thousands of websites for a distributed network of partners, the key challenge isn’t just scale, it’s control. How do you give each site its own digital identity while keeping the experience cohesive and manageable?

In this post, Solvisse unpacks how they engineered a multi-site architecture on top of dotCMS to support thousands of partner websites, without drowning in complexity.

Why Solvisse Chose dotCMS for the Core

dotCMS offered the hybrid flexibility Solvisse needed: structured content models, headless APIs, and multitenancy support via “hosts.” This was critical. We didn’t just want to clone sites—we wanted a single source of truth with modularity and reusability baked in.

At the heart of our implementation sits a centralized dotCMS instance powering every site. But to make it work at this volume, we had to design a layered system that logically separates responsibilities while encouraging shared components.

Hosts: The Building Blocks of Multitenancy

In dotCMS, each Host represents a logically distinct website. Think of it as a semi-isolated tenant within the main instance. Each partner website is mapped to its own host, allowing content, templates, and metadata to be scoped appropriately.

Types of Hosts in Our System:

• Partner Sites: Individually branded, editable by the partner via PartnerCMS.

• Core Host: Contains shared templates, containers, reusable content, shared pages, and global header/footer logic.

• Shared Host: Houses custom content shared across partner groups (e.g., editorial content, localized banners).

• Seed Sites: Template sites used to bootstrap new hosts with brand-specific default content and structure.

Content Engineering: Structured for Reuse, Built for Flexibility

Each host follows a consistent structure and relies on contentlets, containers, and templates to define and display content. Here’s how Solvisse made that scalable:

Content Types & Contentlets

• Strict content types were defined to model each component (e.g., banners, tiles, videos, search widgets).

• These types allow both marketing and partners to reuse logic and avoid duplication.

• Contentlets are the individual instances of these types, scoped either locally or shared across hosts.

Templates & Containers

• Templates define page layout; containers identify and manage content zones (e.g., carousels, sidebars, CTAs).

• Containers are centrally maintained in the Core host and referenced across all other hosts.

• Each maps to a .vtl file that governs how the content is rendered and injected dynamically.

• This model minimizes design drift and simplifies global design updates.

First-Level Contents

A key architectural decision was the introduction of First-Level Content—a foundational layer of contentlets created on every site. These contentlets are designed to be persistent and non-deletable, forming the structural entry points for each page. Their primary function is to reference Second-Level Content, which can be either shared or localized—such as images, videos, and banners.

By anchoring each page to a predictable set of First-Level Content, we ensure consistent layout and query behavior across the ecosystem. For instance, a BannerCarousel contentlet holds configuration data like autoplay behavior and display titles while referencing a set of images that define the actual banner visuals. This layered approach enforces structure while allowing partners to swap out content within predefined safe zones.

Shared vs. Local Content

Each site blends shared content from the Core host with local, partner-specific content. dotCMS’s cross-host referencing capabilities allow this to happen seamlessly, enabling reuse and scalability.

Shared Pages and Virtual Presentation

Instead of duplicating static pages across thousands of sites, we implemented a virtual path strategy to balance scalability with editorial control. Pages under the /vacation path represent centrally authored, globally syndicated content. Pages under /editorial are created by partners but rendered as if they exist under their own subdomains.

To make this possible, we built a set of custom interceptors via an OSGi plugin for dotCMS. These interceptors hook into the request pipeline and analyze the HTTP path and host header. For requests to /vacation or /editorial, the plugin identifies the content source, fetches the corresponding object (regardless of its physical host), and renders it dynamically in the context of the requesting domain.

This plugin-based approach allows us to decouple content storage from content presentation. Marketing maintains centralized control over shared assets, while partners create and publish content that appears native to their site. The result is a clean, multi-tenant user experience without duplicating assets or hardcoding logic.

Rendering Logic: VTL and Dynamic Resolution

Each page request follows a standardized flow:

1. WAF Layer (e.g., Imperva) inspects and secures incoming traffic.

2. dotCMS Resolver determines the correct host using the preserved host header.

3. VTL Rendering dynamically builds the page from containers and contentlets.

Example:

GET jdoe.mycompany.com/about-us

→ routed to dotCMS

→ host header = jdoe.mycompany.com

→ renders /about-us from the corresponding host context

This system supports clean URLs, SEO-friendly structure, and scoped content resolution—regardless of content location.

Meta Tags: Structured, Scoped, and Automated

To ensure SEO compliance at scale, we implemented a three-tier meta tag system: Global, Brand, and Page. Each layer is editable in a controlled way depending on its scope.

• Global Tags (e.g., viewport, charset) are injected via a shared VTL file, which is rendered on every site.

• Brand-Level Tags (e.g., og:brand) live in a dedicated brand host and apply across all sites under that brand.

• Page-Level Tags are configurable by the partner via PartnerCMS—empowering them to manage titles and descriptions for pages they control.

For shared content like marketing editorials, the central marketing team manages metadata directly in dotCMS using structured contentlets. This model enables both consistency and flexibility while maintaining strict governance.

Creating New Sites in Minutes

New partner sites are provisioned automatically through an orchestrated pipeline driven by brand-specific Seed Sites and a set of background CRON jobs.

1. The system clones the appropriate Seed Site and initializes default structure, pages, and containers.

2. A domain is assigned and registered as the site’s unique key.

3. Scheduled CRON jobs populate partnerdata and siteconfig contentlets via secure external API calls, injecting identity, branding, and business logic.

4. Additional CRON-driven jobs fetch rendered headers and footers from dotCMS, then cache them in Redis for rapid delivery across multiple platforms.

Within minutes, the new site is live, fully branded, and ready for customization by the partner. This modular automation pipeline enables rapid, repeatable, and reliable onboarding at scale.

Conclusions

Building a robust multi-site platform for a distributed network of partners requires a strategic blend of architectural foresight and precise content engineering. By leveraging dotCMS’s hybrid capabilities, specifically its host-based multitenancy, structured content models, and extensible API, we at Solvisse created a system that balances centralized control with localized flexibility.

Our layered approach, from the strategic use of First-Level Content and Seed Sites to the implementation of virtual presentation and automated provisioning, demonstrates how to manage complexity while enabling rapid deployment and consistent branding across thousands of independent digital presences. This architecture not only solves the scale challenge but also empowers partners to tailor their digital identity within a well-governed framework, ultimately driving efficiency and brand cohesion across the entire network.