Warum Ihre Produktdaten unsichtbar sind

Was mit einem PDF passiert

Ein PDF-Datenblatt ist für Google eine einzige, unteilbare Datei und für KI-Systeme meist nicht sauber zerlegbar. Wer seine Kennwerte nur dort ablegt, gibt sie in einem Format heraus, das für die Suche schlechter geeignet ist als jede einfache HTML-Seite. Der Ausweg ist keine Abschaffung der PDFs, sondern eine zweite Fassung: je Produktgruppe eine HTML-Seite mit Kennwerttabelle, Einsatzbereichen und strukturierten Daten, das PDF bleibt als Download daneben stehen.

Google indexiert PDFs grundsätzlich seit 2001 und hat nach eigenen Angaben hunderte Millionen davon im Index (Google Search Central: PDFs in Google search results). Das Problem ist also nicht die Aufnahme, sondern die Bewertung. Die Datei wird als Ganzes bewertet, nicht abschnittsweise. Ein 40-seitiger Katalog ist damit ein Dokument mit vielen Themen und rankt für keines davon gut.

Hinzu kommt: Bildinhalte in PDFs werden von Google nicht indexiert, und Text, der als Bild eingebettet ist, kann bestenfalls per Texterkennung erschlossen werden. Kennwerttabellen, die als Grafik im Datenblatt liegen, sind damit im besten Fall bruchstückhaft erfasst, die Zuordnung von Merkmal, Wert und Einheit geht verloren.

Bei KI-Systemen ist die Lage deutlicher. Antwortmaschinen arbeiten nach dem Muster der Retrieval-Augmented Generation: Dokumente werden vorab in Abschnitte von meist wenigen hundert Token zerlegt, und zur Frage werden nur die passenden Abschnitte geladen. Wie stark diese Zerlegung wirkt, zeigt eine Auswertung von Anthropic vom 19. September 2024 über Datensätze aus Programmcode, Belletristik, arXiv-Aufsätzen und Fachartikeln. Ergänzt man jeden Abschnitt vor der Speicherung um seinen Kontext und kombiniert die Suche mit einem Stichwortverfahren, sinkt die Fehlerquote bei den ersten 20 Treffern von 5,7 auf 2,9 Prozent, also um 49 Prozent (Anthropic: Introducing Contextual Retrieval).

Für Produktdaten heißt das: Entscheidend ist, ob ein Abschnitt für sich allein verständlich bleibt. Eine HTML-Tabelle liefert je Zeile die Zuordnung von Merkmal, Wert und Einheit. Beim Chunking eines PDFs zerfällt eine Tabelle, die über zwei Seiten läuft, dagegen leicht in Zahlenkolonnen ohne Spaltenkopf.

Dazu kommt ein praktisches Problem: Wer ein PDF findet, landet in einer Datei ohne Navigation, ohne Kontaktmöglichkeit und ohne Bezug zum restlichen Auftritt. Selbst wenn die Suche funktioniert, endet der Weg dort.

Das heißt nicht, dass PDFs verschwinden müssen. Sie sind zum Ausdrucken, Archivieren und Weitergeben sinnvoll. Sie dürfen nur nicht die einzige Fassung sein.

Konfiguratoren erzeugen nichts, was auffindbar wäre

Ein Produktkonfigurator zeigt Ergebnisse erst nach Eingaben des Nutzers. Was erst nach einer Interaktion entsteht, existiert für eine Suchmaschine nicht. Google folgt einem Link nur dann, wenn er als <a>-Element mit href-Attribut im Quelltext steht. Elemente, die erst per JavaScript zum Ziel führen, wertet Google nach eigener Dokumentation nicht zuverlässig aus (Google Search Central: Make your links crawlable).

<!-- crawlbar: das Ziel steht im Quelltext -->
<a href="/produkte/schnellkupplung-dn-25">Schnellkupplung DN 25</a>

<!-- nicht crawlbar: das Ziel entsteht erst im Browser -->
<span onclick="zeigeVariante('dn-25')">Schnellkupplung DN 25</span>

Das Ergebnis ist paradox. Ein Hersteller mit 800 konfigurierbaren Varianten hat für Google unter Umständen eine einzige Seite, nämlich die Startseite des Konfigurators. Ein Wettbewerber mit 30 schlichten HTML-Seiten je Produktgruppe hat 30 Chancen, gefunden zu werden.

Die Lösung ist nicht, den Konfigurator abzuschaffen. Er erfüllt seinen Zweck für Nutzer, die bereits auf der Seite sind. Die Lösung ist eine zusätzliche, crawlbare Ebene: statische Seiten für die gängigsten Varianten und Produktgruppen, die auf den Konfigurator führen. Sie werden aus denselben Stammdaten erzeugt, die der Konfigurator ohnehin nutzt.

Welche Varianten eine eigene Seite verdienen, entscheidet die Suchintention, nicht die interne Artikelstruktur. Faustregel aus der Praxis: eine Seite je Kombination, die ein Einkäufer so in ein Suchfeld tippen würde, meist Bauform plus Werkstoff oder Bauform plus Nennweite. Alles darunter bleibt im Konfigurator.

Wie eine auffindbare Produktseite aussieht

Für jede Produktgruppe mit eigenem Suchvolumen eine eigene Seite. Der Aufbau folgt dabei der Art, wie technisch gesucht wird.

Bezeichnung und Anwendungsfall in der Überschrift. Einkäufer suchen selten nach Ihrer internen Artikelbezeichnung, sondern nach dem, was das Teil tut, oft in Kombination mit einem Werkstoff oder einer Norm.

Die Kennwerte als HTML-Tabelle, nicht als Bild und nicht als PDF-Verweis. Maße, Werkstoffe, Toleranzen, Temperaturbereiche, erfüllte Normen. Genau diese Tabelle ist das, was ein KI-System zitieren kann. Schreiben Sie Einheiten in die Zelle, nicht nur in die Kopfzeile, denn ein herausgelöster Abschnitt trägt die Kopfzeile nicht immer mit.

Einsatzbereiche in Textform. Zwei bis drei Absätze, die beschreiben, wofür das Produkt verwendet wird und wofür nicht. Die Abgrenzung ist wertvoller, als sie wirkt, weil sie genau die Frage beantwortet, die vor einer Anfrage steht.

Strukturierte Daten vom Typ Product mit den technischen Eigenschaften als additionalProperty. Damit stehen dieselben Angaben, die in der Tabelle sichtbar sind, zusätzlich maschinenlesbar im Quelltext (schema.org/Product). Ausgeliefert wird das als JSON-LD im Kopf der Seite. Die Werte im folgenden Beispiel stehen stellvertretend für Ihre eigenen Kennwerte:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Schnellkupplung DN 25, Edelstahl 1.4404",
  "sku": "SK-25-1.4404",
  "material": "1.4404",
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Nennweite",
      "value": "25", "unitText": "mm" },
    { "@type": "PropertyValue", "name": "Betriebsdruck",
      "value": "16", "unitText": "bar" },
    { "@type": "PropertyValue", "name": "Temperaturbereich",
      "value": "-20 bis 200", "unitText": "°C" }
  ]
}
</script>

Das PDF zusätzlich anbieten, nicht ersetzend. Der Download gehört sichtbar auf die Seite, mit Dateigröße und Ausgabestand, damit niemand raten muss, ob das Datenblatt aktuell ist.

PDF, Konfigurator und HTML-Seite im direkten Vergleich

PDF und HTML-Seite nebeneinander betreiben

Sobald beide Fassungen existieren, stehen dieselben Kennwerte unter zwei Adressen. Google muss dann entscheiden, welche davon in der Suche erscheint. Ohne eine Angabe von Ihnen trifft Google diese Wahl selbst.

Steuern lässt sich das über den Canonical-Tag. Ein PDF hat allerdings keinen HTML-Kopf, in dem er stehen könnte. Für Dateien, die kein HTML sind, wertet Google deshalb einen HTTP-Header aus, den der Server zusammen mit der Datei ausliefert (Google Search Central: How to specify a canonical URL):

Link: <https://www.beispiel.de/produkte/schnellkupplung-dn-25>; rel="canonical"

Der Header sagt: Die HTML-Seite ist die maßgebliche Fassung, das PDF ist eine Ausgabe davon. Pflicht ist die Angabe nicht, sie ist ein Signal. Ein Eintrag in der XML-Sitemap wirkt in dieselbe Richtung, gilt bei Google aber als schwächeres Signal als die Canonical-Angabe.

Wenn Sie PDFs im Zuge der Umstellung an eine neue Adresse verschieben, richten Sie für die alten Dateipfade eine Weiterleitung per Statuscode 301 ein. Alte Datenblatt-Links stehen in Angeboten, Ausschreibungen und E-Mail-Archiven Ihrer Kunden und werden dort noch jahrelang angeklickt.

Schritt für Schritt zur Produktseite

Der Weg von der PDF-Ablage zu gepflegten Produktseiten läuft in fast jedem Projekt gleich ab. Sechs Schritte, in dieser Reihenfolge:

1. Produktgruppen schneiden. Legen Sie fest, welche Gruppen eine eigene Seite bekommen. Maßstab ist die Suchsprache Ihrer Kunden, nicht die Gliederung des Katalogs. Bei den meisten Mittelständlern landen Sie bei 20 bis 60 Seiten.
2. Feldliste je Gruppe festlegen. Welche Kennwerte gibt es, welche Einheit, welche Pflichtfelder. Diese Liste ist der Vertrag zwischen Warenwirtschaft und Website und entscheidet später über die Datenqualität.
3. Vorlage bauen. Eine einzige Seitenvorlage mit Überschrift, Kurzbeschreibung, Kennwerttabelle, Einsatzbereichen, Normen, Downloadbereich und JSON-LD. Alles, was danach entsteht, ist eine Befüllung dieser Vorlage.
4. Erstbefüllung automatisieren. Export aus dem Produktinformationssystem oder der Warenwirtschaft, meist als CSV, dann ein Generatorlauf. Von Hand tippen lohnt erst unterhalb von etwa zehn Seiten.
5. Verknüpfen und melden. Interne Links von den Übersichtsseiten und aus dem Konfigurator, Aufnahme in die Sitemap, Canonical-Header auf den PDFs, Weiterleitungen für alte Pfade.
6. Synchron halten und messen. Eine Schnittstelle oder ein regelmäßiger Export hält die Kennwerte aktuell. In der Google Search Console prüfen Sie nach vier bis acht Wochen, welche der neuen Seiten Impressionen sammeln und welche nicht.

Die Reihenfolge ist wichtiger, als sie aussieht. Wer mit Schritt 4 anfängt, erzeugt hunderte Seiten aus Feldern, die niemand geprüft hat, und pflegt danach jede einzelne von Hand nach.

Häufige Fehler bei der Umstellung

• Eine Seite je Variante. Aus 800 Konfigurationen 800 Seiten zu erzeugen, die sich nur in einer Zahl unterscheiden, führt zu Thin Content. Bündeln Sie auf Gruppenebene und zeigen Sie die Varianten in der Tabelle.
• Kennwerte als Bild. Eine aus dem Katalog exportierte Tabellengrafik ist auf der HTML-Seite genauso wenig verwertbar wie im PDF. Die Tabelle muss aus echten Zeilen und Spalten bestehen.
• Nur Tabelle, kein Text. Ohne beschreibende Absätze fehlt der Seite jeder Satz, den ein KI-System übernehmen könnte. Zwei Absätze zu Einsatz und Abgrenzung sind das Minimum.
• Seiten ohne internen Anschluss. Produktseiten, die nur in der Sitemap stehen und von keiner anderen Seite verlinkt sind, bleiben regelmäßig unbeachtet.

Der Aufwand und was er bringt

Bei vielen Produktgruppen klingt das nach einem großen Projekt. In der Praxis ist es überschaubar, weil die Daten bereits existieren, meist in der Warenwirtschaft oder im Produktinformationssystem.

Der übliche Weg: eine Vorlage bauen, die Daten einmalig automatisiert überführen, danach über eine Schnittstelle synchron halten. Der einmalige Aufwand liegt je nach Datenqualität im Bereich einiger Tage, nicht Wochen. Den Ausschlag gibt fast immer Schritt 2, also die Frage, wie sauber die Kennwerte im System hinterlegt sind. Liegen Maße als Freitext in einem Bemerkungsfeld, wird aus einem Tag Arbeit eine Woche.

Was es bringt, hängt am Suchvolumen. Bei technischen Produkten ist es oft klein, aber hochwertig: Wer nach einer konkreten Werkstoffkombination sucht, hat ein konkretes Vorhaben. Zehn Besucher im Monat auf einer Produktseite können mehr wert sein als tausend auf einem Ratgeber.

Rechnen Sie deshalb nicht in Besuchern, sondern in Anfragen. Ein einziger Auftrag aus einer Spezifikationssuche trägt in vielen Betrieben den gesamten Aufwand der Umstellung.

Der zweite Effekt betrifft KI-Antworten. Wenn ein Einkäufer ein Sprachmodell nach Anbietern für eine bestimmte Spezifikation fragt, kann nur genannt werden, wessen Daten als Text vorliegen. Wer seine Kennwerte ausschließlich in PDFs hält, hat an dieser Stelle nichts, was sich zitieren ließe. Die Zitierfähigkeit Ihrer Seite entscheidet damit über die Prompt-Sichtbarkeit, und beides hängt an derselben Grundlage: Kennwerte als Text, sauber abgegrenzt und für sich verständlich.