Localized URLs SEO: Slug Translation on a TR/EN Site

Localized URLs and slug translation sound like a small editorial detail until a bilingual site grows past a few dozen pages. Then three questions appear at once: should the words in an address follow the page language, how should those words be written, and how does a search engine learn that two addresses describe the same page? This guide takes those questions in turn for a site that publishes in Turkish and English.

It is written for site owners, content editors and translators who maintain both versions. The technical statements below rest on four Google Search Central documents: URL structure, localized versions, managing multi-regional sites and redirects. Example sites are fictional and carry no figures.

Benefits and Limits of Translating Slugs

A slug is the readable last part of an address. On a bilingual site the first decision is whether it should follow the page language. Google's URL structure guidance (Opens in a new tab) answers this in one line: use words in your audience's language in the URL and, where applicable, transliterated words. Its examples include German and Japanese words. The page does not discuss whether an English word is acceptable on a Turkish page, so any claim that one choice outranks the other goes beyond what the document supports.

What translation realistically gives you

The benefits are mostly about people and process:

• Recognition: A reader who sees familiar words in the address knows what the page is about before opening it, for example when a link is pasted into a chat.
• Editorial coherence: When the title, navigation label and address use one term per language, writers and support staff stop juggling two vocabularies.
• Easier audits: A path such as a language folder followed by a native-language slug tells a reviewer which version they are looking at, without opening the page.
• A single maintenance rule: Once the policy is written down, new pages follow it without debate.

What translation does not do

Translating a slug does not replace language signalling. The localized versions documentation (Opens in a new tab) states that Google does not use hreflang or the HTML lang attribute to detect a page's language, and it describes hreflang as the way to point to alternate versions. A native-language slug does nothing to connect the two versions, so the pairing still needs explicit annotation. The companion article on auditing hreflang language and region tags covers that part in depth.

Translation also has costs. An address that already works has accumulated links, bookmarks and citations; changing it only to make it feel more local creates redirect work with an unclear return. And word-for-word translation can produce a phrase nobody actually searches for or says. The goal is the term a native reader would expect on that page, not a dictionary match.

Deciding what to translate

Not every part of an address deserves the same treatment. The table below uses a fictional language-school website to show a workable split.

Fictional example: a language school offers a course on business writing. The Turkish page uses a local phrase for the course, while the English page uses "business writing". The school's branded course name stays identical in both addresses where it appears, because it is a name rather than a description.

Turkish Characters, Hyphens and Short Slug Rules

Once the wording is decided, the next question is how to spell it in an address. Three topics matter here: special letters, separators and length.

Handling Turkish letters

Google's URL structure page says characters in the non-ASCII range should be percent-encoded, and illustrates it with gemüse becoming gem%C3%BCse. What matters in practice is the outcome: an address containing ç, ğ, ö, ş or ü can look tidy in a browser bar and still turn into an encoded string when copied.

That leaves two coherent options:

1. Transliterate: Replace each special letter with its closest ASCII form. This matches the documentation's reference to transliterated words.
2. Keep the letters: Write the slug with the original characters and let the system encode them. Then every sitemap entry, hreflang annotation and internal link must use the same encoded form.

Choose one policy and apply it everywhere. A mixed archive, with some slugs transliterated and others not, makes redirect lists and audits error-prone. For most teams transliteration is easier to maintain; that is an editorial preference, not a Google requirement.

General knowledge, not from the sources: because dotless ı and the dotted i both become i, two different Turkish words can occasionally collapse into the same ASCII slug. Check the existing slug list before publishing, and add a distinguishing word when a clash appears.

Separators and letter case

The same Google page recommends hyphens over underscores to separate words and warns against running words together, as in a single string like "greendress". It also notes that URLs are case sensitive: /APPLE and /apple are treated as distinct URLs, and if your server serves both the same, you should convert everything to one case. In practice, write all slugs in lowercase and redirect any uppercase variant that surfaces to the lowercase form.

Short, descriptive slugs

The documentation favours readable words over long ID numbers and recommends trimming unnecessary parameters. It sets no numeric length limit, so the guidance below is editorial rather than official:

• Do not paste the whole headline into the slug. A few words that carry the main topic are usually enough.
• Drop filler words and anything that ages, such as a year. A dated slug becomes misleading after the next update and then forces a redirect.
• If the category folder already states the topic, avoid repeating it in the slug.
• Pick a short phrase natural to each language rather than forcing an exact translation of a long phrase.

For single-language cleanup rules, see URL structure and slug best practices. The focus here is how those rules line up across two languages.

Category, tag and archive paths

Article slugs get attention, but category, tag and archive paths are generated by templates and often slip through. The result is an address like a language folder, an untranslated category word and then a translated slug, which reads as a half-translated path. Read every address from left to right before launch and confirm each segment follows the language of the page. The documentation does not rule on this specific mix; the advice is about readability and maintenance.

Query parameters follow the same discipline. Google advises shortening URLs by trimming unnecessary parameters and does not recommend using URL parameters to separate language or country versions. Choose one naming convention for the filter parameters that remain, so redirect rules do not need a separate set per language.

TR/EN Pairing: Canonical, Hreflang and a Route Table

Translating slugs does not tell a search engine that two pages belong together. The pairing rests on the address structure, the hreflang annotations and each version's own canonical address.

Choosing the language structure

The managing multi-regional sites page (Opens in a new tab) compares country-specific domains, subdomains, subdirectories and URL parameters. It describes subdirectories as easy to set up and low maintenance, with the drawback that users may not recognise the geotargeting from the address. URL parameters are not recommended because segmenting by them is difficult. A site with Turkish and English sections under language folders sits in the subdirectory category.

The same page recommends giving each language version its own URL instead of adapting content through cookies or browser settings, and it warns against using IP analysis to adapt content, calling location analysis difficult and generally unreliable. It also notes that Googlebot usually crawls from the USA and does not send an Accept-Language header, so a setup that switches language dynamically may hide versions from the crawler.

No automatic language redirects

One of the most useful warnings in that document is to avoid automatically redirecting visitors based on presumed language or location. Such redirects can keep both users and search engines from seeing every version. The suggested alternative is a visible link to the other language version. A visitor whose browser is set to English but who lands on a Turkish page should see a plain link to the English counterpart, not be moved without a choice.

Hreflang rules that matter for slugs

According to the localized versions page, hreflang can be given as link elements in HTML, as HTTP headers or in an XML sitemap, and the three are equivalent from Google's perspective. Using all of them brings no extra benefit. The rules to remember are:

• Pages must reference each other, otherwise the annotations are ignored.
• Each version must list itself as well.
• Alternate URLs must be fully qualified, including http or https; relative paths do not qualify.
• Only ISO 639-1 language codes and ISO 3166-1 Alpha 2 region codes are supported, and a country code cannot stand alone.
• An x-default entry can serve as a fallback for unmatched languages, for instance on a language selector page.

The consequence for slug work is simple: when a slug changes, the absolute address inside every related hreflang annotation changes with it, on both language versions. A half-finished update breaks the return link, and the annotation is then ignored.

Canonical and translated pages

The localized versions page says that localized versions are considered duplicates only if the main content remains untranslated. A fully translated page is therefore not a copy of its counterpart. That page does not describe in detail how hreflang and canonical interact, so no rule is attributed to it here. A common editorial practice is for each language version to canonical to its own address; treat that as a working convention. If canonical errors are suspected, canonical tag issues, audit and fixes walks through the checks.

A route table as the single source of truth

Once slugs are translated, someone must know which Turkish address matches which English one. A shared route table does this job for translators, developers and SEO owners. A fictional example:

The first column holds a topic ID that does not depend on language. Keeping both versions under one ID prevents the "which English page was this?" search later. For teams that commission both versions together, bilingual article writing order from one brief explains how to brief two independent texts.

Navigation that follows the table

The language switcher is where a route table pays off. Many templates link the switcher to the other language's home page. A switcher that reads the table and opens the same topic in the other language is easier on readers, and it matches the documentation's advice to offer links between language versions. If a counterpart page does not exist yet, hiding the switch is preferable to sending people to an unrelated page.

Fictional example: an English tutorial page has a switcher pointing at the Turkish home page. A reader who wants the Turkish tutorial must start over from the menu. After the switcher is connected to the route table, one click lands on the matching Turkish tutorial. The sitemap should follow the same logic, with both addresses listed and updated together.

301s and Internal Link Updates When Slugs Change

Changing a slug means opening a new address and tying the old one to it. That has a real cost, so the first question is whether the change is needed at all.

When a change is justified

Reasonable triggers include a typo, a page whose topic has changed completely, mixed-language wording inside one language version, or a site-wide address policy that is being introduced. Changing a working address because one word "might be nicer" rarely pays back, since redirect handling becomes a permanent chore.

Which redirect to use

Google's redirect documentation (Opens in a new tab) lists HTTP 301 and 308, instant meta refresh and JavaScript location changes as permanent redirects, and 302, 303 and 307 as temporary ones. It says permanent redirects act as a canonical signal, so the target is what appears in results, while temporary redirects do not carry that signal. For method it prefers server-side redirects, offers meta refresh as a fallback and treats JavaScript as the last resort because rendering may fail and Google might never see the redirect.

The page does not state how long a redirect should be kept and does not discuss chains. As general knowledge and an editorial recommendation, keep redirects in place as long as practical and point each old address straight to the final address in one step.

Rules for a language pair

• An old Turkish address must redirect to the new Turkish address, and an old English address to the new English one. Sending one language to the other forces an unexpected language switch.
• If both slugs change, ship both redirects in the same release so that the hreflang pair stays reciprocal.
• Test both source and target, and confirm the target returns 200.

The change sequence

1. Record the old and new address in the route table and count how many internal links point to the old one.
2. Publish the new address and confirm it returns 200.
3. Add a server-side permanent redirect from the old address to the new one.
4. Update internal links, menus, breadcrumbs and the sitemap to the new address. Do not leave links pointing at the old address and rely on the redirect.
5. Replace the address inside the page's own canonical and hreflang annotations, and update the counterpart page's annotations as well.
6. Crawl the site and confirm no internal link still points to the old address.

Step four is the one most often skipped. The redirect hides the problem, yet every leftover internal link triggers an extra request and splits the signals between two addresses. Linking straight to the new address is the cleanest result.

Fictional example: a clinic site shortens "contact-details" to "contact-us" in English. The Turkish page is updated in the same release, but its hreflang entry still lists the old English address. The return link fails and the pairing is ignored until someone notices. The status column of the route table is a simple safeguard: both rows must read "complete" before the release is closed.

Checklist and Common Mistakes

Use the lists below when you publish a new bilingual page or review existing slugs.

Pre-publish checklist

1. Does the slug describe the page topic in that language, in lowercase, with hyphens and in the chosen character policy?
2. Is the counterpart address recorded in the route table?
3. Do both pages carry reciprocal, fully qualified, self-referencing hreflang annotations?
4. Does each version's canonical point to its own language address?
5. Are both addresses present in the sitemap?
6. Does the language switcher open the matching page rather than the home page?
7. Is any visitor or crawler being moved automatically based on language, location or cookies?
8. If an address changed, is there a permanent redirect and are internal links updated?

Common mistakes

• Translating the slug but skipping hreflang: The address changes, yet the two pages are never formally paired.
• Using language parameters: Google's guidance does not recommend URL parameters for this purpose.
• Automatic language redirects: They can hide versions from users and crawlers.
• Putting a year in the slug: The address ages with the content and later forces a redirect.
• Mixing character policies: Part transliterated and part encoded slugs complicate redirect and hreflang lists.
• Leaving uppercase variants alive: Google treats /APPLE and /apple as separate URLs.
• Redirecting across languages: An old Turkish address sent to a new English page confuses visitors.
• Leaving old internal links in place: The redirect works, but each link adds a needless request.
• Translating only the boilerplate: Google's guidance warns against translating only template text while the main content stays in one language. A translated address over untranslated content makes a promise the page does not keep.

A short brief for translators

Slug translation looks like a text task but behaves like a structural one. Give translators the rule before the job: lowercase, hyphens, the agreed character policy, a handful of words and no year. Ask them to enter the result in the route table, and let an editor approve it before it reaches a developer. That habit prevents most of the post-launch redirect repair.

Frequently Asked Questions

Do translated slugs help a Turkish and English site rank higher?

No Google document promises that. Google's URL structure guidance says to use words in the audience's language in the URL, with transliteration where it applies, but it makes no ranking claim. Treat the slug as a clarity and consistency tool, not a ranking lever.

Is it safe to keep Turkish characters in a URL?

Google says characters outside the ASCII range should be percent-encoded, and its own example turns the German word gemüse into gem%C3%BCse. A URL with such characters can work, but it often appears in encoded form once it is copied or logged. Many teams therefore choose plain ASCII equivalents for consistency.

If I add hreflang, do I still need to translate slugs?

They do different jobs. Hreflang tells Google which pages are language alternates of each other, while a translated slug helps readers recognise the language from the address. You can run hreflang with untranslated slugs, but once you translate a slug the hreflang annotations for that pair must be updated too.

Which redirect should I use when a slug changes?

Use a server-side permanent redirect such as 301 or 308 when the change is final. Google's redirect documentation says permanent redirects act as a canonical signal, and that JavaScript redirects are a last resort because rendering may fail.

Should visitors be sent to the Turkish or English version automatically?

Google's multi-regional guidance advises against automatic redirects based on presumed language or location, because they can stop users and search engines from reaching every version. Offer a visible link to the other language version instead.

Conclusion

Translated slugs make a bilingual site easier to read and easier to maintain, but they do not promise rankings and they do not replace hreflang. Keep three things together: short, lowercase, hyphenated slugs written in the page language under one character policy; reciprocal, fully qualified annotations that tie each pair together; and permanent redirects with updated internal links whenever an address changes. Keep editorial preference clearly separate from official guidance.

If you also want those principles carried into the copy itself, Akua Adforce offers SEO content writing; scope and terms are described on the service page. The advice in this article is general technical guidance and does not guarantee any ranking, crawl or indexing outcome.