Cómo crear una analítica SEO de un sitio web multilingüe mediante la API de GSC y BigQuery

¿Te gustaría probar Octo Browser con descuento?
Usa el código promocional OCTOBLOG para obtener un 30% de descuento en cualquier suscripción. Esta oferta es válida solo para nuevos usuarios.

Por qué dejar de depender de las interfaces web

Un sistema fiable de analítica SEO comienza por eliminar las exportaciones manuales. La interfaz de Google Search Console resulta útil para consultar rápidamente las métricas, pero sus posibilidades no son suficientes para realizar una analítica de producto en profundidad.

La API de GSC permite obtener datos con un nivel de detalle mayor, por URL individuales, consultas de búsqueda y otras dimensiones. Esto permite trabajar no solo con informes agregados, sino también con los datos de origen a partir de los cuales puedes crear tus propios segmentos y métricas.

Para entender las ventajas de esta arquitectura, es importante tener en cuenta varios factores clave.

Cardinalidad de los datos y limitaciones de la interfaz web

Uno de los principales problemas de la interfaz de GSC es la cantidad limitada de datos que muestra. En un proyecto multilingüe esto resulta especialmente crítico: cuando hay muchas páginas, países, dispositivos y consultas, una parte considerable de la información queda fuera del informe estándar.

Aquí entra en juego la cardinalidad: el número de combinaciones únicas de parámetros en un conjunto de datos. Por ejemplo, si un sitio web funciona en 10 idiomas, recibe tráfico de 50 países, utiliza 3 tipos de dispositivos y obtiene datos de 10.000 consultas de búsqueda, el número de combinaciones posibles puede alcanzar millones de filas.

Trabajar con semejante volumen desde la interfaz web es prácticamente imposible. La API permite obtener muchos más datos y dividir la exportación en segmentos independientes. Gracias a los filtros y al procesamiento secuencial, puedes recopilar no solo la parte superior de los resultados, sino también la larga cola de consultas y URLs que normalmente se pierde en los informes estándar.

Data Lake y almacenamiento histórico

Google Search Console almacena en su interfaz los datos históricos únicamente de los últimos 16 meses, lo que no es suficiente para una analítica SEO a largo plazo.

Un almacén de datos propio, como BigQuery, resuelve este problema. Puedes guardar periódicamente allí los datos sin procesar obtenidos mediante la API sin estar limitado por el periodo de almacenamiento de la interfaz de GSC. Así dispondrás de una base de datos histórica de SEO que podrás utilizar para análisis a largo plazo, creación de informes y reprocesamiento de los datos según cualquier dimensión necesaria.

Dependencia de servicios externos y coste del escalado

Para automatizar las exportaciones de datos puedes utilizar conectores ETL ya preparados, como servicios SaaS del tipo Supermetrics o Fivetran. Permiten configurar rápidamente la transferencia de datos sin desarrollar una solución propia, pero a medida que el proyecto crece, este enfoque puede resultar caro y generar una dependencia excesiva de un servicio concreto.

Las plataformas SaaS cobran por sus servicios en función del volumen de filas procesadas o del número de conectores. Cuando tu proyecto multilingüe empiece a generar gigabytes de datos SEO crudos al día, el coste de un servicio de este tipo puede superar varias veces el coste de almacenar los datos en BigQuery y alquilar un servidor pequeño para ejecutar scripts de Python.

Además, cuanto más integrado esté el servicio en el proceso de recopilación y transformación de datos, más difícil será prescindir de él posteriormente: la migración puede requerir volver a configurar conectores, lógica de procesamiento e informes.

Nivel de detalle de los datos

Al recopilar datos mediante la API, es importante conservar el máximo nivel de detalle posible. Si combinas los datos ya durante la exportación, después no podrás recuperar las dimensiones originales.

Por ejemplo, al diseñar una base de datos SEO, conviene guardar por separado parámetros como el tipo de dispositivo (Device) y el país (Country). Si el script solicita los datos sin desglosarlos por país, GSC devolverá el número total de clics de la consulta. Después será imposible determinar cuántos clics procedían de Alemania y cuántos de Francia.

Por eso es preferible almacenar los datos de forma detallada y combinar y calcular las métricas finales solo durante la fase de análisis o visualización. Así mantienes la posibilidad de crear en el futuro cualquier segmento de datos que necesites, incluso si no se había previsto originalmente en los informes.

Limitaciones de la API de GSC al exportar grandes volúmenes de datos

A primera vista, trabajar con la API de GSC parece sencillo: autorizar el script, obtener los datos, guardarlos en la base de datos y pasar al análisis. En la práctica, los proyectos grandes se encuentran rápidamente con las limitaciones técnicas de la API.

Si intentas exportar grandes volúmenes de datos sin tener en cuenta estas limitaciones, puedes encontrarte con tiempos de espera agotados, errores 429 Too Many Requests y exportaciones incompletas. Como consecuencia, solo una parte de los datos llegará al almacén y el propio sistema funcionará de forma inestable.

Por eso, al construir el pipeline, es importante tener en cuenta de antemano los límites de la API, el retraso en la actualización de los datos, las cuotas de solicitudes y los mecanismos para repetir las solicitudes en caso de error. Veamos las principales limitaciones de la API de GSC y cómo trabajar correctamente con ellas.

Límite de 50.000 filas y segmentación de las exportaciones

Según la documentación de Google, el parámetro rowLimit permite obtener un máximo de 25.000 filas por solicitud. Para realizar la exportación paginada se utiliza el parámetro startRow: primero puedes solicitar las primeras 25.000 filas y después las siguientes 25.000.

Sin embargo, existe una limitación adicional: la suma de startRow + rowLimit no puede superar 50.000. Por tanto, para una fecha y una combinación de parámetros determinada, no podrás obtener la fila 50.001 de esta forma.

Si la cardinalidad diaria de tus datos supera las 50.000 filas, debes dividir la exportación en segmentos independientes mediante Dimension Filters. Por ejemplo, puedes solicitar los datos por separado para las carpetas lingüísticas — /de/, /fr/, etc. — o dividir adicionalmente las URLs según patrones utilizando expresiones regulares.

De esta forma podrás obtener todos los datos mediante varias solicitudes independientes dirigidas a distintos segmentos.

Retraso de los datos y uso de dataState

La API de GSC tiene un retraso sistemático en la actualización de los datos de entre 48 y 72 horas. Por eso, al realizar exportaciones diarias, es importante distinguir entre datos preliminares y datos definitivos.

Esto se controla mediante el parámetro dataState. Tiene dos valores:

• "final" (por defecto): devuelve únicamente datos completamente agregados y validados.

• "all": incluye datos recientes que todavía no han pasado por el procesamiento final.

Por tanto, al crear el pipeline surge una elección entre rapidez y precisión. Veamos ambos escenarios.

• Uso de dataState: "final" (comportamiento predeterminado). En este modo, los datos de las últimas 24 horas pueden no estar disponibles todavía. Si tu script intenta exportar yesterday con el valor predeterminado, la API devolverá un array vacío. Es necesario aplicar un desfase fijo de current_date — 3 days.

• Uso de dataState: "all". Recibirás el conjunto de datos correspondiente a las 24 horas anteriores. Sin embargo, Google advierte que los datos recientes son preliminares. El sistema todavía no ha consolidado todos los duplicados, eliminado los bots de spam ni recalculado las anomalías. Después de 2–3 días, estas cifras cambiarán en los propios servidores de Google.

Cómo puede afectar esto a la arquitectura del almacenamiento: si tu script de Python simplemente añade datos recientes sin procesar a BigQuery, tu base de datos histórica quedará distorsionada. Al guardar métricas «recientes», estás almacenando un borrador que nunca coincidirá exactamente con los informes finales de la interfaz de GSC.

Por eso, para la analítica operativa es mejor utilizar un esquema de dos etapas:

1. Exportar los datos del día anterior con dataState: "all".

2. Al mismo tiempo, el script debe volver a exportar los datos correspondientes a current_date — 4 days con el parámetro dataState: "final".

3. En BigQuery, en lugar de utilizar un simple Append, utiliza el operador MERGE (o una lógica Upsert). El script debe encontrar en la base de datos los datos preliminares de hace cuatro días y sobreescribirlos con los valores finales y consolidados.

Este enfoque permite ver métricas recientes en el dashboard y, al mismo tiempo, conservar una base de datos histórica correcta una vez finalizado el procesamiento de los datos.

Límites de la API y backoff exponencial

La API de GSC limita el número de solicitudes para proteger su infraestructura frente a una carga excesiva. La API de GSC tiene cuotas estrictas: 50 solicitudes por segundo (QPS) y 1.200 solicitudes por minuto (QPM) por proyecto. Por eso, estos límites deben tenerse en cuenta de antemano al realizar exportaciones masivas.

El problema se hace especialmente evidente cuando los datos deben dividirse en cientos de segmentos para sortear el límite de 50.000 filas. Para acelerar el proceso, los desarrolladores suelen utilizar solicitudes asíncronas (asyncio) o grupos de hilos (ThreadPoolExecutor). Pero de esta forma es fácil agotar rápidamente el límite de 50 QPS, y la API empieza a devolver errores 429 Too Many Requests o 503 Service Unavailable.

Un simple retraso mediante time.sleep() no funciona especialmente bien en este caso: si varios procesos paralelos reciben un error al mismo tiempo y después esperan exactamente el mismo intervalo, reanudarán casi simultáneamente el trabajo y volverán a crear un pico de carga.

La arquitectura correcta del script debe incluir un patrón de backoff exponencial con ruido aleatorio (Jitter). Así, el intervalo entre las solicitudes repetidas aumentará gradualmente. Los distintos procesos no repetirán las solicitudes al mismo tiempo y habrá menos probabilidades de que superen los límites.

En Python no es necesario implementar esta lógica manualmente: puedes utilizar decoradores de la biblioteca tenacity.

Recopilación de datos SEO para subdominios y carpetas lingüísticas

Una vez tenidos en cuenta los límites y retrasos de la API de GSC, la siguiente cuestión importante es cómo está estructurado el sitio web multilingüe. La estructura del proyecto influye directamente en la lógica de exportación, normalización y combinación de los datos.

En el SEO multilingüe existen dos enfoques opuestos para la estructura del sitio: subdominios nacionales y carpetas lingüísticas. Para el usuario, la diferencia es mínima, pero para generar las exportaciones la estructura puede cambiar por completo el enfoque.

Subdominios y dominios independientes

Si las versiones lingüísticas se encuentran en dominios independientes (site.de, site.fr) o en subdominios (de.site.com, fr.site.com), los datos de cada una deben recopilarse como si pertenecieran a un recurso independiente.

¿Por qué es útil para las empresas? El aislamiento por regiones permite controlar de manera más estricta el presupuesto de rastreo. El buscador no gastará el presupuesto de rastreo del bot alemán en rastrear la versión francesa del sitio. Desde el punto de vista SEO, es la vía más segura para escalar.

Para el pipeline de analítica, esto genera dos problemas:

• Más puntos de conexión. Si el proyecto tiene 10 versiones lingüísticas, el script debe consultar varios recursos de GSC de forma secuencial o en paralelo. Cuantos más orígenes existan, más importante será tener en cuenta las cuotas de la API, el tratamiento de errores y la estabilidad de toda la arquitectura de exportación.

• Complejidad de normalización de URL (unificación de datos). Las páginas con la misma finalidad en distintos dominios tendrán direcciones diferentes, por ejemplo, site.de/product y site.fr/product. Para comparar su rendimiento como una única entidad, hay que normalizar las URLs.

En la biblioteca Pandas de Python, esta normalización sería así:

import pandas as pd
from urllib.parse import urlparse

# Conservamos solo la ruta (Path) para unificar métricas de distintos países
df['normalized_url'] = df['page'].apply(lambda x: urlparse(x).path) 
# Resultado: /product

import pandas as pd
from urllib.parse import urlparse

# Conservamos solo la ruta (Path) para unificar métricas de distintos países
df['normalized_url'] = df['page'].apply(lambda x: urlparse(x).path) 
# Resultado: /product

Sin esta normalización, las métricas de las distintas localizaciones permanecerán separadas entre diferentes URL. Esto dificultará el cálculo del rendimiento global de una misma página o plantilla en distintos idiomas.

Carpetas lingüísticas y segmentación de datos

Si las versiones lingüísticas están ubicadas en carpetas, por ejemplo site.com/de/ y site.com/fr/, todo el proyecto permanece dentro de un único dominio. Esto simplifica la recopilación de datos: en lugar de realizar solicitudes independientes a varios recursos, puedes trabajar con una única Domain Property en Google Search Console.

En lugar de realizar 10 solicitudes diferentes, puedes hacer una única exportación masiva, aplicando filtros para superar el límite de 50.000 filas. Así ahorras cuotas de la API de Google y reduces la carga de red.

Una exportación grande seguirá teniendo que dividirse en segmentos. Pero la arquitectura en sí es más sencilla: menos puntos de conexión, menos solicitudes y menor carga sobre la API.

Como la API nos devuelve un flujo continuo de URL, el script debe asignar por sí mismo marcadores de país a las filas. Esto se hace mediante expresiones regulares (RegEx).

Con la biblioteca Pandas, podemos extraer el marcador de idioma directamente de la URL:

df['language_market'] = df['page'].str.extract(r'\.com/([a-z]{2})/')
# Manejo de excepciones: si RegEx devuelve NaN, se trata de la versión principal del sitio
df['language_market'].fillna('en', inplace=True)

df['language_market'] = df['page'].str.extract(r'\.com/([a-z]{2})/')
# Manejo de excepciones: si RegEx devuelve NaN, se trata de la versión principal del sitio
df['language_market'].fillna('en', inplace=True)

Así, con una URL como site.com/de/product, podemos obtener el marcador de y utilizarlo en el análisis posterior.

La principal limitación de este enfoque es su dependencia de la estructura de las URLs. La expresión regular debe coincidir exactamente con las reglas utilizadas para generar las versiones de diferentes idiomas. Si algunas páginas utilizan otro patrón, por ejemplo site.com/category-de/product, estas URL pueden clasificarse incorrectamente o incluso no entrar en el segmento correspondiente.

Por eso, antes de configurar RegEx, es importante comprobar todos los patrones posibles de las URLs de diferentes idiomas y tratar las excepciones por separado.

Transformación de datos y cálculo de métricas en Pandas

Después de recopilar y normalizar los datos, es necesario combinarlos y prepararlos para el análisis. Para esto, Pandas resulta muy útil: la biblioteca permite trabajar con tablas grandes, combinar fuentes y calcular métricas tanto por fila como por grupo.

Unir datos de GSC y GA4 por URL

Google Search Console muestra métricas de búsqueda: impresiones, clics, CTR y posiciones. GA4 las complementa con indicadores de comportamiento y de negocio, como sesiones y conversiones.

Para obtener una visión más completa del rendimiento del tráfico SEO, los datos de GSC y GA4 pueden combinarse mediante una clave común: la URL normalizada de la página de destino.

En Pandas esto se hace uniendo las tablas mediante una clave común, la URL normalizada:

import pandas as pd

# df_gsc — exportación de Search Console
# df_ga4 — exportación de GA4 (Sessions, Conversions)

# Unimos los datos por la página de destino (Left Join para no perder páginas sin tráfico)
merged_df = pd.merge(df_gsc, df_ga4, how='left', left_on='landing_page', right_on='page_path')

# Ahora podemos calcular la tasa de conversión de un clúster SEO concreto:

merged_df['seo_conversion_rate'] = (merged_df['conversions'] / merged_df['clicks']) * 100

import pandas as pd

# df_gsc — exportación de Search Console
# df_ga4 — exportación de GA4 (Sessions, Conversions)

# Unimos los datos por la página de destino (Left Join para no perder páginas sin tráfico)
merged_df = pd.merge(df_gsc, df_ga4, how='left', left_on='landing_page', right_on='page_path')

# Ahora podemos calcular la tasa de conversión de un clúster SEO concreto:

merged_df['seo_conversion_rate'] = (merged_df['conversions'] / merged_df['clicks']) * 100

Cálculo correcto del CTR y de la posición media

Al combinar los datos de varias versiones lingüísticas, no se puede calcular el CTR ni la posición media usando una media aritmética normal. Este enfoque distorsiona el resultado porque no tiene en cuenta el diferente volumen de impresiones.

Por ejemplo:

• subdominio francés: 2 clics de 4 impresiones, CTR = 50 %;

• subdominio alemán: 20 clics de 1.000 impresiones, CTR = 2 %.

Si simplemente calculamos la media de los valores de CTR, obtenemos:

(50 % + 2 %) / 2 = 26 %

Pero el CTR real de ambos subdominios es:

22 clics / 1004 impresiones = 2,19 %

Por tanto, al agregar datos de diferentes localizaciones, las métricas deben calcularse a partir de los valores originales:

• El CTR se calcula como la proporción entre el número total de clics y el número total de impresiones.

• La posición media debe ponderarse por impresiones: la posición de cada fila se multiplica por el número de impresiones y, después, la suma de esos valores se divide por el total de impresiones.

En Pandas, esto se puede implementar de la siguiente manera:

# Agrupamos los datos por consulta de búsqueda para todos los países
def weighted_metrics(x):
    # Posición media ponderada = Suma (Posición * Impresiones) / Suma (Impresiones)
    weighted_pos = (x['position'] * x['impressions']).sum() / x['impressions'].sum()
    # CTR real
    real_ctr = (x['clicks'].sum() / x['impressions'].sum()) * 100
    
    return pd.Series({
        'total_clicks': x['clicks'].sum(),
        'total_impressions': x['impressions'].sum(),
        'weighted_position': weighted_pos,
        'real_ctr': real_ctr
    })

# Aplicamos la función al dataframe agrupado
final_cluster_data = merged_df.groupby('query').apply(weighted_metrics)

# Agrupamos los datos por consulta de búsqueda para todos los países
def weighted_metrics(x):
    # Posición media ponderada = Suma (Posición * Impresiones) / Suma (Impresiones)
    weighted_pos = (x['position'] * x['impressions']).sum() / x['impressions'].sum()
    # CTR real
    real_ctr = (x['clicks'].sum() / x['impressions'].sum()) * 100
    
    return pd.Series({
        'total_clicks': x['clicks'].sum(),
        'total_impressions': x['impressions'].sum(),
        'weighted_position': weighted_pos,
        'real_ctr': real_ctr
    })

# Aplicamos la función al dataframe agrupado
final_cluster_data = merged_df.groupby('query').apply(weighted_metrics)

Automatización de la monitorización de hreflang y canibalización

Un almacén de datos propio puede utilizarse no solo para generar informes, sino también para detectar automáticamente problemas técnicos de SEO. En los proyectos multilingües son especialmente importantes dos tipos de errores: las conexiones de localización rotas y la competencia interna entre varias páginas por la misma demanda de búsqueda.

Control automático de hreflang

La optimización técnica del SEO internacional se basa en la coherencia y bidireccionalidad de las etiquetas de localización. La etiqueta hreflang funciona como un sistema estricto de referencias cruzadas bidireccionales. Si, por ejemplo, una página francesa enlaza a una página alemana como alternativa, la página alemana debe contener el enlace de vuelta correspondiente. La ruptura de esta cadena rompe todo el clúster a ojos de Google.

En un proyecto grande es imposible comprobar manualmente estas relaciones, por lo que el control debe basarse en la comparación de al menos dos fuentes de datos:

• Screaming Frog. Ejecuta el crawler según un calendario. Analiza la presencia real de las etiquetas en el código HTML y valida los códigos de idioma (ISO 639-1) y de país (ISO 3166-1 Alpha 2). El resultado se exporta a una base de datos.

• GSC API. La API de Search Console proporciona un informe de indexación y muestra cómo interpretó Google estas relaciones durante el último rastreo.

Los resultados del rastreo y los datos de Google pueden almacenarse en una misma base de datos y después compararse mediante SQL. Por ejemplo, FULL OUTER JOIN permite encontrar errores críticos en los datos agregados: páginas que técnicamente tienen etiquetas correctas en el código, pero que han sido ignoradas por el buscador.

Las causas pueden ser muchas. Una posibilidad es el renderizado del lado del cliente: los frameworks de JavaScript (React, Vue) tardan demasiado en renderizar las etiquetas dentro de <head>, o las métricas de rendimiento (Core Web Vitals) son tan bajas que Googlebot agota el tiempo de espera antes de poder leer hreflang. La automatización permite detectar estos problemas antes de que el tráfico empiece a caer.

Canibalización del tráfico y búsqueda de URLs en conflicto

El segundo problema de los sitios multilingües es la competencia interna. La canibalización aparece cuando el buscador se confunde sobre la relevancia y empieza a posicionar, por ejemplo, la versión inglesa de una página para una consulta de Alemania, aunque exista una landing page específicamente en alemán.

En la interfaz estándar de GSC, este tipo de solapamientos es difícil de analizar a gran escala. Si los datos sin procesar se almacenan en BigQuery, la posible canibalización puede detectarse automáticamente mediante SQL.

El algoritmo para detectar la canibalización es el siguiente:

1. Agrupamos los datos por dos parámetros: query y country.

2. Contamos el número de URL únicas (COUNT(DISTINCT page)) que reciben impresiones para esa combinación.

3. Filtramos los resultados mediante HAVING count > 1.

Si varias páginas reciben impresiones para la misma combinación query + country, esto es una señal de un posible conflicto de relevancia.

Los datos de GSC pueden complementarse con una comprobación de los resultados de búsqueda reales en las regiones correspondientes. Esto resulta especialmente útil cuando la analítica ya ha detectado una anomalía, pero las cifras por sí solas no permiten determinar qué ve exactamente el usuario ni qué versión de la página muestra Google en un país concreto.

Hemos explicado los métodos para recopilar SERP automáticamente en un artículo independiente. Y cuando necesites comprobar manualmente consultas y localizaciones concretas en distintos entornos regionales, puedes utilizar un navegador antidetección como Octo Browser.

Artículo relacionado

Web scraping de los resultados de búsqueda de Google: tutorial (2026)

Cómo complementa Octo Browser la analítica SEO

GSC y BigQuery son herramientas adecuadas para detectar problemas en grandes volúmenes de datos. Por ejemplo, pueden ayudarte a detectar que una página alemana ha empezado a perder impresiones, que para las consultas de un país concreto se está posicionando la localización incorrecta o que varias URL compiten entre sí.

Pero después de detectar un problema suele surgir otra pregunta: ¿qué exactamente ve el usuario en los resultados de búsqueda?

Los datos de GSC ayudan a detectar una anomalía y entender su magnitud. Para diagnosticar un caso concreto, resulta útil consultar los resultados desde la región correspondiente y comprobar cómo se comporta el sitio web.

Aquí puede resultar útil Octo Browser. Para distintos países puedes crear perfiles separados, conectar proxies con la geolocalización necesaria y realizar comprobaciones en sesiones de navegador aisladas. Esto resulta especialmente práctico cuando trabajas regularmente con varias geolocalizaciones y no quieres mezclar cookies, historial y otros datos entre las distintas comprobaciones.

Imaginemos que nuestro script detecta que la URL inglesa recibe impresiones de consultas de Alemania, aunque el sitio tenga una versión alemana completa en /de/. Esto todavía no significa que el problema esté necesariamente relacionado con la localización. Primero conviene comprobar qué está ocurriendo exactamente en los propios resultados de búsqueda.

Abrimos un perfil de Octo con un proxy alemán y comprobamos qué URL muestra Google para la consulta correspondiente. Al mismo tiempo, podemos comprobar si se abre la versión correcta del sitio, si existe una redirección automática a otra localización y si el contenido de la página corresponde a la región seleccionada.

Del mismo modo, puedes comprobar de forma selectiva:

• la aparición de una versión lingüística incorrecta en las SERP;

• las diferencias de resultados entre varias regiones;

• el funcionamiento de las redirecciones regionales;

• la localización del contenido, los precios y otros elementos de la página;

• los cambios después de corregir hreflang, canonical o el enlazado interno.

De este modo, la API de GSC y BigQuery permiten detectar casos sospechosos a escala de todo el proyecto, mientras que Octo Browser ayuda a analizar anomalías concretas utilizando las geolocalizaciones necesarias en un entorno aislado.

Conclusión

Trasladar la analítica SEO de las interfaces web a un sistema propio de recopilación y almacenamiento de datos supone pasar la gestión del proyecto a un nivel completamente nuevo.

Al principio, esta arquitectura requiere más trabajo técnico: hay que configurar la autorización, el tratamiento de errores, la normalización de datos, las exportaciones periódicas y la gestión de los procesos. Pero, como resultado, obtienes un sistema que escala junto con el proyecto y que no depende de las limitaciones de las interfaces web.

En lugar de recopilar informes manualmente, tendrás una única base de datos histórica en la que podrás analizar todas las versiones lingüísticas de tu sitio web, recalcular correctamente las métricas, detectar problemas técnicos y crear los segmentos de datos que necesites sin perder nivel de detalle.