Google Trends Seasonality: Scale, Years and Lead Time

When should a snow tire guide go live? The answer is not the date of the first snowfall. It is a date you calculate backwards from the point where interest starts to rise, subtracting the time it takes your team to produce the page and the time it takes your site to be discovered. Google Trends can tell you when interest rises. It cannot tell you your own lead time, and it cannot tell you how many people are searching. If you run a tyre retailer's content calendar, that division of labour is the whole method.

Start with the publishing question

A seasonality study needs a decision to serve. Write the decision first: "By which week must the winter tire buying guide be indexed?" or "From which month do we start the pre-season content series?" A vague question such as "what does demand look like" produces charts, not calendars.

The three inputs

• The shape of interest over the year and across years, which comes from Trends.
• Your production time, which comes from your own team.
• Your discovery lag, which comes from your own Search Console history.

Only the first input comes from the tool. The other two are measurements of your own site. Treating all three as equally important keeps the calendar honest.

What a Trends value is and what it is not

How the data is built

Google's Trends data FAQ (Opens in a new tab) describes Trends as access to a largely unfiltered sample of actual search requests made to Google. The data is anonymized, categorized and aggregated. Only a sample of searches is used, which the page calls sufficient given the billions of searches Google handles per day. The sampling is what allows insights to be processed within minutes of an event happening.

The scale

The page explains the scale in two steps. Each data point is divided by the total searches for its geography and time range, so places with high search volume do not automatically rank highest. The results are then scaled from 0 to 100 based on a topic's share of all searches. Regions with the same relative interest can have very different total search volumes.

Two practical consequences follow. A chart value is not a count of searches, so "the value was 80 in January" does not translate to a number of people. The page does not describe adding or comparing values from two separate charts. Practical suggestion: do not substitute one chart's values for another's, and open terms you want to compare in the same chart and range. Check on the screen what the value 100 refers to in the range you selected. If you use the interface in another language, labels may differ from the English names given.

Not a poll

The page states plainly that Trends is not a scientific poll. A spike does not mean a topic is winning, and the data should be treated as one data point among others. For a tyre retailer, that rules out sentences like "the public prefers winter tires to snow tires" drawn from a chart.

Zeros, noise and filtered searches

Zeros

According to the page, Trends shows data only for popular terms, and low-volume terms appear as "0". A narrow phrase such as the name of one tyre model may therefore appear flat even if a few people search for it.

Noise

Statistical noise is added to protect privacy, and the page says it shows up in queries with low or no interest. Apparent one-off spikes should not be read as real search activity or as evidence of individual searches.

What is filtered out

The page lists what is filtered: very low-volume searches, duplicate searches from the same person in a short period, queries containing special characters such as apostrophes, and searches made by Google products, including AI Mode and AI Overviews. It adds that some irregular activity may remain, so Trends is not a perfect mirror of search activity.

Practical suggestion: when a phrase you care about shows zero, look for it in Search Console queries and in autocomplete suggestions before concluding that it is not searched. Phrases with apostrophes deserve a separate look, since the page says they are filtered.

Time range, time zone and granularity

The same term draws a different picture depending on the range you pick. According to the page, on the Explore page, ranges of 30 days or longer are graphed in UTC at daily, weekly or monthly granularity, while ranges of 7 days or shorter use the viewer's local time zone, with data that is typically hourly.

Choosing a range for seasonality

Practical suggestion: for seasonality, use a multi-year range with weekly or monthly granularity. A seven-day window cannot show the season of a product. A multi-year window shows whether the season repeats at about the same place each year.

Table: Three ranges to try for one term (a suggested routine, not a list from the page)

Why the line wobbles

Practical suggestion: read a wobble as one of four candidates: sampling, noise, low-volume terms showing as zero, or a real change in interest. To tell them apart, open the same term in two different ranges. A wobble that appears in one range and vanishes in the other is probably noise. A rise that appears in the same place in every range is a seasonality candidate.

Comparing the same term across years

Year-over-year comparison is the core of the method. The question is simple: in which week does the rise begin each year, when is the peak period and when does the fall begin?

A step-by-step comparison

1. Pick the term and fix the geography. For readers in one country, a country-level view is enough. Do not mix geographies in one chart.
2. Extend the range to at least three years with weekly or monthly granularity.
3. For each year, note the week the rise begins, the peak period and the week the fall begins. Copy the date range the screen gives you rather than rounding it.
4. Place the notes side by side. If the dates shift, write down the direction and a possible cause such as weather or a promotion.

Odd years

If one year looks very different from the others, find out why before using it. A news event, a weather event or a large promotion may explain it. If you find a cause, keep that year out of the pattern. If you cannot find one, note it as an open question rather than treating it as evidence.

Terms without a season

Not every term is seasonal. A line that draws no clear shape over three years has no season to plan for. In that case switch from timed publishing to steady publishing and updating, and keep such terms in a separate list so they do not take up calendar slots.

Table: Planning by chart shape

Comparing terms with each other

The help page recommends relative comparison to judge the scale of a term, and suggests comparing against well-known terms such as food types, celebrities or the weather. For a tyre retailer, two uses stand out.

Different names for one intent

"Snow tires" and "winter tires" can sit in one chart. The comparison shows which name is searched more in your geography. It does not tell you which name will bring more visitors to your page. Decide the page's wording by looking at the results page for each name.

A fixed reference term

Practical suggestion: use the same reference term in every comparison. A fixed reference works like a ruler and lets you set one product group's observations next to another's. The reference itself should not be strongly seasonal, or it will distort every reading.

What Trends cannot answer

The page also says Google News Lab may share event trends data that is not available in the public tool. For an off-pattern year, the news of that period is the first place to look.

Working out lead time

Trends tells you when interest rises. Your lead time is set by three delays of your own.

Three delays

• Production delay: planning, writing, preparing images and publishing.
• Discovery delay: the time between publishing and the first impression in search results.
• Ramp-up delay: the time between the first impression and visibility strong enough to catch the season.

The values differ from site to site, and Google does not promise a single figure. You have to measure them.

Measuring discovery lag from your own data

Practical suggestion: open Search Console and look at your last handful of new pages. Note each publishing date and the date of the first impression. The spread between those gaps is your discovery lag range. Use the upper end of the range for planning.

Example scenario: a tyre retailer sees that its past three seasonal guides each showed their first impressions some time after publishing, and that the gap varied from guide to guide. The team plans from the longest of those gaps. The date then falls out of simple arithmetic: start of the rise, minus the discovery lag, minus the production time. The numbers come from the site's own records.

Decision rules

• Rise dates stable across years: count back from the rise week using the upper end of the discovery lag.
• Rise dates drifting: count back from the early end of the drift.
• New topic with no comparable page on your site: publish earlier than the arithmetic suggests, because the discovery lag is unknown.

New page or refreshed page

If the season repeats every year, refreshing an existing guide can be a more orderly path than opening a new page each year, since the page has already been discovered. Practical suggestion: open a new page only if the topic itself has changed. Keep the update date visible and measure how quickly refreshed pages regain impressions on your own site.

Cross-checking with the Planner forecast

Google Ads help for Keyword Planner (Opens in a new tab) says forecasts refresh daily, use the last 7 to 10 days of data and are adjusted for seasonality. So the forecast carries a seasonal adjustment. It is still a spend-based advertising forecast, and it should not be read as an organic traffic expectation.

Who answers what

• Trends: the shape of interest through the year and its consistency across years.
• Keyword Planner: a rough relative size for the term and its neighbours.
• Search Console: what your own site actually receives.

Table: When the three disagree

Data freshness

The Trends page gives no update schedule. The only timing statement is that insights can be processed within minutes of an event. Write the date on which you pulled each chart, because the same chart may look different weeks later.

Example scenario: a winter tire season plan

Example scenario: a tyre retailer wants its pre-season content ready before interest starts to climb. The work runs in eight steps.

1. Write the decision: by which week must the buying guide and the how-to pages be indexed?
2. Choose two terms from each of three families. Product terms such as snow tires, question terms about when to switch and problem terms about cold-weather care.
3. Open a three-year chart for each term, same geography, weekly granularity, same reference term.
4. Note the rise week, the peak period and the fall week for each year and each term.
5. Compare the families. If the question terms start to rise earlier than the product terms in your own charts, plan the how-to pages before the buying pages. Do not assume the order; read it from the charts.
6. Measure the discovery lag from the last pages you published.
7. Count back from the earliest rise week: subtract the upper end of the lag and the production time.
8. Fill in the calendar row and write the date the data was pulled.

One row per family

Each family gets its own content type and its own publishing window. Question terms lead to guides, product terms to category and buying pages, problem terms to troubleshooting pages. That keeps all the work from piling up in one week and gives the team a staggered schedule.

After the season

Practical suggestion: when the season ends, check whether the plan held. Did first impressions arrive inside the planned discovery range? Did impressions start rising with interest or after it? Did the rise week move compared with earlier years? Late impressions mean the window was too late or the lag was underestimated. Early impressions mean the window was early, which does no harm but suggests the schedule could be spread out better. Record the findings next to the row, because next year's calendar starts from them.

Reporting seasonality to people outside the team

A screenshot of a chart is not a report. Add a caption naming the term, geography, range and the date the chart was pulled. Say "interest starts to rise in this week" rather than "demand starts in this week", since Trends shows relative interest, not absolute demand.

One sentence for stakeholders

Practical suggestion: summarise the result in a single sentence a manager can act on, such as "The buying guide has to be live a production time plus a discovery lag before the rise week, so production starts on this date." The sentence works without any figure in it, and the team fills in the production time and the lag from their own records.

A seasonality calendar template

Keep one row per product group. Rows describe phases rather than dates.

Content type by phase

• Before the rise: buying guides and comparison pages.
• During the rise: product pages and short how-to content.
• At the peak: updates that answer questions arriving in real time.
• After the fall: a season recap and a note for next year.

This list is a suggestion. The real shape of your season comes from your own data. For picking terms to study in the first place, see Google Trends for content topic selection, and for campaign-period planning, see the seasonal SEO content and link calendar.

Checklist and mistakes

• The term and the geography are fixed.
• The range is at least three years with weekly or monthly granularity.
• The same term was opened in two ranges to separate noise.
• Rise, peak and fall weeks are written down for every year.
• Zero terms were looked up in Search Console and autocomplete.
• Variants with apostrophes were checked separately.
• Discovery lag was measured from recent pages.
• The publishing window was counted back from the rise.
• Conflicts between Trends, Planner and Search Console were explained.
• The calendar row carries the date of the data.

Mistakes to avoid:

• Reading the chart value as a search count.
• Comparing numbers from two separate charts directly.
• Treating one year's spike as seasonality.
• Reading zero as "nobody searches".
• Planning a season from a seven-day window.
• Using Trends as a poll or a scoreboard.
• Setting the publishing date from the peak and forgetting the discovery lag.

Each mistake can be prevented with a line in your template. A "data range" and "updated on" field tells the next reader which chart you looked at. Filling "rise phase" with weeks rather than values breaks the habit of reading numbers as counts. Before you open the tool, write one sentence naming the publishing decision the session will serve. A data pull with no decision behind it does not turn into a calendar.

Reviewing the plan after the season

When the season closes, review the calendar in one short note. The note becomes the first document you read next year and it answers three questions.

Decision rule: if impressions kept climbing after the rise week, move the window earlier next year. If they climbed well before the rise, move it later and check separately whether the early publication cost anything. Do not rebuild the whole calendar from one year of data; add the new year to the earlier three and read the four together.

Example scenario: reading last season's tyre plan

Example scenario: the tyre retailer opens its winter guide plan after the season. The guide went live in the second week of October. Search Console shows the first impressions in the last week of October, and weekly impressions keep rising through November. The Trends line for the main term, read over four years, shows the rise week moving one week earlier in the latest year.

1. The gap between publication and first impression is about two weeks, so the discovery estimate stays at two weeks.
2. Impressions kept climbing after the rise week, so the window moves a little earlier.
3. The one-week shift in the latest year is noted as a candidate, not yet as a trend.
4. The calendar row gets a new date and a one-line reason.

The review takes twenty minutes, and it turns a guess into a record. Each season adds one more observation to the calendar, which makes the next window easier to defend to the people who approve production time.

Review checklist:

• Publish date and first impression date were written side by side.
• The Trends line was read over at least three years.
• A shift of one season was marked as a candidate, not a rule.
• The calendar row carries a new update date.

Frequently Asked Questions

Does a Trends value of 100 mean 100 people searched?

No. According to the help page, each data point is divided by total searches for its geography and time range and then scaled from 0 to 100 based on a topic's share of all searches. The value is relative, not a count.

If a term shows zero in Trends, is nobody searching for it?

Not necessarily. The page says Trends shows data only for popular terms, so low-volume terms appear as "0". Check the phrase in Search Console queries.

Which time range should I use for seasonality?

Practical suggestion: a multi-year range with weekly or monthly granularity. The page notes that ranges of 7 days or shorter use the viewer's local time zone with typically hourly data, a window that cannot show a season.

Why are queries with apostrophes missing from Trends?

The page lists queries with special characters such as apostrophes among the filtered searches, so those variants need checking in other sources.

How many weeks before the peak should I publish?

The documentation names no single figure. Add your production time and your measured discovery lag, then count back from the week interest starts to rise.

Is Trends a poll of what people prefer?

No. The page says Trends is not a scientific poll, a spike does not mean a topic is winning, and the data should be one data point among others.

Does the Keyword Planner forecast show seasonality?

The help page says forecasts are adjusted for seasonality. They are still spend-based advertising forecasts, not organic traffic expectations.

Conclusion

A seasonality plan rests on three steps: reading the relative scale correctly, testing consistency across years and counting the publishing date backwards through your own delays. For the snow tire calendar, Trends supplies the shape of the season, Search Console supplies your site's discovery lag and the template ties the two to a date. The result is a calendar built on measurement instead of a hunch about when winter starts.

When the calendar says it is time to produce the pre-season guides, plan the writing early. If you would like help turning the calendar into researched, well-sourced articles, have a look at our content writing service.