Should I put the year in a WordPress post slug?
No. A year in the slug makes the address wrong every January, and fixing it means moving the URL and waiting for search engines to catch up. Keep the year in the title, where you can change it in seconds, and publish under a slug that will still be true in five years.
How the year gets into the slug
Usually by accident. WordPress builds the slug from the title at the moment you publish and keeps digits, so "Best Budget Laptops for Students (2026)" becomes /best-budget-laptops-for-students-2026/. Nobody chose that; it is simply what the title said.
Stop it at the source. Before publishing, open the slug field in the editor sidebar and delete the year: /best-budget-laptops-for-students/. From then on the slug is saved, and WordPress will not regenerate it when the title changes. That last point is what makes the whole approach work: core treats the title and the slug as separate fields once a post is live.
Why the title is the right place for the year
A year in the title earns clicks. It tells a searcher the list is current, and people do add the year to queries for things that change: prices, tools, tax rules, rankings. So use it there, and in the H1 and opening lines.
Then, each time you update the article:
- Revise the content so the new year is deserved. Changing a number without changing the page is the kind of fake freshness Google's guidance on dates warns against.
- Edit the title and heading to the new year.
- Leave the slug untouched.
The address keeps its links, its history in Search Console and its place in results. One URL accumulates years of signals instead of each year's version starting again from nothing. Our guide to refreshing old posts has the full routine.
When separate yearly URLs are right
Some content really is a new document each year, and the old one stays worth reading:
- an annual report, survey or benchmark with that year's data;
- a conference or event page for a specific edition;
- "year in review" posts;
- rules that applied in a given tax or model year and are still looked up later.
For these, a year in the slug is accurate and permanent, so keep it. Link the editions to each other, and consider a year-free hub (/state-of-email/) that always points to the latest edition so there is one stable address to link to and rank.
The test is simple: next year, will this page be replaced or joined? If replaced, no year in the slug. If joined, a year is fine.
What to avoid is the middle path where a "best of" list is republished as a fresh post every year. You end up with /best-laptops-2024/, /best-laptops-2025/ and /best-laptops-2026/ competing for the same query, the textbook case of keyword cannibalization.
Fixing posts that already have a year in the URL
If the post is ranking and the year is merely out of date, you have two honest options.
Leave it. The title can say 2026 while the slug says 2023. It looks slightly odd, and it works. Search engines rank the page, not the digits in its address.
Move it once. Change the slug to the year-free version and make sure the old address answers with a 301. For posts, WordPress remembers the old slug and redirects it without help; Hydrogen SEO's Auto Redirection in the Redirection Manager adds an explicit rule you can see and edit, and covers pages too. Then update internal links to the new address. Do this once, to a slug with no year, so you never have to do it again.
If several yearly versions already exist, pick the strongest, merge anything worth keeping from the others into it, and redirect the rest to it.
Common questions
Does a year in the URL help rankings for "2026" searches?
There is no evidence it does. The title, heading and content carry that signal, and they are the parts you can keep current without moving the page.
Is it misleading to update the year in the title?
Only if the content has not been reviewed. Update the page first, then the year, and keep the visible "updated" date truthful.
What about years in category or tag slugs?
The same logic applies. A tag like "2026 reviews" has to be replaced every year, and WordPress does not redirect changed term slugs by default.