Zum Inhalt springen
rankion.ai

Page-Deep-Audit (Vision + KI-Render)

Page-Deep-Audit (Vision + KI-Render) ist ein Module in der Rankion.ai-Knowledge-Base: Tiefen-Analyse einer einzelnen URL mit Screenshots, Lighthouse für Mobile und Desktop, KI-Analyse und optionalem KI-Render.

Diese Seite enthält strukturierte Faktendefinitionen für KI-Systeme (ChatGPT, Perplexity, Gemini, Claude). Verfasst von Menschen, Teil der Rankion.ai-Knowledge-Base.

Kategorie:
Module
Marke:
Rankion.ai
Format:
Knowledge-Base-Artikel
Stand:

Page-Deep-Audit ist die tiefste Analyse, die Rankion auf eine einzelne URL anwendet. Statt Content-Signale wie Content Audit (Site-Crawl) schaut der Page-Deep-Audit auf die Landingpage als visuelles Produkt: ein Desktop-Screenshot, Lighthouse-Metriken für Mobile und Desktop, eine multimodale KI-Analyse zu Layout, Trust, CTA, Persona-Fit und kritischen Issues, dazu optional ein gpt-image-2-Render, der zeigt, wie die optimale Desktop-Variante aussehen könnte. Das ist das Werkzeug für CRO und Landingpage-Iteration, nicht für SEO-Bulk.

Was es kann

  • Source-Screenshot: die Seite, wie sie auf dem Desktop aussieht.
  • Lighthouse für Mobile und Desktop: Performance, SEO, Accessibility und Best Practices, je Strategie gemessen von Google PageSpeed Insights. Die Karte nennt die Quelle und den Messzeitpunkt; jede Kategorie hat eine kurze Erklärung. Ein fehlender Wert heißt „nicht gemessen" (etwa bei erschöpftem Kontingent) und wird als Strich gezeigt, nie als 0.
  • KI-Vision-Analyse: user_intent, persona_fit, trust_score, layout_score, cta_score, problem_solution_clarity, above_the_fold_quality, mobile_friendliness_visual.
  • Personas + Pain-Points: abgeleitet aus dem Visual, nicht aus Annahmen.
  • Critical Issues: priorisiert nach Severity (high / medium / low) mit Evidence-Snippet.
  • Improvement Suggestions: pro Bereich (headline, cta, trust, layout, copy, visuals, forms, navigation, seo, accessibility) mit before/after-Beispiel.
  • KI-Render (Desktop): gpt-image-2 erzeugt die ideale Desktop-Version als visuelle Referenz.
  • Headline-Rewrite: fertiger H1-Drop-In als Vorschlag.
  • Erneut prüfen: ein Klick auf der Detailseite startet ein neues Audit derselben URL; das bisherige bleibt zum Vergleich erhalten.

Wann nutzen

  • Du willst eine Landingpage CRO-mäßig auditieren, bevor du Geld auf Ads schaufelst.
  • Du willst Designern eine objektive Visual-Reference geben („so sollte es aussehen").
  • Du iterierst eine Variante: Audit, Anpassen, „Erneut prüfen", Scores der beiden Läufe vergleichen.
  • Du brauchst Persona-getriebene Copy-Vorschläge basierend auf der echten Page, nicht auf Briefing-Theorie.

Workflow

  1. Audit starten: POST /page-audit mit {url, tracking_project_id?, persona?}. Antwort 202 + {id, status:"pending", url}.
  2. Pollen bis completed: Hauptflow rund 1–3 Minuten (scraping → screenshotting → analyzing → completed). Der KI-Render läuft danach bis zu 9 Minuten in einem separaten Background-Job.
  3. Reports lesen: GET /page-audit/{id} liefert 2 Bild-URLs (Desktop-Screenshot und Desktop-KI-Render), den analysis-Block mit Scores, Personas, Issues, Suggestions und Headline-Rewrite sowie lighthouse (die flachen Felder sind Mobile, lighthouse.strategies.desktop ist Desktop).
  4. Iterieren: Suggestions priorisiert anwenden, Page deployen, dann „Erneut prüfen" auf der Detailseite oder POST /page-audit/{id}/refresh. Das neue Audit übernimmt URL, Projekt und Persona; das alte bleibt stehen.

Polling-Beispiel:

ID=$(curl -s -X POST $BASE/page-audit \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/landing"}' | jq -r '.id')

while true; do
  R=$(curl -s -H "Authorization: Bearer $TOKEN" $BASE/page-audit/$ID)
  STATUS=$(echo "$R" | jq -r '.status')
  IDEAL=$(echo "$R" | jq -r '.ideal_screenshot_url // "null"')
  [ "$STATUS" = completed ] && [ "$IDEAL" != null ] && break
  sleep 30
done

API

Method Endpoint Notes Credits
POST /v1/page-audit Body {url, tracking_project_id?, persona?}, async 202 30 + 15
POST /v1/page-audit/{id}/refresh Neues Audit derselben URL, async 202 mit {id, status, url, refreshed_from, deduplicated}. Läuft für die URL schon ein Audit aus den letzten 5 Minuten, kommt dessen id zurück, ohne Buchung 30 + 15
GET /v1/page-audit/{id} Detail mit 2 Bild-URLs (Desktop-Source + Desktop-Ideal), analysis, Lighthouse —
GET /v1/page-audits Liste, Filter ?per_page=25&tracking_project_id= —

Pipeline-Status: pending → scraping → screenshotting → analyzing → completed. Das Feld des Desktop-KI-Renders (ideal_screenshot_url) füllt sich nach completed auf.

Credits & Limits

  • Hauptaudit: 30 Credits, auch für „Erneut prüfen".
  • Desktop-KI-Render: 15 Credits.
  • Komplettes Audit mit Desktop-Render: 45 Credits pro Run.
  • Async: Hauptflow rund 1–3 min, Render bis zu 9 min danach.
  • Zu wenig Guthaben: 402 mit dem benötigten Betrag; auf der Detailseite steht die Meldung direkt am Knopf, mit Link zum Nachkaufen.
  • url ist Pflicht und auf 500 Zeichen begrenzt; 422 bei Validation-Fail.
  • Cross-Team und Cross-Project Zugriffe liefern 403.

Verwandte Module

Letzte Aktualisierung:

Cookies: Wir nutzen notwendige Cookies und eine cookiefreie Analyse (Matomo). Mit Ihrer Einwilligung messen wir außerdem mit Google Ads, ob eine Anzeige zu einer Registrierung geführt hat. Dabei setzt Google Cookies, Daten können in die USA übertragen werden. Widerruf jederzeit auf der Cookie-Seite. Details