A friend of mine flipped on her freshly built headless front end for the first time, hit refresh, and got a page so blank it looked like the internet had forgotten her company existed. No title tag. No meta description. No structured data whispering to Google what any of it meant. Her old Adobe Experience Manager instance had been producing all of that quietly for years, and nobody had ever once thanked it for the trouble. That blank page is the whole article in one screenshot, so let's talk about why it happens.
Here is the split that catches everyone off guard. When you move off AEM, your structured content (Content Fragments, taxonomies, metadata, DAM files) maps over relatively cleanly, while everything about how pages get rendered (templates, components, dispatcher caching, personalization, URL routing) has to be rebuilt from scratch. 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.
The picture I keep coming back to is this. 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. Most teams underestimate exactly one half of that, and it is almost always 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
So here is where I actually land. For most teams this is a good trade, and I would take it. Headless gives you a faster, framework-native front end and content you can finally reuse across every channel instead of gluing it to one page editor. What it takes away is the hotel where all the SEO plumbing came pre-installed, and that loss is real, not theoretical. The teams that get burned are the ones who fell in love with the windows and never once asked who was buying the appliances.
If you make me pick the single thing that decides the outcome, it is not the framework and it is not the CMS. It is whether someone owns the rendering, the meta scaffolding, and an exhaustive redirect map before go-live rather than after. Build those three and the blank page never appears. Skip them and you get exactly the screen my friend saw: a company that, as far as Google can tell, quietly stopped existing overnight. Admire the loft all you like, but sign nothing until you know who is installing the kitchen, and whether they have seen the size of this one.