Multi-Site Architecture

Organizations rarely have just one website. There is the corporate site, the product site, the support portal, regional variants, campaign microsites, and partner portals. Managing each as a separate CMS instance means duplicated content, inconsistent branding, separate user accounts, and multiplied maintenance costs.

Multi-site architecture lets you run multiple websites from a single Optimizely CMS instance. You manage content, users, and assets in one place while serving distinct sites to visitors.

A single CMS instance can host multiple sites. Each site has its own:

• Domain mapping — One or more hostnames route to the site
• Start page — A unique root in the content tree
• Content tree — A dedicated branch of pages under the start page
• Settings — Site-specific configuration for language, defaults, and features

All sites share the same CMS application, database, and admin interface. Editors switch between sites using the site selector in the editor toolbar.

In a multi-site setup, the content tree looks like this:

Root
  /corporate-site     -> www.example.com
    /about
    /news
    /careers
  /product-site       -> products.example.com
    /features
    /pricing
    /documentation
  /support-portal     -> support.example.com
    /knowledge-base
    /contact
  /shared-content     -> (no domain, internal only)
    /global-blocks
    /shared-media

Each top-level node acts as a start page for its site. The /shared-content node holds reusable content available to all sites.

Content sharing is the primary benefit of multi-site. Without it, you are just running separate sites in the same database.

Create a shared content area outside any site-specific tree. Store blocks like headers, footers, legal disclaimers, and brand assets there. Any site can reference these shared items through ContentReference or ContentArea properties.

When you update a shared block, the change reflects on every site that uses it. This is powerful but requires discipline. Changing a shared footer affects all sites simultaneously.

Pages on one site can link to pages on another within the same instance. The CMS resolves the correct domain automatically.

Not everything should be shared. Market-specific promotions and localized legal content belong to individual sites. Keep these in site-specific content trees.

Each site needs at least one hostname. You can configure a primary hostname, additional hostnames, language-specific domains (e.g., fr.example.com), and wildcard patterns. Set up redirects from non-primary hostnames to the primary one to prevent duplicate content in search engines.

Multi-site is not always the right answer. Use this decision framework:

• Sites share significant content (brand assets, legal text, product data)
• The same team manages multiple sites
• Sites share a user base or authentication system
• You want consistent content types and editing experience across sites
• Budget favors a single infrastructure over multiple deployments

• Sites have fundamentally different content models
• Different teams with different release cycles own each site
• Sites have conflicting security or compliance requirements
• One site’s traffic patterns would impact another’s performance
• Sites need different CMS versions or configurations

• Plan the content tree before building. Restructuring a multi-site content tree after launch is disruptive. Map out which content is shared, which is site-specific, and where the boundaries lie.
• Standardize content types. All sites in a multi-site instance share the same content type definitions. Design types that work across sites rather than creating site-specific types.
• Isolate access rights by site. Give each site’s editors access only to their content tree and shared resources. This prevents accidental cross-site edits.
• Monitor performance per site. One site’s traffic spike should not degrade another’s. Track response times per site.
• Test cross-site scenarios. Shared content updates, cross-site links, and language fallback all need testing.
• Document the site map. Record which domains map to which sites and which teams own each.