What access Crawlert asks for in Search Console — and what it cannot do
Connecting a monitoring service to Search Console means handing over access to the reporting layer of your own site. That deserves a straight answer rather than a reassuring one, so here is the straight answer — including the part that sounds worse than “read-only”.
We ask for Full, not Restricted
Search Console has three permission levels: Owner, Full user, Restricted user. We ask you to add our service account as a Full user.
We would prefer to ask for less. We can’t. The URL Inspection API — the only endpoint we use — is not available to Restricted users. Call it with a Restricted principal and Google returns 403. There is no read-only tier that includes URL inspection, and no configuration on our side changes that.
So the honest framing is not “we only need read access”. It is: Google’s API requires this level, that level technically permits more than reading, and here is precisely what we do with it.
What Full access permits — and what it does not
A Full user on a property can view every report, use URL Inspection, submit sitemaps and use the tools available in the interface.
A Full user cannot:
- add, remove or change other users’ permissions;
- remove the property or alter its verification;
- transfer or claim ownership;
- see anything about properties they were not explicitly added to.
That last point is the important one. Access is granted per property. Adding our service account to example.com gives it nothing on any other site you own, and nothing on any site anyone else owns. There is no mechanism by which a Full user can add itself to another property.
What we actually call
One endpoint:
POST https://searchconsole.googleapis.com/v1/urlInspection/index:inspect
That is the entire surface of our integration. One request per URL per scheduled check, carrying the URL and the property it belongs to, returning the index status.
We do not call the Indexing API. We do not submit sitemaps through Search Console. We do not request removals. We do not use the Search Analytics endpoint, so we never read your queries, clicks or positions. If you audit the requests hitting your property, index:inspect is all you will find.
When a project uses sitemap syncing, we fetch the sitemap file over plain HTTP from your site, the same way any crawler would — not through Search Console.
Why a service account rather than “Sign in with Google”
OAuth would let us request narrower scopes on paper, but it comes with an access token tied to your Google account, sitting in our database, refreshing itself indefinitely. If that token leaks, it carries your identity.
A service account inverts the arrangement. It is a separate principal with its own address, visible in your Users and permissions list by name. It holds nothing about your Google account. You can see it, audit it, and remove it — and the moment you do, every call we make starts returning 403 and monitoring stops. No token to revoke on our side, no lingering session, no support ticket.
Each project in Crawlert shows the exact service account address assigned to it, on the project settings page. That is the address to look for in Search Console, and the one to remove if you want us gone.
What we cannot do at all
We cannot monitor sites you don’t control. The API only answers for properties where the calling principal has been granted access. Any tool claiming to monitor indexing of arbitrary third-party URLs is not using this API — it is scraping search results, which is unreliable, rate-limited and against Google’s terms. We don’t do it, and we say so on the pricing page rather than in the footnotes.
We cannot make a page index. Nothing we do influences Google’s decisions. We report them.
We cannot see more than you can. Everything Crawlert shows comes from the same inspection data available to you in the interface. We add history and timing, not privileged access.
What we store
Per URL: the URL itself, the verdict, the coverage state, the robots and indexing states, the canonical Google selected, the last crawl time, and our own timestamps. That is what makes the history and the alerts possible.
We keep the raw API response only when a verdict changes — that is the moment worth being able to re-read later. Unchanged checks store the summary fields and nothing more, which is also why the database stays a database rather than a landfill.
We do not store page content, and we never receive it: the API returns status metadata, not HTML.
How to revoke
Search Console → Settings → Users and permissions → find the service account address → Remove.
Checks stop within minutes. Your data stays in Crawlert until you delete the project or the account; deleting the project removes it and its history, and deleting your account removes everything.
If you revoke access without deleting the project, we will tell you: our monitoring notices the 403, marks the project as disconnected, and emails you — because a monitoring tool that goes quiet when it stops working is worse than no monitoring at all.
If that trade — Full access to a property, one endpoint, one call per URL per day — is one you’re comfortable with, connecting a site takes about ten minutes. If it isn’t, we would rather you decided that from an accurate description than from a comfortable one.