The Adobe Commerce front end isn’t one thing anymore. The same catalog, in the same EAV data model, can render through Luma (the default server-side theme), Hyvä (the popular third-party server-side theme), PWA Studio (Adobe’s React headless storefront), Edge Delivery Services (Adobe’s edge-rendered content + commerce platform), or Adobe Commerce as a Cloud Service (ACCS — the SaaS option Adobe shipped in mid-2025).
Each rendering path makes a different set of choices about what AI agents see. The catalog is identical; the storefronts are not. This guide walks the four paths, the AI readiness implications of each, and the patterns for ensuring the JSON-LD lands in the crawler-visible payload — not in a hydration step the agent never reaches.
The catalog-side companion piece, Product schema for Adobe Commerce, covers the EAV model and the schema module pattern for traditional Luma builds. This guide picks up where that one stops — at the headless boundary.
The four rendering paths
The first two render server-side. The next three are headless, edge-rendered, or some hybrid. The render-time story changes everything about what an AI crawler sees.
Path 1 — Luma (the Magento default theme)
The legacy default theme that ships with Magento / Adobe Commerce. Server-rendered PHP templates with Knockout.js handling the interactive bits. Ships almost no JSON-LD out of the box; the schema work is a module the implementation team builds. The catalog-side detail of that work is in the Product schema for Adobe Commerce guide.
For AI readiness, Luma’s advantage is that whatever the module emits ends up in the initial HTML response. Crawlers that don’t execute JavaScript see everything. The disadvantage is that Luma’s default templates have not been a focus for Adobe in years; the most-shipped enterprise builds are increasingly Hyvä, PWA Studio, or one of the SaaS paths.
If your stack is Luma and you’re not planning a migration, the playbook is well-trodden: build the schema module, render it from the PDP layout XML, validate, ship. The work is engineering hours, not platform reinvention.
Path 2 — Hyvä
A third-party theme that replaces Luma’s render layer with
Tailwind CSS and Alpine.js while keeping the rest of the Adobe
Commerce stack. Hyvä ships with better default structured data
than Luma, but it’s still not exhaustive — brand, gtin,
mpn, aggregateRating, and the more attribute-rich Schema.org
shapes still need explicit configuration.
For AI readiness, Hyvä is the easiest path on Adobe Commerce: it renders server-side, the templates are clean, and the structured data starting point is meaningfully ahead of Luma. The work shifts from “build everything” to “fill in what’s missing.”
The trap on Hyvä: the third-party module ecosystem for adding schema is broader than Luma’s, which means quality varies. Pick the module that is actively maintained against the current Hyvä release, audit its output against the validating structured data workflow before trusting it, and verify it handles the catalog’s variant model cleanly. Bulk-installing the most-downloaded module is not the same as picking one that works for the specific catalog.
Path 3 — PWA Studio
Adobe’s first-party headless storefront — React, Apollo Client, and the Magento GraphQL API. The same catalog, but the storefront is a JavaScript application that hydrates from GraphQL responses.
The AI readiness story here is identical to every other headless storefront: the JSON-LD has to be in the server-side render, not injected after hydration. PWA Studio supports server-side rendering through Upward and the framework path the team selected. If the build is using SSR, the schema module can run in the SSR path and emit the JSON-LD into the initial HTML.
If the build is rendering client-side only — and many PWA Studio
deployments do — the JSON-LD goes through react-helmet or
equivalent, but only the SSR-emitted version lands in the
crawler’s view. Anything that only appears after hydration is
invisible to crawlers that don’t execute JavaScript.
The audit step for PWA Studio:
curl -A "Mozilla/5.0" -s https://<storefront>/<pdp-path> \
| grep -i "application/ld+json"If application/ld+json is in the curl response, server-side
rendering is working. If it’s not, the schema is invisible to the
agents you care about — fix the SSR path before anything else.
Path 4 — Edge Delivery Services
Adobe shipped Edge Delivery Services as the rendering substrate for AEM and increasingly for commerce. Pages are pre-rendered or edge-rendered close to the user, content authoring happens in Google Docs or SharePoint (via document-based authoring), and the integration with Adobe Commerce happens through commerce fragments that pull product data into the rendered page.
For AI readiness, Edge Delivery’s edge-rendering model is a
strong primitive — the rendered HTML is what the crawler sees,
served from CDN edge nodes, no hydration step required. The
schema work happens in the commerce fragments themselves: each
fragment that renders product data is responsible for emitting
the corresponding Product or ProductGroup JSON-LD.
The Adobe Commerce Optimizer (ACO) variant — Adobe’s Edge-Delivery-powered offering for brands that want edge-rendered commerce without replatforming the back end — is the configuration to watch. It pairs the existing Magento catalog with edge-rendered storefront pages, which is the shortest path for an existing Adobe Commerce install to get the SSR benefits of a headless storefront without rebuilding the whole front end.
Implementation pattern: every commerce fragment that surfaces
product data renders the JSON-LD inline. Pages with multiple
products render multiple JSON-LD blocks (one per product, or
one ItemList referencing the items). Validation runs against
the rendered URL the same way it would against any other
server-rendered page.
Path 5 — Adobe Commerce as a Cloud Service
ACCS launched in June 2025 as Adobe’s managed SaaS option for Commerce. It runs on the microservices architecture Adobe has been building toward, integrates with Edge Delivery Services for the storefront, and competes more directly with Salesforce Commerce Cloud and Shopify Plus on the buy-vs-build axis.
For AI readiness, the ACCS story converges with the Edge Delivery story: storefront pages are edge-rendered, the schema work happens in the storefront layer, and the catalog work happens in the back-end Commerce service. Brands evaluating ACCS for a new build should treat structured-data rendering as a build requirement up front, not a phase-two retrofit.
The advantage ACCS gives an AI readiness team that didn’t exist on Luma builds: the storefront is a first-class concern of the platform vendor. Adobe has incentive to ship structured-data primitives in the default ACCS templates that Luma never got. How much of that has actually shipped versus how much is planned is a verification question per release; check the rendered HTML of a representative PDP on the current ACCS version rather than trusting the roadmap.
What changes across paths
A short matrix:
| Path | Render | Default JSON-LD richness | SSR-required for AI? | Where to add schema |
|---|---|---|---|---|
| Luma | Server (PHP) | Minimal | N/A (already SSR) | Custom Magento module + layout XML |
| Hyvä | Server (Tailwind/Alpine) | Better than Luma | N/A (already SSR) | Theme override or third-party module |
| PWA Studio | Client (React) | None by default | Yes | SSR render path; react-helmet for the markup |
| Edge Delivery Services | Edge | Component-defined | N/A (already edge-rendered) | Commerce fragment definitions |
| Adobe Commerce as a Cloud Service | Edge / managed | Vendor-defined; verify per release | N/A (already SSR/edge) | Storefront templates / fragments |
The biggest single risk is path 3: a PWA Studio build that ships JSON-LD only after hydration. Every other path renders server-side or at the edge by default, which means whatever schema is configured ends up in the crawler-visible HTML.
A migration question worth asking
Many existing Adobe Commerce installs are sitting on Luma builds that have been incrementally extended for years and are now under pressure to either (a) ship structured data they don’t have, (b) replatform the front end, or (c) both.
The relevant question for an AI readiness lens isn’t “is Hyvä / PWA Studio / EDS the right choice for our brand?” — that question has bigger inputs than schema rendering. The question is: if the team is already planning a front-end replatform, does the chosen path render structured data server-side or edge-side by default? Three of the four destinations above do. One (PWA Studio without SSR) doesn’t, and a brand that chose that path without realizing the SSR requirement is going to relearn it in production when the AI surface checks start coming back empty.
If the front end is staying on Luma for the foreseeable future, build the schema module and move on. If the front end is moving, make structured-data rendering a build requirement that gets verified before launch — not a phase-two retrofit.
Validation, on every path
The validation workflow is identical regardless of path. Render a representative PDP, view source, copy the JSON-LD, and run it through Google’s Rich Results Test and the Schema.org validator. The validating structured data guide has the full workflow.
For continuous coverage across the full catalog rather than one-PDP-at-a-time checks, that’s what Lumio’s AI Readiness Score does. The score is consistent across rendering paths — the same gauge that grades a Luma build grades a PWA Studio build, with the same dimensions. Get in touch when you want to move past per-PDP validation.
Cluster — structured data on Adobe Commerce
- Product schema for Adobe Commerce — the EAV catalog model and the schema module pattern
- Product schema for Salesforce Commerce Cloud — the sibling enterprise platform
- Validating structured data — the validation workflow
- How to audit a Salesforce Commerce Cloud site for AI readiness — the audit methodology for the sibling enterprise platform
