Each universe keyword stores an absolute monthly volume profile (Jan through Dec) pulled from DataForSEO. From that, monthFactor() normalises any month against the keyword's own average, seasonFactor() blends this month with the two ahead at weights 0.25 / 0.5 / 0.25, and seasonLabel() produces a human phrase — 'peaks Mar–Jun' — plus a state of in-season, rising, steady or off-season.
Also called: seasonal demand · when do people search for barns · busy season keywords · seasonality
- 1refreshSeasonality() batches every non-dismissed universe keyword into one DataForSEO Labs call and stores volume, difficulty, CPC and the 12-month series.
- 2The daily cron runs it whenever the freshest season stamp is older than about a week, so the plan always reflects current demand.
- 3seasonFactor() deliberately weights next month heaviest, because ranking lags publication by three to eight weeks.
- 4seasonLabel() finds the peak month and walks outward while the factor stays above 1.1 to name the whole season window.
- 5priorityNow() = throughput × forward season factor — the single number the queue, the planner and the writer sort by.
The header states it: "Seasonality (Keith 08-20): keywords have rhythms — plan WITH them… The planner looks FORWARD: a post published today ranks in 3–8 weeks, so what matters is the demand one and two months out, not today's." Publishing a piece the month demand peaks is publishing it a month late, and in a seasonal trade missing the window costs a full year.
- Content was planned against today's demand, which is already the wrong month.
- Seasonal peaks were missed by exactly the time it takes a page to rank.
- Nothing recorded when a term's season actually was.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →