Page-Deep-Audit (Vision + Render IA)

Page-Deep-Audit es el análisis más profundo que Rankion aplica a una sola URL. En lugar de señales de contenido como Content Audit (Site-Crawl), Page-Deep-Audit mira la landing page como producto visual: 3 screenshots (Desktop, Tablet, Mobile con emulación real de UA), métricas Lighthouse, un análisis multimodal con Opus-4.7 sobre layout, trust, CTA, persona-fit, issues críticos — más hasta 3 renders IA con gpt-image-2 que muestran cómo podría verse visualmente la variante óptima. Es la herramienta para CRO e iteración de landing pages, no para SEO bulk.

Qué puede hacer

• 3 screenshots origen — Desktop, Tablet, Mobile con emulación real de user-agent.
• Métricas Lighthouse — Performance, SEO, Accessibility, Best-Practices como números.
• Análisis Vision con 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 — derivados del visual, no de suposiciones.
• Critical Issues — priorizados por severity (high / medium / low) con evidence-snippet.
• Improvement Suggestions — por área (headline, cta, trust, layout, copy, visuals, forms, navigation, seo, accessibility) con ejemplo before/after.
• 3 renders IA — gpt-image-2 genera la versión ideal Desktop, Tablet, Mobile como referencia visual.
• Reescritura de headline — propuesta lista para drop-in del H1.

Cuándo usarlo

• Quieres auditar una landing page desde la óptica CRO antes de invertir dinero en ads.
• Quieres dar al diseñador una visual-reference objetiva («así debería verse»).
• Iteras una variante: Audit → ajustar → re-audit → comparar diff de score.
• Necesitas propuestas de copy guiadas por persona basadas en la página real, no en teoría de briefing.

Workflow

1. Inicia el audit — POST /page-audit con {url, tracking_project_id?, persona?}. Respuesta 202 + {id, status:"pending", url}.
2. Polling hasta completed — flujo principal ~1–2 minutos (scraping → screenshotting → analyzing → completed). Los renders IA corren +6–9 minutos en un background-job separado.
3. Lee los reports — GET /page-audit/{id} entrega 6 URLs de imagen (3 origen + 3 render IA), bloque analysis con scores, personas, issues, suggestions, headline-rewrite y métricas Lighthouse.
4. Itera — aplica las sugerencias priorizadas, despliega la página, lanza re-audit, compara diff de score.

Ejemplo 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_M=$(echo "$R" | jq -r '.ideal_mobile_url // "null"')
  [ "$STATUS" = completed ] && [ "$IDEAL_M" != null ] && break
  sleep 30
done

API

Estados de la pipeline: pending → scraping → screenshotting → analyzing → completed. Los campos de render IA (ideal_screenshot_url, ideal_tablet_url, ideal_mobile_url) se llenan tras completed uno a uno — primero Desktop, luego Tablet, luego Mobile.

Créditos y límites

• Audit principal: 30 créditos.
• Renders IA: hasta 3×15 créditos (Desktop, Tablet, Mobile).
• Audit completo con todos los renders: hasta 75 créditos por run.
• Async — flujo principal ~1–2 min, renders +6–9 min después.
• url es obligatorio y está limitado a 500 caracteres; 422 en validation-fail.
• Accesos cross-team y cross-project devuelven 403.

Módulos relacionados

• Content Audit — inventario a nivel de site en lugar de un audit profundo individual.
• Content Optimizer — optimiza la capa de contenido, Page-Deep-Audit apunta a Visual + UX.
• AI Content Editor — adopta la propuesta de headline-rewrite directamente en el editor.