Shopware-Themes
Wenn ein Shopware-6-Shop schlecht rankt, langsam lädt oder in den Antworten von ChatGPT, Perplexity und der KI-Übersicht von Google nicht vorkommt, liegt die Ursache oft weder im Sortiment noch in den Texten, sondern im Theme — im Markup, das die Storefront an jeden Besucher und jeden Crawler ausliefert. Überschriften, die nur Optik sind. Inhalte, die erst per JavaScript entstehen. Produktfakten ohne maschinenlesbare Auszeichnung. Ein Slider, der die Ladezeit bestimmt. Ein Theme-Refresh behebt das, ohne den Shop neu zu bauen und meist ohne neues Design. Die Sharpness Solutions GmbH aus Oldenburg ist Shopware Extension Partner und überarbeitet bestehende Themes, auch fremd gebaute und gekaufte — mit Messung vorher und nachher. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr.
Die Symptome zeigen sich an verschiedenen Stellen: in der Google Search Console, in PageSpeed Insights, in einer Testfrage an ChatGPT oder schlicht im Umsatz aus der organischen Suche. Die Ursache steht häufig an einer einzigen Stelle — im Quelltext, den das Theme ausliefert. Diese sechs Befunde finden wir bei der Prüfung bestehender Shopware-Shops immer wieder. Ein zusätzliches SEO-Plugin behebt die wenigsten davon; im Theme lassen sich alle beheben.
Das Theme zeichnet das Logo oder den ersten Slider-Titel als H1 aus, und zwar auf jeder Seite. Der Name der Kategorie oder des Produkts steht darunter als H3 oder als fett gesetzter Absatz, weil die Größe gerade passte. Für Besucher sieht das richtig aus. Für Suchmaschinen, Screenreader und Sprachmodelle trägt jede Seite denselben Titel.
Beschreibung, Eigenschaften oder Bewertungen erscheinen erst nach einem Klick oder werden per JavaScript nachgeladen. Im Browser sieht man sie, im ausgelieferten Quelltext fehlen sie. Google rendert JavaScript, klickt aber nicht; manche KI-Crawler führen gar kein JavaScript aus. Was dort fehlt, wird nicht zitiert.
Der Preis steht groß auf der Produktseite, in den strukturierten Daten fehlt er — oder er steht dort zweimal mit unterschiedlichen Werten, einmal aus dem Template, einmal aus einem SEO-Plugin. Verfügbarkeit, Lieferzeit und Versandkosten sind Text, kein Markup. Eine Suchmaschine kann das Produkt anzeigen, aber nicht vergleichen.
Der größte sichtbare Inhalt ist ein Bild aus dem Startseiten-Slider, das erst nach dessen Skript lädt. Webfonts kommen spät und verschieben die Zeilen. Cookie-Banner, Chat, Bewertungs-Widget und Tracking laufen auf jeder Seite, auch dort, wo sie niemand braucht. Jede einzelne Ursache ist klein. Zusammen ergeben sie rote Core Web Vitals.
Adressen mit Filter-, Sortier- und Seitenparametern landen im Index oder als Duplikat in der Search Console, während die eigentliche Kategorieseite zurückfällt. Canonicals zeigen auf die falsche Fassung oder fehlen. Bei mehreren Sprachen oder Verkaufskanälen fehlt hreflang oder verweist nicht gegenseitig. Woher die Adressen kommen — Theme, Plugin oder externe Links —, zeigt erst der Blick in Quelltext und Logs.
Irgendwann wurden ganze Storefront-Templates ins eigene Theme kopiert, statt einzelne Twig-Blöcke zu überschreiben. Das sah damals schneller aus. Heute erreicht kein Update mehr diese Seiten: Die Kopie behält die alte Struktur, egal was Shopware ändert. Seit Shopware 6.7 mit seinem Barrierefreiheits-Umbau in der Storefront fällt das deutlich auf — Markup, ARIA-Attribute und Blockstruktur haben sich geändert, die Kopie nicht.
Ein Theme-Refresh überarbeitet das Markup, das Ihr Shopware-Theme ausliefert — Überschriften, HTML-Struktur, strukturierte Daten, Bilder, Schriften, Skripte —, und lässt alles andere stehen. Produkte, Kategorien, Kunden und Bestellungen bleiben unberührt, die Adressen bleiben dieselben, und das Design ändert sich nur dort, wo eine Änderung im Markup es verlangt. Der Grund für diesen Zuschnitt ist schlicht: Ein Crawler sieht kein Design. Er sieht, was im HTML steht, in welcher Reihenfolge und wie schnell. Genau dort setzt der Refresh an.
Zum Refresh gehört auch, was andere Erweiterungen in die Storefront schreiben. Jedes Plugin, das etwas anzeigt — Bewertungen, Siegel, Cross-Selling, Cookie-Hinweis, Chat —, bringt eigenes Markup, eigene Skripte und eigene Stile mit, und im Theme fügt sich all das zu einer Seite. Wir prüfen deshalb nicht das Theme allein, sondern die ausgelieferte Seite je Seitentyp. Und wir sagen es, wenn die Ursache woanders liegt: Ein Server, der zwei Sekunden bis zum ersten Byte braucht, wird durch kein Theme schnell, und zu dünne Produkttexte werden durch sauberes Markup nicht länger.
Ein Refresh räumt außerdem die Vererbung auf, denn sie entscheidet, ob die Verbesserungen das nächste Update überstehen. Ein gesundes Shopware-Theme ist ein eigenes Theme, das vom Standard-Theme erbt und nur die Twig-Blöcke überschreibt, die es ändern muss — per sw_extends, Block für Block. Ein Theme, das ganze Templates kopiert hat, behält deren alten Stand, egal was Shopware ändert. Mit Shopware 6.7 ist das konkret geworden: Der Barrierefreiheits-Umbau hat in der Storefront Markup, ARIA-Attribute und Blockstruktur verändert, die Pagination läuft über Links statt über Radio-Inputs, Header und Footer laden per ESI. Eine Kopie bekommt davon nichts mit. Deshalb bauen wir kopierte Templates im Refresh zu gezielten Block-Overrides zurück.
Die H1 einer Seite benennt, worum es auf dieser Seite geht: auf der Kategorieseite die Kategorie, auf der Produktseite das Produkt, auf der Startseite den Shop. Das Logo ist ein Link zur Startseite, keine Überschrift; Slider-Titel und Teaser-Zeilen sind Gestaltung, keine Gliederung. Darunter folgen H2 und H3 der Struktur des Inhalts, nicht der gewünschten Schriftgröße — die regelt das CSS. Dieselbe Ordnung brauchen Screenreader, und für die meisten Onlineshops, die an Verbraucher verkaufen, gehört sie seit dem 28. Juni 2025 zu den Anforderungen des Barrierefreiheitsstärkungsgesetzes. Wir legen die Hierarchie je Seitentyp im Theme fest, damit sie nicht in jeder Erlebniswelt neu verhandelt wird.
Was zitiert werden soll, muss im ausgelieferten HTML stehen. Texte in Tabs sind dafür kein Problem, solange sie beim Laden der Seite im Quelltext stehen und nur optisch eingeklappt sind. Problematisch sind Inhalte, die erst nach einem Klick oder in einem Off-Canvas per JavaScript nachgeladen werden: Google rendert JavaScript, klickt aber nicht, und nicht jeder KI-Crawler führt überhaupt JavaScript aus. Wir vergleichen deshalb je Seitentyp den rohen Quelltext mit der gerenderten Seite und holen die tragenden Inhalte — Produktbeschreibung, Eigenschaften, Lieferangaben, die wichtigsten internen Links — in das, was der Server ausliefert.
Strukturierte Daten übersetzen die Seite für Maschinen, und im Shop zählen vor allem fünf Typen: Product mit Name, Artikelnummer, GTIN, Marke und Bild; Offer mit Preis, Währung, Verfügbarkeit und, wo es passt, Versand- und Rückgabeangaben; BreadcrumbList passend zur sichtbaren Brotkrumennavigation; Organization einmal für die Firmenfakten; FAQPage nur dort, wo Fragen und Antworten tatsächlich auf der Seite stehen. Was Ihr Theme heute ausgibt — Microdata im Template, JSON-LD aus einem Plugin oder beides mit widersprüchlichen Werten —, prüfen wir am ausgelieferten Quelltext, nicht an der Plugin-Beschreibung. Die Regel dahinter ist streng und einfach: Das Markup beschreibt, was auf der Seite sichtbar ist. Ein B2B-Shop, der Preise erst nach dem Login zeigt, gibt sie auch im Markup nicht an anonyme Besucher aus.
Google misst die Nutzererfahrung über drei Werte, und für jeden gibt es eine Schwelle, ab der er als „gut“ gilt: Largest Contentful Paint (LCP), die Zeit, bis der größte sichtbare Inhalt steht, höchstens 2,5 Sekunden; Interaction to Next Paint (INP), wie schnell die Seite auf Eingaben reagiert, höchstens 200 Millisekunden; Cumulative Layout Shift (CLS), wie stark das Layout beim Laden springt, höchstens 0,1. INP hat im März 2024 den früheren Wert First Input Delay abgelöst. Gemessen wird an echten Besuchen, bewertet am 75. Perzentil — drei Viertel der Aufrufe müssen die Schwelle schaffen, nicht der Testlauf auf dem Bürorechner.
Die typischen Bremsen sitzen im Theme. Beim LCP ist es meist das Bild oben auf der Seite: ein Slider, der erst nach seinem Skript lädt, ein Hero-Bild mit Lazy Loading, das gerade nicht verzögert werden sollte, eine Datei in Druckauflösung. Beim CLS sind es Bilder ohne feste Maße, Webfonts, die spät eintreffen und die Zeilen neu umbrechen, und Banner, die sich nachträglich in den Inhalt schieben. Beim INP sind es Skripte: Tracking, Chat, Bewertungs-Widgets, Consent-Lösung und Plugin-Code, der auf jeder Seite läuft, obwohl er nur auf einer gebraucht wird. Jede einzelne Ursache ist klein; im Theme sieht man sie alle auf einmal.
Gemessen wird vorher und nachher, mit denselben Werkzeugen. Die Felddaten aus dem Chrome User Experience Report und dem Core-Web-Vitals-Bericht der Search Console zeigen, was echte Besucher erleben — sofern genug Besuche vorliegen —, laufen aber über ein rollierendes 28-Tage-Fenster nach. Laborwerte aus Lighthouse zeigen sofort, ob eine Änderung wirkt, sind aber eine Simulation. Wir dokumentieren beide je Seitentyp, bevor wir etwas ändern, und noch einmal, wenn die Felddaten den neuen Stand abbilden. Verliert der Server die Zeit — Development-Modus, abgeschalteter HTTP-Cache, zu viele Plugins im Request-Pfad —, steht das im Befund, und dann ist das Theme nicht die erste Baustelle.
Jede Kategorieseite sollte unter genau einer Adresse ranken, und ihre gefilterten und sortierten Fassungen verweisen per Canonical auf sie. Ausnahmen sind Kombinationen, nach denen tatsächlich gesucht wird — etwa Kategorie und Marke —; sie verdienen eine eigene, indexierbare Seite mit eigenem Text statt eines Filterzustands. Wichtig ist die Reihenfolge der Werkzeuge: Eine Adresse, die per robots.txt gesperrt ist, kann Google nicht abrufen und damit auch ihren Canonical nicht lesen. Wer Filterseiten aus dem Index halten will, sperrt sie deshalb nicht pauschal, sondern entscheidet je Parameter zwischen Canonical, noindex und gar keinem Link.
Bei der Paginierung bekommt jede Seite ihren eigenen Canonical; Seite 2 auf Seite 1 zu verweisen, versteckt die Produkte dahinter. Seit Shopware 6.7 läuft die Pagination im Standard über Links statt über Radio-Inputs — einem Formularfeld folgt kein Crawler, einem Link schon. Ein Theme, das den alten Block überschrieben hat, bringt die alte Bauweise zurück. Bei mehreren Sprachen oder Verkaufskanälen kommt hreflang dazu: Jede Sprachfassung nennt alle anderen und sich selbst, gegenseitig und mit Adressen, die tatsächlich erreichbar sind. Fehlt die Gegenrichtung, ignoriert Google die Angabe. Wir prüfen die Ausgabe je Kanal und Sprache, statt uns auf eine Einstellung in der Verwaltung zu verlassen.
Für die Sichtbarkeit in KI-Antworten arbeiten wir in fünf Schritten — Zugang, Technik, Text, Daten, Messen —, und drei davon entscheiden sich im Theme. Der Zugang liegt meist außerhalb, und an ihm scheitert es öfter als am Markup: an der robots.txt, an einer Firewall-Regel des Hosters oder an Cloudflare, wo Bot-Schutz und eine eigene Einstellung gegen KI-Crawler pauschal blockieren können, was die robots.txt erlaubt. Unterscheiden muss man dabei genau. OAI-SearchBot, PerplexityBot und Bingbot holen Inhalte für Antworten, GPTBot und ClaudeBot sammeln vor allem Trainingsdaten. Google-Extended ist kein eigener Crawler, sondern eine Kennung, die nur die Nutzung in den Gemini-Anwendungen steuert — auf die KI-Übersichten der Google-Suche hat sie keinen Einfluss, die speisen sich aus dem normalen Suchindex. Wer Training ausschließen und trotzdem zitiert werden will, regelt die Kennungen einzeln.
Danach entscheidet das Theme, was ein Modell zu lesen bekommt. Sprachmodelle zitieren Absätze, keine Seiten; ein Absatz, der mit der Antwort beginnt, ist zitierfähig, einer, der mit „Herzlich willkommen in unserem Shop“ anfängt, nicht. Im Theme heißt das: Die Produktbeschreibung steht weit oben im Quelltext und nicht hinter drei Bannern, Eigenschaften stehen als Tabelle im HTML und nicht im Bild, Firmenname, Ort und Kontakt stehen im Klartext und im Organization-Markup statt nur als Grafik im Footer. Die Texte selbst schreibt Ihre Redaktion oder entstehen in unserem Content-Konzept; das Theme sorgt dafür, dass ihr Aufbau beim Crawler ankommt. Eine llms.txt kann einen kuratierten Einstieg ergänzen. Sie ist ein vorgeschlagenes Format, kein verbindlicher Standard, und ersetzt keinen der Schritte davor.
Gemessen wird ehrlich, und das heißt: näherungsweise. In den Server-Logs sieht man, ob und wie oft die Crawler der KI-Dienste tatsächlich abrufen und welche Seiten. In der Webanalyse lassen sich Besuche mit Herkunft aus ChatGPT oder Perplexity auswerten. Und mit festen Testfragen an ChatGPT, Perplexity und die KI-Übersicht von Google lässt sich stichprobenartig protokollieren, welche Quellen genannt werden — vorher und nachher, mit denselben Fragen. Ein Ranking wie in der klassischen Suche gibt es dabei nicht, weil Antworten je nach Formulierung und Zeitpunkt schwanken. Einen Platz in KI-Antworten kann niemand zusagen, auch Sharpness (Oldenburg) nicht. Wir zeigen, was sich ändert.
Ablauf
Schicken Sie uns die Adresse Ihres Shops, die Shopware-Version und, wenn vorhanden, einen Zugang zur Search Console. Sie bekommen eine Einschätzung, ob die Ursache im Theme liegt und was ein Refresh ändern würde — und wenn sie woanders liegt, sagen wir auch das. Telefon 0441 21 21 63 0, Mo–Do 9:00–16:00 Uhr, Fr 9:00–13:00 Uhr.
Bevor wir etwas ändern, halten wir den Ist-Stand fest: Felddaten aus Search Console und Chrome User Experience Report, Lighthouse je Seitentyp, einen Crawl des Shops, den Indexierungsstatus, die Zugriffe der KI-Crawler in den Logs und eine feste Liste von Testfragen an ChatGPT, Perplexity und die KI-Übersicht von Google. An diesem Stand muss sich der Refresh später messen lassen.
Startseite, Kategorie, Produkt, Suche, Erlebniswelten: Für jeden Seitentyp vergleichen wir rohen Quelltext und gerenderte Seite, lesen Überschriften, Markup, Canonicals, hreflang und Skripte und prüfen, wie das Theme vererbt. Ergebnis ist ein schriftlicher Befundbericht mit Priorität und Aufwand je Punkt — zum Festpreis, den wir vorher nennen.
Gemeinsam legen wir fest, was ins Theme gehört, was in die Konfiguration von Plugins, robots.txt oder Cloudflare und was Redaktionsarbeit bleibt. Was sich nicht lohnt, wird hier gestrichen. Für klar abgegrenzte Teile gibt es einen Festpreis, für den Rest eine Schätzung.
Gearbeitet wird in einem Git-Repository, das Ihnen gehört, auf einer Staging-Kopie, nicht im Live-Shop. Kopierte Templates werden zu gezielten Block-Overrides zurückgebaut, Überschriften, Markup, Bilder, Schriften und Skripte Seitentyp für Seitentyp überarbeitet.
Strukturierte Daten im Test für Rich-Suchergebnisse von Google und im Schema.org-Validator, Lighthouse gegen die Ausgangswerte, ein neuer Crawl gegen den ersten, Tastaturbedienung und Screenreader an den Kernstrecken, eine Testbestellung. Sie nehmen die Optik ab, wir die Technik — beides schriftlich.
Direkt nach dem Livegang zeigen Laborwerte und Quelltext den neuen Stand; die Felddaten brauchen ihr 28-Tage-Fenster. Danach dieselben Werte wie vorher, dieselben Testfragen, dieselben Seitentypen — Sie bekommen eine Gegenüberstellung, keine Erfolgsmeldung.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Im ganzen Nordwesten
Wir arbeiten für Unternehmen von Wuppertal und Münster über das Emsland und Ostfriesland bis Hamburg und Hannover. Termine vor Ort nach Absprache, die laufende Arbeit remote. Zu jeder Region gibt es eine eigene Seite.
Ein Theme-Refresh ist die Überarbeitung des Markups, das ein bestehendes Shopware-6-Theme ausliefert, mit dem Ziel, dass Suchmaschinen und KI-Assistenten den Shop besser lesen können und er schneller lädt. Überarbeitet werden Überschriften, HTML-Struktur, strukturierte Daten, Bilder, Schriften und Skripte, dazu die Vererbung des Themes. Daten, Adressen und Funktionen bleiben, wie sie sind, und das Design ändert sich nur dort, wo das Markup es erfordert. Die Sharpness Solutions GmbH aus Oldenburg setzt das als abgegrenztes Projekt um, mit Messung vorher und nachher.
An drei Prüfungen, die Sie selbst machen können. Erstens: Öffnen Sie den Quelltext einer Produktseite — nicht die Entwicklerwerkzeuge, sondern „Seitenquelltext anzeigen“ — und suchen Sie nach Produktbeschreibung und Preis; fehlt eines davon, kommt es erst per JavaScript dazu. Zweitens: Suchen Sie im Quelltext nach „h1“; steht dort der Shopname statt des Produktnamens, ist die Hierarchie falsch. Drittens: Sehen Sie im Core-Web-Vitals-Bericht der Search Console nach, ob ganze Seitentypen rot sind. Dann liegt die Ursache meist in einer gemeinsamen Vorlage, also im Theme.
Meist nicht. Die Ursachen, die ein Theme ausbremsen, liegen im Markup — Überschriften, Reihenfolge im Quelltext, strukturierte Daten, Bilder, Skripte — und lassen sich beheben, ohne dass sich am Erscheinungsbild viel ändert. Ein Relaunch tauscht dagegen das Design, oft auch Adressen und Inhalte, und bringt eigene Risiken für die Sichtbarkeit mit. Zeigt der Befund, dass das Theme so verbaut ist, dass ein Neuaufbau günstiger wäre als die Überarbeitung, stellen wir beide Zahlen nebeneinander.
Die Adressen bleiben, wie sie sind; ein Theme-Refresh greift nicht in die SEO-URLs Ihres Shops ein. Was sich ändert, ist das, was unter diesen Adressen ausgeliefert wird — und damit, wie gut Suchmaschinen und KI-Dienste die Seiten lesen können. Ob und wie stark sich das in Rankings niederschlägt, kann niemand vorher zusagen, auch wir nicht. Deshalb messen wir vorher und nachher und zeigen Ihnen den Vergleich. Wo Canonicals oder Filterseiten bereinigt werden, verschiebt sich bewusst, welche Adressen im Index stehen — das ist der Zweck der Änderung und wird vorher besprochen.
Als „gut“ gelten ein Largest Contentful Paint (LCP) von höchstens 2,5 Sekunden, ein Interaction to Next Paint (INP) von höchstens 200 Millisekunden und ein Cumulative Layout Shift (CLS) von höchstens 0,1. Bewertet wird am 75. Perzentil echter Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. INP hat im März 2024 den früheren Wert First Input Delay (FID) ersetzt; Berichte und Angebote, die noch mit FID argumentieren, sind veraltet. In Shopware-Shops liegen die Ursachen schlechter Werte meist im Theme: Slider und Hero-Bilder beim LCP, Schriften und Bilder ohne feste Maße beim CLS, Plugin- und Drittanbieter-Skripte beim INP.
Vor allem Product und Offer auf den Produktseiten — mit Name, Artikelnummer, GTIN, Marke, Bild, Preis, Währung und Verfügbarkeit —, dazu BreadcrumbList für die Einordnung und Organization für die Firmenfakten. FAQPage lohnt sich dort, wo Fragen und Antworten sichtbar auf der Seite stehen; FAQ-Rich-Results zeigt Google inzwischen nur noch für wenige Websites, als maschinenlesbare Gliederung bleibt das Markup trotzdem nützlich. Welche dieser Daten Ihr Theme heute ausgibt und ob sich Theme und Plugins dabei widersprechen, prüfen wir am ausgelieferten Quelltext. Entscheidend ist, dass das Markup dem sichtbaren Inhalt entspricht.
Meist aus einem von drei Gründen, und sie lassen sich in dieser Reihenfolge prüfen. Erstens der Zugang: robots.txt, Firewall oder Cloudflare sperren die Crawler, die Inhalte für Antworten holen, etwa OAI-SearchBot oder PerplexityBot. Zweitens das Markup: Die tragenden Inhalte stehen nicht im ausgelieferten HTML, sondern entstehen erst per JavaScript, oder Produktfakten fehlen in den strukturierten Daten. Drittens der Text: Absätze beginnen mit Anlauf statt mit der Antwort und lassen sich deshalb schlecht zitieren. Die ersten beiden Punkte liegen oft im Theme und in der Server-Konfiguration, der dritte bei der Redaktion. Eine Nennung garantieren kann auch danach niemand.
Nur zum Teil. Ein SEO-Plugin kann Meta-Angaben, Canonicals und strukturierte Daten ergänzen, aber es ändert nicht die Überschriften, die das Theme setzt, nicht die Reihenfolge im Quelltext und nicht die Skripte, die die Ladezeit bestimmen. Gibt das Theme zusätzlich eigenes Markup aus, entstehen leicht doppelte oder widersprüchliche Angaben. Wir prüfen, was Theme und Plugin jeweils ausgeben, und entscheiden dann, wer welche Aufgabe übernimmt — manchmal ist das Plugin danach überflüssig.
Ein eigenes Theme muss beim Sprung auf 6.7 gegen die neue Storefront geprüft werden, weil Shopware dort im Zuge des Barrierefreiheits-Umbaus Markup, ARIA-Attribute und Blockstruktur verändert hat. Die Pagination läuft im Standard über Links statt über Radio-Inputs, Icons aus dem Icon-Helper tragen aria-hidden, Header und Footer laden per ESI. Jeder überschriebene Twig-Block, der noch das alte Original enthält, bringt die alte Struktur still zurück. Für einen Theme-Refresh ist das ein guter Zeitpunkt, denn die Blöcke müssen ohnehin gelesen werden. Den Ablauf des Updates selbst beschreibt unsere Seite zu Shopware-Updates.
Ja, aber nicht durch Änderungen im gekauften Theme selbst, denn die wären beim nächsten Update des Herstellers verloren. Wir legen ein eigenes Theme an, das vom gekauften erbt, und überschreiben dort gezielt die Blöcke, die sich ändern müssen. So bleiben Hersteller-Updates einspielbar, und Ihre Anpassungen bleiben erhalten. Wie weit das trägt, hängt davon ab, wie das gekaufte Theme gebaut ist: Setzt es wenige, grobe Twig-Blöcke oder bündelt es seine Skripte so, dass sie sich nicht einzeln abschalten lassen, sagen wir das nach dem Befund und vor dem Angebot.
Ein Theme-Refresh wird nach Aufwand kalkuliert, und den Aufwand bestimmen vor allem vier Größen: die Zahl der Seitentypen mit eigener Vorlage, die Zahl der kopierten statt überschriebenen Templates, die Zahl der Erweiterungen, die in der Storefront etwas ausgeben, und die Zahl der Sprachen und Verkaufskanäle. Am Anfang steht ein Befundbericht mit Priorität und Aufwand je Punkt; er ist ein abgegrenztes Erstprodukt zum Festpreis, den wir vorher schriftlich nennen. Danach gibt es für klar abgegrenzte Teile einen Festpreis und für den Rest eine Schätzung. Zahlen nennen wir auf Anfrage, nicht auf dieser Seite.
Im Quelltext und in den Laborwerten sofort nach dem Livegang, in den Felddaten nach rund vier Wochen, in Rankings und KI-Antworten frühestens nach Wochen und ohne Zusage. Die Felddaten des Chrome User Experience Report und der Search Console laufen über ein rollierendes 28-Tage-Fenster und bilden den neuen Stand deshalb erst nach und nach ab. Ob Suchmaschinen und KI-Dienste die überarbeiteten Seiten neu bewerten, hängt davon ab, wann sie sie erneut abrufen — das lässt sich anstoßen, aber nicht erzwingen. Wir messen zu festen Zeitpunkten und zeigen Ihnen, was sich bewegt hat und was nicht.
Anfrage
Beschreiben Sie kurz, was Ihnen aufgefallen ist — ein Rückgang in der Search Console, rote Werte in PageSpeed Insights, ein Shop, den ChatGPT nicht kennt. Wir sehen in den Quelltext und sagen Ihnen, ob das Theme die Ursache ist.