Search Console's Performance report is a rolling sixteen-month window, so at month fifteen the first month your site ever had is still in it and in two months it will not be. What to do before then is one job with three parts: pull the earliest months you still have, keep them at a grain that can answer a question you have not thought of yet, and write down which period you are calling your baseline. Nothing about this gets easier by waiting, because the rows leave on a schedule nobody can appeal.
When the sixteen-month window rolls past a date, every row for that date leaves the Performance report, and the API reads the same window as the interface — there is no archive endpoint, no paid tier that keeps more, and no request shape that reaches behind it. What you lose is not a chart, it is the underlying rows: which queries earned impressions that month, on which pages, in which countries, at what position. A screenshot of the chart survives and answers almost nothing.
The part that catches people out is that a rolling window takes the oldest data first, which is exactly the data that describes how the site started. The most recent sixteen months are always there, so nothing looks wrong. The question that quietly becomes unanswerable is the retrospective one: what were we ranking for before we started doing this, and how far have we actually come.
A baseline that is one number per month answers one question and forecloses every other. Six months from now the useful questions about your first year are almost all distributional: which queries did we own then and have since lost, which pages carried the traffic before the ones that carry it now, what share of clicks was branded, what did our average position look like when we had thirty ranking queries rather than three hundred. None of those can be recovered from a clicks total, and all of them can be answered from the query rows if you kept them.
The cost of keeping rows rather than totals is storage measured in megabytes, which is nothing, against a set of questions that cannot be reconstructed at any price. So the rule for a Search Console baseline is to keep the finest grain you can pull, and to derive the totals from it later rather than the other way round.
Ask for query and page together and you get one row per pair — a genuinely useful shape, and one whose totals will never add up to the chart above it.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Pulling a Search Console baseline is four exports, and the grain matters more than the date range. Take the whole window you still have, not just the earliest month, because the intermediate months are what make a trend rather than two dots.
| The question you will ask later | What has to have been kept | What it costs |
|---|---|---|
| Which queries have we lost since launch? | Query rows by month, with clicks, impressions and position | One export per month, paged past the row limit |
| Which page used to earn this traffic? | Query and page together, by month | More rows, and some combinations Google withholds |
| Were we better or worse in Germany? | Country as a dimension, kept alongside query | Row count multiplies; filter to the countries that matter |
| Did the redesign in month eight help? | Date grain, not month grain, around that change | Daily rows for a short period rather than everything |
Grouping by query and page at once is where a Search Console export stops being complete: Google withholds some combinations, so the sum of a query-and-page report does not match the sum of a query report. Keep both, and keep them as separate exports rather than trying to reconcile them, because the difference between the two is information about what is withheld rather than an error to fix.
A baseline nobody named is a folder of exports. Pick a period, write down why it was chosen and what was true of the site then — how many pages were published, what had changed in the previous month, whether the property had only just been verified — and keep that note beside the data. In eighteen months the person comparing against it will be you, and the comparison is only meaningful if the note says what the site was.
One thing to record explicitly is the property the data came from. A URL-prefix property and a domain property are different properties with different data, and a baseline pulled from one cannot be compared like for like against a report pulled from the other. If you are considering that switch, do it before you fix the baseline, not after.
The Performance report holds a rolling sixteen months, and the API reads the same window. Dates older than that return no rows rather than an error, which is why a report that silently narrows is easy to miss. There is no setting that extends it and no export inside Search Console that reaches further back, so anything you want beyond sixteen months has to be copied out before it rolls.
It is a soft deadline with a hard edge behind it. A site's first month leaves the window at month seventeen, so month fifteen leaves a margin for the export to fail, for a row limit to truncate it, and for whoever runs it to be on holiday. Doing it at month sixteen and a half works too, provided nothing goes wrong, which is the assumption worth not making.
Not from Google. Third-party rank trackers hold their own measurements of your rankings, which are a different thing from your impressions and clicks, and analytics holds sessions rather than search data. If a page's early search history was not exported before the window rolled, the honest answer in a later report is that the period is not measurable, stated rather than estimated.
Store rows, not summaries: query by month at minimum, and query with page for the periods you expect to argue about. Keep country as a dimension if you sell in more than one. Totals can always be derived from rows, and rows can never be derived from totals, so the grain you store is the ceiling on every question anyone asks later.
Reaching the target marks a goal as reached and leaves it open. Closing is a separate decision with three possible endings, because a number passed through in week two is not a result.
Search Console has no language dimension. On a site in more than one language you separate the data by page or by country, which means the URL structure you chose for translations decides what you can measure.
