Skip to main content

SitecoreAI Personalization Preview Shows the Default Page Instead of the Selected Variant

When working with personalization in SitecoreAI, you expect the preview to reflect the experience you have selected. But what happens when you select a personalized variant in Pages, click Preview, and still see the default version of the page?

We encountered this behavior while working with personalized versions of a home page in SitecoreAI. Here is what we investigated, what we discovered about the Content SDK, and a possible workaround for projects that are not yet ready to upgrade.

The Problem

We had created multiple personalized versions of our home page to deliver different experiences to different audiences.

For example, one of the variants was intended for Wholesalers. While working in the Personalize section of Sitecore Pages, we could select this variant. However, clicking the Preview icon in the top-right corner did not display the selected personalized experience.

Instead, the preview consistently showed the default version of the page, regardless of which variant we selected.

This made it difficult for content authors to verify the appearance of personalized experiences in preview mode.

The expected behavior was straightforward: when a particular personalization variant is selected, the preview should display that variant rather than the default page.

Our Investigation

We started by looking at how the page behaved inside the Pages editor.

The first thing to establish was whether the personalization itself was working or whether the problem was specific to the preview experience.

When we reviewed the personalized variants in the Pages editor, they were available for rendering, and the selected variant could be applied in edit mode. The unexpected behavior occurred when we switched to Preview.

This distinction was important. If the variant was available in the editor but the preview continued to display the default page, the issue was not necessarily with the personalization rules or content configuration. It could instead be related to how the selected variant was communicated to the preview rendering request.

We then investigated the relationship between our Content SDK version and the preview functionality. This led us to a key finding: the ability to preview a specifically selected personalization variant depends on the Content SDK version and how the Preview API request is constructed.

We raised the issue with Sitecore Support to validate our findings and understand the supported options for our current SDK version.

What Sitecore Support Confirmed

Sitecore Support confirmed that previewing a selected personalized variant directly in Preview mode is supported natively from Content SDK 2.2.0 onwards. This capability is not available out of the box in Content SDK 1.x versions.

Support also confirmed the technical detail that helped explain the behavior: the Preview API can render the requested variant when the sc_variant header is included in the GraphQL Preview request.

This gave us two possible approaches: use the Pages editor to review variants in the meantime, or customize the preview request in our application.

Understanding the Technical Solution

In a typical Sitecore Content SDK Next.js application, the page route is commonly located at:

src/pages/[[...path]].tsx

The preview flow uses the Content SDK to retrieve preview data. In SDK versions where selected-variant preview is not supported natively, the preview request needs additional information to identify which variant should be rendered.

The relevant API is:

client.getPreview(previewData, fetchOptions)

The second argument, fetchOptions, allows custom options, including HTTP headers, to be passed with the Preview GraphQL request.

The proposed workaround is to pass the selected variant ID through the sc_variant header.

Conceptually, the implementation involves three steps:

  1. Read the selected variant ID from previewData.variantIds.
  2. When handling the Preview request, pass the selected variant ID as the sc_variant header.
  3. If no variant is selected, use default.

A simplified illustration of the intended request configuration would look like this:

const fetchOptions = {
  headers: {
    sc_variant: selectedVariantId || 'default',
  },
};

Here, selectedVariantId represents the variant ID extracted from the actual preview data. This example illustrates the header configuration; it is not a complete, drop-in implementation. The exact integration depends on how the existing page route handles preview mode and calls getPreview.

The key point is that selecting a variant in the Pages interface is not, by itself, enough for an older SDK preview request to render that variant. The request must carry the selected variant information.

This customization should be implemented and tested against the actual SDK API and preview flow in your application before being used in production.

An Alternative While Waiting for an Upgrade

If upgrading the SDK is not immediately possible, content authors can continue reviewing personalized variants in the Pages editor.

In edit mode, the personalized variants are returned to the application, and the selected variant is applied there. This provides a practical way to review the personalized experience without relying on the affected Preview flow.

The custom sc_variant header approach is another option for teams that need the selected variant to render in Preview mode before upgrading.

However, this is a custom implementation rather than native support in the older SDK. It needs thorough testing, particularly to verify that selecting a different variant changes the preview correctly and that the default experience continues to work when no variant is selected.

The Long-Term Fix

For projects using Content SDK 1.x, upgrading is the cleaner long-term solution.

Sitecore Support recommended planning an upgrade to the latest Content SDK 2.4.x release available for the project. The native behavior introduced in version 2.2.0 removes the need to maintain a custom workaround for this particular limitation, while later versions include further improvements to personalization handling.

As with any SDK upgrade, compatibility with the existing application and dependencies should be evaluated before proceeding.

Conclusion

This investigation was a useful reminder that a personalization issue in SitecoreAI does not always originate in the personalization configuration itself.

In our case, the behavior pointed towards the preview rendering flow and the capabilities of the Content SDK version in use. Reviewing the page in edit mode helped narrow down the problem, and Sitecore Support confirmed the version-specific limitation and the role of the sc_variant header in the Preview API request.

If you encounter the same issue, I would recommend checking your Content SDK version first, verifying the behavior in edit mode, and then deciding between a tested request customization and an SDK upgrade.

Sometimes the key to solving a Sitecore issue is not changing the content or personalization rules, but understanding what information is actually being passed to the rendering application.

Hope this helps you!!

Labels:

Comments

Post a Comment

POPULAR POSTS

Sitecore PowerShell Script to create all language versions for an item from en version

  We have lots of media items and our business wants to copy the data from en version of media item to all other language versions defined in System/Languages. This ensures that media is available in all the languages. So, we created the below powershell script to achieve the same -  #Get all language versions defined in System/Languages $languages = Get-ChildItem /sitecore/System/Languages -recurse | Select $_.name | Where-Object {$_.name -ne "en"} | Select Name #Ensuring correct items are updated by comparing the template ID  $items = Get-ChildItem -Path "/sitecore/media library/MyProjects" -Recurse | Where-Object {'<media item template id>' -contains $_.TemplateID} #Bulk update context to improve performance New-UsingBlock (New-Object Sitecore.Data.BulkUpdateContext) { foreach($item in $items){    foreach($language in $languages){ $languageVersion = Get-Item -Path $item.Paths.Path -Language $language.Name #Check if language versi...
Post a Comment
Read more

Export Sitecore media library files to zip using SPE

If you ever require to export Sitecore media files to zip (may be to optimize them), SPE (Sitecore Powershell Extension) has probably the easiest way to do this for you. It's as easy as the below 3 steps -  1. Right click on your folder (icons folder in snap)>Click on Scripts> Click on Download 2. SPE will start zipping all the media files placed within this folder. 3. Once zipping is done, you will see the Download option in the next screen. Click Download Zip containing the media files within is available on your local machine. You can play around with the images now. Hope this helps!! Like and Share ;)
Post a Comment
Read more

Make Sitecore instance faster using Roslyn Compiler

When we install the Sitecore instance on local, the first load is slow. After each code deploy also, it takes a while for the Sitecore instance to load and experience editor to come up. For us, the load time for Sitecore instance on local machines was around 4 minutes. We started looking for ways to minimize it and found that if we update our Web.config to use Roslyn compiler and include the relevant Nugets into the project, our load times will improve. We followed the simple steps - Go to the Project you wish to add the NuGet package and right click the project and click 'Manage NuGet Packages'. Make sure your 'Package Source' is set to nuget.org and go to the 'Browse' Tab and search Microsoft.CodeDom.Providers.DotNetCompilerPlatform. Install whichever version you desire, make sure you note which version you installed. You can learn more about it  here . After installation, deploy your project, make sure the Microsoft.CodeDom.Providers.DotNetCompilerPlatform.d...
1 comment
Read more

Experience of a first time Sitecore MVP

The Journey I have been working in Sitecore for almost 10 years now. When I was a beginner in Sitecore, I was highly impressed by the incredible community support. In fact, my initial Sitecore learning path was entirely based on community written blogs on Sitecore. During a discussion with my then technology lead Neeraj Gulia , he proposed the idea that I should start giving back to developer community whenever I get chance. Just like I have been helped by many developers via online blogs, stackoverflow etc., I should also try to help others. Fast forward a few years and I met  Nehemiah Jeyakumar  (now an MVP). He had a big archive of his technical notes in the form Sitecore blogs. I realized my first blog dont have to be perfect and it can be as simple as notes to a specific problem for reference in future. That's when I probably created my first blog post on Sitecore. At that time, I didn't knew about the Sitecore MVP program. Over the years, I gained more confidence to writ...
2 comments
Read more

Clean Coding Principles in CSharp

A code shall be easy to read and understand. In this post, I am outlining basic principles  about clean coding after researching through expert recommended books, trainings and based on my experience. A common example to start with is a variable declaration like - int i  The above statement did not clarify the purpose of variable i. However,  the same variable can be declared as -  int pageNumber The moment we declared the variable as int pageNumber, our brain realized that the variable is going to store the value for number of pages. We have set the context in our brain now and it is ready to understand what the code is going to do next with these page numbers. This is one of the basic advantages of clean coding. Reasons for clean coding -  • Reading clean code is easier - Every code is revisited after certain amount of time either by the same or different developer who created it. In both the cases, if the code is unclean, its difficult to understand and u...
Post a Comment
Read more