PubTrivia has 79 URLs in its sitemap. Until last week, not one of them contained a date, and that was deliberate: the question pages are written so they never need revisiting, and the hub that lists them runs on a rule I will paraphrase as nothing that changes.
Then we published a review of the year quiz for 2026, which is 402 lines of page file containing the string 2026 sixty-nine times. This is what it took to let one dated page into a cluster built to avoid them, and what the first week of January is now going to cost.
The rule, and the loophole in it
The rule is not "no dates", it is "no claim that will quietly become false". The difference is where the date sits in the sentence. The page's own doc comment puts it better than I can paraphrase it:
Every question names its year or its date. "Who became the youngest F1 champion in 2026" stays true after a younger one comes along; "who is the youngest F1 champion" would not.
That is the whole admissibility test, and it is a test on the grammar of each line rather than on the topic of the page. A page of superlatives decays. A page of dated facts does not, which is why an almanac from 1954 is still correct and a "best of" list from last March is not.
Two consequences follow immediately. Every single question on the page had to be rewritten into the dated form, which is tedious and occasionally awkward. And the page can only cover a window that has actually happened: this one runs January to the start of November, and the comment tells the next person what to do if December gets added later, which is to bump one field in the registry.
The year is typed in five places outside the body
Every public page on this site comes from a node in one registry file, and the node is where a page's identity lives. For this one, the year appears in five of its fields:
{ path: '/quiz-questions/review-of-the-year-2026', title: 'Review of the Year Quiz 2026 with Answers', shortLabel: 'Review of 2026', heading: 'Review of the year quiz 2026', description: 'Sixty review of the year quiz questions for 2026 with answers, in six rounds: ...', cluster: 'quiz-questions', updated: '2026-11-04', related: ['/quiz-questions/christmas', '/quiz-questions/sport', '/quiz-questions/music', '/guides/pub-quiz-round-ideas'], } That is the slug, the <title>, the breadcrumb label, the <h1> and the meta description, each with the year in it, all written once. shortLabel exists for a reason that only shows up on dated pages: the title tag wants to be "Review of the Year Quiz 2026 with Answers" because that is what somebody types into a search box, and a breadcrumb trail wants four words. On the live page the trail reads Home, Questions, Review of 2026, and the BreadcrumbList in the JSON-LD says the same three names, because the visible trail and the structured data are generated from one function.
Everything else the node earns for free: the entry in sitemap.xml with lastmod taken from updated rather than from the build clock, the four reciprocal links at the foot of the page, and the listing on the questions hub. The only inbound related edge from a sibling comes from the Christmas page, which is the right neighbour for it: the two get used in the same fortnight.
Four freshness claims, all of them dated on purpose
A dated page has to be louder about its own provenance than an evergreen one. This one makes four separate claims, and they agree:
| Claim | Where | Value |
|---|---|---|
lastmod | sitemap.xml | 2026-11-04 |
datePublished and dateModified | Article JSON-LD | 2026-11-04T00:00:00Z |
| "Last reviewed" | visible, in a <time> element | 4 November 2026 |
| "checked against published reports in" | a sources box at the foot | November 2026 |
The visible line and the Article node both come from one boolean on the page component:
<ContentPage path="/quiz-questions/review-of-the-year-2026" article ...> 34 of the pages on the site set it. It is what turns a marketing page into a thing with an author, a publisher and a modification date, and it is deliberately not on pages like the pricing page, where a "last reviewed" date would be a liability rather than a reassurance.
The sources box is more unusual, and this is the only page in its cluster that has one. Ten official pages are listed by name, all of them rendering as rel="nofollow noopener" target="_blank", with the month they were checked in. The honest reason for it: the body contains sixty answers about recent events, and an answer that turns out to be wrong is a bad night in a pub rather than a bad paragraph on a website. The box says, in effect, here is where I got this, tell us before your quiz rather than after it.
January, and why it is a new URL
The tempting move next December is to edit this page: swap the sixty questions, change 2026 to 2027 in five fields, bump updated, and let the URL keep whatever authority it has accumulated. One line in the doc comment rules that out:
Next year's page is a new path (review-of-the-year-2027), not an edit of this one, so this year's quiz keeps working for anyone who bookmarked it.
The argument against editing in place is not an SEO argument, it is that the URL says review-of-the-year-2026 and somebody who saved it in January wants the 2026 quiz. Editing the page makes a liar of the address. It also makes a liar of dateModified: a page whose headline says 2026 and whose modification date says December 2027 is making two incompatible claims about itself, and a crawler is entitled to believe either one.
The cost of doing it properly is one node, one page file, and a decision each year about what links to what: next year's edition is the one the hub should feature, and this one becomes an archive page that still answers 200. The registry makes the mechanics cheap, which is exactly why the decision has to be written down in a comment rather than left to whoever is holding the keyboard in December.
Check it yourself
Compare the trail and the tab on the 2026 page: the browser tab says "Review of the Year Quiz 2026 with Answers", the breadcrumb says "Review of 2026", and the BreadcrumbList in the page source agrees with the breadcrumb rather than with the tab.
Then line the dates up:
$ curl -s https://pub-trivia.app/sitemap.xml | grep -A1 'review-of-the-year-2026' <loc>https://pub-trivia.app/quiz-questions/review-of-the-year-2026</loc> <lastmod>2026-11-04T00:00:00.000Z</lastmod> That date is not the build date. 75 of the other 78 URLs carry their own midnight timestamp, taken from the day that page's content last changed, which is the only thing a lastmod is worth saying. The three exceptions are the privacy, terms and cookie pages, which have no registry node and fall back to the clock, and they give themselves away: they are the only three dates in the file with a time of day in them.
