The Short Answer
Both Google and Bing let you read your search data with code, so you can pull queries, pages, clicks and impressions for every site you own into one place instead of clicking through dashboards. For Google you create a service account, enable the Search Console API, and add the service account to each property as a restricted user, which is enough to read performance data. For Bing you generate an API key inside Bing Webmaster Tools, and that one key reaches every site verified in your account. Google's data runs about three days behind and goes back about sixteen months. Bing's query data comes back in weekly rows covering about six months.
The one sentence version
Give your scripts read only access, keep the keys out of every repository and every log, and pull all your sites in one pass so you can see patterns no single dashboard shows.
Why Bother With the API
The dashboards are fine for one site and one question. They break down when you have many sites, when you want the same report every week, or when you want to ask something the interface was never built to answer. We built a small read only tool for our own portfolio for exactly that reason, and the first thing it did was answer a question no dashboard could: across all of our sites at once, how do short and long searches behave?
In one pass over six months of Bing data for 41 sites, about 695,000 impressions, we found that queries of ten words or more were under 1% of impressions but were clicked five to seven times as often as queries of one to three words, and that a small group of them were plainly written by machines, with instructions about output formats and dates in the middle of a phrase. That kind of finding needs every site in one table. The same pass showed that queries asking for something to be computed, such as how much something is worth or a calculator, were clicked 3.47% of the time, against 0.66% for queries asking for an explanation. It is the same reason we recommend pulling data yourself for tracking AI citations.
| What you want | Dashboard | API |
|---|---|---|
| One site, one question, today | Fastest | Overkill |
| The same report every week | Manual and easy to skip | A script on a schedule |
| Every site you own in one table | One property at a time | One loop |
| More than the interface shows | Limited to the built in views | Up to 25,000 rows per request from Google, with paging |
| Combining with your own logs | Not possible | Join on page and date |
Google: Set Up Read Only Access
Create a project and a service account
In Google Cloud, create a project, enable the Search Console API, and create a service account. Download its key file once and store it somewhere private.
Add the service account to Search Console
In each property, add the service account email as a user. Restricted permission is enough to read performance data.
Request the read only scope
Ask for webmasters.readonly when your script authenticates, so even a stolen token cannot change anything.
List the properties it can see
A service account only sees properties it has been added to. If a site is missing, it was never added, not broken.
Run one small query first
Ask for one week, one dimension and ten rows, and compare the totals with the dashboard before building anything bigger.
The part that surprises people is step four. A Google service account is not you. It does not inherit your access to every property, so each site has to be added by hand, by someone who owns it. That is a feature: you decide exactly which sites a script can read.
Google: What the Query Returns
The workhorse is the search analytics query. You send a date range, the dimensions you want to group by, and optional filters, and you get rows of clicks, impressions, click through rate and average position.
| Field | What it does | Worth knowing |
|---|---|---|
| startDate and endDate | The date range, in Pacific time | Required on every request |
| dimensions | Group by query, page, country, device, date, hour or search appearance | More dimensions means fewer impressions per row |
| type | Web by default, or image, video, news, Discover or Google News | Each type is a separate query |
| rowLimit and startRow | Up to 25,000 rows per request, default 1,000 | Page with startRow until a request returns fewer rows than you asked for |
| dataState | Final data by default, or all to include fresh incomplete rows | Recent days can change after you read them |
| aggregationType | Group by property or by page | Totals by page and by property do not always match |
Two habits save a lot of confusion. Read the last three days as provisional, because the API itself warns that recent rows may be incomplete. And never compare a total you built from query rows with the total in the dashboard: privacy filtering drops rare queries from query level data, so the rows will always add up to less than the whole.
AI answers are a separate story
Search Console gained separate reports for AI Overviews and AI Mode in 2026, showing impressions. The documented search types in the query API are web, image, video, news, Discover and Google News, so check what your account exposes before you build a report around AI data.
Bing: Set Up the API Key
Open the settings in Bing Webmaster Tools
Find the API access section and generate a key. One key is tied to your account, not to a single site.
Store it like a password
The key reaches every site verified in your account. Keep it in a private file or a secret store, never in code.
List your sites first
The GetUserSites method returns every site the key can see and whether each is verified.
Use read methods only
The same key can submit URLs and change settings. Write your tool so it only calls methods that read.
The breadth of a Bing key is the opposite of Google's service account. Ours saw all 42 sites verified in the account the moment it was created. That makes Bing the faster way to get a whole portfolio into one table, and it is also why the key deserves more care than any other credential in your SEO tooling.
Bing: What the Data Looks Like
The method most people want is GetQueryStats, which returns the queries that showed a site, with impressions, clicks and average positions. It takes the site address and nothing else: there are no date parameters. You receive what Bing keeps, about six months, in weekly rows.
| Method | Returns | Use it for |
|---|---|---|
| GetUserSites | Every site in the account and its verification state | Building the list to loop over |
| GetQueryStats | Queries with impressions, clicks and positions, in weekly rows | Query research across many sites |
| GetPageStats | Pages with impressions and clicks | Finding the pages that earn the traffic |
| GetRankAndTrafficStats | Daily totals for the site | Spotting a sudden drop on one day |
Because the rows are weekly, sum them per query before you analyse anything, or one query will appear many times with small numbers. The daily totals method is the one to watch for the pattern in our guide to sites that are indexed but not served by Bing, where impressions fall to zero on a single day.
Google and Bing Side by Side
| Google Search Console API | Bing Webmaster API | |
|---|---|---|
| How you get access | A service account with a private key file | One API key from inside the dashboard |
| What one credential can see | Only properties it was added to | Every site verified in the account |
| How far back | About 16 months | About 6 months |
| How fresh | About three days behind, newest rows provisional | Weekly rows |
| Shape of the data | Rows by the dimensions you choose, up to 25,000 per request | Everything Bing keeps, returned in one response |
| Biggest risk | Adding the account to the wrong property | A key that can also write, reaching every site |
The practical consequence is that the two complement each other rather than compete. Google gives you depth and history for the sites you choose to connect, with dimensions you can slice however you like. Bing gives you breadth immediately, every site at once, with less control over the shape. For a portfolio, we start with Bing to see the whole picture, then use Google to go deep on the sites that matter. Bing also matters more than its market share suggests, because the same index feeds Copilot and is a documented source for ChatGPT search.
Keep the Keys Safe
Read only by design
Request the read only scope from Google and call only read methods on Bing, so a mistake or a leak cannot change your sites.
Never print a key
Scripts should read keys from a file and never echo them, log them or include them in error messages.
Watch for invisible characters
A key pasted through some editors gains a byte order mark at the start. We once lost two services at once to three invisible bytes. Strip them when reading the key.
Keep key files out of repositories
Put them in a folder that is excluded from version control and backed up separately.
A Weekly Report Worth Automating
Once access works, the most useful thing to automate is a short weekly table that a dashboard will never give you on its own.
Pull every site
Loop over the properties and the Bing site list, and store the raw rows with the date you pulled them.
Compare with last week
For each site, total impressions and clicks, and flag any site that fell by more than half.
Flag zero days
A normally active site with a day of zero Bing impressions deserves a look the same morning.
List new queries
Queries that appeared for the first time show what people and assistants have started asking.
Join with your logs
Put live AI agent fetches next to search impressions per page, so you can see which pages are found and which are actually used.
The last step is where the API pays for itself. Search data tells you what was shown. Your server log tells you what assistants fetched. Together they show which pages are visible and which are quoted, which is the gap our guide on why a site is not showing in ChatGPT is about. It also makes refreshing the Google algorithm update timeline against your own traffic far easier, because a drop and an update can be lined up by date.
Common Mistakes
Reading fresh data as final
The last few days of Google data can still change. Mark them provisional in every report.
Expecting rows to add up to the total
Rare queries are filtered from query level data, so the sum of rows is always lower than the dashboard total.
Not summing Bing weeks
Each query comes back once per week. Sum before ranking, or the top of your list is wrong.
Giving the script write access
There is almost never a reason for a reporting script to be able to change anything.
The Bottom Line
Reading search data through the API takes an afternoon to set up and pays back every week after. Use a Google service account with read only access, added to each property on purpose, and a Bing key stored like a password and used only to read. Pull every site into one table, treat the newest Google days as provisional, sum Bing's weekly rows, and join the result with your server log. The patterns that matter most, like which questions are clicked and which are only answered, only appear when everything sits side by side.