Staffelpreise und Grundpreise in WooCommerce B2B und Google Merchant Center

Der digitale B2B-Handel stellt höchste Anforderungen an die zugrunde liegende Softwarearchitektur. Geschäftskunden erwarten kundenindividuelle Preisvereinbarungen, Mindestbestellmengen (MOQ) und transparente Staffelpreise bei Großabnahmen. Gleichzeitig fordern Suchmaschinen und KI-Shopping-Assistenten standardisierte, maschinenlesbare Daten über Grundpreise und Mengenrabatte. Weichen die Werte im Datenfeed von den tatsächlichen Preisen im Warenkorb ab, lehnt das Google Merchant Center die betroffenen Produkte ab.

Wer ein zukunftssicheres Staffelpreissystem in WooCommerce etablieren möchte, muss überholte Datenstrukturen hinter sich lassen. Erforderlich sind dedizierte relationale Tabellen, speichereffiziente XML- und NDJSON-Generierungsprozesse sowie eine lückenlose semantische Auszeichnung nach Schema.org-Standards.

#Anforderungen des Google Merchant Centers an Grundpreise und Mengenstaffeln

Das Google Merchant Center definiert präzise Vorgaben für Produkte, die nach Gewicht, Volumen, Länge oder in Gebinden vertrieben werden. In der EU, den EFTA-Staaten, Großbritannien, Australien und Neuseeland verlangt Google den Grundpreis für Produkte, bei denen das lokale Recht ihn vorschreibt, in Deutschland etwa die Preisangabenverordnung (PAngV). So werden gewerbliche wie private Einkäufer in die Lage versetzt, die Wirtschaftlichkeit eines Angebots anhand eines standardisierten Grundpreises (etwa Preis pro Kilogramm, Liter oder Quadratmeter) sofort zu vergleichen.

Die wichtigsten Feed-Attribute umfassen:

1. unit_pricing_measure: Der tatsächliche Nettoinhalt der Verpackungseinheit (beispielsweise 25kg, 500ml oder 100ct). Dieser Parameter informiert den Algorithmus über die physikalische Produktmenge.
2. unit_pricing_base_measure: Die einheitliche Bezugsgröße für den Preisvergleich (etwa 1kg, 100ml oder 1ct). Google nutzt diesen Quotienten zur automatischen Berechnung der Grundpreis-Plakette.
3. auto_pricing_min_price: Der niedrigste Preis, auf den Google ein Produkt bei automatischen Rabatten und dynamischen Aktionen senken darf.
4. loyalty_program: Gruppenattribut für Mitgliederpreise, Mitgliederversand und Treuepunkte. Es ist der einzige Ort für Preise, die vom Beitritt zu einem Programm abhängen; ein eigenes Attribut für Großhandelsstaffeln gibt es nicht.

Fehlerhafte Maßeinheiten oder Währungsinkonsistenzen führen zu schweren Fehlern im Diagnosebereich des Merchant Centers. Wird ein industrieller Schmierstoff im 20-Liter-Kanister für 200 EUR angeboten, muss unit_pricing_measure exakt als 20l und unit_pricing_base_measure als 1l hinterlegt sein, damit Google den korrekten Grundpreis von 10 EUR pro Liter ausweist.

#Wie Staffelpreise im B2B-Feed für das Google Merchant Center übermittelt werden

Die Produktdatenspezifikation von Google kennt kein Attribut für Mengenstaffeln. Jeder Feed-Artikel trägt genau einen price, und die Regeln für das Attribut price legen fest, welcher Wert das sein muss. Gilt eine Mindestbestellmenge, ist der Feed-Preis der Preis für diese Mindestmenge: Google schreibt, dass kein Einzelstückpreis übermittelt werden soll, wenn Kunden nicht ein einzelnes Stück kaufen können. Bei einem vom Händler zusammengestellten Multipack oder Set ist der Preis die Summe für das gesamte Paket.

Damit bleiben drei praktikable Wege, eine Mengenstaffel abzubilden:

1. Getrennte Gebindeartikel. Jede Gebindegröße (Eimer, Karton, Palette) wird zu einem eigenen Artikel mit eigener id, eigenem price und eigenem unit_pricing_measure, und alle teilen dieselbe item_group_id. Die Dokumentation zu unit_pricing_measure zeigt dieses Muster mit Reis in 5-, 10- und 12-Pfund-Beuteln, jeweils mit einer Bezugsgröße von 1 Pfund, sodass der Grundpreis zeigt, welches Gebinde pro Gewichtseinheit günstiger ist.
2. Das Attribut multipack. Laut der Seite zu multipack ist es für Pakete gedacht, die der Händler aus identischen Produkten zusammenstellt, und für kostenlose Einträge Pflicht, sobald Sie ein solches Paket anlegen. Bei einem vom Hersteller definierten Gebinde entfällt multipack, die Stückzahl steht dann in unit_pricing_measure.
3. Die Staffeltabelle bleibt im Shop. Rabatte oberhalb der Mindestmenge liegen in WooCommerce und auf der Produktseite, während der Feed den Einstiegspreis überträgt. Diese Variante vervielfacht keine Artikelnummern und bleibt stimmig, solange die Landingpage denselben Einstiegspreis zeigt.

Für den Grundpreis selbst müssen beide Attribute denselben Einheitentyp verwenden, und unit_pricing_base_measure akzeptiert nur bestimmte Werte: 1, 2, 4, 8, 10 oder 100 einer Einheit sowie 75cl, 750ml, 50kg und 1000kg (unit_pricing_base_measure). Die Mengenangabe erlaubt höchstens zwei Nachkommastellen. Für Großbritannien liest Google imperiale Einheiten als US-Einheiten, metrische Werte sind dort also die sichere Wahl. Trägt ein Artikel sowohl unit_pricing_measure als auch eine Energieeffizienzklasse, zeigt Google nur die Energieeffizienzklasse.

#Welche Regeln zu Landingpage und Checkout B2B-Produkte im Merchant Center ablehnen lassen

Die meisten B2B-Ablehnungen entstehen aus der Lücke zwischen Feed und dem, was der Käufer sieht. Die Regeln für das Attribut price enthalten genau die Vorgaben, die mit typischen Großhandelsmodellen kollidieren:

• Der Feed-Preis muss dem Preis auf der Landingpage und im Checkout entsprechen, in der Währung des Ziellandes, und “Preis im Warenkorb anzeigen” ist nicht zulässig.
• Jeder Nutzer im Zielland muss zum übermittelten Preis kaufen können. Ein Kundenkonto darf nur verlangt werden, wenn die Registrierung kostenlos und unkompliziert ist. Das schließt Feeds aus, deren Preise nur freigeschaltete Geschäftskonten sehen.
• In Ländern wie Deutschland, Frankreich oder Großbritannien enthält der Preis die Mehrwertsteuer, und Google wendet das auch auf Großhandelsangebote an. In den USA und Kanada bleiben Steuern außerhalb des Preises.
• Ein Mindestbestellwert gehört nicht in den Preis, sondern in die Versandeinstellungen.

Vertrags- und Mitgliederpreise haben einen eigenen Kanal. Google legt fest, dass Mitgliederpreise weder in price noch in sale_price stehen dürfen. Sie gehören in das Gruppenattribut loyalty_program mit Unterattributen wie program_label, tier_label, price, loyalty_points und member_price_effective_date. Das Programm muss vorher im Merchant Center eingerichtet sein, Mitgliederpreise müssen für Mitglieder im Shop sichtbar sein, und Google zeigt Mitgliederpreise in Anzeigen nur, wenn der Rabatt mindestens 5 % oder 5 Währungseinheiten beträgt. Googles Beispiele sind Kundenstufen wie Silber und Gold, keine verifizierten Geschäftskonten. Ein B2B-Shop muss also prüfen, ob seine Händlerpreisliste überhaupt in dieses Modell passt.

Eine befristete Staffelaktion gehört in sale_price, der niedriger als price sein muss. Der reguläre Preis wird weiter in price übermittelt, die Landingpage zeigt beide Preise, der Checkout nur den Aktionspreis, und sale_price_effective_date begrenzt den Zeitraum; ohne dieses Attribut gilt der Aktionspreis sofort. auto_pricing_min_price ist ein anderes Werkzeug: Das Attribut für den Mindestpreis ist für automatische Rabatte und dynamische Aktionen Pflicht und muss zwischen den Herstellungskosten, sofern übermittelt, und 95 % des regulären Preises liegen.

#Leistungsgrenzen von wp_postmeta und eine eigene Staffelpreistabelle

Das Standarddatenmodell von WordPress basiert auf dem Entity-Attribute-Value-Prinzip (EAV), bei dem alle Produkt- und Variantendaten in der zentralen Tabelle wp_postmeta landen. Für einfache B2C-Shops reicht dieser Ansatz völlig aus. Im komplexen B2B-Umfeld, in dem ein Artikel über 5 Mengenstaffeln für 8 verschiedene Kundengruppen verfügt, gerät das System schnell an seine Grenzen.

Das Speichern von 40 Preisregeln für ein einzelnes Produkt erzeugt 40 Zeilen in wp_postmeta. Bei einem Sortiment von 30.000 Produkten und 100.000 Varianten wächst die Tabelle rasch auf zig Millionen Datensätze an. Jede Abfrage im Shopkatalog erfordert mehrfache LEFT JOIN-Operationen, was zu Sperren in der MySQL-Datenbank und spürbaren Verzögerungen führt.

High-Performance Order Storage (HPOS) löst das nicht von selbst. Laut der HPOS-Dokumentation von WooCommerce verlagert es Bestellungen und Bestelladressen in vier eigene Tabellen (wc_orders, wc_order_addresses, wc_order_operational_data und wc_orders_meta), Produkte bleiben in den Beitragstabellen. HPOS liefert aber das Muster: Daten mit bekannter Struktur bekommen eine eigene Tabelle mit Indizes, die zu den Abfragen passen. Für Staffelpreise heißt das eine separate Tabelle mit zusammengesetzten Indizes:

-- Dedizierte relationale Tabelle fuer performante B2B-Staffelpreise
CREATE TABLE IF NOT EXISTS wp_wc_b2b_price_tiers (
    tier_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    product_id BIGINT UNSIGNED NOT NULL,
    customer_group VARCHAR(32) NOT NULL DEFAULT 'all',
    min_quantity INT UNSIGNED NOT NULL DEFAULT 1,
    max_quantity INT UNSIGNED DEFAULT NULL,
    price_cents BIGINT NOT NULL,
    currency CHAR(3) NOT NULL DEFAULT 'EUR',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_product_lookup (product_id, customer_group, min_quantity),
    INDEX idx_pricing_search (min_quantity, max_quantity)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Dank des zusammengesetzten Index (product_id, customer_group, min_quantity) wird die Suche nach Produkt, Kundengruppe und Menge zu einem einzigen Bereichszugriff auf den Index statt einer Kette von Joins auf wp_postmeta. Durch den Verzicht auf Abfragen gegen wp_postmeta sinkt die CPU-Belastung drastisch und der InnoDB Buffer Pool bleibt entlastet.

Weiterführende Konzepte zur Anbindung leistungsfähiger Shopsysteme an zentrale ERP-Landschaften finden Sie in unserem Beitrag über woocommerce erp integration.

#Speichereffizientes Streaming von XML- und NDJSON-Datenfeeds

Der regelmäßige Export zehntausender B2B-Artikel samt komplexer Staffelpreise an das Google Merchant Center verlangt eine robuste Streaming-Infrastruktur. Der Versuch, das gesamte Sortiment über PHP-Standardmethoden wie wc_get_products() auf einmal in den Arbeitsspeicher zu laden, führt unausweichlich zu fatalen Speicherüberläufen (memory_limit).

Moderne Export-Engines setzen auf Datenbank-Cursor in Verbindung mit PHP-Generatoren (yield). Dabei werden die Produktdaten in überschaubaren Paketen direkt in die Zieldatei auf dem Server geschrieben oder als NDJSON-Stream an Cloud-Speicher übermittelt:

<?php
/**
 * Speicheroptimierter Generator fuer Google Merchant Center Feeds
 */
declare(strict_types=1);

namespace WPPoland\B2BFeedsDE;

use Generator;
use wpdb;

class StreamedProductFeedGenerator
{
    private wpdb $db;

    public function __construct(wpdb $db)
    {
        $this->db = $db;
    }

    public function streamCatalogBatch(int $batchSize = 500): Generator
    {
        $offset = 0;

        while (true) {
            $query = $this->db->prepare(
                "SELECT p.ID, p.post_title, t.min_quantity, t.price_cents, t.currency
                 FROM {$this->db->posts} p
                 INNER JOIN wp_wc_b2b_price_tiers t ON p.ID = t.product_id
                 WHERE p.post_type IN ('product', 'product_variation')
                   AND p.post_status = 'publish'
                   AND t.customer_group = 'wholesale_tier_1'
                 ORDER BY p.ID ASC
                 LIMIT %d OFFSET %d",
                $batchSize,
                $offset
            );

            $rows = $this->db->get_results($query, ARRAY_A);

            if (empty($rows)) {
                break;
            }

            foreach ($rows as $row) {
                yield $this->formatGoogleXmlNode($row);
            }

            $offset += $batchSize;
        }
    }

    private function formatGoogleXmlNode(array $product): string
    {
        $price = number_format($product['price_cents'] / 100, 2, '.', '');
        return sprintf(
            "<item>\n  <g:id>%d</g:id>\n  <g:title><![CDATA[%s]]></g:title>\n  <g:price>%s %s</g:price>\n  <g:min_handling_time>1</g:min_handling_time>\n</item>\n",
            $product['ID'],
            htmlspecialchars($product['post_title'], ENT_QUOTES, 'UTF-8'),
            $price,
            $product['currency']
        );
    }
}

Da immer nur ein Block von 500 Zeilen im Speicher liegt, hängt der Speicherbedarf von der Blockgröße ab und nicht von der Größe des Sortiments. Wird die Generierung über WP-CLI-Hintergrundjobs oder System-Cron-Befehle gesteuert, bleibt der normale Shopbetrieb von Lastspitzen völlig unberührt.

Um Schnittstellen und vertrauliche Großhandelspreise vor unbefugtem Zugriff zu schützen, empfehlen wir ein regelmäßiges wordpress sicherheitsaudit.

#Semantische Datenauszeichnung mit PriceSpecification und unitCode

Für eine fehlerfreie Interpretation durch Suchmaschinen und KI-Systeme müssen Staffel- und Grundpreise präzise im Quellcode der Produktseite hinterlegt sein. Schema.org beschreibt Grundpreise über den Typ UnitPriceSpecification, der in einem Angebot verschachtelt wird.

Zur Kennzeichnung der Maßeinheiten sollten offizielle UN/CEFACT-Codes verwendet werden (beispielsweise KGM für Kilogramm, LTR für Liter, MTK für Quadratmeter und C62 für Stückzahlen):

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Strukturklebstoff auf Polyurethanbasis, 5-kg-Eimer",
  "sku": "ADH-IND-500",
  "offers": {
    "@type": "Offer",
    "price": "240.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "price": "240.00",
      "priceCurrency": "EUR",
      "referenceQuantity": {
        "@type": "QuantitativeValue",
        "value": 5,
        "unitCode": "KGM",
        "valueReference": {
          "@type": "QuantitativeValue",
          "value": 1,
          "unitCode": "KGM"
        }
      }
    }
  }
}

Die Google-Dokumentation zu Händlereinträgen schränkt ein, was Schema.org erlaubt. Händlereinträge brauchen ein Offer, weil der Händler der Verkäufer sein muss; AggregateOffer wird nur für Produkt-Snippets akzeptiert. Der Grundpreis steht in priceSpecification als UnitPriceSpecification, wobei referenceQuantity die zum Preis verkaufte Menge und valueReference die Bezugsgröße angibt, also die Gegenstücke zu unit_pricing_measure und unit_pricing_base_measure. Im Beispiel enthält der Eimer 5 kg, der Preis von 240 EUR entspricht also 48 EUR pro Kilogramm. Als priceType unterstützt Google nur StrikethroughPrice, Mitgliederpreise nutzen validForMemberTier zusammen mit einem regulären Preis, und eine Spezifikation, die beides kombiniert, wird ignoriert. eligibleQuantity erwähnt die Seite nicht. Staffeln oberhalb des Einstiegspreises sollten Sie in den Google-Ergebnissen also nicht erwarten; das Markup überträgt den Einstiegspreis, denselben wie der Feed.

#Serverseitiges Caching bei personalisierten Großhandelspreisen

Klassisches Full-Page-Caching (etwa über FastCGI-Cache in Nginx oder Redis) versagt im B2B-Bereich, wenn eingeloggte Geschäftskunden unterschiedliche Vertragskonditionen sehen. Das Deaktivieren des Caches für alle angemeldeten Benutzer treibt die Serverlast nach oben und verschlechtert die Time to First Byte (TTFB).

Eine zukunftsfähige Auslieferungsarchitektur setzt auf ein hybrides Modell:

1. Statisches Caching des Produktgerüsts: Beschreibungen, Bilder, Datenblätter und Navigationsstrukturen werden global auf CDN-Ebene im Cache gehalten.
2. Asynchrone Preisnachladung (Edge Side Includes oder Micro-REST-Endpunkte): Nach dem Laden der Grundseite ruft der Browser die spezifische Preisstaffel des Kunden über eine schlanke REST-Anfrage ab.
3. Dynamische DOM-Aktualisierung: Ein leichtgewichtiges JavaScript-Modul aktualisiert die Preisanzeige und Warenkorbfunktion direkt im Client, ohne den globalen Seitencache zu entwerten.

Bei anspruchsvollen Enterprise-Shops bietet eine entkoppelte Architektur maximale Flexibilität und Performance. Erfahren Sie mehr über unsere Arbeitsweise im Bereich headless wordpress.

#ERP-Synchronisation und transaktionale Datenkonsistenz

Die Preisstimmigkeit zwischen dem Onlineshop und dem Google Merchant Center hängt entscheidend von der Synchronisationsfrequenz mit dem Warenwirtschaftssystem ab. Ändern sich Rohstoff- oder Einkaufspreise im ERP-System, müssen diese Aktualisierungen unmittelbar im Shop und in den Schnittstellen zu Google abgebildet werden.

Hierbei empfiehlt sich der Einsatz von Action-Scheduler-Warteschlangen und ereignisgesteuerten Webhooks. Jede Preisänderung triggert eine Aktualisierung in der Tabelle wp_wc_b2b_price_tiers und stößt anschließend eine Aktualisierung über die Google Merchant API an, ohne dass der nächste turnusmäßige Feed-Lauf abgewartet werden muss.

Eine bidirektionale Synchronisation mit Transaktionspuffern schützt die Datenbank zuverlässig vor Sperrzuständen bei starkem Bestellaufkommen. Abweichungen zwischen ERP-Lagerbestand und Webshop werden lückenlos protokolliert und dem Betriebsteam zur Behebung gemeldet.

#Was Google for WooCommerce zuordnet und wofür ein eigener Feed nötig ist

Die offizielle Erweiterung Google for WooCommerce deckt einen Teil dieser Einrichtung ab. Ihre Attributzuordnung unterstützt 15 Google-Attribute, darunter Multipack, Is Bundle, GTIN, MPN und Brand. Eine Regel kann für alle Kategorien gelten, für alle außer ausgewählten oder für eine einzelne Kategorie. Regeln füllen nur leere Attribute, und Werte im Google-Tab eines Produkts haben Vorrang. Regeln lesen ausschließlich globale Attribute; Attribute, die auf der Seite eines einzelnen Produkts angelegt wurden, müssen also zuerst global werden.

Die Grundpreis-Mengenangabe steht nicht auf dieser Liste. Ein Shop, der nach Gewicht, Volumen oder Fläche verkauft, braucht deshalb Werte pro Produkt oder eine eigene Feed- oder API-Anbindung für unit_pricing_measure und unit_pricing_base_measure. Dasselbe gilt für getrennte Gebindeartikel aus einer eigenen Staffeltabelle, die die Erweiterung nicht kennt.

Die Übertragungsschicht hat sich 2026 geändert. Google führt die Content API for Shopping als am 18. August 2026 eingestellt, Anfragen schlagen ab dem 1. September 2026 schrittweise fehl, und Google verweist auf die Merchant API. Google for WooCommerce hat den Wechsel mit Version 3.8.1 vollzogen. Eine eigene Integration schreibt Produkte über ProductInput-Ressourcen mit insert, patch und delete, liest die verarbeiteten Product-Ressourcen und kann nur in Datenquellen vom Typ API schreiben, wie der Produktleitfaden der Merchant API beschreibt.

#Automatisierte Testverfahren und Fehlervermeidung in der Preislogik

In komplexen B2B-Shopsystemen können Rechenfehler in den Staffelpreisen verheerende wirtschaftliche und rechtliche Folgen nach sich ziehen. Weicht der im Merchant Center beworbene Nettopreis vom tatsächlichen Rechnungsbetrag ab, drohen Abmahnungen nach dem Gesetz gegen den unlauteren Wettbewerb (UWG) sowie der Ausschluss aus Google Shopping.

Eine professionelle Qualitätssicherung erfordert automatisierte Integrations- und Unit-Tests, die Preiskalkulationen bei jedem Software-Deployment lückenlos überprüfen:

<?php
/**
 * Automatisierter Integrationstest fuer B2B-Staffelpreise und Grundpreisberechnung
 */
declare(strict_types=1);

namespace WPPoland\Tests\Pricing;

use PHPUnit\Framework\TestCase;
use WPPoland\B2BFeedsDE\StreamedProductFeedGenerator;

class TieredPricingCalculationTest extends TestCase
{
    public function testTieredPriceSelectionForBulkQuantity(): void
    {
        $calculator = new \WPPoland\Pricing\TieredPriceCalculator();
        
        // Testet Artikel mit Basispreis 48 EUR und Staffelpreis 34 EUR ab 10 Stueck
        $unitPriceSingle = $calculator->resolveEffectivePrice(
            productId: 1042,
            quantity: 5,
            customerGroup: 'wholesale_tier_1'
        );
        $this->assertEquals(4800, $unitPriceSingle, 'Mengen unter dem Schwellenwert muessen den Grundtarif abrechnen.');

        $unitPriceBulk = $calculator->resolveEffectivePrice(
            productId: 1042,
            quantity: 12,
            customerGroup: 'wholesale_tier_1'
        );
        $this->assertEquals(3400, $unitPriceBulk, 'Mengen ab 10 Einheiten muessen die verguenstigte Staffel erhalten.');
    }

    public function testBaseMeasureDenominatorIntegrity(): void
    {
        $feedHelper = new \WPPoland\B2BFeedsDE\FeedAttributeValidator();
        
        $validMeasure = $feedHelper->validateUnitPricingAttributes(
            measure: '25kg',
            baseMeasure: '1kg'
        );
        $this->assertTrue($validMeasure, 'Gueltige metrische Einheiten muessen die Validierung erfolgreich passieren.');

        $invalidMeasure = $feedHelper->validateUnitPricingAttributes(
            measure: '25kilo',
            baseMeasure: 'einheiten'
        );
        $this->assertFalse($invalidMeasure, 'Nicht-standardisierte Bezeichnungen muessen abgelehnt werden.');
    }
}

Diese Testroutinen stellen sicher, dass Rundungsfehler bei Nachkommastellen oder fehlerhafte Währungskonvertierungen in Fremdwährungen sofort erkannt werden, bevor Daten an externe Schnittstellen übertragen werden.

#Technische Checkliste vor dem Start in Google Shopping B2B

Vor dem Rollout von B2B-Kampagnen sollten folgende Punkte überprüft werden:

1. Prüfung der Maßeinheiten: Sicherstellen, dass unit_pricing_measure und unit_pricing_base_measure nur Einheiten aus der von Google unterstützten Liste und einen zulässigen Bezugswert verwenden.
2. Warenkorb-Validierung: Prüfen, ob der Wechsel in eine höhere Rabattstufe den korrekten Staffelpreis im Checkout fehlerfrei berechnet.
3. GTIN- und MPN-Konsistenz: Gewährleisten, dass alle Gebinde und Verpackungseinheiten mit registrierten GS1-Barcodes versehen sind.
4. Datenbank-Lasttests: SQL-Abfragen für 1.000 parallele Katalogaufrufe unter Lastbedingungen testen und optimieren.
5. Rich-Results-Validierung: Produkt-URLs im offiziellen Google-Testwerkzeug auf Warnungen bezüglich UnitPriceSpecification prüfen.
6. Speicherlimits beim Feed-Export: Kontrollieren, dass der PHP-Spitzenspeicher bei der Feederstellung auch bei wachsendem Sortiment stabil bleibt.
7. Fehler-Monitoring: Automatische Benachrichtigungen bei Produktablehnungen aus der Merchant-Center-Diagnose oder der Merchant API einrichten.
8. Verschlüsselung und Schnittstellensicherheit: TLS 1.3 und strikte Authentifizierungsrichtlinien für alle Preis-Endpunkte durchsetzen.
9. B2B-Lieferbedingungen konfigurieren: Im Merchant Center explizite Fracht- und Speditionsregeln für Palettenware hinterlegen.
10. Notfallschalter (Kill Switch): Einen Fallback einrichten, der statische Standardpreise anzeigt, wenn die ERP-Verbindung vorübergehend ausfällt.

Die professionelle Umsetzung von B2B-Preisstrukturen erfordert fundiertes technologisches Know-how an der Schnittstelle von Datenbankdesign und E-Commerce-Standards. Wenn Sie Unterstützung bei der Optimierung Ihrer B2B-Infrastruktur wünschen, freuen wir uns über Ihre Nachricht über unsere kontaktseite.