Connect Google Search Console to Looker Studio — and what to do when it hits the wall

Search Console is one of the few sources Looker Studio (renamed Data Studio in April 2026) connects to natively, for free, in about ninety seconds. This guide does that part properly — the exact steps, plus the one setup choice that quietly decides which questions your dashboard will be able to answer for the rest of its life. Then it covers the four walls every Search Console dashboard eventually runs into, because "free and native" is not the same as "sufficient". If the connector is already set up and the data isn't showing, go straight to the troubleshooting checklist.

Connect it: the actual steps

You need a verified Search Console property and a Google account with at least restricted access to it. Then:

1. In Looker Studio, choose Create → Data source and search for Search Console. It's a Google-built connector, so it sits near the top of the list with no partner badge and no price.
2. Authorize the connector against the Google account that has access to the property.
3. Pick the property. The list shows both domain properties (sc-domain:example.com) and URL-prefix properties (https://example.com/).
4. Pick the table type — Site Impression or URL Impression. This is the choice that matters; the next section is entirely about it.
5. Pick the default search type — Web, Image, Video or News; the URL Impression table also offers Discover and Google News. Charts show only that type unless you add a control for the data source's Search type parameter, so the simplest way to show Web and Image side by side is two data sources.
6. Connect, then Create report. Drop in a time series of clicks and you have a working dashboard.

The choice that costs you later: Site Impression vs URL Impression

The connector asks you to pick one of two tables, and the difference is not cosmetic: the two tables count differently, so they give different totals for the same days.

• Site Impression gives you Query, country, device and date — but no landing page. It counts the way the Search Console overview chart does, by property: when two of your pages appear for one search, that is a single impression.
• URL Impression gives you Landing Page and Query, plus country, device and date. It counts by page: the same search showing two of your pages is two impressions, and clicks and CTR belong to each URL.

So the most natural SEO question — which queries bring traffic to this page? — is answerable in Looker Studio, but only from the URL Impression table, and only in its counting. Its impressions will not match the Site Impression totals or the Search Console overview for the same dates. Neither number is wrong: Google aggregates by property for queries, countries, devices and dates, and by page for pages (Search Console Help, Performance report).

The trap is mixing them. A chart or blend that combines the two tables adds numbers that were counted two different ways, and nothing on the canvas says so. Pick one table per question: URL Impression when the question involves pages, Site Impression when you need the totals your stakeholders see in Search Console.

What the connector still can't give you

Even in the URL Impression table, queries Google anonymizes for privacy are missing from every query-level row, so a query-by-page table always sums to less than the page's own clicks. Search Console's own Search Analytics API returns both aggregations, by property and by page, and anything that reads it on a schedule can keep them side by side — the query-by-page detail next to the site totals that still include anonymized traffic, and past the sixteen months Search Console retains.

So the fix isn't a better chart. It's reading the same API somewhere that keeps both views.

The four walls, in the order you'll hit them

1. Sixteen months, hard stop

Search Console retains roughly sixteen months of performance data. Looker Studio queries it live, so your dashboard's history is Search Console's history — there is no archive behind it. The first time someone asks for a two-year seasonality comparison, the answer is that the data no longer exists anywhere unless you were storing it yourself the whole time.

2. Anonymized queries mean the numbers never reconcile

Search Console filters out very low-frequency queries for privacy reasons (Google Search Central on data filtering and limits). The consequence catches people out constantly: the sum of a query-level table will always be smaller than the site-level clicks card on the same page. Neither number is wrong; they're different populations. But a stakeholder staring at two totals that disagree will ask about it every single month, and a "top queries" chart is quietly omitting the entire long tail while looking complete.

3. The last two days aren't final

Search Console publishes fresh data within hours and then revises it upward as processing completes. A Monday dashboard that includes yesterday is showing a provisional number that Google will raise later in the week. Nothing on the Looker Studio canvas marks which rows are still settling — the sparkline dips at the right edge and someone reads it as a drop.

4. It stays in the canvas

Every new question is a new chart, built by hand, by whoever has edit rights. A blend tops out at five data sources and gives you join semantics rather than SQL. So when the question becomes "how did organic clicks track against paid spend last quarter", you are reconciling two dashboards by eye — which is exactly the moment people start wondering whether the canvas is the right container at all. We took that argument further in Looker Studio alternatives.

The other route: read the same API where you can join it

TableBI connects Search Console through the same OAuth flow, then keeps the data in two altitudes: search_console_raw, the per-platform table that keeps query and page together on every row (with site totals, page totals and country × device in tables of their own), and facts, where clicks and impressions sit in the same cross-channel definitions as your ad platforms. Setup is three commands:

# install the CLI and teach your agent to drive it
npm i -g @tablebi/cli
tablebi login
tablebi install

# browser opens for OAuth, then the backfill syncs in
tablebi connect gsc --site sc-domain:example.com

# confirm what landed, and how fresh it is
tablebi sources

Now the query-by-page question is one statement, run against a stored copy rather than the live API:

# which queries bring impressions to which pages?
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"

Two details in that query are deliberate. The date filter anchors on MAX(date) rather than today's date — because of wall #3, "today" is not a row that exists yet, and anchoring on the calendar gives you an empty window every morning. And every answer comes back with a trust block: how fresh each source is, plus the caveats that matter here — that the last two days are provisional, and that query-level sums fall short of site totals by design. Your agent reads those and stops confidently reporting a revision as a decline.

If you want the full Search Console workflow rather than just the connection, that's Claude Code for SEO; if what you actually wanted was the raw API without writing an OAuth client, see the Search Console API alternative.

The question the canvas can't reach

The reason to move Search Console out of its own dashboard is rarely Search Console. It's that organic is one line in a picture that also contains paid, and the blend cap is where that picture stops being buildable:

# organic clicks next to paid spend, one result, same definitions
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"

Pin it to a live URL

When a view is worth keeping, pin it. What gets stored is the query, not a snapshot — so the URL refreshes itself every time the source syncs:

tablebi pin --title "Search Console — 28 days" \
  --widget "Daily clicks::line=SELECT date, SUM(clicks) AS clicks FROM search_console_totals_raw WHERE search_type = 'web' …" \
  --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)

Here is a live dashboard on real data you can open now: Search Console totals across the TableBI founder's own sites. It is a different dashboard from the one described above, published the same way, and it re-runs its queries as the sources sync (what the demo shows, and what it doesn't):