An SEO recommendation expires when the evidence, the cause or the remaining upside behind it has changed, not when it reaches a certain age. As of 14 October 2026, Search Engine Land has made this argument in print, and I agree with it. The fix is a small habit: store each recommendation with its evidence and a review date, and re-check it before any engineer or writer spends time on it.
Key Takeaways
- A ticket can be both well written and wrong, because the site, Google or your own roadmap moved after it was filed.
- Search Engine Land's 13 October 2026 piece by Bharath Ravishankar gives three tests: does the diagnosis hold, is the action still the best response, does the remaining opportunity justify the cost.
- Different recommendation types go stale at different speeds. Template and navigation fixes can expire within weeks; evergreen content advice lasts longer.
- Closing an outdated ticket is productive work, not a failure.
- A one-page "recommendation record" and a three-tier review cadence is enough for most teams.
What Search Engine Land actually argued
Ravishankar's article, "Your SEO recommendations have an expiry date", was published on Search Engine Land on 13 October 2026. His claim is that recommendations often become outdated before they are implemented: the original problem, fix or payoff may have changed by the time engineering acts. He says there is no universal point at which a recommendation becomes too old; the test is whether the reasoning still holds.
He gives examples I found useful. A faceted-navigation ticket sat for four months, and a navigation change in the meantime removed many crawlable combinations, so the issue might persist at a smaller scale or from a different source. Two pages that once competed may now have distinct search roles, undermining a merge recommendation. A proposed "CRM for startups" page may be unnecessary if the existing CRM page now captures those queries. An internal-linking module may matter less once new navigation brings category pages closer to the homepage.
The article does not prescribe a review schedule. That gap is what this post fills, with my own template. The cadence below is my suggestion, not his.
Why SEO tickets go stale so quickly in 2026
Three forces make 2026 worse than a few years ago.
- Your site changes. Migrations, redesigns, navigation tweaks and template releases alter what an audit found.
- Google changes. In the last six weeks alone, there were spam-update phases, new reporting and heavy changes in how third-party tools collect data. If you have not read it, I wrote about the September 2026 spam update and what to do next.
- Your evidence changes. I wrote this week that rank trackers are struggling, so a ticket that says "keyword X dropped 12 places" may rest on data that was wrong at the time.
Google's own Search Console documentation makes the same point for its automated suggestions: the Recommendations feature says suggestions are refreshed regularly, so they can expire or change over time, and acting on them is optional. If Google tells you its own recommendations expire, your audit from March certainly can.
Expiry classes: how fast does each type go stale?
This table is my own working model, built on the categories Ravishankar names as most likely to go stale. Treat the review windows as starting settings to tune, not facts.
| Recommendation type | Typical expiry trigger | Suggested max age before re-verify |
|---|---|---|
| Technical fix tied to a template or navigation | Release, migration, navigation change | 4 weeks, or after any release touching it |
| Crawl or indexing issue | Site structure change, robots/CDN change | 4 weeks |
| Page consolidation or merge | Pages developing distinct intent or visibility | 8 weeks |
| New page proposal | Existing page absorbing the target queries | 8 weeks |
| Internal-linking project | Architecture change | 8 to 12 weeks |
| Content refresh | Search results layout or competitors changing | 12 weeks |
| Schema or structured data | Google documentation change | Check on each Google documentation update |
| Platform-claim advice ("Google now supports X") | Rollout status, region, account type | Before each use |
The last row comes from a separate piece of research. João Queirós wrote on 9 September 2026 that launch statements get superseded. His example: Google's June 2026 generative-AI reporting announcement had a limited rollout, and an update dated 31 August reported a worldwide rollout, so someone reading only the launch text could keep an outdated availability conclusion while citing a correct URL. He also notes that availability is not account access. He cites Google's June 2026 announcement of the reports; when I opened that page I could see the title and month but not the body or the 31 August update note, so treat that rollout detail as his reporting, unverified by me. PPC Land's coverage says Google announced the reports on 3 June 2026 and was rolling them out to a subset of sites at that point, which is exactly why a launch-day claim needs a date. That is a single author's proposal, not a standard, but the underlying habit of dating volatile claims is sound.
A recommendation record you can paste into any ticket
Most stale tickets lack one thing: the evidence. Add this block to every recommendation.
- Claim: what is wrong or what to do, in one sentence.
- Scope: which URLs, templates, countries, devices.
- Evidence: the crawl, log, Search Console view or SERP snapshot, with a link and a date.
- Source tool and its reliability: note if the evidence came from a rank tracker, a sampled tool or a first-party source.
- Filed on / evidence date: two dates, because they differ.
- Review by: a date from the table above.
- Expected upside: the metric and a range, not a promise.
- Cost: engineering days or writer hours.
- Status: open, verified, re-scoped, superseded, closed.
When a ticket is superseded, link the successor ticket and keep the old one. Queirós suggests keeping earlier versions so you can explain what changed; I do the same.
The eight-question pre-implementation check
Ravishankar's article summarises a checklist that I have adapted into questions to answer in the ticket before work starts:
- Can we reproduce the original problem today?
- Is the same cause still responsible?
- Has the scope changed?
- Has something else already solved part of it?
- Is the proposed action still the best response?
- How much opportunity remains?
- What happens if we do nothing?
- Would we prioritise it if we found it today?
If the answers still support the work, ship it. If not, re-scope, change the solution, deprioritise or close.
A review-by date on each ticket turns "the backlog" from a graveyard into a queue.
A three-tier review cadence
Here is the cadence I would run for a small team. It is a suggestion based on my own practice, not a published standard.
Weekly (30 minutes): the top of the queue
Take the next five tickets that will be picked up. For each, answer questions 1 to 3 of the check. Anything you cannot reproduce goes to "needs re-verification" and is not assigned.
Monthly (90 minutes): the full open list
Sort by "review by" date. Re-verify anything overdue. Check platform-claim tickets against the current official page. Close or merge duplicates. I do this on the first Monday, together with the habits in my weekly review routine.
Quarterly (half day): the strategy tickets
Re-run a sample crawl and compare with the last quarter. Ask question 8 for every large item. Retire anything that would not make the list if found today. For an edtech or course-site example of what a quarterly audit looks for, see my edtech site audit after the spam update.
Event triggers that override the calendar
Do not wait for the cadence when one of these happens:
- A site release touching templates, navigation or URL structure.
- A migration, CDN or robots change.
- A confirmed Google update or a change in Search Console reporting.
- A tool vendor posting a data incident (Search Engine Roundtable's 12 October roundup of tracker problems lists several).
- A change in your target market or product.
On any trigger, re-verify every open ticket whose scope touches the change.
How to re-verify quickly
You do not need a full audit for each ticket. Ravishankar says as much: check each old recommendation before implementation, not rerun a full audit every time a ticket reaches the top.
- Crawl issues: re-crawl only the affected section.
- Indexing issues: check the URL in Search Console's inspection tool and the page indexing report.
- Content ideas: search the target query and see whether your own pages already appear for it.
- Internal linking: compare click depth for the affected pages today with the figure in the original evidence.
- Performance claims: re-pull Search Console data for the same date range, then for the latest range.
Handling stakeholder pushback
Closing tickets will annoy someone who spent time writing them. Three lines help:
- "The ticket was correct when filed. The evidence has changed, here is what changed."
- "We are closing it, not rejecting it. If the evidence returns, we reopen with a link."
- "The time saved goes to [named ticket], which has current evidence."
Ravishankar argues that closing outdated tickets is not wasted work because it prevents spending resources on problems that have already changed. That framing has helped me with engineering teams, who tend to dislike chasing ghosts more than anyone.
The other kind of expiry: pages that should end on purpose
Not every expiry is about advice. Time-limited offers, admission windows and event pages have a true end date, and Google supports a signal for it. Its robots meta tag documentation says the unavailable_after rule tells Google not to show a page in results after a set date and time, that an invalid date is ignored, and that Googlebot slows crawling of the URL significantly afterwards. Search Engine Journal reported on 29 July 2026 that Google's Gary Illyes was unsure what happens when the date is repeatedly extended: his gut feeling was that extending is fine, but Google must recrawl the page to see the new date, and the renewal case remained unresolved. So if you use it for rolling cohort pages, put the date in your recommendation record and re-check the page after each renewal.
An honest limit
A review cadence will not make your recommendations right. It will make them fresh. A recommendation can still be wrong for reasons unrelated to age: bad data, misread intent, a misunderstood template. And the review costs time. If your backlog has fewer than ten live tickets, the weekly tier alone is enough.
Frequently Asked Questions
How long is an SEO recommendation valid?
There is no universal shelf life. Ravishankar writes that there is no point at which a recommendation automatically becomes too old; the question is whether the reasoning still holds. As a starting rule, I re-verify template and crawl fixes within four weeks.
Which SEO recommendations go stale fastest?
Technical fixes tied to templates, migrations or navigation, plus crawl and indexing issues affected by site structure changes. Consolidation and new-page proposals also go stale when pages change roles or existing pages absorb the demand.
Do Google's own Search Console recommendations expire?
Yes. Google's documentation says recommendations are refreshed regularly, so they can expire or change, and acting on them is optional. They appear only when the data shows something noteworthy.
Should I rerun a full audit for every old ticket?
No. Re-verify the specific evidence behind the ticket: recrawl the affected section, re-pull the relevant data, and check whether something else already solved it.
What should every SEO ticket include?
The claim, scope, dated evidence, evidence source, a review-by date, expected upside, cost and status. The dates are the part most teams omit.
How do I stop a backlog from becoming a graveyard?
Give every ticket a review-by date, run a weekly check on the next five items, and close or supersede anything that fails the eight-question check. Keep the old ticket linked to its successor.
Is closing an outdated ticket a waste?
No. Ravishankar argues it prevents spending resources on problems that have already changed. The work is the verification.
How does this apply to AI search recommendations?
Platform features and rollouts change quickly. Queirós recommends dating each volatile claim and rechecking availability before use, and notes that global availability does not prove your account has data.
Can I automate the review?
You can automate reminders and re-crawls. Keep a human on the decision about whether a diagnosis still holds. If you use agents for part of it, give them the dated record and require them to flag unverifiable claims as unresolved.
Who should own the review cadence?
One named person, usually the SEO lead or the project manager who runs the backlog. Shared ownership usually means no ownership.
CTA
I am Younus Fardeen, an SEO and AEO strategist with 4+ years of marketing experience across edtech and startup teams. If your backlog needs a review, or you want help setting up a recommendation record and cadence your team will actually follow, see my work and contact me through the form at https://younusfardeen.in.
Want help with search and AI visibility for your own site? Get in touch through the contact form.