Semantik-Audit für Shopify-Shops: Ein n8n-Workflow als Blaupause.

Passt für dich, wenn: du verstehen willst, wie man semantische SEO-Analysen mit LLMs automatisiert, du mit Shopify oder einem anderen Shopsystem arbeitest und dich weder 30 Nodes noch individuelle Anpassungsarbeit abschrecken.

Diesen Workflow habe ich für ein Kundenprojekt gebaut: ein gewachsener Shopify-Shop, viele Collections, ein Blog, und die klassische Frage, warum die Sichtbarkeit hinter dem Sortiment zurückbleibt. Die Antwort lag nicht in Title-Tags oder Ladezeiten, sondern eine Ebene tiefer: in der Semantik. Also habe ich die Analyse automatisiert, die ich sonst von Hand mache. Herausgekommen sind 29 Nodes, vier Analyse-Module und ein Google Sheet, das nach dem Lauf mehr über die Soll-Struktur des Shops weiß als jedes Ranking-Tool.

Eins vorweg, damit die Erwartung stimmt: Das hier ist kein Workflow zum Importieren und Starten. Du bekommst ihn unten als Download, aber er ist eine Blaupause. Er zeigt, wie so eine Analyse aufgebaut ist, und will an dein Projekt angepasst werden. Wer einen Workflow zum sofort Loslaufen sucht, findet ihn in meinem GSC-SEO-Report.

Warum ein Semantik-Audit?

Google und KI-Systeme bewerten Shops längst nicht mehr über einzelne Keywords, sondern über Bedeutungszusammenhänge: Welche Entitäten deckt eine Kategorie ab? Passt die Seitenstruktur zur Logik der Nachfrage? Führen interne Links dorthin, wo thematisch verwandte Inhalte liegen? Ein Shop kann technisch perfekt sein und trotzdem unsichtbar bleiben, weil seine Architektur die Fragen des Marktes nicht abbildet: weil das Thema mit stabiler Nachfrage nur als Filter existiert, weil zwei dünne Collections sich gegenseitig das Thema streitig machen, weil der Ratgeber-Artikel nicht auf die passende Kategorie verlinkt.

Genau diese Ebene prüft das Audit. Und weil dafür jede einzelne Seite gelesen, verstanden und eingeordnet werden muss, ist es der perfekte Fall für ein LLM im Werkzeugkasten: Die Denkarbeit steckt in den Prompts, die Fleißarbeit übernimmt der Workflow.

Der Ablauf im Überblick

Die Eingabe ist bewusst simpel: ein Tab mit fünf Spalten pro Seite (URL, Title, Meta-Description, H1, Hauptinhalt), erzeugt aus einem Screaming-Frog-Crawl mit Custom Extraction. Der Workflow erkennt am URL-Muster, ob eine Seite Collection oder Blogartikel ist, und schickt sie durch vier Module.

Und so sieht das Ganze auf dem n8n-Canvas aus:

Modul 1: Entitäten, das Fundament

Für jede Seite extrahiert das LLM Entitäten in vier festen Kategorien: Kern-Entitäten (Produkt- und Objektarten wie „Espressomaschine", „Cold-Brew-Karaffe"), Attribute (Merkmale wie „Füllmenge in Gramm", „Edelstahl", „spülmaschinenfest"), Use Cases (Situationen und Probleme wie „Espresso zu Hause zubereiten", „Kaffee länger frisch halten") und thematischer Kontext. Der Prompt darf dabei auch naheliegende Begriffe ergänzen, die auf der Seite fehlen, denn genau diese Lücken sind später das Interessante.

Das kannst du dir auch ohne n8n mitnehmen: Die vier Kategorien sind ein Denkraster, das jede Kategorieseiten-Überarbeitung besser macht. Schreib für deine wichtigste Collection einmal auf, welche Kern-Entitäten, Attribute und Use Cases sie abdecken müsste, und vergleich das mit dem, was auf der Seite steht. Die Differenz ist dein Arbeitsplan.

Modul 2: Von Entitäten zu Filtern

Aus den Entitäten jeder Collection leitet das zweite Modul ab, welche Filter die Seite braucht: Pflicht-Filter, Nice-to-have-Filter und, am wertvollsten, Filter, die sich aus den Entitäten ergeben, aber im Shop fehlen. Wenn die Entitäts-Analyse zeigt, dass in einer Kategorie ständig über Mahlwerk-Typen gesprochen wird, es aber keinen Mahlwerk-Filter gibt, ist das ein konkreter, umsetzbarer Befund.

Ohne n8n: Nimm deine Top-5-Collections und prüfe je Kategorie, ob die Filter die Kaufentscheidungs-Kriterien der Kunden abbilden oder nur die Datenbank-Felder des Shops. Der Unterschied zwischen beidem ist meistens erheblich.

Modul 3: Collection-Architektur im Map-Reduce-Verfahren

Das technisch spannendste Modul. Eine Architektur-Analyse braucht den Blick auf den ganzen Shop, aber hunderte Collections passen in kein Kontextfenster. Die Lösung ist ein Muster aus der Datenverarbeitung: Map und Reduce. In der Map-Phase bekommt das LLM den Shop häppchenweise, etwa 25 Collections pro Chunk, und labelt jede: Ist das ein Hub-Kandidat, eine Unterkategorie, ein Merge-Fall? Dazu je Chunk eine Zusammenfassung der Hauptthemen. In der Reduce-Phase sieht ein zweiter Prompt nur noch die vor-gelabelten Ergebnisse und Chunk-Zusammenfassungen und definiert daraus die globale Architektur: wenige klare Hubs, Zuordnung jeder Collection, Zusammenlegungs-Kandidaten und Vorschläge für fehlende Kategorien. Wichtige Leitplanke im Prompt: Das LLM darf keine URLs erfinden, es arbeitet nur mit dem, was der Shop hat.

So sieht das Ergebnis aus (fiktive Daten, Demo-Kaffeerösterei):

Ohne n8n: Das Map-Reduce-Muster funktioniert für jede LLM-Analyse, die größer ist als ein Kontextfenster: erst Teilmengen einzeln bewerten lassen, dann die Bewertungen zusammenführen. Wer das einmal verstanden hat, skaliert jede Analyse.

Modul 4: Interne Verlinkung mit Index-Trick

Für Verlinkungsvorschläge gibt es dasselbe Problem in anderer Form: Sinnvolle Links brauchen Wissen über alle möglichen Ziele. Der Workflow löst das mit zwei Datenströmen: Das LLM bekommt je Chunk die Detail-Daten von wenigen Seiten, dazu aber einen kompakten Index aller Seiten des Shops (nur URL, Typ, Kurzinfo). So kann es für jede Seite passende Ziele aus dem gesamten Shop vorschlagen, ohne dass der gesamte Shop in voller Tiefe im Prompt stecken muss. Die Vorschläge landen mit Begründung im Sheet und sind danach Redaktionsarbeit: prüfen, priorisieren, umsetzen.

Was du brauchst, wenn du ihn wirklich nachbauen willst

Kurz und ehrlich, das ist der Teil mit der individuellen Arbeit:

• Einen Crawl mit URL, Title, Meta, H1 und Hauptinhalt. Screaming Frog (kostenpflichtig, ab 259 € im Jahr) mit Custom Extraction ist der bequemste Weg.
• Ein Google Sheet mit dem Eingabe-Tab „1 - Intern - HTML" und vier leeren Ergebnis-Tabs: „Entitäten", „Filter & Attribute", „Collection Vorschläge", „Interne Verlinkung".
• Credentials in n8n: Google Sheets (OAuth2) und OpenAI. Der Workflow läuft durchgehend auf gpt-5-mini, warum das nicht mehr meine heutige Wahl wäre, steht im nächsten Abschnitt.
• Prompt-Anpassung: Die Beispielbegriffe in den Prompts sind auf eine fiktive Kaffeerösterei kalibriert. Tausche sie gegen dein Sortiment, sonst denkt das LLM in der falschen Warenwelt. Auch die URL-Muster der Seitentyp-Erkennung gehören geprüft.
• Einen Testlauf mit 10 bis 20 URLs, bevor der ganze Shop durchläuft. Erst Qualität prüfen, dann skalieren.

Welches Modell für welchen Job?

Der Workflow ist ein gutes Stück älter und stammt aus meiner ChatGPT-Zeit: alles über die OpenAI-API, ein Modell für alle vier Module. Das funktioniert, aber die Modell-Landschaft ist inzwischen arbeitsteilig, und die vier Module stellen sehr unterschiedliche Anforderungen. Würde ich heute neu besetzen, sähe das so aus:

• Massen-Extraktion (Entitäten, Filter, Map-Phase): Hier zählen Preis und Tempo, nicht Tiefgang, denn es sind hunderte Aufrufe mit eng geführten Prompts. Kleine, schnelle Modelle wie Claude Haiku, gpt-5-mini oder Gemini Flash nehmen sich bei sauberem Structured Output wenig. Wer schon einen Anbieter im Haus hat, bleibt einfach dabei.
• Der Reduce-Schritt (globale Architektur): Ein einziger Aufruf, der wertvollste des ganzen Laufs, denn hier entsteht die Struktur-Empfehlung. Das ist der Platz für das stärkste Modell, das du bekommen kannst, etwa Claude Sonnet oder Opus, GPT-5 oder Gemini Pro. Der Aufpreis liegt im Cent-Bereich, der Qualitätsunterschied beim Denken in Strukturen ist deutlich.
• Interne Verlinkung: eigentlich gar kein Textgenerierungs-Job. Im Kern ist das eine Ähnlichkeitssuche, und dafür gibt es Spezialisten: Embedding-Modelle wie die von Voyage AI oder Cohere verwandeln jede Seite in einen Vektor, die Kandidaten-Auswahl läuft dann über Vektor-Ähnlichkeit statt über ein ratendes LLM, ein Reranker sortiert die Treffer. Das Sprachmodell begründet am Ende nur noch die Top-Kandidaten. Schneller, günstiger und konsistenter als mein Index-Trick oben, der dafür ohne zusätzliche Infrastruktur auskommt.
• Entitäts-Normalisierung (aus der Ausbaustufe unten): Derselbe Spezialisten-Fall. Ob „Siebträger" und „Siebträgermaschine" dieselbe Entität sind, beantworten Embeddings über Vektor-Nähe zuverlässiger und billiger als jedes Chat-Modell.

Der Umbau ist in n8n unspektakulär: OpenAI-Nodes gegen Anthropic- oder HTTP-Nodes tauschen, die Prompts bleiben. Genau deshalb lohnt es sich, Prompts und Modell-Wahl gedanklich zu trennen.

Ehrlich eingeordnet: Der Workflow ist nicht ausgereizt

Damit kein falscher Eindruck entsteht: Das hier ist eine Momentaufnahme aus einem Kundenprojekt, keine fertige Produktversion. Auf dem Canvas oben klebt sogar noch meine eigene Notiz, was fehlt. Ich lasse sie bewusst drin, denn genau so sehen Workflows aus, die im echten Projektalltag entstanden sind. Und seit ich im Tagesgeschäft viel direkt mit Claude Code arbeite, erledige ich manche dieser Analysen auch ad hoc im Dialog statt über einen festen Workflow. n8n spielt seine Stärke da aus, wo eine Analyse wiederholbar und übergabefähig sein muss, etwa wenn ein Kundenteam sie ohne mich starten soll.

Wer den Workflow adaptiert, findet hier die Ausbaustufe, wie ich sie heute bauen würde, nach Wirkung sortiert:

1. Nachfrage-Daten einmischen. Die Architektur-Vorschläge sind rein semantisch begründet. Ob eine vorgeschlagene Collection wirklich eine eigene Seite verdient, entscheidet am Ende die Suchnachfrage. Search-Console-Daten (oder Suchvolumen) als zusätzliche Spalte je Collection würden die Vorschläge von „semantisch sauber" auf „semantisch sauber und nachweislich gesucht" heben.
2. Vorhanden vs. fehlend automatisch abgleichen. Das ist die Notiz aus dem Screenshot. Aktuell listet der Entitäten-Tab, was das LLM je Seite findet und ergänzt. Der eigentliche Hebel ist aber die Differenz: Welche Entitäten müsste die Seite abdecken und tut es nicht? Dieser Abgleich passiert bisher beim Lesen im Kopf, er gehört als eigene Spalte ins Sheet.
3. Entitäten normalisieren. Wenn das LLM auf einer Seite „Siebträger" und auf der nächsten „Siebträgermaschine" extrahiert, zählt das als zwei Begriffe. Für die Einzelseiten-Analyse egal, für jede shopweite Auswertung unscharf. Ein Kanonisierungs-Schritt nach der Extraktion würde das lösen.
4. Robustheit nachrüsten. Liefert das LLM in einem Chunk mal kein sauberes JSON, bricht der Lauf an der Stelle ab. Ein Retry pro Chunk macht daraus einen Workflow, der durchläuft statt meistens durchläuft. Dazu die Modell-Besetzung aus dem Abschnitt oben, allen voran das stärkere Modell für den Reduce-Schritt.

Falls du den Workflow adaptierst und eine dieser Stufen baust: Ich freue mich über Post.

Häufige Fragen zum Semantik-Audit