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.

TLS certificate lifetimes are being significantly reduced over the next few years as part of an industry-wide push toward greater security and automation. Here’s the phased timeline currently in place:

• Now through March 15, 2026: Maximum lifetime is 398 days

• Starting March 15, 2026: Reduced to 200 days

• Starting March 15, 2027: Further reduced to 100 days

• Starting March 15, 2029: Reduced again to just 47 days

For teams managing Sitecore implementations, this is more than a policy shift—it introduces operational urgency. As certificates begin expiring more frequently, any reliance on manual tracking or last-minute renewals could result in costly downtime or broken integrations.

If your Sitecore environment includes secure endpoints, custom domains, or external integrations, now is the time to assess your certificate strategy and move toward automation.

Why This Matters for Sitecore

Sitecore projects often involve:

• Multiple environments (development, staging, production) with different certificates

• Custom domains or subdomains used for CDNs, APIs, headless apps, or marketing campaigns

• Third-party integrations that require secure connections

• Marketing and personalization features that rely on seamless uptime

A single expired certificate can lead to downtime, loss of customer trust, or failed integrations—any of which could severely impact your digital experience delivery.

Key Risks of Shorter TLS Lifetimes

• Increased risk of missed renewals if teams rely on manual tracking

• Broken environments due to expired certs in Azure, IIS, or Kubernetes configurations

• Delayed deployments when certificates must be re-issued last minute

• SEO and trust damage if browsers start flagging your site as insecure

How to Prepare Your Sitecore Project Teams

To stay ahead of the TLS certificate lifecycle changes, here are concrete steps you should take:

1. Inventory All TLS Certificates

• Audit all environments and domains using certificates

• Include internal services, custom endpoints, and non-production domains

• Use a centralized tracking tool (e.g., Azure Key Vault, HashiCorp Vault, or a certificate management platform)

2. Automate Certificate Renewals

• Wherever possible, switch to automated certificate issuance and renewal

• Use services like:

  • Azure App Service Managed Certificates

  • Let’s Encrypt with automation scripts

  • ACME protocol integrations for Kubernetes

• For Azure-hosted Sitecore instances, leverage Key Vault and App Gateway integrations

3. Establish Certificate Ownership

• Assign clear ownership of certificate management per environment or domain

• Document who is responsible for renewals and updates

• Add certificate health checks to your DevOps dashboards

4. Integrate Certificate Checks into CI/CD Pipelines

• Validate certificate validity before deployments

• Fail builds if certificates are nearing expiration

• Include certificate management tasks as part of environment provisioning

5. Educate Your Team

• Hold knowledge-sharing sessions with developers, infrastructure engineers, and marketers

• Make sure everyone understands the impact of expired certificates on the Sitecore experience

6. Test Expiry Scenarios

• Simulate certificate expiry in non-production environments

• Monitor behavior in Sitecore XP and XM environments, including CD and CM roles

• Validate external systems (e.g., CDNs, integrations, identity providers) against cert failures

Final Thoughts

TLS certificate management is no longer a “set it and forget it” task. With shorter lifetimes becoming the norm, proactive planning is essential to avoid downtime and ensure secure, uninterrupted experiences for your users.

Start by auditing your current certificates and work toward automating renewals. Make certificate monitoring part of your DevOps practice, and ensure your Sitecore teams are aware of the upcoming changes.

Action Items for This Week:

• Identify all TLS certificates in your Sitecore environments

• Document renewal dates and responsible owners

• Begin automating renewals for at least one domain

• Review Azure and Sitecore documentation for certificate integration options

Searching for content on the web has evolved from basic string based matches to a sophisticated array of approaches including keywords, stemming, synonyms, word order, regular expressions, weights and relevance.  Users expect the highest ranking results to be the most relevant and 75% of users don’t go past the first page of results.  All of these advanced techniques are great to find relevant content.  But sometimes you need to find an exact phrase with the specific words in a specific order.  Many search engines do this by wrapping quote marks around the “search term” to indicate an exact match search. Sitecore Search defaults to relevance based searches, but you can achieve exact match search with some configuration.

Understanding Sitecore Search

Let’s take a moment to remember a few concepts in Sitecore Search to understand the configuration better.

• Index Document – A single piece of indexed content such as a webpage, a word document, a pdf, etc.
• Attributes – The fields of an indexed document such as title, subtitle, url, content type, etc.
• Textual Relevance – Defines the attributes used to locate potential results.
• Weight – Defines a relative value for how important an attribute is within the textual relevance.
• Analyzers – Convert the original search query into a format that is optimized for search.
• Token – A chunk of the original search query, usually a single word or phrase that is often modified by the analyzer to include synonyms, remove stop words and reformat to the root word.

Sitecore Search has a number of predefined analyzers built in.  Each analyzer processes the search query in different ways.

The default analyzer is the multi local standard analyzer.  This analyzer modifies the search query by making it lower case, splitting the search query into single word tokens, finding the root of each word, applying synonyms, and removing punctuation.  For this reason, it will not find an exact match.  For that we need the keyword analyzer which leaves the search query in a single token without applying any modifications.

Configure Exact Match Search – Textual Relevance

In order to configure exact match search, we need to add the keyword analyzer to the textual relevance settings for the desired attribute, in this case the description.

Navigate to Admin/Domain Settings then click the feature configuration tab.

Domain Settings

Edit the Textual Relevance section.

Textual Relevance Settings

Add the keyword analyzer to the description attribute.

Add Analyzer

Select the keyword analyzer

Make sure to save your changes then publish your domain settings for your changes to take effect.

Configure Exact Match Search – Widget Settings

Next we need to configure our search widget to use our textual relevance settings.

Navigate to a widget variation and click add rule.

Add rule to a widget Variation

Click the top icon on the left to set the site context.  Add a context rule for Keyword and select the contains option.  In the input box, type a single quote mark.

Add keyword rule to the site context

Click the bottom icon on the left to configure the settings.  Click the tab for Textual Relevance and click the toggle to enable the configuration.  Notice that the description field is listed twice, once for each analyzer. From here you can enable/disable each attribute/analyzer and set its relative weight.  In this example, I’ve set the description-keyword to 3 and the name-multilocal to 1.  This will do the exact match search only on the description attribute.  You could include name-keyword analyzer to do an exact match on the name as well if that is desired.

Description keyword rule

Repeat the process to add or modify a second rule that uses the description-multilocal analyzer.

Description multilocale rule

This rule will be the fallback if the search term does not include a quote.

Rule order and fallback

Exact Match Search in Action

With this configuration in place, you can see the difference in the search results.  In this example, I’ve searched for “proxy statements”.

When you include a quote mark in the search term, you only get results that have the exact phrase “proxy statements”.  This search returns 12 results.

Exact match search with 12 results

When you do not include the quote mark in the search term, you get results that include proxy, statements and statement.  This search returns 68 results.

Relevance search with 68 results

Securing your Sitecore XM Cloud environment is critical to protecting your content, your users, and your brand. This post walks through key areas of XM Cloud security, including user management, authentication, secure coding, and best practices you can implement today to reduce your security risks.

We’ll also take a step back to look at the Sitecore Cloud Portal—the central control panel for managing user access across your Sitecore organization. Understanding both the Cloud Portal and XM Cloud’s internal security tools is essential for building a strong foundation of security.

Sitecore Cloud Portal User Management: Centralized Access Control

The Sitecore Cloud Portal is the gateway to managing user access across all Sitecore DXP tools, including XM Cloud. Proper setup here ensures that only the right people can view or change your environments and content.

Organization Roles

Each user you invite to your Sitecore organization is assigned an Organization Role, which defines their overall access level:

• Organization Owner – Full control over the organization, including user and app management.

• Organization Admin – Can manage users and assign app access, but cannot assign/remove Owners.

• Organization User – Limited access; can only use specific apps they’ve been assigned to.

Tip: Assign the “Owner” role sparingly—only to those who absolutely need full administrative control.

App Roles

Beyond organization roles, users are granted App Roles for specific products like XM Cloud. These roles determine what actions they can take inside each product:

• Admin – Full access to all features of the application.

• User – More limited, often focused on content authoring or reviewing.

Managing Access

From the Admin section of the Cloud Portal, Organization Owners or Admins can:

• Invite new team members and assign roles.

• Grant access to apps like XM Cloud and assign appropriate app-level roles.

• Review and update roles as team responsibilities shift.

• Remove access when team members leave or change roles.

Security Tips:

• Review user access regularly.

• Use the least privilege principle—only grant what’s necessary.

• Enable Multi-Factor Authentication (MFA) and integrate Single Sign-On (SSO) for extra protection.

XM Cloud User Management and Access Rights

Within XM Cloud itself, there’s another layer of user and role management that governs access to content and features.

Key Concepts

• Users: Individual accounts representing people who work in the XM Cloud instance.

• Roles: Collections of users with shared permissions.

• Domains: Logical groupings of users and roles, useful for managing access in larger organizations.

Recommendation: Don’t assign permissions directly to users—assign them to roles instead for easier management.

Access Rights

Permissions can be set at the item level for things like reading, writing, deleting, or publishing. Access rights include:

• Read

• Write

• Create

• Delete

• Administer

Each right can be set to:

• Allow

• Deny

• Inherit

Best Practices

• Follow the Role-Based Access Control (RBAC) model.

• Create custom roles to reflect your team’s structure and responsibilities.

• Audit roles and access regularly to prevent privilege creep.

• Avoid modifying default system users—create new accounts instead.

Authentication and Client Credentials

XM Cloud supports robust authentication mechanisms to control access between services, deployments, and repositories.

Managing Client Credentials

When integrating external services or deploying via CI/CD, you’ll often need to authenticate through client credentials.

• Use the Sitecore Cloud Portal to create and manage client credentials.

• Grant only the necessary scopes (permissions) to each credential.

• Rotate credentials periodically and revoke unused ones.

• Use secure secrets management tools to store client IDs and secrets outside of source code.

For Git and deployment pipelines, connect XM Cloud environments to your repository using secure tokens and limit access to specific environments or branches when possible.

Secure Coding and Data Handling

Security isn’t just about who has access—it’s also about how your code and data behave in production.

Secure Coding Practices

• Sanitize all inputs to prevent injection attacks.

• Avoid exposing sensitive information in logs or error messages.

• Use HTTPS for all external communications.

• Validate data both on the client and server sides.

• Keep dependencies up to date and monitor for vulnerabilities.

Data Privacy and Visitor Personalization

When using visitor data for personalization, be transparent and follow data privacy best practices:

• Explicitly define what data is collected and how it’s used.

• Give visitors control over their data preferences.

• Avoid storing personally identifiable information (PII) unless absolutely necessary.

Where to Go from Here

Securing your XM Cloud environment is an ongoing process that involves team coordination, regular reviews, and constant vigilance. Here’s how to get started:

• Audit your Cloud Portal roles and remove unnecessary access.

• Establish a role-based structure in XM Cloud and limit direct user permissions.

• Implement secure credential management for deployments and integrations.

• Train your developers on secure coding and privacy best practices.

The stronger your security practices, the more confidence you—and your clients—can have in your digital experience platform.

AI transforms how businesses create, maintain, and provide engaging content in Sitecore. Embedding AI, Sitecore allows developers, marketers, and IT professionals to improve workflows, enhance customer interaction, and fine-tune digital strategies. Let’s explore how AI is shaping Sitecore and what it means for businesses.

Key AI Features in Sitecore

From Content Hub to XM Cloud, products in Sitecore’s portfolio have embedded AI that provides speed and scalability to personalization. Noteworthy features include:

• AI-powered content creation: Marketers can utilize AI to write articles, rephrase language, or write content for a certain audience. This minimizes manual effort and allows teams to focus on their strategy projects.
• Personalization at Scale: AI leverages user behavior to provide scaled personalized engagement, like personalized product recommendations, or personalizing dynamic page layouts. This improves customer engagement and conversion rates remain on the rise.
• Smart Search: Based on user intents and behaviors, Sitecore delivers relevant results through AI-enabled smart search capabilities for visitors, so that they can find the information they are looking for in the blink of an eye, enriching their overall experience.
• A/B Testing: Real-time multi-armed bandit machine learning algorithms will continuously optimize the variations of content that an end user sees, showing the most efficient version of a web page or campaign.
• Augmented Analytics: AI improves the analysis of consumer data by detecting trends and patterns that support improved decision-making.

Advantages of Integrating AI with Sitecore

There are several important benefits for organizations with embedded AI in Sitecore:

• Improved Efficiency: Automating repetitive tasks such as content tagging, approval procedures, and translations allows focusing on more valuable activities.
• Enhanced Creativity: New product offerings like Sitecore Stream, brand-aware assistant, give marketers agility to work with brand assets in new ways that align creativity across brand campaigns.
• Predictive Modeling: With advanced machine learning algorithms, patterns are identified in client behaviors, which enable organizations to make data-informed predictions and improve decision-making, leading to better business outcomes.
• Improved Security: AI can identify patterns in data that suggest unexpected behavior, which could mean a security breach or fraudulent activity, enhancing website safety.

Sector-Wise Applications

Sitecore AI deployment is also being used widely across multiple verticals:

• Retail: Tailored product recommendations are based on browsing history, which helps boosting sales, and enhance the user experience.
• Media and Entertainment: Automated video content tagging simplifies media management workflows.
• Global Businesses: Businesses use AI translation programs to adapt content more quickly for a larger audience.

Challenges and Considerations

However, despite the clear benefits, integrating Sitecore with AI is not without its challenges. Organizations are forced to navigate additional challenges such as data security, implementation costs, and making sure the AI outputs maintain their brand identity. Skilled personnel are needed to manage these advanced tools effectively.

Conclusion

Sitecore is evolving into a high-performance, AI-infused platform that powers personalized digital experiences at scale. Sitecore provides businesses with the tools they need to automate tasks, encourage creativity, and derive actions from data analytics, allowing businesses to stay relevant in an ever-changing environment. In a time where upstanding customer relationships are just as important as an online approach, leveraging AI with their Sitecore development strategy can do wonders.

Intro

In this post, we’ll take a look at a couple Sitecore SDKs commonly used to build XM Cloud head applications. Specifically, we’ll be looking at how to disable cookies used by these SDKs. This can be useful for data privacy and/or regulatory compliance reasons. These SDKs allow your application to integrate with other composable Sitecore services like analytics, personalization, and search. The cookies these SDKs use need to be considered as part of your application’s overall data protection strategy.

It’s worth noting that, even without any additional SDKs, an XM Cloud head application can issue cookies; see XM Cloud visitor cookies for more information.

Sitecore Cloud SDK

The Sitecore Cloud SDK allows developers to integrate with Sitecore’s Digital Experience Platform (DXP) products. These include Sitecore CDP, Sitecore Personalize, etc. You can read the official documentation here. To learn more about the first-party cookies used by this SDK, see Cloud SDK cookies. These cookies include:

• sc_{SitecoreEdgeContextId}
  • Stored in the browser when the SDK’s initialization function is called (more on this function later).
• sc_{SitecoreEdgeContextId}_personalize
  • Needed to run A/B/n tests; configured in the addPersonalize() function. Also stored in the browser when the initialization function is called.

Sitecore are actively working on integrating the disparate Sitecore SDKs into the Sitecore Cloud SDK. The latest version, 0.5, was released on January 29, 2025, and added search capabilities (see the XM Cloud changelog entry here). As Sitecore’s Technical Product Manager Christian Hahn put it in this recent Discover Sitecore YouTube video:

“…[the] Cloud SDK is not another Sitecore SDK–it is the Sitecore SDK.”

It’s safe to assume that, eventually, the Sitecore Cloud SDK will be the only Sitecore SDK developers need to include in their head applications to integrate with any other Sitecore DXP offerings (which will be nice ).

For the remainder of this post, assume that a pre-0.5 version of the Cloud SDK is in use, say, 0.3.0—any version that doesn’t include search widgets (such that the Search JS SDK for React is still required).

Sitecore Search JS SDK for React

The Search JS SDK for React allows developers to create components such as search bars, search results components, etc. These components interact with search sources defined and indexed in Sitecore Search. You can read the official documentation here. While the latest version of the Cloud SDK includes some search dependencies, for older Next.js applications using older versions of the Cloud SDK, the Search JS SDK for React can still be used to build search interfaces.

The Search JS SDK for React uses a cookie to track events context called __ec (reference). This SDK is historically based on Sitecore Discover whose cookies are similarly documented here, e.g., __rutma.

For the remainder of this post, assume that version 2.5.5 of the Search JS SDK for React is in use.

The Problem

Let’s say your XM Cloud project leverages JSS for Next.js, including the multisite add-on. This add-on (which is included in the official starter kit by default) allows a single Next.js application to drive multiple headless sites. Next, let’s assume that some of these sites operate outside of the United States and are potentially subject to different data protection and privacy laws. Finally, let’s assume that not all of the sites will use the full feature set from these SDKs. For example, what if a couple of the sites are small and don’t need to integrate with Sitecore Search at all?

How do you disable the cookies written to the browser when the Search SDK’s <WidgetsProvider> component is initialized? Even though the smaller sites aren’t using search widgets on any of their pages, the <WidgetsProvider> component is (usually) included in the Layout.tsx file and is still initialized. We don’t want to remove the component since other sites do use search widgets and require the <WidgetsProvider> component.

Can these SDKs be configured to (conditionally) not create cookies on the client browser?

The Solution

First and foremost (before we get into how to disable cookies used by these SDKs), know that you must ensure that your application is compliant with any and all data privacy and data protection laws to which it is subject. This includes allowing users to opt-out of all browser cookies. Cookie preferences, their management, third-party solutions, GDPR, CCPA, etc. are all great topics but are well outside the scope of this post. To get started, refer to Sitecore’s documentation on data privacy to understand who is responsible for what when building an XM Cloud application.

With that small disclaimer out of the way, the programmatic hooks discussed in the sections below can be used in conjunction with whatever cookie management solution that makes sense for your application. Let’s assume that, for these smaller sites operating in different geographies that require neither CDP nor search, we just want to disable cookies from these SDKs altogether.

To disable Cloud SDK cookies:

The short version: just don’t call the SDK’s init() function . One way this can be done is to add an environment variable and check its value within the .\src\<rendering-host>\src\lib\context\sdk\events.ts file and either return early or throw before the call to Events.init():

import * as Events from '@sitecore-cloudsdk/events/browser';
import { SDK } from '@sitecore-jss/sitecore-jss-nextjs/context';

const sdkModule: SDK<typeof Events> = {
  sdk: Events,
  init: async (props) => {
    // Events module can't be initialized on the server side
    // We also don't want to initialize it in development mode
    if (typeof window === 'undefined')
      throw 'Browser Events SDK is not initialized in server context';
    if (process.env.NODE_ENV === 'development')
      throw 'Browser Events SDK is not initialized in development environment';
    // We don't want to initialize if the application doesn't require it
    if (process.env.DISABLE_CLOUD_SDK === 'true') // <===== HERE
      throw 'Browser Events SDK is not initialized for this site';

    await Events.init({
      siteName: props.siteName,
      sitecoreEdgeUrl: props.sitecoreEdgeUrl,
      sitecoreEdgeContextId: props.sitecoreEdgeContextId,
      // Replace with the top level cookie domain of the website that is being integrated e.g ".example.com" and not "www.example.com"
      cookieDomain: window.location.hostname.replace(/^www\./, ''),
      // Cookie may be created in personalize middleware (server), but if not we should create it here
      enableBrowserCookie: true,
    });
  },
};

export default sdkModule;

By not calling Events.init(), the cookies aren’t written to the browser.

Note that in newer versions of the XM Cloud starter kit using the Cloud SDK, the initialize function may be in the Bootstrap.tsx file; however, the same principle applies—don’t call the initialize() function by either returning early or setting up conditions such that the function is never called.

For consistency, assuming your application uses the OOTB CdpPageView.tsx component, you’d probably want to do something similar within that component. By default, page view events are turned off when in development mode. Simply add another condition to ensure that the return value of disabled() is true:

import {
  CdpHelper,
  LayoutServicePageState,
  useSitecoreContext,
} from '@sitecore-jss/sitecore-jss-nextjs';
import { useEffect } from 'react';
import config from 'temp/config';
import { context } from 'lib/context';

/**
 * This is the CDP page view component.
 * It uses the Sitecore Cloud SDK to enable page view events on the client-side.
 * See Sitecore Cloud SDK documentation for details.
 * https://www.npmjs.com/package/@sitecore-cloudsdk/events
 */
const CdpPageView = (): JSX.Element => {
  ...
  /**
   * Determines if the page view events should be turned off.
   * IMPORTANT: You should implement based on your cookie consent management solution of choice.
   * By default it is disabled in development mode
   */
  const disabled = () => {
    return process.env.NODE_ENV === 'development' || process.env.DISABLE_CLOUD_SDK === 'true'; // <===== HERE
  };
  ...
  return <></>;
};

export default CdpPageView;

To disable Search JS SDK for React (Sitecore Discover) cookies:

The <WidgetsProvider> component (imported from @sitecore-search/react) includes a property named trackConsent (documented here) and it controls exactly that—whether or not tracking cookies related to visitor actions are created. Setting the value of this property to false disables the various cookies. In the Layout.tsx file, assuming we added another environment variable, the code would look something like this:

ata-enlighter-language="typescript">/**
 * This Layout is needed for Starter Kit.
 */
import React from 'react';
...
import { Environment, WidgetsProvider } from '@sitecore-search/react';

const Layout = ({ layoutData, headLinks }: LayoutProps): JSX.Element => {
  ...
  return (
    <>
      ...
        <div className="App">
          <WidgetsProvider
            env={process.env.NEXT_CEC_APP_ENV as Environment}
            customerKey={process.env.NEXT_CEC_CUSTOMER_KEY}
            apiKey={process.env.NEXT_CEC_API_KEY}
            publicSuffix={true}
            trackConsent={!(process.env.DISABLE_TRACK_CONSENT === 'true') /* <===== HERE */}
          >
            ...
          </WidgetsProvider>
        </div>
      ...
    </>
  );
};

export default Layout;

If trackConsent is false, then the various __r… cookies are not written to the browser.

It’s worth mentioning that, by default, trackConsent is true. To opt-out of cookies, developers must set the property to false.

Whether you control the use of cookies by using environment variables as described in this post or by integrating a more complex cookie preference and consent management system, the onus is on you and your XM Cloud head application to avoid using cookies without a user’s consent.

Thanks for the read!

Are you using Vercel to supercharge your Sitecore experience? If so, you’re already benefiting from a powerful, globally optimized platform designed for modern web applications. But did you know you can take your performance even further? Vercel Fluid Compute is a game-changer, optimizing workloads for higher efficiency, lower costs, and enhanced scalability—perfect for high-performance Sitecore deployments.

What is Vercel Fluid Compute?

Fluid Compute is Vercel’s next-generation execution model, blending the best of serverless and traditional compute. Unlike conventional serverless architectures, which often suffer from cold starts and limited concurrency, Fluid Compute allows multiple requests to be processed within a single function instance. This leads to reduced latency, faster response times, and better resource utilization.

Why Sitecore Developers Should Care

Sitecore is a powerful digital experience platform, but ensuring smooth, high-speed performance at scale can be challenging. Fluid Compute helps reduce performance bottlenecks and optimize infrastructure costs, making it a perfect fit for Sitecore-powered applications. Here’s how it benefits you:

• Faster Load Times: By reusing function instances and reducing cold starts, Fluid Compute improves Sitecore’s response times, ensuring users get the content they need—fast.
• Cost Savings: Efficient resource usage can reduce compute costs by up to 85%, a significant reduction for enterprises managing high-traffic Sitecore applications.
• Scalability Without Hassle: Fluid Compute dynamically scales functions based on demand, ensuring seamless performance even during traffic spikes.
• Better Background Processing: Features like waitUntil enable asynchronous tasks such as logging and analytics to run without delaying user responses.

How Fluid Compute Compares

To truly understand the advantages of Fluid Compute for Sitecore, take a look at this comparison chart:

As shown, Fluid Compute outperforms both traditional servers and serverless architectures in key areas such as scaling, concurrency, and cost efficiency. By preventing cold starts, enabling efficient auto-scaling, and optimizing resource usage, Fluid Compute ensures your Sitecore application runs at peak performance with minimal overhead.

How to Enable Fluid Compute for Sitecore on Vercel

One of the best aspects of Fluid Compute is how easy it is to implement.

1. Deploy Your Sitecore-Powered App to Vercel – Ensure your Sitecore front-end is running on Vercel’s platform.
2. Enable Fluid Compute – Simply update your Vercel project settings to opt into Fluid Compute for serverless functions.
3. Enjoy Enhanced Performance – With zero additional configuration, your Sitecore app now benefits from better efficiency, lower costs, and higher scalability.

The Future of Sitecore Performance

As brands continue to push the boundaries of digital experiences, having a highly optimized, scalable compute model is essential. With Vercel Fluid Compute, Sitecore developers can future-proof their applications, ensuring exceptional performance while keeping costs in check.

Intro

While working on a recent project to migrate a Sitecore 9.1 solution to Sitecore XM Cloud, an interesting situation arose with Bootstrap grid parameters. More specifically, with grid rendering parameters configured on renderings migrated from the legacy 9.1 content tree into the XM Cloud content tree.

To start, some (brief?) background on SXA and the grid system. SXA includes several grid systems out-of-the-box (reference), including Bootstrap 4 (BS4) and Bootstrap 5 (BS5). These grid systems allow developers to build responsive layouts in a consistent, predictable way. When adding a new headless site in XM Cloud, BS5 is the default grid system (reference). The supporting Sitecore items for the different grid systems can be found in the content tree under /sitecore/system/Settings/Feature/Experience Accelerator (BS4 and BS5 are highlighted in the screenshot below, but there are others):

The grid system(s) a site uses can be configured on the site’s Settings item, e.g., /sitecore/content/Test Site Collection/Headless Site A/Settings:

When editing a rendering on a page in the Content Editor, Experience Editor, or XM Cloud Pages (which was recently updated ), content authors can configure the grid and set things like column sizes, offsets, order, etc.:

These grid settings are stored as a single rendering parameter named GridParameters associated to the parent rendering in the page’s Renderings and/or Final Renderings field. For example, assuming a Container rendering has the Size settings depicted in the animation above (meaning: Mobile | Size | 12), the raw value of the rendering in presentation details would look something like this:

<r uid="{FE9A8A21-02C7-4EB0-B1B1-DF67ADD29ADD}"
  ...
  s:par="?Styles=%7b6221E315-B00F-4832-9054-B46F347EC247%7d&amp;GridParameters=%7b7465D855-992E-4DC2-9855-A03250DFA74B%7d&amp;DynamicPlaceholderId=1"
  s:ph="headless-main" />

The s:par attribute stores a URL-encoded query string containing the rendering parameters. The value of GridParameters is “%7b7465D855-992E-4DC2-9855-A03250DFA74B%7d”, or, when URL-decoded, “{7465D855-992E-4DC2-9855-A03250DFA74B}”. That looks a lot like a Sitecore item ID, right ?

Note that, if there was more than one grid parameter, GridParameters would be a pipe-delimited (“|”) string of IDs.

The ID points to the grid size definition item located at (in this case, for BS5) /sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 5/Bootstrap 5 Grid Definition/Extra small/Size/12. Finally, as part of the definition of the size item, the applicable Bootstrap CSS class is specified in the Class field. It is this class (or classes, if more than one grid parameter is specified) that is applied to the markup when the component is rendered in the UI.

For a slightly more “real world” example, assume a Container rendering had (BS5) grid settings that looked like this:

The value of the GridParameters rendering parameter would be:

<r uid="{FE9A8A21-02C7-4EB0-B1B1-DF67ADD29ADD}"
  ...
  s:par="GridParameters=%7B7465D855-992E-4DC2-9855-A03250DFA74B%7D%7C%7B597223E6-B7EE-4D86-BC89-F7DA3DE8A7E5%7D%7C%7B7D865A50-F089-421E-ACDC-620DB03BC49D%7D&amp;FieldNames&amp;BackgroundImage&amp;Styles=%7B6221E315-B00F-4832-9054-B46F347EC247%7D&amp;RenderingIdentifier&amp;CSSStyles&amp;DynamicPlaceholderId=1"
  s:ph="headless-main" />

Which, URL-decoded would be: “{7465D855-992E-4DC2-9855-A03250DFA74B}|{597223E6-B7EE-4D86-BC89-F7DA3DE8A7E5}|{7D865A50-F089-421E-ACDC-620DB03BC49D}”.

The JSON pulled from the layout service for the rendering would look like this:

...
"uid": "fe9a8a21-02c7-4eb0-b1b1-df67add29add",
"componentName": "Container",
"dataSource": "",
"params": {
  "GridParameters": "col-12 col-md-10 col-xl-5", // <=== HERE
  "Styles": "container",
  "DynamicPlaceholderId": "1",
  "FieldNames": "Default"
}
...

And, finally, the resulting markup would look like this:

<div class="col-12 col-md-10 col-xl-5">
...
</div>

For the remainder of this post, assume the following:

• The legacy 9.1 solution used BS4.
• The XM Cloud solution used BS5 (but supported BS4).
• The legacy 9.1 renderings were migrated to XM Cloud (and converted to JSON renderings).
• The migrated renderings were implemented and appear as expected in the head application UI, complete with the expected/correct CSS grid classes.

The Problem

Okay, so, what’s the issue? We have BS4 and BS5 available in XM Cloud and the migrated renderings are emitting the correct grid styles in the markup (e.g., col-12). What’s the problem?

The problem came when content authors went to view and/or update the grid style parameters, either in the Content Editor, Experience Editor, or XM Cloud Pages. There wasn’t an error or anything, but nothing appeared in the Grid tab or the Advanced tab when editing the rendering parameters for the rendering, as if the parameters weren’t there….

When viewing raw values of the Renderings and Final Renderings fields on the page, the GridParameters parameter was clearly present–so why wasn’t anything appearing in the editing UI for content authors?

The Cause

As you may have already guessed (and, yes, it seems obvious now), the reason for this was that the item IDs referenced in the grid rendering parameter are different between BS4 and BS5, even for two grid size definition items with the same CSS class. For example, the col-12 item for BS4 (/sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 4/Bootstrap 4 Grid Definition/Extra small/Size/12) didn’t have the same ID as the matching col-12 item in BS5 (/sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 5/Bootstrap 5 Grid Definition/Extra small/Size/12).

Because the new XM Cloud solution had both the supporting BS4 and BS5 items available under /sitecore/system/Settings/Feature/Experience Accelerator, the BS4 grid CSS classes were still coming through in the UI. However, when editing, the rendering parameters modal was expecting the BS5 IDs (since the site was configured to use BS5) to bind the editing controls. Since no BS5 parameter IDs were found, the editing controls in the modal weren’t bound to the correct values and appeared broken for content authors.

The Solution

As usual, Sitecore PowerShell Extensions (SPE) to the rescue. A PowerShell script was written to iterate over page renderings, map the Bootstrap 4 parameter IDs to their equivalent Bootstrap 5 parameter IDs based on a CSS class name match, if possible, and then save the updated rendering parameters back to the page.

In some cases, it wasn’t possible to map parameters between the two grid systems as there are breaking changes between BS4 and BS5. In BS4, for example, some Order definitions exist that do not exist in BS5 i.e., /sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 4/Bootstrap 4 Grid Definition/Extra small/Order/6.

Luckily, in the case of this particular project, the vast majority of the parameters did have a BS5 equivalent and were remapped accordingy, allowing the rendering parameters modal to properly reflect the current grid parameters for content authors.

The Script

Update-GridParameters.ps1

A few highlights on the script and how it works:

1. 1. The script is intended to be executed via the PowerShell ISE interface in Sitecore.
   2. Update the -Path parameter according to where your content pages live in the tree; I’d recommend running the script on a subset of items initially.
   3. The script emits a report using the Show-ListView command that enumerates which renderings and parameters were updated (or that won’t be updated); the report can be exported if you need to, say, attach it to a work item in Azure DevOps or JIRA.
   4. If a grid rendering parameter ID cannot be mapped to a BS5 ID or if the candidate ID isn’t a BS4 ID (including if it’s already a BS5 ID), then it is skipped but still appears in the report.
   5. Keep the -WhatIf switch set until you’re ready to apply the updates.

Here’s the script:

Function Update-GridParameters {
    <#
    .SYNOPSIS
        Maps Bootstrap 4 grid rendering parameters to Bootstrap 5 grid rendering parameters.

    .DESCRIPTION
        This function maps Bootstrap 4 grid rendering parameter IDs to their Bootstrap 5 equivalent rendering parameter IDs, if possible.

    .NOTES
        Nick Sturdivant | Perficient | nick.sturdivant@perficient.com | https://www.linkedin.com/in/nicksturdivant/
    #>

    param
    (
        [Parameter()]
        [String] $Path,

        [Parameter()]
        [Switch] $WhatIf
    )

    BEGIN {
        Write-Host "Beginning $($MyInvocation.MyCommand)"
    }

    PROCESS {
        # get bootstrap 4 grid parameter definitions
        $bs4GridParameters = Get-ChildItem -Path "/sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 4/Bootstrap 4 Grid Definition" -Recurse `
        | Where-Object {
            $_.TemplateID -eq "{CB3B3906-BE80-4D9B-A2A4-038193DA5422}" # /sitecore/templates/Foundation/Experience Accelerator/Grid/Grid Definition Items/Class
        }

        # get bootstrap 5 grid parameter definitions
        $bs5GridParameters = Get-ChildItem -Path "/sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 5/Bootstrap 5 Grid Definition" -Recurse `
        | Where-Object {
            $_.TemplateID -eq "{CB3B3906-BE80-4D9B-A2A4-038193DA5422}" # /sitecore/templates/Foundation/Experience Accelerator/Grid/Grid Definition Items/Class
        }

        # build mapping
        $bs4To5Mappings = @()
        foreach ($bs4GridParameter in $bs4GridParameters) {
            # match bootstrap 5 parameter based on class name
            $bs5GridParameter = $bs5GridParameters | Where-Object { $_.Fields["Class"].Value -eq $bs4GridParameter.Fields["Class"].Value }

            if ($null -ne $bs5GridParameter) {
                $bs4To5Mappings += [PSCustomObject]@{
                    BS4Id    = $bs4GridParameter.ID
                    BS4Class = $bs4GridParameter.Fields["Class"].Value
                    BS5Id    = $bs5GridParameter.ID
                    BS5Class = $bs5GridParameter.Fields["Class"].Value
                }
            }   
        }

        $report = @()

        Write-Host "Processing $Path..." -ForegroundColor Cyan
    
        # get children based on path parameter, filtering to only those items with a rendering defined in their final layout
        $items = Get-ChildItem -Path $Path -Recurse | Where-Object { ($null -ne (Get-Rendering -Item $_ -FinalLayout)) }
    
        foreach ($item in $items) {
            $renderings = Get-Rendering -Item $item -FinalLayout

            if ($null -ne $renderings) {
                foreach ($rendering in $renderings) {
                    # get grid rendering parameter
                    $renderingParameter = Get-RenderingParameter -Rendering $rendering -Name "GridParameters"

                    if ($null -ne $renderingParameter) {
                        Write-Host "Processing grid rendering parameters on item $($item.ID), rendering $($rendering.UniqueId)..." -ForegroundColor Green
                        $gridParametersIdString = $renderingParameter["GridParameters"]

                        if (-not [string]::IsNullOrWhiteSpace($gridParametersIdString)) {
                            $gridParameterIds = $gridParametersIdString.Split("|")
                            $newGridParameterIds = @()

                            foreach ($gridParameterId in $gridParameterIds) {
                                # check if the parameter is bootstrap 4
                                $mappedParameter = $bs4To5Mappings | Where-Object { $_.BS4Id.ToString() -eq $gridParameterId } | Select-Object -First 1

                                if ($null -eq $mappedParameter) {   
                                    $message = "Grid parameter ID $gridParameterId is not a Bootstrap 4 parameter that can be mapped to a Bootstrap 5 parameter, retaining original ID."
    
                                    Write-Host $message -ForegroundColor Yellow
    
                                    $report += @{
                                        ItemId                 = $item.ID
                                        ItemPath               = $item.FullPath
                                        RenderingItemId        = $rendering.ItemID
                                        RenderingUniqueId      = $rendering.UniqueId
                                        CurrentGridParameterId = $gridParameterId
                                        MappedGridParameterId  = "N/A"
                                        GridClassName          = "N/A"
                                        Notes                  = $message
                                    }

                                    $newGridParameterIds += $gridParameterId

                                    # process next parameter
                                    continue
                                }
    
                                # map to bootstrap 5 parameter
                                $report += @{
    
                                    ItemId                 = $item.ID
    
                                    ItemPath               = $item.FullPath
    
                                    RenderingItemId        = $rendering.ItemID
    
                                    RenderingUniqueId      = $rendering.UniqueId
    
                                    CurrentGridParameterId = $gridParameterId
    
                                    MappedGridParameterId  = $mappedParameter.BS5Id.ToString()
    
                                    GridClassName          = $mappedParameter.BS5Class
    
                                    Notes                  = "Mapping Bootstrap 4 grid parameter ID $gridParameterId to Bootstrap 5 grid parameter ID $($mappedParameter.BS5Id.ToString())."
    
                                }
    
                                $newGridParameterIds += $mappedParameter.BS5Id.ToString()   
                            }
    
                            $newGridParametersIdString = $newGridParameterIds -join "|"
    
                            Write-Host "Current: $gridParametersIdString"
    
                            Write-Host "Mapped: $newGridParametersIdString"
    
                            if ($gridParametersIdString -eq $newGridParametersIdString) {   
                                Write-Host "Current and mapped grid parameters match, skipping update..." -ForegroundColor Yellow
                                
                                # process next rendering
                                continue
                            }
    
                            # set new rendering parameter   
                            $setMessage = "Setting new grid parameters on item $($item.ID) ($($item.FullPath)), rendering $($rendering.UniqueId)..."
    
                            Write-Host $setMessage -ForegroundColor Yellow
    
                            $newGridParameters = [Ordered]@{"GridParameters" = $newGridParametersIdString }
    
                            $report += @{
                                ItemId                 = $item.ID
                                ItemPath               = $item.FullPath
                                RenderingItemId        = $rendering.ItemID
                                RenderingUniqueId      = $rendering.UniqueId
                                CurrentGridParameterId = $gridParametersIdString
                                MappedGridParameterId  = $newGridParametersIdString
                                GridClassName          = ""
                                Notes                  = "$setMessage ($gridParametersIdString ==> $newGridParametersIdString)"
                            }

                            if (-not $WhatIf) {
                                # update new grid parameters and then update the rendering
                                $rendering | Set-RenderingParameter -Parameter $newGridParameters | Set-Rendering -Item $item -FinalLayout
                            }
                        }
                    }
                }
            }
        }
    
        # display report
        $report |
        Show-ListView -Property @{ Label = "Item ID"; Expression = { $_.ItemId } },
        @{Label = "Item Path"; Expression = { $_.ItemPath } },
        @{Label = "Rendering Item ID"; Expression = { $_.RenderingItemId } },
        @{Label = "Rendering Unique ID"; Expression = { $_.RenderingUniqueId } },
        @{Label = "Current Grid Parameter ID"; Expression = { $_.CurrentGridParameterId } },
        @{Label = "Mapped Grid Parameter ID"; Expression = { $_.MappedGridParameterId } },
        @{Label = "Grid Class Name"; Expression = { $_.GridClassName } },
        @{Label = "Notes"; Expression = { $_.Notes } }
    }

    END {
        Write-Host "Ending $($MyInvocation.MyCommand)"
    }
}

# 1. Change the Path parameter as necessary, depending on where the content pages are in the tree.
# 2. Use the -WhatIf switch to preview the changes; remove the switch to update the renderings and pages.
Update-GridParameters -Path "/sitecore/content/Test Site Collection/Headless Site A" -WhatIf

Bonus Script

My colleague (and Sitecore MVP) Eric Sanner happened to write a similar script recently. I can neither confirm nor deny that the two of us wrote two scripts to do the same thing at around the same time . His script can be found below and illustrates another approach to solve the same problem. Thanks for sharing, Eric!

BS4toBS5.ps1

<#
    .SYNOPSIS
       Update Final Layouts
        
    .DESCRIPTION
        Find bootstrap4 grid settings in final layout and convert to bootstrap5
        
    .NOTES  
        Eric Sanner | Perficient | eric.sanner@perficient.com | https://www.linkedin.com/in/ericsanner/      
#>

#BEGIN Config
$database = "master"
$allowDelete = $false
#END Config

#BEGIN Helper Functions

function Write-LogExtended {
    param(
        [string]$Message,
        [System.ConsoleColor]$ForegroundColor = $host.UI.RawUI.ForegroundColor,
        [System.ConsoleColor]$BackgroundColor = $host.UI.RawUI.BackgroundColor
    )

    Write-Log -Object $message
    Write-Host -Object $message -ForegroundColor $ForegroundColor -BackgroundColor $backgroundColor
}

function Strip-Html {
    #https://www.regular-expressions.info/lookaround.html#lookahead Replaces multiple spaces with a single space
    param (
        [string]$text
    )
    
    $text = $text -replace '<[^>]+>',' '
    $text = $text -replace " (?= )", "$1"
    $text = $text.Trim()
    
    return $text
}

function Truncate-Output {
    param (
        $obj,
        $maxLeng
    )
    
    $ret = "";
    
    if($obj -ne $null)
    {
        $str = $obj.ToString().Trim()
        $leng = [System.Math]::Min($str.Length, $maxLeng)
        $truncated = ($str.Length -gt $maxLeng)
        
        $ret = $str.Substring(0, $leng)
        if($truncated -eq $true)
        {
            $ret = $ret + "..."
        }
    }

    return $ret
}

#END Helper Functions

#BEGIN Sitecore Functions

function Get-SitecoreItemById {
    param(
        [string]$id
    )

    return Get-Item -Path $database -ID $id -ErrorAction SilentlyContinue
}

function Update-SitecoreItem {
    param(
        [Sitecore.Data.Items.Item]$item,
        [System.Collections.Hashtable]$updates
    )
    
    if($item -eq $null)
    {
        Write-LogExtended "[E] Error updating item $($item) - Item is null" Red
        return
    }
    
    if($updates -eq $null)
    {
        Write-LogExtended "[E] Error updating item $($item) - Update hashtable is null" Red
        return
    }
        
    $changeDetected = $false
    $foregroundColor = "Green"
    
    Write-LogExtended "[I] Updating Item $($item.ID) - $($item.Name)"
    $item.Editing.BeginEdit()
    
    foreach($key in $updates.GetEnumerator())
    {
        if($item.($key.Name) -ne $null)
        {
            $output = "Field Name '$($key.Name)' Current Value: '$(Truncate-Output $item.($key.Name) 40)' New Value: '$(Truncate-Output $key.Value 40)'"            
            
            if($item.($key.Name) -ne $key.Value)
            {
                Write-LogExtended "[U] $($output)"
                $item.($key.Name) = $key.Value
                $changeDetected = $true
            }
            else
            {
                Write-LogExtended "[-] $($output)"
            }
        }
    }
    
    $itemModified = $item.Editing.EndEdit()
    
    if($changeDetected -ne $itemModified)
    {
        $foregroundColor = "Red"
    }
    
    Write-LogExtended "[I] Change Detected: $($changeDetected) Item modified $($itemModified)" $foregroundColor
}
#END Sitecore Functions

#BEGIN Conversion Functions

function ProcessItem {
    param(
        [Sitecore.Data.Items.Item]$item     
    )
    
    Write-LogExtended "[I] Processing item $($item.ID): $($item.ItemPath)"

    $gridPattern = "GridParameters=%7B(\w{8}-\w{4}-\w{4}-\w{4}-\w{12})%7D"
    $bs4Pattern = "Bootstrap 4"
    $finalRenderings = $item["__Final Renderings"]
    $finalRenderingsNew = $item["__Final Renderings"]
    $gridRenderings = @{}

    $gridMatches = Select-String -InputObject $finalRenderings -Pattern $gridPattern -AllMatches    
    foreach($gridMatch in $gridMatches.Matches)
    {       
        if(!$gridRenderings.ContainsKey("$($gridMatch.Groups[1].Value)"))
        {
            $gridRenderingItem = Get-SitecoreItemById $gridMatch.Groups[1].Value
            $gridRenderings["$($gridMatch.Groups[1].Value)"] = $gridRenderingItem.ItemPath          
        }
    }

    foreach($rendering in $gridRenderings.GetEnumerator())
    {
        $bs4Matches = Select-String -InputObject $rendering.Value -Pattern $bs4Pattern
        if($bs4Matches)
        {
            Write-LogExtended "[I] Found BS4 GridParams $($rendering.Value)" -ForegroundColor "Red"
            $bs4Items.Add($item.ID, $item.Path)

            if($bs4ToBs5Mapping.ContainsKey($rendering.Name))
            {
                Write-LogExtended "[I] Mapping $($rendering.Name) to $($bs4ToBs5Mapping[$rendering.Name])"  -ForegroundColor "Green"
                
                $finalRenderingsNew = $finalRenderingsNew -replace $rendering.Name, $bs4ToBs5Mapping[$rendering.Name]
            }
            else
            {
                Write-LogExtended "[E] No Mapping Found for $($rendering.Name)"  -ForegroundColor "Red"
            }
        }
    }   

    if($update -and $finalRenderings -ne $finalRenderingsNew)
    {
        $updates = @{}  
        $updates.Add("__Final Renderings", $finalRenderingsNew)

        Update-SitecoreItem $item $updates
    }
}

#END Conversion Functions

#BEGIN Main

    $update = $true
    $bs4Items = @{}

    $bs4ToBs5Mapping = @{}
    #/sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 4/Bootstrap 4 Grid Definition/Extra small/Size/12 -> /sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 5/Bootstrap 5 Grid Definition/Extra small/Size/12
    $bs4ToBs5Mapping.Add("908E2BC6-C110-4ED7-AF39-7EEACBB31A34", "7465D855-992E-4DC2-9855-A03250DFA74B") 
    #/sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 4/Bootstrap 4 Grid Definition/Extra small/Size/8 -> /sitecore/system/Settings/Feature/Experience Accelerator/Bootstrap 5/Bootstrap 5 Grid Definition/Extra small/Size/8
    $bs4ToBs5Mapping.Add("D65D90FB-45BF-4A04-A1EA-6F348E7CCBEA", "F2A11D85-8B09-40AC-B5D8-A9E1025F899D")    

    $parentPath = "master:/sitecore/content/<tenantName>/<siteName>/Home"
    $childItems = Get-ChildItem -Path $parentPath -Recurse

    $childItems | ForEach-Object {
        ProcessItem $_
    }

    Write-LogExtended "[I] Found $($bs4Items.Count) Items that reference BS4"
    
#END Main

Thanks for the read!

Optimizing Sitecore Search: Enhancing User Experience and Content Indexing

Sitecore Search is a powerful tool that helps users quickly find relevant content by indexing various sources and presenting results in an intuitive, customizable way. To get the most out of it, businesses must optimize how search widgets function, manage crawlers to keep content fresh, and enhance query handling through automated tools. Let’s dive into these essential components to understand how they work together.

Enhancing Search Interactions with Widgets

Search widgets shape how users interact with search results. These elements power features such as autocomplete, filtering, sorting, and ranking adjustments, making searches more intuitive and personalized. Businesses can configure widgets to offer spell-check, AI-driven recommendations, and customized ranking rules, ensuring that users find what they need with minimal effort. A well-optimized search widget improves relevance and usability, allowing users to refine results based on parameters like relevance, date, or popularity.

The Search API Explorer is another valuable tool that allows businesses to test and refine search queries before deploying them. It acts as a testing ground for adjusting ranking logic, playing with filters, and debugging settings in real time. By viewing API responses in JSON format, developers can fine-tune search behavior to better align with user expectations and business goals.

Keeping Content Up to Date with Crawlers and Extractors

For search results to remain accurate, Sitecore Search relies on crawlers to fetch and index content from different sources. These crawlers can be scheduled to update content in real time, at set intervals, or manually. Businesses have control over crawl frequency, depth, and which URLs should be included or excluded. Additionally, authentication settings ensure that restricted content can be indexed when necessary.

There are different types of crawlers depending on where content resides:

• Web Crawlers scan publicly accessible sites.
• API Crawlers extract structured data via APIs.
• RSS Crawlers gather content from RSS feeds.
• Database Crawlers index content from databases.
• Cloud Storage Crawlers fetch files from cloud platforms like AWS S3 or Azure Blob.

A crucial part of making all content searchable is the Document Extractor, which enables search engines to read and index PDFs and Word documents. Since these file types often contain valuable information that would otherwise be hidden from search results, the extractor converts document content into searchable text and extracts metadata such as titles, authors, and dates. This makes it easier for users to find relevant information even when it exists within non-web-based files.

Automating and Refining Search Behavior

Automation plays a key role in delivering personalized and relevant search results. Search request triggers dynamically modify search behavior based on user actions, ensuring that results align with their needs. For instance, businesses can set up triggers to automatically apply filters based on past searches, boost specific results for certain keywords, or redirect users to relevant pages when they search for particular terms.

Similarly, search request extractors enhance the quality of search results by interpreting user intent, applying synonyms, and refining queries. These tools help improve accuracy by understanding variations in phrasing and context, ensuring that users receive the most relevant results even if their initial search terms aren’t perfectly aligned.

Final Thoughts

Sitecore Search is more than just a search tool—it’s a dynamic system that can be tailored to enhance user experience and ensure content is indexed efficiently. By optimizing search widgets, managing crawlers effectively, and leveraging automation, businesses can significantly improve search accuracy and usability.

If you need help configuring Sitecore Search or have questions about optimizing your setup, drop a comment or reach out—we’d love to chat!

Personalization has always been one of the most sought-after features for brands, allowing them to deliver tailored digital experiences. Sitecore’s CMS products XP and XM have built-in personalization capabilities, ensuring that the right content reaches the right contacts, for example, by showing, hiding, or adjusting content.

In recent years, the shift towards headless solutions has gained significant momentum, enabling greater flexibility, omnichannel delivery, and seamless integrations with modern digital ecosystems – making Sitecore XM Cloud the next choice or most obvious step in a brand’s digital transformation. However, with the shift from Sitecore XP to Sitecore XM Cloud, customers will notice a significant change in how personalization works behind the scenes. While XM Cloud provides a cloud-first, headless, and scalable solution, it does come with certain limitations in personalization compared to XP. This blog will explore how personalization in Sitecore XM Cloud differs from XP, its strengths, and how marketers and developers can still leverage its capabilities effectively.

Personalization in Sitecore XM Cloud

Personalization in XM Cloud, also known as Embedded Personalization in XM Cloud pages, offers a predefined set of built-in, page-based personalization features. Users can easily define audience segments and serve them customized page variations. The embedded personalization capabilities include real-time data stream collection, predefined conditions, and comprehensive site and page analytics.

The Differences

For those migrating from Sitecore XP, the most significant change is the absence of a provision to create custom conditions for rule-based personalization. Sitecore XP provided extensive flexibility, allowing users to define custom conditions and personalize based on deep visitor analytics. However, in XM Cloud, personalization is streamlined and focused on a more structured OOTB (Out-of-the-Box) approach.

Here’s what changes:

• No Custom Conditions: XM Cloud does not support creating custom personalization rules, unlike XP.
• Page Builder Integration: Personalization is managed within the Personalize tab inside the Page Builder.
• Page Variants Instead of Component-Level Personalization: XM Cloud primarily offers page-level personalization, meaning different page variants can be displayed based on predefined conditions.
• Simplified OOTB Conditions: The personalization engine in XM Cloud allows authors to define conditions using a pre-defined set of rules but with limited extensibility.

Elements of Personalization in Sitecore XM Cloud

The personalization model in XM Cloud is straightforward and designed for ease of use. Here’s how it functions:

• Using the Personalize Tab: Within the Page Builder, authors can access the Personalize tab to define different user experiences.
• Page Variants: Instead of component-level changes, XM Cloud enables authors to create and manage different page versions to be served based on specific conditions
• Defining Conditions: While the conditions are OOTB and non-extensible, they still allow for basic personalization, such as user location, visit, point of sale, device type, etc.
• Analyze and Optimize: The Analyze section helps track performance, providing insights into which variants perform better.

Personalization in Sitecore XM Cloud takes a different approach than XP. Despite its limitations, personalization in XM Cloud still offers benefits: it favors simplicity and scalability over deep customization. While some brands may feel the impact of losing advanced personalization rules, the benefits of speed, cloud-native architecture, and ease of use make XM Cloud an attractive option. Combining XM Cloud with Sitecore Personalize can be a game-changer for those needing deeper personalization.

In the next few blogs, we’ll explore the details of embedded personalization and how Sitecore Personalize can enhance personalization in XM Cloud.

The digital experience landscape is evolving rapidly, and businesses face growing pressure to deliver personalized, scalable, and seamless customer experiences while minimizing complexity. Traditional on-prem and PaaS-based CMS solutions often come with heavy infrastructure demands, maintenance, and upgrade cycles.

Sitecore XM Cloud addresses these areas with a fully cloud-native, SaaS-based approach, eliminating the need to manage infrastructure, accelerating deployments, and providing a scalable foundation for digital transformation. But beyond the technical shift, what does this mean for your digital roadmap? How can enterprises leverage this approach to future-proof their content strategy?

Why Enterprises Are Moving to XM Cloud

Sitecore XM Cloud represents more than just another update—it’s a fundamental shift in how digital experiences are built, delivered, and maintained. Here’s why organizations are making the move:

• Always Up to Date: No more version upgrades or downtime—new features and security updates are automatically applied.
• Faster Deployments & Time-to-Market: Continuous delivery enables teams to launch updates and new content faster than ever.
• Scalability Without Complexity: Auto-scaling and cloud-native architecture ensure smooth performance, even during high-traffic periods.
• Cost Efficiency & Operational Agility: By moving away from infrastructure-heavy deployments, businesses can reduce IT overhead and focus on innovation.
• Seamless Integrations with a Composable DXP: Built to work with Sitecore’s ecosystem and third-party tools, enabling more flexibility.

Organizations that require global scalability, frequent content updates, and reduced reliance on IT teams stand to gain the most from XM Cloud’s SaaS-based efficiency.

Key Considerations

Transitioning to XM Cloud requires careful planning to maximize benefits while minimizing disruptions. Here’s what enterprises should consider:

• Content & Data Migration: Assess existing content structures and ensure seamless migration to the cloud.
• Integration with Current Systems: Evaluate how XM Cloud will interact with CRM, eCommerce, and analytics platforms.
• Personalization & AI Capabilities: Take advantage of Sitecore’s advanced features to enhance customer experiences.
• Phased Migration Strategy: Start with non-critical components before a full transition to reduce risks and ensure adoption.

Next-Level Capabilities

Beyond just a shift to SaaS, Sitecore XM Cloud introduces advanced features designed to enhance business operations:

• AI-Powered Personalization – Deliver tailored content based on real-time user data to improve engagement.
• Built-In Performance Analytics – Gain deeper insights into customer behavior and optimize content strategies accordingly.
• Composable & API-First Architecture – Easily integrate with new tools and expand capabilities as business needs evolve.

These enhancements allow businesses to be more responsive, data-driven, and customer-focused without the complexity of traditional platforms.

Sitecore XM Cloud isn’t just an upgrade—it’s a fundamental shift in digital experience management. By adopting a cloud-native, SaaS-first approach, businesses can move faster, scale effortlessly, and eliminate infrastructure complexity. This enables teams to focus on delivering exceptional customer experiences with greater agility.

For organizations looking to modernize their CMS strategy, XM Cloud offers the flexibility, efficiency, and innovation needed to stay ahead. However, every business has unique requirements, and a thoughtful evaluation of long-term goals is essential to determine if it’s the right fit.

In one of the recent projects I worked on, there was a major challenge in integrating multiple digital systems effectively. The client had a complex technology stack comprising a CMS, an e-commerce platform, a search engine, and a personalization system, all of which needed to work together seamlessly. However, we ran into several roadblocks that made this integration far from straightforward:

• Legacy Infrastructure – The client’s existing monolithic systems were outdated and rigid, making it extremely difficult to introduce new integrations or modifications.
• Data Silos – Information was trapped in separate systems with no efficient way to sync data across platforms, leading to inconsistent customer experiences and operational inefficiencies.
• High Development Costs – Custom integrations required significant effort, as each system had its own APIs, data formats, and integration requirements, affecting both the time and cost of development.
• Scalability Issues – Without a unified architecture, expanding the solution across different channels and touchpoints became increasingly challenging as business needs grew.

Example Problem Scenario: E-Commerce (Product information management Integration)

Imagine a company that stores its product data in a Product Information Management (PIM) system but also wants to showcase featured products dynamically on its website’s homepage. Without proper integration, marketers would have to manually update product listings, leading to inconsistencies and delays in showcasing the latest promotions or inventory updates.

Many organizations struggle same kind if issues to bridge the gap between their current tech stack and modern, cloud-native solutions. This is where Sitecore Connect comes in.

Sitecore’s Composable Offerings

Sitecore has transitioned into a composable digital experience platform (DXP), providing best-in-class products such as:

• Sitecore XM Cloud – Headless CMS for dynamic content management.
• Sitecore OrderCloud – Cloud-native e-commerce solution.
• Sitecore Discover – AI-powered search and personalized recommendations.
• Sitecore CDP & Personalize – Customer data platform for real-time segmentation and targeting.

To ensure seamless integration between these products and external platforms, Sitecore Connect acts as the integration hub.

What is Sitecore Connect?

Sitecore Connect is a low-code/no-code integration platform designed to connect Sitecore products with third-party applications, services, and legacy systems. It enables businesses to:

• Automate Workflows – Synchronize data between Sitecore and external systems without manual intervention.
• Reduce Integration Complexity – Utilize pre-built connectors and workflows to eliminate custom development effort.
• Ensure Data Consistency – Maintain a unified experience across content, commerce, and marketing platforms.
• Scale Efficiently – Adapt quickly to new technologies and business needs.

When to Choose Sitecore Connect?

Organizations should consider Sitecore Connect when they:

Need to integrate Sitecore products (XM Cloud, OrderCloud, Discover, CDP) with existing systems.

Want to connect legacy system or CMS platforms with modern Sitecore solutions.

Require seamless data synchronization between Sitecore and third-party tools (ex: Salesforce, SAP, Shopify, etc.).

Aim to reduce integration costs and implementation time using low-code/no-code solutions.

Seek to future-proof their digital architecture with a scalable, composable ecosystem.

Key Advantages of Sitecore Connect

Faster Time-to-Market – Reduces development time with pre-built connectors.

Seamless Interoperability – Ensures smooth communication between different systems.  Better Data Management – Eliminates data silos for a unified customer experience.

Business Agility – Enables organizations to pivot quickly to new digital strategies.

Cost Efficiency – Minimizes the need for extensive custom development.

Basic Keywords in Sitecore Connect & Their Descriptions

• Connector – A pre-built integration component that facilitates data exchange between different systems.
• Workflow – A set of automated actions that execute integration processes between systems.
• Trigger – An event-based mechanism that initiates a workflow when certain conditions are met.
• Action – A predefined operation that modifies, transfers, or updates data across connected platforms.
• Mapping – The process of aligning data fields between different systems to ensure proper synchronization.
• API Integration – The use of REST or GraphQL APIs to enable seamless data exchange between applications.
• Event-Based Processing – A method where integration workflows are executed based on real-time events rather than scheduled intervals.

Some Real-Time Implementation Examples

Example 1: Healthcare Website Integration

A healthcare provider has an Electronic Health Record (EHR) system to manage patient data but wants to offer an online appointment booking system while also providing personalized health content based on patient history.

With Sitecore Connect, they can:

1. Integrate the EHR system with Sitecore XM Cloud to pull in relevant patient details securely.
2. Sync patient appointment data with a scheduling system and display available time slots dynamically.
3. Use Sitecore Personalize and CDP to tailor content, such as recommending relevant health articles based on a patient’s medical history.
4. Ensure compliance with data security standards while maintaining seamless integration between systems.

By leveraging Sitecore Connect, the healthcare provider can offer a more personalized, automated, and efficient patient experience while reducing manual data handling.

Example 2: Integration with E-Commerce system

Returning to our PIM system example, Sitecore Connect can be configured to:

1. Automatically sync product data from the PIM system to Sitecore XM Cloud.
2. Trigger real-time updates when new products are marked as “featured” or “promoted.”
3. Ensure accurate and dynamic content updates on the homepage, removing the need for manual updates.
4. Integrate with Sitecore Discover if present to provide AI-driven personalized recommendations based on PIM data.

By using Sitecore Connect, the company can ensure that its PIM system, content management, and personalization efforts work in harmony without the need for complex custom development.

Conclusion

For organizations looking to modernize their digital experiences integrating all existing systems to share interrelated data, Sitecore Connect is the ideal solution. By enabling seamless integration between Sitecore’s composable products and external platforms, businesses can create scalable, future-proof digital experiences.