Versand & Zahlungsmethoden
Diese beiden Tabs füttern die Unterknoten jedes Angebots: Versand liefert OfferShippingDetails, Zahlungsmethoden liefert acceptedPaymentMethod. Zusammen mit der Rückgabe machen sie deine Offer-Knoten vollständig — genau die Felder, die Google Merchant Listings und KI-Agenten besonders gewichten.
Tab „Versand”
Ein Eintrag pro Zielland. Jede aktive Zeile erzeugt einen OfferShippingDetails-Block — einmal für den kostenpflichtigen Versand und, sobald eine Gratisversand-Schwelle angegeben ist, automatisch einen zweiten Block für den Gratisversand.
- Öffne Plugins → Structured Data → Versand.
- Trage Land (ISO-Code, z. B.
DE) und Währung (ISO-4217, z. B.EUR) ein. - Setze die Versandpauschale (Brutto, Dezimaltrennzeichen ist der Punkt, z. B.
4.90). - Optional: Gratisversand ab einem Mindestbestellwert. Leer = kein Gratisversand.
- Hinterlege Bearbeitungs- und Lieferzeit als min–max in Werktagen. Speichern.
| Feld | Standard | Bedeutung |
|---|---|---|
| Land | DE | ISO-3166-1 alpha-2 Zielland. |
| Währung | EUR | ISO-4217 Währungscode. |
| Versandpauschale | 4.90 | Brutto-Versandkosten in der angegebenen Währung. |
| Gratisversand ab | – | Mindestbestellwert für Gratisversand. Leer = keiner. |
| Bearbeitungszeit (min–max) | 0–1 | Werktage Lager → Übergabe an Versand → handlingTime. |
| Lieferzeit (min–max) | 1–3 | Werktage Versand → Zustellung → transitTime. |
Tab „Zahlungsmethoden”
Das Plugin liest deine aktiven JTL-Zahlungsmodule automatisch aus und ordnet sie dem passenden schema.org-Typ (GoodRelations-URI) zu. In den meisten Shops ist hier nichts zu tun — ein Status-Banner oben zeigt dir, ob alle Module erkannt wurden.
Eine Übersicht listet jedes aktive Modul mit seinem Erkennungsstatus:
| Status | Bedeutung |
|---|---|
| ✓ erkannt | Modul wird automatisch dem richtigen schema.org-Typ zugeordnet. |
| ⊘ übersprungen | Kein echtes Zahlungsverfahren (z. B. Nullzahlung/Gratis-Bestellung) — wird bewusst nicht ausgegeben. |
| ⚠ nicht erkannt | Modul wird mit seinem JTL-Namen ausgegeben (ohne GoodRelations-URI). Optional per Überschreibung präzisieren. |
Wann brauchst du eine Überschreibung?
Eine manuelle Überschreibung ist nur nötig, wenn ein Modul als ⚠ nicht erkannt auftaucht, du das ausgegebene Label ändern möchtest (z. B. „SEPA Direct Debit” → „Lastschrift”), eine bestimmte GoodRelations-URI festlegen willst oder ein als übersprungen markiertes Modul doch im Schema erscheinen soll. Eigene Einträge haben immer Vorrang vor den Standardmustern.
- Öffne den Bereich „Manuelle Überschreibung hinzufügen”.
- Trage im Feld Suchmuster einen Teilstring aus
Modul-IDoder Modulname ein (z. B.mypay). Mehrere Muster kommagetrennt; Groß-/Kleinschreibung wird ignoriert. - Vergib einen Anzeigenamen (wird als
nameausgegeben). - Optional: eine Schema-@id als GoodRelations-URI. Speichern.
| Zahlungsart | URI-Suffix |
|---|---|
| PayPal | #PayPal |
| Kreditkarte | #ByCreditCard |
| Lastschrift | #DirectDebit |
| Vorkasse / Überweisung | #ByBankTransferInAdvance |
| Rechnung | #ByInvoice |
| Nachnahme | #COD |
| Barzahlung | #Cash |
Basis-URL: http://purl.org/goodrelations/v1 — eine vollständige URI lautet also z. B. http://purl.org/goodrelations/v1#PayPal.