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 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.
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|