Forecast Google Search Console Clicks from a CSV
Charlie SimmonTurn daily Search Console clicks into a seven-day forecast. Prepare a clean CSV, try the inline tool, and compare a holdout against the previous week.
You can forecast daily Google Search clicks by exporting a consistent date-and-clicks series, uploading it below, and setting the horizon to seven days. Before using that forecast in a report, hide the last completed week and check how well the model predicts it compared with simply repeating the previous week.
This workflow is for a site owner or analyst who already has Search Console history and needs a short-term baseline. It estimates what the existing pattern might do next. It does not predict keyword rankings or tell you how many clicks a new article will earn.
Try a seven-day click forecast
The tool is prefilled with 28 days of invented example data, with seven forecast steps selected. These are format examples, not customer results or evidence of forecast accuracy. Replace them with your prepared CSV when you are ready.
The web forecast sends the CSV to a public Hugging Face Space for processing. It does not run entirely in your browser. Only submit data you are permitted to share with that third-party service. The browser demo needs no account, and its availability depends on the shared upstream service.
CSV forecast studio
Forecast daily search clicks
Try the synthetic example, or replace it with your own date-and-clicks CSV. Seven daily steps forecast one week.
1. Export the series you actually want to forecast
Open your property in Search Console and go to the Search results performance report. Choose your search type, date range and any page, country, device or query filters. Use daily granularity and the Dates view, then export to CSV. Keep the daily table with a date on each row; a table of queries or pages is not a time series.
Google documents that exports reflect the current filters and grouping. Write those settings beside the file. A forecast for one country cannot later be evaluated against clicks from every country.
Use completed days. The newest Search Console data can be preliminary, and the 24-hour view contains hourly points. Do not combine that hourly export with a daily file or interpret an unfinished day as a sudden loss of demand.
For a first weekly experiment, aim to collect several completed weeks rather than relying on the eight-row technical minimum. Eight weeks gives you repeated weekdays to inspect, but it is a practical starting point, not a guarantee of useful predictions. A new site with only a few days of traffic does not yet have enough history for this workflow to be convincing.
2. Reduce the export to date and clicks
Create a working copy with two columns:
| Column | What to keep |
| -------- | ----------------------------------------------------------------------- |
| date | One valid YYYY-MM-DD date per day, sorted oldest first |
| clicks | The daily click count as a number, without thousands separators or text |
Remove summary rows, notes and duplicate dates. Keep a recorded zero when there were genuinely no clicks. Investigate missing or unavailable observations rather than silently converting them into zero; Google notes that some unavailable values export as zero, so check suspicious gaps against the report.
Leave out CTR, average position and impressions for this first experiment. They answer different questions, and the tool forecasts every numeric column as a target. Adding a position column does not make the forecast a ranking simulation. Adding a future campaign budget does not condition it on that campaign.
The studio accepts CSV, TXT or TSV up to 2 MB, with at least eight history rows and no more than eight numeric columns. This workflow only needs one numeric column. Use the CSV preparation guide if your export has inconsistent dates, decimal commas or quoted fields.
3. Run seven steps and inspect the output
Upload your prepared file or paste it over the example. Set the forecast steps to 7, then select Run forecast. A step follows the input frequency: seven daily steps mean seven days; seven weekly rows would mean seven weeks. The browser control accepts 1–36 steps, so a 28-day forecast is possible when the history is daily, but a longer horizon needs its own evaluation.
Read the median as the model's central estimate, then inspect the displayed 80% interval. It is a nominal model interval, not a promise that your next seven observations will fall inside it. A wide band may make the forecast too uncertain for the decision you had in mind.
Check that the output dates follow the last input date and that the column is still clicks. Download the CSV to keep the forecast made at this cutoff. Record the cutoff, horizon and filters alongside it so that a colleague can reproduce the comparison later.
4. Test the last completed week before forecasting the next one
Do this once before presenting a forward projection:
- Keep the final seven completed days in a separate sheet as the actual results.
- Remove those seven rows from the model input. Keep all earlier dates in order.
- Forecast seven steps and download the result. Do not edit the held-out actuals to make the fit look better.
- For a simple comparison, predict each held-out day using the observed count from seven days earlier. This is a weekly repeat baseline.
- For each method, calculate the absolute difference between predicted and actual clicks for every day, then average the seven differences. That is mean absolute error, measured in clicks.
Compare daily errors as well as the week's total. A model can get the total close while getting the weekday pattern wrong. Absolute error also remains interpretable when a day has zero clicks, whereas a percentage error can become undefined.
If the model does not improve the comparison enough to matter, keep the simpler baseline. One week is only an initial check: repeat at several earlier cutoffs before drawing a conclusion. Seven observations are too few to establish whether an 80% interval is well calibrated. The forecast evaluation guide explains how to extend that check without using future information.
5. Keep the forecast separate from SEO promises
This tool sees your numerical history. It does not know next month's Google update, your planned site migration, a newly launched section or a competitor's changes. Record those possibilities separately instead of assuming they are already represented in the forecast.
A forecast can help you notice that actual clicks are departing from a historical baseline. It cannot prove that an SEO edit caused the difference. That requires a suitable comparison and an investigation of other changes. Likewise, Search Console clicks are not Analytics sessions, registrations or revenue; measure those outcomes in their own systems.
If there was a major measurement or site change, compare a shorter, consistent history against the longer history using the same holdout. Do not remove an inconvenient period simply because doing so improves the result. State why a cutoff changed and keep the original file.
Questions before using this in a report
Does the tool connect to my Google account?
No. This workflow uses a file you export and prepare yourself. It does not require your Google credentials or Search Console API key.
Can I forecast only non-brand search clicks?
You can use an appropriately filtered daily export. Keep the same query filter across the input, holdout and future actuals, and describe the filter in the report. The forecast does not classify your brand terms for you.
What if the public model service is busy?
Keep your input and retry later after checking the error. The web demo and current paid API depend on the same shared public Space; buying credits does not provide dedicated capacity or an availability guarantee.
Can I use the result to forecast all website traffic?
Only if the input represents the traffic metric you intend to forecast. For Analytics sessions and capacity planning, use the separate website traffic forecasting workflow. Do not relabel Search Console clicks as total visits.