Your data. Your control.
KeywordHistory reads your Google Search Console data so you can track it over time. This page explains exactly what we can access, where your data lives, and what we can and cannot do with it, in plain English.
GSC access
Read-only
We cannot change your Search Console settings or data
Your data
Stays in BigQuery
In your Google Cloud account or our isolated store
We cannot
Delete anything
No delete or modify operations on your search data
What Google permissions we ask for
We use Google Sign-In and ask for the minimum permissions needed at each stage.
At sign-up
We only ask for your name, email address, and profile picture. This is the same information any Google Sign-In uses. We do not request access to Search Console or Google Cloud at this point.
During setup
Once you connect a site, we ask for one additional permission:
- ✓Search Console (read-only) — this uses the
webmasters.readonlyscope, which is enforced by Google and means we literally cannot modify anything in Search Console. It lets us fetch your impression, click, and ranking data. - ✓If you choose the Guided plan, you create your own Google Cloud project and BigQuery dataset and grant our service account access via IAM — we walk you through each step. We never receive broad Google Cloud access on your behalf.
You can revoke our access at any time from your Google account permissions page.
What we can and cannot do
Here is the complete picture of our capabilities, determined by the permissions Google grants us:
We can
- ✓Read your GSC search analytics data (impressions, clicks, CTR, position)
- ✓Copy that data into BigQuery so it is preserved beyond Google's 16-month limit
- ✓Query BigQuery to show you charts and insights inside the app
We cannot
- ✕Modify, delete, or reset your Search Console data
- ✕Change your GSC property settings or ownership
- ✕Delete or drop your BigQuery tables or datasets
- ✕Access any Google property you have not explicitly connected
- ✕Read your Google Analytics, Gmail, Drive, or any other Google product
Where your search data lives
The answer depends on which plan you choose. All three options use BigQuery. They differ in whose Google Cloud account it sits in.
Expert — your GCP project, your dataset
You provide your own Google Cloud project and BigQuery dataset IDs.
- ✓Data is stored in your own Google Cloud account
- ✓You have full direct access — query it, export it, delete it yourself
- ✓If you stop using KeywordHistory, your data stays exactly where it is
- ✓We access your dataset only to append new rows and run read queries for the app
Guided — your GCP project, you create it
We walk you through creating your own Google Cloud project and BigQuery dataset, then you grant our service account access via IAM.
- ✓Data is stored in your own Google Cloud account
- ✓You have full direct access — the GCP project belongs to you
- ✓If you stop using KeywordHistory, your data stays in your GCP project
- ✓We never request broad Google Cloud access — only read-only Search Console
Managed — our infrastructure, isolated per account
We handle everything. Your data lives in our Google Cloud project.
- ✓Your data is stored in a dedicated BigQuery dataset named after your account, kept isolated from all other customers
- ✓No other KeywordHistory customer can access your dataset
- ✓Daily sync runs automatically, with no manual action needed
- ✓We can provide a data export on request if you want to leave
Regardless of plan, your raw GSC data is never stored in our application database. Only your account settings, site configuration, and preferences are stored there.
Your data is never aggregated or benchmarked
The Google API Services User Data Policy prohibits us from using data obtained via Google's APIs for any purpose beyond providing the features you see in the app. That means we are not permitted to:
- ✕Use your Search Console data to build cross-site benchmarks or industry comparisons
- ✕Combine your data with other customers' data to derive anonymised insights
- ✕Sell, transfer, or share your data with any third party for their benefit
- ✕Use your data to train machine learning models or improve any product outside of KeywordHistory
Your keyword data belongs to your site alone. It is used only to power the dashboards and reports you see when you are logged in.
What we store in our own database
Our application database (hosted on Turso, a managed SQLite service) holds only the metadata needed to run the app:
- ✓Your name, email address, and profile picture (from Google Sign-In)
- ✓The Google Search Console property URLs you have connected
- ✓Your plan, subscription status, and billing reference
- ✓App settings: keyword filters, brand terms, annotations, team members
- ✓Encrypted OAuth refresh tokens, so we can sync data on your behalf without you needing to be logged in
Not stored here: your actual search queries, impressions, clicks, ranking positions, or any GSC analytics data. All of that lives in BigQuery.
How we handle your Google tokens
When you grant us access to Search Console, Google issues us an access token and a refresh token. Here is how we treat them:
- ✓Tokens are stored encrypted in our database, never in plain text
- ✓Access tokens expire after one hour and are refreshed automatically in the background
- ✓Tokens are scoped per site, so connecting a second site does not expand what we can see for the first
- ✓We only use tokens when syncing your data or serving an insight you requested
- ✕We do not sell, share, or transfer your tokens to any third party
You can disconnect any site from inside the app at any time. This removes our stored credentials for that site immediately.
How we protect access to our own systems
Preventing unauthorised access starts with how our own infrastructure is secured. Here is what is in place.
No passwords on any infrastructure
Our hosting, database, and code repository all use Google OAuth to authenticate.
- ✓GitHub (source code), Vercel (hosting), and Turso (database) are all accessed via Google Sign-In — no passwords exist on any of them
- ✓There is no password database to steal, phish, or brute-force. The entire attack surface for accessing our infrastructure reduces to a single Google account
- ✓That Google account is protected by two-factor authentication. Any unrecognised sign-in attempt sends a push notification to the account owner's phone and requires manual approval before access is granted
Secrets are never in the codebase
API keys, database credentials, and service tokens are stored as encrypted environment variables in Vercel.
- ✓No credentials are committed to version control at any point
- ✓Vercel injects secrets at build and runtime only — they are not readable by anyone browsing the repository
- ✓Rotating a secret requires only updating the environment variable in Vercel, not a code change or deployment
No exposed database port
The database is a managed cloud service, not a server we run ourselves.
- ✓Turso is a managed SQLite service with no publicly accessible SQL port — it cannot be reached by IP scanning or credential stuffing tools
- ✓Database connections require an authenticated token, not a username and password
Deployments are controlled through GitHub
Code only reaches production through a verified GitHub push.
- ✓Vercel deploys are triggered exclusively by commits to the GitHub repository — there is no other route to push code to production
- ✓An attacker cannot deploy arbitrary code to our servers without first compromising the GitHub account, which itself requires the Google account and its 2FA approval
What would happen if KeywordHistory were breached
This is the right question to ask. Here is an honest assessment by plan.
Expert or Guided users
Your search data lives in your own Google Cloud account. An attacker who broke into KeywordHistory's servers would find encrypted API tokens in our database but would not find your GSC data, because it was never copied to our systems.
It is important to understand what a stolen API token can and cannot do. It cannot be used to log in to your Google account, access the Google Cloud Console, or sign in to BigQuery as you. It is an API-only credential tied to a specific set of permissions. In this case, that permission is webmasters.readonly, which means the token could only be used to read the same Search Console data that is already visible inside Google's own Search Console interface. It could not modify, delete, or export anything.
Managed users
Your BigQuery dataset is on our infrastructure, so a breach of our Google Cloud environment could expose your stored search data. We mitigate this through IAM access controls, per-tenant dataset isolation, and service account key management.
A stolen token still cannot be used to log in to your Google account or access the Google Cloud Console. It is not a password. And regardless of how a token is obtained, the webmasters.readonly scope enforced by Google means your live Search Console data cannot be modified.
Account and access controls
- ✓Sign-in is handled via Google OAuth. We never store or handle your Google password
- ✓Team members can be invited to access specific sites and they see only the sites you grant them
- ✓All app traffic is served over HTTPS (TLS 1.2+)
- ✓Session tokens are stored in HTTP-only cookies scoped to keywordhistory.com
- ✓Admin access to our systems is restricted to KeywordHistory staff by service account
Your rights and how to exercise them
You can request a copy, correction, or deletion of your personal data at any time. For Expert and Guided users, your search data is under your own Google Cloud account and you control it directly. For Managed users, contact us and we will export or delete your BigQuery dataset.
To disconnect a site or delete your account entirely, use the settings inside the app or email us at privacy@keywordhistory.com.
Full details of your rights under UK GDPR are in our Privacy Policy. Our service terms are in the Terms of Service.
Have a security question that is not answered here? Get in touch. We aim to respond within one business day.
Last updated: 21 May 2026