> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Anatomie eines Web-Scrapers

> Jeder Web-Scraper durchläuft dieselbe Pipeline: abrufen, rendern, finden, extrahieren, navigieren und speichern. So greifen die Phasen ineinander.

Ein Web-Scraper ist kein einzelnes Element, sondern eine Pipeline. Ob Sie ihn in Python schreiben, selbst einen Headless-Browser steuern oder visuell in einem No-Code-Tool erstellen: Dieselben Phasen laufen in derselben Reihenfolge ab. Wer sie kennt, erkennt leichter, wo ein Scraper ausfällt, wo er langsamer wird und welche Technik welches Problem behebt.

<Steps>
  <Step title="Seite abrufen">
    Eine HTTP-Anfrage senden und HTML empfangen.
  </Step>

  <Step title="Seite rendern">
    Das JavaScript der Seite in einem echten Browser ausführen.
  </Step>

  <Step title="Daten finden">
    Elemente mit XPath oder CSS-Selektoren bestimmen.
  </Step>

  <Step title="Extrahieren und verfeinern">
    Werte auslesen und mit regulären Ausdrücken bereinigen.
  </Step>

  <Step title="Durch die Website navigieren">
    Paginierung und Anmeldesperren bewältigen.
  </Step>

  <Step title="Ausgabe speichern">
    Als CSV, JSON, in einer Datenbank oder über eine nachgelagerte API.
  </Step>
</Steps>

Die ersten fünf Phasen laufen auf jeder Seite der Reihe nach ab. **Navigieren** führt für die nächste Seite zurück zu **Abrufen**, und die gesamte Schleife läuft in großem Maßstab – in der Cloud, hinter rotierenden Proxies und trotz CAPTCHAs.

## Seite abrufen

Alles beginnt mit einer Anfrage. Der Scraper sendet eine HTTP-Anfrage an eine URL und erhält eine Antwort – meist HTML, manchmal JSON. Bei einfachen serverseitig gerenderten Seiten liefert dieser Schritt alles Nötige. Allerdings ist die Antwort nur die *anfängliche* Nutzlast des Servers; bei vielen modernen Websites ist das kaum mehr als eine leere Hülle.

## Seite rendern

Erstellt eine Website ihre Inhalte mit JavaScript, stehen die gewünschten Daten nicht im ursprünglichen HTML, sondern erscheinen erst nach Ausführung der Skripte. Beim Rendern werden diese Skripte in einem echten Browser ausgeführt, damit der vollständige Inhalt sichtbar wird. Die hier verwendete [Browser-Laufzeit](/docs/de/academy/browser-runtime-landscape) bestimmt, wie originalgetreu die Seite geladen wird und wie viel Arbeitsspeicher und Zeit dies kostet. Sie bildet den Kern beim [Scraping JavaScript-gerenderter Seiten](/docs/de/academy/scrape-javascript-pages).

## Daten finden

Nach dem vollständigen Laden muss der Scraper die gewünschten Bestandteile bestimmen – etwa einen Preis, einen Titel oder eine Tabellenzeile. Dazu dienen [XPath oder CSS-Selektoren](/docs/de/academy/xpath-css-selectors), die beschreiben, *wo* ein Element in der Seitenstruktur liegt. Gute Selektoren entscheiden darüber, ob ein Scraper kleinere Layoutänderungen übersteht oder bei jeder Aktualisierung der Website ausfällt.

## Extrahieren und verfeinern

Das Auffinden eines Elements liefert seinen Rohinhalt. Die Extraktion liest den Wert aus, die Verfeinerung bereinigt ihn. Ein ausgelesener Preis könnte beispielsweise als `"$1,299.00 USD"` vorliegen, obwohl Sie nur die Zahl benötigen. [Reguläre Ausdrücke und Nachbearbeitungsregeln](/docs/de/academy/refining-data-with-regex) entfernen, teilen und formatieren Rohtext in die strukturierten Felder um, die tatsächlich gespeichert werden sollen.

## Durch die Website navigieren

Die meisten Datensätze umfassen mehrere Seiten. Der Scraper muss die [Paginierung](/docs/de/academy/handle-pagination) durchlaufen – Links zur nächsten Seite, „Mehr laden“-Schaltflächen oder unendliches Scrollen –, um jeden Datensatz zu erreichen. Manche Inhalte liegen außerdem hinter [Anmeldesperren](/docs/de/academy/scraping-login-walls), die der Scraper zunächst authentifiziert überwinden muss.

## Im großen Maßstab ausführen

Ein Scraper, der einmal auf Ihrem Laptop funktioniert, muss auch Tausende Läufe bewältigen. Die Ausführung [in der Cloud](/docs/de/academy/cloud-web-scraping) hält Aufgaben am Laufen, ohne Ihren Rechner zu belegen. Rotierende Proxies verteilen Anfragen auf viele IP-Adressen, damit eine Website sie nicht begrenzt oder blockiert. CAPTCHAs und Anti-Bot-Dienste sind die Hindernisse, die in dieser Phase bewältigt werden.

## Ausgabe speichern

Schließlich landen die extrahierten Daten an einem nutzbaren Ort – in einer CSV- oder Excel-Datei, einem JSON-Export, einer Datenbank oder einer nachgelagerten API. Erst diese Phase macht aus einem Scraping-Lauf einen Datensatz.

## Die Rolle von Octoparse

Bei einem selbst programmierten Scraper verbinden Sie alle Phasen selbst: Anfragebibliothek, Browser-Treiber, Selektor-Engine, Bereinigungscode, Paginierungslogik, Proxy-Verwaltung und Export. Octoparse bündelt die gesamte Pipeline in einem visuellen Workflow. Sie legen Selektoren per Point-and-Click fest; Rendering, Paginierung, Proxy-Rotation, Cloud-Extraktion und Export sind integriert und werden konfiguriert statt programmiert. Die Phasen bleiben gleich. Sie beschreiben jedoch, *was* erfasst werden soll, statt technisch umzusetzen, *wie* jede Phase abläuft.