Crawler mit JavaScript-Rendering

SpiderHead kann Seiten über Playwright in einem Headless-Browser rendern und das rohe HTML sowie das gerenderte DOM nebeneinander speichern. So sehen Sie, was erst nach der Ausführung von Skripten existiert. Das Rendering ist optional und standardmäßig deaktiviert.

Was es leistet

Roh gegenüber gerendert

render-check lädt eine URL zweimal: so, wie der Server sie ausliefert, und im Browser nach der Ausführung der Skripte. Dabei vergleicht es Titel, Canonicals, Links und Inhalte, die erst erscheinen oder verschwinden. Bei einem Crawl setzen Sie rendering.mode auf js. SpiderHead rendert dann gezielt: Standardmäßig prüft es einige URLs pro Template-Muster und rendert die Muster, die sich unterscheiden, bis zu 30 Seiten.

  • Gerenderte Routen werden als Nachweis erfasst; ihr Crawling ist eine bewusst aktivierte Option (rendering.rendered_links.crawl)
  • Labordaten aus einem Durchlauf, keine Felddaten zu den Core Web Vitals

Nur bei Bedarf

Der Browser ist eine optionale Erweiterung, der Basis-Crawl kommt ohne ihn aus. Installieren Sie die Gruppe render und einen Browser; für Chromium sollten Sie rund 150 MB einplanen. Prüfen Sie zuerst mit render-check je eine Seite pro Template und rendern Sie die ganze Website nur, wenn sich rohe und gerenderte Seiten unterscheiden.

  • pip install -e ".[render]"
  • python -m playwright install chromium

Drei Schritte, ein gespeicherter Scan

  1. Rohes HTML und gerendertes DOM abrufen

    render-check lädt die URL zweimal: einmal so, wie der Server sie ausliefert, und einmal in Chromium über Playwright nach der Ausführung der Skripte.

  2. Vergleichen, was erst nach Skripten erscheint

    Der Vergleich zählt Wörter und Links, die nur nach dem Rendering existieren, und markiert eine leere App-Shell wie einen nackten Mount-Punkt #root oder #app.

  3. Konsolenfehler und Zeitmessungen lesen

    Wenn Sie rendering.artifacts.console_errors einschalten (standardmäßig aus), werden Skriptfehler, die während des Renderns protokolliert werden, als JS_CONSOLE_ERRORS gemeldet. Die Zeitmessungen stammen aus einem lokalen Durchlauf und sind Labordaten, keine Felddaten der Core Web Vitals.

Prüfungen in dieser Funktion

PrüfungBedeutungSchweregradBeleg
JS_CONSOLE_ERRORSDie Seite hat während des Renderings JavaScript-Fehler in die Browser-Konsole geschriebenImportantText des Konsolenfehlers aus dem Render-Durchlauf
ROBOTS_BLOCKS_RESOURCESDie robots.txt blockiert .js-, .css- oder _next/static-Dateien, die für das Rendering nötig sindTipRegel der robots.txt, die zum Pfad der Ressource passt (aus robots-check)
AJAX_CRAWLING_SCHEME_URLEine Seite oder ein Link auf ihr verwendet das veraltete AJAX-Schema mit #! oder _escaped_fragment_TipDie URL mit dem Schema
Außerdem im Prüfungsregister
RENDER_RESOURCE_BLOCKEDNOINDEX_ONLY_IN_RAW_HTMLCANONICAL_ONLY_IN_RENDERED_HTMLPAGE_TITLE_ONLY_IN_RENDERED_HTML

Ein Befehl

bash
seohead render-check --url https://example.com/

Zuerst installieren: Installationsanleitung. Jeder Befehl läuft auch als MCP-Tool für KI-Agenten.

Was Sie brauchen

  • Eine Seiten-URL für render-check
  • Die Erweiterung render und ein installierter Playwright-Browser
  • Für einen Crawl mit Rendering: eine Crawl-Konfiguration mit rendering.mode auf js

Grenzen

  • Die Zeitmessungen stammen aus einem lokalen Durchlauf und sind keine Felddaten
  • Der Browser startet nicht als root
  • Seitenaktionen sind deklarativ (Klick, Scrollen, Warten, Extraktion); eigenes JavaScript können Sie nicht angeben
  • Auf Websites mit dauerhaft offenen Verbindungen kann networkidle nie eintreten

Fragen

Brauche ich für jeden Crawl einen Browser?
Nein. Der Basis-Crawl funktioniert ohne Browser. Chromium ist eine optionale Erweiterung für render-check und Crawls mit Rendering: pip install -e ".[render]", danach python -m playwright install chromium (rund 150 MB).
Ändert ein Render-Check etwas auf meiner Website?
Nein. Er lädt die URL und ihre Ressourcen so, wie es ein Browser tut, und verändert nichts. Seitenaktionen wie Klicks laufen nur, wenn Sie sie in einem Crawl konfigurieren.
Sind die Geschwindigkeitswerte Core Web Vitals?
Nein. LCP, CLS und Zeitmessungen stammen aus einem Durchlauf auf einer Maschine. Es sind Labormessungen, keine Felddaten aus dem Chrome UX Report.
Kann ich als Smartphone rendern?
Ja. Ergänzen Sie --viewport mobile, um das eingebaute Smartphone-Profil und den Viewport zu verwenden. Für eine eigene Identität nutzen Sie --user-agent.
Was passiert, wenn die Seite nie fertig lädt?
Verwenden Sie --wait domcontentloaded. Standard ist load. networkidle kann auf Websites mit dauerhaften Verbindungen nie eintreten, deshalb vermeiden Sie es dort.

Testen Sie es auf Ihrer eigenen Website