Funcionalidad final del proyecto¶

Resultado funcional¶

SEO Growth Engine no es una pagina estatica ni una maqueta. Hemos desarrollado una aplicacion que autentica usuarios, separa clientes, lanza procesos largos, consulta integraciones, genera artefactos y conserva historico.

Nuestro flujo empieza cuando un usuario pulsa Run analysis y termina con un informe reutilizable, ficheros de salida y un registro historico del proceso.

Comparacion del flujo de trabajo¶

Sin una aplicacion propia, el trabajo SEO queda repartido entre herramientas, exportaciones y notas manuales. En nuestro proyecto hemos reunido esas partes en un flujo unico dentro de la aplicacion.

Sin nuestra aplicacion

Crawler externo Issues tecnicos en una herramienta

Search Console Queries, paginas y CTR en otra pestana

GA4 Sesiones, fuentes y landings separadas

ChatGPT Prompts manuales sin historico operativo

Resultado: informacion dispersa, copias manuales, poco historico y mucho trabajo para convertir datos en decision.

VS

Con SEO Growth Engine

Un solo workspace

Crawl GSC GA4 AI Visibility

Runs, logs, permisos, artefactos, reportes e historial en la misma plataforma.

Resultado: ejecuciones, permisos, artefactos, reportes e historial quedan relacionados en la misma aplicacion.

Pipeline completo¶

1. Login Usuario Django y permisos por sitio

→

2. Dashboard Sites, integraciones y ultimos runs

→

3. Run setup Crawl, GSC, GA4, IA y rango de fechas

→

4. Worker Redis/RQ ejecuta sin bloquear la web

→

5. Report HTML, CSV, JSON, logs e historial

Como funciona realmente por dentro¶

Este es el flujo tecnico real cuando el usuario lanza una ejecucion desde la plataforma:

Capa usuario

Login / Dashboard

Formulario de run

Django

Valida permisos

Crea AnalysisRun

Guarda opciones

Cola

Redis + RQ

Worker

Motor

Crawler

GSC API

GA4 API

OpenAI

Salida

PostgreSQL

CSV / JSON

Report HTML

Historial

En este flujo, el usuario dispara la accion desde la interfaz. La ejecucion pesada ocurre en segundo plano, mientras Django guarda progreso, logs, errores y artefactos para que la interfaz pueda consultar el estado.

Modulos de una ejecucion¶

Modulo	Que hace	Salida generada
`Technical crawl`	Recorre la web, detecta paginas HTML, assets, enlaces internos y problemas tecnicos	`pages.csv`, `assets.csv`, `issues.csv`, redirects, canonical, estructura URL
`GSC`	Consulta Google Search Console por query y pagina	quick wins, CTR leaks, canibalizacion, winners, losers, clusters y oportunidades
`GA4`	Consulta Google Analytics 4 con la Data API	sesiones, usuarios, page views, engagement, conversiones, landings y fuentes
`AI Visibility`	Ejecuta prompts contra OpenAI con salida estructurada	menciones de marca, dominio citado, competidores, posicion y score
`Report`	Une todo lo anterior en un informe HTML y artefactos descargables	informe final, CSVs, JSON, logs y comparativa historica

Como se hace el crawl¶

El crawl se lanza desde engine/runner.py mediante run_audit_pipeline(). Esa funcion llama a engine/crawler.py con una configuracion controlada:

max_pages limita el numero de paginas para evitar rastreos infinitos.
crawl_delay controla el ritmo y evita golpear demasiado el sitio.
timeout_seconds evita que una pagina bloqueada pare toda la ejecucion.
SEO_CRAWL_CONCURRENCY permite ajustar concurrencia desde entorno.

Despues del rastreo se aplican auditorias:

audit_pages() detecta problemas de titulos, H1, thin content y errores.
internal_link_graph() genera informacion de enlazado interno y orfandad.
audit_redirects() revisa redirecciones, cadenas y errores.
audit_canonical() analiza canonicals ausentes o cruzados.
audit_url_structure() detecta profundidad y URLs dinamicas.

El resultado del crawl no se queda solo en una lista tecnica. Generamos CSVs, acciones priorizadas y un informe HTML.

Como funciona GSC¶

El modulo de GSC vive en engine/gsc.py. Usa una service account y la propiedad configurada en el Site, por ejemplo sc-domain:going.international.

El flujo es:

Se cargan credenciales con google.oauth2.service_account.
Se crea un cliente de searchconsole.
Se consulta searchanalytics().query() con dimensiones query y page.
Se comparan dos periodos: actual y anterior.
Se generan bloques SEO accionables.

Bloques que se calculan:

quick_wins: keywords con impresiones y posicion cercana a primera pagina.
ctr_leaks: consultas con mucha impresion pero CTR inferior al esperado.
cannibalization: varias URLs compitiendo por una misma query.
winners_pages y losers_pages: paginas que suben o bajan frente al periodo previo.
new_queries y movers_queries: oportunidades nuevas y movimientos relevantes.
bigram_clusters: agrupaciones semanticas para detectar patrones de contenido.

Como funciona GA4¶

El modulo GA4 vive en engine/ga4.py y usa la Google Analytics Data API.

El flujo es:

Se recibe el property_id configurado en el sitio.
Se crea BetaAnalyticsDataClient con la service account.
Se consulta un periodo actual y uno anterior.
Se normalizan metricas para que el informe no dependa del formato crudo de Google.
Se calculan fuentes, landings y posibles referencias desde asistentes IA.

Metricas que genera:

sesiones;
usuarios;
page views;
engaged sessions;
engagement rate;
conversiones;
landing pages;
source / medium;
trafico desde fuentes relacionadas con IA como ChatGPT, Perplexity, Gemini, Copilot o Claude.

Como funciona AI Visibility¶

La capa de AI Visibility vive en engine/ai_visibility.py. No se limita a pedir texto libre a un modelo. Usa prompts configurados por sitio y una salida estructurada para poder guardar resultados consistentes.

El flujo es:

El sitio tiene AIVisibilityPrompt activos con categoria, prompt y keywords.
El worker llama a run_visibility_analysis().
Se crea un cliente OpenAI usando OPENAI_API_KEY.
Se ejecuta cada prompt con instrucciones de analisis SEO.
Se pide respuesta estructurada con campos como brand_visible, domain_cited, mentions y cited_urls.
Se calcula un prompt_score.
Se guardan resultados en AIVisibilityRun, AIVisibilityObservation o se adjuntan al informe del AnalysisRun.

Esto permite analizar si, ante determinados prompts, aparece la marca, se cita el dominio, aparecen competidores y que posicion estimada se obtiene.

Seguimiento durante el run¶

Durante una ejecucion, el backend actualiza:

progress_percent;
current_step;
status_message;
log_output;
status;
artifacts.

Con estos campos podemos mostrar seguimiento, cancelacion, reintento, errores visibles e historial.

Demo recomendada¶

Entrar con tutor / tutor123 para mostrar la vision interna reproducible de revision.
Entrar con going-client / going12345 para demostrar acceso limitado a un unico cliente.
Abrir el site Going International.
Mostrar tarjetas de integracion: GSC, GA4 y AI Visibility.
Abrir un run existente o lanzar uno controlado.
Mostrar progreso, logs, artefactos y report.
Cerrar explicando que todo queda en la base de datos para historico y trazabilidad.

Si el entorno se ha inicializado con los valores por defecto del comando bootstrap_dashboard, el usuario interno puede llamarse boss. Para la defensa y la revision reproducible usamos tutor, porque es el usuario documentado en la guia de arranque local.

Cierre funcional¶

La funcionalidad final une datos tecnicos, rendimiento organico, visibilidad en IA y acceso cliente. No funciona como un script aislado, porque incorpora usuarios, permisos, workers, integraciones, informes e historial.