Bevor Sie einen Produktfeed anbinden, holen Sie einen Nachweis ein, der die geplante Erhebung, Transformation, Speicherung und Nutzung präzise erlaubt. Eine öffentliche URL, ein gültiges Konto, ein antwortender Endpoint oder eine großzügige robots.txt reichen nicht aus. Verknüpfen Sie jede Verarbeitung mit einer Lizenzklausel, den AGB, einem Liefervertrag oder einer schriftlichen Erlaubnis, und notieren Sie die Grenzen bezüglich Frequenz, Gebiet, Dauer und Weiterverbreitung. Bleibt ein wesentliches Recht unklar, blockieren Sie die Automatisierung und holen Sie eine Bestätigung beim Lieferanten oder eine passende Rechtsberatung ein. Diese Prüfung schützt sowohl die Quelle als auch die Reversibilität des Projekts.
Fünf oft verwechselte Fragen trennen
Der erste Fehler besteht darin, die Nutzungsrechte auf „Kann man die Datei herunterladen?“ zu reduzieren. Der technische Zugriff ist nur eine Ebene. Eine saubere Anbindung unterscheidet mindestens fünf Fragen:
1. Zugriff: Wurden Konto, Schlüssel, Pfad oder Export für diesen Zweck bereitgestellt? 2. Erhebung: Ist der automatisierte Abruf erlaubt, in welcher Frequenz und innerhalb welcher Grenzen? 3. Transformation: Dürfen Spalten normalisiert, Kennzahlen berechnet oder Produkte abgeglichen werden? 4. Speicherung: Welche Daten dürfen gespeichert werden, wie lange und mit welchen Löschmaßnahmen? 5. Weitergabe: Dürfen Titel, Bilder, Preise oder Bestände Nutzern angezeigt, exportiert oder an Dritte übermittelt werden?
Eine positive Antwort auf eine Frage gilt nicht automatisch für die anderen. Ein Lieferant kann den Import in ein internes Tool erlauben, ohne die öffentliche Weiterveröffentlichung seiner Bilder zu gestatten. Er kann auch einen manuellen Export erlauben, ohne eine automatisierte Abfrage vorzusehen. Nur der geltende Text und, falls nötig, eine ausdrückliche Bestätigung erlauben eine Entscheidung.
Eine Nachweisakte je Quelle anlegen
Die Akte muss einer klar identifizierten Quelle zugeordnet sein. Vermeiden Sie allgemeine Notizen wie „Katalog erlaubt“. Erfassen Sie den Namen des Lieferanten, den betroffenen Dienst, die Kontoart, das Dokument, seine Version oder sein Datum, die offizielle URL und die Person, die die Auslegung validiert hat. Ein einzelner Screenshot ist zerbrechlich, wenn der Text auch heruntergeladen oder im Originalformat archiviert werden kann.
| Frage | Zu suchender Nachweis | Mögliche Entscheidung | Neu zu prüfender Punkt |
|---|---|---|---|
| Wer gewährt den Zugriff? | Vertrag, Einladung, Kontodokumentation | Zugriff anerkannt | Wechsel des Inhabers oder Kontos |
| Welcher Kanal ist erlaubt? | API-, FTP- oder Export-Dokumentation | Kanal festgelegt | Endpoint-Umzug oder Dienstende |
| Welche Frequenz? | Kontingent, Zeitfenster, Fair-Use-Regel | gedeckelte Taktung | wiederholte Fehler oder neues Kontingent |
| Welche Daten? | Katalogumfang und Ausschlüsse | erlaubte Felder | Hinzufügen von Bildern, Texten oder Preisen |
| Welche Verarbeitung? | in der Lizenz beschriebener Zweck | interner Import, Analyse oder anderer benannter Zweck | neue Funktion oder neue Zielgruppe |
| Welche Speicherung? | Dauer, Vertragsende, Löschung | Aufbewahrungsrichtlinie | Kündigung oder Produktrückzug |
| Welche Weiterverbreitung? | Veröffentlichungs- oder Freigabeklausel | Weitergabe erlaubt oder verboten | Hinzufügen eines Drittexports |
Die Form des Feeds ändert diese Pflicht nicht. Die technischen Unterschiede zwischen CSV, XML, API und FTP helfen beim Aufbau der Anbindung, aber keine dieser Technologien gewährt von sich aus ein Wiederverwendungsrecht.
Was die EU-Datenbankrichtlinie ändert
Die Richtlinie 96/9/EG regelt den rechtlichen Schutz von Datenbanken in der Europäischen Union. Sie sieht unter bestimmten Voraussetzungen ein Recht in Bezug auf die Entnahme oder Weiterverwendung des Gesamtinhalts oder eines wesentlichen Teils davon vor, wenn eine wesentliche Investition getätigt wurde. Sie behandelt auch bestimmte wiederholte und systematische Handlungen an nicht wesentlichen Teilen. Die Anwendung auf einen konkreten Katalog hängt jedoch von den Fakten, dem nationalen Recht und dem Vertrag ab.
Diese Richtlinie ist weder eine Zugriffslizenz noch ein automatisches Verbot jeglichen Imports. Sie zeigt, warum „die Seiten sind öffentlich sichtbar“ oder „wir nehmen nur wenige Zeilen auf einmal“ als Analyse nicht ausreichen. Vertragsrechte, ein etwaiges Urheberrecht an Inhalten, der Datenbankschutz und andere geltende Regeln müssen separat geprüft werden. Bei echtem Risiko oder mehrdeutiger Klausel liegt die Validierung bei einer kompetenten Rechtsperson; dieser Artikel liefert eine dokumentarische Methode, keine Rechtsberatung.
Warum robots.txt die Frage nicht klärt
RFC 9309 formalisiert das Robots Exclusion Protocol. Sie besagt, dass die veröffentlichten Regeln an Robots gerichtet sind, die URIs crawlen, und stellt ausdrücklich klar, dass sie keine Form der Zugriffsberechtigung darstellen. Die Datei dient also dazu, die technischen Präferenzen des Dienstes zu respektieren, ersetzt aber weder Authentifizierung noch Lizenz noch AGB.
Die praktische Konsequenz ist zweifach. Ein durch robots.txt erlaubter Pfad gewährt nicht das Recht, dessen Inhalt zu kopieren oder erneut zu veröffentlichen. Ein verbotener Pfad muss vom betroffenen Robot respektiert werden, selbst wenn das Team ein kommerzielles Interesse zu haben glaubt. Scheint ein spezifischer Vertrag einer technischen Einschränkung zu widersprechen, versuchen Sie nicht, diese zu umgehen: Fragen Sie den Lieferanten nach dem offiziellen Kanal, der der Vereinbarung entspricht.
Validierungsverfahren vor der Anbindung
Schritt 1: Die tatsächliche Nutzung beschreiben
Formulieren Sie einen konkreten Satz: „Datei X über Kanal Y in Frequenz Z abrufen, Felder A behalten und für Zweck B verwenden.“ Nennen Sie die Nutzer und etwaige Übermittlungen. Ein vager Zweck verhindert den Abgleich des Projekts mit den Klauseln.
Schritt 2: Die geltenden Texte sammeln
Stellen Sie Vertrag, Konto-AGB, Feed-Lizenz, technische Dokumentation und schriftliche Kommunikation zusammen, die die Erlaubnis präzisieren. Notieren Sie deren Datum und Umfang. Verkaufsseiten können den Dienst erklären, ersetzen aber nicht notwendigerweise die Vertragsbedingungen.
Schritt 3: Die Rechtematrix ausfüllen
Nennen Sie für jede Handlung – erheben, transformieren, speichern, anzeigen, exportieren, löschen – den Nachweis und klassifizieren Sie das Ergebnis: erlaubt, verboten, bedingt oder unbestimmt. Verwenden Sie „erlaubt“ nie ohne Referenz. Ein unbestimmtes Feld wird zu einer Frage an den Lieferanten.
Schritt 4: Grenzen in Schutzmechanismen übersetzen
Wandeln Sie bestätigte Pflichten in Einstellungen um: maximale Frequenz, ausgeschlossene Felder, Aufbewahrungsdauer, Protokollierung, Löschung bei Vertragsende und Begrenzung der Exporte. Dokumentation und Ausführung müssen konsistent bleiben. Läuft die Erlaubnis aus, muss die Erhebung gestoppt werden können, ohne die für ein Audit nötigen Nachweise zu löschen.
Schritt 5: In einem reversiblen Rahmen testen
Sind die Rechte geklärt, nutzen Sie eine Canary-Testcharge, um Kanal und Grenzen in einem kleinen, kontrollierten Rahmen zu prüfen. Dieser Test legalisiert keine unerlaubte Nutzung; er erfolgt nach der dokumentarischen Validierung.
Schritt 6: Die Überprüfung einplanen
Legen Sie fest, welche Ereignisse eine erneute Prüfung erfordern: AGB-Änderung, neue Domain, Kontowechsel, Hinzufügen von Bildern, Weitergabe an Dritte, Frequenzerhöhung, neuer Zweck oder Kündigung. Eine Erlaubnis sollte nicht als ewig gültig betrachtet werden, wenn sich ihr Kontext ändert.
Grauzonen ohne erfundene Erlaubnis handhaben
Fehlt eine Klausel, formulieren Sie eine geschlossene, nachvollziehbare Frage an den Lieferanten. Zum Beispiel: „Erlaubt unser Konto einen täglichen Abruf dieser Datei für eine interne Analyse, mit Speicherung von Kennung, Preis und Bestand?“ Fügen Sie die Frage nach Anzeige und Export hinzu, wenn diese Nutzungen geplant sind. Eine vage kommerzielle Antwort muss vor der Automatisierung geklärt werden.
Kopieren Sie keine zusätzlichen Daten „für alle Fälle“. Datenminimierung reduziert Risiken und vereinfacht die Löschung. Die Kontrolle der Spalten eines Großhandelskatalogs hilft, die tatsächlich benötigten Felder zu identifizieren und jene, deren Zweck nicht belegt ist.
Dokumentieren Sie schließlich auch Ablehnungen. Eine wegen fehlender Erlaubnis blockierte Quelle ist kein technischer Fehlschlag: Es ist eine Compliance-Entscheidung. Der Status muss den Grund, das Datum und die nächstmögliche Aktion angeben, ohne die Erhebung automatisch neu zu starten.
Was ArbitragePro+ automatisieren könnte / was der Verkäufer prüfen muss
Die Funktion registre-droits-source ist eine vorgeschlagene Spezifikation, keine als verfügbar erklärte Funktion. Sie könnte jeder Quelle eine Nutzungsmatrix, die offiziellen Dokumente, deren Daten, die Einschränkungen, einen Überprüfungstermin und einen blockierenden Status zuordnen. Sie könnte auch eine Erhebung verhindern, wenn eine erforderliche Erlaubnis fehlt oder abgelaufen ist, während der Entscheidungsverlauf erhalten bleibt.
Der Verkäufer muss die geltenden Verträge auslegen, Erlaubnisse einholen, Zwecke bestätigen und bei Bedarf Rechtsrat einholen. Er prüft außerdem, ob die technische Konfiguration Frequenz, Felder, Speicherung und Weitergabe tatsächlich gemäß der Erlaubnis einhält. Kein automatisiertes Register verwandelt eine mehrdeutige Klausel in eine Erlaubnis.
Checkliste vor der Aktivierung
- Die tatsächliche Nutzung, der Kanal, die Frequenz und die Empfänger sind beschrieben.
- Der Kontoinhaber und der Erlaubnisgeber sind identifiziert.
- AGB, Lizenzen und technische Dokumente sind datiert und archiviert.
- Erhebung, Transformation, Speicherung und Weitergabe haben jeweils einen Nachweis.
- Die
robots.txt-Regeln werden respektiert, ohne als Lizenz behandelt zu werden. - Die erhobenen Felder haben einen expliziten Zweck.
- Die Grenzen sind in technische Schutzmechanismen übersetzt.
- Ein Abbruch- und Löschverfahren existiert.
- Zweckänderungen lösen eine neue Prüfung aus.
- Jede unbestimmte Zone bleibt bis zur Klärung blockiert.
Eine erlaubte Quelle dokumentieren
Quellenverwaltung in ArbitragePro+ öffnen
Offizielle Quellen
- EUR-Lex, Richtlinie 96/9/EG über den rechtlichen Schutz von Datenbanken: https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A31996L0009 (abgerufen am 17.08.2026).
- IETF, RFC 9309 — Robots Exclusion Protocol: https://www.rfc-editor.org/rfc/rfc9309.html (abgerufen am 17.08.2026).
