SEO para Sitecore

TL;DR — Sitecore es un CMS empresarial de gran escala y no resuelve el SEO por sí solo. Los elementos básicos de cualquier sitio —títulos de página, descripciones, un mapa del sitio y un archivo robots.txt adecuado— deben configurarse, y Sitecore tiene algunas particularidades que pueden bloquear silenciosamente todo el sitio o crear páginas duplicadas. Conocerlas permite evitar la mayor parte de estos problemas.

Qué es Sitecore

Sitecore es una plataforma de experiencia digital: un CMS empresarial de gran escala que las organizaciones usan para operar sitios web complejos con personalización, varios idiomas y múltiples sitios en una sola instalación. Tiene dos variantes principales, cuya diferencia es muy importante para el SEO:

• Sitecore XP (Experience Platform): la alternativa tradicional. Está construida sobre .NET y renderiza las páginas en el servidor, por lo que los motores de búsqueda suelen recibir el HTML completo.
• XM Cloud: la versión moderna en la nube. Sitecore almacena el contenido y un sitio front-end independiente —normalmente creado con Next.js— lo obtiene y construye las páginas. El SEO se controla en esa aplicación front-end, no dentro de Sitecore.

El dato principal

Sitecore ofrece muy poca funcionalidad SEO de fábrica. Existe una extensión llamada SXA (Sitecore Experience Accelerator) que proporciona los elementos esenciales —mapa del sitio, control de robots.txt y campos de metadatos—, pero aun así se requiere configurarlos. Sin SXA, incluso elementos básicos como el campo de metadescripción deben añadirse manualmente.

Tres problemas que conviene vigilar

Sitecore tiene algunas particularidades que suelen sorprender a los equipos:

1. El robots.txt que bloquea todo. Si el campo de robots en la configuración de Sitecore queda en blanco, Sitecore no entrega un robots.txt vacío y permisivo, sino uno que bloquea todos los motores de búsqueda. En este caso, vacío no significa «permitir todo».
2. Alias que duplican páginas. Sitecore permite asignar una segunda URL (un «alias») a una página. Ambas URL devuelven una respuesta normal «200 OK», sin redirección, lo que genera dos URL activas para el mismo contenido: contenido duplicado.
3. Campos vacíos que no recuperan el valor predeterminado. Sitecore puede definir un valor predeterminado para un campo («Standard Value»), pero si una persona autora borra el campo, este permanece vacío en lugar de volver al valor predeterminado. El resultado son páginas con títulos y descripciones vacíos.

Para consultar la versión técnica —cómo funciona el SEO en XP frente a XM Cloud, el flujo de metadatos de Next.js, hreflang y la gobernanza empresarial—, puede abrirse la pestaña Advanced.

TL;DR — Sitecore casi no incluye funcionalidad SEO de fábrica; SXA añade lo básico, pero requiere configuración. Las dos plataformas difieren por completo: XP usa .NET con renderizado del lado del servidor —los rastreadores reciben HTML completo y la personalización también se renderiza en el servidor—; XM Cloud es headless y un front-end de Next.js controla el HTML y el SEO mediante las API de metadatos de Next.js (generateMetadata, MetadataRoute), con SSG/ISR como modos recomendados. Los problemas específicos de la plataforma son tres: el robots.txt predeterminado bloquea todos los rastreadores cuando el campo está vacío; los alias de elementos devuelven HTTP 200 en ambas URL —contenido duplicado real, sin corrección canónica predeterminada—; y los campos de metadatos vacíos no heredan Standard Values salvo que se active «Reset Blank» (vacío ≠ NULL). A la escala empresarial de Sitecore, el trabajo decisivo es la gobernanza: una plantilla SEO base, reglas de validación y control de entornos. Nota de nomenclatura: la documentación actual de Sitecore llama SitecoreAI al producto XM Cloud; la arquitectura descrita no cambia.

Dos plataformas, dos modelos SEO completamente diferentes

Antes de realizar cualquier cambio, debe determinarse un dato fundamental: ¿qué versión de Sitecore se utiliza? El nombre del producto es el mismo, pero sus mecanismos SEO no lo son.

• Sitecore XP (Experience Platform). .NET tradicional, con renderizado del lado del servidor mediante Razor/MVC y despliegue local o en una nube administrada. Googlebot suele recibir el HTML completo. El SEO se gestiona dentro de Sitecore: en plantillas, Standard Values y flujos de solicitudes.
• XM Cloud. SaaS headless. Sitecore almacena el contenido y lo expone mediante una API GraphQL (Experience Edge); un front-end desacoplado —casi siempre Next.js construido con Sitecore JSS (JavaScript Services)— renderiza el HTML. El SEO reside en la capa de la aplicación Next.js. Sitecore conserva el contenido; Next.js controla la salida.

Una nota de nomenclatura para quienes consulten la documentación de Sitecore: a mediados de 2026, el sitio de documentación cambió el nombre del producto SaaS componible de «XM Cloud» a SitecoreAI. Las rutas antiguas doc.sitecore.com/xmc/... y developers.sitecore.com/learn/accelerate/xm-cloud/... ahora redirigen a rutas .../sai/.../sitecoreai/..., y la página oficial de la plataforma la describe como “a cloud-native, SaaS, hybrid headless digital experience platform.” (una plataforma de experiencia digital headless híbrida, SaaS y nativa de la nube). La arquitectura descrita en este artículo no cambió —Experience Edge, GraphQL y un front-end de Next.js desacoplado—, pero el SDK front-end ahora se publica como Content SDK —de código abierto y orientado a Next.js— en lugar de usar el nombre JSS. En capturas y menús actuales aparecerá «SitecoreAI» en vez de «XM Cloud». Este artículo conserva «XM Cloud» porque sigue siendo el término que más buscan los profesionales y el que usan la mayoría de las implementaciones existentes. Si una persona representante de Sitecore o el Cloud Portal usan SitecoreAI, se trata de la misma plataforma y de los mismos mecanismos SEO descritos a continuación.

En ambos casos, el punto de partida práctico es el mismo. Marcel, de Fishtank, lo resumió en 2018: “Sitecore ships with virtually no SEO functionality (with the exception of SXA which includes some basics).” (Sitecore casi no incluye funcionalidad SEO, salvo SXA, que aporta algunos elementos básicos). Ese sigue siendo el modelo mental correcto. SXA (Sitecore Experience Accelerator) es la capa que incorpora un módulo de mapa del sitio, gestión de robots.txt en el árbol de contenido y campos de metadatos estandarizados. Sin ella, todo esto requiere desarrollo personalizado.

Este es claramente un ámbito de SEO empresarial. Las implementaciones de Sitecore implican equipos de desarrollo y socios de soluciones especializados y, como se ha señalado sobre los sitios empresariales en general, “the more likely you are to run into multiple tech stacks,” (mayor es la probabilidad de encontrar varias pilas tecnológicas), además de sistemas heredados y responsabilidades divididas entre secciones. En Sitecore, la solución a un problema SEO suele ser un cambio de plantilla o una modificación de un flujo que pertenece al equipo de desarrollo, no un simple ajuste de configuración.

Metadatos y el problema de los campos vacíos frente a NULL

Los campos SEO —título de página, metadescripción y etiquetas Open Graph— se encuentran en las plantillas de datos de las páginas. El patrón adecuado es una plantilla SEO base de la que hereden todas las plantillas de página, de modo que los campos existan en todas partes. Ken Gray, de Konabos, señala directamente esta carencia predeterminada: “out-of-the-box, Sitecore’s data templates might not include some of the Meta Data fields.” (de fábrica, las plantillas de datos de Sitecore podrían no incluir algunos campos de metadatos).

Los Standard Values permiten definir valores predeterminados razonables para esos campos, por ejemplo, un token $name como título alternativo. Sin embargo, existe una particularidad de Sitecore que produce metadatos ausentes a gran escala. La documentación oficial es explícita: “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.” (si el valor de un campo es NULL, el elemento contiene el valor estándar definido en su plantilla de datos). El problema es que un campo vacío no es NULL. Cuando se borra una metadescripción, el campo queda vacío y no vuelve al Standard Value salvo que se active «Reset Blank». Así se generan páginas con <meta name="description" content=""> en lugar de heredar un valor predeterminado. En un sitio grande, esto puede originar miles de descripciones vacías sin intención editorial.

La solución tiene dos partes: activar «Reset Blank» en los campos de metadatos que deban recuperar un valor predeterminado y añadir reglas de validación que exijan títulos y descripciones no vacíos —con límites de caracteres— antes de publicar.

Gestión de URL y el problema de los alias

De forma predeterminada, Sitecore genera las URL a partir de la ruta del árbol de contenido; las URL limpias proceden de la configuración de SXA o de resolutores de elementos personalizados.

El problema son los alias de elementos: URL alternativas que pueden asociarse a cualquier elemento. Aunque parezcan inocuas, no son neutrales para el SEO. Dheer Rajpoot documentó que “no redirect (no 301 or 302 HTTP status code) happens when you are using aliases in Sitecore,” (no se produce ninguna redirección —ni código HTTP 301 ni 302— al usar alias en Sitecore), lo cual significa que “multiple URLs will be created for a single page URL.” (se crean varias URL para una sola página). Tanto la URL canónica como el alias devuelven HTTP 200 con contenido idéntico: contenido duplicado real. Sitecore no emite automáticamente una etiqueta canónica para resolverlo.

Hay dos soluciones adecuadas para la gobernanza:

1. Modificar AliasResolver en el flujo HttpRequest para insertar una etiqueta canónica que apunte a la URL real, o
2. Modificar el flujo de alias para emitir una redirección 301 en lugar de servir el alias directamente.

Se recomienda la segunda opción: tratar los alias como redirecciones, no como URL de acceso alternativas. El consejo general de Ken Gray es pertinente: “use Sitecore’s canonical link management to specify the preferred version of a URL” (usar la gestión de enlaces canónicos de Sitecore para indicar la versión preferida de una URL). No obstante, para los alias, una redirección 301 es más clara que depender de señales canónicas.

Mapas del sitio

En SXA, el mapa del sitio se configura en site/Settings → Search Engines Sitemap → Sitemap Mode. Hay dos modos relevantes: Stored in cache —el predeterminado, que se regenera dinámicamente y resulta apropiado para sitios con actualizaciones frecuentes o alojados en Azure— y Stored in file —un archivo estático, más adecuado para sitios grandes con pocos cambios, pues evita el costo de regeneración—. SXA añade automáticamente la URL del mapa del sitio a robots.txt, y el mapa se publica en /sitemap.xml. Un fallo frecuente es que el mapa devuelve un 404 si no se configura TargetHostName.

En XM Cloud + Next.js, el mapa del sitio se genera mediante programación con MetadataRoute.Sitemap y consultas GraphQL a Experience Edge. Esto permite excluir las URL no indexables en la capa de aplicación. La propia guía de Sitecore señala que “Next.js offers built-in sitemap and robots.txt generation.” (Next.js incluye generación de mapas del sitio y robots.txt).

Robots.txt: el valor predeterminado que bloquea todo

Esta particularidad de Sitecore tiene el mayor alcance potencial. En SXA, robots.txt se configura en el árbol de contenido —campo Robots en Settings del sitio— y el sitio debe volver a publicarse después de cualquier cambio. La advertencia procede directamente de la documentación de Sitecore: “If no rules are added, the system writes: ‘User-agent: * Disallow: /’” (si no se añaden reglas, el sistema escribe «User-agent: * Disallow: /»), lo que bloquea todos los rastreadores. Un campo de robots vacío no produce un robots.txt permisivo, sino un bloqueo general. Debe configurarse explícitamente:

User-agent: *
Allow: /

En la mayoría de las plataformas, la ausencia de robots.txt significa «rastrear todo»; en Sitecore puede significar lo contrario. Por eso, verificar el robots.txt de producción es un paso imprescindible antes del lanzamiento. En XM Cloud + Next.js, debe usarse MetadataRoute.Robots para generar un robots.txt mediante código y con comprobación de tipos. Por separado, las instancias CM (Content Management) y los entornos de QA/preproducción siempre deben bloquear todo el rastreo; solo la instancia CD (Content Delivery) de producción debe ser rastreable.

Sitios multilingües, hreflang y multisite

Sitecore almacena los idiomas como versiones del mismo elemento, no como elementos separados. Esto, junto con la sustitución lingüística —a nivel del elemento o de campos individuales, por ejemplo una cadena es-MX → es-ES → en—, puede servir el mismo contenido en varias URL de idioma. Es una fuente de contenido duplicado si hreflang no señala la relación. Hreflang no es automático en Sitecore estándar: debe añadirse a las plantillas —SXA puede generarlo cuando se configura— con URL absolutas completas, referencias bidireccionales y un x-default. John Mueller lo expresó así, según la cita de Jakub Koba: “TBH hreflang is one of the most complex aspects of SEO (if not the most complex one).” (sinceramente, hreflang es uno de los aspectos más complejos del SEO, si no el más complejo). No debe subestimarse.

Sitecore también admite multisite de forma nativa: varios sitios en una sola instalación, a veces con contenido compartido. El contenido compartido entre sitios requiere una estrategia canónica deliberada, y cada sitio necesita su propio mapa del sitio y robots.txt. Es el tipo de complejidad de infraestructura compartida y responsabilidad dividida señalado en el SEO técnico empresarial: “Sometimes different people are responsible for different sections of the website or even different pages, which can make internal linking time-consuming.” (a veces distintas personas son responsables de secciones o incluso páginas diferentes, lo que puede hacer que los enlaces internos requieran mucho tiempo).

Estrategia de renderizado headless (XM Cloud)

Conviene precisar la propiedad de esta capa porque suele causar confusión: los entornos de XM Cloud tienen un host de edición y un host de renderizado, y no son lo mismo. La documentación de Sitecore establece que el host de edición solo habilita la experiencia WYSIWYG en Page Builder/Design Studio, “is not set up or scaled for serving live traffic,” (no está configurado ni dimensionado para servir tráfico activo) y recibe tráfico interno de autoría. El host de renderizado es la aplicación pública de Next.js, alojada en Vercel, Netlify o Azure, que consume contenido de Experience Edge y está dimensionada para visitantes reales. Los rastreadores solo llegan al host de renderizado. El comportamiento del host de edición —o una URL de edición filtrada a un mapa del sitio o a un enlace— no renderiza lo que ve Googlebot ni debería ser accesible para los motores de búsqueda.

En XM Cloud, el modo de renderizado elegido en Next.js constituye la decisión SEO. Akshay Sura (Konabos) resume las cuatro alternativas:

La recomendación es usar SSG o ISR para el contenido esencial para el SEO y reservar CSR solo para interfaces interactivas. Los metadatos se definen mediante generateMetadata (App Router). David Austin (Fishtank) destaca una ventaja de rendimiento: “All fetch calls within generateMetadata are memoized, meaning identical URLs are only fetched once across the application, preventing redundant requests.” (todas las solicitudes fetch dentro de generateMetadata se memorizan; las URL idénticas se solicitan una sola vez y se evitan peticiones redundantes). Sebastián Aliaga añade: “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.” (el enfoque dinámico es mejor para Sitecore Headless porque permite incorporar los datos de diseño de la página).

Personalización sin encubrimiento

La personalización de Sitecore es una consideración SEO real. En XP, se renderiza en el servidor, por lo que Googlebot recibe la experiencia predeterminada —sin personalización—. Esa versión debe ser completa y estar optimizada para SEO, no ser insuficiente. En XM Cloud, la personalización del lado del cliente mediante JSS puede ocultar contenido a rastreadores que no ejecuten JavaScript; debe prerenderizarse la experiencia predeterminada con SSR o personalizarse en el perímetro.

La regla estricta en ambas plataformas es no servir contenido diferente a rastreadores y personas usuarias: eso constituye encubrimiento e infringe las directrices. El H1 principal, el contenido de preguntas frecuentes y los datos estructurados no deben personalizarse con reglas del lado del cliente. La personalización debe añadir a la información canónica, nunca reemplazarla.

Datos estructurados

Debe usarse JSON-LD en <script type="application/ld+json">. En XP, se renderiza desde campos de plantilla en la vista Razor o mediante el flujo; en XM Cloud, se modelan los campos de datos estructurados en plantillas, se recuperan mediante GraphQL y se renderizan en el componente de Next.js. Conviene priorizar FAQPage, HowTo, Product, Article y BreadcrumbList. Puede implementarse mediante un gestor de etiquetas. Martha van Berkel (Schema App) indica que los equipos “typically use JavaScript to deploy Schema Markup to Sitecore… both efficient and scalable” (suelen usar JavaScript para implementar marcado de schema en Sitecore de manera eficiente y escalable). Sin embargo, la inyección del lado del cliente implica que los rastreadores de IA podrían no detectarlo, por lo que se prefiere JSON-LD renderizado en el servidor para maximizar la cobertura. Peter Lambrou (Codehouse) resume el beneficio: “Add schema markup to the page HTML to make your search results appear more attractive.” (añadir marcado de datos estructurados al HTML para hacer más atractivos los resultados).

Gobernanza empresarial: donde reside el trabajo real

Más allá de cada ajuste, el resultado SEO de una instalación grande de Sitecore depende de la gobernanza. Como se ha señalado en los sitios empresariales, donde destaca el SEO técnico, “enterprise sites can have complex infrastructures and a lot of legacy systems in place” (los sitios empresariales pueden tener infraestructuras complejas y numerosos sistemas heredados), y “I doubt there’s a major website that is technically perfect.” (es dudoso que exista un sitio web importante técnicamente perfecto). Los elementos recurrentes de gobernanza específicos de Sitecore son:

• Proliferación de plantillas. Varias plantillas para el mismo fin, cada una con campos SEO diferentes o ausentes. Deben auditarse y aplicarse una plantilla SEO base heredada por todas las plantillas de página.
• Validación de metadatos. «Reset Blank» y validación a nivel de campo impiden publicar títulos o descripciones vacíos o demasiado largos.
• Gobernanza de alias. Una política que solo permita crear alias con una modificación canónica o como redirecciones 301.
• Control de entornos. CM, QA y preproducción bloqueados; producción permitida y verificada explícitamente.
• Presupuesto de rastreo a escala. La navegación por facetas, las versiones de idioma y las URL con parámetros pueden multiplicar el espacio de URL; deben seleccionarse los mapas del sitio y gobernarse estrictamente robots/noindex. Véase presupuesto de rastreo.

Resumen de IA

Síntesis de la versión Advanced:

• Dos plataformas y dos modelos SEO. Sitecore XP usa .NET tradicional con renderizado del servidor; los rastreadores reciben HTML completo y el SEO se gestiona dentro de Sitecore mediante plantillas, Standard Values y flujos. XM Cloud es SaaS headless; un front-end de Next.js —mediante JSS, ahora publicado como Content SDK— controla el HTML y el SEO con las API de metadatos de Next.js. La documentación actual denomina SitecoreAI al producto; la arquitectura es la misma.
• Host de edición ≠ host de renderizado. En XM Cloud, el host de edición es interno y solo sirve para la edición WYSIWYG; no está dimensionado para tráfico activo. El host de renderizado es la aplicación pública de Next.js que reciben los rastreadores, alojada en Vercel/Netlify/Azure y alimentada por Experience Edge.
• Casi nada de fábrica. “Sitecore ships with virtually no SEO functionality” (Sitecore casi no incluye funcionalidad SEO). SXA añade mapa del sitio, gestión de robots.txt y campos de metadatos, pero todo requiere configuración.
• Problema de robots.txt: un campo de robots vacío hace que Sitecore genere User-agent: * / Disallow: / y bloquee todos los rastreadores. Vacío no significa permisivo; debe configurarse Allow: / y volver a publicarse.
• Problema de alias: los alias de elementos devuelven HTTP 200 en ambas URL sin redirección, lo que genera contenido duplicado real. Sitecore no aplica automáticamente una etiqueta canónica; debe añadirse una modificación canónica o una redirección 301.
• Problema de metadatos: vacío ≠ NULL. Un campo borrado no hereda su Standard Value salvo que se active «Reset Blank», una causa frecuente de títulos y descripciones vacíos a gran escala. Deben añadirse reglas de validación.
• Renderizado headless: se recomiendan SSG/ISR para SEO; SSR es adecuado y CSR es la peor opción. Los metadatos se gestionan con generateMetadata; el mapa del sitio y robots con MetadataRoute.
• Sin encubrimiento: el H1, las preguntas frecuentes y los datos estructurados no deben personalizarse para rastreadores; la experiencia predeterminada debe ser completa para SEO.
• La gobernanza empresarial es el trabajo decisivo: plantilla SEO base, validación de metadatos, política de alias, control de entornos —bloquear CM/QA/preproducción— y selección del presupuesto de rastreo.

Documentación oficial

Documentación de fuentes primarias: la propia de Sitecore y las directrices de Google aplicables. Google no publica documentación específica para Sitecore.

Sitecore

• Search engine optimization (SEO) — XM Cloud / SitecoreAI — conjunto documentado de funciones SEO: mapa del sitio, códigos de idioma en las URL del mapa, robots.txt, redirecciones y optimización de imágenes. Esta URL ahora redirige con 308 a una ruta .../sai/.../sitecoreai/...: la documentación cambió el nombre del producto a SitecoreAI.
• Configure the robots.txt file — SitecoreAI — fuente del comportamiento de bloqueo predeterminado, ubicación del campo robots y motivo por el que debe volver a publicarse.
• Configure a sitemap — SXA — Sitemap Mode —caché o archivo—, atributos y la particularidad de TargetHostName que puede causar un 404.
• Standard values for data template fields — XM — modelo de herencia NULL frente a vacío y compatibilidad con tokens.
• Environment, editing hosts and rendering hosts — SitecoreAI — separación entre CM, host de edición y host de renderizado: solo el último sirve tráfico público y de rastreadores.
• On-page SEO Optimization — Accelerate Cookbook (XM Cloud / SitecoreAI) — lista oficial de optimización en página —H1, texto alternativo, redirecciones y contenido mixto—.
• Optimizing content for AI — Accelerate Cookbook (XM Cloud / SitecoreAI) — guía GEO de Sitecore —SSR/SSG/ISR, autoría por componentes y schema—.

Google (directrices generales aplicables)

• JavaScript SEO basics — pertinente para la renderizado headless de XM Cloud.
• Crawling and Indexing — robots, mapas del sitio, canonicalización y controles de rastreo.

Citas de las fuentes

Declaraciones verificadas y públicas de la documentación de Sitecore y de profesionales especializados en la plataforma. Las citas se conservan en el inglés original y se acompañan de una traducción al español.

Documentación de Sitecore: el comportamiento de bloqueo predeterminado

• “If no rules are added, the system writes: ‘User-agent: * Disallow: /’” — documentación de Sitecore, Configure the robots.txt file. Traducción: «Si no se añaden reglas, el sistema escribe: “User-agent: * Disallow: /”».
• “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.” — documentación de Sitecore, Standard values for data template fields. Traducción: «Si el valor de un campo es NULL, el elemento contiene el valor estándar definido para ese campo en la plantilla de datos del elemento». La particularidad es que vacío ≠ NULL.

El punto de partida: «prácticamente ninguna funcionalidad SEO»

• “Sitecore ships with virtually no SEO functionality (with the exception of SXA which includes some basics).” — Marcel, Sitecore SEO Best Practices | Fishtank (agosto de 2018). Traducción: «Sitecore prácticamente no incluye funcionalidad SEO, salvo SXA, que aporta algunos elementos básicos».
• “out-of-the-box, Sitecore’s data templates might not include some of the Meta Data fields.” / “Use Sitecore’s canonical link management to specify the preferred version of a URL.” — Ken Gray, SEO Best Practices for Sitecore | Konabos (enero de 2024). Traducción: «De fábrica, las plantillas de datos de Sitecore podrían no incluir algunos campos de metadatos» / «La gestión de enlaces canónicos de Sitecore debe usarse para indicar la versión preferida de una URL».

Alias y contenido duplicado

• “no redirect (no 301 or 302 HTTP status code) happens when you are using aliases in Sitecore” / “multiple URLs will be created for a single page URL.” — Dheer Rajpoot, Impact of Sitecore Aliases on SEO | BugDebugZone (julio de 2014). Traducción: «No se produce ninguna redirección —ni código HTTP 301 ni 302— al usar alias en Sitecore» / «Se crean varias URL para una sola página».

Renderizado headless (XM Cloud + Next.js)

• “SSG pre-renders HTML at build time, creating static files that can be served from a CDN.” / “Search engines can easily crawl the pre-rendered HTML.” / “Fully rendered HTML is ready for search engines to index.” / “Search engines may struggle with indexing JavaScript-rendered content.” — Akshay Sura, Master Rendering in Next.js with Sitecore XM Cloud | Konabos (febrero de 2025). Traducción: «SSG prerenderiza HTML durante la compilación y crea archivos estáticos que pueden servirse desde una CDN» / «Los motores de búsqueda pueden rastrear fácilmente el HTML prerenderizado» / «El HTML completamente renderizado está listo para que los motores lo indexen» / «Los motores pueden tener dificultades para indexar contenido renderizado con JavaScript».
• “All fetch calls within generateMetadata are memoized, meaning identical URLs are only fetched once across the application, preventing redundant requests.” / “metadata is one of those things we tend to leave to the bitter end.” — David Austin, Optimizing Metadata and SEO in Next.js for Sitecore XM Cloud | Fishtank (octubre de 2023). Traducción: «Todas las solicitudes fetch dentro de generateMetadata se memorizan; las URL idénticas se solicitan una sola vez en toda la aplicación, lo que evita peticiones redundantes» / «Los metadatos son una de esas cosas que suelen dejarse para el final».
• “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.” — Sebastián Aliaga, Handling SEO in Sitecore XM Cloud Projects | DEV (junio de 2024). Traducción: «El enfoque dinámico es el mejor método para Sitecore Headless, porque permite incorporar los datos que forman parte del diseño de la página».

Sitios multilingües y schema

• “TBH hreflang is one of the most complex aspects of SEO (if not the most complex one).” — John Mueller, Google, citado por Jakub Koba, How to Customize Multilingual Features in Sitecore | kogifi (junio de 2025). Traducción: «Sinceramente, hreflang es uno de los aspectos más complejos del SEO, si no el más complejo».
• “we typically use JavaScript to deploy Schema Markup to Sitecore. This method is both efficient and scalable…” — Martha van Berkel, Implementing Schema Markup on Sitecore | Schema App. Traducción: «Normalmente se usa JavaScript para implementar marcado de datos estructurados en Sitecore. Este método es eficiente y escalable».
• “Add schema markup to the page HTML to make your search results appear more attractive.” — Peter Lambrou, 10 SEO Tips for Your Sitecore Website | Codehouse (diciembre de 2022). Traducción: «Se debe añadir marcado de datos estructurados al HTML de la página para que los resultados de búsqueda sean más atractivos».

Contexto empresarial (de la fuente original)

• “Enterprise sites can have complex infrastructures and a lot of legacy systems in place.” / “I doubt there’s a major website that is technically perfect.” — Patrick Stox, Enterprise Sites Are Where Technical SEO Shines | Ahrefs. Traducción: «Los sitios empresariales pueden tener infraestructuras complejas y numerosos sistemas heredados» / «Es dudoso que exista un sitio web importante técnicamente perfecto».

Lista de verificación de lanzamiento y auditoría SEO de Sitecore

Esta lista debe revisarse antes del lanzamiento y al heredar cualquier sitio de Sitecore:

Aspectos básicos de rastreo e indexación

• El robots.txt de producción es explícito (User-agent: * / Allow: /): se confirma que el campo de robots no está vacío —vacío bloquea a todos— y que el sitio se volvió a publicar.
• Las instancias CM, QA y de preproducción bloquean todos los rastreadores.
• El mapa del sitio responde en /sitemap.xml —SXA— o mediante MetadataRoute.Sitemap —Next.js—; se configuró TargetHostName para evitar un 404.
• El mapa del sitio solo enumera URL canónicas e indexables.

Metadatos

• Existe una plantilla SEO base y todas las plantillas de página la heredan —título, descripción y campos OG—.
• «Reset Blank» está activado en los campos de metadatos que deben recuperar Standard Values.
• Las reglas de validación exigen títulos y descripciones no vacíos y con longitud acotada.

URL y duplicados

• Los alias de elementos redirigen mediante 301 o incluyen una modificación canónica; no hay dos URL HTTP 200 para el mismo contenido.
• Se definen etiquetas canónicas, especialmente para contenido compartido entre sitios.
• Se aplica coherencia de URL —www/sin www, barra final y prefijo de idioma—.

Sitios multilingües

• Hreflang está implementado con referencias bidireccionales, URL absolutas y x-default.
• La sustitución lingüística no duplica silenciosamente contenido en varias URL de idioma.

Solo para headless (XM Cloud)

• El contenido esencial para SEO se renderiza mediante SSG/ISR/SSR, no CSR.
• Los metadatos se establecen con generateMetadata; JSON-LD se renderiza en el servidor, no solo en el cliente.
• Ningún contenido principal —H1, preguntas frecuentes o schema— queda oculto tras una personalización del lado del cliente.

Marco de gobernanza SEO para Sitecore

El SEO en Sitecore escala cuando todas las páginas pasan por los mismos cinco controles, en lugar de depender de cada persona autora o de correcciones puntuales en componentes.

1. Plantilla SEO base: todas las plantillas de página heredan los mismos campos de título, descripción, URL canónica, redes sociales e indexación. Una plantilla sin esta base es un defecto de lanzamiento, no una excepción editorial.
2. Validación de metadatos: Standard Values proporciona valores alternativos, Reset Blank gestiona los campos borrados y las reglas de validación detienen metadatos vacíos o inválidos antes de publicar. Los valores predeterminados y la aplicación de reglas actúan en conjunto.
3. Gobernanza de alias: cada alias redirige permanentemente al elemento canónico o tiene una implementación canónica explícita. Dos URL HTTP 200 para un solo elemento no son un valor predeterminado aceptable.
4. Control de entornos: producción permite el rastreo de forma explícita; CM, QA y preproducción lo bloquean. La respuesta robots activa se comprueba después de cada publicación que modifique esa configuración.
5. Selección de la superficie de rastreo: los mapas del sitio solo contienen URL canónicas e indexables, mientras que la sustitución lingüística, el contenido compartido entre sitios, las facetas y los parámetros se revisan como fuentes de expansión.

En XP, estos controles se aplican en plantillas, Standard Values, flujos y SXA. En XM Cloud, se mantiene el mismo modelo de gobernanza, pero la salida se implementa en la aplicación Next.js mediante generateMetadata, MetadataRoute, JSON-LD renderizado en el servidor y la capa de consultas de Experience Edge.

Hoja de referencia rápida para SEO en Sitecore

XP frente a XM Cloud: dónde se controla el SEO

Los tres problemas

Modos de renderizado headless: orden para SEO

• SSG → mejor —prerenderizado y servido por CDN—
• ISR → excelente —estático y actualizado en segundo plano—
• SSR → bueno —renderizado por solicitud—
• CSR → debe evitarse para contenido indexable

Prioridad de datos estructurados: FAQPage, HowTo, Product, Article y BreadcrumbList; JSON-LD renderizado en el servidor, pues los rastreadores de IA podrían no detectar la inyección mediante un gestor de etiquetas.

Fallos frecuentes de SEO en Sitecore

El sitio de producción desaparece repentinamente tras un bloqueo de rastreo

Síntoma: el /robots.txt activo contiene User-agent: * y Disallow: /, o los rastreadores informan de un bloqueo en todo el sitio.

Causa probable: el campo de robots de Sitecore quedó vacío y se publicó; en esta implementación, vacío no es permisivo.

Solución: se define una regla explícita que permita el rastreo en producción, se vuelve a publicar el sitio y se solicita de nuevo el /robots.txt activo. Debe confirmarse por separado que CM, QA y preproducción permanezcan bloqueados.

Un alias y el elemento canónico aparecen como páginas indexables

Síntoma: dos URL devuelven HTTP 200 con el mismo contenido y el alias no redirige.

Causa probable: el resolutor de alias de Sitecore sirve directamente la ruta alternativa y no añade automáticamente una etiqueta canónica.

Solución: se modifica el flujo de alias para devolver una redirección 301 al elemento canónico o se añade una modificación canónica si el alias debe permanecer accesible. Al volver a rastrear ambas URL, el resultado preferible es un destino 200 y una redirección permanente.

Las páginas publicadas tienen títulos o descripciones vacíos

Síntoma: los metadatos renderizados están vacíos aunque Standard Values defina un valor alternativo.

Causa probable: se borró el campo y se creó un valor vacío en vez de NULL; Standard Values no lo reemplaza salvo que Reset Blank esté activado.

Solución: se activa Reset Blank donde deba aplicarse el valor alternativo, se añade validación de campos, se restablecen los elementos afectados y se vuelve a publicar. El código fuente renderizado debe contener el valor predeterminado o la modificación intencional de la página.

El mapa del sitio de SXA devuelve 404

Síntoma: /sitemap.xml no responde aunque Sitemap Mode esté activado.

Causa probable: falta TargetHostName o la definición del sitio apunta al host incorrecto.

Solución: se configura el nombre de host de destino correcto, se limpia la caché pertinente si es necesario y se vuelve a solicitar /sitemap.xml en el host de producción.

Cómo demostrar que un cambio de robots.txt en Sitecore es seguro

Obtener la respuesta publicada en producción

Prueba: después de editar y volver a publicar el campo de robots, se solicita directamente el /robots.txt activo de producción.

Resultado esperado: producción contiene las reglas explícitas de permitir/bloquear previstas y no vuelve al bloqueo general Disallow: /.

Interpretación de un fallo: se editó el elemento equivocado, no se publicó el cambio o el sitio activo sirve contenido en caché o predeterminado.

Periodo de monitorización: inmediatamente después de publicar y actualizar la caché.

Criterio de reversión: se restaura de inmediato el último valor de robots válido si la respuesta de producción bloquea todos los rastreadores u omite protecciones necesarias.

Comprobar la separación de entornos

Prueba: se obtiene /robots.txt en CM, QA, preproducción y el host de entrega de producción.

Resultado esperado: CM, QA y preproducción bloquean el rastreo; solo el host de producción previsto puede rastrearse.

Interpretación de un fallo: el elemento de robots, el destino de publicación o la configuración de sitio específica del host se comparten incorrectamente entre entornos.

Periodo de monitorización: inmediatamente después del cambio y tras la promoción entre entornos.

Criterio de reversión: se revierte si un entorno que no es de producción se vuelve rastreable o si producción hereda el bloqueo general de un entorno no productivo.

Confirmar el comportamiento que reciben los rastreadores

Prueba: se usa la inspección de URL de Search Console en una URL representativa de producción después de corregir la respuesta de robots.

Resultado esperado: la prueba en vivo puede obtener la página y el HTML renderizado contiene los metadatos y el contenido esperados.

Interpretación de un fallo: otro control de rastreo, una capa de autenticación o una respuesta de robots almacenada en caché todavía bloquea a Google.

Periodo de monitorización: la prueba en vivo se ejecuta de inmediato; debe permitirse el tiempo normal de rastreo antes de evaluar la recuperación en los informes.

Criterio de reversión: se revierten los cambios relacionados con el control de acceso si Google sigue bloqueado mientras las solicitudes públicas ordinarias parecen permitidas.

Herramientas para SEO en Sitecore

En Sitecore

• SXA (Sitecore Experience Accelerator): capa que genera mapas del sitio, gestiona robots.txt en el árbol de contenido y estandariza campos de metadatos. Es el conjunto SEO predeterminado para XP y XM Cloud.
• Sitecore Content Editor — reglas de validación de campos: exigen títulos y descripciones no vacíos y con longitud acotada para impedir que se publiquen campos vacíos.
• Next.js MetadataRoute / generateMetadata (XM Cloud): mapa del sitio, robots.txt y metadatos por página generados mediante código y obtenidos de Experience Edge con GraphQL.

Verificación en motores de búsqueda

• Google Search Console: permite verificar la indexación, inspeccionar el HTML renderizado —Inspección de URL—, enviar mapas del sitio y observar el informe de indexación de páginas.
• Bing Webmaster Tools: ofrece verificación y envío de mapas por separado; cobra mayor importancia en sitios headless porque Bing tarda más en renderizar JavaScript.

Auditoría y rastreo

• Ahrefs Site Audit y Screaming Frog SEO Spider: simulan un rastreo para detectar a escala alias duplicados, metadatos vacíos, cadenas de redirecciones y URL bloqueadas. Son esenciales en una instalación grande de Sitecore.
• Google Lighthouse: el propio Accelerate Cookbook de Sitecore lo recomienda para revisar velocidad de página y optimización en página.

Recursos recomendados

Artículos relacionados de Patrick Stox

• Enterprise SEO — limitaciones de recursos, complejidad organizativa y enlaces internos a escala: el entorno propio de Sitecore.
• Enterprise Sites Are Where Technical SEO Shines — sistemas heredados, varias pilas tecnológicas, propiedad dividida y canonicalización a escala empresarial.

Presentación de Patrick Stox

• How Search Works (SlideShare) — rastreo, renderizado, indexación y posicionamiento; la sección de renderizado es la más pertinente para Sitecore headless. Se conserva el descargo original: “This is my understanding of systems… not going to be 100% complete or accurate.” (esta es la interpretación del autor sobre los sistemas; no será completamente exhaustiva ni precisa).

Fuentes del sector

• SEO Best Practices for Sitecore | Konabos (Ken Gray, enero de 2024) — prácticas estructuradas, incluidos campos de metadatos y gestión de enlaces canónicos.
• Master Rendering in Next.js with Sitecore XM Cloud | Konabos (Akshay Sura, febrero de 2025) — desglose de SSG/SSR/ISR/CSR para SEO en XM Cloud.
• Optimizing Metadata and SEO in Next.js for Sitecore XM Cloud | Fishtank (David Austin, octubre de 2023) — análisis detallado del flujo generateMetadata.
• Sitecore SEO Best Practices | Fishtank (Marcel, agosto de 2018) — punto de partida de «prácticamente ninguna funcionalidad SEO» y enfoque del ciclo de vida.
• Impact of Sitecore Aliases on SEO | BugDebugZone (Dheer Rajpoot, julio de 2014) — mecanismo de contenido duplicado mediante alias.
• How to Customize Multilingual Features in Sitecore | kogifi (Jakub Koba, junio de 2025) — versiones de idioma, sustitución y hreflang.
• 10 SEO Tips for Your Sitecore Website | Codehouse (Peter Lambrou, diciembre de 2022) — recomendaciones prácticas, incluido el marcado de datos estructurados.

Evaluación: SEO en Sitecore

Cinco preguntas breves sobre los problemas SEO específicos de Sitecore y las diferencias entre plataformas. Las respuestas se seleccionan y luego se comprueban.

Registro de cambios