Our client purchased Adobe Experience Manager (AEM) with the goal of bringing hundreds of retail, residential, and microsites into AEM. The existing sites had no national brand consistency, used a variety of different CMSs and agencies, and each site was filled with its own unique content. Tasked with bringing consistency to the sites for greater branding, control and cost efficiency, our solution was to design and build page templates to house individual standardized components that could be used as-needed across all individual properties.
We started the project with one main intention: stand up the first site in AEM, but keep a multi-site architecture in mind. Four hundred JIRA tickets, 35 components, lots of cache clearing and plenty of testing later, the first site went live. Basking in client delight and feeling the greatest difficulties were behind us, we began to work on the second site, which should have been a cake walk. We wanted to be able to add a new site in 30 days. Ultimately, what we achieved is that new sites can go-live in a matter of hours (pending content). Here are the five valuable lessons learned for a successful multi-site AEM implementation.
1. Do Not Hardcode – Use Configurable Global Settings
Whatever you do, do not hardcode a single element on the site. Multi-sites require that content authors have the flexibility to configure items which may not change once the site is live, but which do change between sites. For the second site, we built a Settings Page at the site-level that enables the content author to configure elements such as:
• Location Information, including address, city, state, company and Google Maps links
• Hours info
• Account information for social link channels
• 404 pages
• Design categories
2. Put thought into the DAM Hierarchy
Assets can get very messy, very quickly when you have multiple sites running on the same instance of AEM. Take time to discuss and identify the assets that are shared between sites and the assets are unique to a site. Even more importantly, take time to review the DAM setup with the content author, and monitor frequently.
3. Create Site / Page Structures That Can Live at Any Level
The structure of the site pages is also very important to content authors and for mapping/rewrite rules. Ensure that your development team is aware that pages can live at any level (L1, L2, L3, etc.) and do not assume a certain type of page will always be at a certain level.
4. Design Dynamic Components Carefully
Components that simply display some static piece of content that is local to the component typically work without a problem in a multi-site environment. However, more complex components with dynamic content should be designed with some multi-site forward thinking. For example, the search path should be configurable in the search results component, and the tag path should be configurable on the directory, so that it only pulls in tags specific to the site.
A blueprint essentially offers a turn-key solution for spinning up sites. From a development perspective, we define:
• The name of the blueprint
• Pages to be included in the blueprint (the site structure, as well as the extra pages, such as sitemap.xml,
robots.txt, 404 page)
• The Content / Page Layouts to be included in the blueprint
• Any restrictions for the blueprint (i.e. don’t allow the author to create an event detail page at a higher
level than the event landing page)
With the click of a few buttons, a new site is up and is ready for content to be entered. Whether the content can be curated in a matter of hours is another story.