Looker Studio con Search Console: un panel SEO que sí se usa

Para conectar Search Console a Looker Studio, crea una fuente de datos con el conector de Google Search Console, elige la propiedad y decide entre dos tablas: impresiones del sitio o impresiones de URL. Esa elección, que casi nadie lee con atención, determina qué cifras puedes sumar, cuáles se duplican y qué preguntas puede responder tu panel. El resto es trabajo de diseño.

Este artículo trata de la construcción de los datos, no de cómo presentar resultados a un cliente. Verás qué diferencia hay entre las dos tablas, cómo configurar la fuente, qué campos calcular, qué gráficos merecen un sitio en la página y qué errores hacen que un panel termine ignorado al cabo de un mes.

Qué ofrece el conector y qué no

El conector de Search Console es un conector nativo de Looker Studio: no necesitas API, hojas intermedias ni código. Se autoriza con la cuenta de Google que tiene acceso a la propiedad y lee los datos del informe de rendimiento, los mismos que ves en la interfaz de Search Console. Por eso hereda sus limitaciones: los datos llegan con unos días de retraso, las consultas anonimizadas no aparecen desglosadas y el historial disponible es el que Google conserva, unos dieciséis meses.

Ese último punto es el que más sorprende. Un panel conectado hoy no crea historia hacia atrás; solo muestra lo que Search Console todavía guarda. Si quieres comparar años completos, la conexión directa no basta y tendrás que archivar los datos por tu cuenta, por ejemplo con una exportación a BigQuery o con copias periódicas en una hoja de cálculo. Conviene decidirlo al principio, porque lo que hoy se borra de Search Console no se recupera después.

Tampoco es una herramienta de rastreo. El conector no te dice si una página está indexada ni por qué no lo está; entrega rendimiento en búsquedas: clics, impresiones, CTR y posición. Los informes de indexación de páginas, Core Web Vitals o datos estructurados quedan fuera y se consultan en la propia interfaz.

Tabla de sitio o tabla de URL: la decisión que condiciona todo

Al crear la fuente, Looker Studio te pide elegir el tipo de tabla. Las dos leen el mismo informe de rendimiento, pero agregan las impresiones de forma distinta, y de ahí salen diferencias reales en los totales.

En la tabla de impresiones del sitio los datos se agrupan por propiedad. Si en una misma búsqueda aparecen dos páginas de tu dominio, cuenta una sola impresión para el sitio, y la posición que se registra es la mejor de ellas. Es la tabla que coincide con los totales de la página principal del informe de rendimiento, y por eso es la adecuada para hablar de visibilidad del dominio, de tendencias globales y de consultas.

En la tabla de impresiones de URL los datos se agrupan por dirección. Cada página que aparece en una búsqueda suma su propia impresión y su propia posición. Esta tabla añade la dimensión de página de destino y permite analizar cada URL por separado, pero sus totales no cuadran con los del sitio cuando varias páginas compiten por la misma consulta: la suma de impresiones por URL puede superar la cifra del dominio.

La regla práctica es sencilla. Si la pregunta es «¿cómo va el dominio?», usa la tabla de sitio. Si la pregunta es «¿qué página rinde o no?», usa la de URL. Y si tu panel necesita las dos, crea dos fuentes de datos distintas en lugar de mezclarlas en una sola, cosa que Looker Studio no permite de todos modos.

• Tabla de sitio: totales fieles al informe de Search Console, ideal para tendencias, consultas, países y dispositivos.
• Tabla de URL: detalle por página, necesaria para rankings de contenido y para cruzar consultas con URL concretas.
• No sumes impresiones de la tabla de URL para sacar el total del dominio: cuentas varias veces la misma búsqueda.

Configurar la fuente de datos paso a paso

Desde Looker Studio, crea un informe en blanco y añade datos. Busca el conector de Google Search Console, autoriza el acceso y selecciona la propiedad. Las propiedades de dominio y las de prefijo de URL se comportan distinto: la de dominio reúne todos los subdominios y protocolos; la de prefijo solo la versión exacta que registraste. Si tienes ambas, usa la de dominio para el panel global.

Después elige el tipo de tabla y el tipo de búsqueda. Web es el valor habitual y conviene no mezclarlo con imagen, vídeo o noticias, porque son superficies con comportamientos de clic muy distintos. Si te interesa analizar una de ellas, crea una fuente aparte y nómbrala con claridad, por ejemplo «GSC sitio web» y «GSC URL imagen».

Antes de pulsar en conectar, revisa los campos que se van a importar. Looker Studio ofrece fecha, consulta, país, dispositivo y, en la tabla de URL, página de destino, junto a las métricas de clics, impresiones, CTR y posición media. Comprueba que los tipos son correctos: la fecha debe ser de tipo fecha, y el CTR y la posición deben quedar como métricas, no como dimensiones.

Un detalle que ahorra problemas: decide desde el principio quién será el propietario de la fuente. Si la autorización está ligada a una cuenta personal y esa persona se va del equipo o pierde el acceso a la propiedad, el panel se rompe sin aviso. Usa una cuenta compartida con acceso a la propiedad, o al menos documenta quién mantiene las credenciales.

Campos calculados que hacen útil el panel

Los campos que trae el conector cubren lo básico. Lo que convierte una tabla de datos en un panel que ayuda a decidir son unos pocos campos calculados, creados una vez y reutilizados en todos los gráficos.

El primero separa las consultas de marca de las que no lo son. Con una expresión CASE y una coincidencia de expresión regular sobre el campo consulta, como REGEXP_MATCH(Query, "(?i)nombre|nombre de marca"), obtienes un campo «Tipo de consulta» con los valores «Marca» y «Sin marca». Sin esta división, el tráfico de gente que ya te conocía infla el rendimiento y oculta si el SEO está captando audiencia nueva. Las mismas expresiones regulares que usas en los filtros de Search Console funcionan aquí, con la salvedad de que Looker Studio usa la sintaxis RE2.

El segundo agrupa las páginas por sección del sitio. Un CASE sobre la página de destino, buscando rutas como «/blog/», «/productos/» o «/ayuda/», te da una dimensión «Sección» que permite comparar tipos de contenido en vez de listar cientos de URL. Es el campo que más conversaciones útiles genera, porque convierte un volcado en una comparación.

El tercero clasifica la posición en tramos: 1 a 3, 4 a 10, 11 a 20 y más allá. La posición media pura engaña porque es un promedio ponderado por impresiones; agruparla en tramos deja ver cuántas consultas están cerca de la primera página y merecen trabajo. Este es el origen de la vieja táctica de buscar «casi páginas uno».

Por último, si necesitas un CTR propio, calcúlalo como clics entre impresiones sobre los datos ya agregados, nunca promediando los CTR de las filas. Promediar porcentajes da el mismo peso a una consulta con diez impresiones que a otra con diez mil, y el resultado carece de sentido.

Qué gráficos merecen estar en la página

Un panel se abandona por exceso, no por falta. Una página bien pensada tiene entre cinco y siete elementos, cada uno para responder una pregunta que alguien se hace de verdad.

Arriba van unas tarjetas de clics, impresiones, CTR y posición con comparación respecto al periodo anterior. Debajo, una serie temporal de clics e impresiones, preferiblemente con dos ejes para que la escala de las impresiones no aplaste a los clics. Cuando las impresiones suben y los clics no, la pregunta es de posición o de atractivo del resultado, no de volumen.

• Tendencia con anotaciones: serie diaria o semanal con el periodo anterior superpuesto. Añade una serie de eventos propios, como lanzamientos o migraciones, para no culpar al algoritmo de lo que fue un cambio interno.
• Tabla de consultas con tramos de posición: filtrable por «Sin marca» y ordenada por impresiones, para ver dónde hay visibilidad sin clic suficiente.
• Comparación por sección: barras de clics y CTR por tipo de contenido, usando el campo calculado de sección sobre la tabla de URL.
• Dispositivo y país: dos gráficos pequeños, útiles sobre todo para detectar que el móvil va por detrás del escritorio o que un mercado se ha caído.
• Páginas con pérdida: tabla de URL ordenada por la diferencia de clics frente al periodo anterior, que es la lista de trabajo más directa que puede salir de un panel.

Errores de datos que invalidan un panel

El fallo más frecuente es comparar cifras de fuentes distintas sin avisar. Si una tarjeta usa la tabla de sitio y una tabla de detalle usa la de URL, los totales no coinciden y alguien terminará desconfiando de ambos. Rotula en cada gráfico de qué fuente procede, o pon la fuente en el título.

El segundo es ignorar el retraso de los datos. Search Console tarda unos días en consolidar los últimos, así que un rango que incluye el día de hoy muestra una caída falsa al final de la serie. Configura el rango del informe para que termine unos días antes, o usa un rango predefinido que excluya los más recientes, y deja esa regla escrita en el propio panel.

El tercero es olvidar que las consultas anonimizadas existen. La suma de las filas de la tabla de consultas no iguala al total de clics de la propiedad, porque Google omite las consultas poco frecuentes por privacidad. Es normal; lo que no es normal es dar por bueno un porcentaje de marca calculado solo sobre las filas visibles sin tener en cuenta ese hueco.

El cuarto es la mezcla con Analytics. Los clics de Search Console y las sesiones de Analytics miden cosas distintas, y ponerlas en el mismo gráfico con el mismo eje invita a conclusiones erróneas. Si necesitas ambas, usa una combinación de datos con una clave común y entiende que solo coincidirán de forma aproximada; las razones están explicadas en nuestro artículo sobre por qué Search Console y Analytics no coinciden.

Por último, cuida el rendimiento. Las tablas de URL con miles de filas y filtros con expresiones regulares tardan en cargar. Limita el número de filas de cada tabla, evita gráficos duplicados y, si el panel sigue lento, valora la extracción a un almacén de datos antes de añadir más visualizaciones.

Cuándo el conector se queda corto

El conector nativo funciona muy bien para un sitio pequeño o mediano. Se queda corto cuando el volumen de URL y consultas obliga a muestreos, cuando necesitas más historia que los meses que conserva Search Console, o cuando quieres cruzar el rendimiento con datos propios como pedidos, márgenes o el rastreo del servidor.

La exportación masiva de Search Console a BigQuery resuelve buena parte de estos casos: guarda los datos de forma continua y los expone con mayor detalle, y Looker Studio puede leerlos desde ahí. Añade complejidad y, según el volumen, coste de almacenamiento y consulta, así que conviene dar ese paso solo cuando el panel ya se usa y se echa algo en falta, no antes.

Un criterio útil para decidir: si tras un mes el equipo abre el panel cada semana y hace preguntas que los datos no alcanzan a contestar, amplía. Si nadie lo abre, el problema no es técnico; probablemente las preguntas que responde no son las que el equipo se hace, y conviene rediseñarlo antes de invertir en infraestructura.