PLAYBOOK
The busy season is coming.
Get the site ready first.
Seasonal search is unforgiving. The demand arrives on a schedule you can't move, and a page that isn't ranking when it starts won't catch up before it ends. This playbook works backwards from the peak, so that the pages, the site and the tracking are ready weeks ahead.
The page still shows last year's dates.
Your busiest period comes round every year, and every year the preparation starts too late. Last season's page still shows old dates. Nobody can remember when searches began to climb, or which pages brought in the orders. By the time the new page is live, the peak is half over.
"We should have started on this a month ago."
Search engines need time to crawl and rank a page. Work done in the final fortnight mostly arrives too late.
"Which pages did the work?"
Without a record, you rebuild from scratch and repeat last year's mistakes.
"There's a code freeze before the peak."
Then every fix has to be in before the freeze, which moves your deadline earlier still.
Work backwards from the peak.
The dates below are a rule of thumb. What matters is the order, and starting earlier than feels necessary.
Find out what happened last year
Which pages and searches brought the traffic, and the date it began to rise. Search Console history goes back 16 months, so last season is still there.
Search Console analytics →See when demand starts
The 12-month trend for a keyword shows the month searches begin to climb. That month, less a few weeks, is your deadline.
Search volume and trends →Update the pages, keep the URLs
Bring last year's pages up to date on the same addresses. A new URL each year throws away the links and history the old one earned.
Optimise existing content →Make sure nothing is broken
Crawl the seasonal pages. Fix redirects, missing tags and slow pages before any code freeze.
Site audit →Performance →Free: Redirect chain tracer →Follow it as it happens
Track positions as the peak approaches and watch visits live once it starts. Then write down what worked, for next year.
Real-time analytics →Test last year's URLs today.
Put last year's seasonal URLs through the bulk status checker, then trace any that redirect. Any that end in an error, or take more than one hop, go on the list.
Each stage, with the demo account.
Ledgerly is our demo account, a B2B accounting tool for agencies. Its peak is the end of the tax year, when agencies rush to send final invoices.
Last year already told you what to do.
Most of the answers are in your own data from last season. The work is going back to read them before you plan anything.
- The pages that brought the visitsAnd the searches behind them, from Search Console.
- The date it beganUsually earlier than people remember.
- A trend for each keywordTwelve months of search volume, for the country you choose.
Same URL, fresh page.
The commonest seasonal mistake is publishing a new page every year. Each one starts from nothing, and last year's is left to gather links nobody uses.
- One address, kept for goodUpdate it each year. Drop the year from the URL if it has one.
- Updated content and datesBrought in from the live page and fixed issue by issue.
- Supporting pages, briefed earlyGuides and comparisons that answer what people ask before the peak.
Find the faults before the freeze.
A broken redirect or a slow page costs most on the days with most traffic. Those are also the days nobody is allowed to deploy a fix.
- A crawl of the seasonal pagesStatus codes, redirects, titles and schema.
- SpeedCore Web Vitals, tied to the cause on each page.
- Old seasonal URLsRedirected to the current page, in one hop.
- Safe fixes, appliedAutoFix handles the ones with one correct answer.
Watch it live, then write it down.
During the peak there's little you can change. The value is in seeing what happens clearly enough to do better next year.
- Positions in the run-upSo a slip is noticed while there's still time.
- Visits as they arriveReal-time analytics during the busiest days.
- Notes for next yearMark the key dates on the chart, and record what you'd start earlier.
A countdown you can adapt
| When | What to do | Why then |
|---|---|---|
| About 12 weeks before | Review last year. Decide which pages to update and which to write. | New pages need time to be found and to rank. |
| About 8 weeks before | Publish the updated pages and any new supporting content. | So they are crawled and settled before demand rises. |
| About 6 weeks before | Crawl the seasonal pages and fix what's broken. | Before any code freeze begins. |
| About 2 weeks before | Check positions and internal links to the seasonal pages. | Late changes should be small and safe. |
| During the peak | Watch. Change as little as possible. | A mistake now costs the most. |
| Straight afterwards | Record what worked. Keep the pages live. | The page carries its value into next year. |
These timings are a rule of thumb. Competitive categories and brand-new pages need longer.
Two ways the same season can go.
Same business, same demand. The only difference is the date the work began.
Starting three weeks out
- –A new page on a new URL, with no history
- –Last year's page still live, with old dates
- –Faults found during the code freeze
- –No record of what worked, again
Starting three months out
- ✓Last year's URL, updated and already ranking
- ✓Supporting pages live before searches rise
- ✓Faults fixed with weeks to spare
- ✓Dates and results written down for next year
Any business with a busy season.
How do you prepare a site for seasonal search?
Start about three months before the peak. Look at last year's data to see which pages and searches brought the traffic and when it began. Update those pages on the same URLs, publish any supporting content early, and crawl the seasonal pages for faults before a code freeze. During the peak, watch and change little. Afterwards, record what worked and keep the pages live for next year.
Key facts
- A page that isn't ranking when the season starts rarely catches up before it ends
- Keep one permanent URL for each seasonal page and update it yearly. A new URL every year starts from nothing
- Search demand usually begins to rise weeks before the peak itself
- Technical fixes need to be in before any code freeze
- SEORCE shows a 12-month search trend for each keyword, and holds 16 months of your Search Console data
- No preparation guarantees a position. It removes the avoidable reasons for missing out
Last reviewed 15 October 2026 by the SEORCE team.
Frequently asked questions.
About three months for most businesses. New pages need time to be crawled and ranked, and technical fixes have to be in before any code freeze. Competitive categories need longer.
No. Keep one permanent URL and update it every year. A new address each year starts with no links and no history, while last year's page keeps the value it earned.
Update them if they are on a permanent URL. If the address has a year in it, redirect it to a permanent one and build from there.
Look at the 12-month trend for your main keywords in Keyword Explorer, and at your own Search Console data from last year. Demand usually starts climbing weeks before the peak.
No. Leave them live all year, with a short note that the event has ended. Removing them loses the links and rankings you'll want next time.
Keep them small. A change that goes wrong during your busiest days costs more than it could gain. Use the peak to observe and take notes.
Yes. The bulk HTTP status checker shows whether old seasonal URLs still resolve, and the redirect chain tracer shows where each one ends up. Both are free.
See what last season already told you.
Add your site and connect Search Console. Last year's peak is in the data, along with the pages that carried it.
Not ready for an account? Use the free browser extension or any of the free tools.