Deeper into the Content SDK for SitecoreAI

It has been a few months since our talk at the Sitecore User Group in Budapest back in June, where we explored the then-beta release of the Sitecore Content SDK, Sitecore’s successor to JSS for XM Cloud customers. In the months that followed, the SDK has evolved quickly. The beta became version 1, followed by 1.1, and more recently version 1.2 released to coincide with Sitecore Symposium in Orlando.

This article revisits what has changed since that early beta, what made it into the stable releases, and what the recent additions mean for teams building digital experiences on XM Cloud and SitecoreAI.

From beta to stable: what made it into version 1

Version 1.0.0 was the first production-ready release of the Content SDK. Beyond stabilising the API, it introduced several significant features.

Sitecore Design Studio support

Version 1 added early support for the Sitecore Design Studio, including code-generation improvements such as variant-generation modes and import-map handling. This will become increasingly important as SitecoreAI’s content-and-design capabilities mature.

Improved component map generation

Automatic component-map generation moved into the SDK, with full customisation options for teams wishing to integrate third-party components or maintain their own mapping logic. This reduces setup friction and supports more predictable scaffolding.

Sitecore client limitations (later resolved)

In version 1, the Sitecore client remained opinionated and limited to predefined queries (dictionary items, layout, page data). Custom GraphQL queries still required teams to extend the client manually, a gap later addressed in version 1.2. We implemented a manual SitecoreClient extension for a version 1.1 migration, based on our experience, the incoming fix is welcome.

Version 1.1: strengthening the developer experience

Version 1.1 focused heavily on modernising the development environment and laying foundations for AI-assisted workflows.

AI coding-agent rules

Coding-agent rules for Cursor (and later other AI IDEs) were added to the SDK boilerplate. These rules guide automated coding assistants to generate Sitecore-compliant patterns and architectures.

Enhanced Next.js support and error-page data fetching

Version 1.1 introduced component-level data fetching for 404 and 500 pages, allowing error templates to access the same structured data as standard routes, unlocking more personalised or context-aware fallback experiences.

ESLint 9 + flat config migration

Sitecore modernised the repo by migrating to ESLint 9 with flat configuration, aligning the SDK with current JavaScript industry standards and improving maintainability for teams adopting the recommended linting setup.

Design Studio code-generation improvements

Additional utilities for import-map creation (writeImportMap, combineImportEntries) were added, reinforcing the SDK’s integration with the Design Library.

Faster release cadence

Version 1.1 also included a long list of bug fixes, smaller enhancements, and stability updates. More importantly, the frequency of releases validated Sitecore’s rationale for ending JSS: maintaining diverging on-prem and SaaS roadmaps was slowing innovation. With the Content SDK being SaaS-only, updates are arriving more quickly and more predictably.

Version 1.2: Next.js App Router, raw GraphQL and what comes next

Version 1.2 landed around Sitecore Symposium and represents the most significant leap since the initial release.

Next.js App Router support (beta)

This has been one of the most requested features from the community. Version 1.2 introduces full App Router support, aligning Sitecore with the direction of the Next.js core team.

• Server-first architecture
• Native support for server components
• Streaming for faster perceived performance
• Nested layouts
• Smaller client-side bundles
• Better SEO and generative engine optimisation
• Cleaner developer experience

App Router support also includes sitemap and robots file generation, and full internationalisation (i18n) support, important additions not present in earlier previews.

Separation of client and server component maps

The SDK now distinguishes between client and server components, with correct handling of the use client directive. This ensures predictable bundling and avoids accidental hydration of server-only components.

Raw GraphQL query support

The SitecoreClient.getData() method now enables arbitrary GraphQL queries directly through the SDK, removing the need to extend the Sitecore client manually. This unlocks much more flexible data-retrieval patterns.

CLI enhancements

A new scConfig property in sitecore.cli.config improves how CLI commands receive and manage configuration, helping teams integrate with more complex pipelines and deployment processes.

AI-tooling updates

Version 1.2 expands AI IDE support beyond Cursor, adding formal guidance files for Claude and Windsurf.

Maintenance patch: v1.2.1

A follow-up patch resolved issues with missing component variants causing Next.js build failures. While version 1.2 remains in beta, these rapid maintenance releases indicate that the SDK is stabilising quickly.

A note on production readiness

At the time of writing, 1.2 App Router projects should not yet be deployed to production. Sitecore encourages evaluation and feedback while the release moves toward stability.

Why the shift matters for XM Cloud customers

The direction is clear. JSS cannot efficiently support both on-prem (XM/XP) and XM Cloud with their diverging roadmaps. The Content SDK is purpose-built for XM Cloud’s rapid delivery cycle and the emerging SitecoreAI roadmap.

For organisations already on XM Cloud (or planning to move) now is the right time to assess the transition. With fixed-price migration tiers and AI-powered analysis tools, we can deliver these migrations quickly, predictably, and with minimal disruption.

What if you’re not on XM Cloud yet?

Customers on XM/XP are not being left behind. Sitecore is investing in practical tooling to make the transition to SaaS easier, including Sitecore Pathway, a guided set of automation, analysis, and migration utilities designed specifically to reduce friction when moving to XM Cloud and SitecoreAI.

For those still planning their modernisation roadmap, now is an ideal moment to start the conversation.

Explainer: key concepts introduced in 1.2

Server components and streaming

Server components run entirely on the server, reducing client-side JavaScript and improving performance. Streaming delivers page segments progressively as they are ready, improving perceived speed.

The Sitecore Design Studio

Part of SitecoreAI’s content-and-design intelligence, the Design Studio provides a shared workspace for exploring, previewing, and refining components. It brings designers, developers, and authors together in a single environment where variants can be compared, responsive behaviour tested, and ideas prototyped safely. With AI-generated design options, real-time previews, and integrated code inspection, it accelerates experimentation and ensures components stay consistent, reliable, and aligned to your brand.

Architectural differences between JSS and the Content SDK

For those comparing the two models, our earlier presentation outlines the architectural differences, how data flows have changed, and why the Content SDK is a better fit for XM Cloud’s long-term roadmap.

Conclusion

The Content SDK has matured rapidly. With App Router support, raw GraphQL queries, Design Library alignment, improved multi-framework compatibility, and a modernised developer experience, this SDK is becoming the foundation of Sitecore’s AI-enabled digital-experience stack.

For organisations on XM Cloud (or preparing for it), this is the right moment to evaluate the transition. With the right expertise and tooling, the move from JSS to the Content SDK can be fast, predictable, and cost-effective.