Build a Looker Studio dashboard

Design site- and URL-level Search Console views with useful filters, comparisons, and blended context.

Combined data Additional data required Intermediate

A useful Search Console dashboard preserves the source’s scope instead of forcing every metric into one page. Keep site-impression and URL-impression data separate, expose the active property and Search type, use weighted metric calculations, and treat Google Analytics blends as contextual—not as proof that clicks equal sessions.

Looker Studio is a presentation and query layer. Its direct Search Console connector does not make the underlying data more complete than Search Analytics. For warehouse-scale rows, retained history, or governed transformations, connect Looker Studio to BigQuery bulk-export models instead.

Choose the data path first

Direct Search Console connector

Use the native connector when:

  • the dashboard needs a quick setup;
  • the property’s important rows fit within Search Analytics limits;
  • 16 months of available history is enough;
  • transformations are modest;
  • report editors can manage Search Console credentials safely.

This path is well suited to team scorecards and exploratory dashboards. It inherits query privacy, top-row availability, aggregation rules, and Search Console freshness.

BigQuery data source

Use modeled BigQuery bulk-export tables when:

  • long-tail completeness materially matters;
  • history must be retained beyond the Search Console window;
  • URLs require taxonomy, product, author, or template enrichment;
  • multiple reports need governed definitions;
  • large joins or scheduled transformations would be fragile inside Looker Studio.

BigQuery adds storage, query cost, IAM, and pipeline ownership. Build tested aggregate tables at the dashboard’s grain so each chart does not scan raw high-cardinality exports.

Connect the direct Search Console source

In Looker Studio:

  1. create a data source and select the Search Console connector;
  2. authorize the connector;
  3. choose the exact Search Console property;
  4. choose Site Impression or URL Impression;
  5. choose the default Search type;
  6. connect and review field types and default aggregations.

The Google Account needs at least view permission on the property. If a property is missing, verify that Looker Studio and Search Console use the same account and that the expected property—not a similar URL-prefix—is selected.

Keep site and URL impressions separate

One Search Console connector data source can use only one table type.

Site Impression

Use this for property-level performance, query trends, countries, devices, and Search types supported by that table. It follows site-level impression aggregation and does not provide a landing URL dimension.

URL Impression

Use this for landing pages, page-query relationships, URL-level search appearances, Discover, and Google News where supported. It follows page-level aggregation.

Create two data sources and place them on clearly labeled pages. Do not blend the two merely to display their clicks side by side or sum them into one total. Search Console calculates site and URL impressions differently, and a graph’s property-level total need not equal the sum of detailed page rows.

Use a dashboard structure that matches decisions

1. Executive overview

Show finalized clicks, impressions, CTR, and average position for one named property and Search type. Include a date comparison, last refresh time, and annotation or release context.

The overview should answer:

  • Is the change material in absolute terms?
  • Did clicks and impressions move together?
  • Is the comparison equivalent and complete?
  • Which segment deserves investigation?

2. Query view

Use the Site Impression source for top and changing queries. Include minimum-impression controls and separate branded or topic logic whose definition is documented.

Do not label the table “all queries.” Privacy-protected queries and lower-ranked rows can be absent while still contributing to totals.

3. Landing-page view

Use URL Impression for pages, directories, and page groups. Prefer a maintained URL taxonomy in BigQuery for complex classifications; giant calculated-field regular expressions embedded across charts are difficult to test and version.

4. Market and device view

Use country and device filters to explain aggregate changes. Compare like with like rather than declaring a low CTR “bad” across different positions or result environments.

5. Data-quality panel

Show source type, property, Search type, maximum complete date, refresh time, row-cap or privacy warnings, and pipeline status. A dashboard without visible data state encourages people to interpret preliminary or stale numbers as final.

Configure controls carefully

Useful report controls include:

  • date range and comparison;
  • Search type parameter;
  • country and device;
  • page group or directory;
  • query category;
  • minimum impressions;
  • branded/non-branded classification version.

Test every control on every page. A control can silently apply only to compatible data sources or charts. Do not let one “Search type” label imply that it filters a separate source where the field or supported values differ.

Set sensible defaults—usually a complete recent period rather than today—and display the selection in chart titles.

Calculate metrics at the correct grain

Clicks and impressions are additive over compatible rows. CTR is not. Calculate:

CTR = SUM(Clicks) / SUM(Impressions)

Do not use the average of row CTR values. Average position is impression-weighted and should use a trusted source metric or summed-position model; do not average row positions across pages, queries, or dates.

Round only for display. Preserve enough precision for comparisons, and use absolute differences alongside percentage changes so tiny baselines do not dominate a winner/loser table.

Design comparisons that remain interpretable

Use complete periods with matching weekdays. Add year-over-year context for seasonal sites. Keep Web, image, video, News, Discover, and Google News separate.

For a change table, include:

  • current and comparison clicks;
  • absolute click difference;
  • impressions and their difference;
  • CTR and percentage-point difference;
  • position as supporting context;
  • enough volume to judge materiality.

A percentage-only table tends to rank noise from low-volume rows above important losses.

Blend Search Console and GA4 only with a declared question

Search Console clicks and GA4 sessions measure different systems. Differences can arise from attribution, consent and JavaScript, time zones, canonical versus landing URLs, redirects, bot processing, and one click creating zero, one, or multiple sessions.

The safest dashboard places Search Console acquisition metrics and GA4 onsite outcome metrics in adjacent panels. If a blend is necessary, use a controlled grain such as normalized landing page plus date and document the limitations.

Before joining:

  1. normalize hostname, protocol, path, trailing slash, parameters, and redirects;
  2. reconcile Search Console Pacific Time with the GA4 property time zone;
  3. aggregate both sources to unique join keys first;
  4. test for duplicate keys and many-to-many row multiplication;
  5. keep clicks and sessions as separate metrics;
  6. state whether Search Console uses canonical URLs while GA4 records visited URLs.

Never calculate a generic “conversion rate from GSC clicks” without explaining consent loss, attribution scope, and the join population.

Avoid unsafe blends

Blending is unsafe when:

  • either side has multiple rows per join key;
  • queries are joined to GA4, which generally has no equivalent Search Console query dimension;
  • site-level totals are joined to URL-level rows;
  • different Search types are mixed;
  • the blend reaggregates already averaged CTR or position;
  • unmatched rows are silently discarded;
  • dashboard filters change one side but not the other.

When the logic is important, model the join in BigQuery with tests and expose a clean result table to Looker Studio.

Choose credentials and sharing deliberately

Looker Studio supports owner’s, viewer’s, and in some contexts service-account credentials.

  • Owner’s credentials let viewers see data through the owner’s access; losing that owner can break or expose reports.
  • Viewer’s credentials require every viewer to have source access and are appropriate for strict source-level permission enforcement.
  • Service-account credentials can support managed non-human access where the connector and organization setup allow it.

Share the minimum data needed, review report and source permissions, and avoid using a departing employee’s identity as production infrastructure.

Understand freshness

Google marketing and measurement connectors, including Search Console, have a documented 12-hour data-freshness setting in Looker Studio. Manual report refresh cannot make Search Console publish source data sooner.

Display both the dashboard refresh time and the maximum Search performance date. A recently refreshed dashboard can still contain preliminary or lagged source data.

For BigQuery, the dashboard’s readiness should depend on successful bulk export and downstream transformation completion, not merely the Looker Studio cache.

Validate before launch

Use this QA sequence:

  1. match a simple finalized daily property total against Search Console;
  2. confirm the same property, Search type, dates, and aggregation;
  3. test CTR with summed clicks and impressions;
  4. compare page totals separately from property totals;
  5. test every control on every chart;
  6. inspect duplicate join keys in every blend;
  7. test zero-data, low-volume, and missing-current-day states;
  8. verify owner/viewer behavior with a second account;
  9. document source, refresh, and known coverage limitations on the report.

Common dashboard mistakes

  • Using one unlabeled data source for both site and URL questions.
  • Summing site- and URL-impression metrics.
  • Calling the query table complete.
  • Averaging CTR or position.
  • Showing today by default without a preliminary-data warning.
  • Comparing clicks with GA4 sessions as if they should match.
  • Creating a many-to-many blend that inflates metrics.
  • Hiding the property, Search type, active dates, or refresh state.
  • Embedding critical business logic in unversioned chart formulas.
  • Giving every viewer the dashboard owner’s unrestricted credentials.

Official sources