Den Content in Seller Central einspielen — die vier Wege, die tatsächlich auf der ASIN landen.

Am Ende von Episode 08 war das Keyword-Brief vollständig platziert: Der Titel trug die Head-Terms, die Bullets die nächste Synonym-Schicht, die Beschreibung wiederholte entweder das Angebot für die Fallback-Flächen oder wurde für A+ leer gelassen, und der unsichtbare 250-Byte-Backend-Slot moppte jeden verbleibenden Synonym auf. Nichts davon ist live. Der Content muss noch in Seller Central gepusht werden, die Contribution-Rule-Logik überstehen, die entscheidet, welche Version jedes Feldes gewinnt, und darf nicht still von einem älteren Feed oder einem anderen Contributor auf derselben ASIN überschrieben werden.

Seller Central bietet vier Upload-Pfade für Listing-Content. Von außen sehen sie austauschbar aus — sind sie aber nicht. Den falschen Pfad für die Größe der Änderung zu wählen ist der häufigste Einzelgrund, warum ein fertiges Brief nie auf der Live-Detail-Page landet.

Die vier Upload-Pfade, nach Größenordnung geordnet

Von der kleinsten zur größten Änderung sind die vier Pfade:

• Die Einzel-Bearbeitungs-UI in Seller Centrals Lagerbestand verwalten → Bearbeiten-Ansicht. Feld für Feld, eine ASIN nach der anderen. Geeignet für einmalige Korrekturen und die erste manuelle Einrichtung eines einzelnen Produkts.
• Der Inventar-Flat-File — das kategoriespezifische Excel-Template, das über Lagerbestand → Produkte per Upload hinzufügen heruntergeladen wird. Geeignet für jede Änderung, die mehr als eine Handvoll ASINs betrifft, alles, was eine Header-Spalte benötigt, die in der UI nicht verfügbar ist, und alles, das wiederholbar sein muss.
• Build International Listings (BIL) — die Quell-Marktplatz → Ziel-Marktplatz-Synchronisation. Geeignet für das Ausrollen eines fertigen Briefs von einem „Heim“-Marktplatz auf weitere EU-Marktplätze, ohne das Listing fünfmal neu schreiben zu müssen.
• Die SP-API / Listings API — Partner-Tool- oder interne Integration. Geeignet für laufendes Katalogmanagement im großen Maßstab, für Tools, die dieselben Felder nach einem Zeitplan zurückschreiben müssen, und für alles, das den Flat-File-Upload-Rhythmus überwachsen hat.

Die Entscheidungsregel ist einfach: den kleinsten Pfad verwenden, der zur Änderung passt. Die UI für einen einzelnen Tippfehler. Der Flat-File für ein Brief. BIL, wenn dasselbe Brief auf vier Marktplätze muss. Die API nur, wenn ein Tool das Feld bereits besitzt.

Pfad 1 — die Einzel-Bearbeitungs-UI

Man öffnet Lagerbestand verwalten, findet die ASIN, klickt auf Bearbeiten, und Seller Central rendert die Detail-Page-Felder gruppiert in dieselben Reiter, die der Flat-File verwendet: Wesentliche Informationen, Varianten, Angebot, Compliance, Bilder, Beschreibung, Schlüsselwörter, Weitere Details. Titel, Bullets und Produktbeschreibung befinden sich unterBeschreibung. Backend-Search-Terms befinden sich unter Schlüsselwörter → Suchbegriffe. Attribute, die als Filter-Facetten verwendet werden, befinden sich unter Weitere Details.

Drei Fallstricke auf Feldebene, die erstmalige Bearbeiter erwischen:

• Bullet-Point-Felder werden beim Speichern von HTML befreit. Fett-Tags, Zeilenumbrüche und jegliches Markup, das aus einem Word-Dokument eingefügt wird, werden entfernt. Nur Plain-Text schreiben oder einfügen; mit Großbuchstaben und Emoji formatieren, wenn die Kategorie sie erlaubt, nicht mit HTML.
• Das Produktbeschreibungsfeld verträgt eine schmale HTML-Teilmenge — Zeilenumbrüche (<br>) und Absatz-Tags überleben in den meisten Kategorien, fast alles andere wird entfernt. Die Beschreibung aus Modul 8 Episode 07 mit <br>-Umbrüchen bei der ~160-Zeichen-Leerzeichen-Regel ausführen, nicht mit freiem Markup.
• Das Search-Terms-Feld ist eine einzelne Zeichenkette, keine Liste von Slots. Den fertigen 245-Byte-Token-Stream aus Episode 08 einfügen, einzelne Leerzeichen, Kleinbuchstaben, keine Kommas. Seller Central zeigt eine Zeichenanzahl, keine Byte-Anzahl — vorher im Listing-Tool prüfen.

Pfad 2 — der Inventar-Flat-File

Der Flat-File ist der bei weitem wichtigste Upload-Pfad in Seller Central und der, auf dem fast jedes Produktions-Listing letztendlich lebt. Das kategoriespezifische Template unter Lagerbestand → Produkte per Upload hinzufügen → Inventar-Datei herunterladen herunterladen, den Template-Reiter ausfüllen, als tabulatorgetrenntes .txt speichern und unter Produkte per Upload hinzufügen hochladen. Amazon verarbeitet die Datei asynchron und gibt einen zeilenweisen Verarbeitungsbericht zurück — diesen lesen. Der Verarbeitungsbericht ist das einzige zuverlässige Signal, dass eine Zeile angekommen ist.

Die Spalten, auf die das Modul-8-Brief abgebildet wird:

• item_name — der Titel aus Episode 05.
• bullet_point1 bis bullet_point5 — die Bullets aus Episode 06.
• product_description — die Beschreibung aus Episode 07 (oder leer gelassen, wenn A+ sie vollständig ersetzt hat).
• generic_keywords — der 245-Byte-Backend-Token-Stream aus Episode 08.
• intended_use1…n, target_audience1…n, subject_keywords1…n — die benachbarten Backend-Slots, die ebenfalls zur Indexierung beitragen.
• Kategoriespezifische Attributspalten — Material, Oberfläche, Kapazität, Kompatibilität, Sport, Anlass — jede davon kann als SERP-Filter-Facette auftauchen.

Zwei Flat-File-Regeln ersparen Wochen des Debuggings:

• Den Partial-Update-Dateityp für Content-Bearbeitungen verwenden. Die update_delete-Spalte auf jeder Zeile auf PartialUpdate setzen. Ohne diese Einstellung überschreiben leere Zellen in der Datei Live-Werte auf der ASIN als „absichtlich leer“ — stiller Datenverlust.
• Immer mit einem frisch heruntergeladenen Template arbeiten. Amazon fügt Spalten hinzu, benennt sie um und zieht sie Kategorie für Kategorie zurück. Ein altes Template zu bearbeiten kann Zeilen unter einem veralteten Header einreichen, den der neue Validator ablehnt, und der Verarbeitungsbericht beschuldigt die Zeile, nicht die Template-Version.

Pfad 3 — Build International Listings

BIL ist der Eins-zu-viele-Pfad. Einen Quell-Marktplatz festlegen (typischerweise der Marktplatz, für den das Brief geschrieben wurde), die Ziel-Marktplätze auswählen, und Amazon synchronisiert Katalogdaten von der Quelle zum Ziel nach einem wiederkehrenden Zeitplan. Preisregeln sind pro Ziel konfigurierbar; Content (Titel, Bullets, Beschreibung, Bilder, Attribute) spiegelt die Quelle, außer er wird auf dem Ziel explizit überschrieben.

BIL ist der richtige Pfad, um ein fertiges EU-Brief über DE → FR/IT/ES/NL/PL/SE auszurollen, ohne fünf Flat-Files hochzuladen. Es ist der falsche Pfad, wenn das Brief selbst lokalisiert werden muss — übersetzt, auf lokale Suchgewohnheiten ausgerichtet oder gegen den Style Guide einer lokalen Kategorie neu aufgebaut. In diesen Fällen nur das Angebot und die Bilder per BIL spiegeln und die Content-Felder pro Marktplatz neu schreiben.

Der Fallstrick: Sobald BIL für ein Ziel aktiv ist, wird jede manuelle Bearbeitung auf diesem Ziel-Marktplatz beim nächsten Sync überschrieben, es sei denn, die Bearbeitung wurde auch auf dem Quell-Marktplatz vorgenommen. Bearbeiter auf dem Ziel-Marktplatz müssen wissen, dass BIL läuft; sonst verbringen sie einen Nachmittag damit, einen Titel zu korrigieren, der sich über Nacht wieder zurücksetzt.

Pfad 4 — die SP-API-Listings-Endpoints

Der SP-API-Listings-Items-Endpoint schreibt dieselben Felder wie der Flat-File, auf einer Attribut-Granularitätsebene, mit einer sofortigen Status-Antwort pro Anfrage statt eines gebündelten Verarbeitungsberichts. Es ist der richtige Pfad, wenn ein Tool das Feld bereits besitzt — ein PIM, eine AMALYZE-artige Listing-Plattform, ein interner Katalog-Manager — und der Upload-Rhythmus kontinuierlich statt periodisch ist.

Die API ändert nicht die Contribution-Rule-Logik, die entscheidet, welche Version eines Feldes gewinnt (siehe unten). Sie macht den Schreibvorgang nur schnell und maschinell prüfbar. Für die meisten Teams, die keine interne Integration betreiben, ist der Flat-File der richtige Pfad, bis der Katalog darüber hinauswächst.

Der Contribution-Rule-Fallstrick — wessen Content tatsächlich gewinnt

Dies ist das am meisten missverstandene Element in Seller Central. Amazons Katalog ist geteilt — mehrere Seller können zur selben ASIN beitragen, und Amazons Katalog-Engine wählt pro Feld basierend auf einem Contribution-Score den Wert des Contributors aus, der angezeigt wird. Brand-Registry-Beiträge tragen das höchste Gewicht, dann GS1-verifizierte Beiträge, dann wiederholte Beiträge, dann alles andere.

Praktische Konsequenzen beim Drücken von Speichern:

• Bei einer Marke, die man besitzt und registriert hat, gewinnt der eigene Beitrag für die markeneigenen Felder — Titel, Bullets, Beschreibung, Bilder, A+ Content. Der Upload wird innerhalb von Minuten live.
• Bei einer Marke, die man nicht besitzt, aber weiterverkauft, wird der Beitrag zwar erfasst, verliert aber typischerweise gegen den des Markeninhabers. Das Listing erscheint nach dem Upload unverändert — nicht weil der Upload fehlschlug, sondern weil Amazon den Wert des Contributors mit höherem Vertrauen für das Rendering ausgewählt hat.
• Bei einer brandneuen ASIN ohne vorherige Beiträge tendiert der erste vollständige Beitrag dazu zu gewinnen, bis ein Beitrag mit höherem Vertrauen eintrifft. Die Einrichtung einer neuen ASIN ist der einzige Moment, in dem ein Nicht-Markeninhaber die Detail-Page entscheidend gestalten kann.

Der Audit-Schritt, der dies erkennt: Die Live-Detail-Page 24 Stunden nach dem Upload mit dem Brief abgleichen. Zeigt ein Feld noch den alten Wert, hat der Upload nicht versagt — der Beitrag hat verloren. Die Lösung ist Brand-Registry- oder GS1-Dokumentation, kein weiterer Upload.

Vendor Central — dieselben Felder, ein anderer Eingang

Vendoren haben nicht Seller Centrals Einzel-Bearbeitungs-UI für Content. Die entsprechenden Pfade sind:

• Item-Setup-Formular in Vendor Central — das nächste Analogon zur UI-Bearbeitung, eine ASIN nach der anderen, mit einer 24–72-stündigen Propagierungsverzögerung und gelegentlichen Überarbeitungen durch Amazons Katalog-Team.
• Katalog-Feed per Bulk-Upload in Vendor Central — das Analogon zum Flat-File, mit demselben zeilenweisen Verarbeitungsbericht in einem langsameren Rhythmus.
• Die Vendor Direct Fulfillment / Retail Analytics API für Partner mit API-Zugang.

Die Contribution-Rule-Logik gilt auch auf der Vendor-Seite, aber Vendor-Beiträge sind auf einer höheren Stufe als die meisten Seller-Beiträge bei ASINs, die sowohl 1P als auch 3P verkauft werden — Vendor-Bearbeitungen gewinnen normalerweise bei gemeinsam gelisteten ASINs.

Das Post-Upload-Audit

Den Upload als Schritt behandeln, nicht als Ziellinie. Die Fünf-Minuten-Audit-Checkliste, nachdem ein Brief live geht:

1. Die Live-Detail-Page in einem Inkognito-Fenster öffnen — niemals nur die Seller-Central-Vorschau.
2. Titel, Bullets und Beschreibung Zeichen für Zeichen mit dem Brief abgleichen.
3. Bestätigen, dass das neue Hauptbild und die Galeriereihenfolge gerendert wurden.
4. Die Backend-Token-Liste gegen eine Testabfrage prüfen, die neu indexiert werden sollte (den Brand Analytics Search Terms Report 48–72 Stunden später für das tatsächliche Indexierungssignal verwenden — die Live-Page zeigt das Backend-Feld nicht an).
5. Prüfen, dass jeder veraltete Wert (ein alter Bullet, ein veraltetes Attribut) tatsächlich ersetzt und nicht nur ergänzt wurde.

Alles, was das Audit aufdeckt, geht durch den kleinsten Pfad zurück, der zur Korrektur passt — normalerweise die Einzel-Bearbeitungs-UI für eine einzeilige Korrektur oder ein gezielter Partial-Update-Flat-File für alles Umfangreichere.

Was diese Episode übergibt

Episode 09 macht aus dem fertigen Brief eine Live-Detail-Page. Von hier aus führt Modul 8 weiter in den Higher-Surface-Content, den der Upload-Pfad eröffnet: A+ Content-Module, A+ Premium, Brand Story 1.0 und 2.0 und den Brand Store — all diese leben auf derselben ASIN, durchlaufen aber ihre eigene Contribution-Rule-Logik und ihren eigenen Upload-Rhythmus.