How do you separate seasonality from a real SEO change?

To separate seasonality from a real SEO change, measure a page against pages you left alone over the same calendar days and read the gap. Seasonality is a pattern in search demand that repeats on the calendar, so a seasonal swing in clicks is not evidence that a change worked or failed.

• Google suggests setting the Search Console date filter to the last 16 months to see whether a drop recurs yearly because of a holiday or trend (Google, Search Central, read 30 October 2026).
• Search Console retains the most recent 16 months of data, which leaves only the newest 4 months (16 minus 12, our arithmetic) open to a same-date comparison with a year earlier (Google, Analytics Help, read 30 October 2026).
• Penlid's content decay check sets a page's last 28 days against the 84 before them, then subtracts the rest of the site's move over the same days (Penlid, content decay check, read 30 October 2026).
• Penlid gives no decay verdict for a page under 3,000 impressions in the trailing 90 days (Penlid, methodology, read 30 October 2026).

What counts as seasonality in SEO data?

Seasonality in SEO data is any rise or fall in clicks or impressions that repeats on a calendar rhythm: weekly, monthly or yearly. Google's debugging guide says demand for queries can shift with a new trend or with seasonality over the year, and that seasonality differs by industry. A season moves many pages at once, so it lands in the same weeks as your edits and can be mistaken for their effect.

How can you see a season in your own Search Console data?

Set the date filter to the last 16 months and look for the same rise or dip at the same time each year. The first three rows below come from Google's debugging guide; the fourth, other pages on your own site, is the one this guide builds on.

Sixteen months is one year plus four months, so only 4 of the 12 calendar months appear twice and the other 8 appear once (our arithmetic); a bump in one of those 8 has no second year to be compared with. To go past 16 months, Google says you could use the Search Analytics API or bulk data exports to pull the data and store it in your own systems.

How does comparing a page with the rest of your site take a season out?

Comparing a page with the rest of your site takes out the part of a season that hits every page alike, because both are measured over the same calendar days. Penlid's content decay check works this way: it sets a page's last 28 days against the 84 before them and subtracts the rest of the site's move over the same days. Without that, our methodology says, every page on a site looks like it's decaying every January. The tool page puts the result in one line: a January dip that hit everything reads as healthy, and a page that fell while the rest of the site held does not.

The decay check's page says Search Console's own Download CSV export does not produce the day-by-day table the tool needs (Date and Page columns, one row per page per day), but a Data Studio (formerly Looker Studio) table or a Search Analytics API query does. Ask for at least 112 days (28 + 84).

The same idea judges a change you made on purpose. If you know which page you changed, the did-it-work check reads the same export plus a list of what you changed and when; see how to tell if a content update worked. The estimator behind it was tested on simulated sites where nothing was done to the page. Across 675 such scenarios, which included site-wide moves of −30%, none and +50%, a change was called significant 3.26% of the time on average when the estimator runs alone, where a 95% test allows 5% (methodology).

Why must the comparison use the same calendar dates?

A window's place in the calendar decides which part of a season it catches, so every page must be summed over identical dates. The decay check's page explains the trap: Search Console leaves out a page's row on days it got nothing, so counting "the last 28 rows" spans four weeks on a busy page and four months on a quiet one. Penlid's check sums every page over identical calendar days instead, and a missing day counts as zero.

Weekdays need the same care: when comparing two date ranges, Google says aggregating by week or month neutralizes the day-of-the-week effect. A 30-day window is 28 days plus 2, so two weekdays appear five times and the other five appear four times. The decay check's windows of 28 and 84 days are 4 and 12 whole weeks, so each weekday appears equally often (our arithmetic).

What can still pass for a season, or hide behind one?

Four things can still fool a same-days comparison: uneven exposure, a Google update in the same weeks, pages picked because they were low, and data errors.

• Uneven exposure. The baseline is the rest of the site, so a page whose season is sharper or flatter than the site's keeps the difference; Penlid's methodology notes that a season hits one page more than another. Our reasoning: such a page can read as decaying after every peak, so give it comparison pages that share its topic; the guide to control pages covers choosing them.
• A Google update in the same weeks. A comparison among your own pages cannot separate two causes that both reach the whole site; see how to measure what a Google update did to your site.
• Pages picked because they were low. A page chosen for a seasonal trough is a page chosen for decline. In Penlid's simulations, pages whose last 28 days sat at least one standard deviation below their own average, then left unchanged, came back "improved" 5.50% to 9.20% of the time, against at most 3.10% otherwise (methodology). See regression to the mean.
• Data that changed underneath you. Google lists a logging error that left impressions, CTR and average position inaccurately reported from May 13, 2025 to April 27, 2026; clicks were not affected (Google, Search Console Help). Our reasoning: a year-over-year comparison of impressions with one side inside that period and the other outside it compares unlike data, so read clicks.