Using Agility CMS for Multiple Sites

With Agility CMSs flexibility, we make it easy to architect a content model that can be used to power multiple websites.

There are different approaches to take, each with their own benefits so we recommend reviewing these options to see what is the best fit for your case.

Approaches to Managing Content for Multiple Sites


Channels are unique sitemaps that you can manage within Agility CMS.

Each site can have different pages but utilize the same underlying architecture such as page templates, modules, and content definitions. They are designed to support multi-tenancy where each site has its own unique domain.

Page Folders

Page folders are ways to organize a set of pages within one of your Channels.

This allows you to create folders in your sitemap to represent each site you have. This model works great for microsites when all your pages can live on a single domain.


While not designed for this purpose, you can utilize an additional Language locale to represent a new site.

This works well for when you have pages that will be identical in layout across all your sites. Simply initialize the content in the other language and you can pull that into your website.

Separate Instances

An instance represents your Agility CMS project.

You can create as many instances as you'd like. They are designed to be used for distinct properties where content and your models cannot be accessed or shared across instances. Instances have their own list of users that are granted access to them, making it easy to manage security across teams.

Access vs Permissions

An Agility CMS instance grants access to users. This is managed by admins. If a user has access to an instance, further permissions may be applied to that user so that they either can or cannot modify specific content lists, pages, or groups of pages.

It's important to note that users that have access to an instance can see all content and pages listed in the CMS, but depending on their permissions may not have access to view or edit them. If you need to separate different teams from seeing each other's content, consider using separate instances.


  Channels Page Folders Languages/Locales Separate Instances
Site Creation Add a new Channel, its pages, and initialize its content Create a new Page folder in your Channel, its pages, and initialize its content Create a new language, then initialize the pages and content for that language Create a new instance, create definitions, initialize pages and content
Flexible Sitemaps per Site Yes Yes No Yes
Shared Content grouped by Site Yes Yes No No - each instance has its own list of Shared Content
Security Applied per Site Yes - via user permissions Yes  - via user permissions No Yes - via user access per instance
Shares same Website Deployment/Host Yes Yes Yes No - must be a separate web app
Shares same Page/Module/Content Definitions Yes Yes Yes No
Reference global or site-specific content across sites Yes Yes Custom - logic must be written to pull from specific languages Custom - can only be accessed using the Content Fetch API
Content API is Secured by Site No - the API is able to query all content No - the API is able to query all content No - the API is able to query all content Yes - each site has its own API permissions
Domain Mapping to Site Yes - each channel is mapped to its own list of domains Custom - logic needed to rewrite paths without the site folder name Custom Yes
Dedicated Preview for each Site Yes - each site has its own Preview URL Custom - logic needed to redirect a preview URL to the appropriate site domain and rewrite path Yes Yes
URL Redirections Yes Custom - logic required to handle rewritten paths without the site folder name  Yes Yes
Supports Editor URL Page Picker Yes Custom - logic needed on the site to rewrite URLs used by editors to exclude the folder path Yes Yes
 Licensing Impact Yes - Channels can be added to subscriptions for $100 N/A  N/A Yes - Requires a new subscription plan per instance
3 out of 3 found this helpful



Article is closed for comments.