Affinero

Blog

Translate the slug at launch, or leave it alone for good

GENERATED · 869 words · EN→FI ✓

Most decisions about a second language can be revisited. The words in the URL are the exception. Whether your Finnish pages live at a Finnish address or an English one is a choice you can make cheaply exactly once, before the first post goes out, and every month you wait raises the price of changing your mind. So make it at launch, and once the archive exists, leave it alone.

Google prefers your audience's language, and says how little it matters

Start with what Google actually recommends, because it cuts against us. Its URL structure guidance says to use words in your audience's language in the URL, with German words for German searchers and Japanese words for Japanese ones. The multi-regional guidance agrees that localized words in the URL are fine, provided they are UTF-8 encoded and escaped properly when you link to them.

Our Finnish posts do not do this. They live at addresses like /fi/blogi/site-search-shows-the-gaps: the section name is Finnish, the slug is English. On the face of it, we are ignoring the documentation.

The same documentation tells you what that costs. Google's SEO starter guide puts it plainly: from a ranking perspective, keywords in the domain or URL path "have hardly any effect beyond appearing in breadcrumbs." A translated slug is a courtesy to the reader, visible in the breadcrumb and in a pasted link. It is not a ranking lever, and anyone selling it as one is selling the wrong thing.

What a translated slug really buys

The courtesy is real, and we concede it. A Finnish reader who sees an English phrase in the breadcrumb under a Finnish title gets a small signal that the page started life somewhere else. A link shared in a Finnish Slack channel reads as foreign before anyone clicks it. For a company whose argument is that the second language should be written natively rather than translated, that is not nothing.

There is also a cost on the other side that rarely gets mentioned. Our slug is shared across both locales, which means the English and Finnish versions of a post are paired by construction: same slug, two paths, and the hreflang annotations that tell Google which page answers which language are generated mechanically from that. Translated slugs break the pairing. Each locale needs its own stored slug, the alternates have to be joined by an id rather than by the address, and every place that builds a link, from the sitemap to the language toggle, has to know the difference. It is solvable. It is also one more thing an automated engine can get wrong on every page at once.

So the trade is a readable breadcrumb against a more fragile system. Reasonable teams land on either side. What is not reasonable is landing on one side, publishing for a year, and then switching.

Changing your mind costs a redirect per page, per locale

Once a page is indexed and linked, its address is a promise. Change it and you owe a redirect from the old one, and Google's site move documentation says how long: keep redirects for as long as possible, generally at least a year, and from the user's point of view consider keeping them indefinitely. The same page asks you to update your own internal links and the high-volume external ones, because redirects are slow for readers.

Run that across an archive. Translating the Finnish slugs on the 48 posts that came before this one would mean 48 permanent redirects, 48 rewritten hreflang pairs, a sitemap rebuild, and a pass through every Finnish body that links to another Finnish post. All to change a breadcrumb that Google says barely matters to ranking. Every post published before the switch adds to the bill, which is why the cheapest moment is the one before the first post and the second cheapest is never.

Why we chose English slugs, and why we are keeping them

We made the call at launch, though not loudly. Slugs are not localized in our schema, so a Finnish post inherits the English one. We would make the same call again for a blog published by an engine. The shared slug removes an entire class of mismatch, and on a blog whose argument is about what Google actually rewards, the readable breadcrumb was the smaller prize.

A client selling mainly to Finnish buyers, with English as the occasional second language, should probably choose the opposite. Their primary audience sees the slug every day. What matters is that the choice is made deliberately on day one, written down, and then left alone.

Make it a launch decision, not a backlog item

The mistake we see is treating slug language as a polish task for later, once the content is settled. It is the reverse. Content can be rewritten in place for as long as the blog lives, as we argued in the second language is a maintenance commitment. The address cannot. Decide whether each locale gets its own words in the URL before the first post ships, accept the trade you picked, and spend the rest of the year on the part readers actually judge you by, which is the page itself.