How to forecast website traffic

A traffic forecast is a planning number, not a prophecy. It exists so you can size next quarter's content plan, notice early when reality runs under it, and answer "is this month normal?" with something better than a feeling. Forecasting your own site works because you have the real history. Forecasting someone else's site is a different exercise - estimates stacked on estimates - and we'll get to why at the end.

The good news for anyone allergic to statistics: for a small site's purposes, the simple methods hold up surprisingly well, and the fancy ones mostly add precision the underlying data can't support.

Everything below needs one input: monthly visitors or sessions, as far back as you have them, ideally two years so a seasonal pattern can show up twice. Any analytics tool has this. In GA4, mind one trap: data retention settings cap event-level data at 14 months (the default is two), which limits Explorations - though standard reports reach further back. If you want a history longer than that, export the monthly totals to a spreadsheet now and keep your own archive; your future forecasts will thank you.

If your traffic has both a trend and seasons, the second method is the workhorse: it splits the forecast into "how big are we now" and "what does this month usually do", which is the same decomposition professional forecasters use, done with division instead of software.

These come straight from the standard forecasting textbook - Hyndman and Athanasopoulos's Forecasting: Principles and Practice, free online - where they serve as the baselines fancier models have to beat:

• Same month last year. Forecast next March as last March's number. This is the seasonal-naive method, and for sites with a yearly rhythm it's embarrassingly hard to beat.
• Last year plus your growth. If the last twelve months ran 20% above the twelve before, forecast next March as last March times 1.2. This adds the trend the first method ignores.
• A moving average. Average the last three months to smooth out noise and read the underlying level. Better for flat, jittery traffic than for growing or seasonal traffic, where it lags reality.

Before trusting a seasonal pattern, confirm it repeats: line up the same months across two or three years and see whether the shape rhymes. One January bump is an event; two is a season. Borrowed seasonality is the common mistake - retail's Q4 surge, the fitness industry's New Year spike - your site has its own calendar, and only your data knows it.

Google Trends is a useful second witness for search-driven sites, with one caveat: its numbers are an index from 0 to 100, normalized against total search volume - so it confirms when interest in your topic peaks, and says nothing about how many visits that means for you.

Whatever the method, the honest output is a range. Look at how far your actual months have landed from what the method would have predicted for them - that spread is your error bar, and for most small sites it's on the order of plus or minus 20%. "Between 8,000 and 12,000, centered on 10,000" reads less impressively than "10,412", and is the only version that deserves to be in a plan. A single-point forecast isn't wrong because the method failed; it's wrong because it claims a precision no traffic data has.

Every method above quietly assumes the future behaves like the past, and the web periodically refuses. Google's core and spam updates land unannounced and can move organic traffic sharply in either direction - the largest single reason a sensible forecast misses. AI answers are the slower-moving version of the same problem: Pew Research found users click a result on 8% of searches with an AI summary versus 15% without, so a trend line fitted to pre-AI-Overview months overstates what search will deliver next year.

One-off events cut both ways too: a viral spike or an outage sitting in your history distorts every average it touches. Before forecasting, mark the months you can explain as exceptional and consider computing around them. And when reality diverges from the forecast, that's not the method failing - that's the forecast doing its actual job, which is flagging that something changed early enough to investigate.

Everything above assumes measured data. For a site you don't own, there is none available to you - only panel-based estimates from tools like Similarweb or Semrush, which routinely land tens of percent off the site's real numbers. A forecast built on an estimate inherits the estimate's error and adds its own, which is why "projecting a competitor's growth" belongs in the rough-comparison bucket: fine for direction, meaningless as a number.

Keep your own monthly archive, forecast with last-year-times-growth, sanity-check the seasonality, publish a range, and re-fit after anything structural - an algorithm update, a redesign, a strategy change. Then close the loop: each month, compare actuals to the forecast in your regular traffic review. The forecast that gets checked monthly earns its keep twice - once as a plan, and once as the tripwire that tells you when the website's world just changed.