Shopware themes
When a Shopware 6 shop ranks poorly, loads slowly or never appears in the answers of ChatGPT, Perplexity and Google’s AI Overviews, the cause is often neither the product range nor the copy, but the theme — the markup the storefront delivers to every visitor and every crawler. Headings that are only styling. Content that only comes into being through JavaScript. Product facts without machine-readable markup. A slider that sets the load time. A theme refresh fixes this without rebuilding the shop and usually without a new design. Sharpness Solutions GmbH from Oldenburg is a Shopware Extension Partner and reworks existing themes, including ones built by others and ones bought in the store — with measurements before and after. Telephone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET).
The symptoms show up in different places: in Google Search Console, in PageSpeed Insights, in a test question to ChatGPT or simply in revenue from organic search. The cause often sits in a single place — in the source code the theme delivers. These six findings come up again and again when we review existing Shopware shops. An additional SEO plugin fixes few of them; all of them can be fixed in the theme.
The theme marks up the logo or the first slider title as the H1, on every single page. The name of the category or product sits below it as an H3 or as a bold paragraph, because the size happened to fit. To visitors it looks right. To search engines, screen readers and language models, every page carries the same title.
Description, properties or reviews only appear after a click or are loaded via JavaScript. You can see them in the browser; they are missing from the delivered source. Google renders JavaScript but does not click; some AI crawlers do not run JavaScript at all. What is missing there does not get cited.
The price is large on the product page but missing from the structured data — or it appears there twice with different values, once from the template and once from an SEO plugin. Availability, delivery time and shipping costs are text, not markup. A search engine can show the product but cannot compare it.
The largest visible element is an image from the homepage slider that only loads after the slider’s script. Web fonts arrive late and reflow the lines. Cookie banner, chat, review widget and tracking run on every page, even where nobody needs them. Each cause on its own is small. Together they add up to red Core Web Vitals.
Addresses with filter, sort and page parameters end up in the index or flagged as duplicates in Search Console, while the actual category page falls behind. Canonicals point to the wrong version or are missing. With several languages or sales channels, hreflang is missing or not reciprocal. Where the addresses come from — theme, plugin or external links — only becomes clear from the source code and the logs.
At some point whole storefront templates were copied into the custom theme instead of overriding individual Twig blocks. It looked quicker at the time. Today no update reaches those pages any more: the copy keeps the old structure, whatever Shopware changes. Since Shopware 6.7 and its accessibility overhaul of the storefront this shows clearly — markup, ARIA attributes and block structure have changed, the copy has not.
A theme refresh reworks the markup your Shopware theme delivers — headings, HTML structure, structured data, images, fonts, scripts — and leaves everything else as it is. Products, categories, customers and orders are untouched, the addresses stay the same, and the design changes only where a change in the markup requires it. The reason for this scope is simple: a crawler does not see design. It sees what is in the HTML, in what order and how fast. That is exactly where the refresh starts.
The refresh also covers what other extensions write into the storefront. Every plugin that displays something — reviews, trust badges, cross-selling, cookie notice, chat — brings its own markup, scripts and styles, and the theme is where all of it comes together as one page. We therefore do not review the theme in isolation but the delivered page for each page type. And we say so when the cause lies elsewhere: a server that needs two seconds to the first byte will not be made fast by any theme, and thin product copy does not get longer through clean markup.
A refresh also tidies up the inheritance, because it decides whether the improvements survive the next update. A healthy Shopware theme is a custom theme that inherits from the default theme and overrides only the Twig blocks it needs to change — with sw_extends, block by block. A theme that has copied whole templates keeps their old state, whatever Shopware changes. Shopware 6.7 made this concrete: the accessibility overhaul changed markup, ARIA attributes and block structure in the storefront, pagination now runs on links instead of radio inputs, and header and footer load via ESI. A copy notices none of this. That is why the refresh rebuilds copied templates as targeted block overrides.
The H1 of a page names what that page is about: the category on a category page, the product on a product page, the shop on the homepage. The logo is a link to the homepage, not a heading; slider titles and teaser lines are design, not structure. Below that, H2 and H3 follow the structure of the content, not the desired font size — that is what CSS is for. Screen readers need the same order, and for most online shops selling to consumers in Germany it has been part of the requirements of the Accessibility Strengthening Act (BFSG) since 28 June 2025. We fix the hierarchy for each page type in the theme so that it is not renegotiated in every Shopping Experience.
Whatever is meant to be cited has to be in the delivered HTML. Text in tabs is no problem as long as it is in the source when the page loads and is merely collapsed visually. The trouble is content that is loaded via JavaScript only after a click or in an off-canvas panel: Google renders JavaScript but does not click, and not every AI crawler runs JavaScript at all. For each page type we therefore compare the raw source with the rendered page and move the content that matters — product description, properties, delivery information, the key internal links — into what the server delivers.
Structured data translates the page for machines, and in a shop five types matter most: Product with name, SKU, GTIN, brand and image; Offer with price, currency, availability and, where it fits, shipping and returns details; BreadcrumbList matching the visible breadcrumb; Organization once for the company facts; FAQPage only where questions and answers actually appear on the page. What your theme outputs today — microdata in the template, JSON-LD from a plugin, or both with contradicting values — we check in the delivered source, not in the plugin description. The rule behind it is strict and simple: the markup describes what is visible on the page. A B2B shop that shows prices only after login does not hand them to anonymous visitors in the markup either.
Google measures user experience with three metrics, each with a threshold for “good”: Largest Contentful Paint (LCP), the time until the largest visible element is in place, at most 2.5 seconds; Interaction to Next Paint (INP), how quickly the page responds to input, at most 200 milliseconds; Cumulative Layout Shift (CLS), how much the layout jumps while loading, at most 0.1. INP replaced the former First Input Delay metric in March 2024. The measurement comes from real visits and is assessed at the 75th percentile — three quarters of page views have to meet the threshold, not the test run on the office computer.
The typical brakes sit in the theme. For LCP it is usually the image at the top of the page: a slider that only loads after its script, a hero image with lazy loading that of all images should not be deferred, a file in print resolution. For CLS it is images without fixed dimensions, web fonts that arrive late and reflow the lines, and banners that push into the content after the fact. For INP it is scripts: tracking, chat, review widgets, consent tool and plugin code that runs on every page although it is needed on one. Each cause on its own is small; in the theme you see all of them at once.
We measure before and after, with the same tools. Field data from the Chrome User Experience Report and the Core Web Vitals report in Search Console show what real visitors experience — provided there are enough visits — but they lag behind over a rolling 28-day window. Lab values from Lighthouse show immediately whether a change works, but they are a simulation. We document both for each page type before we change anything, and again once the field data reflect the new state. If the server is losing the time — development mode, HTTP cache switched off, too many plugins in the request path — that goes into the findings, and then the theme is not the first job.
Each category page should rank under exactly one address, and its filtered and sorted versions point to it with a canonical. The exceptions are combinations people actually search for — category and brand, for example — which deserve their own indexable page with their own copy instead of a filter state. The order of the tools matters: an address blocked in robots.txt cannot be fetched by Google, so its canonical cannot be read either. Anyone who wants to keep filter pages out of the index therefore does not block them wholesale but decides per parameter between canonical, noindex and no link at all.
With pagination, every page gets its own canonical; pointing page 2 to page 1 hides the products behind it. Since Shopware 6.7 the default pagination runs on links instead of radio inputs — a crawler does not follow a form field, but it does follow a link. A theme that overrode the old block brings the old construction back. With several languages or sales channels, hreflang comes in: every language version names all the others and itself, reciprocally and with addresses that can actually be reached. If the return link is missing, Google ignores the annotation. We check the output per channel and language rather than relying on a setting in the administration.
For visibility in AI answers we work in five steps — access, technology, text, data, measurement — and three of them are decided in the theme. Access usually lies outside it, and it fails more often than the markup does: because of robots.txt, a firewall rule at the host or Cloudflare, where bot protection and a dedicated setting against AI crawlers can block across the board what robots.txt allows. The distinction has to be precise. OAI-SearchBot, PerplexityBot and Bingbot fetch content for answers; GPTBot and ClaudeBot mainly collect training data. Google-Extended is not a crawler of its own but a token that only controls use in the Gemini applications — it has no influence on the AI Overviews in Google Search, which draw on the normal search index. Anyone who wants to exclude training and still be cited sets each token separately.
After that, the theme decides what a model gets to read. Language models cite paragraphs, not pages; a paragraph that opens with the answer can be cited, one that opens with “Welcome to our shop” cannot. In the theme that means: the product description sits high up in the source and not behind three banners, properties are a table in the HTML and not an image, company name, location and contact details are plain text and in the Organization markup rather than only a graphic in the footer. The copy itself is written by your editorial team or in our content concept; the theme makes sure its structure reaches the crawler. An llms.txt can add a curated entry point. It is a proposed format, not a binding standard, and it replaces none of the steps before it.
Measurement is honest, which means approximate. Server logs show whether and how often the AI services’ crawlers actually fetch pages, and which ones. Web analytics can break out visits arriving from ChatGPT or Perplexity. And fixed test questions to ChatGPT, Perplexity and Google’s AI Overviews let you record, by sample, which sources are named — before and after, with the same questions. There is no ranking as in classic search, because answers vary with wording and timing. Nobody can promise a place in AI answers, and neither can Sharpness in Oldenburg. We show what changes.
Process
Send us your shop’s address, the Shopware version and, if available, access to Search Console. You get an assessment of whether the cause lies in the theme and what a refresh would change — and if it lies elsewhere, we tell you that too. Telephone +49 441 21 21 63 0, Mon–Thu 9:00–16:00, Fri 9:00–13:00 (CET).
Before we change anything we record the current state: field data from Search Console and the Chrome User Experience Report, Lighthouse per page type, a crawl of the shop, the indexing status, AI crawler hits in the logs and a fixed list of test questions to ChatGPT, Perplexity and Google’s AI Overviews. This is the yardstick the refresh will later be measured against.
Homepage, category, product, search, Shopping Experiences: for every page type we compare the raw source with the rendered page, read headings, markup, canonicals, hreflang and scripts and check how the theme inherits. The result is a written findings report with priority and effort per item — at a fixed price that we state beforehand.
Together we decide what belongs in the theme, what in the configuration of plugins, robots.txt or Cloudflare, and what remains editorial work. Whatever does not pay off is struck here. Clearly defined parts get a fixed price, the rest an estimate.
Work happens in a Git repository that belongs to you, on a staging copy, not in the live shop. Copied templates are rebuilt as targeted block overrides; headings, markup, images, fonts and scripts are reworked page type by page type.
Structured data through Google’s Rich Results Test and the Schema.org validator, Lighthouse against the baseline, a new crawl against the first one, keyboard operation and screen reader on the core journeys, a test order. You sign off the look, we sign off the technology — both in writing.
Right after go-live, lab values and source code show the new state; the field data need their 28-day window. After that come the same values as before, the same test questions, the same page types — you receive a side-by-side comparison, not a success story.
Projects on this system
A selection — not the full client list.
Across the north-west
We work for companies from Wuppertal and Münster via the Emsland and East Frisia to Hamburg and Hanover. Meetings on site by arrangement, the ongoing work remotely. Each region has a page of its own.
A theme refresh is the reworking of the markup an existing Shopware 6 theme delivers, so that search engines and AI assistants can read the shop better and it loads faster. Headings, HTML structure, structured data, images, fonts and scripts are reworked, along with the theme’s inheritance. Data, addresses and functions stay as they are, and the design changes only where the markup requires it. Sharpness Solutions GmbH from Oldenburg carries this out as a clearly defined project, with measurements before and after.
With three checks you can do yourself. First: open the source of a product page — not the developer tools, but “View page source” — and search for the product description and the price; if either is missing, it only arrives via JavaScript. Second: search the source for “h1”; if it contains the shop name rather than the product name, the hierarchy is wrong. Third: look at the Core Web Vitals report in Search Console to see whether whole page types are red. Then the cause usually lies in a shared template, in other words in the theme.
Usually not. The causes that hold a theme back lie in the markup — headings, order in the source, structured data, images, scripts — and can be fixed without changing much of the appearance. A relaunch, by contrast, replaces the design, often addresses and content as well, and brings its own risks for visibility. If the findings show that the theme is so tangled that a rebuild would be cheaper than reworking it, we put both figures side by side.
The addresses stay as they are; a theme refresh does not touch your shop’s SEO URLs. What changes is what is delivered under those addresses — and therefore how well search engines and AI services can read the pages. Whether and how much that shows in rankings nobody can promise in advance, and neither can we. That is why we measure before and after and show you the comparison. Where canonicals or filter pages are cleaned up, the set of addresses in the index shifts deliberately — that is the purpose of the change, and we discuss it beforehand.
“Good” means a Largest Contentful Paint (LCP) of at most 2.5 seconds, an Interaction to Next Paint (INP) of at most 200 milliseconds and a Cumulative Layout Shift (CLS) of at most 0.1. They are assessed at the 75th percentile of real page views, separately for mobile and desktop. INP replaced the former First Input Delay (FID) in March 2024; reports and proposals that still argue with FID are out of date. In Shopware shops the causes of poor values usually lie in the theme: sliders and hero images for LCP, fonts and images without fixed dimensions for CLS, plugin and third-party scripts for INP.
Above all Product and Offer on the product pages — with name, SKU, GTIN, brand, image, price, currency and availability — plus BreadcrumbList for context and Organization for the company facts. FAQPage is worthwhile where questions and answers are visible on the page; Google now shows FAQ rich results for only a few websites, but the markup remains useful as a machine-readable structure. Which of this data your theme outputs today, and whether theme and plugins contradict each other, we check in the delivered source. What matters is that the markup matches the visible content.
Usually for one of three reasons, and they can be checked in this order. First, access: robots.txt, firewall or Cloudflare block the crawlers that fetch content for answers, such as OAI-SearchBot or PerplexityBot. Second, markup: the content that matters is not in the delivered HTML but only comes into being through JavaScript, or product facts are missing from the structured data. Third, text: paragraphs open with a run-up instead of the answer and are therefore hard to cite. The first two often lie in the theme and the server configuration, the third with the editorial team. Even then, nobody can guarantee a mention.
Only in part. An SEO plugin can add meta tags, canonicals and structured data, but it does not change the headings the theme sets, the order in the source or the scripts that determine load time. If the theme outputs its own markup as well, duplicate or contradicting data appear easily. We check what theme and plugin each output and then decide which of them takes on which job — sometimes the plugin is no longer needed afterwards.
A custom theme has to be checked against the new storefront when moving to 6.7, because Shopware changed markup, ARIA attributes and block structure there as part of its accessibility overhaul. The default pagination runs on links instead of radio inputs, icons from the icon helper carry aria-hidden, and header and footer load via ESI. Every overridden Twig block that still contains the old original silently brings the old structure back. For a theme refresh this is a good moment, because the blocks have to be read anyway. The update process itself is described on our Shopware updates page.
Yes, but not by changing the bought theme itself, because those changes would be lost with the vendor’s next update. We create a custom theme that inherits from the bought one and override there exactly the blocks that need to change. That way vendor updates can still be installed and your adjustments are kept. How far this goes depends on how the bought theme is built: if it sets few, coarse Twig blocks or bundles its scripts so that they cannot be switched off individually, we tell you after the findings and before the quote.
A theme refresh is calculated by effort, and four factors determine most of it: the number of page types with their own template, the number of templates that were copied rather than overridden, the number of extensions that output something in the storefront, and the number of languages and sales channels. It starts with a findings report with priority and effort per item; that report is a self-contained first deliverable at a fixed price that we state in writing beforehand. After that there is a fixed price for clearly defined parts and an estimate for the rest. We give figures on request, not on this page.
In the source code and the lab values immediately after go-live, in the field data after about four weeks, in rankings and AI answers after weeks at the earliest and without any promise. The field data of the Chrome User Experience Report and Search Console run over a rolling 28-day window and therefore reflect the new state only gradually. Whether search engines and AI services reassess the reworked pages depends on when they fetch them again — that can be prompted but not forced. We measure at fixed points in time and show you what has moved and what has not.
Enquiry
Briefly describe what you have noticed — a drop in Search Console, red values in PageSpeed Insights, a shop that ChatGPT does not know. We look at the source code and tell you whether the theme is the cause.