WordPress Slugs From Turkish Titles and Percent-Encoding

When you build a WordPress slug from a Turkish title, you have two choices: write ç, ğ, ı, ö, ş and ü as their ASCII counterparts (c, g, i, o, s, u), or keep the letters and let the address appear percent-encoded. Google's documentation says words in your audience's language, and transliterated words where applicable, may appear in a URL, and that characters outside the ASCII range should be percent-encoded. If you run a blog, a store blog or a client site, a transliteration rule, an understanding of percent-encoding and a written team rule are enough to check a slug before you publish.

For general address rules see URL structure and slug best practices; for two-language sites see localized URLs and slug translation. The remaining permalink settings are in the WordPress SEO settings checklist.

What WordPress does when it makes the slug

The definition

The WordPress permalink documentation (Opens in a new tab) describes the post name tag as a sanitized version of the post title and says it comes from the slug field in the edit screen. Its example turns "This Is A Great Post!" into this-is-a-great-post. Capitals become lower case, spaces become hyphens, and characters like the exclamation mark do not reach the address.

Turkish letters are not covered

The documentation's example is an English title. Whether the automatic process converts Turkish letters to ASCII, keeps them or handles them some other way is not stated; the documentation is silent on this. Instead of trusting the generated slug, read the slug field after you type the title.

Where the field sits

The edit screen shows the post's permalink and an editable slug field. If your dashboard is not in English, labels can look different. Opening that field before you publish is the surest way to see what the address will be.

Testing your own setup with a dummy title

1. Create a draft and give it a title containing every Turkish letter: çiğ, ışık, İstanbul, ödül, şehir, üzüm.
2. Save the draft and open the slug field in the permalink section.
3. Record what happened to each letter: kept, converted to ASCII, dropped or replaced by another character.
4. Open the preview address and copy it from the address bar into a text file to see how it reads when pasted.
5. Delete the draft and add the result to your style guide.

What each observation means

The ASCII counterparts

Practical suggestion: write ç, ğ, ı, ö, ş and ü as c, g, i, o, s and u. This is a writing convention, not a rule from Google; the Google page allows transliterated words but does not prescribe a mapping.

The two letter i's

Turkish keeps a dotless ı and a dotted i as separate letters, with the capitals I and İ. A slug has no capitals, so a title word like İstanbul should end up as istanbul. If the generated slug shows an unexpected letter, correct it by hand.

When dropping a mark changes the word

Writing Turkish letters as ASCII can make two different words look identical, which makes the topic harder to read from the address.

A rule for collisions

1. Does the slug word, without its marks, become another word? If so, add a second word that supplies context.
2. Will readers see the title next to the address, as in share previews? That reduces the collision.
3. Does the slug fail to carry the meaning of the title? Then rebuild it; it does not have to equal the title.

Practical suggestion: choose a phrase that defines the topic over a single ambiguous word. In a post about age calculation, a slug like yas-hesaplama is clearer than a bare yas.

When percent-encoding bites

What the Google page says

The Google URL structure documentation (Opens in a new tab) says characters in the non-ASCII range should be percent-encoded, while unreserved ASCII characters may be left unencoded. It also recommends hyphens over underscores to separate words, because hyphens signal a word boundary, and says to use words from your audience's language. It does not say that Turkish-letter addresses help or hurt rankings.

What the encoded form looks like

In standard UTF-8 percent-encoding, each Turkish letter becomes a two-byte sequence. The table shows how encoding appears; the Google page does not provide it.

Where it causes friction

• When an address is pasted into plain text, email or chat in its encoded form, it is harder to read and looks long.
• Sitemaps, access logs and analytics reports can show the encoded form, which makes matching addresses harder.
• One tool shows the address with letters and another shows it encoded; the same address in two spellings looks like an inconsistency.
• A hand-written redirect rule has to match either the encoded or the plain spelling, and you need to know which.

These points come from working experience, not from the Google page. Practical suggestion: whichever style you choose, use it everywhere on the site.

Myths worth separating

Treat the table as a way to base the decision on readability and ease of management, not on fear. Google's recommendations can change; check the current page before applying them.

ASCII or Turkish letters: a decision

A short rule

1. Can you apply one style across the whole site? If so, which style you pick matters less than being consistent.
2. Were older posts published in one style? Then continue it for new posts.
3. If sharing, tool compatibility and ease of redirects come first, choose ASCII.

Practical suggestion: on a new site make ASCII transliteration the default and add context words wherever a collision exists. That is a preference for ease of management, not a rule; the Google page does not rule out percent-encoded Turkish-letter addresses.

Editing slugs by hand

• Separate words with hyphens, not underscores.
• Use lower case. The Google page says URL handling is case sensitive and recommends one case if your server treats both the same.
• Keep the phrase that names the subject; drop conjunctions and filler instead of copying the whole title.
• Leave out dates, serial numbers and anything temporary.
• Do not change a slug after publishing; if you do, set up a redirect from the old address.

Changing a published slug

The WordPress documentation says permalinks should not be changed. If you notice a Turkish-letter problem after publication, correcting the slug changes the address, and because the old one lives on in shares, links and search listings you need a permanent redirect from old to new. For a single post, one redirect line is enough; the wider method is in the article on changing a live permalink structure.

If the title changes

The documentation says the slug comes from the slug field on the edit screen. It does not say whether editing the title of a published post updates the slug by itself. After a title edit, open the permalink section and confirm the slug did not change unintentionally; if it did, the old address needs a redirect.

Numbers and dates in slugs

A year or serial number in the slug makes the address age. Practical suggestion: drop the date if the subject does not depend on a year. For a yearly list you will refresh, keep the year in the title but not in the slug, otherwise you must change the slug and add a redirect each year.

Slugs, keywords and Turkish endings

A slug is not the place to stuff search terms. Turkish suffixes inflect the keyword into many forms, a subject covered in Turkish keyword research, suffixes, inflections and character problems. For the slug, a practical rule is to use the root word and leave the inflection ending off.

Title, slug and visible text are different things

Keeping Turkish letters in the title is right for readers; the slug is only an address. Since the WordPress documentation calls the slug a sanitized version of the title, a difference between the two is normal.

Category and tag slugs

The WordPress documentation says the category tag in a structure uses a sanitized version of the category name, the category slug. A Turkish category name therefore raises the same question as a post slug. Read the slug field when you create the category and apply the same rule. Changing a category slug later changes every post address in that category if the structure includes the category.

Two languages, two sets of slugs

On a bilingual site each language has its own slugs: the Turkish slug is a transliteration of Turkish words, the English slug is English. The documentation says nothing about pairing the two languages, so you decide. A tracking table keeps the pairs honest.

The two slugs do not have to be equal; what matters is that each language follows one spelling rule and that the pair is recorded. If a slug changes, plan the redirect in both languages.

Auditing the slugs you already have

Turkish-letter problems may have built up on a live site. Export the post list or read the sitemap, then filter slugs by three criteria.

1. Addresses with a percent sign: they may carry encoded Turkish letters.
2. Single-word slugs and slugs with a meaning collision.
3. Long slugs that hold the whole title.

Is fixing worth it?

Correcting a working address creates redirect work. Practical suggestion: change only addresses that cause demonstrable trouble, such as a misleading collision or a form that breaks in your tools. Apply the rule from the start to new posts. Applying a rule to new posts carries far less risk than bulk-editing old ones.

New site or live site

On a site with nothing published, deciding the slug rule is free: write the style guide before the first post, test the setup with the dummy title and announce the rule. On a live site every fix is an address change, so decide which addresses really cause trouble, prepare permanent redirects only for those and leave the rest. When an editor says "let us fix the slug," a published post means a redirect job, while a draft can be changed freely.

Plugins and slugs

SEO plugins, multilingual plugins and import tools can interfere with slug generation, and the documentation says nothing about their behavior. After installing or updating one, repeat the dummy-title test and check whether the plugin has a setting for slugs or character conversion.

Example scenario: a neighborhood flower shop's blog

Example scenario: A flower shop drafts a post titled "Çiğdem Yetiştirme Rehberi: Işık ve Sulama".

1. The owner opens the slug field after saving the draft; an earlier dummy title showed her how the site handles Turkish letters.
2. The slug carries the whole title, so she shortens it to cigdem-yetistirme-isik-sulama.
3. She reads isik, sees that the context is enough and accepts it.
4. She checks that older posts use ASCII transliteration, so the style stays single.
5. She publishes and opens the address in a new tab.

Mistakes to avoid

A ten-question check before publishing

1. Did I open the slug field?
2. Are the Turkish letters written by the site's rule?
3. Are words separated by hyphens?
4. Is everything lower case?
5. Does the slug say the subject without the title?
6. Is there a collision, and did I add a context word?
7. Is there a date or serial number?
8. Does another item carry the same slug?
9. Do category and tag slugs follow the rule?
10. Did I open the address in a new tab after publishing?

Keywords in the slug as a ranking lever

Stuffing keywords into the slug is believed to raise rankings. The documentation makes no such promise; a short, readable, meaningful address is enough for both readers and maintenance.

Setting a slug rule for the whole team

Slug production from Turkish titles is rarely a problem for one post. The trouble begins when several people make different choices across a hundred posts. A small set of rules keeps addresses consistent.

Publishing steps for each post

1. The author writes the title and saves a draft.
2. The editor opens the slug field and checks the Turkish letters and the length.
3. The editor shortens the slug and adds a context word if there is a collision.
4. The address is previewed before publication.
5. After publishing, the address is opened in a new tab and returns 200.
6. Any slug decision is logged in the post notes or in the tracking table.

A style guide template

Example scenario: an independent bookshop's recommendation blog

An independent bookshop publishes reading recommendations and author interviews. Titles carry special letters, such as in a post about five contemporary Turkish novels. The shop decides to build the slug not from the title but from the short phrase a reader would type: the author's surname and the topic. Letters are converted to their plain Latin equivalents, and the slug stays the same even if the title is polished later. A title edit no longer turns into an address change.

Questions each team should answer

• Is the slug reviewed by eye before publication, or does automatic output go live untouched?
• Is it agreed how special letters are converted?
• Does editing the title also change the address, or is the slug kept separate?
• When long addresses are shortened, does the meaning survive?
• Who may change a slug that is already published?

Typo cases and what to do

Practical suggestion: treat the slug as a decision separate from the title. The title speaks to the reader browsing, while the slug speaks to the person who shares or bookmarks the link.

Before changing a published slug

Practical suggestion: before changing the slug of a published post, check three things. Do outside pages link to it, has it been shared by email or social media, and do the site's own internal links depend on the address? If all three answers are no, the change is low risk. If even one is yes, the change creates a redirect task and belongs in the decision note. Fixing an address that shows percent-encoded letters follows the same rule: if the address looks ugly but works, weigh the cost of the fix against what you actually gain.

Frequently Asked Questions

How does WordPress convert Turkish letters in a slug?

The WordPress documentation calls the post name tag a sanitized version of the title and gives an English example. How Turkish letters are converted is not stated, so check the generated slug in the slug field.

Can I use Turkish characters in a slug?

The Google documentation says words in your audience's language may be used and non-ASCII characters should be percent-encoded. Encoded addresses look long. Practical suggestion: prefer ASCII transliteration and use one style across the site.

Does a percent-encoded URL affect rankings?

The Google documentation makes no statement about the ranking effect of percent-encoded addresses. It says only that non-ASCII characters should be percent-encoded.

Should slugs be lower case?

The Google documentation says URL handling is case sensitive and recommends converting to one case if your server treats both the same. Lower case is therefore the safe choice.

Can I fix the slug of a published post?

You can, but the WordPress documentation says permalinks should not be changed. If you change one, set up a permanent redirect from the old address to the new one.

Must the Turkish and English slugs match?

The documentation says nothing about pairing slugs across languages. Use each language's own words, one spelling rule and a tracking table of the pairs.

Conclusion

The decision for a Turkish slug is simple: read the slug field before publishing, pick one style, add context to words that collide and never change a published slug without a redirect. The Google documentation accepts both audience-language words and transliteration, and asks for percent-encoding of non-ASCII characters.

If you want to fill well-built slugs with articles that serve readers, take a look at our content writing service.