Consultas de BigQuery para Search Console que sí sirven

Crea el proyecto en Google Cloud y activa BigQuery

Necesitas una cuenta de Google Cloud con la facturación activada, lo que implica meter una tarjeta aunque no vayas a pagar nada. Dentro, crea un proyecto nuevo, habilita la API de BigQuery y anota el ID del proyecto.

Después hay que darle permiso a Google para que escriba ahí: en IAM, añade la cuenta de servicio search-console-data-export@system.gserviceaccount.com con el rol de Usuario de tareas de BigQuery y el de Editor de datos de BigQuery. Si te saltas esto, la configuración del paso siguiente falla.

Activa la exportación desde Search Console

En la propiedad de Search Console, ve a Ajustes → Exportación de datos masiva. Pon el ID del proyecto de Cloud, elige el nombre del conjunto de datos (por defecto searchconsole) y la ubicación. Continuar.

Dos cosas importantes de este paso:

• No trae histórico. La exportación empieza a partir del día que la activas. Todo lo anterior se queda solo en la interfaz. Cuanto antes la actives, antes empiezas a acumular.
• Tarda un par de días en aparecer la primera carga. A partir de ahí llega sola cada día.

Conoce las tres tablas antes de escribir SQL

Esto es lo que ahorra más tiempo, porque la mitad de las consultas mal escritas vienen de usar la tabla equivocada:

• searchdata_site_impression — datos agregados por propiedad. Tiene query, país, dispositivo y tipo de búsqueda. No tiene la URL. Si buscas datos por keyword del sitio entero, es esta.
• searchdata_url_impression — datos por URL. Tiene url y también query, más un montón de columnas de tipo de resultado (si saliste en un resultado enriquecido, en el pack local, como vídeo…). Es la que más se usa.
• ExportLog — el registro de qué días se han cargado. Sirve para detectar huecos.

Y la trampa que descuadra todos los totales: la columna is_anonymized_query. Google oculta las búsquedas poco frecuentes por privacidad, y esas filas llegan con el campo query vacío y esa marca a true. Si sumas clics agrupando por query, el total te va a salir por debajo del real, y la diferencia puede ser grande.

Depende de lo que quieras: para un total fiel, no agrupes por query; para analizar keywords, filtra WHERE is_anonymized_query = false y sé consciente de que estás mirando una parte.

Lanza las consultas que de verdad sirven

Cambia tu-proyecto por el ID de tu proyecto y ajusta las fechas.

Keywords donde estás en segunda página (el empujón más rentable)

Las que ya rankean entre la 11 y la 25 con impresiones de sobra: estás cerca y no te llevas nada.

SELECT
  query,
  SUM(impressions) AS impresiones,
  SUM(clicks) AS clics,
  SUM(sum_position) / SUM(impressions) + 1 AS posicion_media
FROM `tu-proyecto.searchconsole.searchdata_site_impression`
WHERE data_date BETWEEN '2026-07-01' AND '2026-07-31'
  AND is_anonymized_query = false
GROUP BY query
HAVING impresiones > 200
   AND posicion_media BETWEEN 11 AND 25
ORDER BY impresiones DESC
LIMIT 50

URLs con muchas impresiones y CTR bajo (problema de título, no de posición)

SELECT
  url,
  SUM(impressions) AS impresiones,
  SUM(clicks) AS clics,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SUM(sum_position) / SUM(impressions) + 1 AS posicion_media
FROM `tu-proyecto.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-07-01' AND '2026-07-31'
GROUP BY url
HAVING impresiones > 1000
   AND ctr < 0.02
ORDER BY impresiones DESC

Filtra además por posición media menor que 10 y tienes la lista exacta de páginas que salen arriba y no las clica nadie. Ahí no se toca el contenido: se tocan el título y la descripción.

Páginas que se han caído respecto al mes anterior

WITH actual AS (
  SELECT url, SUM(clicks) AS clics_actual
  FROM `tu-proyecto.searchconsole.searchdata_url_impression`
  WHERE data_date BETWEEN '2026-07-01' AND '2026-07-31'
  GROUP BY url
),
anterior AS (
  SELECT url, SUM(clicks) AS clics_anterior
  FROM `tu-proyecto.searchconsole.searchdata_url_impression`
  WHERE data_date BETWEEN '2026-06-01' AND '2026-06-30'
  GROUP BY url
)
SELECT
  a.url,
  p.clics_anterior,
  a.clics_actual,
  SAFE_DIVIDE(a.clics_actual - p.clics_anterior, p.clics_anterior) AS variacion
FROM actual a
JOIN anterior p USING (url)
WHERE p.clics_anterior > 30
  AND SAFE_DIVIDE(a.clics_actual - p.clics_anterior, p.clics_anterior) < -0.3
ORDER BY p.clics_anterior DESC

El filtro de más de 30 clics en el periodo anterior es lo que evita el ruido: sin él te salen cien URLs que pasaron de 2 clics a 1.

Canibalización: dos URLs peleando por la misma búsqueda

Esta es la consulta que no puedes hacer en la interfaz y que más valor da.

SELECT
  query,
  COUNT(DISTINCT url) AS urls_compitiendo,
  STRING_AGG(DISTINCT url, ' | ' LIMIT 5) AS ejemplos,
  SUM(impressions) AS impresiones
FROM `tu-proyecto.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-07-01' AND '2026-07-31'
  AND is_anonymized_query = false
GROUP BY query
HAVING urls_compitiendo > 1
   AND impresiones > 100
ORDER BY urls_compitiendo DESC, impresiones DESC

Que dos URLs salgan alguna vez por la misma búsqueda no es un problema en sí. Lo es cuando las dos se turnan sin que ninguna consolide. Esas son las candidatas a fusionar.

Qué páginas están perdiendo el sitio en los resultados enriquecidos

SELECT
  url,
  SUM(IF(is_amp_top_stories OR is_job_listing OR is_job_details, impressions, 0)) AS impresiones_enriquecidas,
  SUM(impressions) AS impresiones_totales
FROM `tu-proyecto.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN '2026-07-01' AND '2026-07-31'
GROUP BY url
ORDER BY impresiones_totales DESC
LIMIT 50

La tabla trae una columna booleana por cada tipo de resultado. Cámbialas por las que te interesen según tu web (las de vídeo si publicas vídeo, las de producto si tienes tienda) y verás qué páginas están consiguiendo esos formatos y cuáles no.