How to structure editable templates for multi-site setups in AEM?

[AryaBa1]

Hi everyone,

We are building a multi-site architecture in AEM (eg for different brands or regions), and I am trying to determine the best practices for organizing editable templates.

Each site has its own design system and slightly different requirements, but we also want to reuse components and reduce duplication.

My question is:

• Should we create a separate editable template per site or try to use shared templates with conditional logic?

• How can we manage different policies (e.g., allowed components, styles) per site?

• What’s the recommended folder structure under /conf for clean separation and maintenance?

Any guidance would be appreciated!

Thanks!

[ShivamKumar]

Hi @AryaBa1 ,

Here's how you can manage editable templates in a multi-site AEM architecture:

1. Create separate editable templates per site.

• Design flexibility: Each brand/region may have its own layout, header/footer, or navigation rules.

• Policy isolation: Easier to configure component policies, allowed components, and styling without conflict.

• Avoids conditional logic: Prevents bloated templates with if/else logic based on brand or region.

• Future scalability: If a brand's requirements change significantly, you're already isolated.

2. Use site-specific policy paths under /conf/<site>/settings/wcm/policies.

• Policies define:

  • Which components are allowed in a layout container.

  • Which styles are available in the style system.

• Using separate paths per site keeps each brand’s configuration modular.

• Avoids unintentional cross-site changes.

How:

• In template editor, select policy paths under /conf/brandA/settings/wcm/policies/...

• Example structure:

  /conf/brandA/settings/wcm/policies/page-content
  /conf/brandB/settings/wcm/policies/page-content

3. Best Practice: Create a folder per site under /conf and mirror settings inside.

Recommended Structure:

/conf
  /global                        ← shared templates or styles (optional)
/conf
  /brandA
    /settings
      /wcm
        /templates               ← editable templates
        /policies                ← policy definitions
  /brandB
    /settings
      /wcm
        /templates
        /policies

• Keeps content authors and developers aligned by brand or region.

• Simplifies troubleshooting and onboarding.

• Isolates brand-specific changes from impacting others.

4. Reuse components, not templates.

• Build shared components in /apps/myproject/components/...

• Use them in all site templates by including the same resource type.

• Style variations (like color or layout) can be controlled via:

  • CAConfig (Context-Aware Configuration)

  • Style System

  • Site-specific clientlibs

[SantoshSai · Accepted solution]

Hi @AryaBa1,

I would suggest to use AEM’s MSM (Multi-Site Manager) to inherit structure but allow local overrides. Combine this with editable templates for flexible but controlled site management.

• Use a separate /conf folder per site or brand
  Example:

  /conf/site-us

  /conf/site-uk

  /conf/site-fr

  Each folder contains its own editable templates, policies, and design configurations.

• Create site-specific templates only when necessary
  If layouts differ significantly (eg. header/footer variations), make unique templates per site.
  If only components/styles differ, reuse templates and apply site-specific policies.

• Use dynamic templates + content policies
  Define a shared structure (eg. two-column layout) and apply different policies per site using template-type inheritance or cq:policy.

• Organize policies cleanly in the design dialog
  In each template, assign policies that limit the component set per brand or region. This keeps editors focused and reduces error risk.

• Use language-masters and live copy wisely
  For multilingual support, structure content under /content/site/language-masters and use live copies for locale-specific pages.

Hope that helps!

[AmitVishwakarma]

Hi @AryaBa1 ,

Folder Structure

Your /conf should reflect your site architecture clearly:

/conf
  /global                      => shared styles, policies, templates (optional)
/brandA
  /conf/brandA
    /settings
      /wcm
        /templates             => editable templates
        /policies              => component and style policies
        /designs               => optional, for style systems
  /brandB
    /conf/brandB
      /settings/wcm/templates
      /settings/wcm/policies

Templates Strategy

1. Use separate editable templates per site if:

  - Layouts, headers, footers differ per brand

  - You need isolated policy control

  - Teams work independently on site content

2. Use shared templates only when:

  - Layout is identical across brands

  - You handle branding via clientlibs, CAConfig, or policy variation

Avoid conditional logic inside templates (like data-sly-test on brand). It makes maintenance harder and breaks clarity.

Policies & Allowed Components

Each site gets its own policy path:

/conf/brandA/settings/wcm/policies/page-content
/conf/brandB/settings/wcm/policies/page-content

Assign allowed components and style system options per template via the Template Editor.

If components need brand-specific styling, use:
  - Style System (per-policy)
  - ClientLibs with brand-specific categories
  - CAConfig to inject site-specific values (logos, colors, etc.)

Component Reuse

All components go under a shared path:

/apps/myproject/components/

Build once, use everywhere. Brands override styles, not structure.

Multilingual / Regional Support

Use MSM + Language Masters:

/content/brandA/language-masters
/content/brandA/en
/content/brandA/fr
/content/brandB/language-masters

Use live copies for region/language variants

Use CAConfig for localization, regional configs

Regards,
Amit