Sitecore SEO

How to make a Sitecore site rank — the two platforms that change everything (XP vs XM Cloud), what SXA gives you out of the box and what it doesn't, and the platform-specific traps that catch enterprise teams: the default robots.txt that blocks every crawler, aliases that create duplicate content at HTTP 200, and metadata that silently fails to inherit because blank isn't NULL.

First published: Jun 27, 2026 · Last updated: Jul 19, 2026 · Advanced
demand #7 in CMS#38 in Platform SEO#237 in Technical SEO#319 on the site

Sitecore is an enterprise DXP that ships with almost no SEO functionality out of the box — and the two product lines behave very differently. Sitecore XP is traditional server-rendered .NET; XM Cloud (renamed SitecoreAI in Sitecore's current docs) is headless SaaS where a Next.js front end (via JSS, now published as Content SDK) controls the HTML and you manage SEO with Next.js metadata APIs. SXA adds the basics (sitemap, robots.txt management, metadata fields) but everything still needs configuration. Three Sitecore-specific traps catch teams: the default robots.txt blocks every crawler if the robots field is left blank (empty ≠ permissive); item aliases serve HTTP 200 on both URLs, creating true duplicate content that canonical doesn't fix automatically; and blank metadata fields don't fall back to Standard Values unless 'Reset Blank' is enabled, because blank isn't NULL. On the enterprise scale Sitecore lives at, governance — a base SEO template, validation rules, environment control — matters as much as any single setting.

TL;DR — Sitecore ships with almost no SEO functionality; SXA adds the basics but needs configuration. The two platforms diverge completely: XP is server-rendered .NET (crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. see finished HTML, personalization renders server-side); XM Cloud is headless, where a Next.js front end controls the HTML and you manage SEO with Next.js metadataNext.js SEO is the set of practices and built-in features that make a Next.js site crawlable, indexable, and rankable — rendering mode (SSG/SSR/ISR/Server Components), the App Router Metadata API, sitemap.ts/robots.ts conventions, next/image, and next/link. APIs (generateMetadata, MetadataRoute) — with SSG/ISR the recommended renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. modes. The platform-specific traps: the default robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. blocks all crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. when the field is blank; item aliases return HTTP 200HTTP 200 OK is the standard 2xx success status code, meaning the server received, understood, and fulfilled the request and is returning the resource. It's the code every page you want indexed should return — but a 200 alone doesn't guarantee Google will index the page. on both URLs (true duplicate content, no canonical fix by default); and blank metadata fields don’t inherit Standard Values unless “Reset Blank” is enabled (blank ≠ NULL). At Sitecore’s enterprise scale, governance — a base SEO template, validation rules, environment control — is the real work. (Naming note: Sitecore’s docs now call the XM Cloud product SitecoreAI; the architecture below is unchanged.)

Evidence for this claim The article's described sitecore-seo capabilities must be evaluated against the platform's current documentation rather than assumed to be search-engine behavior. Scope: Platform-specific capability documentation. Confidence: high · Verified: Sitecore: SEO Evidence for this claim Regardless of platform, Google needs crawlable URLs, accessible rendered content, descriptive metadata, and valid search directives. Scope: Google requirements independent of platform. Confidence: high · Verified: Google Search Central: SEO Starter Guide

Two platforms, two completely different SEO models

The single most important thing to establish before touching anything: which Sitecore are you on? The product name is the same; the SEO mechanics are not.

  • Sitecore XP (Experience Platform). Traditional .NET, server-rendered via Razor/MVC, deployed on-premise or in managed cloud. GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. generally receives finished HTML. SEO is managed inside Sitecore — in templates, Standard Values, and request pipelines.
  • XM Cloud. Headless SaaS. Sitecore stores the content and exposes it over a GraphQL API (Experience Edge); a decoupled front end — almost always Next.js built with Sitecore JSS (JavaScript Services) — renders the HTML. SEO lives in the Next.js application layer. Sitecore holds the content; Next.js controls the output.

A naming note if you’re checking Sitecore’s own docs while reading this: as of mid-2026, Sitecore’s documentation site has renamed the composable SaaS product from “XM Cloud” to SitecoreAI — the old doc.sitecore.com/xmc/... and developers.sitecore.com/learn/accelerate/xm-cloud/... URL paths now redirectA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. to .../sai/.../sitecoreai/... paths, and the platform’s own landing page describes it as “a cloud-native, SaaS, hybrid headless digital experience platform.” The architecture this article describes is unchanged — Experience Edge, GraphQL, a decoupled Next.js front end — but the front-end SDK is now published as Content SDK (open source, Next.js-first) rather than under the JSS name, and you’ll see “SitecoreAI” rather than “XM Cloud” in current screenshots and menu labels. I’ve kept “XM Cloud” in this article because that’s still the term most practitioners search for and most existing implementations run on, but don’t be thrown if your Sitecore rep or the Cloud Portal now says SitecoreAI — same platform, same SEO mechanics below.

In both cases the practical baseline is the same. As Fishtank’s Marcel put it back in 2018, “Sitecore ships with virtually no SEO functionality (with the exception of SXA which includes some basics).” That’s still the right mental model. SXA (Sitecore Experience Accelerator) is the layer that gives you a sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. module, robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere. management in the content tree, and standardized metadata fields. Without it, all of that is custom development.

This is squarely enterprise SEO territory. Sitecore implementations involve dedicated developers and solution partners, and — as I’ve written about enterprise sites generally“the more likely you are to run into multiple tech stacks,” legacy systems, and split ownership across sections. Keep that in mind: on Sitecore, the fix for an SEO problem is often a template change or a pipeline override owned by a developer, not a setting you flip yourself.

Metadata — and the blank-vs-NULL trap

SEO fields (page titleThe title tag is the HTML title element in a page's head that specifies the document's title. It's the primary source for the SERP title link and a confirmed light ranking factor — but since August 2021 Google doesn't always show it verbatim., meta descriptionThe meta description is an HTML head tag — `<meta name=\"description\" content=\"…\">` — that suggests a short summary of the page for the search snippet. It's not a Google ranking factor, and Google rewrites it the majority of the time, but a good one can still lift click-through., Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. tags) live in your page data templates. The clean pattern is a base SEO template that every page template inherits from, so the fields exist everywhere. Ken Gray of Konabos notes the default gap directly: “out-of-the-box, Sitecore’s data templates might not include some of the Meta Data fields.”

Standard Values let you set sensible defaults for those fields (for example a $name token as a title fallback). But here’s the Sitecore-specific trap that produces missing metadata at scale. Sitecore’s own docs are explicit: “If the value of a field is NULL, the item contains the standard value for that field as defined in the data template for that item.” The catch is that a blank field is not NULL. When a content author clears a meta description, it becomes blank — and a blank field does not fall back to the Standard Value unless “Reset Blank” is enabled on that field. The result is pages renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. &lt;meta name="description" content=""> instead of inheriting a default. On a large site, that’s thousands of empty descriptions nobody intended.

The fix is twofold: enable “Reset Blank” on metadata fields where a fallback is desired, and add validation rules that enforce non-empty titles and descriptions (and character limits) so authors can’t silently ship blanks.

URL management and the alias trap

Sitecore generates URLs from the content-tree path by default; clean URLs come from SXA settings or custom item resolvers.

The trap is item aliases — alternate URLs you can attach to any item. They look harmless and they are not SEO-neutral. As Dheer Rajpoot documented, “no redirect (no 301 or 302 HTTP status codeAn HTTP status code is the three-digit number a server returns with every response to tell a browser or crawler what happened to its request — success, redirect, client error, or server error. For SEO the code matters as much as the content: it tells Google and Bing whether to index a page, follow a redirect, retry later, or drop the URL from the index.) happens when you are using aliases in Sitecore,” which means “multiple URLs will be created for a single page URL.” Both the canonical URL and the alias return HTTP 200 with identical content — genuine duplicate contentThe same or very similar primary content reachable at more than one URL. There's no general duplicate content penalty — the real costs are possible signal dilution, the wrong URL getting chosen, and less-efficient crawling., and Sitecore does not auto-emit a canonical tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. to resolve it.

You have two governance-grade fixes:

  1. Override the AliasResolver in the HttpRequest pipeline to inject a canonical tagA rel=\"canonical\" annotation — in the HTML <head> or an HTTP Link header — that tells search engines which URL is the preferred version of duplicate or near-duplicate content. pointing at the real URL, or
  2. Modify the alias pipeline to issue a 301 redirectA 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank. instead of serving the alias directly.

My recommendation is the second: treat aliases as redirects, not alternate access URLs. Ken Gray’s advice applies broadly here — “use Sitecore’s canonical link management to specify the preferred version of a URL” — but on aliases specifically, a 301 is cleaner than relying on canonical hints.

Sitemaps

On SXA, configure the sitemapA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing. at site/Settings → Search Engines Sitemap → Sitemap Mode. Two relevant modes: Stored in cache (the default — regenerates dynamically; good for frequently updated or Azure-hosted sites) and Stored in file (a static file; better for large sites that change infrequently, avoiding regeneration overhead). SXA automatically appends the sitemap URL to robots.txt, and the sitemap lives at /sitemap.xml. A common failure: if TargetHostName isn’t configured, the sitemap returns a 404.

On XM Cloud + Next.js, generate the sitemap programmatically with MetadataRoute.Sitemap, querying Experience Edge over GraphQL — which lets you exclude non-indexable URLs at the application layer. Sitecore’s own guidance notes that “Next.js offers built-in sitemap and robots.txt generation.”

Robots.txt — the default that blocks everything

This is the Sitecore trap with the highest blast radius. On SXA, robots.txt is configured in the content tree (site Settings → Robots content field), and you must republish the site after a change. The gotcha, straight from Sitecore’s docs: “If no rules are added, the system writes: ‘User-agent: * Disallow: /’” — which blocks every crawler. An empty robots field is not a permissive robots.txt; it’s a site-wide block. You must explicitly set:

User-agent: *
Allow: /

On most platforms a missing robots.txt means “crawl everything.” On Sitecore it can mean the opposite, so verifying production robots.txt is a non-negotiable launch step. On XM Cloud + Next.js, use MetadataRoute.Robots for a code-driven, type-safe robots.txt. Separately, CM (Content Management) instances and QA/staging environments should always disallow all — only the CD (Content Delivery) production instance should be crawlable.

Multilingual, hreflang, and multisite

Sitecore stores language versions as separate versions of the same item, not separate items. That, combined with language fallback (item-level or the more granular field-level, e.g. an es-MX → es-ES → en chain), can serve the same content at multiple language URLs — a duplicate-content vector unless hreflangHreflang is an annotation (in HTML, HTTP headers, or XML sitemaps) that tells search engines which language and optional region a page targets, and which alternate versions exist. It only works when every page in the cluster references all the others. signals the relationship. And hreflang is not automatic in standard Sitecore; it has to be added to templates (SXA can generate it when configured), with full absolute URLs, bidirectional references, and an x-default. As John Mueller put it (cited by Jakub Koba), “TBH hreflang is one of the most complex aspects of SEO (if not the most complex one).” Don’t underestimate it.

Sitecore also natively supports multisite — many sites in one install, sometimes sharing content. Shared content across site boundaries needs a deliberate canonical strategy, and each site needs its own sitemap and robots.txt. This is exactly the kind of split-ownership, shared-infrastructure complexity I flagged in enterprise technical SEO: “Sometimes different people are responsible for different sections of the website or even different pages, which can make internal linkingLinks between pages on the same site. time-consuming.”

Headless rendering strategy (XM Cloud)

One layer-ownership point worth being explicit about, since it trips people up: XM Cloud environments have both an editing host and a rendering host, and they are not the same thing. Sitecore’s own docs draw the line clearly — the editing host exists only to power the WYSIWYG editing experience inside Page Builder/Design Studio, “is not set up or scaled for serving live traffic,” and sees internal (author-only) traffic. The rendering host is the public-facing Next.js app — hosted on Vercel, Netlify, or Azure, consuming content from Experience Edge, and scaled to serve real site visitors. Crawlers only ever hit the rendering host; the editing host’s rendering behavior (or an editing-host URL leaking into a sitemap or getting linked to) is not representative of what GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. sees and isn’t something search engines should be able to reach at all.

On XM Cloud the rendering mode you choose in Next.js is the SEO decision. Akshay Sura (Konabos) lays out the four options cleanly:

StrategySEO impact
SSG (static)Best — “SSG pre-renders HTML at build time… Search engines can easily crawl the pre-rendered HTML.”
ISR (incremental static regen)Good — static performance with background freshness; recommended for content at scale
SSR (server-side render)Good — “Fully rendered HTML is ready for search engines to index.”
CSR (client-side render)Worst — “Search engines may struggle with indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. JavaScript-rendered content.”

The recommendation: SSG or ISR for SEO-critical content; reserve CSR for interactive UI only. Metadata is set via generateMetadata (App Router). David Austin (Fishtank) notes a performance nicety: “All fetch calls within generateMetadata are memoized, meaning identical URLs are only fetched once across the application, preventing redundant requests.” And as Sebastián Aliaga puts it, “The dynamic approach is the better method for Sitecore Headless as you’ll be able to take what’s part of the page’s layout data and incorporate it.”

Personalization — don’t cloak

Sitecore’s personalization is a real SEO consideration. On XP, personalization renders server-side, so Googlebot sees the default (un-personalized) experience — make sure that default is complete and SEO-optimized, not thin. On XM Cloud, client-side personalization (JSS) can hide content from crawlers that don’t run the JavaScript; pre-render the default with SSR, or personalize at the edge.

The hard rule across both: never serve different content to crawlers than to users — that’s cloaking, and it’s a guidelines violation. Never personalize the primary H1, FAQ content, or structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. with client-side rules. Personalization should add to, never replace, the canonical content.

Structured data

Use JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. in &lt;script type="application/ld+json">. On XP, render it from template fields in your Razor view or via pipeline; on XM Cloud, model schema fields in templates, retrieve over GraphQL, and render in the Next.js component. Prioritize FAQPage, HowTo, Product, Article, and BreadcrumbList. You can deploy via a tag manager — Martha van Berkel (Schema App) notes teams “typically use JavaScript to deploy Schema MarkupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. to Sitecore… both efficient and scalable” — but be aware client-side injection means AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. may miss it, so prefer server-rendered JSON-LD for maximum coverage. Peter Lambrou (Codehouse) frames the payoff simply: “Add schema markup to the page HTML to make your search results appear more attractive.”

Enterprise governance — where the real work is

Single settings aside, the SEO outcome on a big Sitecore install is decided by governance. I’ve said before that enterprise sites are where technical SEO shines precisely because “enterprise sites can have complex infrastructures and a lot of legacy systems in place” — and “I doubt there’s a major website that is technically perfect.” The recurring Sitecore-specific governance items:

  • Template sprawl. Multiple templates for the same purpose, each with different (or missing) SEO fields. Audit them; enforce a base SEO template that every page template inherits.
  • Metadata validation. “Reset Blank” plus field-level validation so authors can’t ship empty or over-length titles and descriptions.
  • Alias governance. A policy that aliases are only created with a canonical override or as 301s.
  • Environment control. CM/QA/staging disallowed; production explicitly allowed and verified.
  • Crawl budgetThe number of URLs an engine will crawl in a timeframe. at scale. Faceted navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals., language versions, and parameter URLs can blow up the URL space; curate sitemaps and govern robots/noindexMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored. tightly. (See crawl budgetThe number of URLs an engine will crawl in a timeframe..)

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.