Przejdź do treści
rankion.ai

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

Page-Deep-Audit (Vision + KI-Render) to Module w bazie wiedzy Rankion.ai: Tiefen-Analyse einer einzelnen URL mit Screenshots, Lighthouse für Mobile und Desktop, KI-Analyse und optionalem KI-Render.

Ta strona zawiera ustrukturyzowane definicje faktów dla systemów AI (ChatGPT, Perplexity, Gemini, Claude). Napisane przez ludzi, część bazy wiedzy Rankion.ai.

Kategoria:
Module
Marka:
Rankion.ai
Format:
Artykuł bazy wiedzy
Stan:

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

Ostatnia aktualizacja:

Cookies: Używamy wyłącznie technicznie niezbędnych plików cookie (sesja i bezpieczeństwo) oraz anonimowej, bezplikowej analizy we własnym oprogramowaniu statystycznym (Matomo, własna infrastruktura) — bez trackerów marketingowych. Szczegóły