Reusing Content across Multiple Web Properties

Content is valuable, but duplicating it is something you'd like to avoid. When you need to use the same content in multiple places, Agility makes it easy to do that. Often when we think of digital destinations for content, we think of websites. Agility lets you manage multiple websites inside a single instance using Page Management sitemaps, and we'll show you how that is the easiest way to reuse content. You might also want to use a single Agility instance as a Content Hub, and in that case you'll use the Content APIs to distribute and reuse the content in the Content Hub.

Let's dig into both cases.

Reusing Content across Multiple Sitemaps

Using multiple sitemaps within a single Agility instance is an effective way to maintain all of the content for numerous websites in a single place. It's also the most straightforward scenario for content reuse, since it allows a single team to manage all of the content for those websites. Your team will be able to find and update content easily just by navigating or searching in the page tree to find out what content is on a particular page.

Your content team can reuse any modules in the instance many times across each sitemap. The development team should emphasize ease of reuse when designing the module structures as part of the overall Content Architecture.

Reusing Content from a Content Hub

Content Hubs provide tremendous value for content reuse. You will need to consider the various possible destinations for your content when designing the Content Architecture for a Content Hub. It probably doesn't make sense to use a rich text or HTML field when displaying content in a fixed size on a mobile device.

When architecting websites that will be consuming content from a Content Hub, you will need to treat that content just like any other data source. For instance, you'll be pulling that content into the website using the Agility API or an SDK, depending on which development framework you're using.

From your editors' perspective, they won't necessarily know where users will be consuming the content. You may want to provide guidance to your editing team to help them format content in an output-neutral way.

Knowing Where Reused Content Will Appear

Once the same content can appear in more than one place, editors don't always know where it will be consumed, and that uncertainty is worth designing away. There are two clean options depending on your content. If a single item genuinely could go to several destinations, add a destination selector field so editors can choose where it appears. If each item only ever belongs to one property, group your containers by destination so the structure itself makes it obvious. In both cases, the development side filters or routes content based on those signals.

For the full set of patterns — selector fields, container grouping, sitemaps and channels, development logic, and external orchestration layers — see Publishing to Multiple Destinations.