SEO para Shopware

TL;DR — Shopware es una plataforma de comercio electrónico creada en Alemania que incorpora muchas funciones de SEO: puede generar las URL de productos, crear el sitemap, gestionar etiquetas canónicas y configurar hreflang para varios idiomas. Hay dos aspectos clave: las funciones disponibles dependen de la versión de Shopware —algunas son recientes— y ciertas tareas, como resolver páginas duplicadas de variantes, todavía requieren un complemento o desarrollo.

Qué significa «SEO para Shopware»

Shopware es una plataforma de comercio electrónico con núcleo de código abierto. La versión actual es Shopware 6. A diferencia de Shopify o BigCommerce, que incluyen alojamiento, Shopware suele instalarse en infraestructura propia —o en la nube de Shopware—, lo que aporta más control y también más responsabilidad.

«SEO para Shopware» es el trabajo habitual para que los productos y las páginas de categorías puedan descubrirse, rastrearse, indexarse y posicionarse, aplicado a una tienda que usa Shopware. Merece una guía específica porque Shopware toma muchas decisiones de SEO de forma predeterminada: es necesario distinguir qué resuelve, qué deja pendiente y qué funciones solo aparecen en versiones suficientemente recientes.

Qué resuelve Shopware

• URL limpias. Shopware genera «URL de SEO» para productos y categorías mediante plantillas editables desde el panel de administración. El formato es configurable.
• Sitemap. Shopware genera un sitemap XML de productos y categorías, lo mantiene en https://yourdomain.com/sitemap.xml y solo requiere enviarlo a Google.
• Etiquetas canónicas. En categorías, Shopware selecciona automáticamente la URL principal correcta cuando un producto pertenece a más de una categoría.
• hreflang para idiomas. En tiendas multilingües, Shopware puede añadir las etiquetas que indican a Google qué versión lingüística mostrar, a partir de la configuración de «canal de ventas» y dominio.
• robots.txt —solo en versiones recientes—. Desde Shopware 6.7.1.0 puede editarse robots.txt desde el panel de administración.
• Datos estructurados —solo en versiones recientes—. Desde Shopware 6.7.9.0, Shopware puede emitir datos JSON-LD modernos para resultados enriquecidos de productos.

Qué sigue siendo responsabilidad de la tienda

• Completar títulos y descripciones. Shopware proporciona los campos, pero el texto debe redactarse. No existe una función nativa para configurarlos masivamente mediante un patrón en miles de productos.
• Gestionar páginas duplicadas de variantes. Cada variante de producto —cada talla o color— obtiene su propia URL y suele tener una descripción casi idéntica, por lo que las variantes pueden competir entre sí. Shopware no lo resuelve por completo.
• Comprobar la versión. Como robots.txt y JSON-LD son incorporaciones recientes, las recomendaciones en línea pueden estar desactualizadas para una tienda o adelantarse a su versión.

El error más frecuente

Suele suponerse que, como Shopware «tiene buen SEO», todo está resuelto. Hay dos dificultades frecuentes. Primero, cambiar una plantilla de URL no actualiza las URL existentes hasta que se reconstruye el índice de SEO de Shopware, un paso fácil de olvidar. Segundo, al adoptar una arquitectura headless —un escaparate moderno con Vue/Nuxt—, casi ninguna configuración de SEO del panel se aplica de la misma forma: el equipo de desarrollo debe implementar el SEO en el nuevo frontend.

Para consultar la versión profesional —plantillas Twig exactas, corrección canónica de variantes, estrategias de sitemap, comandos de CLI, restricciones por versión y consideración headless—, debe abrirse la pestaña Avanzado.

TL;DR — Shopware 6 ofrece más SEO técnico nativo que la mayoría de las plataformas autoalojadas, pero lo «nativo» depende mucho de la versión. Las URL de SEO son plantillas Twig por tipo de entidad —producto, categoría y página de destino—, configurables globalmente o por canal de ventas; tras cambiar una plantilla debe reconstruirse el índice (dal:refresh:index) o las URL existentes no se actualizarán. El sistema canónico es independiente de las plantillas de URL: automático para categorías y semimanual para variantes —puede apuntarse una variante a otra como canónica, pero no directamente al producto principal sin modificar una plantilla—. El sitemap XML tiene tres estrategias de actualización —programada, en vivo y manual, con sitemap:generate para la manual— y Shopware excluye expresamente toda garantía de indexación. Antes de 6.7.1.0, robots.txt no tiene automatización —archivo manual y reescritura del servidor—; después, existe edición nativa por dominio desde el panel. En 6.7.9.0, los datos estructurados migraron de Microdata a JSON-LD tras la marca JSON_LD_DATA. hreflang procede del modelo Canal de ventas > Dominio, con una carencia entre canales de ventas que dio lugar a complementos de pago. La modalidad headless —Composable Frontends, Vue y Nuxt— traslada toda la lista de SEO a la capa de renderizado de Nuxt.

El marco: funciones nativas, restricciones por versión y trabajo pendiente

La mayoría del contenido sobre SEO para Shopware es un recorrido con capturas del panel o una presentación comercial de una agencia. Ninguno explica los dos aspectos decisivos: las funciones nativas de Shopware dependen de la versión y las carencias restantes son concretas y previsibles. Si cada tarea se clasifica en tres grupos —nativa y vigente, nativa solo en versiones recientes y todavía responsabilidad de la tienda—, la plataforma deja de resultar confusa.

Shopware presenta generosamente sus funciones nativas: afirma que la plataforma “includes many SEO features out of the box – from country- and language-specific URLs to meta data, hreflang, and performance optimizations, allowing you to build strong SEO without additional plugins.” (traducción) «incluye muchas funciones de SEO de forma predeterminada, desde URL específicas por país e idioma hasta metadatos, hreflang y optimizaciones de rendimiento, lo que permite crear un SEO sólido sin complementos adicionales». Es bastante cierto, con las salvedades de versión que se detallan más adelante y una lista breve de tareas —metadatos masivos, canónicos de variantes, hreflang entre canales y renderizado headless— que todavía requieren complementos o código.

Como Shopware es autoalojado y tiene un núcleo de código abierto, se diferencia de las plataformas alojadas. Shopify impone los prefijos /products/ y /collections/ y no permite editar robots.txt de forma nativa; BigCommerce ofrece un robots.txt editable y estructuras de URL personalizadas en una plataforma administrada. Shopware proporciona más control que ambas —pueden modificarse directamente las plantillas del escaparate—, pero exige asumir más responsabilidad por el resultado, incluido el alojamiento, la reconstrucción de índices y, en headless, la canalización de renderizado. Se parece más a Magento o una tienda WooCommerce autoalojada que a Shopify.

Estructura de URL: plantillas de URL de SEO

Las URL de SEO se encuentran en Settings > Shop > SEO y pueden configurarse por canal de ventas o globalmente. Existen tres tipos de entidad con plantillas independientes —páginas de detalle de producto, páginas de categorías y páginas de destino—, y las plantillas usan sintaxis Twig. La documentación de Shopware lo expresa así: “In the SEO settings you can define the structure for the SEO URLs of the product detail pages and categories. For this purpose you have a variety of variables at your disposal.” (traducción) «En la configuración de SEO puede definirse la estructura de las URL de SEO de las páginas de detalle de producto y categorías. Para ello hay diversas variables disponibles».

Aspectos importantes del funcionamiento:

• La plantilla de producto predeterminada es {{ product.name }} y hay más de 50 variables de producto disponibles —número de producto, EAN, fabricante, ruta de navegación/categorías, campos personalizados, fecha de lanzamiento y otras—.
• Las variables de varios niveles deben escribirse manualmente. El selector solo inserta el token principal incompleto; {{ product.translated.name }} debe completarse a mano.
• Los nombres largos pueden truncarse. Para un nombre de más de, por ejemplo, 50 caracteres, Shopware documenta {{ product.translated.name[:50] }} para abreviarlo en la URL.
• La categoría usa de forma predeterminada la ruta de navegación: {% for part in category.seoBreadcrumb %}{{ part }}/{% endfor %}.
• Los filtros Twig funcionan para normalizar, por ejemplo {{ product.translated.name|lower }}/{{ product.productNumber }}; Shopware señala que “in general you can use the available Twig filters.” (traducción) «en general pueden usarse los filtros Twig disponibles».
• La lógica condicional (IF) gestiona campos ausentes; la documentación ofrece un ejemplo para variantes con {% if product.canonicalProductId is not null %}.

La trampa más frecuente: “After you have made changes to the SEO template, it is necessary to rebuild the index so that the URLs are updated. You can do this from the console using the command php bin/console dal:refresh:index.” (traducción) «Después de cambiar la plantilla de SEO, es necesario reconstruir el índice para actualizar las URL. Puede hacerse desde la consola con el comando php bin/console dal:refresh:index». Editar una plantilla solo afecta a las URL generadas después; los productos existentes conservan sus slugs anteriores hasta reconstruir el índice. Si se cambia la plantilla y no ocurre nada, esta es la causa.

Internamente, las URL de SEO se guardan en la tabla seo_url con un concepto de URL dual: un path_info técnico —la ruta real— y un seo_path_info legible —el slug—, además de sales_channel_id, language_id, is_canonical y las marcas is_deleted/is_modified. El equipo de desarrollo añade rutas de URL de SEO personalizadas o dinámicas mediante una implementación de SeoUrlRouteInterface registrada con la etiqueta de contenedor shopware.seo_url.route. No es necesario en una tienda normal, pero explica el comportamiento a escala descrito más adelante.

Etiquetas canónicas

La canonicalización en Shopware es un mecanismo independiente de las plantillas de URL; es el aspecto más malinterpretado del SEO para Shopware. La documentación define el concepto igual que Google: “A canonical URL is the URL of the page that the search engine assumes is the most representative of several duplicated pages on your site.” (traducción) «Una URL canónica es la URL de la página que el buscador considera más representativa entre varias páginas duplicadas del sitio».

Deben distinguirse tres aspectos:

• Las categorías se canonicalizan automáticamente. Cuando un producto aparece en varias categorías —y, por tanto, en varias URL—, Shopware afirma que lo detecta y “automatically marks the correct URL, automatically preventing technical SEO issues.” (traducción) «marca automáticamente la URL correcta y evita problemas técnicos de SEO». Conviene verificar esta afirmación comercial en la tienda, aunque el comportamiento automático para categorías es real.
• Las variantes son solo semimanuales. Cada una obtiene su propia URL de SEO y el selector integrado “Variant for Canonical URL” permite designar una variante como destino canónico. No permite canonicalizar una variante directamente hacia el producto principal. Para resolverlo, se modifica product-detail/meta.html.twig —o se usa un complemento— de modo que las variantes apunten a la URL de SEO del producto principal cuando exista. Esta es la corrección cuando páginas de variantes casi duplicadas compiten entre sí.
• Existe un control global para redirecciones 301. En «Forwarding behavior», Shopware puede “output an HTTP 301 redirect when URLs are changed” (traducción) «emitir una redirección HTTP 301 cuando cambian las URL», en vez de mantener las URL antiguas activas tras editar una plantilla. Esta configuración se combina con la reconstrucción dal:refresh:index.

Esto coincide con la postura de Google: la canonicalización es una señal y las URL duplicadas de variantes o parámetros son normales en el comercio electrónico. Los mecanismos generales se explican en canonicalización; este artículo es su complemento específico para Shopware.

Sitemap XML

El sitemap se configura en Settings > Shop > Sitemap. Shopware “generates a standard sitemap that is compressed and cached in the file system” (traducción) «genera un sitemap estándar comprimido y almacenado en caché en el sistema de archivos» y, para catálogos grandes, “the sitemap is divided into several files and can be generated in the background” (traducción) «el sitemap se divide en varios archivos y puede generarse en segundo plano». Esta división mantiene cada archivo dentro de los límites de sitemaps.org y Google: 50 000 URL y 50 MB sin comprimir.

Existen tres estrategias de actualización, y la diferencia es importante:

1. scheduled — se genera automáticamente mediante una tarea programada con un intervalo definido.
2. live — se crea cuando no existe y vuelve a generarse una vez transcurrido el tiempo de actualización.
3. manually — la generación automática queda totalmente desactivada; “the sitemap will only be created if you call the following command manually: php bin/console sitemap:generate. In this case, it is necessary to run this command again each time a new URL is added or an old one is removed.” (traducción) «el sitemap solo se creará si se ejecuta manualmente el comando php bin/console sitemap:generate. En ese caso, es necesario volver a ejecutarlo cada vez que se añade una URL nueva o se elimina una antigua».

Hay dos aspectos que suelen pasarse por alto:

• La URL pública es sitemap.xml y no existe una página /sitemap para visitantes. Shopware lo aclara: “Shopware 6 does not provide a visitor sitemap (suffix /sitemap after your domain). The index file sitemap.xml is created for evaluation by Google.” (traducción) «Shopware 6 no proporciona un sitemap para visitantes —con el sufijo /sitemap después del dominio—. El archivo índice sitemap.xml se crea para que Google lo evalúe».
• Un sitemap no garantiza nada. Shopware declara expresamente que “cannot guarantee that every URL will be crawled and indexed. This always depends on the search engine provider.” (traducción) «no puede garantizar que todas las URL se rastreen e indexen; siempre depende del proveedor del buscador». Un sitemap facilita el descubrimiento, pero no promete indexación, igual que en cualquier otra plataforma.

Añadir o excluir URL personalizadas —además de productos y categorías— no es una opción del panel, sino trabajo de desarrollo mediante clases UrlProvider personalizadas, documentadas en las guías para desarrolladores de sitemaps de Shopware.

robots.txt: primero debe comprobarse la versión

Esta es la parte del SEO para Shopware más sensible a la versión, por lo que toda recomendación debe fecharse.

• Antes de 6.7.1.0 —la mayoría de instalaciones antiguas— no se genera nada automáticamente. La documentación indica que “the robots file is not created automatically in Shopware 6, but has to be created manually as a text file” (traducción) «el archivo robots no se crea automáticamente en Shopware 6, sino que debe crearse manualmente como archivo de texto» en /public/. En configuraciones multidominio se sirve un archivo por dominio mediante una reescritura del servidor: Apache RewriteRule ^robots\.txt$ robots/%{HTTP_HOST}.txt [NS] o el equivalente de NGINX rewrite ^/robots\.txt$ /robots/$host.txt, que apuntan a una estructura /public/robots/<domain>.txt.
• Desde 6.7.1.0 —versión de julio de 2025— existe gestión nativa de robots.txt por dominio desde el panel: “can define individual robots.txt rules for each domain in the Admin under Settings > General > Basic information.” (traducción) «pueden definirse reglas individuales de robots.txt para cada dominio en el panel, en Settings > General > Basic information». Comenzó como una contribución comunitaria de Hacktoberfest 2024.

Por tanto, el mito “Shopware doesn’t let you edit robots.txt” (traducción) «Shopware no permite editar robots.txt» solo es cierto antes de 6.7.1.0. Debe confirmarse la versión antes de recomendar que se edite desde el panel; las tiendas antiguas todavía necesitan un archivo manual y una reescritura. El campo del panel —«Rules for robots.txt», en Settings > General > Basic information— es un área de texto libre que se integra directamente en el robots.txt del dominio, por lo que admite bloques completos User-agent: / Allow: / Disallow:, no solo reglas simples. Esto está confirmado en la documentación vigente y en una corrección de 6.7.10.0 —avoid duplicate robots.txt directives for user-agent blocks— que reproduce específicamente el error con bloques por agente de usuario en ese campo.

Datos estructurados: migración de Microdata a JSON-LD

En 6.7.9.0, Shopware realizó un cambio importante de arquitectura: el escaparate pasó de Microdata en línea y disperso a JSON-LD emitido como un bloque <script type="application/ld+json"> en <head>. La función depende de la marca JSON_LD_DATA y está desactivada de forma predeterminada. Al activarla, se inyecta JSON-LD y se retira el Microdata anterior, que está obsoleto y se eliminará en 6.8.0.0.

Al activar la marca, la salida JSON-LD es mucho más completa que el Microdata anterior:

• Product —todas las imágenes del producto; VideoObject para videos; AggregateRating con ratingCount; hasta los 10 elementos Review más recientes; OfferShippingDetails/ShippingDeliveryTime para productos con un solo precio; Dimensions como QuantitativeValue; itemCondition; información estructurada de quien vende; y gtin13 —EAN— / mpn cuando estén disponibles.
• WebSite con SearchAction, que habilita el cuadro de búsqueda de enlaces de sitio de Google.
• Organization en el nivel superior, con el logotipo de la tienda.
• ItemList en páginas de categorías y resultados de búsqueda, además de BreadcrumbList.

Cada tipo de schema se encuentra en su propia plantilla Twig modificable bajo storefront/layout/structured-data/. La misma versión 6.7.9.0 añadió campos Open Graph por producto en la pestaña de SEO del panel —og:title, og:description y og:image personalizados— que usan como valores predeterminados el metatítulo, la metadescripción y la imagen de portada del producto. Así, los recursos compartidos en redes y ciertas vistas previas de resultados pueden diferir deliberadamente de las metaetiquetas sin usar un complemento.

La conclusión práctica desmiente un mito. Muchas publicaciones profesionales y extensiones de pago de la tienda —«JSON-LD Rich Snippets for product pages»— son anteriores a la función nativa. En 6.7.9.0 o posterior debe comprobarse si todavía se necesita ese complemento antes de comprarlo; en versiones anteriores sí puede aportar valor. Las directrices de datos estructurados de producto de Google son la especificación objetivo, y Google exige que los datos estructurados reflejen el contenido visible, por lo que deben completarse los campos que se desee incluir en el marcado.

SEO internacional: hreflang mediante Canal de ventas + Dominio

Shopware no tiene un editor independiente de hreflang. hreflang se deriva del modelo Canal de ventas > Dominio: cada canal de ventas puede tener varios dominios y cada uno se asigna a un idioma, una moneda, un conjunto de fragmentos y un sistema de unidades, configurado con su “own virtual URL, language, currency, snippet set and its own unit system.” (traducción) «propia URL virtual, idioma, moneda, conjunto de fragmentos y sistema de unidades».

Dos configuraciones realizan el trabajo de SEO:

• Un selector de modo de localización con dos opciones: ISO standard, “useful, for example, if you use different (country-specific) language variants that may use their own country-specific terms,” (traducción) «útil, por ejemplo, si se emplean variantes lingüísticas específicas de distintos países que pueden usar términos propios», que produce códigos completos de región e idioma como en-US y en-GB; y localización por browser language, que solo usa el idioma —en—. ISO standard debe usarse cuando realmente existan variantes regionales.
• Un dominio predeterminado que, tras activar la metaetiqueta hreflang, “will serve as a fallback for all languages” (traducción) «servirá como alternativa para todos los idiomas»: la versión de Shopware del x-default de Google.

La limitación conocida es que esto funciona dentro de los dominios de un solo canal de ventas, pero el hreflang entre canales de ventas —canales separados por país o TLD con catálogos casi duplicados— no se enlaza de forma nativa. Esa carencia explica la existencia de extensiones de pago como «Hreflang Manager». Conviene tratarla como una señal sólida de la comunidad y el mercado, no como una limitación documentada por Shopware, aunque aparece con frecuencia en los foros.

La documentación de Shopware tampoco indica un requisito de Google: hreflang debe ser bidireccional —etiquetas de retorno— e incluir x-default. Los mecanismos generales están en hreflang. La configuración de dominio predeterminado de Shopware resuelve x-default, pero todavía deben verificarse las etiquetas de retorno.

Headless: Composable Frontends —Shopware Frontends—

La opción headless es «Shopware Frontends» —antes «Composable Frontends» o «PWA»—, un conjunto de herramientas Vue.js + Nuxt que consume la Store API de Shopware y se diferencia del escaparate Twig/Symfony predeterminado. Incluye una biblioteca de componentes, un cliente de API, «composables» reutilizables y tipos TypeScript generados; la tienda de referencia «Vue Demo Store» usa Nuxt + Tailwind.

Aquí aparece el aspecto que otras guías suelen omitir: adoptar headless traslada prácticamente toda la responsabilidad del SEO a la capa de Nuxt y la configuración del panel deja de aplicarse de la misma forma. Las plantillas de URL de SEO, los ajustes canónicos, el control del sitemap y el nuevo panel de robots.txt son funciones del escaparate Symfony —Twig—. Una implementación de Composable Frontends necesita:

• Un modo de renderizado que produzca HTML rastreable: SSR de Nuxt —o renderizado híbrido, ISR o perimetral— para páginas relevantes para SEO. Una aplicación SPA renderizada solo en el cliente reintroduce el riesgo clásico del SEO para JavaScript. Headless no mejora automáticamente el SEO; un escaparate mal configurado puede ser peor que el predeterminado con Twig.
• Generación de sitemap, etiquetas canónicas, datos estructurados e inyección de metaetiquetas implementadas en la aplicación Nuxt —normalmente con sus «composables» de head o metadatos de SEO—, que por lo general siguen obteniendo slugs y datos de producto desde las mismas URL de SEO o Store API de Shopware.

Por tanto, el mito “going headless with Shopware fixes/improves SEO” (traducción) «adoptar headless con Shopware corrige o mejora el SEO» es falso tal como está formulado. El resultado depende por completo de cómo se configure el renderizado en Nuxt. Es la misma trampa de cualquier implementación headless; la versión independiente de la plataforma se explica en SEO para JavaScript y SEO para CMS headless.

Problemas frecuentes a escala

Los problemas profesionales se concentran en tres áreas:

• Configuraciones predeterminadas incorrectas. Las auditorías profesionales advierten que «Remove Category ID from URL» viene en No de forma predeterminada —conviene activarlo para lograr URL más limpias—, que las señales de paginación están desactivadas y que es aconsejable aplicar noindex a páginas paginadas de blogs y archivos porque “add no value; they only take up crawl budget.” (traducción) «no aportan valor y solo consumen presupuesto de rastreo». Otra afirmación muy repetida —que Shopware añade automáticamente nofollow a todos los enlaces externos— debe verificarse en una instalación real antes de repetirse, porque no se confirmó en la documentación oficial.
• Contenido duplicado de variantes de productos. Es la queja más recurrente. Cada variante obtiene una URL propia —/SW10000.1, /SW10000.2, …— con descripciones heredadas casi idénticas, por lo que compiten salvo que se canonicalicen. Como se explicó antes, el selector integrado no puede apuntar directamente al producto principal sin modificar una plantilla.
• Crecimiento de la tabla seo_url en catálogos multilingües grandes. El número de filas sigue aproximadamente (producto principal + variantes activas) × cantidad de idiomas. Un análisis profesional calcula unas 153 filas para una familia con 9 variantes en 17 idiomas. Los cambios frecuentes de plantillas multiplican además las filas históricas. A escala, las correcciones son generar URL de SEO solo para productos principales —no para cada variante—, depurar periódicamente filas eliminadas lógicamente o no canónicas y añadir índices compuestos. Esto explica por qué una tienda Shopware grande puede volverse lenta y acumular URL de SEO duplicadas extrañas.

Cuándo bastan las funciones nativas y cuándo se necesita un complemento o desarrollo

El umbral aproximado que señalan las fuentes profesionales es que las funciones nativas bastan para catálogos pequeños y sencillos —del orden de unos cientos de productos— y los complementos o el desarrollo personalizado se vuelven necesarios a una escala considerable: miles de SKU, matrices profundas de variantes, muchos idiomas o configuraciones internacionales entre canales de ventas. Se necesita un complemento o código para patrones masivos de títulos/metadatos, canónicos de variantes hacia el producto principal, hreflang entre canales, entradas personalizadas del sitemap o JSON-LD en versiones anteriores a 6.7.9.0. El resto —plantillas de URL de SEO, canónicos de categorías, sitemap, hreflang multidominio en un solo canal y, en versiones actuales, robots.txt y JSON-LD— es nativo.

Shopware frente a plataformas alojadas: comparación realista

Todas pueden posicionarse bien. La ventaja real de Shopware es el control: URL mediante plantillas Twig, plantillas del escaparate modificables y un gran conjunto de funciones nativas que crece con cada versión. El costo real es que se asume una mayor parte de la canalización: alojamiento, reconstrucción de índices, conocimiento de versiones y, en headless, toda la capa de renderizado y etiquetas de SEO. Al igual que Magento y WooCommerce autoalojado, y a diferencia de los valores predeterminados más sencillos de Shopify o PrestaShop, este intercambio favorece a equipos con capacidad de desarrollo.

Resumen de IA

Versión condensada de la perspectiva Avanzado:

• Shopware 6 es una plataforma de comercio electrónico autoalojada con núcleo de código abierto —Symfony/PHP + escaparate Vue.js— y muchas funciones nativas de SEO. Ofrece más control que Shopify o BigCommerce, pero obliga a asumir una mayor parte de la canalización.
• Las funciones nativas dependen de la versión. robots.txt por dominio solo existe desde 6.7.1.0 —el campo del panel es texto libre y acepta bloques User-agent:, no solo reglas simples—. Los datos estructurados JSON-LD —que sustituyen Microdata— y los campos Open Graph por producto aparecen desde 6.7.9.0, con la marca JSON_LD_DATA para JSON-LD —Microdata se elimina en 6.8.0.0—. Siempre debe comprobarse la versión de la tienda antes de recomendar.
• Las URL de SEO son plantillas Twig por tipo de entidad —producto, categoría y página de destino— en Settings > Shop > SEO. Cambiar una plantilla → reconstruir el índice (php bin/console dal:refresh:index) o las URL existentes no se actualizarán.
• El sistema canónico es independiente: automático para categorías; en variantes puede designarse una variante como canónica, pero no puede apuntarse directamente al producto principal sin modificar product-detail/meta.html.twig. El control global «Forwarding behavior» emite redirecciones permanentes cuando cambia una URL.
• Sitemap: tres estrategias —scheduled, live y manual, con php bin/console sitemap:generate—; URL pública sitemap.xml; no existe página /sitemap para visitantes; Shopware excluye toda garantía de indexación.
• hreflang procede del modelo Canal de ventas > Dominio —un dominio equivale a un idioma y una moneda—, con selector ISO standard o browser language y dominio predeterminado como x-default. El hreflang entre canales de ventas no se enlaza de forma nativa; ese vacío lo cubren complementos de pago.
• Headless —Composable Frontends, Vue + Nuxt— traslada toda la lista de SEO —sitemap, canónico, metadatos y datos estructurados— a la capa de renderizado de Nuxt. La configuración de SEO del panel no se aplica y una implementación headless deficiente puede ser peor para el SEO.
• Problemas a escala: contenido duplicado de variantes, crecimiento de la tabla seo_url —aproximadamente variantes × idiomas— y configuraciones predeterminadas incorrectas —ID de categoría en URL y señales de paginación—. Las funciones nativas bastan para catálogos pequeños; a escala se necesitan complementos o desarrollo.

Documentación oficial

Documentación de fuentes primarias de Shopware y Google.

Shopware

• SEO settings (SEO URL templates, canonical, forwarding behavior) — página principal de SEO del panel; variables Twig, truncamiento, filtros y nota sobre la reconstrucción dal:refresh:index.
• Sitemap settings — las tres estrategias de actualización, sitemap:generate, la URL sitemap.xml y la exclusión de garantía de indexación.
• Sales channel (domains / hreflang) — modelo Canal de ventas > Dominio, modos de localización de hreflang y alternativa del dominio predeterminado.
• Creation of robots.txt (legacy / manual method) — método anterior a 6.7.1.0 con archivo manual y reescritura del servidor.
• Add Custom SEO URLs (developer) — tabla seo_url, SeoUrlRouteInterface y etiqueta de contenedor shopware.seo_url.route.
• Sitemap plugin guide (developer) — clases UrlProvider personalizadas para añadir o retirar entradas del sitemap.
• Release notes 6.7.1.0 (native robots.txt) — versión que añadió robots.txt por dominio en el panel.
• Release notes 6.7.9.0 (JSON-LD structured data) — migración de Microdata a JSON-LD, marca JSON_LD_DATA y tipos de schema.
• Shopware Frontends (headless docs) y Nuxt module — conjunto de herramientas Composable Frontends con Vue + Nuxt.
• SEO in Shopware (marketing overview) — resumen de Shopware sobre sus funciones nativas de SEO.

Google

• Product structured data — campos Product obligatorios y recomendados a los que se dirige la salida JSON-LD.
• Structured data intro — motivos para recomendar JSON-LD sobre microdata.
• URL canonicalization — planteamiento de «señal, no regla» que sustenta la gestión canónica de Shopware.
• Managing multi-regional and multilingual sites (hreflang) — requisitos de etiquetas de retorno bidireccionales y x-default que corresponden al dominio predeterminado de Shopware.

Citas de la fuente

Declaraciones públicas de la documentación y el material comercial de Shopware. Cada enlace lleva al pasaje citado.

Shopware — plantillas de URL de SEO —documentación—

• “In the SEO settings you can define the structure for the SEO URLs of the product detail pages and categories. For this purpose you have a variety of variables at your disposal.” (traducción) «En la configuración de SEO puede definirse la estructura de las URL de SEO de las páginas de detalle de producto y categorías. Para ello hay diversas variables disponibles». Ir a la cita
• “After you have made changes to the SEO template, it is necessary to rebuild the index so that the URLs are updated. You can do this from the console using the command php bin/console dal:refresh:index.” (traducción) «Después de cambiar la plantilla de SEO, es necesario reconstruir el índice para actualizar las URL. Puede hacerse desde la consola con el comando php bin/console dal:refresh:index». Ir a la cita

Shopware — canónico —documentación—

• “A canonical URL is the URL of the page that the search engine assumes is the most representative of several duplicated pages on your site.” (traducción) «Una URL canónica es la URL de la página que el buscador considera más representativa entre varias páginas duplicadas del sitio». Ir a la cita

Shopware — sitemap —documentación—

• “Shopware 6 does not provide a visitor sitemap (suffix /sitemap after your domain). The index file sitemap.xml is created for evaluation by Google.” (traducción) «Shopware 6 no proporciona un sitemap para visitantes —con el sufijo /sitemap después del dominio—. El archivo índice sitemap.xml se crea para que Google lo evalúe». Ir a la cita
• “Shopware cannot guarantee that every URL will be crawled and indexed. This always depends on the search engine provider.” (traducción) «Shopware no puede garantizar que todas las URL se rastreen e indexen; siempre depende del proveedor del buscador». Ir a la cita
• Sobre el modo manual: “the sitemap will only be created if you call the following command manually: php bin/console sitemap:generate.” (traducción) «el sitemap solo se creará si se ejecuta manualmente el comando php bin/console sitemap:generate». Ir a la cita

Shopware — robots.txt —documentación—

• “The robots file is not created automatically in Shopware 6, but has to be created manually as a text file.” (traducción) «El archivo robots no se crea automáticamente en Shopware 6, sino que debe crearse manualmente como archivo de texto». —Método heredado, anterior a 6.7.1.0—. Fuente

Shopware — SEO nativo —material comercial—

• “Shopware includes many SEO features out of the box – from country- and language-specific URLs to meta data, hreflang, and performance optimizations, allowing you to build strong SEO without additional plugins.” (traducción) «Shopware incluye muchas funciones de SEO de forma predeterminada, desde URL específicas por país e idioma hasta metadatos, hreflang y optimizaciones de rendimiento, lo que permite crear un SEO sólido sin complementos adicionales». Fuente

Lista de auditoría de SEO específica para Shopware

Revisión adaptada al funcionamiento real de Shopware, no una lista genérica de comercio electrónico.

Comprobación de versión —debe hacerse primero—

• Registrar la versión exacta de Shopware; determina qué es nativo.
• robots.txt: en 6.7.1.0 o posterior, gestionarlo por dominio en Settings > General > Basic information; en versiones anteriores, confirmar un /public/robots.txt manual —con reescritura del servidor por dominio si hay varios—.
• Datos estructurados: en 6.7.9.0 o posterior, decidir si se activa la marca JSON_LD_DATA; en versiones anteriores, comprobar si todavía se necesita un complemento JSON-LD.

Estructura de URL

• Plantillas de URL de SEO definidas deliberadamente por tipo de entidad —producto, categoría y página de destino— en Settings > Shop > SEO, en vez de conservar sin revisión el valor predeterminado.
• Índice reconstruido después de cada cambio de plantilla —php bin/console dal:refresh:index— para actualizar realmente las URL existentes.
• Opción «Remove Category ID from URL» revisada —su valor predeterminado es No—.
• Opción «Forwarding behavior» configurada para emitir una redirección 301 al cambiar una URL, en vez de mantener activas las antiguas.

Canónicos y variantes

• Canonicalización de categorías confirmada como correcta —es automática, pero debe verificarse—.
• Contenido duplicado de variantes resuelto mediante «Variant for Canonical URL» o una modificación de product-detail/meta.html.twig o un complemento que canonicalice las variantes hacia el producto principal.

Sitemap

• Estrategia de actualización elegida deliberadamente —scheduled, live o manual—; en la manual, php bin/console sitemap:generate se ejecuta cada vez que cambian las URL.
• sitemap.xml enviado a Google Search Console y Bing Webmaster Tools.

Internacional —varios idiomas o dominios—

• hreflang activado con el modo de localización correcto —ISO standard para variantes regionales; browser language en los demás casos—.
• Dominio predeterminado configurado como alternativa x-default.
• Etiquetas de retorno verificadas como bidireccionales; en configuraciones entre canales de ventas, comprobada la carencia de enlace nativo —complemento si es necesario—.

Escala y rendimiento

• En catálogos multilingües grandes, URL de SEO generadas solo para productos principales cuando sea posible, filas de seo_url eliminadas lógicamente o no canónicas depuradas e índices compuestos considerados.
• Páginas paginadas de blogs o archivos con noindex cuando no aportan valor.

Headless —solo Composable Frontends—

• El modo de renderizado de Nuxt produce HTML rastreable —SSR, híbrido o ISR; no solo CSR—.
• Sitemap, canónico, metaetiquetas y datos estructurados implementados en la aplicación Nuxt —la configuración de SEO del panel no se transfiere—.

Modelos mentales

1. Tres grupos, no dos, debido a las versiones. Cada tarea de SEO para Shopware debe clasificarse como nativa y vigente, nativa solo en una versión reciente —robots.txt ≥ 6.7.1.0 y JSON-LD ≥ 6.7.9.0— o todavía responsabilidad de la tienda —metadatos masivos, canónico de variante hacia producto principal, hreflang entre canales y renderizado headless—. La versión es el grupo que suele provocar errores; siempre debe comprobarse antes de confiar en una recomendación.

2. Las plantillas generan; el índice publica. Editar una plantilla de URL de SEO solo cambia las URL futuras. Nada se publica hasta ejecutar la reconstrucción —dal:refresh:index—. Cuando un cambio de plantilla parece no funcionar, esto es lo primero que debe comprobarse.

3. El sistema canónico es independiente de las URL. Los canónicos de Shopware no deben analizarse mediante las plantillas de URL; son mecanismos distintos. Las categorías se canonicalizan automáticamente; las variantes son semimanuales y no pueden llegar al producto principal sin modificar una plantilla. Ambos sistemas deben mantenerse separados en el análisis.

4. hreflang reside en el modelo de dominios. No existe un editor de hreflang: es una consecuencia de la estructura de Canales de ventas y Dominios. Un dominio equivale a un idioma y una moneda; el dominio predeterminado es x-default. Si hreflang es incorrecto, debe revisarse la configuración del dominio, no buscar un campo hreflang.

5. Headless reinicia toda la lista. Al adoptar Composable Frontends, la configuración de SEO del panel deja de ser la fuente de verdad: sitemap, canónico, metadatos y datos estructurados pasan a Nuxt. Headless no es «la misma lista de SEO, pero más rápida», sino una lista diferente bajo responsabilidad del frontend.

Hoja de referencia rápida de SEO para Shopware

Ubicación en el panel

Restricciones por versión

Comandos de CLI

Estrategias de sitemap

Prácticas que deben evitarse

• Cambiar una plantilla de URL y esperar que las URL existentes se actualicen sin reconstruir el índice.
• Suponer que «Variant for Canonical URL» apunta las variantes al producto principal; no lo hace.
• Recomendar editar robots.txt desde el panel sin comprobar que la versión sea 6.7.1.0 o posterior.
• Comprar un complemento JSON-LD en 6.7.9.0 o posterior sin comprobar antes la marca nativa.
• Suponer que headless —Composable Frontends— hereda la configuración de SEO del panel.

Errores de SEO para Shopware que deben evitarse

Editar una plantilla de URL de SEO sin reconstruir el índice

Por qué es incorrecto: las URL existentes conservan los valores generados anteriormente, por lo que el cambio del panel parece no tener efecto. Qué debe hacerse: ejecutar php bin/console dal:refresh:index, rastrear después URL antiguas y nuevas de productos y confirmar el comportamiento de redirección.

Suponer que Variant for Canonical URL apunta al producto principal

Por qué es incorrecto: el selector nativo designa otra variante, no el producto principal. Por tanto, las variantes casi idénticas pueden seguir divididas entre varias URL. Qué debe hacerse: modificar product-detail/meta.html.twig o usar un complemento adecuado cuando el producto principal sea el canónico previsto.

Dar recomendaciones sobre robots.txt sin considerar la versión

Por qué es incorrecto: la gestión de robots.txt por dominio desde el panel comienza en 6.7.1.0; las tiendas antiguas requieren un archivo y una reescritura del servidor. Qué debe hacerse: registrar la versión exacta de Shopware antes de elegir la implementación.

Comprar un complemento JSON-LD sin comprobar la función nativa

Por qué es incorrecto: Shopware 6.7.9.0 incorporó JSON-LD nativo tras la marca JSON_LD_DATA. Una segunda fuente puede duplicar el marcado existente o entrar en conflicto con él. Qué debe hacerse: comprobar la versión y la marca, validar la salida actual y cubrir únicamente carencias reales.

Esperar que la configuración de SEO del panel se transfiera a un escaparate headless

Por qué es incorrecto: Composable Frontends traslada a Nuxt el renderizado, los metadatos, los canónicos, los sitemaps y los datos estructurados. Qué debe hacerse: tratar headless como una nueva implementación de SEO del frontend y verificar de forma independiente su respuesta del servidor.

Demostrar que un cambio de plantilla de URL de SEO surtió efecto

Reconstruir e inspeccionar URL representativas

Prueba: después de guardar la plantilla, ejecutar php bin/console dal:refresh:index y abrir URL representativas de productos, categorías y páginas de destino afectadas.

Resultado esperado: las entidades existentes usan el nuevo patrón de URL de SEO, no solo los elementos creados después del cambio.

Interpretación del fallo: la reconstrucción del índice no terminó, se cambió la plantilla de un canal de ventas incorrecto o la ruta usa una plantilla de entidad diferente.

Ventana de supervisión: inmediatamente después de que termine el comando del índice y se actualicen las cachés.

Criterio de reversión: restaurar la plantilla anterior y reconstruir otra vez si el nuevo patrón crea colisiones, rutas ausentes o rutas con formato incorrecto.

Confirmar que las URL antiguas conservan su destino

Prueba: solicitar una muestra de las URL de SEO anteriores después de la reconstrucción e inspeccionar el estado HTTP y el encabezado Location.

Resultado esperado: cada URL antigua modificada devuelve la redirección permanente configurada hacia la nueva URL canónica correspondiente.

Interpretación del fallo: el comportamiento de redirección está desactivado, no se conservó la ruta anterior o dos reglas de URL entran en conflicto.

Ventana de supervisión: inmediatamente después del despliegue; repetir tras invalidar la caché.

Criterio de reversión: revertir si URL antiguas importantes devuelven 404, forman bucles o cadenas, o redirigen al producto o la categoría equivocados.

Verificar la concordancia entre canónico y sitemap

Prueba: inspeccionar la etiqueta canónica de la página nueva y localizar la entidad en sitemap.xml después de ejecutar la estrategia de actualización del sitemap.

Resultado esperado: ambas señales indican la misma URL de SEO nueva.

Interpretación del fallo: la configuración canónica, la generación del sitemap y el índice de URL no están sincronizados.

Ventana de supervisión: inmediata para el canónico; después de la regeneración programada, en vivo o manual para la salida del sitemap.

Criterio de reversión: revertir la publicación de URL si las páginas canónicas apuntan a destinos antiguos o ausentes después de regenerar.

Herramientas para el SEO de Shopware

• Shopware Console —bin/console—: los dos comandos que ejecutan realmente funciones de SEO de Shopware son dal:refresh:index —reconstruye las URL de SEO tras cambiar una plantilla— y sitemap:generate —genera manualmente el sitemap—.
• Google Search Console: envío de sitemap, Inspección de URL —para verificar el canónico elegido por Google y cómo se renderizan las páginas de variantes— y vista de Segmentación internacional / hreflang. Es la referencia de lo que Google hace realmente.
• Bing Webmaster Tools: segundo envío del sitemap, control de rastreo y análisis del sitio.
• Screaming Frog / Ahrefs Site Audit: rastreo de la tienda para detectar la proliferación de URL de variantes, duplicados de seo_url a escala, comportamiento de redirecciones tras cambiar plantillas y páginas ausentes del sitemap. Así se encuentran las carencias específicas de Shopware.
• Rich Results Test / Schema Markup Validator: confirma que la salida JSON-LD de 6.7.9.0 sea válida y coincida con el contenido visible tras activar JSON_LD_DATA.
• Extensiones de Shopware Store: cubren carencias nativas como gestores de hreflang entre canales de ventas, gestores masivos de metadatos o URL de SEO, proveedores avanzados de sitemap y, en tiendas anteriores a 6.7.9.0, complementos JSON-LD para resultados enriquecidos.
• Modificaciones de plantillas del escaparate: para corregir el canónico de variantes, modificar product-detail/meta.html.twig en vez de recurrir a un complemento cuando exista capacidad de desarrollo.

Recursos útiles

Relacionados en el sitio

• Canonicalización — mecanismos independientes de la plataforma que sustentan el comportamiento canónico automático para categorías y manual para variantes de Shopware.
• hreflang — requisitos de etiquetas de retorno bidireccionales y x-default a los que corresponde el modelo Canal de ventas / dominio predeterminado de Shopware.
• SEO para JavaScript y SEO para CMS headless — motivos por los que una implementación de Composable Frontends —Nuxt— necesita su propia disciplina de SSR y renderizado.

Documentación oficial de Shopware

• SEO settings, Sitemap settings y Sales channel / domains.
• Release notes 6.7.1.0 (robots.txt) y 6.7.9.0 (JSON-LD).
• Shopware Frontends (headless).

Fuentes del sector

• Conductor Academy — Shopware SEO best practices — lista profesional de problemas de configuración predeterminada —ID de categoría en URL, señales de paginación y noindex en páginas paginadas de blogs—.
• BrocksiNet — Deep dive into Shopware SEO URLs — funcionamiento interno de la tabla seo_url y cálculo del crecimiento variantes × idiomas.
• EXWE — SEO optimization in Shopware 6: canonicals for product variants — problema canónico de variantes y corrección mediante modificación de plantilla.
• elgentos — shopware-seo-canonical-url (GitHub) — complemento de código abierto para canonicalizar variantes hacia el producto principal.
• Qualimero — Shopware SEO guides — cobertura vigente para el mercado europeo y alemán sobre SEO y preparación para IA en Shopware.
• Kickbyte — Shopware Frontends: headless storefront with Nuxt — influencia de la capa Nuxt en el SEO headless.
• Shopware — SEO in Shopware (marketing overview) — resumen del proveedor sobre sus funciones nativas de SEO.

Autoevaluación: SEO para Shopware

Cinco preguntas breves sobre el funcionamiento del SEO en Shopware 6. Debe elegirse una respuesta y comprobarla.

Registro de cambios