Search Console 1000 Row Limit: How to Export All Your Data

We at Talha Aslan and team hear this question most often from growing online stores and large content sites. At some point, the queries you see in the report stop reflecting your real search footprint. Instead, they show only a thin slice of it. In this guide, we first explain exactly what the limit cuts off. Then we walk through each method step by step. Finally, we close with a table that matches each method to a type of site. We skip code blocks on purpose and focus on logic and setup order.

If you are new to the tool, start with our guide on what Google Search Console is and how to use it. This article assumes you already know your way around the report screens.

What exactly does the Search Console 1000 row limit restrict?

The Performance report shows a chart at the top and a table below it. The table has tabs for queries, pages, countries, devices, and more. It lists a maximum of 1,000 rows. So even if 40,000 different queries earned impressions for your site, the screen shows only part of them.

Google states this plainly in its help page on exporting data directly from a Search Console report. Exported data stops at 1,000 rows of representative examples of your data. The page also notes that small sites may get most or all of their data, while large sites usually get only a sample.

One detail matters a lot here. The cap affects the table, not the chart. Therefore, your total clicks and total impressions still show the real trend. However, any answer to "which query" or "which page" stops at 1,000 rows. Most of your long tail lives exactly in the part that disappears.

• Chart: reliable for overall trends.
• Table: up to 1,000 rows, ordered with the top performers first.
• Export: same cap as the table, in Google Sheets, Excel, or CSV format.

Why do totals in your export differ from the sum of the rows?

Almost everyone asks this the first time they open the file. You add up clicks across the 1,000 rows, yet the result never matches the total at the top. The reason is simple. The total includes the rows that the cap removed.

According to Google's help page, totals in the export are actual totals, without any row limit applied. On the other hand, the rows themselves only cover the visible part. As a result, comparing the two numbers gives you a rough idea of how much detail you are missing.

Example scenario: the export for example.com shows 10,000 total clicks. Yet the 1,000 rows add up to only 7,000. In other words, about a third of the clicks come from queries outside your table or from anonymized queries. This is an example calculation. Your own ratio depends on how your site earns traffic.

In addition, cells that show "~" or "-" in the report turn into zeros in the downloaded file. So do not read every zero in the file as a true zero. In the average position column especially, those zeros can drag your averages in the wrong direction.

Part of the missing share will never come back, whatever method you use. We explain why in our article on why Search Console queries are missing. We also touch on it briefly below.

Which sites actually hit the Search Console 1000 row limit?

A small business website often earns impressions for only a few hundred distinct queries per month. On a site like that, the table already shows nearly everything. That means not every site needs an extra setup.

The limit becomes a real problem in these cases:

• Online stores with thousands of product or category pages.
• Content and news sites with hundreds of published articles.
• Sites that publish in several languages or target several countries.
• Local service and directory sites that live on long-tail queries.
• Any site that wants to keep more than 16 months of history.

People often overlook the last point. The Performance report shows at most 16 months of data. So if you want to compare this season with the same season two years ago, you need to store the data outside Search Console, starting today. The problem, in short, covers both row counts and history that fades over time.

Example scenario: example.com runs a store with 3,000 products. Each product page earns only a few clicks. Brand and category queries fill the first 1,000 rows. Consequently, product-level opportunities never appear in the report at all. This is why we treat the limit as a strategic blind spot, not a cosmetic one.

How far can filters push you past the limit in the interface?

Before you set anything up, the first idea is usually to slice the report with filters. Each filter opens a fresh window of 1,000 rows. For example, you can filter for pages that start with /products/ first, then for pages under /blog/. That way, you get a separate set of 1,000 rows for each section.

These are the main dimensions you can slice by:

1. Date: pick weekly or daily ranges instead of a full month.
2. Page: use filters for URLs that contain or start with a given folder.
3. Country: download each target market on its own.
4. Device: separate desktop, mobile, and tablet.
5. Query: add a filter that excludes brand queries.

That said, this approach has clear limits. When you merge the slices, the same query can repeat across several files. Also, downloading each file by hand takes time and invites mistakes. For that reason, we use slicing for one-off reviews, never for regular reporting.

A regular expression (regex) filter makes the brand split much easier. We show how to set that up in our guide to brand vs non-brand queries in Search Console.

How does the Search Console API return more than 1,000 rows?

The Search Console API lets you query Performance report data with a program. In a Search Analytics query, the row limit parameter defaults to 1,000. However, Google's developer documentation says you can raise it to 25,000 rows per request.

To go further, you page through results with the startRow parameter. You request the first 25,000 rows, then the next 25,000, and so on. When a response comes back empty, you have reached the end of the data.

Still, the API has a ceiling too. Google's guide on getting all your data says the API exposes a maximum of 50,000 rows per day per search type. Those rows follow click order. So on very large sites, even the API does not give you everything. It does, however, open a much wider window than the interface.

The documentation also stresses that the API does not guarantee every row, only the top ones. Therefore, treat API data as your widest sample, not as a full list. Always check the current limits in the official documentation, because Google can change them.

Each search type also counts separately. You query web, image, video, and news data one at a time. As a result, image traffic never blends into your web numbers by accident.

How should you set up paging and daily queries in the API?

Google's recommendation is clear: run a query every day for one day's worth of data. This approach makes the best use of the daily row ceiling. It also keeps you inside your quota. For instance, instead of one request for a whole month, you run thirty single-day requests.

We suggest planning the flow in this order:

1. Decide which dimensions you need, such as date, query, page, country, and device.
2. Pick your search types, since each one needs its own query.
3. Set the date range to a single day.
4. Set the row limit to 25,000 and start at row zero.
5. While responses return rows, raise the start row by 25,000 and ask again.
6. When a response returns no rows, close that day and save the result to your own table.
7. The next day, repeat the process for the following date.

Timing matters as well. According to the documentation, data typically becomes available after two to three days. In addition, the API returns only final data by default. If you also want fresh data, you can set the dataState parameter to "all". Keep in mind that values for those recent days may still change.

That is why we recommend that your pipeline pull the last few days again later and overwrite them. That way, preliminary numbers never leave a permanent error in your reports. For more on data delays, see our article on the "processing data" message in Search Console.

How do API quotas and "expensive queries" affect you?

The Search Console API costs nothing, but it has limits. Google applies request limits per site, per user, and per project. There are also short-term and long-term load limits. We recommend checking the current values on the official usage limits page.

The concept that matters most is the "expensive query." According to Google's documentation, queries become expensive when you group or filter by page or by query string. Grouping by both page and query is the most expensive combination. Moreover, load increases with the date range you request.

The documentation adds that for these queries, the system may drop some data to keep calculations manageable. In practice, a table that pairs page and query can show lower totals than your site-wide total. This is known behavior, not a bug.

In practice, you can strike this balance:

• Use light dimensions such as date and device for overall trends.
• Pull your query list in a separate request without the page dimension.
• Pair page and query only for analyses that truly need it.

A keyword cannibalization review, for example, requires the page and query pairing. We cover the logic behind it in our guide on what keyword cannibalization is and how to fix it.

How can you reach full Search Console data without writing code?

Not every business has a developer, and that is perfectly normal. You can still move past 1,000 rows without using the API directly. There are two common routes.

The first route is third-party add-ons for Google Sheets. These add-ons use the same API in the background and write the result straight into a sheet. However, each add-on asks for different permissions. So read carefully which data it wants to access before you install it. We do not recommend a specific add-on. Pick one with a known developer and clear permissions.

The second route is Google's own Looker Studio connector. It needs no add-on at all. It also presents the data visually inside a dashboard. We cover this connector in detail in the next section.

On the other hand, these no-code routes share a limit. They all depend on the API ceiling in the end. That means the daily row ceiling and the loss of anonymized queries apply here as well. Thinking "I installed an add-on, so now I see everything" is therefore misleading.

In short, no-code routes usually work well for small and mid-sized sites. As your data volume grows, though, it makes sense to consider the bulk export.

Does the Looker Studio connector get around the Search Console 1000 row limit?

Yes, it does. The Search Console connector in Looker Studio pulls data through the API. Because of that, your tables can show far more than 1,000 rows. According to a Google Search Central blog explanation, the connector shares the API ceiling of 50,000 rows per day per site per search type.

To connect, follow the order in the official documentation:

1. Sign in to Looker Studio with the same Google account you use for Search Console.
2. Create a new data source and select the Search Console connector.
3. Authorize access if Looker Studio prompts you.
4. Select your property.
5. Choose a table type: Site Impression or URL Impression.
6. Pick a search type and connect.

According to Google's Looker Studio documentation on connecting to Search Console, you need at least view permission on the property. The page also explains that, for privacy, some rare queries can collapse into one row with a blank value. You can remove that row with a filter that excludes null values in the Query field.

The connector has another advantage: sharing. A report that uses the owner's credentials lets other people view it without their own Search Console access. Still, think about who receives the link, because everyone who sees the report also sees your query data.

What is the difference between Site Impression and URL Impression?

These two options reflect the two ways Search Console aggregates performance data. Site Impression aggregates at the property level. URL Impression aggregates at the page level. This difference changes your numbers directly.

With property-level aggregation, two of your pages in the same result still count as one impression. With page-level aggregation, each page earns its own impression. Consequently, impression totals in the URL Impression table usually run higher. Average position also differs between the two tables.

A single data source can use only one method. So if you want both side by side, you create two data sources and add both to one report. For example, the top of the report can show the overall trend with Site Impression, while the bottom covers page analysis with URL Impression.

Your property type also shapes the numbers. We compare the two options in our article on domain vs URL prefix properties.

What is the Search Console bulk data export to BigQuery?

The bulk data export sends your Search Console performance data to Google BigQuery automatically, once a day. BigQuery is the Google Cloud data warehouse built for querying very large tables. This method is the most complete data path Search Console offers.

According to Google's help page, the export gives you all the performance data available to Search Console for your property, with the exception of anonymized queries. In other words, the API's daily row ceiling does not apply here. Nearly all of your long-tail queries land in your tables.

That said, the method comes with three important traits:

• It does not backfill. The export starts from the day you set it up.
• It requires a Google Cloud project with billing enabled.
• Reading the data requires SQL skills or a reporting tool that connects to BigQuery.

The first point matters most. If you do not set it up today, today's data will never exist in BigQuery. For the period before setup, you have to rely on the API or the reports. For that reason, if you manage a large site, we advise you not to postpone the setup.

On the plus side, you set it up once, and then it runs on its own every day. It also removes the 16-month history limit for you, since you keep the data as long as you want.

How do you set up the BigQuery bulk export step by step?

Setup happens in two places: first Google Cloud, then Search Console. Here is the order from Google's page on starting a new bulk data export, in summary form:

1. Prepare a Google Cloud project with billing enabled and BigQuery turned on.
2. Note the project ID, not the project number.
3. In the APIs and services area, check that the BigQuery API and the BigQuery Storage API are active.
4. In IAM, add search-console-data-export@system.gserviceaccount.com as a principal.
5. Give that account the BigQuery Job User and BigQuery Data Editor roles.
6. In Search Console, open the bulk data export option in your property's Settings.
7. Enter the project ID, a dataset name, and a dataset location.
8. Confirm and continue.

The dataset name defaults to searchconsole and must start with that string. Pay special attention to the location. The help page warns that changing it after exports begin is difficult.

According to Google, the first export happens up to 48 hours after a successful setup. Empty tables during that window are normal. Also, never change the table schema. The help page says that doing so makes exports fail.

Which BigQuery tables does the export create, and how should you read them?

The export creates three tables in your dataset. Google's table guidelines and reference page describes them like this:

• searchdata_site_impression: performance data aggregated by property.
• searchdata_url_impression: performance data aggregated by URL.
• ExportLog: a record of each successful export. Failed attempts do not appear here.

As you can see, the first two tables follow the same logic as Site Impression and URL Impression in Looker Studio. So you use the site table for trends and the URL table for page analysis.

Keep three rules in mind when you read them. First, the date field (data_date) follows Pacific Time. Second, rows with the same keys can repeat, because Search Console accumulates data incrementally. That is why you should almost always aggregate your metrics in your queries.

Third, average position needs care. The tables have no ready-made average position column. Instead, they store a zero-based sum of positions. You calculate average position by dividing that sum by total impressions and then adding one. If you skip that step, every position you report looks one place better than reality.

Also, check the ExportLog table regularly. If a day is missing, that day's export most likely failed. This helps you tell a real traffic drop from a simple data gap.

How do you keep BigQuery costs under control?

BigQuery includes a free usage tier. Storage and queries above that tier show up on your Google Cloud bill. Check the current free tier and prices on the official Google Cloud pricing page, since those values can change.

Two things drive costs up: growing storage and careless queries. By default, the bulk export keeps data indefinitely. So storage grows over the long run. However, the bigger cost often comes from needlessly broad queries.

To keep costs in check, we suggest these steps:

1. Set an expiration on partitions instead of on the table.
2. Always include a date range filter in your queries.
3. Select only the columns you need.
4. Create a budget alert in Google Cloud.
5. Connect dashboards to summary tables instead of raw tables.

The first step is critical. According to Google's table guide, a table-level expiration deletes all your data. A partition-level expiration, by contrast, only clears old days. The setup page also recommends a partition expiration of at least 14 days.

Example scenario: example.com only analyzes the last 12 months. In that case, a 12-month partition expiration keeps storage in check. On the other hand, if you run multi-year seasonal comparisons, skip the expiration and focus on query discipline instead.

Which method fits which kind of site?

We compared all the methods in one table. Read each row against your site size and your team's technical capacity.

The ceilings in the table come from official documentation, yet Google can change them. Therefore, confirm the current values on the relevant help page before you build anything.

In practice, these methods do not exclude each other. For many projects, the most efficient setup is to turn on the BigQuery export right away and fill the earlier period with the API. That way, you end up with one dataset that covers both past and future.

Why do anonymized queries stay missing whatever method you use?

No export method brings anonymized queries back. To protect user privacy, Google does not show queries that very few people make. This holds for the interface, the API, Looker Studio, and BigQuery alike.

In BigQuery, those rows stay in the table, but the query text stays empty. According to the table guide, the anonymized query flag reads true for those rows and the query field holds no value. In other words, you can see that this traffic exists and how large it is. You simply cannot see which words it came from.

This affects your analysis in two ways. First, query-level totals always fall short of the site total. Second, the gap grows larger on sites that rely on the long tail. So the idea that "bulk export means complete data" is also wrong.

What can you do, then? Track the anonymized share as its own line. If that share grows quickly over time, your site earns traffic from many scattered, low-volume queries. That fact alone is a meaningful signal for your content strategy.

Discover data has a similar anonymization flag. When it reads true, fields such as URL and country can be missing. For that reason, treat Discover totals with care as well.

Which SEO analyses become possible with full data?

The goal of moving past 1,000 rows is not a bigger file. The goal is better decisions. With full data, you can run analyses that the interface simply cannot support.

• Long-tail opportunity analysis: find high-impression, low-click queries page by page.
• Cannibalization checks: spot pages that compete with each other for the same query.
• Content decay tracking: catch articles that slowly lose traffic over many months.
• Category and folder performance: measure growth section by section based on URL structure.
• Multi-year seasonal comparison: see trends that reach beyond the 16-month window.
• Country and device breakdowns: separate real demand in each target market.

Content decay analysis, for example, requires months of page-level data. We cover the steps in our guide on what content decay is and how to detect it in Search Console. For a quick first look, Search Console's newer summary view also helps; we review it in what Search Console Insights is.

In short, full data does not hand you answers. Instead, it helps you ask the right questions. That is why the person running the analysis still needs to understand your site, your market, and your goals.

What are the most common mistakes when exporting Search Console data?

The mistakes we see most in the field are not technical. They are mistakes of interpretation. Even accurate data leads to bad decisions when you read it the wrong way.

1. Treating the exported 1,000 rows as the whole site.
2. Mixing Site Impression and URL Impression numbers in one table.
3. Reading repeated BigQuery rows without aggregating them.
4. Forgetting to add one when you calculate average position.
5. Setting a table expiration and losing every row of data.
6. Reporting preliminary recent days as final numbers.
7. Putting off the bulk export with "we will turn it on later".

The last mistake costs the most, because there is no way back. The bulk export does not backfill, so every postponed day disappears for good. Even so, you can still recover the last 16 months with the API. Arriving late, therefore, does not leave you without options.

Access control is another frequent issue. A Looker Studio report that runs on owner credentials and goes out through a public link can expose your query data to the wrong people. So review your sharing settings on a regular basis.

Who sets this up on your site and keeps track of the results?

The technical setup may look like a few hours of work. However, the real value comes from reading the data correctly every month and turning it into action. We handle this process end to end as part of our SEO consulting service.

We usually start by measuring how much data your site actually needs. Then we choose the right method and, where it makes sense, set up the BigQuery export along with a historical backfill. After that, we turn the data into a regular report and a prioritized task list. For example, that list tells us which pages to update and which queries call for new content.

Let us be clear about one thing: no data setup guarantees rankings. Good data makes good decisions easier. Results, however, depend on content, technical health, and competition together. So instead of bold promises, we offer you a measurable work plan.

If your Search Console data feels too thin for the decisions you need to make, you can request a quote through our SEO consulting page. In the quote, we spell out which method suits your site and what the scope includes.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.