# Why connecting Search Console is two steps, not one

> Granting Google access is account-wide; choosing the property a project reads is per project. Merging the two into one button is why integrations feel flaky.

Source: https://netweft.com/blog/search-console-two-steps
Updated: 2026-02-24

**Google access is granted once per account, and the property a project reads is chosen per project. netweft keeps them as two separate steps because a single control that sometimes does one and sometimes both is unpredictable.**

Every tool that reads Search Console has the same two facts to handle, and most
of them try to hide one.

## The two facts

**Access is account-wide.** When you complete Google's OAuth consent screen, you
grant an application access to the properties your Google account can see. That
grant belongs to your account, not to any particular project inside the tool.

**Selection is per project.** A workspace with five projects points at five
different domains, and each of them needs one property from the set the grant
exposed — the same per-project boundary that [rank
tracking](/features/rank-tracking) and the [site audit](/features/site-audit)
work within.

These are genuinely different operations. One goes to Google and comes back
with a token. The other is a choice you make inside the product and can change
without touching Google at all.

## Why one button breaks

A single "Connect Search Console" control has to guess which of those two it is
doing.

The first time you press it, it does both: consent, then selection. The second
time, on a different project, it does only the second — unless the grant has
been revoked, or the scopes have changed, or you are signed into a different
Google account, in which case it silently does both again. Sometimes it opens a
popup. Sometimes it does not. Nothing about the label tells you which.

That is the whole reason these flows feel unreliable. It is not the OAuth. It
is a control whose behaviour depends on state you cannot see.

## How netweft does it

Two steps, always, in the same order, with the same labels.

You grant access once. netweft asks for read-only Search Console and GA4 scopes
at the moment you connect the integration, not at sign-in — signing in only
needs to know who you are, and asking for analytics scopes at that moment is
how a login screen becomes something people close.

Then, per project, you choose a property. That choice is a project setting. You
can change it, and changing it does not go anywhere near Google.

The result is that both screens say what they do, and neither of them depends
on invisible state to decide what pressing the button means.

## Read-only, and asked for late

Two smaller decisions follow from the same principle.

The scopes are read-only. netweft reads Search Console and GA4; it never writes
to either. Requesting write access "in case we need it later" is how an
integration ends up refused by the person who actually administers the account.

And the request happens at connection time. A first-run experience that asks for
analytics access before you have created a project is asking you to trust
something you have not evaluated yet. The grant is worth more when it is asked
for by a product you have already decided to use.

Nothing about the connection is metered, incidentally: Search Console and GA4
are your own data coming back from Google, so no credits are reserved for
reading them. The [rate card](/pricing) covers the lookups netweft buys from a
data vendor, which is a different set of operations entirely.