Skip to main content

Implementing SitecoreAI Wildcard Pages with Next.js and Content SDK

I recently got chance to help a team on a requirement where we needed to implement product detail pages using SitecoreAI wildcard pages.

The setup was:

  • SitecoreAI
  • Content SDK 1.3.2
  • Next.js 15
  • Next.js App Router

The requirement was to have a Product Details page configured as a wildcard (*) item in SitecoreAI and use the incoming URL to determine which product should be displayed.

For example, we wanted URLs such as:

/products/product-123
/products/product-456
/products/product-789

All of these URLs should use the same wildcard page layout, while the last part of the URL identifies the actual product.

The Initial Question

We raised a Sitecore support case because we wanted to understand the recommended way to implement the wildcard page resolver with the Content SDK and Next.js App Router.

The important part of the question was that we were using Content SDK, not the JSS SDK, and the application was using the Next.js App Router.

Initially, the Sitecore AI support agent provided some guidance and documentation links. We specifically asked for the query to be reviewed by a support engineer rather than relying only on the AI response.

The Basic Wildcard Page Setup

The first part is straightforward.

In SitecoreAI, create a wildcard page under the required route. For example, if the required URL structure is:

/products/<product-slug>

the content tree can contain a wildcard item under the products item.

The wildcard item is configured with the required presentation details, components and placeholders.

Once the wildcard item is published, Sitecore represents the wildcard route using the special ,-w-, token.

So instead of trying to resolve the layout using:

/products/product-123

the layout should be resolved using the wildcard route:

/products/,-w-,

The Important Separation

This is the part that I found most useful.

There are actually two different things happening:

  1. We need to determine which Sitecore item provides the page layout.
  2. We need to determine which product the visitor is requesting.

The wildcard item is responsible for the first part.

The URL segment is responsible for the second part.

So for:

/products/product-123

we don't necessarily ask Sitecore for layout information for /products/product-123.

Instead, we resolve the layout from:

/products/,-w-,

and separately keep product-123 for retrieving the product data.

Resolving the Wildcard Layout

The support response described the approach using the Layout Service.

For example, when calling the REST Layout Service, the route passed to the layout request would be the wildcard route:

const language = 'en';

const sitecoreRoutePath = '/products/,-w-,';

const layoutData = await layoutService.fetchLayoutData(
  sitecoreRoutePath,
  language
);

The important point is not the exact helper implementation above, but the route being supplied to Layout Service.

The incoming URL and the Sitecore layout route are two different pieces of information.

Getting the Product from the URL

Once Next.js receives a request such as:

/products/product-123

the application can extract the relevant URL segment from the catch-all route.

That value can then be used to retrieve the actual product data.

For example:

const productSlug = path[path.length - 1];

The application can then use that value to query the product source, such as Experience Edge GraphQL or another product system.

Conceptually, the flow becomes:

Incoming URL
     |
     v
/products/product-123
     |
     +----------------------+
     |                      |
     v                      v
Wildcard layout        Product identifier
/products/,-w-,        product-123
     |                      |
     v                      v
Sitecore layout        Product data
     |                      |
     +----------+-----------+
                |
                v
         Render the page

Why Use a Wildcard Layout?

One of the reasons for using this pattern is that potentially thousands of product URLs can share the same Sitecore layout.

For example:

/products/product-123
/products/product-456
/products/product-789
/products/product-1000
...

All of them can use the same wildcard item for their Sitecore presentation.

The product itself can come from another data source based on the URL.

This also has implications for caching and Experience Edge because the layout request can consistently target the wildcard item rather than creating a separate layout resolution for every external product URL.

One Important Caveat

The initial support response included an example using RestLayoutService from the JSS package.

However, our application was using the Sitecore Content SDK.

So I would not take the JSS code example and assume that it is directly applicable to a Content SDK implementation.

The important part of the support guidance is the architecture:

  • Resolve the Sitecore layout using the wildcard route.
  • Keep the original URL/path available to the application.
  • Use the URL segment to identify the product.
  • Fetch the product data independently.
  • Render the product using the wildcard page layout.

The Architecture I Took Away From This

For me, the key takeaway from this support case was that a wildcard page is not really about making Sitecore understand every possible product URL.

Instead, the wildcard item acts as the reusable Sitecore page definition.

The application handles the dynamic part of the URL.

So the responsibilities can be thought of as:

Responsibility Handled By
Page layout Sitecore wildcard item
Presentation details SitecoreAI
Incoming URL Next.js App Router
Product identifier URL segment
Product data Experience Edge or external product source

Final Thoughts

Wildcard pages are particularly useful when the number of dynamic pages is large but the page structure is common.

Instead of creating a separate Sitecore page for every product, the wildcard item provides the common Sitecore presentation while the application resolves the actual product from the URL.

The important thing is to keep these two concepts separate: the Sitecore item that provides the layout and the URL value that identifies the dynamic entity.

That separation makes the implementation much easier to reason about, especially when working with Next.js App Router and Sitecore Content SDK.

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