Search Console data is delayed on purpose, and the size of the delay is documented: collected data is usually available in two to three days. Almost every “my traffic dropped off a cliff” message I get on a Monday is somebody looking at Friday and Saturday in a report that has not finished counting them.
This one is worth understanding properly, because the lag is not a single number. Different reports lag by different amounts, and one of them, the Core Web Vitals report, is a 28-day rolling average that will not move for weeks no matter what you change, the newest days in the Performance report are marked as provisional in a way that is easy to miss, and the API quietly hides the recent days altogether unless you ask for them. That last one has bitten me in my own tooling, which is the reason I am writing this.
How far behind is Search Console data?
Google’s troubleshooting documentation for the Performance report gives the number directly:
Time lag: There can be a lag between when the numbers are calculated and when they are visible. Collected data is usually available in 2-3 days.
Two to three days is your default assumption for anything in Performance. On top of that sits a second concept, which Google now calls preliminary data:
The newest data in the Performance report is sometimes preliminary, meaning it’s still being collected and may change in the next few hours.
Preliminary data is drawn on the chart with a dotted line, and by default the report does not show it at all. Google’s wording: “The report shows complete days by default; preliminary data will only show when you explicitly choose a day with preliminary data in the date-range selector (usually today’s data and sometimes yesterday’s).”
So there are three states, not two, and they explain most of the confusion:
Source: Google Search Console Help, Performance report data and discrepancies pages, and the Search Analytics API reference, read 23 August 2026.
Two smaller details that settle arguments. Daily rows are counted in Pacific Time, not your time zone, so your “yesterday” and Google’s are not the same day. And the “last updated” date on the report is the honest one to look at, because it “shows the last date for which the report has any data”.
Why does the API return less data than the interface?
This is the part that catches people building their own reporting, and it caught me.
The Search Analytics API reference documents the dataState parameter like this:
If ‘all’ (case-insensitive), data will include fresh data. If ‘final’ (case-insensitive) or if this parameter is omitted, the returned data will include only finalized data.
Read the last clause again. Omitting the parameter is not neutral. Omitting it means final, which means the most recent few days are missing from your response and nothing in the response says so. There is no flag, no warning, no partial-data marker. You get fewer rows and a smaller total, and it looks exactly like a traffic decline.
The failure mode is specific and nasty: someone builds a dashboard on the API defaults, opens Search Console in a browser next to it, and finds the two disagree. Then they go looking for a bug in their code, or worse, they believe the dashboard and tell a client traffic fell.
I hit this while building my own Search Console tooling, and the fix I settled on was to invert the default. The MCP server I use for client work sends dataState: "all" unless I explicitly ask for finalized rows, and when I do ask for finalized rows it attaches a warning explaining that the last few days are being omitted and why. That decision is written into the tool itself rather than into a README nobody reads, because the whole class of error comes from a silent default. The trade-off is honest and worth stating: with fresh data included, the last day or two can revise upward on a later query. Google said so when the feature shipped in 2019: “Each fresh data point will be replaced with the final data point after a few days. It is expected that from time to time the fresh data might change a bit before being finalized.”
Fresh numbers that move slightly beat missing numbers that pretend to be complete. If you are building anything on this API, set dataState explicitly, in both directions, and never leave it to the default.
Is the missing data a bug or a known anomaly?
Sometimes it is neither the lag nor your code, and there is a specific page for that case. Google maintains a data anomalies list, which it describes as recording “known issues in the last 3-16 months that might affect your data”.
It is the first place to look when a chart has a hole in it, and it is genuinely maintained. Recent entries include a Discover and generative AI logging error on 13 August 2026 that decreased clicks and impressions, a further generative-AI impressions decrease from 13 to 17 August, and, in a more sobering entry from earlier in the year, two days missing from the Bulk data exports with the note that the data will not be recovered.
That last line is worth internalising. Not every gap gets backfilled. If you depend on complete daily history, export it yourself rather than assuming Google’s copy will be repaired.
The important thing about the anomalies page is what its absence means. When something is missing and the page says nothing, you are in unconfirmed territory, which is exactly where the crawl stats gap on 15 and 16 August sat when I wrote it up: real, widely reported, and not listed. Unlisted does not mean imaginary. It means nobody at Google has written it down yet.
Which reports lag by how much?
They are not on one clock, and treating them as one is where bad diagnoses come from.
- Performance: two to three days, plus preliminary data for today and sometimes yesterday.
- Page indexing: updates on its own schedule after a crawl, so a page you fixed today will not change status today. This is the same reason fix validation takes up to two weeks rather than minutes.
- Crawl stats: usually more current than Performance, and the report that has visibly wobbled twice this month.
- Core Web Vitals: field data from CrUX, which is a trailing 28-day aggregate, and Google’s own validation on it runs as “a 28-day monitoring session”. A fix you shipped yesterday cannot show here yet, no matter how good it was.
So the answer to “did my change work” depends entirely on which report answers it. URL Inspection’s live test answers in seconds, because it fetches the page right now. Everything else answers in days or weeks. If you want to know whether a fix is live, use the live test; if you want to know whether it worked, wait. When the inspection and the Page indexing report contradict each other about one URL, URL Inspection tool vs Page indexing report explains which one is telling the truth. That difference is the single most useful thing to teach a client, and it is why I check a batch myself with the bulk URL inspection tool rather than refreshing a report that structurally cannot have the answer yet.
What to do when the numbers look wrong
In order, and it takes five minutes:
- Check the last updated date on the report before reading the chart. If your “drop” is inside the last three days, stop here.
- Compare like for like: same day count, same property type, same search type. Web, image, and video are separate.
- Open the data anomalies page and look for a matching date range.
- If you are using the API, print your
dataStateand confirm it is what you intended. - Only then start looking for a real cause, and start with the Search Console indexing statuses rather than the performance chart, because a genuine drop usually has a cause you can name in the indexing data.
I have watched clients spend a week on a decline that was a reporting lag and a time zone. The five minutes above would have bought that week back. One more candidate cause to keep on the list this month: Google confirmed on 26 August 2026 that result links now route through a google.com/goto redirect, which is a referrer story rather than a Search Console one, but it lands in the same reports.
Sources
- Google Search Console Help, Performance report data discrepancies, time lag section
- Google Search Console Help, About Performance report data, preliminary data and last updated date
- Google Search Console Help, Data anomalies in Search Console
- Google Search Console Help, Core Web Vitals report
- Google for Developers, Search Analytics: query, dataState parameter
- Google Search Central, Fresh data in Search performance reports, September 2019