How Do You Build a Monthly SEO Reporting View in Looker Studio?

How do you build a monthly SEO reporting view in Looker Studio?

Connect Search Console as a data source, choose your aggregation table deliberately, add a second data source for the other aggregation, then build four charts and stop. The whole job is under an hour, and the only decision that genuinely matters is the one most people click past in ten seconds.

One naming note before the steps, because it will confuse you otherwise. Google's own connector documentation now carries a line saying Looker Studio is now called Data Studio, and the help pages use the Data Studio name throughout while still living on looker-studio URLs. Both names refer to the same product, so search for either.

This tutorial assumes you own or have view access to a Search Console property and want a report you can send a client or a founder every month without rebuilding it.

How do you connect Search Console as a data source?

Sign in, then on the home page click Create in the top left and select Data Source. Choose the Search Console connector and click Authorize if prompted. In the Sites panel choose your property, in the Tables panel choose Site Impression or URL Impression, in the Search Type panel choose the default search type, then click Connect in the upper right.

If your property does not appear in the Sites panel, the cause is almost always one of two things Google names directly. You need to be signed in to both products with the same Google Account, and you need at least view permission on the property. Neither is obvious from the empty list you are staring at.

Once connected, the data source fields panel appears. This is where you rename fields, add descriptions, create calculated fields, and change data types and aggregations. Renaming fields to the words your client actually uses is a small act of kindness that saves explaining the report every month.

Which table should you choose, and why does it matter?

This is the decision that defines your report. Google states that Search Console uses two different aggregation methods for reporting on search performance, site impressions and URL impressions, that the connector gives access to both, and that a single data source can only use one of them.

The practical consequence is that your totals change depending on which one you picked, and a client comparing your report to something they saw elsewhere will find a discrepancy that is not an error. Site impression aggregation counts at the property level. URL impression aggregation counts at the page level. Same underlying reality, two valid ways of counting it.

Google's own advice is the right move here: to see site impressions and URL impressions side by side, create two data sources and add both to a single report. I build both by default, because the moment somebody asks why two numbers differ is the moment you want the answer already on the page.

Which search types are available on each table?

Not the same set, and this catches people building Discover reporting. Google's documentation gives Site Impression access to web, image, video and news, while URL Impression adds discover and googleNews on top of those four.

So if Discover traffic matters to the site you are reporting on, that requirement alone decides your table choice. You cannot get Discover data from the site impression aggregation, no matter how you configure the rest of the report.

There is also a nicer way to handle search type than hard coding it. Google notes that data sources created with the connector provide a Search type parameter, and describes wiring it to a drop-down list control by editing the report, adding a control, selecting the drop-down list, and choosing the Search type parameter in the Setup tab. One report, viewer selectable.

What is the blank query row in your report?

Privacy protection, not a bug. Google explains that to protect user privacy Search Analytics does not show all data, that it might not show some queries made a small number of times or those containing personal or sensitive information, and that these can be aggregated into a single row with a blank value.

That blank row is often large, and left in place it makes your top queries table look broken. Google's suggested fix is straightforward: use a filter in the report to exclude null values from the Query dimension.

What I would not do is delete the row and say nothing. If a client's biggest query row is blank, that is a fact about how much of their search demand is long tail or sensitive, and it is worth one sentence of explanation rather than silent removal.

How do you control who can see the data?

Through the credentials setting at the top of the data source fields panel. Google describes three options, owner's credentials, viewer's credentials and service account credentials, and they control who can see the data that this data source provides. The difference matters more for a shared client report than it looks.

Owner's credentials let other people view or create reports using the data source without needing their own access to the dataset. Viewer's credentials require each user to supply their own credentials to access the data. Service account credentials use a special type of Google Account representing a non-human user that can authenticate and be authorised to access data.

For a monthly client report, owner's credentials are usually the right choice and also the one to think about hardest, because you are deciding that anyone with the link inherits your access to that data. Decide it consciously rather than accepting the default and discovering later who the link reached.

What should actually be on the report?

Four things, and resisting the fifth is the skill. A time series of clicks and impressions by month. A table of top pages with clicks, impressions and average position. A table of top queries with the blank row filtered out. And a comparison against the same period last year.

Everything else is decoration that costs you credibility when it moves for reasons nobody can explain. Device breakdowns, country breakdowns and search appearance charts are all interesting once a quarter and noise every month.

The year over year comparison is the one people skip and the one that does the most work. Search demand is seasonal, and a month over month drop that is actually seasonality will otherwise generate a panicked email you have to answer with a caveat you could have designed in.

How do you make it reusable across clients?

With a data control rather than a copy of the report. Google notes that data controls give report viewers a way to select the account providing the data, and that they can eliminate the need to create separate reports and data sources for each account. That is the difference between maintaining one report and maintaining eleven.

If you would rather start from something prebuilt, Google points to its template gallery, which has a Search Console category you can use as is or customise. I usually start from a template, delete about half of it, and keep the parts I would have built anyway.

Either way, build one canonical version and change it in one place. The failure mode for agency reporting is not the first build, it is the twelfth variant that has drifted and now disagrees with the others. If you also report on conversions, the plumbing I described in wiring Webflow Analyze conversions into Looker Studio sits alongside this cleanly.

What does this report not tell you?

Anything about why. It shows Google Search performance and, on the URL impression table, Discover and Google News. It does not show other search engines, it does not show AI assistants that are not Google, and it does not explain a movement it displays.

That is worth saying in the report itself, in one line, because an unlabelled dashboard implies completeness. The most common misreading I see is treating a Search Console report as a report on all demand, which then makes any channel outside it invisible in the conversation.

Use it to find the pages worth investigating, then investigate elsewhere. Falling impressions on a cluster of posts is a prompt to audit them, which I went through in auditing and pruning low performing blog posts, and a page appearing with no clicks is often a technical or markup issue rather than a content one, which is where finding schema errors with Search Console comes in.

What should you do next?

Build the two data sources today, one on each aggregation table, and put them in the same report before you style anything. That single step removes the most common reporting argument you will ever have, and it takes about ten minutes.

Then add the query filter for null values and the year over year comparison, and stop there for the first month. A small report you actually send beats a comprehensive one you keep meaning to finish. If you want a second opinion on whether your reporting view is measuring the right four things, reach out and send me a screenshot.