DEV Community: Roshan Ravaliya

Building High-Performance Product Catalogs in SitecoreAI (XM Cloud) Without Creating Millions of Items

Roshan Ravaliya — Tue, 30 Jun 2026 18:53:00 +0000

Model a real commerce catalog as Sitecore items and you already know how it ends: 50,000 SKUs become 50,000 items, each with variants, each needing to publish, each one stretching your build, your publish queue, and limits Experience Edge was never built to carry. The instinct is understandable Sitecore is where content lives. But a product catalog is not content, and treating it like content is the most expensive mistake teams make on SitecoreAI.

The fix is a hybrid architecture: product data stays in a system built for it, Sitecore owns presentation and marketing, and a dedicated search service powers discovery. This post lays out that pattern — then answers the question that decides your search engine: which is fastest, and which reflects changes immediately after a sync.

Why a catalog can't live as Sitecore items

SitecoreAI serves content through Experience Edge which is a globally cached, read-only GraphQL layer that's excellent at its job but has hard limits a large catalog hits immediately:

A single query returns at most 1,000 entities, beyond that you paginate with cursors.
Every query is scored against a complexity budget of 250, spent on the number of items and the fields and nesting. "Fetch all products in one call" is off the table.
The delivery API enforces roughly 80 uncached requests per second. On a catalog site firing several queries per page, that ceiling is easy to breach under load or right after a publish clears the cache — and visitors start seeing 429s.

Publishing compounds it. A single item publishes to Edge in tens of seconds, not the few a web database takes, multiply by a large catalog and a few busy authors and the queue becomes a bottleneck. Builds balloon too, since pre-generating a page per product means generating tens of thousands of pages from Edge.

The deeper issue: Edge's GraphQL search filters content by field value it isn't full-text or faceted site search, and Sitecore's own docs point you to a dedicated service for anything more. The embedded Solr inside the platform powers only the authoring UI, not your front end. So even if you forced the catalog into items, you still wouldn't have real search.

The catalog doesn't belong in Sitecore, and search doesn't come from Sitecore. Both need a different home.

Separate the catalog from the content

Stop asking "how do I get products into Sitecore" and ask "what is Sitecore actually responsible for here?"

Product data like SKUs, prices, inventory, specs, variants… has a natural home. your commerce platform, PIM, or ERP behind an API. That system already owns and updates it. Sitecore owns the experience around the product like the page template, layout, merchandising blocks, editorial copy, campaign banners, SEO fields. That's content, and it's a small, manageable set of items.

So you model the shape of a product page once, and fetch the data for any product at request or build time. The catalog can hold ten million SKUs while your item tree barely grows.

The hybrid architecture

Three layers do the work.

Source of truth: your commerce/PIM/ERP API, plus a Redis cache for hot data. It owns the data, catalog size never touches Sitecore's item count.

Search and discovery a dedicated service (Coveo, Sitecore Search, or Algolia) that ingests the catalog and powers listings, facets, type-ahead, and keyword search. This is what users query, and it exists because Edge can't do this job.

Presentation SitecoreAI plus your headless frontend, where you model one product-detail template and a few merchandising components, and let a single dynamic route serve every product.

That route is the keystone. Instead of an item per product, a wildcard "Product Detail" route reuses one layout for every product URL. Every product page resolves to the same layout item, so requests share one cached Edge response that doesn't count against the rate limit. The route reads the SKU from the URL, fetches that product's data from the API or index, and renders unlimited product URLs, full design control, almost no Edge load.

# One cached layout query for the shared Product Detail route
query ProductDetailLayout($site: String!, $routePath: String!, $language: String!) {
  layout(site: $site, routePath: $routePath, language: $language) {
    item {
      rendered
    }
  }
}

// getStaticProps / getServerSideProps for /products/[sku]
export async function getProduct({ params }) {
  // 1. Sitecore (Edge) gives you the page chrome — cached, cheap, rate-limit-friendly
  const layout = await edgeClient.getLayoutData('/products/_wildcard');

  // 2. Your commerce/PIM API gives you the live product data — the source of truth
  const product = await fetch(`${PRODUCT_API}/products/${params.sku}`).then(r => r.json());

  // 3. Your search service backs listing/category pages and search itself
  return { props: { layout, product } };
}

For listings and category pages you don't hit the product API per item. you query the search index, which returns paginated, faceted results in milliseconds. The detail route handles the deep single-item view. Nothing here grows with catalog size except records in a search index, which is exactly what indexes are for.

Coveo vs. Sitecore Search vs. Algolia

All three work on SitecoreAI, none is the embedded Solr. They differ in how they ingest data, how fast they answer, and how quickly changes appear after a sync. First, one distinction that most "which is faster" debates blur:

Query latency keystroke to results on screen. "How fast is search" for the user.
Index-freshness latency content change to "queryable in the index." "How fast it reflects after a sync."

A service can be great at one and mediocre at the other.

How each ingests data.

Coveo the old Coveo for Sitecore package isn't supported on SitecoreAI, you can use generic connectors instead: a Sitemap or Web source that crawls on a schedule, or a Push / REST API source you feed with custom code for near-real-time updates or non-crawlable data.

Sitecore Search crawlers (web, advanced web, API) pull on a schedule and rebuild a source as a unit, with no single-page update, the Ingestion API pushes targeted updates, usually wired to publish webhooks.

Algolia no first-party connector, so you build it, which gives you the most control: either the Algolia Crawler, or better for catalogs. a serverless function triggered by a publish webhook or, ideally, by changes in your commerce/PIM/Redis layer, writing records straight to Algolia.

Dimension	Algolia	Coveo	Sitecore Search
Query latency (user-facing speed)	Fastest by design — ~1–20 ms per query, built for instant search-as-you-type.	Fast, enterprise-grade; tuned for relevance and ML over headline speed.	Fast, REST/SDK-based with AI relevance. Ample, not a raw-speed leader.
Freshness via push/API	Near-instant, async, but typically seconds; waitTask confirms.	Near-real-time via Push API, custom code required.	Ingestion has no SLA, often ~20 min; can feel fast but isn't guaranteed.
Freshness via crawler	Scheduled (minutes to hours).	Scheduled, Sitemap source supports efficient refresh.	Scheduled, rebuilds the whole source, no single-page update.
Integration effort	Highest fully custom.	Medium connectors; Push needs code.	Lowest native Sitecore product.
Beyond speed	Speed, simplicity, great DX; lighter on personalization.	Strongest relevance, recommendations, personalization at scale.	Tight Sitecore fit, OOTB AI embeddings.

Fastest queries: Algolia, by design single-to-low-double-digit millisecond processing, built for instant search-as-you-type. Coveo and Sitecore Search are both fast enough for almost any requirement but aren't built around that obsession.

Most immediate after a sync: Algolia again. Its engine turns a write into a queryable record in seconds, and waitTask confirms it. Coveo's Push API is also near-real-time. Sitecore Search is where expectations and reality diverge: teams report webhook-to-ingestion updates "within seconds," and in good conditions they happen but Sitecore documents ingestion as asynchronous, with no SLA, often around 20 minutes, and a full republish can flood it. If "publish and it's instantly searchable, guaranteed" is the requirement, its crawler is scheduled and its ingestion is best-effort.

Worked example: 50K SKUs, search-driven listings, 5-minute price updates

Here's the concrete case the architecture has to handle:

A 50,000+ SKU catalog. Listing pages come from search, with sort and filter. Product data syncs from an ERP and a Redis cache over an API. And a hard rule is when a discount campaign goes live at 12:00 and someone updates price in the ERP/Redis, the new prices must appear on the frontend within 5 minutes.

This scenario pulls in two directions at once, and that tension is the whole test. Because you sort and filter by price, price has to live inside the search index and sorting and faceting happen in the engine, not at render time, so a stale index means wrong ordering. But price is also your most volatile field, and it has to be fresh within five minutes.

That combination rules one engine out. Sitecore Search's ingestion is asynchronous with no SLA and often takes around 20 minutes it can't promise a 5-minute price update, and its crawler rebuilds the entire source, which is impractical to run every few minutes across 50K records.

Algolia is the right choice here. Coveo's Push API is a viable second.

The architecture:

ERP/Redis stays the source of truth for price. Nothing about price is authored in Sitecore.
The search index stores each product with its price, so listings can sort and filter on it.
On a price change, push a partial update to Algolia just the price attribute in a batch. Algolia indexes it in seconds, so listings reflect new prices well inside the 5-minute window. Real-time pricing is a use case Algolia is built for, and partial, batched updates are exactly the recommended pattern.
The product-detail page reads the live price from Redis at render. Redis is sub-millisecond, so the detail view is always exact even in the seconds between a change and the index catching up.

For the 12:00 campaign, the trigger fits your stack: the ERP fires an event, or your "update price" action calls a sync endpoint → a serverless function → a batched Algolia partial update. If you'd rather not wire events, a job polling Redis for changed prices every minute or two still clears the 5-minute bar comfortably. Either way, listings update through the index in seconds-to-a-minute, and the detail page reads live from Redis regardless. (Sitecore's own guidance on integrating Sitecore Search with XM Cloud flags the same webhook-pipeline considerations if you go that route.)

The split is the point: the index handles discovery and price-based sorting; Redis serves the exact, live number. Sort and filter stay correct, the displayed price is never wrong, and you hit the 5-minute SLA without forcing the search engine to act as a real-time database.

Choosing between them

Match the tool to the job, not to a benchmark:

Algolia — when speed, simple real-time updates (price, stock), and developer experience matter most, and catalog data is best pushed straight from a PIM/ERP/Redis. You build and own the Sitecore integration.
Coveo — when relevance, ML ranking, recommendations, and enterprise-scale personalization drive conversion. Its Push API covers near-real-time needs.
Sitecore Search — when staying inside the Sitecore ecosystem matters most: one vendor, native fit, AI relevance out of the box — provided you don't need guaranteed sub-5-minute freshness.

Conclusion

You don't scale a catalog in Sitecore by making more items, you scale it by keeping the catalog out of Sitecore. Let the ERP/PIM own product data, a dedicated search service own discovery, and SitecoreAI own the experience through one reusable product-detail route. The search choice then comes down to what you optimize for: Algolia for the fastest queries and the most immediate, predictable freshness after a sync; Coveo for the deepest relevance; Sitecore Search for the tightest native fit. For a 50K-SKU catalog with search-driven listings and a 5-minute price SLA, the answer is clear Algolia for the index, Redis for the live price.

References (official documentation)

Sitecore — Experience Edge

Sitecore Search

Coveo

Algolia

Automating Bulk Content Authoring in SitecoreAI with PowerShell Extensions

Roshan Ravaliya — Sun, 31 May 2026 14:07:32 +0000

Modern CMS platforms excel at managing content, but large-scale content updates remain one of the biggest operational challenges for content teams. While SitecoreAI provides powerful component-based architectures, authors are often responsible for manually creating datasources, configuring components, and assigning presentation details across hundreds of pages. At enterprise scale, this process quickly becomes a bottleneck.

Reducing 140+ hours of manual CMS work to under 30 minutes using SPE automated data source scaffolding, intelligent link resolution, and audit reporting from a single Ribbon button.

The Business Challenge

Enterprise SitecoreAI implementations constantly face one tension: developers build robust, reusable components, but content authors still bear the burden of wiring them up manually, one page at a time.

A seasonal campaign might require component updates across hundreds of category pages, multiple product series pages, several regional websites, and multiple language versions. For each page, the content author must complete a predictable sequence of manual steps:

Task	Time per Page
Create data folder	2 min
Create datasource item	2 min
Create child items (slides, etc.)	5 min
Configure CTA links	3 min
Assign datasource to rendering	2 min
Validate content	3 min
Total per page	~17 min

At 500 pages, that is 8,500 minutes, roughly 142 hours of uninterrupted, error-prone, repetitive work.

Value	Metric
142h	Manual effort (before)
<30m	Automated runtime (after)
500	Pages updated per run

THE GOAL

Enable content authors to update hundreds of components through a single automated process while maintaining governance, consistency, and full auditability.

Why SitecoreAI PowerShell Extensions?

There are several ways to approach content automation in SitecoreAI: custom admin applications, scheduled jobs, external integration services, and tools built on the SitecoreAI API. For this scenario, SPE offered a decisive combination of advantages.

Native SitecoreAI Integration

SPE provides direct, first-class access to content items, templates, the Media Library, presentation details, layout renderings, languages, and workflows with no additional abstraction layers.

No Deployment Pipeline Required

Scripts live inside SitecoreAI itself and can be updated directly in the Script Library. Changes are immediate and require no build, package, or deployment cycle.

Author-Friendly Exposure

SPE scripts can be surfaced as Content Editor Ribbon buttons, meaning content authors trigger complex automation without accessing any external tool or developer console.

Built-In Reporting

SPE's Show-ListView provides an immediate audit report with zero custom UI development invaluable for operations teams that need visibility without building a dashboard.

Solution Architecture

The end-to-end workflow follows a linear pipeline from a CSV file stored in the Media Library through to fully configured, presentation-injected pages:

CSV stored in the SitecoreAI Media Library
Ribbon command triggers the SPE script
Language selection dialog
CSV read and parsed with UTF-8 encoding
Target page located by stable business identifier
Data folder created if missing
Datasource item created if missing
Child items generated (slides, etc.)
CTA links resolved, internal path, GUID, or external URL
Datasource injected into the rendering via Presentation Details
Audit report displayed via Show-ListView

This pipeline allows content teams to execute large-scale updates without any developer involvement after initial setup.

Step-by-Step Walkthrough

Step 1 Ribbon Entry Point with Language Selection

The script is registered in the SPE Script Library. When an author clicks the Ribbon button, a dialog collects the target language before any processing begins.

$languageOptions = [ordered]@{
    "Norwegian (nb-NO)" = "nb-NO"
    "English (en)"      = "en"
}

$result = Read-Variable @{
    Title       = "Import Content"
    Description = "Select the target language for this import."
    Parameters  = @(
        @{ Name = "targetLanguage"; Title = "Target Language"; Options = $languageOptions }
    )
}

if ($result -ne "ok") { Exit }

WHY THIS MATTERS

This guard step prevents accidental imports into the wrong language version a common and painful mistake in multilingual implementations.

Step 2 CSV Stored in the Media Library

Storing the import file in the Media Library rather than a local file path is a deliberate architectural choice. Local paths break in cloud environments and create governance issues. A Media Library item is XM Cloud-compatible, centrally managed, and replaceable without developer access.

$mediaItem = Get-Item "master:$csvFilePath" -ErrorAction Stop

$stream    = $mediaItem.Fields["Blob"].GetBlobStream()
$bytes     = New-Object byte[] $stream.Length
$stream.Read($bytes, 0, $stream.Length) | Out-Null
$stream.Close()

$csvData = [System.Text.Encoding]::UTF8.GetString($bytes) |
            ConvertFrom-Csv -Delimiter ","

Step 3 Locating Target Pages by Business ID

Pages are matched by a stable business identifier field rather than by content path. Paths change when items are renamed or moved; business identifiers remain stable across reorganisations.

$page = Get-ChildItem $categoryRoot -Recurse |
    Where-Object { $_["WebCategoryId"] -eq $row.WebCategoryId }

Step 4 Automatic Datasource Scaffolding

If a page does not already have the required datasource structure, the script creates it automatically. This idempotent check-and-create pattern makes the solution safe to run repeatedly.

# Create Data folder if missing
$dataFolder = Get-ChildItem $page.Paths.FullPath |
    Where-Object { $_.Name -eq "Data" }

if (-not $dataFolder) {
    $dataFolder = New-Item -Path $page.Paths.FullPath `
                           -Name "Data" -ItemType $dataFolderTemplateId
}

# Create datasource item if missing
$datasource = Get-ChildItem $dataFolder.Paths.FullPath |
    Where-Object { $_.Name -eq "Content Component" }

if (-not $datasource) {
    $datasource = New-Item -Path $dataFolder.Paths.FullPath `
                     -Name "Content Component" -ItemType $componentTemplateId
}

Step 5 Intelligent CTA Link Resolution

Content authors provide links in whatever format they have SitecoreAI content paths, GUIDs, or external URLs. The script detects the format and writes the correct SitecoreAI link XML automatically.

if ($urlValue -like "/sitecore/content/*" -or
    $urlValue -match "^\{?[A-Fa-f0-9\-]{36}\}?$") {

    $targetLinkItem = Get-Item -Path "master:$urlValue" -ErrorAction SilentlyContinue

    if ($targetLinkItem) {
        $itemLang["CTA"] =
            "<link text=`"$text`" linktype=`"internal`" id=`"$($targetLinkItem.ID)`" />"
    }
} else {
    $itemLang["CTA"] =
        "<link text=`"$text`" linktype=`"external`" url=`"$urlValue`" />"
}

Step 6 Idempotent Item Creation

The script checks for an existing item by its ExternalId field before creating a new one. Re-running the import updates existing content rather than duplicating it critical for production systems.

$existingItem = Get-ChildItem $datasource.Paths.FullPath |
    Where-Object { $_["ExternalId"] -eq $row.ItemId }

if ($existingItem) {
    $item = $existingItem         # update in-place
} else {
    $item = New-Item ...           # create new
}

Step 7 Automated Datasource Injection

Creating the datasource item is only half the job. The rendering must also reference it. Without this step, the page would have a correctly structured datasource that the component never reads.

$device     = Get-LayoutDevice -Default
$renderings = Get-Rendering -Item $page -Device $device

foreach ($r in $renderings) {
    if ($r.ItemID.ToString() -eq $componentRenderingId) {
        $r.Datasource = $datasource.ID.ToString()
        Set-Rendering -Item $page -Instance $r -Device $device
    }
}

WHAT THIS REPLACES

Without automation, assigning a datasource requires opening Experience Editor, selecting the component, opening rendering properties, browsing to the datasource, and saving five manual steps per page, at 500 pages.

Step 8 Audit Report

Every action is captured in a structured collection and displayed at the end of execution. Authors see successful imports, failures, skipped records, and validation warnings without digging through logs.

$reportData += [PSCustomObject]@{
    "Page Name" = $page.Name
    "Page ID"   = $page.ID
    "Type"      = "Content Component"
    "Status"    = "Success"
    "Log"       = "Datasource assigned"
}

$reportData | Show-ListView `
    -Title    "Content Import Audit Report" `
    -PageSize 100 `
    -Property "Page Name", "Page ID", "Type", "Status", "Log"

Production Hardening

Enterprise automation should anticipate edge cases, not just the happy path. The script includes explicit guards for the most common failure scenarios at scale:

Missing pages: log a clear error with the business ID and continue processing remaining rows. Never abort the full import for one bad row.
Missing templates: throw early with a descriptive message if a template ID is not configured.
Missing language versions: automatically create using Add-ItemVersion before populating fields.
Missing images: log a warning and continue. The import should not fail because a single media path is incorrect.

Deploying the Script in SitecoreAI

Go to SitecoreAI content editor
Go to System > Modules > Powershell > script library
Create new PowerShell Script Module Folder

Under the new folder create new module using Module Wizard

Create PowerShell Script Library under /sitecore/system/Modules/PowerShell/Script Library/Content/Content Tools/Content Editor/Ribbon/Home
Create PowerShell Script under newly created PowerShell Script Library
Paste your PS Script in Script body field

Rebuild the module
After rebuild it is reflected in Home section in top bar like Import Hero Banners.

Results and Business Impact

Metric	Before	After
Time per page	~17 minutes	Automated
500-page campaign	~142 hours	Under 30 minutes
Re-run safety	Manual debug	Idempotent by design
Audit trail	None	Full Show-ListView report

The most important result is not the time saved it is the operational model it enables. Content teams can now execute large-scale campaign launches without developer involvement, without risking inconsistency, and without a support ticket for every missed datasource assignment.

KEY TAKEAWAY
The true value of automation in this context is not reducing clicks. It is enabling content teams to operate at enterprise scale without proportionally increasing operational complexity.

For SitecoreAI teams working in headless and XM Cloud environments, patterns like this are a baseline capability for managing content efficiently across large digital estates. What once required close to four weeks of focused manual effort can now be triggered with a single Ribbon button click.

SitecoreAI Deployments: The Shift from Legacy to Decoupled Architecture

Roshan Ravaliya — Mon, 30 Mar 2026 12:34:30 +0000

When enterprise teams migrate to SitecoreAI (XM Cloud), they celebrate the shift to a headless, composable, and AI-driven architecture. However, a common technical trap awaits them during the DevOps setup:

“how you deploy your frontend matters just as much as how you build it.”

This decision directly impacts:

Release velocity
Developer experience
Deployment speed
Production risk

In the SitecoreAI ecosystem, there are two primary ways to deploy your Next.js application: the Integrated (Coupled) approach via the Sitecore Deploy App, and the true Decoupled approach using independent CI/CD pipelines.

Decoupling in SitecoreAI isn’t just an architectural choice it’s the difference between treating your frontend as a deployable product versus a dependency of your CMS

Let’s break down the architectures, execution behaviours, and why enterprise teams are standardizing on the decoupled model.

In this guide, we’ll break down:

Coupled vs Decoupled deployment in SitecoreAI
Real-world system behaviour
Architecture patterns
Pros, cons, and when to choose each

What is Coupled vs Decoupled Deployment in SitecoreAI

In Sitecore AI, there are two primary deployment models:

1) Coupled (Integrated) Deployment

Managed via SitecoreAI Deploy App
Backend (CM) + Frontend (Next.js) deployed together
Single pipeline
One pipeline control everything
Small UI change → full deployment
Deployments act as a monolith.
Small UI change → full deployment must trigger a deployment through Sitecore.
Typical Flow:

Git → Deploy App → CM + Edge + Frontend → Live

Deployment time: 15–30 minutes

2) Decoupled Deployment

Backend and frontend deployed independently
Separate CI/CD pipelines
Frontend hosted on:
- Vercel
- Netlify
- BYOF (Bring Your Own Frontend)
Flow

- Backend: Git → Deploy App → CM + Edge
- Frontend: Git → Vercel → Live

Deployment time:
- Small apps: 2–5 minutes
- Enterprise apps: 5–10 minutes

The Architecture: Coupled vs. Decoupled

To understand the difference, we must trace how code moves from your repository to the delivery edge.

1) The Coupled (Integrated) Architecture

In this legacy model, the Sitecore Deploy App acts as the monolithic orchestrator for your entire stack.

Your GitHub/Azure DevOps repository is connected directly to the SitecoreAI Deploy App.
When a deployment is triggered, SitecoreAI builds BE and FE, pushes schema changes to Experience Edge, and then pushes the Next.js frontend code to the Sitecore-managed rendering host - all in the same pipeline instance.
Git → Deploy App → CM + Edge + FE → Live

2) The Decoupled Architecture

In this model, the CMS backend and the Next.js frontend are treated as completely independent microservices.

Pipeline A (The CMS): The SitecoreAI Deploy App is strictly responsible for building the CM server and pushing backend schema/configuration changes to the Authoring environment.
Pipeline B (The Frontend): The Next.js application is built and deployed via its own pipeline.
BE: Git → Deploy App → CM + Edge
FE: Git → Vercel → FE

If you place both the backend and frontend in the same repository (Monorepo), the Authoring environment pipeline will completely ignore the frontend code, and the Delivery pipeline will ignore the backend code.

Alternatively, you can physically split them into two different repositories (Polyrepo).

The Two Flavors of Decoupled Frontend Hosting:

When decoupling, you have two options for hosting your Next.js delivery layer:

Option A: Sitecore-Managed (Inbuilt Vercel): You utilize the Vercel infrastructure provisioned and managed by Sitecore under the hood. It provides a managed Editing Host, but you still decouple the deployment triggers.
- Note: You can not use public url for this environment for the preview site, it is useful Page builder and experience editor only.
Option B: Bring Your Own Frontend (BYOF - External): You connect your own enterprise Vercel or Netlify account directly to your repository. This requires manual configuration but offers ultimate DevOps control.

Architectural Implementation Steps

Moving to a decoupled setup requires re configuring your pipelines to isolate the delivery edge. Here is the architectural flow:

Step 1: Establish the CMS Pipeline

In the SitecoreAI Cloud Portal, configure your Deploy App to only build the CM environment.
Disable any integrated frontend rendering host configurations if moving entirely to BYOF.

Step 2: Choose and Configure the Frontend Pipeline

If using BYOF (External Vercel/Netlify): Go directly to your external hosting provider. Create a new project, point it to your repository, and specify the root directory of your Next.js application.

-Note: Manually configure all variable in step 3
If using Sitecore-Managed (Inbuilt Vercel): Ensure your editing host is configured within your xmcloud.build.json to point to the correct Next.js application path, but rely on external webhooks to trigger UI-only builds if supported by your tier.
- Note: Sitecore configure all required variable automatically, No need to do Step 3

Step 3: Map the Environment Variables

Because Sitecore is no longer auto-injecting environment variables into the delivery host, you must map them manually in your frontend host. Crucial variables include:

SITECORE_API_KEY (Your Experience Edge Token)
SITECORE_API_HOST (The Experience Edge GraphQL endpoint)
JSS_APP_NAME (The name of your site configuration)
GRAPH_QL_ENDPOINT (The endpoint for the delivery layer)

Step 4: Configure CI/CD Hooks

Set up GitHub Actions, Azure Pipelines, or Vercel webhooks to trigger frontend builds automatically upon merging to your main or staging branches.

Common Troubleshooting Scenarios

Experience Editor breaks due to incorrect editing host setup
Mismatched GraphQL schemas between FE and Edge
Environment variable drift between environments
Preview vs Delivery endpoint confusion

Pros and Cons

Coupled (Legacy) Deployment

Pros:
- Simplicity: A single pane of glass for all deployments in the Sitecore Cloud Portal.
- Beginner Friendly: SitecoreAI handles the Edge and Editing Host environment variable mapping automatically.
Cons:
- Slow Feedback Loop: Frontend deployments take drastically longer because they wait on CM orchestration.
- Difficult Rollbacks: Rolling back a bad frontend deployment often means reverting the entire CM state.
- Lack of DevOps Control: You cannot easily utilize advanced CI/CD testing steps (like Playwright or Cypress) before the frontend deploys.

Decoupled Deployment

Pros:
- Blazing Fast Iteration: Frontend deployments finish in minutes.
- Independent Rollbacks: Revert a bad UI push instantly without affecting the CMS backend.
- Security & Access: Frontend developers don't need access to the Sitecore Cloud Portal to do their jobs.
- Reduced frontend deployment time by 80%
- Enabled parallel FE/BE releases

Cons:
- Manual Configuration: You must manage API keys, webhooks, and environment variables manually.
- Two Pipelines: DevOps teams must monitor two separate deployment streams.

Feature	Coupled (Integrated)	Decoupled (Standalone)
Frontend Deploy Speed	15 - 30+ Minutes	2 - 5 Minutes (small Apps) 5 – 10 minutes (Enterprise Apps)
Rollback Complexity	High (Tied to CM state)	Low (Instant via Vercel/Netlify)
CI/CD Customization	Limited	Unlimited (GitHub Actions, etc.)
Setup Effort	Low (Out of the box)	Medium (Requires manual Env Vars)
Best For	POCs, Sandboxes, Small Teams	Enterprise, Agile Teams, Production

When is Decoupled NOT the Right Choice?

Small teams without DevOps expertise
POCs or hackathons
Projects with minimal frontend changes
Teams heavily reliant on Experience Editor with no FE team

Why Enterprises Prefer Decoupled XM Cloud

While the Coupled deployment model is excellent for a quick Proof of Concept, the Decoupled architecture is the undisputed best practice for production environments.

The core promise of a headless CMS is agility. If your frontend developers are forced to wait for a monolithic backend deployment pipeline just to update a button color, you have lost the primary benefit of headless architecture like Release velocity, Team independence, Parallel development.

Decoupling your deployments aligns perfectly with modern software engineering principles:

Separation of Concerns: The delivery layer (Next.js) and the authoring layer (CM) have different lifecycles and should fail or succeed independently.
Developer Experience (DevEx): Frontend engineers can work entirely within their native tools (Vercel, GitHub) without navigating Sitecore portals.
Risk Mitigation: Isolating the delivery pipeline ensures that an error in a custom backend Sitecore pipeline won't prevent you from pushing a critical UI hotfix to your live website.
Reduce Deployment time more than 70%
Enabled parallel FE/BE releases

Untangle your pipelines, secure your Edge tokens, and let your frontend run free.

Final Thoughts

Decoupling in SitecoreAI is not just an optimization-it’s a mindset shift.

You move from:

-“Frontend as part of CMS”

To:

“Frontend as an independent product”

And that changes everything.

Official Documentation References

To explore the technical specifications of these architectures, refer to the official Sitecore documentation:

Turbocharge Your Content with Sitecore AI Publishing V2

Roshan Ravaliya — Sat, 21 Feb 2026 14:22:20 +0000

If you have worked with Sitecore AI (XM Cloud), you already know:

Publishing performance directly impacts delivery speed and author productivity.
For a long time, Snapshot Publishing (V1) powered Sitecore AI content delivery. It worked but as projects scaled, publishing times increased, CM servers became overloaded, and queues slowed down deployments.

Now, Sitecore introduces a modern, cloud-native approach:

Experience Edge Runtime (Publishing V2)

Let’s explore what changed and why it matters.

The Bottleneck: Publishing V1 (Snapshot-Based)

In Publishing V1, when you publish a page, the CM server performs heavy processing before the content even reaches Experience Edge

Calculated the entire layout.
Resolved all data sources.
Executed Layout Service pipes.
Created a massive, static JSON blob (a "Snapshot") to send to Experience Edge.

The Result: Publishing a simple page update could take minutes. Even a small content change requires rebuilding the entire page structure.

As your site grows:

Layout complexity increases
Datasource relationships multiply
CPU usage on CM rises
Publish queues grow longer

What once took seconds can quickly turn into minutes.

And at scale, this affects both publishing speed and authoring performance.

The Solution: Publishing V2 (Edge Runtime)

Sitecore AI introduced a new way to publish content: Publishing V2 (also known as Edge Runtime mode). It sounds technical, but it’s a beautiful simplification of how data moves.

Publishing V2 changes the architecture entirely.

Instead of pre-calculating the full layout JSON on the CM server, Sitecore now:

Publishes raw item data
Publishes layout references
Defers JSON assembly to the Edge runtime

The final JSON response is assembled dynamically on the Experience Edge delivery layer not on CM.

This shifts the workload from the single CM instance to the massively scalable Edge CDN.

The "Cake" Analogy: V1 vs. V2

To understand the difference, imagine you are sending a cake to a friend.

Publishing V1 (Snapshot):

You bake the cake, frost it, box it up, and ship the entire heavy box.

Technical Translation: Sitecore calculates the entire layout JSON on the CM server and sends a massive static blob to Experience Edge.
Result: Slow and heavy.
If you change one ingredient, you must bake the whole cake again.

Publishing V2 (Edge Runtime):

You just send the recipe and the ingredients. Your friend (Experience Edge) assembles the cake instantly when someone asks for it.

Technical Translation: Sitecore sends only the raw item data and layout references. Experience Edge assembles the JSON at "runtime" when the API is called.
Result: Lightning fast.
You only ship the tiny changes.

Architecture Comparison

V1 Flow (Snapshot Publishing)

CM → Layout Service Processing → Full JSON Snapshot → Experience Edge → CDN → Frontend
Everything is assembled on CM before delivery.

V2 Flow (Edge Runtime)

CM → Raw Items + Layout References → Edge Worker Runtime → JSON Assembly → CDN → Frontend
JSON is assembled at request time by the Edge worker.

Key Advantages of Publishing V2

1). Blazing Fast Publish Times

Since layout JSON is no longer generated on CM, publish jobs typically complete in seconds rather than minutes.

This is especially noticeable on:

Large component-based pages
Sites with heavy personalization
Complex layout structures

2️). Better CM Performance
The CM instance is no longer CPU-bound by layout assembly.

This means:

Better authoring performance
Higher concurrency
Multiple publish jobs can run safely

3️). True Scalability

Processing shifts to the globally distributed Experience Edge runtime designed for high availability and horizontal scaling.

Your publishing performance now scales with Edge infrastructure, not your CM size.

Important Behavioral Change: Strict Dependencies

This is where V2 requires architectural awareness.

In V1:

The snapshot captured fully resolved data at publish time.
Previously resolved data could still exist inside snapshots.

In V2:

JSON is assembled at request time.
If a datasource item is not published, it does not exist in the GraphQL response.

This can result in:

Empty components
Missing navigation items
Incomplete JSON output

Best Practice:

Always use:

Publish Related Items
Or ensure parent and datasource items are included in the publish job.

Caching Behavior in V2

V2 invalidates cache per item ID.

It does not automatically invalidate related items such as:

Parent navigation
Sibling teasers
Shared components

If a shared data source changes, and parents are not published, you may see stale content.

Always plan publish dependency carefully.

How to Implement (The "Switch")

No code changes required. No config patching. No redeployment of frontend.

You can do this directly in the Sitecore AI Deploy Portal

Step 1: Log in to the SitecoreAI Deploy.

Step 2: Select your Project and Environment (e.g., Production, QA, or Development).

Step 3: Go to the Variables tab.

Step 4: Click Create Variable and add the following:

Name: Sitecore_ExperienceEdge_dot_WorkerStoreEnabled 
Value: TRUE
Target: CM

Step 5: Save and deploy your environment.

Step 6: Once deployment completes, Republish all sites in the environment.

Important: Deployment + full republish is required for activation.

To revert to V1:

Change the variable Sitecore_ExperienceEdge_dot_WorkerStoreEnabled to FALSE.
Redeploy the environment
Delete Edge content
Republish all sites

Frontend Impact: The Best News

This is the "sweetest" part of the update.

Do not need to change your Next.js API endpoints.

Even though the backend architecture has completely changed, the Frontend Contract remains the same.

✔ Your Endpoint: Remains https://edge.sitecorecloud.io/api/graphql/v1
✔ Your Query: Remains exactly the same.
✔ Your JSON Response: Look exactly the same.
✔ Require zero refactoring

Why?

The change from V1 to V2 is purely architectural (Backend/Ingestion). It changes how data gets into the Edge, but it does not change Delivery how read it out.

V1: Edge reads a pre-baked JSON blob.
V2: Edge reads references and assembles the JSON blob on the fly.

Real-World Impact

In enterprise implementations, teams have observed:

Homepage publish time reduced from minutes to seconds
Massive reduction in publish queue backlogs
Improved CM responsiveness during large content pushes

For content-heavy, composable architectures, this is a game-changing improvement.

Final Verdict

Publishing V2 (Experience Edge Runtime):

✔ Faster
✔ Lighter
✔ More scalable
✔ No frontend changes
✔ Cleaner architecture

The only requirement?

Be disciplined with publish dependencies.

For most Sitecore AI headless projects, this is a clear upgrade and a rare “win-win” architectural improvement.

Official Documentation

Ready to make the switch? Check out the official guides here:

Closing Thought

Sitecore AI is evolving toward true cloud-native architecture and Publishing V2 is a major step forward.

If you are still on Snapshot Publishing, this is the time to switch.

Happy Publishing.