is giving you access safe

Privacy, in plain English.

Every job I take runs on the same permission: a client adds me to their Search Console. That deserves a straight explanation of what I can see, what I cannot, and how you switch it off. No legal fog.

What I ask for

One thing: user access to your Search Console property. You add my account yourself, from your own Settings screen, at the permission level you choose. The grant happens inside your Google account, under your control, from the first minute to the last.

What that access lets me see

Search Console shows how Google treats your site: which pages are indexed and which are not, coverage and crawl reports, sitemaps, and search performance for that one property. That is the data the whole job runs on. It does not expose your emails, your files, your customers, or anything else in your Google account.

What I never ask for

Your Google password. Your hosting or domain registrar login. Your payment details. If a fix needs a change inside your site, I tell you exactly what to change and where, or you grant the specific access you are comfortable with. Anyone claiming to be me and asking for a password is not me.

How to revoke access

Open Search Console, go to Settings, then Users and permissions, and remove me. It takes effect immediately and you do not need to warn me first. Most clients remove me the day the ledger is done; monthly clients keep me on while the monitoring runs. Either way the switch stays on your side of the table.

What ends up public

Case studies on this site name the site and link to it, because work you cannot check is not evidence. What they publish is the domain, the niche, the country, the period, and page paths with indexing status and dates. What stays private is everything behind the account: screenshots of your Search Console, your traffic and revenue figures, the names and contact details of the people I dealt with, and every message between us. If you would rather your site was not named, say so at any time and it comes off the page, no reason needed, no argument from me.

The free tools on this site

The tools ask for read-only Search Console access through Google's own sign-in screen. What happens next is the whole policy: the access token Google returns is held in your browser tab, used by your browser to call Google's API directly, and gone when you close the tab or press Disconnect. It is never sent to this site, never written to storage or a cookie, and never seen by me. The URLs you check and the results that come back live in the same place, the page, until you leave it.

One addition, stated plainly. If you choose to give the tools your email address after a run, two things are sent to Kit along with it: which tool you used, and one aggregate line of the form 2847 scanned / 61% not indexed. That line holds counts only. It never contains a URL, a domain, or the name of your Search Console property, and it is only sent if you type an address and press the button. The results themselves stay in your browser tab and are destroyed when you reload.

There is no account system and no database behind the results themselves. One server-side piece is a sitemap reader, used whenever you check a sitemap, because browsers are not allowed to read another site's sitemap directly: it takes a public sitemap address, returns the XML, keeps no copy and writes no log entry. Paste mode does not touch it, so if you want nothing at all to leave your browser and you are not using the email box, paste the URLs. No Google data ever passes through it. Google's sign-in library loads on the tool pages only, and the only thing about a tool run that reaches the analytics is roughly how big the batch was: not the URLs you paste, not the property you pick, not a single result.

There is a second stateless piece, and it belongs to one tool only: the page checker behind the sitemap health check. When you run that tool, it fetches each URL from the sitemap you submitted once, follows redirects, reads the status, the redirect target, the robots directives and the canonical, and reads at most 256 KB of the page head to do it. It identifies itself to the site it visits as shahidali.co sitemap health check, so the site owner can see it in their own logs. It writes no log line, no file and no database entry, holds nothing once the answer has been returned to your tab, and never sees a Google token because that tool does not use one. The report it feeds is built in your browser and dies with the tab, like every other report on this site.

Search Console data obtained through these tools is used for one purpose: showing you your own results in that session. It is not transferred to anyone, not used for advertising, not used to train anything, and not retained, with one named exception: the counts-only line described above, which can leave your browser two ways, both of them yours to trigger. It goes to Kit if you type your email address into the tool box and press the button. And if you follow the link from a poor result through to the contact form, that same line rides in the part of the web address that browsers never send to a server, so it reaches this site's host not at all, and it arrives in the message box, where you can read it and edit it or delete it before you do anything else; nothing is sent unless you submit the form, and if you do submit it, the form goes to Web3Forms, which keeps a copy, as set out below. You can withdraw the permission at any time at myaccount.google.com/permissions.

This website

Most of this site carries no advertising at all. Ads run on the blog posts and on the three Search Console tools, and nowhere else. The site is static HTML; the host (Vercel) keeps ordinary server logs the way every host does. If you message me on WhatsApp or by email, it lands in my inbox and goes nowhere else.

The first measurement script is Umami, and this is everything it records: the page address, the referring site, coarse device and country information derived from the request, and how quickly the page rendered for you. It sets no cookies, stores no identifier on your device, and cannot follow you across sites. I also count two actions so I know whether the site is doing its job: clicking a WhatsApp or email link, and finishing a run in the inspection tool. Those record the page you were on and, for a tool run, roughly how many URLs were in the batch. Never the URLs themselves.

The second is Google Analytics, added on 16 August 2026 so that this site's search traffic can sit next to its Search Console data in one place. Being straight about the difference: Google Analytics sets first-party cookies (_ga and one _ga_ cookie) that hold a random client identifier for two years, so it can tell a returning visitor from a new one on this site. What it receives is the page address with any query string and fragment stripped off before it is sent, the page title, the referring site, and the coarse device, browser and country data Google derives from the request. Google Signals, advertising features and ad personalisation are switched off in the tag, and IP addresses are not stored by Google Analytics 4. It does not follow you to other sites from here. Google processes this data on my behalf under its data processing terms. If you would rather it did not run, a content blocker or Google's own opt-out add-on stops it and nothing on the site breaks. One exception, deliberately: Google Analytics does not run at all on the bulk URL inspection tool. That page promises nothing reaches Google until you connect your own account, and loading Google's script on arrival would break the promise before you had agreed to anything.

I use both to see which guides get read, whether anyone uses the tools, and whether the site is slow for people on connections unlike mine. Neither is shared or sold, and neither feeds the ads described below.

Advertising

Two pages in five carry ads, and I want to be exact about which. Ads are served by Google AdSense on the blog posts and on the three Search Console tools. There are at most two on a blog post and one on a tool page. The home page, the service pages, the pricing page, the guides, the case studies and the contact page carry none, and I intend to keep it that way.

Google is the party that serves those ads, and Google sets its own cookies and reads its own identifiers to do it. That is how it decides which ad to show, how it stops showing you the same one forever, and how it counts a click. Depending on your settings and where you are, those ads may be personalised, which means Google uses what it already knows about you from elsewhere. I do not see any of that. I do not receive your identifiers, I cannot tell Google who you are, and I get nothing back except counts of views, clicks and earnings.

If you are in the UK, the EEA or Switzerland, a consent box appears before any of this starts, and nothing personalised runs until you answer it. You can change your answer later from the link in that box. Anywhere in the world you can turn personalised ads off at My Ad Center, and Google explains the rest in its advertising notice. A content blocker also stops the ads, and nothing on the site breaks when it does: every tool and every article works with the ads blocked.

One thing I will not do: the bulk URL inspection tool never sends your Search Console data, your property name or your URLs to the ad script. The ad sits below the tool and knows nothing about what you ran through it.

The forms

The contact form and the email box at the end of the guides are handled by Web3Forms, because this site is static files with no server of its own. Being straight about what that means: what you type does not go directly to me. It goes to Web3Forms first, which emails it to me and keeps a copy on its own servers (AWS, encrypted, up to three years, and they record the IP address the submission came from). I am the one responsible for that data and they process it on my behalf. Everything they hold is what you typed: your site address, your email address, your message.

The email box at the end of the guides is the one exception, because a mailing list needs a real unsubscribe link and a contact form cannot give you one. Those addresses go to Kit, which asks you to confirm by email before it adds you and puts an unsubscribe link at the bottom of everything it sends. It holds your address, which page you signed up from, and, if you signed up from a tool, the two things described above: which tool it was and the counts-only line. Nothing else.

On my side it sits in my inbox and nowhere else. There is no CRM, nothing gets sold or handed to anyone, and I do not run automated sequences at you. If you gave me your address for the occasional indexing write-up, that is the only thing it is used for, and one reply saying stop is enough. Ask me to delete anything you have sent and I will, on both sides, no reason needed.

If you would rather skip the middleman entirely, email mr.shahidali.sa@gmail.com or use WhatsApp. Both reach me directly and neither touches Web3Forms.

Questions about any of this: WhatsApp or mr.shahidali.sa@gmail.com. Last updated 16 August 2026.