The year in the slug: not wrong today — wrong next year

A year in the slug is not wrong today — it is wrong next year: the text gets updated, but the address stays locked in the publishing year, and every January makes you choose between an address that lies and a move with a redirect. Pages with the year in the address rank very well — we measured it. The problem is not today's ranking, it is what you do in January: either you let the address say 2026 on a text from 2027, or you move it — and whoever moves every year ends up with redirect on top of redirect. Put the year in the title and in the article date, where it can change — never in the slug, where any change means moving the address. And for the articles that already have it, there is one rule: do not rename them on reflex; move each one once, with a permanent redirect, when you are revising its content anyway.

How the year ends up in the slug

Because it works in the short term. A title like "The complete guide for 2026" tells the reader the text is fresh, and at publish time the slug gets generated from the title — year included. Nobody decided to put the year in the address; the system left it there.

The problem shows up in January. You change the title in a minute. You update the article date. But the address …/complete-guide-2026 stays, and now it says something false about a text that is true. Google recommends simple, descriptive, stable addresses — their documentation on URL structure↗ insists on relevant words and on avoiding parameters and noise, not on time markers in the address. A year is precisely a time marker that expires.

What the address says and what the content says — two different things

An address is an identifier. Content is a claim. When you tie them together through a year, you force the identifier to change every time the claim ages — and every identifier change is a migration with its costs: a redirect, internal links to rebuild, signals that transfer with a delay.

The rule we apply on our own site and on our clients' sites:

• The year in the title (H1) and in the SEO title — that is where people see it and where Google shows it in results; that is where it updates in a minute.
• The year in the publish date and the modified date — that is where search engines read it as a freshness signal.
• Never in the slug. The slug carries the subject, not the moment.

Our own case:14 out of 161

We counted them today, on our own site: 14 out of 161 Romanian articles have the year in the slug — "how much an online store costs in Romania 2026", "core update 2026", "Google AI Mode SEO 2026" and the rest. That is not a scandal; it is the history of a convention we corrected along the way. It is, however, a textbook case for the question in the title: what do you do with the articles that have it?

The answer is not "rename them all tomorrow". The answer is a rule with three conditions.

The rule for existing articles

1. Do not touch what ranks just to make it "clean". An address that brings traffic is an asset. A measured example from a client in construction (September 2026): their highest-traffic organic page has the year in the address — and ranks for queries that contain no year at all. It works, so it stays exactly as it is; the rule below is for the day its text gets rewritten, not for today. A cosmetic rename changes the identifier of a page that works — and every migration, however correct, goes through a period where signals settle again. If the article ranks and is current, leave it; at most, drop the year from the title at the next revision.

2. Move once, with a 301, when you are revising the content anyway. When an article with a year in the slug reaches its annual revision — the text gets rewritten, the figures get updated — that is the moment: the new address without the year, and a permanent redirect from the old one. Google states explicitly that the permanent 301 redirect↗ is the signal it uses to understand that a page has moved for good and that the new address is the canonical one.

3. A migration is complete or it is not a migration. A correct move touches, on the same day: the redirect, the internal links that pointed to the old address (so they do not all pass through the redirect), the canonical of the new page, the sitemap and, where one exists, the counterpart in the other language. The thing most often forgotten: internal links. A site that sends itself through its own redirects pays an unnecessary hop on every click.

And one prohibition: never a chain. If …-2025 already redirected to …-2026, the new address without a year gets a direct redirect from both, not a cascade.

What we are doing with our 14

We treat them exactly by the rule above. Each of the 14 enters the annual revision when its turn comes; then it gets the address without the year, the redirect, the rebuilt internal links and the updated sitemap — one move per article, with Search Console data in front of us, not all at once overnight. We are publishing this article before the migration precisely so it is visible that the rule applies to us first.

The annual revision — this is where an evergreen article lives

An evergreen text lives through dated revision, not through a new address. Revision means: figures updated with their source, outdated sections cut, the modified date set to the day of the revision, and the title — if it carries the year — updated. The address does not move. That way, every year adds trust to the same page instead of splitting the history between two.