Experience Edition

Setting Up Experience Edition in AEM — What Actually Works

I've been deploying AEM sites for about eight years, and Experience Edition keeps coming up as one of those things people read about in documentation but don't fully understand until they're three weeks into an implementation and the preview pages aren't publishing correctly. This isn't a pitch. It's just the process I ended up using after tearing my hair out over dispatcher cache rules and asset sync delays. Experience Edition in Adobe Experience Manager is essentially the frontend-facing deployment layer that serves published, rendered content to end users. It's not the authoring environment — that stays on the Author instance. The Experience Edition instance runs in publish mode by default and connects back to the Author for content synchronization, asset delivery, and dynamic personalization logic. Think of it as the thin web-facing shell that handles traffic, caching, and rendering.

What Experience Edition Actually Is

The simplest way to think about it: Author is where editors create and manage content. Experience Edition (the Publish instance configured as such) is where that content becomes publicly visible. The distinction matters because misconfiguring the Publish instance as if it were an Author instance will cause problems immediately — particularly around permissions, storage configurations, and the way Sling models resolve paths. When you set up Experience Edition, you're really configuring a Publish instance with specific optimizations: tighter cache policies, read-only access to certain content structures, reverse proxy compatibility, and often OSGi bundles tuned for serving rather than editing. The core content repository structure is the same as Author, but the runtime profile is dramatically different. I ran into a case where a team cloned their Author configuration almost directly into a new instance thinking they could flip a switch and call it Experience Edition. The instance came up, sure, but content updates from Author weren't propagating past the first replica. The issue wasn't the replication agent — it was that certain OSGi configurations tied to the Author runmode were still active, and one of them was interfering with the replication consumer. The fix was stripping out the non-publish runmode bundles and re-registering the replication agent with explicit content filter paths instead of the wildcard they'd inherited from Author.

Configuring the Experience Edition Instance

Instance Setup and Launch Configuration

Start with a clean Publish instance from the AEM ArcGIS or the quickstart JAR. Do not copy configuration from an Author instance. The JVM parameters, JVM heap size, and thread pool allocations differ enough that this shortcut causes issues later. Set your JVM heap to at least 4 GB for a production Experience Edition instance, ideally 8 GB if you're handling more than moderate traffic with dynamic content personalization. In the launchpad configuration, ensure you have these bundles active:

• Adobe Granite Replication Agent Handler
• AEM Social Publishing (if applicable)
• WCM Core Components
• Asset Share Common or your preferred DAM integration
• Dispatcher flush handler or the equivalent cache invalidation service

Disable anything Author-specific: Content Fragment editing tools, Asset Migration tools, any bundle with Author in its symbolic name, and the built-in debugging servlets that expose repository paths in error responses. This is where most people lose time. The default replication agent on a Publish instance points inward by default. You need to create an outbound agent that targets your Author instance or, in a cloud-structured setup, the appropriate AEM as a Cloud Service ingestion point. Configure the agent with these settings:

Transport: HTTP/HTTPS to the Author instance's /bin/replicate endpoint.
Handler: Use the default handler, but set the filter to only replicate the content paths your Experience Edition site actually needs. Don't replicate everything under /content — that includes assets, DAM metadata, and system nodes that either don't need to sync or will cause conflict errors on the Publish side. I once spent two days debugging why certain pages on Experience Edition were serving stale content after the Author updated them. The replication was technically succeeding — the agent showed green status — but the dispatcher on the Experience Edition side was holding cached versions for the full TTL. The fix was adjusting the dispatcher's invalidate cache configuration to respond to the ACTIVATE replication action rather than relying on the default behavior, which in that environment wasn't triggering cache purges reliably. Setting Dispatcher's /cache/invalidateCache directive with the proper handler dramatically improved consistency.

Dispatcher and Caching Layer

Experience Edition almost always sits behind a dispatcher or equivalent CDN layer. The dispatcher configuration you use on this instance is more critical than on Author because it's what defines what visitors actually see. Key dispatcher rules for Experience Edition: /allow all sections should restrict GET and HEAD to published content paths only. Don't leave open endpoints that expose the Sling servlet resolver or OSGi console. Those exist but shouldn't be accessible through the public-facing path.

The /cache section needs to define which content types get cached. HTML pages, yes. JSON API responses used by personalization, probably not unless you're using client-context with aware caching headers. Dynamic form submissions and analytics events must never hit the cache. Set your gzip compression to at least level 6. The difference in page load times between uncompressed and compressed HTML is significant, especially on Experience Edition where mobile traffic often dominates.

Personalization and Client Context

If your Experience Edition setup includes personalization — and most enterprise deployments do — you need Client Context properly configured. This isn't optional if you're serving different content variants to different audiences. Client Context runs on the Publish instance and evaluates visitor segments before the page renders. The profile data flows from the Author instance through replication, but the actual segment evaluation happens at request time on Experience Edition. Make sure your segment definitions are replicated correctly and that the Client Context OSGi config points to the right segment provider. A mismatch here will cause every visitor to see the default variant, which looks like a broken personalization setup until you dig into the segment evaluation logs. The personalization routing in Experience Edition can also be affected by URL structure. If you're using path-based targeting (e.g., /content/sites/us/en vs /content/sites/eu/en), verify that your page components are reading the correct localization context and not defaulting to a fallback that returns the wrong variant.

Common Problems and Fixes

Content not appearing after publication is the #1 issue, and it's almost never what people think. Check these in order: 1. Is the replication agent actually active and connected? The status screen in the AEM Console will tell you, but the status alone isn't enough — check the agent's delivery log for specific error messages. Silent failures here are common. 2. Is the dispatcher cache blocking the update? Clear the dispatcher cache manually from the Experience Edition instance using the flush agent or by hitting the dispatcher's flush endpoint. If the cache clears and the content appears, your TTL settings are too aggressive for your content update frequency.

3. Is the page itself published and activated? Sometimes the content node is replicated but the page resource isn't marked as published. Check the jcr:content node's published flag and the sling:resourceType chain. Another problem I see frequently: Experience Edition instances crashing under load because someone configured the instance with Author-level JVM settings. Author instances run more threads because they handle concurrent edit sessions, form submissions, and workflow processing. Publish/Experience Edition instances don't need those same thread counts. Reduce your thread pool size and increase your cache sizes instead. This usually cuts memory usage by 30-40% while actually improving response times because the JVM spends less time on garbage collection cycles. Asset rendering delays on Experience Edition often trace back to the DAM sync configuration. If your assets aren't showing up in published pages, check whether the Asset Publisher or Image component is resolving the asset path correctly. Sometimes the path stored in the page content references the Author's asset repository structure, which differs slightly from Publish's view of the same asset. The workaround I used was to add a resolver rule in the Sling mapping that normalizes DAM asset paths between Author and Publish instances.

Validation Before Going Live

Before you point your domain at the Experience Edition instance, run through this checklist: Replication is functional — publish a test page on Author and confirm it appears on Experience Edition within your expected timeframe, including any variant or personalization changes you configured. Dispatcher caching works as intended — verify that cached pages are served from cache and that cache invalidation triggers correctly when content is updated.

No Author-only functionality is exposed — try accessing the CRXDE Lite interface, the Felix Console, and any debugging endpoints from outside the internal network. These should return access denied or be unreachable entirely. Performance meets your SLA — run a basic load test. Even a simple ab or vegeta script against your Experience Edition endpoint will tell you whether your JVM settings, thread pools, and cache configuration can handle your expected traffic volume. SEO elements render correctly — check that meta tags, canonical URLs, Open Graph properties, and structured data markup are all present on published pages. This is easy to miss in a rush and devastating if you ship it and then discover that Google is indexing the wrong URLs.

Monitoring and Maintenance

Once Experience Edition is live, you need basic monitoring in place. AEM's own diagnostics servlet gives you instance health, but you should also set up external monitoring that hits your public URLs and checks response times, status codes, and content correctness at regular intervals. I use a combination of a simple uptime monitor and periodic content comparison checks between Author and Experience Edition to catch replication drift before it becomes a user-facing problem. Keep an eye on your dispatcher cache hit ratio. A healthy Experience Edition instance should be serving the vast majority of requests from cache. If you're seeing a sudden drop, something has changed — either your cache invalidation rules broke, your traffic pattern shifted, or content is being updated so frequently that caching is no longer effective. Each of those has a different fix. Log retention matters more on Experience Edition than on Author because that's where you see the actual user traffic patterns. Configure your access logs to retain at least 30 days of data. You'll need that when someone reports that a page worked yesterday but not today, and you need to figure out whether it was a content issue, a cache issue, or a traffic spike that overwhelmed the instance.

That's the short version of getting Experience Edition running without unnecessary headaches. The process is straightforward if you respect the separation between Author and Publish roles from the start. Trying to adapt an Author configuration for Experience Edition is the single most common mistake I see, and it's the one that causes the most downstream problems.