EDS + Universal Editor — Migration path for PDP routes after Folder Mapping deprecation (SEO-safe) | Community
Skip to main content
O
olsalas711
Level 4
October 1, 2025
Solved

EDS + Universal Editor — Migration path for PDP routes after Folder Mapping deprecation (SEO-safe)

  • October 1, 2025
  • 2 replies
  • 516 views

Hi everyone,
Our storefront runs on Edge Delivery Services (EDS) with Universal Editor. PDP routes like:

 

Public PDP (example): https://shop.example.mx/p/product-slug-123

Current mapping target: /p/default

 

We noticed Folder Mapping shows a deprecation notice in the docs. We want to move to the supported approach while keeping PDP SEO correct (self-canonical, structured data, crawlability).

 

Questions:

 

What is the recommended replacement pattern in EDS to serve many PDPs without Folder Mapping, while still supporting per-URL head (title, meta description, self-canonical, Product JSON-LD)?

 

Any reference implementation or sample project for this new approach?

 

Key SEO pitfalls to avoid during migration (duplicate content, canonical conflicts, caching/invalidations).

 

Goal:
A short, official path to migrate PDP routes off Folder Mapping with no SEO regressions.

Best answer by arunpatidar

Hi @olsalas711 

Adobe introduced 'content overlay' as a replacement of folder mapping

https://www.aem.live/developer/byom 

https://ericvangeem.dev/blog/edge-delivery-byom-content-overlay 

2 replies

SantoshSai
Community Advisor
SantoshSaiCommunity Advisor
Community Advisor
October 1, 2025

HI @olsalas711,

Folder Mapping is indeed deprecated in Edge Delivery Services. The supported way forward is to rely on Path Mapping combined with a product route template (overlay/BYOM).

  • Routing: Set up a path mapping so that /p/{slug} points to your PDP route. Instead of dynamically stitching content via folder mapping, you serve a dedicated template that resolves the slug, looks up product data (via an index or API), and renders the full HTML.

  • SEO (title/meta/canonical/JSON-LD): Generate <head> tags per URL inside that route. EDS supports page/bulk metadata (so you can set defaults like /p/**), but for PDPs you typically override those with product data. Always output a self-canonical (/p/{slug}) and keep JSON-LD in sync with visible content.

  • References: The docs on  Path Mapping, Page/Bulk Metadata, and Indexing show the recommended pattern. Also see Content Overlays/BYOM as the replacement for Folder Mapping.

  • SEO pitfalls to avoid:

    • Don’t leave duplicate or “soft-404” pages (a known folder mapping issue).

    • Make sure only one canonical appears per PDP.

    • Keep head tags and body content sourced from the same product record to avoid mismatches.

    • If you change URLs, manage them through https://www.aem.live/docs/redirects.

    • Configure cache invalidation (push purge) so product detail updates reach search engines quickly.

Santosh Sai
    O
    olsalas711Author
    Level 4
    October 2, 2025

    Hi @arunpatidar ,

     

    Thanks a lot for the pointers and links on Content Overlay / BYOM — super helpful.

     

    I’m running an EDS site already live with AEM (Universal Editor) as the primary content source, and routing today relies on fstab.yaml (folder mapping). I saw in the docs that Content Overlay requires Configuration Service and fstab.yaml is not supported. Before I move forward, could you please help me validate the following so I do this safely on a live site?

     

    Cutover & precedence


    When I enable Configuration Service to use Content Overlay, what happens to existing fstab.yaml mappings?

     

    Do they keep working during a transition, or does overlay immediately take precedence?

     

    Universal Editor continuity

    Will Universal Editor continue working unchanged for WYSIWYG pages (authoring, preview, publish URLs) once Configuration Service + Content Overlay is enabled? Any limitations when a route is resolved by the overlay?

     

    Creating overlay entries via API

    For routes that don’t exist in the AEM author tree, is the recommended approach to create overlay records via API (one per page)? 

     

    SEO signals (SSR vs sitemap)

    Moving to overlay shouldn’t change the SEO approach, but I want to confirm the recommended pattern for hreflang/canonical in EDS with AEM as content source:

     

    Prefer server-served <head> (SSR/edge) for hreflang or is sitemap alternates sufficient? Or both?

     

    Goal: perform a safe migration to Content Overlay on a live site.

     

    Thanks in advance.

    arunpatidar
    Community Advisor
    arunpatidarCommunity Advisor
    Community Advisor
    October 5, 2025

    Hi @olsalas711 

    I would recommend to post same on discord channel at https://discord.com/channels/1131492224371277874/1148893229316587550 

     

    Let me try to answer based on my understanding - 

    1. I think folder mapping is at client side, you need to write a logic on your block to detect to make third party call to get the content or rely on existing markup(byom)

    2. Yes, it will work with Universal editor

    3. Adobe's documentation demonstrates what this setup looks like when using the API-based Configuration Service via the Helix Admin APIs, since this setup cannot be configured via the older fstab.yaml file approach

    4. Overlay approach is SEO friendly, should not change your SEO approach. 

    Arun Patidar
    arunpatidar
    Community Advisor
    arunpatidarCommunity AdvisorAccepted solution
    Community Advisor
    October 2, 2025

    Hi @olsalas711 

    Adobe introduced 'content overlay' as a replacement of folder mapping

    https://www.aem.live/developer/byom 

    https://ericvangeem.dev/blog/edge-delivery-byom-content-overlay 

    Arun Patidar
      Terms & ConditionsAccessibility statement

      Loading footer...