Cómo conectar Google Search Console a Looker Studio (y qué hacer cuando se queda corto)

Search Console es una de las pocas fuentes que Looker Studio conecta de forma nativa, gratis y en unos noventa segundos. En resumen: en Looker Studio (que Google volvió a llamar Data Studio en abril de 2026) creas una fuente de datos con el conector de Search Console, lo autorizas, eliges la propiedad, el tipo de tabla y el tipo de búsqueda, y conectas. Esta guía hace bien esa parte: los pasos exactos y la única decisión de configuración que, sin avisar, marca qué preguntas podrá responder tu dashboard durante toda su vida. Después repasa los cuatro límites con los que acaba chocando cualquier dashboard de Search Console, porque «gratis y nativo» no es lo mismo que «suficiente».

Conéctalo: los pasos exactos

Necesitas una propiedad verificada en Search Console y una cuenta de Google con, al menos, permisos restringidos sobre ella. Después:

1. En Looker Studio, elige Crear → Fuente de datos (Create → Data source en la interfaz en inglés) y busca Search Console. Es un conector hecho por Google, así que aparece arriba en la lista, sin distintivo de socio y sin precio.
2. Autoriza el conector con la cuenta de Google que tiene acceso a la propiedad.
3. Elige la propiedad. La lista muestra tanto propiedades de dominio (sc-domain:example.com) como propiedades con prefijo de URL (https://example.com/).
4. Elige el tipo de tabla: Impresión del sitio (Site Impression) o Impresión de la URL (URL Impression). Esta es la decisión que importa, y la siguiente sección trata solo de ella.
5. Elige el tipo de búsqueda: Web, Imagen, Vídeo o Noticias. Queda fijado en cada fuente de datos, así que un informe que necesite Web e Imagen necesita dos fuentes de datos.
6. Pulsa Conectar y después Crear informe. Añade un gráfico de serie temporal con los clics y ya tienes un dashboard funcionando.

Google describe los mismos pasos, con las etiquetas de la interfaz en español, en su ayuda: Conectarse a Search Console.

La decisión que te sale cara después: Impresión del sitio o Impresión de la URL

El conector te pide elegir una de dos tablas, y la diferencia no es estética: las dos tablas cuentan de forma distinta, así que dan totales distintos para los mismos días.

• Impresión del sitio te da Consulta (Query), país, dispositivo y fecha, pero no la página de destino. Cuenta como el gráfico del resumen de Search Console, por propiedad: si dos de tus páginas aparecen en una misma búsqueda, eso es una sola impresión.
• Impresión de la URL te da la página de destino (el campo Landing Page) y la Consulta, además de país, dispositivo y fecha. Cuenta por página: la misma búsqueda que muestra dos de tus páginas son dos impresiones, y los clics y el CTR corresponden a cada URL.

Así que la pregunta de SEO más natural, ¿qué consultas traen tráfico a esta página?, sí se puede responder en Looker Studio, pero solo desde la tabla Impresión de la URL y solo con su forma de contar. Sus impresiones no van a coincidir con los totales de Impresión del sitio ni con el resumen de Search Console para las mismas fechas. Ninguno de los dos números está mal: Google agrega por propiedad los datos por consulta, país, dispositivo y fecha, y por página los datos por página (ayuda de Search Console sobre el informe de rendimiento).

La trampa es mezclarlas. Un gráfico o una combinación de datos que junta las dos tablas suma números contados de dos maneras distintas, y nada en el lienzo te lo avisa. Elige una tabla por pregunta: Impresión de la URL cuando la pregunta tiene que ver con páginas, e Impresión del sitio cuando necesitas los totales que ven en Search Console quienes reciben tus informes.

Lo que el conector sigue sin darte

Incluso en la tabla Impresión de la URL, las consultas que Google anonimiza por privacidad faltan en todas las filas por consulta, así que una tabla de consulta por página siempre suma menos que los clics de la propia página. La propia API de Search Analytics de Search Console devuelve las dos agregaciones, por propiedad y por página, y cualquier herramienta que la lea de forma periódica puede guardarlas una junto a otra: el detalle de consulta por página al lado de los totales del sitio, que sí incluyen el tráfico anonimizado, y más allá de los dieciséis meses que conserva Search Console.

Así que la solución no es un gráfico mejor. Es leer la misma API en un lugar que conserve las dos vistas.

Los cuatro límites, en el orden en que te los vas a encontrar

1. Dieciséis meses y ni uno más

Search Console guarda unos dieciséis meses de datos de rendimiento. Looker Studio los consulta en vivo, así que el historial de tu dashboard es el historial de Search Console: no hay ningún archivo detrás. La primera vez que alguien te pida comparar la estacionalidad de dos años, la respuesta será que esos datos ya no existen en ninguna parte, salvo que los hayas estado guardando tú todo ese tiempo.

2. Las consultas anonimizadas hacen que los números nunca cuadren

Search Console filtra las consultas de muy baja frecuencia por motivos de privacidad (ayuda de Search Console). La consecuencia toma por sorpresa a mucha gente: la suma de una tabla por consultas siempre será menor que la tarjeta de clics del sitio en la misma página. Ninguno de los dos números está mal; miden poblaciones distintas. Pero quien vea dos totales que no coinciden va a preguntar por ello todos los meses, y un gráfico de «consultas principales» omite toda la cola larga mientras parece completo.

3. Los dos últimos días no son definitivos

Search Console publica datos recientes en cuestión de horas y luego los revisa al alza a medida que termina de procesarlos. Un dashboard del lunes que incluye el día anterior muestra un número provisional que Google subirá más adelante esa semana. Nada en el lienzo de Looker Studio marca qué filas siguen asentándose: la línea cae en el borde derecho del gráfico y alguien lo interpreta como una bajada.

4. Todo se queda en el lienzo

Cada pregunta nueva es un gráfico nuevo, hecho a mano por quien tenga permisos de edición. Una combinación de datos admite como máximo cinco fuentes y te da uniones (joins) en lugar de SQL. Así que cuando la pregunta pasa a ser «¿cómo evolucionaron los clics orgánicos frente a la inversión en anuncios el último trimestre?», acabas cuadrando dos dashboards a ojo, que es justo el momento en que la gente empieza a preguntarse si el lienzo es el contenedor adecuado. Desarrollamos ese argumento en alternativas a Looker Studio (en inglés).

La otra vía: leer la misma API donde sí puedes cruzar los datos

TableBI conecta Search Console con el mismo flujo OAuth y guarda los datos en dos niveles: search_console_raw, la tabla propia de la plataforma que mantiene consulta y página juntas en cada fila (los totales del sitio, los totales por página y país × dispositivo están en tablas aparte), y facts, donde los clics y las impresiones siguen las mismas definiciones entre canales que tus plataformas de anuncios. La configuración son tres comandos:

# instalar la CLI y enseñar a tu agente a usarla
npm i -g @tablebi/cli
tablebi login
tablebi install

# se abre el navegador para OAuth y después se sincroniza el histórico
tablebi connect gsc --site sc-domain:example.com

# confirmar qué se cargó y lo actualizado que está
tablebi sources

Ahora, la pregunta de consulta por página es una sola sentencia, sobre una copia almacenada en vez de la API en vivo:

# ¿qué consultas llevan impresiones a qué páginas?
tablebi ask "SELECT query, page, SUM(clicks) AS clicks,
             SUM(impressions) AS imp, AVG(position) AS pos
             FROM search_console_raw
             WHERE date >= (SELECT MAX(date) FROM search_console_raw) - 28
             GROUP BY query, page
             ORDER BY imp DESC LIMIT 50"

Hay dos detalles deliberados en esa consulta. El filtro de fechas se ancla en MAX(date) y no en la fecha de hoy: como los dos últimos días todavía no son definitivos, «hoy» aún no es una fila que exista, y anclar el filtro al calendario te deja una ventana vacía cada mañana. Y cada respuesta llega con un bloque de confianza (trust block): lo actualizada que está cada fuente y las advertencias que importan aquí, que los dos últimos días son provisionales y que las sumas por consulta se quedan por debajo de los totales del sitio por diseño. Tu agente lee esas advertencias y deja de presentar con total seguridad una revisión como si fuera una caída.

Si quieres el flujo de trabajo completo de Search Console y no solo la conexión, está en Claude Code para SEO; si lo que buscabas era la API en bruto sin escribir un cliente OAuth, mira la alternativa a la API de Search Console. Los dos artículos están en inglés.

La pregunta a la que el lienzo no llega

La razón para sacar Search Console de su propio dashboard casi nunca es Search Console. Es que lo orgánico es una línea dentro de un panorama que también incluye los anuncios, y el límite de la combinación de datos es donde ese panorama deja de poder construirse:

# clics orgánicos junto a la inversión en anuncios: un resultado, las mismas definiciones
tablebi ask "SELECT platform, SUM(clicks) AS clicks, SUM(cost) AS spend
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY platform ORDER BY clicks DESC"

Fíjalo en una URL en vivo

Cuando una vista merece conservarse, fíjala. Lo que se guarda es la consulta, no una captura, así que la URL se actualiza sola cada vez que la fuente se sincroniza:

tablebi pin --title "Search Console — 28 days" \
  --widget "Daily clicks::line=SELECT date, SUM(clicks) AS clicks FROM search_console_raw …" \
  --widget "Top query × page=SELECT query, page, SUM(impressions) AS imp FROM search_console_raw …"
✓ published → https://dk.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

Aquí tienes uno real: datos en vivo de Search Console de una cartera de sitios, fijado exactamente así. No es una maqueta; se actualiza a medida que se sincronizan las fuentes: