As organizations continue their journey toward composable and headless architectures, the way we manage even simple things like redirects evolves too. Redirects are essential for SEO and user experience, but managing them within a CMS often introduces unnecessary complexity. In this blog, I will share how we streamlined redirect management for a Sitecore XM Cloud + Next.js implementation using Vercel Edge Config  – a modern, edge-based approach that improves performance, scalability, and ease of maintenance.

Why Move Redirects Out of Sitecore?

Traditionally, redirects were managed within Sitecore through redirect items stored in the Content Tree. While functional, this approach introduced challenges such as scattered items, and added routing overhead. With Sitecore XM Cloud and Next.js, we now have the opportunity to offload this logic to the frontend layer – closer to where routing happens. By using Vercel Edge Config, redirects are processed at the edge, improving site performance and allowing instant updates without redeployments.

By leveraging Vercel Edge Config and Next.js Middleware, redirects are evaluated before the request reaches the application’s routing or backend systems. This approach ensures:

1. Redirects are processed before routing to Sitecore.
2. Updates are instant and do not require deployments.
3. Configuration is centralized and easily maintainable.

The New Approach: Redirects at the Edge

In the new setup:

1. Redirect rules are stored in Vercel Edge Config in JSON format.
2. Next.js middleware runs at the edge layer before routing.
3. Middleware fetches redirect rules and checks for matches.
4. Matching requests are redirected immediately – bypassing Sitecore.
5. Non-matching requests continue to the standard rendering process.

Technical Details and Implementation

Edge Config Setup in Vercel

Redirect rules are stored in Vercel Edge Config, a globally distributed key-value store that allows real-time configuration access at the edge. In Vercel, each project can be linked to one or more Edge Config stores.

You can create edge config stores at project level as well as at account level. In this document, we will be creating the store at account level and this edge config store will be shared across all the projects within the account.

Steps:

1.  Open the Vercel Dashboard.
2. Go to Storage -> Edge Config.
3. Create a new store (for example: redirects-store).
   
4. Add a key named redirects with redirect data in JSON format.
   Example JSON structure:

   {
     "redirects": {
       "/old-page": {
         "destination": "/new-page",
         "permanent": true
       },
       "/old-page/item-1": {
         "destination": "/new-page./item-1",
         "permanent": false
       }
     }
   }

5. To connect your store to a project, navigate to Projects tab and click on Connect Project button.

6. Select the project from the dropdown and click Connect.
   

7. Vercel automatically generates a unique Edge Config Connection String for your project which is stored as an environment variable in your project. This connection string securely links your Next.js app to the Edge Config store. You can choose to edit the environment variable name and token name from the Advanced Options while connecting a project.

8. Please note that EDGE_CONFIG environment that is added by default (if you do not update the name of the env. variable as mentioned in step #7). This environment variable is automatically available inside the Edge Runtime and used by the Edge Config SDK.

Implementing Redirect Logic in Next.js Middleware

1. Install the Vercel Edge Config SDK to fetch data from the Edge Config store:

   npm install @vercel/edge-config

   The SDK provides low-latency, read-only access to configuration data replicated across Vercel’s global edge network. Import the SDK and use it within your middleware to fetch redirect data efficiently.

2. Middleware Configuration: All redirect logic is handled in the middleware.ts file located at the root of the Next.js application. This setup ensures that every incoming request is intercepted, evaluated against the defined redirect rules, and redirected if necessary – before the request proceeds through the rest of the lifecycle.Code when using single store and the default env. variable EDGE_CONFIG

   import { NextResponse } from 'next/server';
   import type { NextFetchEvent, NextRequest } from 'next/server';
   import { get } from '@vercel/edge-config';
   
   export async function middleware(req: NextRequest, ev: NextFetchEvent) {
     try {
       const pathname = req.nextUrl.pathname;
   
       // Normalize the pathname to ensure consistent matching
       const normalizedPathname = pathname.replace(/\/$/, '').toLowerCase();
   
       // Fetch redirects from Vercel Edge Config using the EDGE_CONFIG connection
       const redirects = await get('redirects');
   
       const redirectEntries = typeof redirects === 'string' ? JSON.parse(redirects) : redirects;
   
       // Match redirect rule
       const redirect = redirectEntries[normalizedPathname];
   
       if (redirect) {
         const statusCode = redirect.permanent ? 308 : 307;
         let destinationUrl = redirect.destination;
         //avoid cyclic redirects
         if (normalizedPathname !== destinationUrl) {
           // Handle relative URLs
           if (!/^https?:\/\//.test(redirect.destination)) {
             const baseUrl = `${req.nextUrl.protocol}//${req.nextUrl.host}`;
             destinationUrl = new URL(redirect.destination, baseUrl).toString();
           }
           return NextResponse.redirect(destinationUrl, statusCode);
         }
       }
   
       return middleware(req, ev);
     } catch (error) {
       console.error('Error in middleware:', error);
       return middleware(req, ev);
     }
   }
   
   export const config = {
     /*
      * Match all paths except for:
      * 1. /api routes
      * 2. /_next (Next.js internals)
      * 3. /sitecore/api (Sitecore API routes)
      * 4. /- (Sitecore media)
      * 5. /healthz (Health check)
      * 6. all root files inside /public
      */
     matcher: ['/', '/((?!api/|_next/|healthz|sitecore/api/|-/|favicon.ico|sc_logo.svg|throw/).*)'],
   };

   Code when using multiple stores and custom environment variables. In this example, there are two Edge Config stores, each linked to its own environment variable: EDGE_CONFIG_CONSTANT_REDIRECTS and EDGE_CONFIG_AUTHORABLE_REDIRECTS. The code first checks for a redirect in the first store, and if not found, it checks the second. An Edge Config Client is required to retrieve values from each store.

   import { NextRequest, NextFetchEvent } from 'next/server';
   import { NextResponse } from 'next/server';
   import middleware from 'lib/middleware';
   import { createClient } from '@vercel/edge-config';
   
   export default async function (req: NextRequest, ev: NextFetchEvent) {
     try {
       const pathname = req.nextUrl.pathname;
   
       // Normalize the pathname to ensure consistent matching
       const normalizedPathname = pathname.replace(/\/$/, '').toLowerCase();
   
       // Fetch Redirects from Store1
       const store1RedirectsClient = createClient(process.env.EDGE_CONFIG_CONSTANT_REDIRECTS);
       const store1Redirects = await store1RedirectsClient .get('redirects');
   
       //Fetch Redirects from Store2
       const store2RedirectsClient = createClient(process.env.EDGE_CONFIG_AUTHORABLE_REDIRECTS);
       const store2Redirects = await store2RedirectsClient.get('redirects');
   
       let redirect;
   
       if (store1Redirects) {
         const redirectEntries =
           typeof store1Redirects === 'string'
             ? JSON.parse(store1Redirects)
             : store1Redirects;
   
         redirect = redirectEntries[normalizedPathname];
       }
   
       // If redirect is not present in permanent redirects, lookup in the authorable redirects store.
       if (!redirect) {
         if (store2Redirects) {
           const store2RedirectEntries =
             typeof store2Redirects === 'string'
               ? JSON.parse(store2Redirects)
               : store2Redirects;
   
           redirect = store2RedirectEntries[normalizedPathname];
         }
       }
   
       if (redirect) {
         const statusCode = redirect.permanent ? 308 : 307;
         let destinationUrl = redirect.destination;
   
         if (normalizedPathname !== destinationUrl) {
           // Handle relative URLs
           if (!/^https?:\/\//.test(redirect.destination)) {
             const baseUrl = `${req.nextUrl.protocol}//${req.nextUrl.host}`;
             destinationUrl = new URL(redirect.destination, baseUrl).toString();
           }
           return NextResponse.redirect(destinationUrl, statusCode);
         }
       }
   
       return middleware(req, ev);
     } catch (error) {
       console.error('Error in middleware:', error);
       return middleware(req, ev);
     }
   }
   
   export const config = {
     /*
      * Match all paths except for:
      * 1. /api routes
      * 2. /_next (Next.js internals)
      * 3. /sitecore/api (Sitecore API routes)
      * 4. /- (Sitecore media)
      * 5. /healthz (Health check)
      * 6. all root files inside /public
      */
     matcher: [
       '/',
       '/((?!api/|_next/|healthz|sitecore/api/|-/|favicon.ico|sc_logo.svg|throw/).*)',
     ],
   };

Summary

With this setup:

• The Edge Config store is linked to your Vercel project via environment variables.
• Redirect data is fetched instantly at the Edge Runtime through the SDK.
• Each project can maintain its own independent redirect configuration.
• All updates reflect immediately – no redeployment required.

Points to Remember:

• Avoid overlapping or cyclic redirects.
• Keep all redirects lowercase and consistent.
• The Edge Config connection string acts as a secure token – it should never be exposed in the client or source control.
• Always validate JSON structure before saving in Edge Config.
• A backup is created on every write, maintaining a version history that can be accessed from the Backups tab of the Edge Config store.
• Sitecore-managed redirects remain supported when necessary for business or content-driven use cases.

Managing redirects at the edge has made our Sitecore XM Cloud implementations cleaner, faster, and easier to maintain. By shifting this responsibility to Next.js Middleware and Vercel Edge Config, we have created a more composable and future-ready approach that aligns perfectly with modern digital architectures.

At Perficient, we continue to adopt and share solutions that simplify development while improving site performance and scalability. If you are working on XM Cloud or planning a headless migration, this edge-based redirect approach is a great way to start modernizing your stack.

In my previous post, we explored the request lifecycle in a Sitecore headless application using Next.js, focusing on how Server Side Rendering (SSR) works in tandem with Sitecore’s Layout Service and the Next.js middleware layer.. But that’s only one part of the story.

This follow-up post dives into Static Site Generation (SSG) and Incremental Static Regeneration (ISR) – two powerful rendering modes offered by Next.js that can significantly boost performance and scalability when used appropriately in headless Sitecore applications.

Why SSG and ISR Matter?

In Sitecore XM Cloud-based headless implementations, choosing the right rendering strategy is crucial for balancing performance, scalability, and content freshness. Static Site Generation (SSG) pre-renders pages at build time, producing static HTML that can be instantly served via a CDN. This significantly reduces time-to-first-byte (TTFB), minimizes server load, and is ideal for stable content like landing pages, blogs, and listing pages.

Incremental Static Regeneration (ISR) builds on SSG by allowing pages to be regenerated in the background after deployment, based on a configurable revalidation interval. This means you can serve static content with the performance benefits of SSG, while still reflecting updates without triggering a full site rebuild.

These strategies are especially effective in Sitecore environments where:

• Most pages are relatively static and don’t require real-time personalization.
• Content updates are frequent but don’t demand immediate global propagation.
• Selective regeneration is acceptable, enabling efficient publishing workflows.

For Sitecore headless implementations, understanding when and how to use these strategies is key to delivering scalable, performant experiences without compromising on content freshness.

SSG with Sitecore JSS: The Request Lifecycle

In a Static Site Generation (SSG) setup, the request lifecycle transitions from being runtime-driven (like SSR) to being build-time-driven. This fundamentally alters how Sitecore, Next.js, and the JSS application work together to produce HTML. Here’s how the lifecycle unfolds in the context of Sitecore JSS with Next.js:

1. Build-Time Route Generation with getStaticPaths

At build time, Next.js executes the getStaticPaths function to determine which routes (i.e., Sitecore content pages) should be statically pre-rendered. This typically involves calling Sitecore’s Sitemap Service or querying layout paths via GraphQL or REST.

2. Layout Data Fetching with getStaticProps

For every path returned by getStaticPaths, Next.js runs getStaticProps to fetch the corresponding layout data from Sitecore. This data is fetched via: Sitecore Layout Service REST endpoint, or Experience Edge GraphQL endpoint

At this stage:

• Sitecore’s middleware is not executed.
• There is no personalization, since requests are not user-specific.
• The component factory in the JSS app maps layout JSON to UI components and renders them to static HTML.

3. Static HTML Generation

Next.js compiles the entire page into an HTML file using:

• The Layout JSON from Sitecore.
• Mapped UI components from the JSS component factory.
• Placeholder content populated during build

This results in fully static HTML output that represents the Sitecore page as it existed at build time.

4. Deployment & Delivery via CDN

Once built, these static HTML files are deployed to a CDN or static hosting platform (e.g., Vercel, Netlify), enabling:

• Sub-second load times as no runtime rendering is required.
• Massively scalable delivery.

5. Runtime Request Handling

When a user requests a statically generated page:

• CDN Cache Hit: The CDN serves the pre-built HTML directly from cache
• No Server Processing: No server-side computation occurs
• Client-Side Hydration: React hydrates the static HTML, making it interactive
• Instant Load: Users experience near-instantaneous page loads

Incremental Static Regeneration (ISR): The Best of Both Worlds

While SSG provides excellent performance, it has a critical limitation: content becomes stale immediately after build. ISR addresses this by enabling selective page regeneration in the background, maintaining static performance while ensuring content freshness.

ISR Request Lifecycle in Sitecore JSS Applications

1. Initial Request (Cached Response)

When a user requests an ISR-enabled page:

export const getStaticProps: GetStaticProps = async (context) => {
  const layoutData = await fetchLayoutData(context.params?.path);
  
  return {
    props: { layoutData },
    revalidate: 3600, // Revalidate every hour
  };
};

• Next.js checks if a static version exists and is within the revalidation window
• If valid, the cached static HTML is served immediately
• If the cache is stale (beyond revalidation time), Next.js triggers background regeneration

2. Background Regeneration Process

When regeneration is triggered:

1. Next.js makes a fresh API call to Sitecore’s Layout Service or GraphQL endpoint
2. Sitecore resolves the current item, applies any layout changes, and returns updated JSON
3. The JSS component factory processes the new layout data
4. The newly rendered HTML replaces the cached version
5. Updated content propagates across the CDN network

3. Subsequent Requests

After regeneration completes:

• New requests serve the updated static content
• The cycle repeats based on the revalidation interval
• Users always receive static performance, even during regeneration

Best Practices for Sitecore SSG/ISR Implementation

When implementing SSG and ISR in Sitecore headless applications, align your rendering strategy with content characteristics: use SSG for truly static pages like landing pages, ISR for semi-dynamic content such as blogs and product catalogs with appropriate revalidation intervals (5 minutes for news, 30 minutes for blogs, 1 hour for products), and continue using SSR for personalized experiences. Focus on selective pre-rendering by only building high-traffic, SEO-critical, and core user journey pages at build time while using fallback strategies for less critical content.

Conclusion: Choosing the Right Strategy

The choice between SSR, SSG, and ISR isn’t binary – modern Sitecore headless applications often employ a hybrid approach:

• SSG for truly static content that rarely changes
• ISR for content that updates periodically but doesn’t require real-time freshness
• SSR for personalized experiences and rapidly changing content

By understanding the request lifecycle for each rendering strategy, you can architect Sitecore headless solutions that deliver exceptional performance while maintaining content flexibility. The key is aligning your technical approach with your content strategy and user experience requirements. So, choose your rendering strategy wisely!

In the era of traditional Sitecore MVC, the rendering lifecycle was tightly coupled to the Sitecore server. HTML generation, content retrieval, and presentation logic were all orchestrated within a single monolithic application. With the advent of headless architectures built using Sitecore JSS and platforms like XM Cloud, this paradigm has significantly shifted. Rendering responsibilities now move to decoupled frontend applications, enabling greater flexibility, scalability, and performance.

The responsibility for rendering has been decoupled and offloaded to a dedicated front-end application (e.g., React, Next.js, Vue.js), transforming Sitecore into a highly optimized content and layout delivery platform via robust APIs. For developers building Sitecore headless applications, a profound understanding of how a request traverses from the browser, through the front-end rendering host, interacts with Sitecore, and ultimately returns a rendered page, is paramount. This intricate knowledge forms the bedrock for effective debugging and advanced performance optimization.

This blog post will meticulously breaks down:

• The generalized request processing flow in Sitecore headless applications.
• The specific instantiation of this flow within JSS applications built leveraging the Next.js framework.
• Debugging tips.

Sitecore XM Cloud and other headless Sitecore setups embody the principle of separation of concerns, decoupling content management from presentation logic. Rather than Sitecore generating the final HTML markup, your front-end rendering application (React/Next.js) dynamically fetches content and layout data via API endpoints and orchestrates the rendering process, whether client-side or server-side. Comprehending this architectural decoupling is critical for engineering performant, scalable, flexible, and personalized digital experiences.

The General Request Flow in Sitecore Headless Architectures

Irrespective of the specific front-end rendering host, the foundational request processing flow in Sitecore headless applications remains consistent:

1. Client Request Initiation: A user initiates a request by navigating to a specific URL (e.g., https://www.example.com/about) in their web browser. This request is directed towards your front-end rendering host.
2. Front-end Rendering Host Interception: The front-end rendering host (e.g. a Next.js application deployed on Vercel, or Netlify) receives the incoming HTTP request.
3. Data Fetching from Sitecore: The rendering host, acting as a data orchestrator, makes an API call to Sitecore to retrieve the necessary page layout and content data. This can occur via two primary mechanisms:
   • Sitecore Layout Service : A traditional RESTful endpoint that delivers a comprehensive JSON representation of the page’s layout, components, and associated field values. This service is part of the Sitecore Headless Services module.
   • Sitecore Experience Edge GraphQL API: A more flexible and performant GraphQL endpoint that allows for precise data querying. This is the preferred mechanism for XM Cloud-native applications, providing a single endpoint for diverse data retrieval.  Critical parameters passed in this request typically include route (the requested URL path), sc_lang (the desired content language), sc_site (the target Sitecore site definition), and potentially additional context parameters for personalization or A/B testing.
4. Sitecore Route and Context Resolution: Upon receiving the data request, the following server-side operations are performed:
   • Item Resolution: It resolves the incoming route parameter to a specific Sitecore content item within the content tree, based on defined route configurations (e.g., sitecore/content/MyTenant/MySite/About).
   • Context Establishment: It establishes the current request context, including the site, language, and user session, personalized page variant.
   • Layout Computation: Based on the resolved item and evaluated personalization, Sitecore computes the final page layout, including the arrangement of renderings within placeholders and the specific data sources for each component.
5. Sitecore Response Generation: A structured JSON payload is returned to the rendering host. This payload typically includes:
   • Layout Metadata: Information about the overall page structure, placeholder definitions, and associated rendering components.
   • Component Data: For each component on the page, its type (e.g., “Hero”, “RichText”), its associated data source item ID (if applicable), and all serialized field values (e.g., Title, Body, Image).
6. Front-end Rendering: The rendering host receives the JSON payload and, using its component factory (a mapping between Sitecore component names and UI component implementations), dynamically constructs the HTML for the requested page.
   • Component Mapping: Each JSON-defined component type is mapped to its corresponding React/Next.js UI component.
   • Data Binding: The serialized field values from the JSON are passed as props to the UI components.
   • Placeholder Resolution: The rendering host iterates through the placeholder definitions in the JSON, rendering child components into their designated placeholder regions.
   • Client-side Hydration: For server-rendered applications (SSR/SSG), the initial HTML is sent to the browser, where React then “hydrates” it, attaching event listeners and making the page interactive.
   • Post-render Actions: Any client-side personalization or analytics integration (e.g., Sitecore Personalize Engage SDK) may occur after the initial page render.

Key takeaway: In a headless setup, Sitecore acts as the intelligent provider of content and layout data via APIs, while the front-end application takes full ownership of rendering the final HTML and handling all user interface interactions.

Deep Dive: Request Lifecycle in JSS + Next.js Applications

The general headless flow finds its specific implementation within a JSS application leveraging the Next.js framework, benefiting from Next.js’s powerful data fetching and rendering capabilities. We’ll focus specifically on Server-Side Rendering (SSR) here, while a separate post will cover Static Site Generation (SSG) and Incremental Static Regeneration (ISR).

1. User Request Initiation

A user navigates to a specific route, such as /products, initiating an HTTP GET request directed to your deployed Next.js application, which acts as the unified rendering endpoint.

2. Next.js Middleware and Sitecore Add-on Integration (Edge-Based Execution)

If implemented, the middleware.ts file in your Next.js application executes at the Edge (close to the user) before the request even reaches your application’s pages. This provides an opportune moment for early request manipulation and context enrichment:

• Authentication & Authorization: Redirecting unauthorized users or validating session tokens.
• Request Rewrites & Redirects: URL transformations based on dynamic conditions.
• Header Manipulation: Injecting custom headers or modifying existing ones.
• Contextual Data Injection: Reading user-specific cookies, geolocation data, and potentially passing this context to downstream services via HTTP headers.

This middleware layer is where Sitecore XMCJSS Next.js add-ons particularly shine, streamlining complex Sitecore-specific functionalities.

2.1 Sitecore JSS Next.js Add-ons: Extending Middleware Capabilities

Sitecore provides specialized add-ons for JSS Next.js applications that are designed to integrate seamlessly with Next.js middleware, enhancing data fetching and other critical functionalities at the Edge. These add-ons abstract away much of the boilerplate code, allowing developers to focus on business logic.

Key add-ons relevant to the request lifecycle and that are compatible with XM Cloud are:

• SXA (nextjs-sxa):
  • Includes example components and the setup for Headless SXA projects.
• Next.js Multisite Add-on (nextjs-multisite):
  • Enables a single Next.js rendering host to serve multiple Sitecore sites.
  • Leverages middleware to resolve the correct Sitecore site (sc_site parameter) based on the incoming request’s hostname, path, or other routing rules. This ensures the correct site context is passed to the Layout Service or GraphQL calls.
  • Often uses a GraphQLSiteInfoService to fetch site definitions from Sitecore Experience Edge at build time or runtime.
• Next.js Personalize Add-on (nextjs-personalize):
  • Integrates with Sitecore Personalize (formerly Boxever/CDP) for advanced client-side personalization and experimentation.
  • Its core component, the PersonalizeMiddleware, is designed to run at the Edge.
  • The PersonalizeMiddleware makes a call to Sitecore Experience Edge to fetch personalization information (e.g., page variants).
  • It then interacts with the Sitecore CDP endpoint using the request context to determine the appropriate page variant for the current visitor.
  • Crucially, if a personalized variant is identified, the middleware can perform a rewrite of the request path (e.g., to /_variantId_<variantId>/<original-path>). This personalized rewrite path is then read by the Next.js app to manipulate the layout and feed into client-side Page View events. This allows client-side logic to render the specific personalized content.
  • Also includes a Page Props Factory plugin to simplify data retrieval for personalized content.

These add-ons are included in your application when you create a Next.js project with the JSS initializer script, you can include multiple add-ons in your application. In addition to the above add-ons, you also get middleware plugin  redirects.ts that supports and enables redirects defined in Sitecore.

3. Next.js Server-Side Rendering (SSR) via getServerSideProps

JSS Next.js apps commonly employ a catch-all route (e.g., pages/[[...path]].tsx) to dynamically handle arbitrary Sitecore content paths. The getServerSideProps function, executed on the rendering host server for each request, is the primary mechanism for fetching the Sitecore layout data.

While Sitecore add-ons in middleware can pre-fetch data, getServerSideProps remains a critical point, especially if you’re not fully relying on middleware for all data, or if you need to merge data from multiple sources. The layoutData fetched here will already reflect any server-side personalization applied by Sitecore based on context passed from middleware.

4. Sitecore Layout Service / Experience Edge GraphQL Processing

Upon receiving the data fetch request from the Next.js application, Sitecore’s backend performs a series of crucial operations as mentioned earlier – resolves the route, evaluates the context (such as language, site, and device), and assembles the appropriate renderings based on the presentation details. It then serializes this information – comprising route-level fields, component content, placeholder hierarchy, and any server-side personalization – into a structured JSON or GraphQL response. This response is returned to the rendering host, enabling the front-end application to construct the final HTML output using the data provided by Sitecore.

5. Rendering with the JSS Component Factory

Upon receiving the layoutData JSON, the JSS Next.js application initiates the client-side (or server-side during SSR) rendering process using its component factory. This factory is a crucial mapping mechanism that links Sitecore component names (as defined in the componentName field in the Layout Service JSON) to their corresponding React UI component implementations.

6. HTML Response to Browser

Next.js completes the server-side rendering process, transforming the React component tree into a fully formed HTML string. This HTML, along with any necessary CSS and JavaScript assets, is then sent as the HTTP response to the user’s browser. If personalization rules were applied by Sitecore, the returned HTML will reflect the specific component variants or content delivered for that particular user.

7. Client-Side Hydration

Once the browser receives the HTML, React takes over on the client-side, “hydrating” the static HTML by attaching event listeners and making the page interactive. This ensures a seamless transition from a server-rendered page to a fully client-side interactive single-page application (SPA).

 Debugging Tips for Sitecore JSS Applications

When working with Sitecore JSS applications, in headless setups, debugging can be a crucial part of development and troubleshooting when components fail to render as expected, personalization rules seem to misfire, or data appears incorrect.

1. Enable Debug Logs in the JSS App

JSS uses a logging mechanism based on debug – a npm debugging module. The module provides a debug() function, which works like an enhanced version of console.log(). Unlike console.log, you don’t need to remove or comment out debug() statements in production – you can simply toggle them on or off using environment variables whenever needed.

To activate detailed logs for specific parts of your JSS app, set the DEBUG environment variable.

1. To output all debug logs available, set the DEBUG environment variable to sitecore-jss:*. The asterisk (*) is used as a wildcard. DEBUG=sitecore-jss:*
2. To filter out and display log messages from specific categories, such as those related to the Layout Service, set the variable like so  DEBUG=sitecore-jss:layout
3. To exclude logs of specific categories use - prefix: DEBUG=sitecore-jss:*,-sitecore-jss:layout

Please refer to this document to get details of all the available debug logging.

2. Use Browser DevTools to Inspect Logs

If your app runs client-side, and the debug package is configured, JSS logs will appear in the browser console.

To enable this manually in the browser, set this in the browser console:

localStorage.debug = 'jss:*';

Then refresh the page. You’ll start seeing logs for:

• Layout service requests

• Component-level rendering

• Data fetching and personalization events

3. Leveraging Server-Side Logging within Next.js

Next.js’s server-side data fetching functions (getServerSideProps, getStaticProps) provide excellent points for detailed logging. Add console.log statements within your getServerSideProps or getStaticProps functions to get more details of the request and its data. When deployed to platforms like Vercel, or Netlify, these console.log statements will appear in your serverless function logs (e.g., Vercel Function Logs).

Additionally, when deploying your Sitecore headless application on Vercel, you can leverage Vercel’s built-in request logging and observability features. These tools allow you to track incoming requests, inspect headers, view response times, and monitor serverless function executions. This visibility can be especially helpful when debugging issues related to routing, personalization, or data fetching from the Layout Service or other backend APIs.

Wrapping It All Up: Why This Matters

Understanding how requests are processed in Sitecore Headless applications – especially when using JSS with Next.js – gives developers a strong foundation for building high-performing and maintainable solutions. By grasping the complete request lifecycle, from incoming requests to Layout Service responses and component rendering, you gain the clarity needed to architect more efficient and scalable applications. Coupled with effective debugging techniques and observability tools, this knowledge enables you to identify bottlenecks, troubleshoot issues faster, and deliver seamless user experiences. With Sitecore’s architecture already embracing composable and headless paradigms, understanding these fundamentals is essential for developers looking to build modern, future-ready digital experiences.

At Perficient, we believe that continuous learning is essential for excellence. This commitment drives us to evolve and master the latest technologies, ensuring the best possible delivery for our clients. This belief fuels our team’s pursuit of mastering cutting-edge technology.

On that note, we’re incredibly proud to announce a significant achievement for our Nagpur team! Six dedicated team members have successfully completed their Contentstack Implementation training and certification, equipping them with the expertise to deliver advanced headless CMS solutions to our clients.

A huge congratulations to the following achievers for their hard work and dedication in earning this significant certification! Their commitment to continuous learning and mastering new technologies is a reflection of the strong talent pool we have.

1. Mahima Patel
2. Sandeep Reddy Duddeda
3. Aditi Paliwal
4. Ashish Chinchkhede
5. Akshay Gawande
6. Vikrant Punwatkar

Our newly certified Contentstack implementers have undergone extensive training. They gained solid knowledge in content modeling, API integration, workflow automation, and best practices for creating scalable and efficient digital experiences with Contentstack. This expertise allows us to better assist our clients in maximizing their digital presence.

Why is this a big deal for Perficient and our clients?

In today’s fast-moving digital world, businesses really need to be agile, flexible, and able to deliver content smoothly across a growing number of channels. That’s exactly where Contentstack stands out as a top-notch headless CMS, and we’re genuinely thrilled to have our team leading the charge in this game-changing technology.

We’re looking forward to the exciting opportunities this enhanced capability offers our clients, and we are eager to leverage Contentstack to create even more innovative, impactful, and future-ready digital solutions.

Maybe you’ve already made the switch to XM Cloud, or maybe you’re still evaluating it as the answer to all your digital delivery challenges. Spoiler alert: it won’t magically solve everything — but with the right setup and smart optimizations, it can absolutely deliver fast, scalable, and maintainable experiences.

If you’re using Sitecore Headless with Next.js, you’re already building on a modern and flexible foundation. Add in a deployment platform like Vercel, and you’ve got serious power at your fingertips. But unlocking that potential requires knowing where to fine-tune — both at the application and platform level.

Streamline Your Layout and API Payloads

The Sitecore Layout Service is versatile but can return bulky JSON payloads if left unchecked. Clean up your responses by:

• Removing unused placeholders and renderings

• Filtering out internal tracking or analytics fields unless explicitly needed

• Configuring the Layout Service to tailor the response to your frontend needs

If you’re using Sitecore Search or XM Cloud with GraphQL, concise queries will help keep your pages fast and predictable

• Request only the fields you need

• Use first: or limit: to control result size

• Organize queries into reusable fragments for maintainability and performance

Smaller payloads result in faster hydration, quicker time-to-interactive, and lower bandwidth usage — all especially valuable for mobile-heavy audiences.

Use Webhooks for Smarter Publishing (On-demand Revalidation or ODR)

Don’t rely on manual rebuilds or blanket cache clears. XM Cloud supports webhooks on publish, which opens the door to smarter automation:

• Trigger on-demand ISR revalidation for updated pages

• Push new content to Edge Config, CDNs, or search indexes

• Notify external systems (e.g., analytics, commerce, personalization) immediately

It’s the best way to keep content fresh without sacrificing performance or rebuilding the entire site.

Choose the Right Rendering Method: SSR, SSG, or ISR?

Not every page needs to be dynamic, and not every page should be static. Picking the right rendering strategy is critical — especially in a Sitecore headless app where you’re mixing marketing content with personalization and real-time updates.

Here’s how to decide:

Use SSR (Server-Side Rendering) when:

• The page depends on the user session or request (e.g., personalization, authenticated pages)

• You’re rendering in preview mode for content authors

Use SSG (Static Site Generation) when:

• The content rarely changes (e.g., static landing pages or campaigns)

• You want instant load times and no server cost

Use ISR (Incremental Static Regeneration) when:

• Content changes periodically, but not per-request

• You want to combine the speed of static with the freshness of dynamic

Use next/link with Prefetching

If you’re still using regular <a> tags or not thinking about navigation performance, this one’s for you. The next/link component enables fast, client-side routing and automatic prefetching of pages in the background.

Example:

import Link from 'next/link';

<Link href="/products" prefetch={true}>About Us</Link>

• Use it for all internal links

• Set prefetch={true} on high-priority routes

• Check behavior in your browser’s network tab — look for .json page data being fetched in advance

This alone can make your site feel instantly faster to users.

Optimize Fonts with next/font

Sitecore headless apps don’t include next/font by default, but it’s worth integrating. It allows you to self-host fonts in a performance-optimized way and avoid layout shifts.

Example:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

Apply fonts globally or per-page to improve loading consistency and avoid FOUT (Flash of Unstyled Text). Better fonts = better user experience.

Clean Up Your Codebase

Performance isn’t just about server-side logic — it’s also about keeping your codebase lean and clean.

What to review:

• Old personalization plugins that are no longer used

• Middleware that’s too permissive or generic in its matching

• Outdated multisite logic if you’ve already split into multiple Vercel projects

• Unused components or fetch logic in shared utilities

Use Vercel performance insights to track slow routes and spot cold starts.

Enable Fluid Compute

Fluid Compute lets Vercel reuse idle time across your serverless functions. That means better performance and lower costs — without any code changes.

To enable it:

• Go to your Vercel project settings

• Navigate to Functions

• Toggle Fluid Compute on

You can monitor the impact under Observability → Logs in your dashboard. It’s a low-effort win. Read more details about Fluid Compute in my previous blog!

Be Selective with Middleware

Next.js middleware is powerful but potentially expensive in performance terms. Use it wisely:

• Limit middleware to only essential routes

• Avoid using fetch() inside middleware — use Edge Config instead

• Replace multisite plugins with separate Vercel projects

• Audit unused or legacy logic, especially leftover personalization

Track middleware behavior through the Middleware tab in Vercel Logs.

Manage Redirects with Edge Config

For the fastest possible redirects, manage them directly in Vercel using Edge Config. This keeps Sitecore out of the request path and ensures instant resolution at the edge.

• Store all redirect data in Edge Config
• Deploy updates as part of your app or via external config tools
• Avoid real-time fetches from Sitecore for redirect logic

If you’re managing a large volume of redirects, consider using a bloom filter to optimize memory usage. Just note that bloom filters introduce a small delay due to redirect verification.

Conclusion

Optimizing a Sitecore Headless application, especially one deployed on Vercel, is about making dozens of small, smart decisions that add up to big wins in performance, scalability, and developer happiness. Whether it’s pruning your Layout Service output or toggling a setting in your Vercel dashboard, each move brings you closer to a faster, more responsive site.

XM Cloud doesn’t come pre-optimized — but that’s actually a good thing. It gives you the power and flexibility to build the way you want. Just make sure you’re building it right.

Optimization Checklist

Sitecore & XM Cloud

• Prune Layout Service JSON (remove unused placeholders and fields)

• Use GraphQL efficiently (limit queries, use fragments)

• Set up publish webhooks for on-demand rendering or cache purging

Rendering Strategy

• Use SSR for personalized/authenticated content

• Use SSG for static pages

• Use ISR for hybrid performance/freshness

Next.js

• Replace <a> with next/link and enable prefetching

• Add next/font for consistent and fast font rendering

Vercel

• Enable Fluid Compute for better serverless efficiency

• Use middleware only where necessary and avoid fetch inside

• Use Edge Config for fast redirect handling

• Monitor logs and performance insights for slow routes and cold starts

What is GraphQL?

GraphQL is a powerful query language for APIs that allows clients to request only the data they need. Optimizely leverages GraphQL to serve content to your platform agnostic presentation layer. This approach to headless architecture with Optimizely CMS is gaining traction in the space and developers often encounter new challenges when transitioning from the more common MVC approach.

In this blog post, we will explore some common errors you’ll encounter and how to troubleshoot them effectively.

Common Errors

1. Schema Mismatches

Description

Some of the most frequent issues arise from mismatches between the GraphQL schema and the content models in Optimizely. This can occur from mistyping fields in your queries, not synchronizing content in the CMS, or using the wrong authentication key.

Example Error

{
"errors": [
    {
      "message": "Field \"Author\" is not defined by type \"BlogPage\".",
      "locations": [
        {
          "line": 2,
          "column": 28
        }
      ]
    }
  ]
}

Solution

• Double check your query for any mismatches between field and type names
  • Case-sensitivity is enforced on Types/Properties
• Validate that the API Key in your GraphQL Query matches the API Key in the CMS environment you’ve updated
• Ensure that your GraphQL schema is up-to-date with the latest data model changes in Optimizely.
  • If you are running the CMS with the same Graph API Keys, check the GraphQL Explorer tab and validate that your type shows in the listing
• Run the ‘Optimizely Graph content synchronization job’ from the CMS Scheduled Jobs page.
  • After you see the Job Status change from ‘Starting execution of ContentTypeIndexingJob’ to ‘Starting execution of ContentIndexingJob’ you can stop the job and re-run your query.
• Reset the Account
  • If all else fails you may want to try to reset your GraphQL account to clear the indices. (/EPiServer/ContentGraph/GraphQLAdmin)
  • If you are sharing the key with other developers the schema can become mismatched when making local changes and synchronizing your changes to the same index.

2. Maximum Depth

Description

When querying nested content, you may see an empty Content object in the response rather than your typed content.

Example Error

In this scenario, we are trying to query an accordion set block which has multiple levels of nested content areas.

Query

query MyQuery {
  Accordion {
    items {
      PanelArea{
        ContentLink {
          Expanded {
            ... on AccordionPanel{
              PanelContent{
                ContentLink {
                  Expanded {
                    ... on CardGrid{
                      CardArea {
                        ContentLink {
                          Expanded {
                            ... on Card{
                              CtaArea{                                
                                ContentLink{
                                  Expanded{
                                    __typename
                                    ...on Button {
                                      __typename
                                    }

Response

{
  "data": {
    "Accordion": {
      "items": [
        {
          "PanelArea": [
            {
              "ContentLink": {
                "Expanded": {
                  "PanelContent": [
                    {
                      "ContentLink": {
                        "Expanded": {
                          "CardGrid": [
                            {
                              "ContentLink": {
                                "Expanded": {
                                  "CtaArea": [
                                    {
                                      "ContentLink": {
                                        "Expanded": {
                                          "__typename": "Content"
                                        }
       ...
}

Solution

• Configure GraphQL to use higher maximum depth in appsettings
  • The default level of nesting content is 3, but that can be modified in Startup.CS
    services.AddContentGraph(options => { options.ExpandLevel.Default = 5 options.ExpandLevel.ContentArea = 5; });
  • Note that increasing this will increase the document size and make the synchronization job much slower depending on the amount of content and level of nesting in your site.
• Break-up requests into multiple queries.
  • Instead of expanding the inline fragment (… on Block) instead get the GuidValue of the ContentModelReference and use subsequent queries to get deeply nested content.
  • Consider making this extra request asynchronously on the client-side to minimize performance impact.

3. Authentication Errors

Description

There are a few different scenarios where you can get a 401 Authentication Error response on your GraphQL query.

{
  "code": "AUTHENTICATION_ERROR",
  "status": 401,
  "details": {
    "correlationId": "1234657890"
  }
}

Solution

• Check your authentication tokens and ensure they are valid.
• If you are querying draft content you need to configure and enable preview tokens Documentation

4. Unsynchronized Content

Description

When making updates to content in the CMS, you will occasionally run into issues where you don’t see the updated content on the page or in the graph response.

Solution

• Confirm that Content has been synchronized
  • In the CMS you can determine whether or not Content has been synchronized by the checkmark icon in the Publish Options ‘Synchronize with Optimizely Graph’ button
    
  • If the ‘Synchronize with Optimizely Graph’ button is not triggering the content to be synced check to see if either of the Optimizley Graph Synchronization Jobs are in progress.  When they are running, manually syncing content will be delayed until job completion.
• Validate that your CMS Graph API Key matches the API Key in your front-end/graph query

In the ever-evolving world of web development, the term “headless” is as popular today as it ever has been. But what does it really mean, and why should you care? Let’s dive into the concept of headless architecture, its benefits, and why Sitecore is leading the charge in this space.

What is Headless?

At its core, a headless CMS is a software design approach that separates the front-end (what users see) from the back-end (where content is managed). Unlike traditional CMS platforms that tightly couple content management with presentation, headless CMS’s use APIs to deliver content anywhere—web, mobile app, kiosk, or a smart device. In many ways, the originator of headless architecture is Jamstack – which stands for JavaScript, APIs, and Markup. Instead of relying on traditional monolithic architectures, Jamstack applications decouple the web experience from the back-end, making them more scalable, flexible, and high-performing. JavaScript handles dynamic interactions on the front-end, allowing developers to build fast and modern user experiences. API’s provide a way to pull in content and services from various sources and the website can also push data to API’s such as form submissions, custom analytics events and other user driven data. Markup refers to pre-built HTML that can be served efficiently, often generated using static site generators or frameworks like Next.js.

Why Go Headless?

You might be wondering, “Why would I build my website entirely in JavaScript when it’s mostly content?” That’s a valid question and I thought the same when Sitecore JSS first came out. Headless though is less about “building your site in JavaScript” and more about the benefits of the architecture.

Flexibility

Headless CMS’s allow developers to work with any front-end framework they choose, whether it’s React, Vue, Angular, or whatever your favorite framework might be. This means teams are not locked into the templating system of a traditional CMS or the underlying backend technology.

Performance

Speed is everything in today’s digital landscape. Studies show that even a slight delay in page load time can significantly impact user engagement and conversion rates. Headless CMS’s improve performance by enabling static site generation (SSG) and incremental static regeneration (ISR)—both of which ensure lightning-fast load times. Instead of a server processing each request from a user, static content can be served from a global CDN – which is a modern composable architecture. Of course, server side rendering is also still an option and can also by very performant with the right caching strategy.

Omnichannel Delivery

Content today is consumed on more than just websites. Whether it’s a mobile app, smart device, digital kiosk, or even a wearable, headless architecture ensures content can be delivered anywhere through API’s. This makes it easier for brands to maintain a consistent digital experience across multiple platforms without duplicating content.

Security

Traditional CMS’s are often vulnerable to security threats because they expose both the content management system and the front-end to potential attacks. In contrast, headless CMS’s separate these layers, reducing the attack surface. With content served via APIs and front-end files hosted on secure CDNs, businesses benefit from enhanced security and fewer maintenance headaches.

Scalability

Handling high traffic volumes is a challenge for traditional CMS platforms, especially during peak times. Since headless solutions rely on cloud-based infrastructure, they can scale dynamically without requiring expensive hardware upgrades. Whether you’re serving thousands or millions of users, headless architecture ensures your site remains stable and responsive.

Why Sitecore for Headless?

There are plenty of options in the headless CMS market, but Sitecore offers a unique blend of features that make it stand out. With XM Cloud, Sitecore provides a fully SaaS-based solution—no more infrastructure headaches, no more costly upgrades, and uptime and reliability are now handled by Sitecore.

Sitecore’s hybrid headless approach allows organizations to transition at their own pace, leveraging the benefits of headless while maintaining familiar content management workflows. Hybrid headless gives content authors complete freedom and flexibility to build content however they’d like – where most purely headless content management systems are more rigid on how pages are built.

As digital experiences become more dynamic and user expectations continue to rise, headless CMS solutions offer the agility businesses need. If you’re looking to modernize your digital strategy, now is the time to embrace headless.

Delivering exceptional digital experiences requires a powerful, flexible, and scalable content management system. Optimizely’s SaaS CMS continues to evolve with new features and innovations designed to drive efficiency, enhance flexibility, and unlock greater value. Perficient, a trusted leader in digital transformation, has deep expertise in Optimizely solutions, helping businesses implement and optimize their CMS strategies for maximum impact. Here’s a look at the latest advancements that can enhance content management and customer experiences.

Why SaaS CMS Matters

SaaS CMS was developed to provide businesses with a seamless, scalable, and cost-efficient content management solution. Key benefits include:

• Automatic Updates: Stay up to date with the latest features—no manual effort required.
• Scalability: Effortlessly handle traffic spikes and evolving content needs.
• Flexibility: Headless configurations and multi-channel delivery for diverse requirements.
• Superior User Experience: Streamlined workflows, continuous releases, and faster time to value.

By combining these strengths, SaaS CMS enables businesses to adapt to ever-changing digital demands and deliver engaging, personalized content efficiently.

New Features and Enhancements

1. Visual Builder Enhancements

• Section-Enabled Blocks: Editors can leverage preconfigured design elements, improving productivity and consistency. Reusable templates ensure faster page builds without requiring technical expertise.
• Interactive Previews: Real-time previews at the element level allow teams to visualize changes instantly, reducing errors and enhancing collaboration.
• Styling Control: Developers can define style options, ensuring brand consistency while giving editors a guided but flexible approach to design.

2. Robust Scalability

• SaaS CMS now includes hyperscaler capabilities to handle increased traffic automatically. Hosting flexibility and reliability are enhanced through integrations with Vercel and Netlify, enabling seamless scaling.

3. Enhanced Content Modeling and Multi-Step Workflows

• The new Content Modeling UI simplifies content structuring, making it easier to create and manage content types.
• Customizable multi-step workflows streamline approval processes and improve content governance.

4. Expanded Language Support

• Enhanced semantic search capabilities support additional languages, broadening global reach.
• AI-driven search refines content discovery by understanding user intent and delivering more accurate results.

5. HIPAA-Ready Compliance

• For organizations in healthcare and other regulated industries, SaaS CMS now supports HIPAA readiness, ensuring compatibility with compliance requirements.

What’s on the Roadmap?

Graph Portal

• A new Graph Portal will enable teams to build and manage queries, set up webhooks, and troubleshoot with ease.

AI-Powered Auto-Translations

• Automated translations will simplify multilingual content management, allowing businesses to expand their global presence efficiently.

Integrated Digital Asset Management (DAM)

• A seamless DAM integration will eliminate the need to switch between systems, streamlining content workflows.

Embedded Experimentation and Personalization

• A/B testing and feature experimentation will be embedded directly into the CMS UI, enabling businesses to deliver personalized digital experiences with precision.

How SaaS CMS Drives Business Value

• Faster Time to Market: Automatic updates, reusable components, and intuitive tools accelerate project delivery.
• Enhanced User Experiences: Organizations can deliver personalized, scalable, and engaging content across channels effortlessly.
• Cost Efficiency: Reduced operational overhead allows businesses to allocate resources more effectively.

Perficient’s Optimizely practice helps organizations implement and maximize the benefits of SaaS CMS, ensuring they stay ahead of evolving digital needs. By leveraging these new advancements, businesses can optimize their content strategy, enhance user engagement, and drive measurable results.

As Sitecore has started supporting Headless CMS architecture, from my working experience on headless JSS projects, I thought of putting together a series of blogs demonstrating the basics that one has to do in Sitecore Next.js project.

In my first blog, I will explain about creating new component in sitecore and frontend project.

The prerequisite to practically perform these steps is to have project setup.

If project setup is not done, please refer to this informative blog from Martin Miles : Creating a containerized Sitecore Headless StarterKit with the latest Next.js SDK and Headless SXA

Assuming that everything is setup, let’s get started with creating a component:

• Create sitecore template

As the first step of creating any component, create a template to define a structure and behavior of item created from that template, create a template in sitecore for required fields. Here I have added 2 fields – Image and Content for example.

• Create sitecore component

  1. Create JSON rendering with appropriate name under folder “/sitecore/layout/Renderings/Project/<Project-Name>”
  2. Add datasource template and datasource location so that when content editor adds a rendering to any item, defined template will be used to create datasource item and datasource item will be created on specified location.

• Make sure to add newly created component rendering to allowed controls in “Main placeholder” item to leverage the option for content editor to add respective component to item using experience editor.

• Create component in Next.js App

Now that component in Sitecore is created, create component in Next.js App.

1. 1. Go to /src/components folder, right click and select “New file”, Create file with .tsx extension.
   2. Define component with same name as JSON rendering created as Sitecore
   3. Add fields same as sitecore template as props.
   4. Render the field props value in Sitecore tags as below.

• Add data for component

Open experience editor and add component to placeholder and update data for fields and the data will get rendered as expected

• Once everything is done, publish the content and validate the page.
  1. I generally use Chrome React developer tool to check what and how data is coming from Layout service
  2. You can also check same on https://<your site host>/sitecore/api/layout/render/jss?item=/&sc_apikey=<API key>&sc_site=<YOUR SITE NAME>&sc_mode=normal
  3. API key can be fetched from 2 places:
     • scjssconfig.json file under src/rendering folder
     • /sitecore/system/Settings/Services/API Keys/<api key item name>

__PRESENT

__PRESENT

__PRESENT

__PRESENT__PRESENT__PRESENT

__PRESENT

__PRESENT__PRESENT__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT__PRESENT__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT

In the previous blog, I demonstrated how to create a new component in JSS Next.js app. If you must have noticed, I added it to an existing Main placeholder, however most of us come across scenarios where we have to create new placeholders to build the desired page design.

So, in this blog, I will add a new placeholder and display it in experience editor to facilitate adding more components in it.

Create Placeholder in Sitecore

Create a new placeholder in path: /sitecore/layout/Placeholder Settings/Project/<Project-Name>/<Placeholdername>

I have created placeholder with the key : jss-container

Create placeholder in Code

Now, add the placeholder in our frontend component code.

• To know how to create a JSON rendering, please refer to my previous blog.

Being a conventional Sitecore developer, one would directly jump on to adding components to the newly created placeholder in EE. So, now I added the rendering “FullWidthContainer” in the jss-main placeholder in Experience Editor.

The rendering item was already added to “Allowed Controls” field in Main placeholder: /sitecore/layout/Placeholder Settings/Project/<project-name>/jss-main to make it available here.

After adding the rendering and saving changes, I got the below error instead of getting the newly added placeholder.

This error was bound to happen because we are missing one configuration/setting that has been introduced with Sitecore JSS. We have to add all the newly created nested placeholders in a field called “Layout Service Placeholders”  in the respective Sitecore rendering.

To resolve this issue, make sure to select the new placeholder item in “Layout Service Placeholders” MultiList field of JSON rendering item which contains the placeholder code.

Once placeholder  is added to layout service placeholder field, it will render on the page and will allow to add other components to it.

Following the same steps, you can add multiple placeholders to a component which is imperative when creating a nested structure.

__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT

__PRESENT

I previously wrote about Sitecore Content Hub ONE and its place in the market as a new pure-play headless CMS. One of the key differentiators of a pure-play headless CMS is the lack of any presentation or visual rendering of content. They focus on managing content in its purest form in a repository to syndicate it to any channel. While many organizations still leverage pure play headless CMS’s to build traditional web experiences, a good fit use case is to provide physical world and virtual world omnichannel experiences. Let’s dive in!

Use Cases for Virtual Worlds

Brands can leverage virtual worlds to bring a traditional physical experience to consumers in a browser-based virtual experience. There are a number of use cases where this may be beneficial, for example:

Education

Universities often provide campus tours to prospective students looking to get a feel for the campus. What if a prospective student cannot make the physical journey to the campus but still wants to experience what it is like? A partially curated free-form virtual tour in a web browser can enable prospects to navigate around the campus, see key landmarks, and learn information about the campus — the same information afforded in a live physical tour.

(Image: virtual tour of Harvard College, the undergraduate program at Harvard University)

Healthcare

Hospital systems and buildings are often filled with endless corridors and elevator banks all over the place. Sometimes it can be overwhelming to know where to go. Providing a virtual in-browser experience of navigating the corridors and clinics of a hospital can afford people the ability to see what they’re getting into before going to the hospital.

This is also an opportunity for personalization! For example, say you’re having a procedure at a hospital and have never been to a particular part of the building. A few days before your procedure you can receive an email with a link to a curated tour of entering the building and navigating the exact path to the clinic or location in the building where you need to go.

(Image: curated virtual journey into Boston Children’s Hospital)

Tourism

A pandemic hits the entire world. Travel is shut down. Tourism and cultural events grind to a halt. Providing a virtual experience for a tourist destination may be in order. Museums, sporting venues, and historical landmarks are among the types of locations that can still provide an experience without a physical presence.

From Virtual Back to Physical

We can take the virtual world concept one step further by implementing an omnichannel strategy. Museums and landmarks can take physical signs/plaques at exhibits and turn them into digital signs. You know what can power that digital signage? The same content from the same headless CMS. So the content can be updated over time and it will consistently syndicate out to both the physical digital signage and virtual in-browser experience. Win-win!

(Image source: https://www.intuiface.com/blog/museums-and-interactive-displays)

Sitecore Pano – Manage Virtual Experiences in Content Hub ONE

Sitecore Pano is a demo of a virtual world-like experience using a panoramic library and Content Hub ONE to source content. Each panoramic scene contains an equirectangular image and any number of hotspots. Hotspots use pitch and yaw for dimensional placement on the panoramic image, and text when hovering over them of informational content. The possibilities are endless with how you want to augment your virtual experience with content since under the hood Content Hub ONE can store any content you need.

Try Sitecore Pano

How can I get involved?

As of 11/8/2023 the GitHub repository is now available: https://github.com/mursino/sitecore-pano

Perficient’s XM Cloud Jumpstart helps existing Sitecore customers who want to adopt XM Cloud create and execute a plan to move their MVC solutions to XM Cloud using Next.js and React or rapidly implement a greenfield solution according to the best industry standards from scratch.

Regardless of your starting point, JumpStart delivers a better experience to visitors and ensures your marketing and development teams are ready to take full advantage of the platform. Perficient’s brilliant XM Cloud JumpStart solution comes as the essence of the company’s collective well-documented experience, derived from our XM Cloud and Headless experts’ discoveries, improvements, and of course – real project expertise.

What are the key features of Perficient XM Cloud JumpStart?

• it benefits from the latest versions of XM Cloud offering – we carefully monitor and sync updates regularly which allows you to stay up to date with the latest features, like Next.js SDK.
• supports multisite architecture in all possible ways, whether you want to share the same resources within the same rendering host or are looking for total isolation between websites
• multilingual support with scaffolding all the required dependencies, such as dictionaries, language switchers, etc.
• SEO friendliness – achieved by a combination of our custom implementation and the best OOB SXA configuration
• DevOps automation and infrastructure provisioning as well as support for multiple Source code providers (such as Azure DevOps) not just GitHub.
• speaking about GitHub – GitHub Actions are also supported as an advanced CI/CD mechanism.
• site blueprints – are especially helpful for multibrand and/or multiregional clients.
• content migration scripts & automation.

Migration from XP/XM

Transferring your existing XP/XM platform to XM Cloud can demand a substantial allocation of resources. In some cases, the expense associated with reconstructing the solution may outweigh the benefits for certain businesses. Fortunately, our XM Cloud JumpStart offers a comprehensive toolkit, including templates, blueprints, migration automation tools, and adjustable pre-developed headless components. This simplifies and expedites the migration process, ultimately reducing the overall cost of transitioning to the cloud solution and making it a more accessible option for brands currently utilizing an on-premises platform.

Components

Headless SXA provided with each and every XM Cloud environment contains only a limited and basic set of components. Based on our previous XM Cloud implementations, we’ve identified that the Components Library is among the top time boosters for development and faster time to market. Therefore we create a components library featuring the most met and desired components for a typical enterprise-level website. Since all the components are Headless SXA-based, there are plenty of styling configuration options for each of them, including rendering variants and parameters. Configuring components on a page consumes significantly less time than implementing homebrewed components from scratch.

XM Cloud JumpStart implementation strategies

Adopting XM Cloud requires careful planning and execution and most importantly, a roadmap. Existing Sitecore customers considering a move to XM Cloud may feel overwhelmed at first.

Your Sitecore solution and business priorities may require different strategies for moving to XM Cloud. Here are a few approaches we’ve seen be successful:

• Site Migration Factory works best for customers running a number of sites on Sitecore, creating a factory approach for migrating sites leads to the most efficiencies
• Incremental & Agile approach suggests moving features incrementally, being responsive to business priorities along the way instead of focusing on a “big bang” release
• Lift & Shift is the most popular strategy, allowing to keep like-for-like functionality and move as efficiently as possible this approach makes the most sense.
• Redesign & Rearchitect is helpful when you want to improve the user experience during the migration. This approach can account for changes to design and content.

Want to learn more?

Reach out to me or my resourceful colleague David San Filippo, if you’d prefer to have a tour of XM Cloud in order to see it in action with your own eyes, as well as familiarize yourself with any of XM Cloud JumpStart capabilities.