SEO Traffic Forecast: Build a CTR Curve From Query Data

Short answer: A defensible SEO traffic forecast multiplies three things: the impressions your queries already earn in Search Console, a click-through rate (CTR) curve built from your own data, and the position change you expect from planned work. Run the same formula under three sets of assumptions (conservative, target, optimistic), quantify the error by testing the method on a past period, and present ranges instead of a single figure. A generic "CTR by position" table should be a sanity check at most, because published studies disagree with one another.

Somebody will eventually ask, "What will organic traffic look like in six months?" The quick answer is a growth percentage. The honest answer shows what the percentage rests on. This guide is about the honest answer. It begins with what Search Console actually counts, moves to building a CTR curve from your own queries, turns that curve into scenarios, deals with seasonality and uncertainty, and ends with how to present the result. No step guarantees a ranking or a traffic level; the goal is a transparent model that a decision maker can challenge.

Start With What Search Console Counts

Every forecast is only as good as its inputs. Before building anything, read the definitions Google uses, because several of them behave differently from what the labels suggest.

Four metrics, four definitions

The Search Console Performance report help page (Opens in a new tab) defines clicks as the number of times a user clicked through to your site from Google Search results, impressions as how many times your site appeared in Search results, and CTR as clicks divided by impressions. Average position is the average position of the topmost result from your site; in the chart it covers the whole site, and in the table it covers the URL or grouping in that row. You can slice the data by queries, pages, countries, devices, search appearance and dates, and by search type: web, image, video and news.

Two details on that page matter for forecasting. In the chart, data is aggregated by property, so two results from one site for the same query count as a single impression in the chart total. And the newest data may be preliminary and can change within hours; it appears as a dotted line on the graph.

The "topmost position" trap

A second help page, what impressions, position and clicks mean (Opens in a new tab), says an impression means a user has seen, or potentially seen, a link to your site. It defines position as the topmost position occupied by a link to your property or page in the results. Its worked example: if a query shows your links at positions 2, 4 and 6, the position for that query is 2; if another query shows links at 3, 5 and 9, the position is 3; the average across the two queries is (2 + 3) / 2 = 2.5.

Three consequences follow. An average position of 3.2 does not mean you sit at third place every time. Sites with several results for one query look better than a single-result site at the same effective visibility. And impressions that were "potentially" seen can rise without anyone really viewing more of your listing. For a forecast, treat position as a range, not a point.

Limits that shape the dataset

The help page on Performance report data limits (Opens in a new tab) explains that, due to internal limitations, Search Console stores top data rows rather than all of them, that tables are capped at 1,000 rows, that rare queries are omitted to protect privacy, and that daily figures follow California time. Exported cells shown as "~" or "-" arrive as zeros, so a zero in the file may not be a real zero. These limits can change in Google's documentation, so check the current pages before you build on them.

The API guide on getting all your data (Opens in a new tab) adds that the API exposes at most 50,000 rows per day per search type, sorted by clicks. It notes that metrics are calculated differently when grouping by page rather than by property, and that grouping by page and query can cause the system to drop some data. For accurate totals, it advises omitting those dimensions. In practice, pull your top-line traffic from a dimensionless request and your query distribution from a dimensioned one, and do not expect the two to reconcile exactly.

History is limited too. A Google Analytics help page states that Search Console keeps data for the last 16 months (source (Opens in a new tab)). Archive your exports monthly if you want a longer baseline.

Cleaning the export before you model

• Export the full 16 months by date, query, page and device, and keep a separate dimensionless total.
• Tag branded queries (brand name, misspellings, domain) so they can be excluded from growth math.
• Mark the last few days as provisional and leave them out of the baseline.
• Treat "~" and "-" cells as missing, not as zero.
• Log site events with dates: migrations, template changes, large content launches.
• Separate low-impression rows into their own bucket, because their average positions are noisy.

Grouping queries into forecastable units

Forecasting query by query is tedious and misleading, since single queries are noisy. Group them by target page and intent: queries that land on the same page and answer the same question belong together. For each group, record the page URL, the impression-weighted current position and the last twelve months of impressions. These three fields become the raw material of your scenario table. Keep a separate "out of scope" group for accidental queries, one-off long-tail rows and anything with the brand name, and keep it so you can reconcile your forecast to the dimensionless total later.

Building a CTR Curve From Your Own Queries

A CTR curve describes how click-through rate changes with position. Ready-made curves look attractive because they fit on one slide. Their weakness is that you rarely know whose data they came from.

Why borrowed curves mislead

The Backlinko CTR study (Opens in a new tab) shows the issue. It says it used CTR data from several Google Search Console accounts supplied through Semrush, covering 1,312,881 pages and 12,166,560 search queries, and it reports an average CTR of 27.6% for the number one result. The same article cites another study (FirstPage, 2023) that puts the first position at 39.8%. Two large datasets, two quite different headline numbers. The study also states that CTR for the number one result is significantly higher for branded queries than for non-branded ones, which it says is likely related to navigational searches, and it does not state the period the data covers. The lesson is not that either number is wrong. It is that query mix, brand share and the layout of the results page change the answer, and yours will differ from theirs.

Building the curve step by step

1. Remove branded queries. Branded rows pull the curve upward and inflate growth forecasts.
2. Split by device. Mobile and desktop result pages differ; build separate curves if volume allows.
3. Bucket positions. Round average position to whole numbers for the top few places and widen buckets lower down (4 to 5, 6 to 10, 11 to 20) where data thins.
4. Compute CTR as a weighted ratio. For each bucket, divide total clicks by total impressions. Averaging row-level CTRs overweights tiny rows and distorts the result.
5. Set a minimum impressions rule. Decide how many impressions a bucket needs to be trusted and merge thin buckets with a neighbor.
6. Run a sanity check. CTR should usually fall as position worsens. If it rises between two buckets, look for causes (results-page features, snippet quality, thin data) before smoothing.
7. Compare with outside curves without copying them. Use published figures only as a boundary check and investigate large gaps.

Search type and appearance breakouts

Because the report lets you filter by search type, device and search appearance, you can test whether pages with a certain appearance behave differently from the rest. If they do, forecast them in a separate bucket. A single site-wide curve averages these differences away and then misses both groups. The finer you slice, the fewer impressions each bucket holds, so keep slices only as thin as your minimum impressions rule allows.

A template to fill with your own data

We leave the cells empty on purpose. Your numbers must come from your property; filling the table with someone else's figures defeats its purpose.

Mapping the curve to pages

Once the curve exists, match each query group to a landing page. The guide to page-two queries shows how to build that list, and the article on reading average position explains the nuances of the metric you are now relying on.

From Curve to Three Scenarios

One number hides uncertainty. Three scenarios expose which assumptions drive the result. The scenarios do not use different math; they run the same formula with different inputs.

The core calculation

For every query group, expected extra clicks equal the group's expected impressions multiplied by the difference between the CTR at the target position and the CTR at the current position, then multiplied by a realization rate. The realization rate captures how much of the planned work (a content update, internal links, a rewritten title) ships and takes effect. Sum the results over all groups to get the total.

Sorting out the realization rate

Realization rate is the most argued-over input and the least documented. Derive it from your own history, not from optimism. Count how many planned page updates in recent periods shipped on time, how many of those moved position in the intended direction and how many weeks the movement took. If you have no history, label a low value in the conservative scenario and a medium value in the target scenario as "first assumptions" and replace them with real data after two quarters. The rate reflects your team's capacity and approval speed, so it is as much a planning parameter as a technical one.

Scenario assumptions at a glance

Which scenario drives which decision

Use the conservative case for budget and resourcing commitments, the target case for internal goals, and show the optimistic case only as context. A simple decision rule follows: if even the conservative scenario does not justify the investment, rethink the scope or the goal. A plan that only makes sense in the optimistic case carries risk that should be named. To rank which initiatives to include, the hypothesis list guide offers an impact and effort ordering.

Example scenario: a documentation site

This example is fictional and only illustrates the logic. A software documentation site has a handful of how-to pages sitting near the bottom of page one for questions that many developers ask. The plan is to add clearer code explanations, restructure headings and link the pages from related guides. The conservative scenario assumes only the restructure ships on time and positions improve slightly. The target scenario assumes all three tasks ship and the pages move up several places. The optimistic scenario assumes the pages reach the top three. All three use the same curve and the same impressions; only the position and realization assumptions differ. The point of the exercise is to show the reader which assumption moves the result most, and in many real cases it is the realization rate, not the curve.

Seasonality, Backtests and Error Bands

A good forecast separates what it knows from what it cannot know. Seasonality is knowable. Uncertainty is measurable but never zero.

Seasonality with a 16-month window

With 16 months of history you can see at best one season twice, so year-over-year comparison needs at least thirteen months. For a given month, divide this year's impressions by last year's; treat that ratio as a seasonal index and carry it forward. With fewer than twelve months of data, do not fabricate a seasonal index. State the limitation and, if you use outside interest curves for the topic, use them only as a directional hint and say so in the model notes.

Backtesting to size the error band

The most defensible way to estimate uncertainty is to run your method on the past. Hold out the most recent three months, build the model from earlier data, forecast the held-out period and compare it with what happened. The percentage gap is a concrete error estimate you can use to widen or narrow your ranges. Repeat the test over several periods to see whether the error is stable. This is a validation practice rather than a rule from a documentation page, so each team must run it on its own data.

What the model cannot see

• Results-page changes: New layout elements or ads can shift clicks at the same position. Backlinko, for example, suggests that the second position's CTR spike may relate to that result appearing above the fold when there are no ads or other features.
• Algorithm updates: You cannot predict their direction; rebuild after one.
• Competitor moves: A rival's new page can change your position.
• Demand shifts: Impressions depend on interest you do not control.
• Technical incidents: Migrations, speed regressions or indexing problems produce results the plan did not include.

Handling short-term noise

Daily spikes and dips are not reasons to change the model. Work with weekly totals, watch forecast deviation with at least a four-week moving average, and leave the model alone while the gap sits inside your error band. If the gap leaves the band, first rule out data issues (provisional data, export zeros, dimension loss) and then revisit assumptions. For practical ways to lift click-through itself, see the guide to improving organic CTR.

When to rebuild the forecast

A forecast is not a document you write once. Refresh it every quarter and also rebuild when consecutive deviations leave the error band, when a migration or template change lands, when a new content cluster changes the query mix, or when a lasting layout change appears in the results. Keep dated versions so that after a few periods you can see which assumption missed most often and improve the model there.

Presenting the Forecast

A sound model presented badly gets read as a promise. A forecast report should answer three questions: what is it based on, how uncertain is it and what will we watch?

A one-page structure

1. Summary sentence: The expected additional organic clicks under the three scenarios, with the target scenario as the planning baseline.
2. Data and scope: Date range, device, brand included or excluded, query groups covered.
3. Method: One paragraph on impressions, the CTR curve and position assumptions.
4. Scenario table: A short version of the assumptions table.
5. Error band: The backtest result and how to read it.
6. Risks: The list of things the model cannot see.
7. Monitoring indicators and review date: What you will track and when you will revisit.
8. Out of scope: Conversions, revenue and branded queries.

Tailoring the summary to the audience

Leadership wants to know whether the conservative case justifies the investment and what the biggest risk is. Content and engineering teams want to see which pages tie to which query groups and in what order to work. Finance asks when assumptions will be refreshed and how the error band was computed. Produce a different page for each audience from one model, so the numbers never diverge. When several copies of a forecast circulate, teams defend different numbers and trust erodes. Always state what the forecast excludes, so nobody is surprised later when total traffic does not match.

Leading indicators

Traffic itself lags the work. To learn earlier whether changes are working, track weekly position, impressions and bucket-level CTR for the target query groups. If position improves but impressions do not grow, you may have chosen the wrong query range. If impressions grow while CTR falls, the title and description deserve attention.

Phrases to avoid

• "Traffic will grow by X" without conditions.
• A single headline number without its range.
• A borrowed CTR curve with no source or data mix named.
• Branded queries inside a growth story.
• Revenue or conversion claims tied to traffic through an assumption you never measured.

Checklist

• Were inputs read against Search Console definitions (topmost position, potentially seen impressions)?
• Are the dimensionless total and the dimensioned distribution kept apart?
• Were branded queries separated?
• Is CTR computed per bucket as total clicks over total impressions?
• Do the three scenarios use one formula with different assumptions?
• Is the seasonal index built from at least thirteen months of data?
• Was a backtest run and the error band written into the report?
• Are monitoring indicators and a review date set?

Frequently Asked Questions

Can I use a published CTR by position table for a traffic forecast?

Use it only as a boundary check. Published studies diverge: Backlinko's study reports an average of 27.6% for the first result, while another study cited in the same article reports 39.8%. Query mix, brand share and results-page layout differ, so the most reliable base is a curve built from your own Search Console data.

Why is average position not enough on its own for forecasting?

Search Console reports the topmost position of your site's results, averaged across queries and days. A value of 3.2 does not mean you always rank third, and averages are noisy for low-impression queries. Treat position as buckets and ranges in the model.

How far back does Search Console data go, and how does that affect seasonality?

A Google Analytics help page says Search Console keeps data for the last 16 months. That lets you see a season twice at best, and month-by-month year-over-year comparison needs at least thirteen months. Archive your exports regularly to extend your baseline.

How do I estimate the error of an SEO forecast?

Backtest it. Hold out the latest few months, build the model from earlier data, forecast the held-out period and compare it with actual results. Repeat across several periods and use the gap to size your ranges. This is a validation practice that each team should run on its own data.

Should branded queries be part of the forecast?

Exclude them from growth math and report them separately. The Backlinko study states that CTR for the number one result is significantly higher for branded searches than for non-branded ones, so branded rows can inflate a curve and the resulting targets.

Is it acceptable to give stakeholders a single traffic number?

A single number hides uncertainty and is often read as a commitment. Present conservative, target and optimistic ranges with assumptions, an error band, risks and monitoring indicators. No scenario is a guarantee of traffic or rankings.

Conclusion

A realistic SEO traffic forecast starts by reading Search Console's definitions correctly: average position is an average of topmost positions, impressions count links a user may have seen, and tables and exports have limits. From there, build a CTR curve from non-branded queries in your own property, use published curves only as a boundary check, run three scenarios through one formula, build a seasonal index only when you have enough months, and size the error band with a backtest. Present ranges together with assumptions, risks and leading indicators. A forecast is not a promise; it is a transparent record of the assumptions a decision rests on, and it has to be rebuilt as search results, algorithms and competitors change.

If your plan includes strengthening the authority of target pages through link work, you can review the backlink packages at Akua Adforce; scope and terms are listed on the product page.