Page-Deep-Audit (Vision + KI-Render)
Tiefen-Analyse einer einzelnen URL mit Screenshot, KI-Render-Vergleich und 6-9 min Render-Phase.
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: 3 Screenshots (Desktop, Tablet, Mobile mit echter UA-Emulation), Lighthouse-Metriken, eine Opus-4.7-Multimodal-Analyse zu Layout, Trust, CTA, Persona-Fit, kritischen Issues — plus bis zu 3 gpt-image-2 KI-Renders, die zeigen wie die optimale Variante visuell aussehen könnte. Das ist das Werkzeug für CRO und Landingpage-Iteration, nicht für SEO-Bulk.
Was es kann
- 3 Source-Screenshots — Desktop, Tablet, Mobile mit echter User-Agent-Emulation.
- Lighthouse-Metriken — Performance, SEO, Accessibility, Best-Practices als Zahlen.
- Opus-4.7-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. - 3 KI-Renders — gpt-image-2 erzeugt die ideale Version Desktop, Tablet, Mobile als visuelle Referenz.
- Headline-Rewrite — fertiger H1-Drop-In als Vorschlag.
Wann nutzen
- Du willst eine Landingpage CRO-mäßig auditieren bevor du Geld auf Ads schaufelst.
- Du willst Designer eine objektive Visual-Reference geben („so sollte es aussehen").
- Du iterierst eine Variant: Audit → Anpassen → Re-Audit → Score-Diff 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 ~1–2 Minuten (
scraping→screenshotting→analyzing→completed). KI-Renders laufen +6–9 Minuten in einem separaten Background-Job. - Reports lesen —
GET /page-audit/{id}liefert 6 Bild-URLs (3 Source + 3 KI-Render),analysis-Block mit Scores, Personas, Issues, Suggestions, Headline-Rewrite und Lighthouse-Metriken. - Iterieren — Suggestions priorisiert anwenden, Page deployen, Re-Audit fahren, Score-Diff vergleichen.
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_M=$(echo "$R" | jq -r '.ideal_mobile_url // "null"')
[ "$STATUS" = completed ] && [ "$IDEAL_M" != null ] && break
sleep 30
done
API
| Method | Endpoint | Notes | Credits |
|---|---|---|---|
| POST | /v1/page-audit |
Body {url, tracking_project_id?, persona?}, async 202 |
30 + bis zu 3×15 |
| GET | /v1/page-audit/{id} |
Detail mit 6 Bild-URLs, analysis, Lighthouse |
— |
| GET | /v1/page-audits |
Liste, Filter ?per_page=25&tracking_project_id= |
— |
Pipeline-Status: pending → scraping → screenshotting → analyzing → completed. KI-Render-Felder (ideal_screenshot_url, ideal_tablet_url, ideal_mobile_url) füllen sich nach completed einzeln auf — Desktop zuerst, dann Tablet, dann Mobile.
Credits & Limits
- Hauptaudit: 30 Credits.
- KI-Renders: bis zu 3×15 Credits (Desktop, Tablet, Mobile).
- Komplettes Audit mit allen Renders: bis zu 75 Credits pro Run.
- Async — Hauptflow ~1–2 min, Renders +6–9 min danach.
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.