Bulk export is running, new rows arrive, and the dashboard shows a decline from the previous month. Before treating that as an SEO finding, check whether the selected periods contain comparable data days. A successfully configured export does not establish a complete archive.
When taking over a BigQuery report, reconstruct its delivery history first. When was export configured? Which dates and tables have successful delivery records? Which data are still present today? These are separate questions. An absent row should not silently become a measured zero-click result.
Google Search Console remains the source of the search-performance data. This guide concerns their ongoing delivery into BigQuery. Its timeline is entirely fictional; no real property or Cloud dataset was queried.
Setup does not initiate a historical backfill
Google's setup instructions describe the first export occurring up to 48 hours after successful configuration. According to that documentation, the first export contains data for the day of the export. Earlier history is not automatically backfilled into the same tables.
For older periods, Google points to Search Console reports or its API. Treat any such supplemental extraction as a separate source with its own limits. A Performance report CSV does not become bulk-export data simply because it is stored in the same Cloud project.
Record three dates: successful configuration, first observed export completion and earliest data_date still present. Each answers a different question. The first establishes when the request began, the second records an observed delivery, and the third describes the current retained inventory.
A property can have a longer history in Search Console reports than in BigQuery. If the warehouse has no rows for that earlier period, their absence does not establish a visibility loss during those months.
Two performance tables need separate delivery checks
The table reference distinguishes searchdata_site_impression, aggregated by property, from searchdata_url_impression, aggregated by URL. ExportLog records successful exports. The two performance tables are normally delivered separately and not necessarily at the same time of day.
Checking whether a new date appears anywhere in the dataset is therefore insufficient. Look for the date in the table that the report actually uses. A property-level report may be further ahead than the individual-URL analysis.
The tables are not two additive parts of a single metric either. Do not add their impressions together as total visibility. Record the source table and aggregation for every report so its delivery requirements remain explicit.
Also record the property, Cloud project, dataset and location. The default name searchconsole is not necessarily the actual dataset name chosen during setup. Particularly in an inherited project, a familiar-looking table does not prove that you have selected the intended inventory.
A fictional delivery timeline
Suppose a team configures export on May 1. Every event and record below is invented. The example demonstrates how to distinguish delivery state from data inventory; it does not describe an observed export.
| Point in the example | Recorded state | Supported conclusion |
|---|---|---|
| May 1 | Successful configuration documented | Ongoing export is configured |
| May 3 | First successful records in both tables for May 3 data_date | These deliveries are recorded; April is not established by them |
| May 6 | An expected URL-table record is absent for a data day and an access problem is visible | That day's URL analysis needs investigation |
| May 9 | Access problem corrected | The technical prerequisite is repaired; recovery still needs checking |
| May 10 | The fictional log now contains the missing date for the URL table | That particular recovery is recorded; other dates require separate checks |
A generic “export successful again” message on May 10 would not establish the final conclusion. The evidence needs the relevant data date and destination table. This mapping prevents one new success from concealing older holes in the report.
For SEO metrics, a delivered zero value and an unverified day are different states. The chart can show a missing day as a gap. Quietly filling it with zero would create an artificial decline.
What ExportLog records and what it leaves out
Its fields serve different purposes. namespace identifies the destination table, data_date identifies the data day, and publish_time records completion. epoch_version starts at zero and increases when that table's data for the date are corrected later. agenda describes the data type, currently SEARCHDATA.
A success record establishes delivery. It does not establish that the date remains stored today, every desired dimension has a value, or a downstream report calculates correctly. Each of those claims needs additional evidence.
Failed exports are not recorded in ExportLog. The monitoring documentation also explains that Search Console displays only the most recent export attempt. An empty place in the log therefore contains neither a complete failure cause nor the history of every attempt.
When a problem is visible, preserve the message, observation time and affected data dates. This lets a later review connect a gap with a documented access problem. An absent entry alone cannot identify that particular cause.
Inspect a bounded period before scanning everything
The GoogleSQL example below reads the delivery history for a short period. The project and dates are fictional. It was not executed against BigQuery for this article. Before using it yourself, replace the project, dataset and dates and review the cost estimate.
Read-only queries can still incur costs. The BigQuery cost guide describes the validator and dry-run options. Adding a LIMIT is not a general substitute for a cost control.
sqlSELECT
namespace,
data_date,
epoch_version,
publish_time
FROM `example-project.searchconsole.ExportLog`
WHERE agenda = 'SEARCHDATA'
AND data_date BETWEEN DATE '2026-05-03' AND DATE '2026-05-10'
ORDER BY
data_date,
namespace,
epoch_version DESC,
publish_time DESC;
Place a list of expected data dates and required namespaces beside the results. Mark each combination as successfully recorded or unresolved. A query returns existing rows; it does not automatically make absent combinations visible.
The fictional May 3 to May 10 period contains eight calendar days. If two separate analyses require both performance tables, there are 16 combinations to inspect. A report requiring only the URL table needs eight. This count describes the inspection plan, not a measured outcome.
Count distinct combinations rather than log rows. Two versions for the same table and date do not close an additional day. Even 16 existing log rows could therefore cover fewer than 16 required combinations. Record the inspection time so a later delivery can update the relevant item. A fully evidenced delivery plan still needs reconciliation with the data retained today and the downstream report. One row count cannot replace all three checks.
A technical SEO investigation should hand over those unresolved combinations explicitly. “Check BigQuery” is too vague. “URL performance table, May 6 data date, no success record in the inspected log” states a bounded finding and its evidence.
Recovery attempts have a time limit
Google distinguishes transient errors from persistent problems. Temporary connection failures can be retried immediately. For non-transient issues such as missing permissions, the next attempt happens at the next scheduled export.
The documentation describes retries for a missed data date lasting about a week. After about a month of unsuccessful attempts, bulk export as a whole can stop. These approximate windows are neither a reason to postpone repair nor a precise recovery guarantee to the minute.
After correcting the cause, check current operation and then revisit each unresolved combination. A recovered date can close one gap. A working export does not establish that dates now outside the retry window will still arrive.
The same care applies to a project or dataset-location change. Plan the transition with an explicit boundary between the previous and new inventory. The SEO migration checklist helps organize the handover of technical changes; add delivery dates, table coverage and outstanding gaps for this data pipeline.
Reconcile data days in Pacific Time
In the GSC tables, data_date identifies the day of the clicks or impressions in Pacific Time. Preserve that value as the reporting day when reconciling the export. Do not derive it from the date your browser in Berlin displays for publish_time.
Delivery time and performance period are different fields. An older data day can be delivered or corrected later. Grouping solely by delivery date creates a report about arrivals rather than a correct search-performance series.
Preserve the completion time with unambiguous timezone information. Also document the timezone in which an interface displays it. A fixed manual hour offset is unsuitable for a continuing reconciliation. The date supplied by the source remains the common reference.
Check revisions, retention and schema separately
An increased epoch_version identifies a correction to data already delivered. Google describes these daily corrections as atomic updates. Do not add the versions together as additional performance volume. They describe delivery states, not extra clicks.
Next, inspect today's inventory. Retention settings can remove an older partition even though its export once succeeded. Google's setup instructions recommend a partition lifetime of at least 14 days. The BigQuery partition-retention documentation also explains inherited settings and their relationship to table expiration. An expiration date on the entire table is a separate decision.
Do not modify the raw schemas supplied by Search Console to add your own report columns. The setup instructions warn that schema changes cause exports to fail. Put custom reporting logic in a separate analysis layer.
Performance queries can also contain repeated keys. Google's query guidelines therefore require suitable aggregation. Physical row counts, distinct URL counts and total impressions are different quantities. None alone establishes a complete delivery calendar.
Make coverage visible in the report
Record the inventory used, period by data_date, selected table and known gaps. Separate dates before the export began from missed deliveries and subsequently expired partitions. These states lead the reader to different actions.
Historical ranking observations are another source again. Our guide to measuring Google rankings reliably explains how to interpret those series. They cannot reconstruct missing GSC exports. Likewise, rank tracking started later does not generate retrospective daily observations.
If you also connect the property to your SEO workflow, Crawl Foundry's Search Console integration explains the read-only connection and source status. That is a separate task from checking the BigQuery deliveries described here. It does not establish that bulk export has been configured.
The final acceptance record names the data dates for each table that are successfully recorded, currently present or unresolved. A green status message can supplement that list. It cannot replace it. You can then investigate a subsequent decline against a known inventory instead of first having to explain an artificial drop created by missing deliveries.