GSC's web UI is fine for occasional spelunking. It's slow for daily ops. Three pages of clicks to get to the same five queries I run every morning. The export is CSV. The date range picker is finicky.
So I built a Node script. About 150 lines. Three flags. Pulls everything I look at daily into the terminal in four seconds.
Here's what it does, what it doesn't do, and what I learned about the GSC API along the way.
What I check every morning
Five things, in order:
- Total clicks last 7 days vs prior 7 days
- Top 25 queries by clicks
- Top 25 pages by clicks
- Pages with the biggest position gain (rising stars)
- Pages with the biggest position loss (warning signs)
In GSC's web UI, that's five-plus clicks and a date range adjustment per check. In a terminal, it's node gsc-query.js --all and four seconds.
One-time setup
You need OAuth. The GSC API requires a refresh token, which you get by going through a one-time auth flow.
I wrote a separate script for this (gsc-auth.js) that handles the dance:
const { google } = require('googleapis');
const open = require('open');
const http = require('http');
const url = require('url');
const oauth2Client = new google.auth.OAuth2(
process.env.GSC_CLIENT_ID,
process.env.GSC_CLIENT_SECRET,
'http://localhost:3737/oauth-callback'
);
const authUrl = oauth2Client.generateAuthUrl({
access_type: 'offline',
scope: ['https://www.googleapis.com/auth/webmasters.readonly'],
});
console.log('Opening browser for authentication...');
open(authUrl);
http.createServer(async (req, res) => {
const code = url.parse(req.url, true).query.code;
if (code) {
const { tokens } = await oauth2Client.getToken(code);
console.log('Add this to your .env:');
console.log('GSC_REFRESH_TOKEN=' + tokens.refresh_token);
res.end('Auth complete. You can close this tab.');
}
}).listen(3737);
You run it once, click through the consent screen, and it prints your refresh token to the terminal. Save that to .env and you never run this script again.
A note on the OAuth flow: you'll need to set up an OAuth consent screen and a Web Application credential in the Google Cloud Console first. Add http://localhost:3737/oauth-callback as an authorized redirect URI. The whole setup takes about 10 minutes if you've never done it before, and it's the most annoying part of the project.
The "domain property vs URL prefix" gotcha
This one cost me 30 minutes when I was setting up. Sharing it so it costs you zero.
GSC has two ways to verify a property:
-
URL prefix (e.g.,
https://www.gas-price-check.com/): covers exactly that protocol + subdomain combo -
Domain property (e.g.,
gas-price-check.com): covers all subdomains and protocols
The API treats these as different objects. To call data for a domain property, you use the format sc-domain:gas-price-check.com. Without the prefix, the API returns "site not found" with no hint about the format issue.
const siteUrl = 'sc-domain:gas-price-check.com'; // domain property
// not 'https://www.gas-price-check.com'
// not 'gas-price-check.com'
const res = await searchconsole.searchanalytics.query({
siteUrl,
requestBody: {
startDate: '2026-04-22',
endDate: '2026-04-29',
dimensions: ['query'],
rowLimit: 25,
},
});
If you set up your GSC property as a URL prefix, use the URL with the protocol. If you set up as a domain property, use the sc-domain: prefix. The error message gives you no hint about which format the API expects, so just remember the rule.
The query script
The actual gsc-query.js is straightforward. The interesting part is the flag handling:
const args = process.argv.slice(2);
const days = parseInt(args[args.indexOf('--days') + 1] || '7');
const showQueries = args.includes('--queries') || args.includes('--all');
const showPages = args.includes('--pages') || args.includes('--all');
const showRising = args.includes('--rising') || args.includes('--all');
The actual API call is shaped like this:
async function fetchData(dimensions, days = 7) {
const endDate = new Date();
const startDate = new Date(endDate);
startDate.setDate(startDate.getDate() - days);
const res = await searchconsole.searchanalytics.query({
siteUrl: process.env.GSC_SITE_URL,
requestBody: {
startDate: startDate.toISOString().split('T')[0],
endDate: endDate.toISOString().split('T')[0],
dimensions,
rowLimit: 25,
},
});
return res.data.rows || [];
}
To get top queries: dimensions: ['query']. Top pages: dimensions: ['page']. To compute position changes over time: query twice with different date ranges and diff the results.
The five queries I run every morning
node gsc-query.js --days 7 # summary
node gsc-query.js --queries --days 28 # top queries last month
node gsc-query.js --pages --days 7 # top pages last week
node gsc-query.js --rising # biggest position gains
node gsc-query.js --falling # biggest position losses
Output looks like:
Top 25 queries (last 28 days):
cheap gas near me 142 clicks 3,201 impr 4.4% CTR pos 8.2
gas prices houston 87 clicks 1,892 impr 4.6% CTR pos 6.1
77386 gas prices 61 clicks 520 impr 11.7% CTR pos 2.8
cheapest gas in austin 52 clicks 1,104 impr 4.7% CTR pos 9.4
...
Whole thing returns in four seconds. I run it while my coffee is brewing.
A few things I learned about the API
The free quota is generous. GSC API gives you 1,200 queries per minute and 30,000 per day. For a personal dashboard you'll never hit it.
The API returns the same data as the UI, but with no rounding. The web UI rounds clicks to the nearest digit and aggregates queries below 10 impressions into "..." rows. The API gives you actual numbers, including the long tail of queries with 1-3 impressions. For finding "rising star" queries, that long tail is gold. A query with 4 impressions today that had 0 impressions last week is a signal the web UI hides from you.
Rate limiting is per project, not per user. If you have multiple scripts hitting GSC, run them all from the same OAuth project to share the budget cleanly.
Caching helps a lot. I cache yesterday's data in a local JSON file and only re-fetch today's data on the second run of the day. Cuts run time roughly in half.
The searchAppearance dimension is underrated. Filter by searchAppearance: 'AMP_TOP_STORIES' or 'WEBLITE' to see how each rich-result type is performing separately. Most people never look at this.
What I haven't bothered to add
The script is about 150 lines. I've thought about adding:
- A diff mode that flags queries that moved more than 5 positions week-over-week
- An export-to-CSV flag for when I want to load data into a spreadsheet
- A "branded queries only" filter
- A daily Slack notifier so I don't have to run the script at all
Each is a 30-line addition. The fact that I haven't bothered is a sign the script does enough already. Premature feature creep is a real risk on personal tools.
What's the point
For a side project, GSC's web UI is fine. For a project where you check the same data daily, building a 150-line wrapper script will save you hours per month and surface signals the web UI hides. The whole thing took me about three hours to build, including the OAuth dance. It's paid that back in saved clicks within a week.
If you've built a similar GSC daily dashboard, what flags do you reach for? I'm curious what other people's morning checks look like. Mine is pretty narrow, but it's stable, and I've stopped opening the GSC web UI for daily ops entirely. Once a week I check the URL Inspection tool for specific pages in trouble. The rest is the script.
