So erstellen Sie eine Aggregator-Website: Ein praktischer Leitfaden

Unsere Position: Wir sind Geonode und verkaufen Proxys – eine der Eingangsgrößen für einen Aggregator, die in den meisten Anleitungen überbewertet wird. Daher gleich zu Beginn die ehrliche Feststellung: Proxys sind das Letzte, was Sie kaufen sollten, nicht das Erste. Ein großer Teil der aggregierbaren Daten ist über Feeds, APIs und Sitemaps verfügbar, die kostenlos, strukturiert, stabil und ausdrücklich für diesen Zweck bereitgestellt werden. Einen Crawler für Inhalte zu entwickeln, die jemand als RSS-Feed veröffentlicht, ist vergebliche Mühe, und Bandbreite zu kaufen, bevor man das erkannt hat, ist verschwendetes Geld. Proxys werden erst ab einem bestimmten Punkt relevant – wenn Sie in großem Umfang, aus mehreren Regionen und auf Websites crawlen, die eine Ratenbegrenzung haben – und dieser Punkt kommt später, als die meisten Menschen annehmen. Weiter unten gibt es einen Abschnitt darüber, wo genau diese Grenze liegt.

Welche Art von Aggregator: Vier Modelle

Diese weisen unterschiedliche wirtschaftliche Rahmenbedingungen und unterschiedliche rechtliche Risiken auf, und sie miteinander zu verwechseln, ist der erste Fehler.

Link-Aggregatoren sammeln Schlagzeilen und verweisen auf externe Seiten. Geringer Speicherbedarf, geringes rechtliches Risiko, geringe Wechselkosten für Nutzer. Der Mehrwert liegt ausschließlich in der Kuratierung und der Geschwindigkeit. Nachrichten- und Inhaltsaggregatoren sind meist in diesem Bereich angesiedelt.

Anzeigenaggregatoren sammeln strukturierte Datensätze – Stellenangebote, Immobilien, Autos, Veranstaltungen – und präsentieren sie als durchsuchbare Datenbank. Höherer Mehrwert, höherer Aufwand und das Modell, bei dem die Dublettenbereinigung zum zentralen technischen Problem wird.

Preisaggregatoren verfolgen denselben Artikel bei verschiedenen Anbietern. Der engste und schwierigste Bereich: Das Abgleichen von Produkten bei verschiedenen Händlern, die diese unterschiedlich beschreiben, ist ein wirklich schwieriges Problem, und die Anforderungen an die Aktualität sind extrem hoch, da ein veralteter Preis schlimmer ist als gar kein Preis.

Bewertungs- und Rezensionsaggregatoren bündeln Meinungsdaten. Geringe Abdeckung, hoher Normalisierungsaufwand und die größte Anfälligkeit für Vorwürfe der Falschdarstellung der Quelle.

Wählen Sie bewusst eine Variante aus. Die Architektur unterscheidet sich, die rechtliche Bewertung unterscheidet sich, und „ein Aggregator für alles“ ist der Grund, warum Projekte unvollendbar werden.

Holen Sie sich die Daten zunächst auf dem einfachen Weg

In der Reihenfolge der Präferenz. Arbeiten Sie diese Liste ab und hören Sie auf, sobald etwas funktioniert.

Offizielle APIs. Wenn die Quelle eine veröffentlicht, nutzen Sie diese. Sie ist stabil, strukturiert, autorisiert, und jemand wird sie reparieren, wenn sie ausfällt. Lies dir die Nutzungsbedingungen durch – die meisten schränken die Weiterverbreitung, die Caching-Dauer und die kommerzielle Nutzung ein, und diese Einschränkungen prägen dein Produkt.

Feeds von Partnern oder Affiliates. Viele Branchen veröffentlichen umfangreiche Feeds speziell für Aggregatoren, da diese ihnen Traffic zuführen. Jobbörsen, Immobilienportale, Einzelhändler und Reiseveranstalter verfügen häufig über ein Partnerprogramm, über das du den gesamten Datensatz erhältst. Dies ist die am wenigsten genutzte Quelle in diesem Bereich, und der Grund dafür ist, dass die Leute nach „Wie kann man X scrapen?“ suchen, anstatt X per E-Mail zu fragen, ob es einen Feed gibt. Fragen Sie einfach. Eine überraschend große Anzahl sagt „Ja“.

RSS- und Atom-Feeds. Nach wie vor weit verbreitet und nach wie vor ideal für die Link-Aggregation. Strukturiert, kostengünstig, genau für diesen Zweck konzipiert und eindeutig zur Nutzung bereitgestellt.

Sitemaps. sitemap.xml liefert dir eine vollständige URL-Liste sowie Zeitstempel im Format „lastmod“, wodurch du effizient crawlen kannst, anstatt auf Brachialkraft zu setzen. Selbst wenn du crawlen musst, zeigt dir die Sitemap an, was sich geändert hat, sodass du nur diese Änderungen abrufst.

Strukturierte Daten auf der Seite. Bevor Sie HTML-Parser schreiben, prüfen Sie, ob in einem <script type="application/ld+json">-Block JSON-LD vorhanden ist. Schema.org-Markup für JobPosting, Product, Event und Recipe ist weit verbreitet, da es Suchfunktionen antreibt und Ihnen saubere, strukturierte Daten von einer Seite liefert, die Sie ohnehin abrufen wollten. Es übersteht Redesigns zudem weitaus besser als CSS-Selektoren.

HTML-Parsing. Der letzte Ausweg. Anfällig, wartungsintensiv und der Grund, warum die Arbeit mit einem Aggregator zu einem Vollzeitjob wird.

Die Reihenfolge ist wichtiger als jeder einzelne Punkt. Teams, die am Ende dieser Liste ansetzen, entwickeln erst einen Crawler und entdecken den Feed erst sechs Monate später.

Wenn Sie crawlen müssen: robots.txt ist jetzt ein Standard

robots.txt ist seit 2022 keine Konvention mehr. RFC 9309 standardisiert das Robots Exclusion Protocol und legt fest, welches Verhalten Sie implementieren sollten, wenn Sie einen Crawler schreiben.

Vier Anforderungen, die Sie genau kennen sollten:

Die Übereinstimmung erfolgt nach Spezifität, nicht nach Reihenfolge. „Die spezifischste gefundene Übereinstimmung MUSS verwendet werden. Die spezifischste Übereinstimmung ist diejenige mit den meisten Oktetten.“ Es gilt nicht das Prinzip „First-Match-Wins“, wie es viele selbst entwickelte Parser annehmen.

Cache-Speicherung für höchstens 24 Stunden. „Crawler SOLLTEN die zwischengespeicherte Version nicht länger als 24 Stunden verwenden, es sei denn, die robots.txt-Datei ist nicht erreichbar.“ Ein einmaliges Abrufen zum Zeitpunkt der Bereitstellung entspricht nicht den Vorgaben.

Serverfehler bedeuten Stopp. „Wenn die robots.txt-Datei aufgrund von Server- oder Netzwerkfehlern nicht erreichbar ist …… MUSS der Crawler von einer vollständigen Sperrung ausgehen.“ Ein 5xx-Fehler bedeutet, sich vollständig zurückzuziehen. Ein 404-Fehler bedeutet dagegen keine Einschränkungen – es gibt keine Datei, also ist nichts gesperrt.

Mindestens 500 KiB parsen. „Das Parsing-Limit MUSS mindestens 500 Kibibyte betragen.“ Große Websites haben große Dateien.

Verwende eine gepflegte Bibliothek, anstatt dies selbst zu programmieren. Allein die Regel zum Abgleich der Spezifität ist eine häufige Fehlerquelle, und ein Crawler, der ein „robots.txt“ falsch interpretiert, ist ein Crawler, der Beschwerden hervorruft.

Abgesehen von der Datei selbst gelten die üblichen Höflichkeitsregeln: Identifiziere dich mit einem echten User-Agent, der eine Kontakt-URL enthält, respektiere „Crawl-delay“, sofern vorhanden, zieh dich bei 429 und 503 sofort zurück und speichere Inhalte im Cache, damit du unveränderte Inhalte niemals zweimal abrufst. Bedingte Anfragen mit If-Modified-Since oder If-None-Match kosten die Quelle nichts und kosten auch Sie nichts. Die meisten Websites, die Aggregatoren blockieren, tun dies aufgrund ihres Verhaltens, nicht wegen ihrer bloßen Existenz.

Die rechtliche Ebene: Urheberrecht, TDM-Opt-outs und Datenbankrechte

Dies ist keine Rechtsberatung, und die Rechtslage hängt stark vom jeweiligen Rechtsraum ab. Es gibt jedoch vier Dinge, die Sie verstehen sollten, bevor Sie mit der Entwicklung beginnen.

Fakten unterliegen im Allgemeinen keinem Urheberrecht; die Darstellung hingegen schon. Eine Berufsbezeichnung, ein Gehalt, ein Preis und ein Datum sind Fakten. Die Beschreibung, die verfasst wurde, um die Stelle zu bewerben, ist eine Ausdrucksform. Das Aggregieren der erstgenannten Elemente steht auf weitaus sichererem Boden als die Wiedergabe der letztgenannten. Diese eine Unterscheidung prägt das Design der meisten sinnvollen Aggregatoren: Speichere die strukturierten Fakten, verlinke auf die Quelle für den Text.

Die Länge des Auszugs spielt eine Rolle. Die Wiedergabe einer Überschrift und eines Satzes mit einem Link ist etwas anderes als die Wiedergabe eines Artikels. In mehreren Rechtsordnungen wurde gerichtlich geklärt, wo die Grenze verläuft, und die Antworten fallen unterschiedlich aus. Kürzer ist sicherer, und das Verlinken statt der Wiedergabe ist am sichersten.

Die EU verfügt über eine Opt-out-Regelung für Text- und Daten-Mining, die von Grund auf maschinenlesbar ist. Artikel 4 der Richtlinie (EU) 2019/790 erlaubt Text- und Daten-Mining durch jedermann, sofern die Rechteinhaber ihre Rechte nicht ausdrücklich „in geeigneter Weise, beispielsweise durch maschinenlesbare Mittel“ vorbehalten haben. Bei Inhalten, die online öffentlich zugänglich gemacht wurden, betrachtet die Richtlinie maschinenlesbare Vorbehalte – „einschließlich Metadaten und Nutzungsbedingungen einer Website oder eines Dienstes“ – als den geeigneten Weg. Die Ausnahme setzt zudem voraus, dass der Zugriff auf das Material rechtmäßig erfolgte.

Die praktische Auswirkung für einen Crawler: Vorbehalte, die in maschinenlesbarer Form zum Ausdruck gebracht werden, sollen beachtet werden, und die EU arbeitet daran, die Protokolle für deren Darstellung zu standardisieren. Einen Crawler zu entwickeln, der maschinenlesbare Vorbehalte ignoriert, bedeutet, ein Compliance-Problem von Grund auf einzubauen.

Die EU kennt zudem ein eigenständiges Datenbankrecht. Über das Urheberrecht hinaus schuf die Datenbankrichtlinie ein sui generis-Recht, das erhebliche Investitionen in die Beschaffung, Überprüfung oder Darstellung der Inhalte einer Datenbank schützt – unabhängig davon, ob die Inhalte selbst urheberrechtlich geschützt sind. Dies ist für Aggregatoren von unmittelbarer Relevanz, da das Extrahieren eines wesentlichen Teils der Eintragsdatenbank eines anderen dieses Recht bereits auslösen kann, selbst wenn jeder einzelne Eintrag eine reine Tatsache darstellt.

Hinzu kommen Nutzungsbedingungen, die eher vertraglicher als gesetzlicher Natur sind und von vielen Websites genutzt werden, um den automatisierten Zugriff gänzlich zu untersagen. Ob eine Klausel für Sie bindend ist, wenn Sie nie auf etwas geklickt haben, ist eine wirklich umstrittene Frage, die je nach Rechtsordnung unterschiedlich beantwortet wird. Lesen Sie sie trotzdem: Sie geben Aufschluss darüber, wie die Website damit umgeht, was oft unmittelbar relevanter ist als die Entscheidung eines Gerichts.

Die pragmatische Zusammenfassung: Bevorzugen Sie autorisierte Quellen, speichern Sie Fakten statt Text, verlinken Sie statt zu reproduzieren, beachten Sie maschinenlesbare Einschränkungen und holen Sie sich bei allem, was wirtschaftlich von Bedeutung ist, Rat ein.

Architektur: Vier Phasen und die schwierige

Jeder Aggregator durchläuft dieselben vier Phasen, von denen nur eine schwierig ist.

Abrufen. Rohdaten abrufen. Zu beachtende Aspekte: Zeitplanung, Ratenbegrenzung, Wiederholungsversuche, Zwischenspeicherung, bedingte Anfragen. Speichern Sie die Rohantwort immer – wenn ein Parser ausfällt, möchten Sie historische Daten erneut parsen, anstatt sie erneut abzurufen.

Parsen. Rohdaten in strukturierte Datensätze umwandeln. Zu beachtende Aspekte: Anfälligkeit und Änderungserkennung. Es sollte eine Warnung ausgelöst werden, wenn sich die Form der Parser-Ausgabe ändert, und nicht erst, wenn ein Fehler auftritt – denn der kostspielige Fehler ist ein Parser, der stillschweigend weniger Felder zurückgibt.

Normalisierung und Deduplizierung. Die schwierige Phase. Im Folgenden näher erläutert.

Bereitstellen. Suchen, filtern, anzeigen. Standardmäßige Webentwicklung und der Teil, in den die meisten Teams zu Beginn zu viel investieren, weil er im Blickfeld steht.

Die Dublettenbereinigung entscheidet über Erfolg oder Misserfolg von Aggregatoren. Dieselbe Stellenanzeige wird auf vier Jobbörsen mit unterschiedlichen Titeln geschaltet. Dieselbe Immobilie wird von drei Maklern zu unterschiedlichen Preisen angeboten. Dasselbe Produkt hat bei jedem Händler einen anderen Namen. Die Nutzer beurteilen euch fast ausschließlich danach: Eine Anzeigenplattform, die dasselbe sechsmal anzeigt, wirkt fehlerhaft, egal wie vollständig sie ist.

Der Ansatz, der funktioniert, ist mehrschichtig – am günstigsten zuerst:

Exakte Identifikatoren. ISBNs, Artikelnummern, Registrierungsnummern, Quell-IDs. Wo sie vorhanden sind, nutzen Sie sie und belassen Sie es dabei – sie lösen das Problem vollständig.

Normalisierte Schlüssel. Erstellen Sie einen kanonischen Schlüssel aus Feldern, die in Kleinbuchstaben geschrieben, von Leerzeichen bereinigt und von Satzzeichen befreit sind: Arbeitgeber plus Berufsbezeichnung plus Standort; Postleitzahl plus Anzahl der Schlafzimmer plus Wohnfläche. Erfasst einen großen Teil kostengünstig.

Fuzzy-Matching. Tokenbasierte Ähnlichkeitsanalyse bei Titeln und Beschreibungen, mit einem Schwellenwert, den Sie anhand einer manuell gekennzeichneten Stichprobe anpassen. Notwendig und kostspielig; beschränken Sie dies auf Kandidaten, die bereits einen groben Schlüssel gemeinsam haben, sonst wird es zu einem Vergleich aller Paare, den Sie sich nicht leisten können.

Manuelle Überprüfung für die mehrdeutigen Fälle. Akzeptieren Sie, dass ein gewisser Anteil menschlicher Überprüfung bedarf. Bauen Sie die Warteschlange frühzeitig auf, anstatt erst, wenn sich Nutzer beschweren.

Zwei Entwurfsentscheidungen, die später Ärger ersparen: Bewahren Sie jeden Quelldatensatz separat auf und verknüpfen Sie ihn mit einer kanonischen Entität, anstatt ihn destruktiv zusammenzuführen – Sie werden bei der Zusammenführung Fehler machen und diese rückgängig machen müssen. Und protokollieren Sie, warum zwei Datensätze zusammengeführt wurden, denn „Warum wird in diesem Eintrag der falsche Preis angezeigt?“ ist eine Frage, die Ihnen gestellt wird und die Sie anhand der zusammengeführten Daten allein nicht beantworten können.

Aktualität, Zeitplanung und Kosten

Die Anforderungen an die Aktualität variieren enorm und bestimmen Ihre gesamte Kostenstruktur.

Der Fehler, der Budgets sprengt, besteht darin, alles mit der Häufigkeit zu crawlen, die der am stärksten schwankende Eintrag erfordert. Die Lösung ist eine Abstufung: Crawlen Sie, was sich oft ändert, häufig; crawlen Sie, was sich selten ändert, selten; und nutzen Sie „lastmod“ aus Sitemaps und bedingten Anfragen, um unveränderte Inhalte komplett zu überspringen.

Die Erkennung von Löschungen ist das Aktualitätsproblem, mit dem niemand rechnet. Ein besetzter Stellenplatz oder ein verkauftes Haus muss verschwinden, und Quellen geben dies selten bekannt. Man benötigt entweder ein Signal (die Seite gibt einen 404-Fehler aus, ein Statusfeld ändert sich) oder eine Richtlinie (Datensätze, die in drei Crawls nicht gefunden wurden, werden als inaktiv markiert). Wenn man hier einen Fehler macht, füllt sich der Aggregator mit veralteten Einträgen – was nach Duplikaten der zweithäufigste Grund ist, warum Nutzer das Vertrauen in einen Aggregator verlieren.

Die Kosten skalieren mit den Abrufen, nicht mit den Datensätzen. Zehntausend stündlich überprüfte Angebote entsprechen 240.000 Abrufen pro Tag; dieselben Angebote, die täglich überprüft werden, entsprechen 10.000 Abrufen. Gleiche Daten, ein vierundzwanzigfacher Unterschied bei der Bandbreite und bei der Belastung, die Sie den Quellen auferlegen. Jede Stunde akzeptabler Veralterung kostet Geld.

Wo Proxys sinnvoll sind und wo nicht

Unser Ende der Pipeline, so genau wie möglich beschrieben.

Sie benötigen keine Proxys, wenn: Sie Feeds oder APIs nutzen, Ihr Datenvolumen gering ist, Sie von einem Standort aus Quellen crawlen, die keine Ratenbegrenzung haben, oder Sie sich noch in der Entwicklungs- und Testphase befinden. Dies trifft auf viele Aggregatoren in der Anfangsphase vollständig zu.

Sie benötigen sie, wenn: Sie so intensiv crawlen, dass eine einzelne Adresse einer Ratenbegrenzung unterliegt; die Inhalte je nach Region variieren und Sie mehrere Regionen abdecken müssen; Sie verteilte Crawler betreiben und möchten, dass diese wie separate Clients erscheinen und nicht wie ein einziger Rechner mit mehreren Threads; oder Sie geografische Genauigkeit für regionsspezifische Preise und Verfügbarkeit benötigen.

Welcher Typ: Rechenzentrum für die meisten Crawling-Aufgaben, da dies um ein Vielfaches günstiger ist und öffentliche Listing-Seiten in der Regel nichts Weiteres erfordern. Unser Angebot beginnt bei 0,14 $/GB und wird nach Datenverkehr statt pro IP abgerechnet. Wechseln Sie erst dann auf „Residential“ – ab 0,79 $/GB –, wenn das Rechenzentrum nachweislich versagt oder wenn Sie eine Geolokalisierung im Verbrauchernetzwerk benötigen. Neue Konten erhalten 1 TB kostenlosen „Residential“-Traffic, was ausreicht, um festzustellen, ob Sie diesen überhaupt benötigen. Zahlen stammen von unserer Preisseite, Stand: September 2026.

Der Kostenfaktor, den niemand einplant: Headless-Browser. Wenn Ihre Quellen JavaScript-Rendering erfordern, lädt ein Browser jedes Bild, jede Schriftart und jedes Skript herunter, wodurch die Bandbreite im Vergleich zu reinem HTTP um eine Größenordnung ansteigt. Blockieren Sie Ressourcentypen, die Sie nicht benötigen. Bei kontingentierter Bandbreite ist dies der größte verfügbare Hebel, und wir haben die wirtschaftlichen Zusammenhänge in unserem Proxy-Preisleitfaden ausführlich behandelt.

Und die ehrliche Grenze: Proxys lösen das Problem der Verteilung. Sie lösen weder Probleme mit den Nutzungsbedingungen noch mit Datenbankrechten, und sie sorgen nicht dafür, dass eine Quelle Sie dort haben will. Wenn eine Website Ihnen mitgeteilt hat, dass Sie sie nicht crawlen sollen, sind mehr Adressen keine Lösung dafür; es ist lediglich eine Möglichkeit, diese Anweisung effizienter zu ignorieren.

Warum die meisten Aggregatoren scheitern

Nicht aus technischen Gründen.

Kein einzigartiger Mehrwert. Das Aggregieren dessen, was alle anderen auch aggregieren, führt zu einer schlechteren Version einer bereits bestehenden Website. Der Mehrwert muss in einer Berichterstattung liegen, die sonst niemand bietet, in einer Organisation, die sonst niemand bietet, oder in einer Nische, die für die etablierten Akteure zu klein ist.

Duplikate. Wurde oben bereits angesprochen und ist es wert, wiederholt zu werden. Dies ist der Hauptgrund, warum Nutzer abwandern.

Veraltete Daten. Ungültige Einträge zerstören das Vertrauen schneller als fehlende Einträge, denn ein fehlender Eintrag ist unsichtbar, während ein ungültiger Eintrag die Zeit des Nutzers verschwendet.

Wartungsaufwand übersteigt den Nutzen. Zwanzig handgeschriebene HTML-Parser sind ein Dauer-Teilzeitjob. Jede Quelle, die man hinzufügt, erhöht die festen laufenden Kosten. Bevorzugen Sie Quellen mit Feeds; seien Sie bereit, Quellen zu streichen, deren Wartungsaufwand ihren Beitrag übersteigt.

Henne und Ei. Aggregatoren brauchen eine umfassende Abdeckung, um Nutzer anzuziehen, und Nutzer, um die Abdeckung zu rechtfertigen. Der Weg dorthin führt über Vollständigkeit in einem engen Bereich statt Unvollständigkeit in einem breiten.

Spät auftretende rechtliche Probleme. Eine Unterlassungsaufforderung, nachdem Sie Ihr Geschäft auf einer Quelle aufgebaut haben, ist erheblich teurer als ein Gespräch mit dem Partner, bevor Sie angefangen haben. Sprechen Sie frühzeitig mit Ihren größten Quellen; einige werden sich über den Traffic freuen, und diejenigen, die das nicht tun, sollten Sie besser gleich am ersten Tag ausfindig machen.

Häufig gestellte Fragen

Ist es legal, eine Aggregator-Website zu erstellen?

Das hängt davon ab, was Sie aggregieren, woher Sie die Inhalte beziehen und wie Sie dabei vorgehen. Fakten unterliegen in der Regel keinem Urheberrecht, die Darstellung hingegen schon. Deshalb ist es sicherer, strukturierte Daten zu speichern und auf die Quelle zu verlinken. In der EU gelten die Ausnahme für Text- und Data-Mining, maschinenlesbare Rechtevorbehalte und das gesonderte Datenbankrecht. Lassen Sie sich bei allen kommerziell relevanten Fragen beraten.

Woher beziehen Aggregatoren ihre Daten?

In der Reihenfolge ihrer Bevorzugung: offizielle APIs, Feeds von Partnern und Affiliates, RSS und Atom, Sitemaps, in Seiten eingebettete strukturierte Daten und erst dann HTML-Parsing. Die am häufigsten übersehene Quelle ist der Partner-Feed – viele Branchen veröffentlichen vollständige Datensätze für Aggregatoren, da diese ihnen Traffic zuführen. Fragen Sie nach, bevor Sie einen Crawler erstellen.

Benötige ich Proxys, um einen Aggregator zu entwickeln?

Anfangs nicht. Feeds und APIs benötigen keine, und auch für ein moderates Crawling von einem Standort aus sind sie in der Regel nicht erforderlich. Sie werden notwendig, wenn das Volumen Ratenbegrenzungen auslöst, wenn Sie regionsspezifische Inhalte abrufen müssen oder wenn Sie verteilte Crawler betreiben. Die Bandbreite eines Rechenzentrums ist die sinnvolle Standardwahl; private Internetverbindungen sollten nur dort genutzt werden, wo dies nachweislich erforderlich ist.

Wie gehen Aggregatoren mit doppelten Einträgen um?

Mehrstufiger Abgleich, nach dem Prinzip „günstigster zuerst“: exakte Identifikatoren, sofern vorhanden, dann normalisierte Schlüssel, die aus bereinigten Feldern gebildet werden, dann unscharfe Ähnlichkeit innerhalb grober Kandidatengruppen und schließlich manuelle Überprüfung der verbleibenden mehrdeutigen Einträge. Halten Sie Quelldatensätze getrennt und verknüpfen Sie sie mit einer kanonischen Entität, anstatt sie destruktiv zusammenzuführen.

Was verlangt „robots.txt“ von mir?

Seit RFC 9309 ist es ein Standard und keine Konvention mehr. Abgleich nach Spezifität statt nach Reihenfolge, Aktualisierung der Datei mindestens einmal täglich, Behandlung von Serverfehlern als vollständiges Verbot, Behandlung eines 404-Fehlers als keine Einschränkungen und Analyse von mindestens 500 KiB. Verwenden Sie eine gepflegte Bibliothek, anstatt einen eigenen Parser zu schreiben.

Wie oft sollte ein Aggregator seine Daten aktualisieren?

So selten, wie es Ihr Anwendungsfall zulässt, da die Kosten mit der Anzahl der Abrufe skalieren. Nachrichten benötigen Minuten, Stellenanzeigen Stunden, Veranstaltungen Tage. Stufen Sie Ihre Quellen nach Volatilität ein, nutzen Sie Sitemap-lastmoden und bedingte Anfragen, um unveränderte Inhalte zu überspringen, und legen Sie eine explizite Richtlinie zur Erkennung gelöschter Einträge fest.

Kann ich Inhalte von Websites aggregieren, die Scraper blockieren?

Technisch gesehen ist das vielleicht möglich; ob Sie es tun sollten, ist eine andere Frage. Eine Sperre ist eine Absichtserklärung, und eine Umgehung ändert nichts an den Bedingungen, dem Datenbankrecht oder der Beziehung. Besser ist es, nach einem Feed zu fragen – viele Websites, die Crawler blockieren, stellen gerne Partnerdaten zur Verfügung.

Was ist der schwierigste Teil beim Aufbau eines Aggregators?

Mit großem Abstand die Deduplizierung und die Aktualität. Das Abrufen und Parsen sind Probleme, die mit Bibliotheken gelöst sind. Die Entscheidung, dass zwei unterschiedlich formulierte Einträge dasselbe sind, und das Erkennen, wenn einer davon stillschweigend nicht mehr existiert, ist der Punkt, an dem sowohl der technische Aufwand als auch das Vertrauen der Nutzer hängen.

Fazit

Die Kunst beim Aufbau eines Aggregators besteht darin, zu erkennen, welche Probleme tatsächlich bestehen. Das Abrufen von Inhalten gehört nicht dazu – Feeds, APIs, Sitemaps und eingebettete strukturierte Daten decken weitaus mehr ab, als man erwartet, und Teams, die sich direkt an die Entwicklung von HTML-Parsern machen, lösen in der Regel ein Problem, das bereits für sie gelöst wurde.

Die wirklichen Probleme liegen weiter unten in der Kette. Die Dublettenbereinigung entscheidet darüber, ob Nutzer Ihren Daten vertrauen. Die Erkennung von Löschungen entscheidet darüber, ob sie ihnen ein zweites Mal vertrauen. Der Wartungsaufwand entscheidet darüber, ob das Projekt den Kontakt mit zwanzig Quellen übersteht, die ihr Markup unabhängig voneinander ändern. Und die rechtliche Ebene – Urheberrecht an der Ausdrucksform, maschinenlesbare TDM-Vorbehalte, das EU-Datenbankrecht, Nutzungsbedingungen – entscheidet darüber, ob das Ganze ein Geschäft oder eine Belastung ist.

Fangen Sie lieber klein und vollständig an als breit und unvollständig. Bevorzugen Sie bei jeder Gelegenheit autorisierte Quellen, einschließlich der direkten Anfrage bei den Quellen, da ein Partner-Feed eine ganze Kategorie von Problemen auf einen Schlag beseitigt. Fügen Sie Infrastruktur – einschließlich Proxys – erst dann hinzu, wenn Sie an die Grenzen stoßen, nicht vorher.