Why connecting Search Console is two steps, not one
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 and the 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 covers the lookups netweft buys from a data vendor, which is a different set of operations entirely.