Search Console Integration: Privacy-Safe SEO Analytics

Every analytics dataset you own is shrinking. Consent banners remove a share of it, browser storage limits erode the rest, and the numbers you keep describe only the visitors who agreed to be described. Search Console is the exception: it reports aggregated search behaviour that never belonged to your site in the first place, so no banner gates it and no cookie carries it.

That makes it the most durable reporting surface most sites have. It is also the one that is worst understood, because the interface hides two design decisions that change every number you export.

Why it counts as privacy-safe

The data arrives already aggregated. You get counts of impressions and clicks by query, page, country, device and date — never a user, a session or an identifier. Rare queries are removed entirely before you see them: if a phrase was searched by too few people, showing it could identify someone, so it is dropped rather than anonymised.

Two consequences follow, and both surprise people building their first pipeline.

The sum of your queries will never equal your site total. The difference is the removed long tail. On small sites it is routinely 30–50% of impressions. Nothing is broken; a reconciliation that insists on matching is chasing data that does not exist.

You cannot join it to a person. Search Console tells you a query produced a click on a page. Your analytics tells you what happened after a landing. The join between them is at page and date level, and that is the honest limit.

What the API gives you

The Search Console API has three parts worth knowing.

Search Analytics. The performance data, queried by date range with any combination of dimensions — query, page, country, device, search appearance. Up to 25,000 rows per request, with paging beyond that. Retention is sixteen months, and fresh data lags roughly two to three days.

URL Inspection. The indexing status of a single URL: whether it is indexed — the check that matters most after a migration — when it was last crawled, which canonical Google chose, whether the mobile version is usable. It is rate-limited to a couple of thousand calls per property per day, which makes it a tool for auditing a sample rather than a whole site.

Sitemaps. List, submit and read the processing status of sitemap files, including the count of discovered URLs and any errors.

Authentication is OAuth against a Google account that has access to the property, or a service account that has been added as a user. The second is what you want for anything scheduled — a service account does not expire when a person changes their password.

The four row types that double-count

This is the trap that produces inflated dashboards, and it is entirely invisible in the interface.

When you request dimensions, the API returns rows for exactly the combination you asked for. Store the results of several requests in one table and you end up with four different kinds of row living together:

A filter like WHERE page IS NOT NULL looks reasonable and silently adds the page rows to the page-and-query rows, inflating impressions by a factor of roughly 1.4 to 1.8. The correct filters are explicit on both columns: page IS NOT NULL AND query IS NULL for per-page reporting, query IS NOT NULL AND page IS NULL for per-query, and both null for the site total. Never sum across types.

The same caution applies to position. Average position is impression-weighted, so averaging the column across rows gives a number that means nothing. Weight by impressions or do not report it.

A pipeline that stays honest

The shape that works for a site of any size:

Pull daily, ask for a window rather than a day. Request the last seven days each night and upsert. Data continues to settle for two to three days, and a seven-day window backfills those corrections automatically.

Set the row limit deliberately. The limit applies to the whole request, not per day. Asking for forty days with a limit of 200 rows does not give you 200 rows a day — it gives you 200 rows for the entire range, which on a real site is the top fraction of one percent. For backfills, use the 25,000-row maximum and page through.

Store the raw rows, not a summary. Aggregations are cheap to rebuild and impossible to un-summarise. Keep date, page, query, country, device, clicks, impressions, position.

Make the primary key include every dimension. A key of date plus page, on a table that also holds query rows, silently overwrites. Where a column can be null, remember that null does not equal null in a unique index — either use sentinel values or a hash of the dimension tuple.

Log the request, not just the response. When a number looks wrong six weeks later, the only way to find out why is to know exactly what was asked.

What to build on top

Three reports repay the work immediately.

Striking distance. Queries at positions 8–20 with meaningful impressions. These are pages Google already considers relevant; small on-page work moves them into the range where clicks happen.

Impressions with no clicks. A page with thousands of impressions and a handful of clicks is either ranking for the wrong intent or wearing a title that does not match the query. Sorting by that gap finds title rewrites worth doing.

Navigational leakage. Watch for a single brand term that dominates impressions. Search interest in someone else’s product name inflates a site total and cannot be converted by any snippet change — it belongs in a separate bucket, not in your addressable numbers.

Where it fits next to analytics

Keep the two datasets in their lanes. Search Console answers what happened in the results: impressions, position, the phrases people typed. Analytics answers what happened after the click. Joining them at page and date level gives a full funnel from query to outcome without ever needing an identifier — which is exactly why this pairing keeps working while everything built on third-party storage keeps degrading.