Page Deep Audit (Vision + Render IA)

Page Deep Audit est l'analyse la plus profonde que Rankion applique à une URL unique. Au lieu de signaux de contenu comme Content Audit (Site Crawl), le Page Deep Audit regarde la landing page comme un produit visuel : 3 captures (Desktop, Tablet, Mobile avec émulation UA réelle), métriques Lighthouse, une analyse multimodale Opus-4.7 sur layout, trust, CTA, persona-fit, issues critiques — plus jusqu'à 3 renders IA gpt-image-2 qui montrent à quoi pourrait visuellement ressembler la variante optimale. C'est l'outil pour le CRO et l'itération de landing page, pas pour le SEO en bulk.

Ce qu'il peut faire

• 3 captures source — Desktop, Tablet, Mobile avec émulation user-agent réelle.
• Métriques Lighthouse — Performance, SEO, Accessibility, Best-Practices en chiffres.
• Analyse Vision Opus-4.7 — user_intent, persona_fit, trust_score, layout_score, cta_score, problem_solution_clarity, above_the_fold_quality, mobile_friendliness_visual.
• Personas + pain points — déduits du visuel, pas d'hypothèses.
• Critical Issues — priorisés par sévérité (high / medium / low) avec extrait de preuve.
• Improvement Suggestions — par zone (headline, cta, trust, layout, copy, visuals, forms, navigation, seo, accessibility) avec exemple before/after.
• 3 renders IA — gpt-image-2 produit la version idéale Desktop, Tablet, Mobile en référence visuelle.
• Réécriture de headline — drop-in H1 prêt en suggestion.

Quand l'utiliser

• Tu veux auditer une landing page côté CRO avant d'y mettre du budget Ads.
• Tu veux donner aux designers une référence visuelle objective (« voilà comment ça devrait ressembler »).
• Tu itères une variante : Audit → Ajuster → Re-Audit → comparer le diff de score.
• Tu as besoin de suggestions de copy pilotées par persona basées sur la vraie page, pas sur la théorie de briefing.

Workflow

1. Lancer l'audit — POST /page-audit avec {url, tracking_project_id?, persona?}. Réponse 202 + {id, status:"pending", url}.
2. Poller jusqu'à completed — flow principal ~1–2 minutes (scraping → screenshotting → analyzing → completed). Les renders IA tournent +6–9 minutes dans un background job séparé.
3. Lire le rapport — GET /page-audit/{id} livre 6 URLs d'images (3 source + 3 render IA), bloc analysis avec scores, personas, issues, suggestions, headline rewrite et métriques Lighthouse.
4. Itérer — appliquer les suggestions par priorité, déployer la page, refaire un audit, comparer le diff de score.

Exemple de polling :

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

Statut pipeline : pending → scraping → screenshotting → analyzing → completed. Le champ render IA Desktop (ideal_screenshot_url) se remplit après completed.

Crédits et limites

• Audit principal : 30 crédits.
• Render IA Desktop : 15 crédits.
• Audit complet avec render desktop : 45 crédits par run.
• Async — flow principal ~1–2 min, render desktop +2–3 min ensuite.
• url est obligatoire et limité à 500 caractères ; 422 en cas d'échec de validation.
• Les accès cross-team et cross-project livrent 403.

Modules associés

• Content Audit — inventaire à l'échelle du site plutôt qu'audit en profondeur d'une seule URL.
• Content Optimizer — optimiser la couche contenu, Page Deep Audit cible le visuel + UX.
• AI Content Editor — reprendre directement la suggestion de réécriture de headline dans l'éditeur.