Transliteration and SEO: Searches in Two Scripts

Short answer: In many markets people search in more than one script: Russian and Ukrainian users often type in Latin letters, Hindi speakers mix Latin-script Hindi with English, Greek and Arabic users use Latin “chat” spellings, and speakers of languages with diacritics often leave them out. Research both forms, write your pages in the correct native script, and cover common transliterated forms naturally where they fit. Only build separate script versions when your audience really reads both, as in Serbian, and then connect them with hreflang script codes such as sr-Latn and sr-Cyrl.

What transliteration means for search

Transliteration is writing the words of one script with the letters of another. “Спасибо” becomes “spasibo”, “Ευχαριστώ” becomes “efcharisto”, “धन्यवाद” becomes “dhanyavaad”. It happens in search for practical reasons:

• The keyboard or phone is set to a Latin layout and switching is inconvenient.
• People learned to type on devices that did not support their script well.
• Brand names, products and technical terms are known in Latin form.
• Informal online writing in the language developed a Latin-script habit, as with Arabizi, Greeklish or Hinglish.

A related case is diacritics. Speakers of Lithuanian, Polish, Czech, Vietnamese, Turkish and many other languages often type words without accents and special letters, especially on mobile. “Kaunas viesbutis” instead of “Kauno viešbutis” is a typical example.

For site owners this creates a question: which form do you target, and do you need to do anything about the other one?

How search engines handle mixed scripts

Modern search engines are good at connecting transliterated queries with native-script pages, and at matching queries without diacritics to pages with them. For common words and well-known entities, a Latin-script query often returns native-script results, and the reverse.

That matching is not perfect, though:

• Transliteration is not standardised. One word can have several Latin spellings, and less common ones may not be connected.
• Removing diacritics can create a different real word with another meaning, so search engines cannot always assume they are the same.
• Results for transliterated and native queries often differ, even when they overlap.
• Brand and product names may only be known in one form.

How engines identify page language in the first place is covered in how Google detects the language of a page. The key point: the page text itself decides, so the script you write in matters.

Research both forms before you decide

Keyword tools and Search Console data usually show the transliterated and native forms as separate queries. Check both for your main topics:

1. List the native-script terms for each topic, with native speakers’ help.
2. Add the common transliterated spellings and versions without diacritics. Native speakers know which ones people actually type.
3. Compare volumes and results. Search each form in the local version of the search engine and note whether the same pages rank.
4. Check your own Search Console queries for the country, filtered by page, to see which forms already bring impressions.

Often you will find that results overlap heavily and one page can serve both. Sometimes a transliterated form has its own significant demand and different results, which is a sign to address it explicitly on the page. Our guide to multilingual keyword research describes how to work with native speakers on this.

Write in the correct native script

For most languages the right approach is simple: write the page properly, in the script and with the diacritics that a careful native reader expects. This is what looks trustworthy to readers, and it is what search engines expect for the language.

• Do not strip diacritics to match lazy queries. Text without them looks unprofessional and can change meanings.
• Do not write the whole page in transliteration unless that is genuinely how your audience reads, which is rare outside informal contexts.
• Keep the lang attribute accurate for the language of the page.

Then cover the transliterated forms where they appear naturally. Brand and product names can be given in both forms once, for example “Київстар (Kyivstar)”. Technical terms can include the Latin form readers may search for. A short FAQ can use a common spelling that people type. Do not add lists of variant spellings or hidden text; that is keyword stuffing and helps nobody.

URLs, titles and other visible elements

Scripts also affect URLs and snippets:

• URL slugs. Native-script slugs are valid and readable in the address bar, but they are percent-encoded when copied, which makes shared links long and unreadable in many places. Many sites in Cyrillic and Greek use transliterated Latin slugs for that reason. Both approaches work for search; pick one and apply it consistently. The trade-offs are discussed in should you translate URL slugs.
• Title tags. Write them in the native script. If a transliterated brand name is how most people search, include it in the title where it fits.
• Image file names and alt text. Alt text belongs in the language and script of the page. File names can be transliterated for practical reasons.
• Structured data. For organisations and products known by names in two scripts, the alternateName property can hold the other form.

When to build separate script versions

Some languages are officially written in more than one script, and readers genuinely prefer one or the other:

• Serbian uses both Cyrillic and Latin in everyday life.
• Chinese uses Simplified and Traditional characters, depending on the region.
• Uzbek, Kazakh and Azerbaijani have moved or are moving between Cyrillic and Latin.
• Punjabi is written in Gurmukhi in India and Shahmukhi in Pakistan.

Here separate versions can make sense. Each version gets its own URL, full content in that script and hreflang annotations with an ISO 15924 script subtag, such as sr-Cyrl and sr-Latn, or zh-Hans and zh-Hant. The code format is covered in our hreflang language and region codes reference, and the Chinese case in Chinese hreflang codes.

Automatic script conversion can be a reasonable base for these versions, especially for Serbian, where conversion between Cyrillic and Latin is largely mechanical. Chinese conversion is harder, because vocabulary also differs by region, so it needs human review.

Script choices at a glance

Mistakes to avoid

• Stuffing spelling variants. A paragraph listing “spasibo, spasiba, spaseebo” at the bottom of the page is keyword stuffing. It does not help and looks spammy to readers.
• Hidden transliterated text. Text in white on white, collapsed blocks that never open or tiny fonts meant only for search engines can violate search engine spam policies.
• Automatic conversion without review. Converting a whole site to another script with a plugin, without checking names, abbreviations and foreign words, produces errors that native readers notice immediately.
• Mixing scripts in one version. A Serbian Latin page with Cyrillic menus, or a Simplified Chinese page with Traditional product names, confuses both readers and language detection.
• Script versions without hreflang. Two converted versions of the same page without annotations look like duplicates, and one may be filtered out.
• Relying on one test search. Personal results depend on location and settings. Use Search Console data and local checks.

Checking your site for script problems

Script issues often hide in details. Common findings in audits of multilingual sites include wrong or missing lang attributes, hreflang codes without the needed script subtag, duplicated pages that differ only by automatic conversion without hreflang, and page titles left in the original language. Site SEO AI Audit checks hreflang return links, broken language versions, x-default and lang attributes across the whole site, weighted by how many pages each issue affects. It shows quickly whether your language and script versions are connected correctly. See the plans for regular re-checks.

Related reading

• The HTML lang attribute: what it does for SEO and users
• SEO-friendly URLs: how to write clean page slugs
• Translation vs localization for SEO: what actually changes

The bottom line

Many searchers type in a different script or without diacritics. Research both forms with native speakers, write your pages correctly in the native script, and include common transliterated names and terms naturally. Build separate script versions only where readers truly use both scripts, and connect them with hreflang script subtags.

KKK

Should I create separate pages for transliterated keywords?

Usually not. Search engines connect transliterated queries with native-script pages reasonably well, and separate pages would be near-duplicates. Mention the common transliterated forms naturally on the main page instead.

Do search engines understand queries without diacritics?

In most cases, yes, especially for common words. Where removing diacritics creates a different word, results can differ, so check your key terms in the local search engine.

Should URL slugs be in the native script or transliterated?

Both work for search. Transliterated slugs are easier to share because native characters are percent-encoded when copied. Choose one approach and use it consistently across the site.

How do I mark Serbian Latin and Cyrillic versions in hreflang?

Use the language code with an ISO 15924 script subtag, for example sr-Latn and sr-Cyrl, optionally followed by a region code. Each version must list all others and itself.

Is writing a page in Latin transliteration bad for SEO?

It is rarely a good choice for standard content, because readers expect the native script and it can look unprofessional. It can fit informal communities where transliteration is the normal written style.