When you move from Adobe Experience Manager to a headless CMS, your structured content (Content Fragments, taxonomies, metadata, DAM files) maps over relatively cleanly, while everything about how pages are rendered (templates, components, dispatcher caching, personalization, URL routing) has to be rebuilt from the ground up. Rankings leak in the gap between those two facts: the content survives the move, but the machine-readable scaffolding that told Google what the content meant does not travel with it unless you rebuild it on purpose.
Here is the mental picture I keep coming back to. AEM is a corporate hotel where everything is included. The plumbing, the furniture, the front desk that greets Googlebot, the little chocolate on the pillow that is your server-rendered meta description. You never had to think about any of it because Adobe bolted it into the walls. A headless CMS is a beautiful empty loft. Great bones, huge windows, and absolutely no kitchen. You are bringing your own appliances now.
Most teams underestimate exactly one half of that. (It is usually the kitchen.)
What actually maps cleanly
Content Fragments are the good news. Adobe built them to be presentation-agnostic structured content, which means they already think the way a headless entry thinks: fields, references, a defined model. A Content Fragment Model becomes a content type in Contentful or a schema in Sanity with very little violence. Your taxonomy and tags map. Your metadata fields map. The DAM assets themselves (the actual bytes of every PDF, image and video) move over fine, because a file is a file.
If your team invested early in Content Fragments and GraphQL delivery, congratulations, you did the hard part years ago and the migration will feel almost anticlimactic. If instead your entire site is component-based pages authored in the page editor, I have some furniture news for you.
What has to be rebuilt
Experience Fragments, components, and templates are presentation. They do not map. HTL (the old Sightly) markup, the client libraries, the dispatcher rules that cached everything into oblivion, all of it stays behind. In a headless world your front end (Next.js, Nuxt, Astro, whatever you pick) becomes responsible for rendering, and that front end starts as a blank file.
The quieter rebuilds are the ones that bite at go-live. Workflows and approval chains. Adobe Target personalization, which has no direct equivalent and needs a new home. On-site search. Forms. And URL routing, which in AEM was a byproduct of your /content/site/en/ repository path and now has to be a deliberate design decision instead of an accident of the JCR.
| AEM concept | Headless outcome | Effort |
|---|---|---|
| Content Fragments | Content types / entries | Low, maps directly |
| Tags and taxonomies | Reference fields / taxonomies | Low |
| DAM assets (files) | Asset library / external DAM | Low to medium |
| Components and templates (HTL) | Front-end framework code | High, full rebuild |
| Experience Fragments | Composed front-end sections | High |
| Dispatcher caching | CDN + framework caching | Medium, re-architected |
| Adobe Target personalization | New personalization stack | High |
| Repository-path URLs | Deliberate routing + redirects | Medium, ranking-critical |
Where rankings actually leak
Rendering is the first leak, and it is the sneaky one. AEM served fully-formed HTML to crawlers. A headless front end can too, but only if you choose server-side rendering. Ship a client-side-rendered app instead and you have handed Google a page that looks empty on first paint and hoped it comes back to run your JavaScript. Sometimes it does. On a slow crawl budget, sometimes it does not, and your content quietly stops existing as far as the index is concerned.
The second leak is your meta scaffolding. Titles, descriptions, canonical tags, hreflang, and structured data were often generated by AEM components you are about to delete. If nobody reimplements that logic in the new front end, every page ships with a blank pillow. No chocolate.
The third leak is URLs. When your paths stop mirroring the JCR tree, every single one changes, and a headless move without an exhaustive redirect map is just a polite way of deleting your rankings. This is where I would spend the paranoia budget. Crawl the live AEM site, capture every indexed URL and every DAM asset path (people forget the PDFs rank too), and map old to new before a single thing goes live. Auditing that gap between what AEM published and what the new stack actually renders is precisely the pre-migration work a content-intelligence crawl exists to do; if you want the AEM-specific version, the AEM to Contentful guide walks the same ground.
The honest tradeoff
Headless gives you a faster, cleaner, framework-native front end and content you can finally reuse across channels. It takes away the hotel where SEO plumbing came pre-installed. That is a genuinely good trade for most teams, as long as everyone understands they signed up to build a kitchen and not just admire the windows.
So before you sign the lease on the empty loft, ask the one question that decides everything: who on this project actually knows how to install a kitchen, and have they seen the size of this one?
Wait, I have a stray character. Let me fix.