Sitecore Docs - Tech Tips by GS

I recently spent some time troubleshooting SitecoreAI Page Branches, and what initially looked like one problem actually turned out to be two different things. The requirement was fairly straightforward: We wanted content authors to be able to create pages using Page Branches directly from Page Builder, without having to manually configure insert options on every page template. At the same time, we wanted the Page Branch to provide the required datasource structure for the components used by the page design. That led to two questions: Why are my Page Branches not appearing as insert options? Why aren't the datasource items being automatically created when a page is created from a Page Branch? The interesting part was that the answers were different. The Original Requirement We had Page Branches configured under: /sitecore/content/mysite/Shared/Presentation/Page Branches The idea was to configure a rule on the Page Branches folder so that a particular Pag...

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 Sitec...

I recently came across an interesting routing issue in SitecoreAI where enabling useDisplayName started generating much cleaner URLs, but those URLs were returning 404 in the rendering host. The interesting part was that the same pages worked perfectly when accessed using their original item-name based URLs. The Requirement The team I was helping had category pages with URLs like: https://testing.mysite.com/Products/1341592/1342427/1342434 These URLs are technically valid, but they aren't particularly user-friendly. The preferred URL was something like: https://testing.mysite.com/Products/category1 display name/category2 display name /category3 display name In Sitecore, this can be achieved by configuring the link provider to use the item's display name when generating URLs. The Configuration Change We deployed the following Sitecore configuration patch in the staging environment: <?xml version="1.0" encoding="utf-8"?> <confi...

I recently came across an interesting issue in SitecoreAI Page Builder where Insert Options were not behaving as expected. The problem was quite simple to reproduce from the editor's point of view, but the underlying behavior was confusing. The Problem We had Page Branches configured as insert options for a page. When opening the page in Page Builder and checking the available insert options, the same Page Branch templates were appearing multiple times . In other words, instead of seeing something like: Branch Template A Branch Template B Branch Template C the Page Builder insert menu could show the same branch template more than once. This was particularly confusing because the configuration itself did not appear to contain duplicate entries. Initial Investigation One of the first things I wanted to establish was whether this was simply a Page Builder UI issue or whether the duplication was already present in the data returned by Sitecore. Sitecore...

The Problem If you have ever built a site on Sitecore AI, you have probably seen image URLs that look like this: https://edge.sitecorecloud.io/yourcompany1-yourcompanyltd-p49d-fb1a/media/images/HeroBanner.png That works fine while you are prototyping or testing. But when real customers visit your site, a URL that says "sitecorecloud.io" can cause real problems: Your images are not showing up in Google Image search. Sitecore adds an X-Robots-Tag: noindex header to every media request served from the default Edge domain. Search engines see that and skip your assets. It looks unprofessional. Brand teams hate sharing links that point to someone else's domain. Analytics and cookies get messy. Browsers are blocking third-party cookies, and a "shared" domain makes it harder to track your own traffic correctly. You lose domain authority. Search engines don't credit your brand for content hosted on a shared, multi-tenant domain. In this p...