Where does your Google token go? Questions to ask any Search Console app

Every third-party Search Console app, this one included, works the same way: you sign in with Google, grant the app permission to read your Search Console data, and from then on the app holds a credential that can read everything Google knows about your sites’ search traffic. Google classes that permission as sensitive, and it is right to. Reviews of apps in this category are full of people asking, reasonably, what exactly they just handed over and to whom.

So here are the questions we think you should ask before signing in to any of them, with our own answers written out. The questions are more important than the answers; put them to every app, and be suspicious of any that cannot answer plainly.

What are you actually granting?

When you sign in, Google shows a consent screen listing what the app is asking for. For a Search Console app, it is the Search Console scope: permission to list your properties and read their performance data, inspect URLs and view sitemaps on your behalf. Google requires apps requesting that scope to go through its verification process, and an app that has not will show you a warning screen saying so. Read the consent screen. It is the one document in this process that Google wrote rather than the app.

QueryWatch asks for the Search Console scope and nothing else: no Gmail, no Drive, no Analytics. The privacy policy names the specific API calls it makes.

Does the app talk to Google directly from your phone, or through its own server?

Either can be legitimate, but it determines whether a copy of your data exists anywhere other than your phone and Google.

QueryWatch talks to Google directly from the device. On iPhone, your refresh token is stored in the Keychain. On Android, Google Play services hold the grant and the app never receives a refresh token at all. With the default settings there is no row about you on any server of ours, because there is no server in the path.

If it offers push alerts, where does the credential go?

This is the question that matters most, and the one apps are quietest about. A notification has to be computed while your phone is asleep, and a phone cannot reliably run a background job every few hours. So the check runs on a server, and that server needs permission to read your Search Console data. An app that offers alerts and does not explain this is leaving out the most important sentence in its privacy policy.

Our answer: with alerts off, which is the default, nothing leaves the device. When you turn alerts on, a Google credential is sent to our relay, the refresh token on iPhone, or on Android a one-time authorisation code that the relay exchanges for a token of its own. The relay is our own server in Germany, not a third-party backend service. The credential is stored encrypted at rest with libsodium and decrypted in memory only while a scheduled check runs, every six hours. The app shows you exactly this, in a consent screen of four sentences, before anything is sent.

What happens when you turn it off?

Ask whether “off” means deleted or means archived. For QueryWatch, turning alerts off deletes the row, the rules, the watched URLs and the alert history immediately. Not soft-deleted, not kept for thirty days. Gone, and you can turn them back on later with a fresh grant.

Can you delete everything without asking anyone?

An app that requires you to email support to remove your data has given you a promise rather than a control. There should be a route that needs nobody’s cooperation.

For QueryWatch there are three. In the app: Settings, then Privacy and data, then Delete all my data. Without the app: revoke QueryWatch’s access at myaccount.google.com/permissions, which makes every credential it holds useless immediately, whether or not we have deleted it. And a public page, delete my data, that needs no login and says what exists in the first place, so you know what you are deleting. If you had alerts on and want to be certain the relay row is gone, an email to [email protected] gets it removed, but you do not need us for the first two.

Does the privacy policy name the APIs and carry Google’s Limited Use wording?

Google requires apps that use its APIs to commit to its Limited Use policy: the data is used to provide the feature you asked for, not sold, not used for advertising, not read by humans except in narrow cases. A privacy policy that does not carry that commitment, in Google’s words, has either not been reviewed or is hoping you will not look.

Ours does, verbatim, and it names everyone who sees anything: Apple for payment, RevenueCat for subscription status, Google Analytics 4 with Firebase Crashlytics for anonymous product analytics and crash reports, and the German server the relay runs on. Nobody else, and your Search Console data goes to none of them.

Does it also track rankings?

A rank tracker scrapes Google’s results pages to find positions for keywords, which breaks Google’s terms of service. An app that holds your Google credential and also runs scraping infrastructure is putting your account next to behaviour Google does not allow. QueryWatch shows the average position Google itself reports in Search Console, for queries your site actually appeared for, and will never scrape. Why QueryWatch is not a rank tracker is the longer version.

Stay suspicious, including of us

A consent screen is a promise, not a proof. What you can verify is the permissions page in your Google account, which shows every app with access and what it was granted, and which lets you revoke any of them in one tap. Check it after you sign in to anything, and check it again in a month. An app that is honest about where your token goes should be pleased that you did.