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
- Audit starten:
POST /page-auditmit{url, tracking_project_id?, persona?}. Antwort202+{id, status:"pending", url}. - 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. - Reports lesen:
GET /page-audit/{id}liefert 2 Bild-URLs (Desktop-Screenshot und Desktop-KI-Render), denanalysis-Block mit Scores, Personas, Issues, Suggestions und Headline-Rewrite sowielighthouse(die flachen Felder sind Mobile,lighthouse.strategies.desktopist Desktop). - 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:
402mit dem benötigten Betrag; auf der Detailseite steht die Meldung direkt am Knopf, mit Link zum Nachkaufen. urlist Pflicht und auf 500 Zeichen begrenzt;422bei Validation-Fail.- Cross-Team und Cross-Project Zugriffe liefern
403.
Verwandte Module
- Content Audit: Site-weite Inventur statt einzelner Tiefen-Audit.
- Content Optimizer: Content-Layer optimieren, Page-Deep-Audit zielt auf Visual + UX.
- AI Content Editor: Headline-Rewrite-Vorschlag direkt im Editor übernehmen.