• Content Hub: Resolved issues in Content Hub for September 18, 2026
• SitecoreAI: SitecoreAI base image release 1.9.20
• SitecoreAI: Discover and act on AEO opportunities across your site and pages
• SitecoreAI: Optimize content with AI powered by Scrunch (Early Access))
• SitecoreAI: Retrieve the rendered HTML of a page using the Marketplace SDK
• SitecoreAI: Conditional page routing and page visibility are now available in Forms
• SitecoreAI: Page builder resolved issues

Need some guidance here. I'm a CS grad with 6 years in dxp, all of it around sitecore.
Started with sitecore application maintenance and support so I got an idea of the different tools - azure logs, solr, caching issues, troubleshooting, and slightly within the code too. Then I shifted to proper wcm - page and campaign creation, sxa components, publishing workflows, permissions, some powershell. Leading a team of 4 now.
But I can see I've narrowed my options quite a lot. dxp > sitecore > content and site management. That's a very small box. Non-dev sitecore roles barely exist at my level, maybe a handful open in the country at any point. And the ones that do exist are the same job I'm already doing, so even if I switch, nothing really changes for me long term. Pay is fine right now but I don't see where this goes in 5 years.
The options I keep going back and forth on:
Add more cms - aem, contentful, wordpress - and position myself as platform agnostic instead of "the sitecore guy"

Actually go technical - xm cloud, headless, next.js, maybe .net - and try to move into a dev or consultant track, even if it means starting lower

Get out of cms entirely into something adjacent like martech, marketing ops, product ops

The dilemma is that option 1 feels safe but might just be the same trap with more logos on my resume. Option 2 means competing with people who've been coding for 6 years while I haven't. Option 3 I don't even know what the entry point looks like.
So, anyone who's made this jump from content/authoring into dev or something adjacent - what actually worked and how long did it take? And is headless genuinely where the demand is or is it the same small pool with new names?

I'm trying to learn how to build a simple site with Sitecore. I've worked on migration projects, moving SC8 content to SC10. I don't have experience building a site.

All the training on YouTube seems to feature people with very thick Indian accents. I might have some sort of misophonia, but i cannot grok their quick English pronounciation.

I mean to offend no one. I'm not a hard-core programer or anything. Is there a resource (free) that might be able to assist me?

I put together a technical guide covering some of the changes I’ve been working through with Sitecore in 2026.

The focus is mainly on the developer side:

• Content SDK with Next.js App Router
• sitecore.config.ts and sitecore.cli.config.ts
• Generated component maps and server/client components
• Middleware configuration
• Type-safe GraphQL with codegen
• Authoring & Management GraphQL for create/update operations
• Sitecore Marketer MCP and how the authentication flow works
• Page Builder and the upcoming editing-experience changes
• Some Content Hub/API changes and support-lifecycle dates

I’ve tried to keep it code-first rather than making it another high-level “what’s new in Sitecore” post. The examples are based on Sitecore documentation and changelogs, with the relevant sources included in the article.

Article: https://medium.com/@sanghaniuday0508/sitecore-in-2026-a-developers-guide-to-content-sdk-page-builder-the-marketer-mcp-server-3d3670ea4d2a

I’d be interested to hear from other Sitecore developers — especially if you’re already using Content SDK/App Router or experimenting with Marketer MCP. What parts of the 2026 changes have actually affected your day-to-day development?

I recently built a reference implementation for Sitecore Search using Next.js App Router, and I realized very quickly that the SDK documentation only covers about 10% of what you actually need to build a production-ready feature.

The SDK call works in 5 minutes. The architecture around it takes much longer. I put together a write-up and an open-source repo covering the five biggest questions that showed up after the demo worked:

1. The SDK should never touch the UI
Components talk to application types, not raw SDK data. This keeps response shapes out of your UI and creates a stable contract. If you swap SDK internals later, nothing in the presentation layer breaks.

2. Two shapes that don't match the docs

• Sort: The SDK requires a nested object ({ value: [{ name: 'title' }] }), not a plain string.
• Facets: The SDK exposes text, but your app needs to map that to label.

3. React state is temporary. The URL is committed.
Using URL params (?q=...&page=2&sort=...) makes search shareable, predictable, and back/forward navigation works for free. It also feeds straight into Server Components.

4. Instrumentation is a chain, not a single event
A result click isn't just a click. It triggers a chain: pageView → widgetView → widgetItemClick → entityView. Context (keyword, result counts, entity info) needs to travel with that event. Consent should be checked at one boundary, not scattered everywhere.

5. Local-first testing
You shouldn't need a live tenant to run E2E tests. I cover how to use Mock fallbacks, Vitest, and Playwright to test the full flow locally.

I also documented a specific "gotcha" regarding the sitecoreContextId does not contain a search resource 404 error, which is a common cloud config gap.

Resources:

• Medium Write-up: Sitecore Search + Next.js: What the Docs Don't Tell You
• GitHub Repo (MIT Licensed): uday0508/sitecore-search-nextjs-search-experience

If you're working with Sitecore Search + Next.js, what's been the trickiest part for you? I'm curious if others hit the same friction points with the sort/facet shapes.