Loading articles
Core path · 22 of 34
Managing Shared Content Across Sites Without Losing Local Control
Running one AEM site is relatively simple.
Running the same site across ten countries is a different problem.
A company may start with a global site and later need sites for:
Most of these sites may share the same basic structure and a large part of the same content.
But they are rarely identical.
Germany may need different legal text. India may run a different campaign. Japan may need locally managed content. Some global changes should reach every market, while other sections should remain under local control.
Copying the original site for every market solves the initial creation problem.
It does not solve the maintenance problem.
This is the problem AEM Multi Site Manager (MSM) is designed to handle.
Consider a global site:
/content/company/global/en
The team needs versions for several markets.
Without MSM, one approach is to copy the site:
/content/company/us/en
/content/company/uk/en
/content/company/in/en
/content/company/de/de
Initially, this looks fine.
Each market has its own pages and can edit them independently.
Then the global team changes the navigation structure.
A new legal section is added.
A component is added to an important landing page.
A page is renamed.
Now somebody has to determine which changes need to be repeated across each market.
With five sites, this may still be manageable.
With dozens of sites, brands, and language variations, manual synchronization becomes part of the operating model.
That is where the design starts to break down.
MSM allows AEM to maintain a relationship between a source site and sites derived from that source.
Instead of treating every regional site as a completely independent copy, AEM can understand that one site was created from another and that some content should remain connected.
The source provides shared content or structure.
Regional sites can inherit that content while still allowing controlled local changes.
That gives us two things that normally conflict:
central reuse
and
local control
MSM is the mechanism used to manage that relationship.
Two concepts sit at the center of MSM:
The Blueprint represents the source from which other sites are derived.
For example:
/content/company/global/en
The global site may define:
A Live Copy is a site created from that source while maintaining an MSM relationship with it.
For example:
/content/company/us/en
/content/company/uk/en
/content/company/in/en
These are not simply copies of the global site.
They can maintain inheritance relationships with the source.
That relationship is what allows changes from the source to be rolled out later.
This distinction matters.
If you copy a page, you get another page.
After the copy, both pages can evolve independently.
If you create a Live Copy, you are creating a relationship.
That relationship has consequences.
A source change may later affect the Live Copy depending on:
So before creating a Live Copy, the architectural question should be:
Should this content continue to follow the source?
If the answer is no, a normal copy may be more appropriate.
MSM should not be introduced just because two sites initially look similar.
Creating the relationship is only part of MSM.
The next question is:
What happens when the source changes?
This is where rollout comes in.
A rollout propagates changes from the source to its Live Copies according to the configured MSM behavior.
Suppose the global team updates:
/global/en/products/product-a
and corresponding Live Copies exist under regional sites.
A rollout can propagate that source change to the connected Live Copies.
This is very different from maintaining unrelated copies.
AEM knows that the content participates in an MSM relationship.
Not every source change should produce the same downstream behavior.
AEM uses rollout configurations to define what happens when content is rolled out.
Depending on the configuration, MSM actions can deal with operations such as:
The important architectural point is not memorizing every rollout action.
It is understanding that:
MSM propagation is controlled behavior, not simple repository copying.
That control becomes important when regional sites have different ownership requirements.
Inheritance determines whether a Live Copy continues to receive a particular value from its source.
Suppose the global page contains:
Explore Our Latest Products
The India site initially inherits that headline.
Later, the India marketing team wants:
Explore Products Available in India
If the field continues to inherit from the source, a global rollout may replace the local value.
The local team therefore needs a way to stop inheriting that property where local ownership is required.
This is one of the most important parts of MSM.
Without controlled inheritance, local teams cannot safely customize their sites.
A local market can cancel inheritance for content that needs to diverge from the source.
Once inheritance is canceled for that content, the local value can be maintained independently.
This gives the regional team control without requiring the entire page to become independent.
For example, a product page may still inherit:
while maintaining a local:
That is much more useful than treating the whole page as either completely global or completely local.
Local ownership does not always need to be permanent.
A market may temporarily diverge from the global content and later decide to follow the source again.
Inheritance can be restored where appropriate.
That makes inheritance a lifecycle decision.
The important part is knowing which team currently owns which part of the content.
Without that clarity, MSM becomes difficult to operate regardless of how well it is technically configured.
These terms are sometimes used loosely, but the direction matters.
A rollout starts from the source and pushes changes toward Live Copies.
Synchronization is performed from the Live Copy side to bring it back in line with its source.
Both operate on the MSM relationship, but they are initiated from different contexts.
For troubleshooting, this distinction matters.
If a regional page is out of sync, the first question should not be:
Why didn't AEM copy the page?
Instead, check:
MSM problems are usually relationship problems before they are rendering problems.
This distinction is important in multilingual implementations.
MSM manages content inheritance and site relationships.
It does not automatically solve translation.
For example:
/global/en
/de/de
/fr/fr
MSM can help establish and maintain relationships between the site structures.
But English content still needs to become German or French through the project's translation process.
Translation and MSM may work together, but they solve different problems.
MSM answers:
How are these sites related?
Translation answers:
How does this content become available in another language?
Mixing these responsibilities leads to confusing site architectures.
Another common source of confusion is treating every localized site as the same type of relationship.
A site architecture may involve both:
For example, an organization may maintain a language master and then create country-specific Live Copies from it.
The exact hierarchy depends on how the organization owns content.
The repository structure should reflect that ownership model rather than being copied from another project simply because it uses MSM.
Before defining the structure, architects need answers to questions such as:
Those answers matter more than the folder names themselves.
A multi-country implementation might have a structure conceptually similar to:
/content/company/language-masters/en
/content/company/language-masters/de
/content/company/us/en
/content/company/uk/en
/content/company/in/en
/content/company/de/de
The language master provides centrally managed content.
Country sites can be created as Live Copies where the business requires inheritance.
But this structure is not a rule for every AEM project.
Some organizations organize by brand first.
Others organize by region.
Others have stronger country ownership and use less inheritance.
The repository should follow the actual content operating model.
MSM becomes difficult when everything inherits from everything else.
A deep inheritance hierarchy may look efficient because content is reused at several levels.
In practice, it can become difficult to answer a basic question:
Where is this value coming from?
If a page inherits from a country master, which inherits from a regional master, which inherits from a global master, every local change has to be understood in that chain.
Deep inheritance also increases the impact of rollout decisions.
Use inheritance where there is a real ownership relationship.
Do not create another MSM level simply because AEM allows it.
Before configuring MSM, classify the content.
Examples may include:
The central team may own this content.
Examples may include:
The local team may own this content.
This is usually where MSM provides the most value.
The global team provides the starting point, while regional teams can modify specific parts.
This boundary should be decided before rollout configurations are designed.
Otherwise, technical inheritance rules end up defining business ownership by accident.
Consider a global product launch.
The global team creates:
/products/product-a
The page contains:
The page is rolled out to several country sites.
The US site may use most of the global content unchanged.
The India site may require:
Germany may require translated content and country-specific compliance information.
The right design is not necessarily to disconnect each country page from the global source.
Instead, determine which parts should remain inherited and which parts should become locally owned.
That is the real value of MSM.
It lets the architecture reflect the organization's content ownership model.
MSM is difficult to operate when teams do not know what a rollout will change or who is responsible for local and shared content. Authors may avoid rollout, leaving sites out of date even though the technical configuration is working as designed.
When an MSM change does not behave as expected, start with the relationship.
Check:
Do not start by debugging the component if the repository content itself was never synchronized.
Check whether the content was still inheriting from the source.
A local author may have changed a value without establishing the intended local ownership boundary.
The page can appear correct until the next rollout exposes the problem.
This is why inheritance behavior should be part of author training, not only developer documentation.
Because one rollout can affect many sites, define these rules before production:
A production implementation should define:
For large implementations, teams should also understand the impact radius before rolling out major structural changes.
A change that is small in the source can become a large change when dozens of Live Copies depend on it.
MSM reduces duplicated maintenance.
But it introduces dependency between sites.
The more a regional site inherits from the global source, the easier it is to keep sites aligned.
At the same time, the regional site has less independent control.
If inheritance is broken everywhere, local teams gain flexibility, but the value of the Live Copy relationship starts to disappear.
So the goal is not:
Inherit as much as possible.
It is:
Inherit where ownership is genuinely shared, and allow local control where the business requires it.
That boundary is different for every organization.
MSM encodes dependencies between sites. Architects need to make ownership and rollout boundaries explicit before selecting Blueprints and rollout configurations; more technical rules cannot compensate for unclear ownership.
So far, the series has covered the content and authoring side of AEM architecture.
We now have Pages, structured content, reusable experiences, content models, and multi-site inheritance.
The next part moves into the backend layer.
When a component needs Java logic, the first question is usually:
How should the component expose backend data to HTL without putting business logic into the presentation layer?
Chapter 23 — Sling Models starts the AEM Backend Architecture module.
Get an email when I publish the next chapter. No spam — just new technical deep-dives.
Comments
Share feedback or questions about this blog post.
No comments yet. Be the first to share your thoughts.