How to build a topic cluster dashboard in Looker Studio

A topic cluster dashboard in Looker Studio needs three parts: Search Console's URL Impression table as the data source, one calculated field that names the cluster each page belongs to, and three charts that read every cluster side by side. It takes about an hour to build, and every cluster you add later shows up in it without a new report.

The point is a weekly answer to one question per cluster: is it reaching more searches than last month, and which pages are doing the reaching. Search Console's Performance report can show you one folder at a time. The dashboard shows all of them on one screen, with the pages nobody filed sitting in a bucket of their own.

Start from Search Console's URL Impression table

When you add the Search Console connector, Looker Studio asks for a table: Site Impression or URL Impression. Pick URL Impression. It's the table with the Landing Page dimension, and a cluster dashboard is built on landing pages. The Site table has Average Position and no Landing Page, so it can't group pages at all.

Expect the two tables to disagree. Google counts impressions differently by page and by property. When several of your URLs show up in one search result, the property view counts one impression for the whole result, and the page view counts one for each URL. So your cluster totals will add up to more than the site total in the Performance chart. That's how the data is built, and there's nothing to reconcile.

Two settings to fix on day one. Set the search type to web, because the URL table also carries Discover and Google News, which would mix feed traffic into your search numbers. And set the default date range to the last 16 weeks, so every chart opens with enough history to show a trend.

Name every cluster with one calculated field

Add a field called Cluster to the data source. It's a CASE statement that reads the landing page and returns a name:

CASE
  WHEN REGEXP_CONTAINS(Landing Page, "/guides/rank-tracking/") THEN "Rank tracking"
  WHEN REGEXP_CONTAINS(Landing Page, "/guides/") THEN "Guides (other)"
  WHEN REGEXP_CONTAINS(Landing Page, "/blog/(utm-|ga4-)") THEN "Attribution"
  ELSE "Unclustered"
END

Three rules make it hold up.

Order matters. CASE stops at the first match, so a child folder goes above its parent. Put "/guides/" first and the rank tracking pages land in the wrong group.

Folders beat slug lists. If a cluster lives in its own URL folder, one pattern catches every page you'll ever publish in it. That's the practical case for giving each cluster its own URL folder. On a flat /blog/ you're back to listing slug fragments, and every new post means an edit to the field.

Keep the Unclustered bucket. It's the most useful line on the dashboard. A page that belongs to a cluster but sits in Unclustered is a page your cluster numbers can't see. When that bucket starts gaining impressions, open it and file what's in it.

Looker Studio uses RE2 regular expressions, so lookaheads won't work. Keep the patterns plain.

Build three charts and stop there

Impressions by cluster, by week. A time series with Date set to ISO year week, Impressions as the metric and Cluster as the breakdown. This is the chart you read first. A cluster gaining impressions is being shown for more searches, whatever any single keyword did.

The cluster table. One row per cluster with URL Clicks, Impressions and a count of distinct Landing Page values. That last column is how many pages in the cluster earned at least one impression in the period. Hold it against the number of pages you've published there. Say you've published twelve and seven earn impressions: that's five pages Google isn't showing yet, and those are your first refresh candidates.

Queries inside one cluster. A table with Query, Landing Page, clicks and impressions, plus a drop-down control on Cluster. Sort by query. When the same query shows two of your landing pages with similar impressions, the two pages are splitting it, and that's where a cluster leaks.

There's no average position on this dashboard. The URL table doesn't carry it, and averaging positions across a cluster hides more than it shows anyway. Keep position in your rank tracker, read as a median for the cluster's tagged keywords, the way we set it up in rank tracking for a topic cluster. The dashboard covers reach. The tracker covers rank.

Where the numbers go thin

Search Console keeps at most 50,000 rows of performance data per day, per search type, per property. A small B2B site never gets near it. A site with thousands of programmatic pages can, and past that line the query table stops holding every row.

Google also leaves out queries that are rare or could identify someone. That's why the query chart for a cluster adds up to fewer impressions than the cluster's line in the time series. Use the time series for totals and the query table for patterns.

Both gaps hit every week the same way, so week-over-week trends stay honest even when the absolute numbers run short.

Read it once a week, in the same order

Monday morning, ten minutes. Open the time series and find the cluster whose line changed direction. Open the cluster table and check whether its count of pages earning impressions moved with it. Then open its queries and look for pairs of pages on one query.

A cluster with rising impressions and a rising page count is working: keep publishing into it. Flat impressions with new pages added means the new pages aren't getting picked up, so check their internal links from the pillar. Falling impressions across one cluster while the others hold is a change worth an hour, and your change log is the first place to look.

If you want a cluster dashboard built on your own Search Console data and read with you every week, that's the kind of work we do at vibhe.