How to Start Using Agility CMS for Multiple Sites- Guide | Agility CMS Docs

Using Agility CMS for Multiple Sites

Thinking of using Agility CMS to power multiple websites? With our flexibility, we make it easy to architect content models that can be used to power multiple websites. 

Depending on the nature of your organization, your branding, and your content itself, you have options for how you deploy your websites.

In most cases, you'll find that separate Sitemaps and Instances are what will work best for you.

Multiple Page Management Sitemaps

An Instance in Agility can have multiple Sitemaps. Each Sitemap can have different pages but utilize the same underlying architecture such as page templates, page modules, and content models. They are designed to support multi-tenancy where each sitemap has its own unique domain.

Some organizations utilize multiple Page Management Sitemaps in Agility to separate their sub-brands or microsites. They can easily reuse content and assets from the primary site on the additional sites.

Naming Convention Considerations for Sitemaps

Since sitemaps allow you to manage multiple websites within the same Agility instance, you should take some care to differentiate what Content (and their Models) and Page Modules are applicable to each sitemap.

For example, if you have two sitemaps, each sitemap can use the same Page Modules and have access to the same Content. This has some great advantages in that you can re-use Page Modules and Content Models across all sitemaps. 

However, there will likely be cases where some Content (and/or its underlying Model) or Page Modules are only intended for a specific sitemap. It's important to label these dependencies so that your editors are aware that certain content or page modules are only intended to be used with a specific sitemap.

Naming your Page Modules

If you are developing a page module that can be used across any sitemap, consider using a naming convention like Global {Page Module Title} (i.e. "Global Slider"). The word Global denotes that this Page Module can be safely used anywhere.

Respectively, if you have a Page Module that is designed to only be used on a specific sitemap, you should pre-pend it with a word references the sitemap. For example "Site B Slider".

Naming your Content Models

Content Models are used to initialize a content list or item. Similar to Page Modules, if Content Model can be safely re-used, it should be pre-pended with a word like Global (i.e. "Global Articles").

Where Content Models are a unique, is when you initialize a content list or item with it, you can set the name of the list/item. You may have a Global Content Model, however your list of content that you initialize off it, could be specific to a sitemap. You could name your list "Site B Articles".

Organizing your Content

Pages are already organized by sitemaps, but Content in Agility is meant to be globally available to all your pages. If you are creating Content that you know is specific to a sitemap, consider creating folders in your Content (area) for each sitemap and place the appropriate content within it.

For example:

  • Global [folder]
    • Global Articles
    • Global Footer
  • Site A [folder]
    • Site A Articles
    • Site A Header
  • Site B [folder]
    • Site B Articles
    • Site B Header

If you are looking for a clearer separation of concerns, look at using Multiple Instances to manage your websites.

Multiple Instances

An instance represents your Agility CMS project.

Agility allows you to manage multiple instances that are completely separate from each other in terms of the content, assets and editor team. In a multi-instance scenario, organizations can maintain a one-to-one ratio between an instance and a website. The security and workflow for each instance can be completely different from the next.  

In many cases, it makes sense to have multiple instances where there is also a primary instance that acts as the Content Hub for all content that's shared everywhere. You can read more about how to build a Content Hub.

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 micro-sites when all your pages can live on a single domain and is powered by the same website code.

Multiple Locales

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.

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

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.

SitemapsPage FoldersLocalesSeparate Instances
Site CreationAdd a new Sitemap, its Pages and Initialize ContentCreate a new Page Folder in your Sitemap, its Pages and Initialize its ContentCreate a new Locale, then Initialize Pages and Content for that languageCreate a new Instance, create Content Models, Initialize Pages and Content
Flexible Sitemaps per SiteYesYesNoYes
Shared Content grouped by SiteYesYesNoNo, each Instance has its own Content
Security Applied per SiteYes - via User PermissionsYes - via User PermissionsNoYes - via user access per Instance
Share same Website Deployment or HostYesYesYesNo - must be a separate deployment
Share same Page/Module/ContentYesYesYesNo
Reference Global or site-specific Content across sitesYesYesCustom - logic must be written to pull from specific localesCustom - can only be accessed using Content Fetch API
Content API is Secured by SitemapNo - the API is able to query all ContentNo - the API is able to query all ContentNo - the API is able to query all ContentYes - each site has its own API permissions
Domain Mapping to SitemapYes - each Sitemap is mapped to its own list of DomainsCustom - logic needed to rewrite paths without the folder nameCustomYes
Dedicated Preview for each SitemapYes - each Sitemap its own Preview URLCustom - logic needs to redirect to a Preview URL to the appropriate site domain and rewrite pathYesYes
URL RedirectionsYesCustom - logic required to handle rewritten paths without the site folder name YesYes
Support Editor URL Page PickerYesCustom - logic needed on the site to rewrite URLs used by editors to exclude the folder pathYesYes
Licensing ImpactYes - Sitemaps can be added to subscriptions for $100N/AN/AYes - requires a new subscription plan per instance