Capability
Website localization, with the technical details handled
Localization fails on mechanics far more often than on language: asymmetric hreflang, keywords translated instead of researched, and plugins that overwrite a local team's corrections. PolyDraft generates the annotations, researches demand per market, and protects hand-edited translations.
Definition
What website localization means
Website localization is adapting a site for another market so it reads as though it was written there. Copy is rewritten by meaning rather than translated word for word, search terms are researched for that market specifically, and the annotations that tell search engines which version serves which audience are generated correctly.
Translation is a subset of it. A translated site says the same things in another language; a localized site says the things that market responds to, findable through the words that market actually searches for.
The mechanics
Where multilingual sites usually break
Each item below is a specific failure mode, paired with what the system does instead.
hreflang generated, not hand-maintained
Self-referencing annotations, symmetric pairs between every locale, and valid BCP 47 language codes. These three details are mechanical, easy to get wrong by hand, and the usual reason language versions compete with each other instead of cooperating.
One site or separate market sites
Run a single site with language subpaths, or separate market-specific sites when a market needs its own domain and positioning. Both are first-class choices; the URL architecture is decided once and applied consistently.
Transcreation, not word-for-word
Copy is rewritten by meaning the way a local marketer would write it. Literal translation moves words across a boundary; it does not move a buyer who expresses the same need differently.
Per-market keyword research
Search demand differs by market, so each locale gets its own keyword plan rather than a translation of the English one. The phrase your German buyers actually type is rarely the German words for your English phrase.
Right-to-left scripts handled properly
Arabic, Hebrew, Persian and Urdu render with correct direction and logical layout properties, not a mirrored afterthought bolted onto a left-to-right design.
Hand-edited translations are never overwritten
Auto-translate on publish is optional. When your local team corrects a page, a later automated pass leaves that correction alone — the failure mode that makes teams abandon translation plugins.
Up to 100 content languages are supported; per-plan limits are on the pricing page. For the market-entry perspective rather than the mechanics, see global brands.
The workflow
How a market gets added
01
Choose the URL architecture
Decide between language subpaths on one site and separate market sites, based on whether markets need distinct domains and positioning. Everything downstream follows from this choice, so it is made deliberately and up front.
02
Research demand per market
Each target locale gets its own keyword plan from live search demand data, so pages target phrases real buyers in that market type rather than translated guesses.
03
Transcreate the content
Pages are rewritten by meaning into each language, including right-to-left scripts, keeping the argument intact while the phrasing becomes native.
04
Generate the annotations
hreflang, localized sitemaps and canonical URLs are produced for every locale, so search engines can map the relationships correctly rather than inferring them.
05
Govern it from the admin panel
The translation manager tracks which pages are translated and which are stale. Your team edits any locale directly, and those edits are protected from later automated passes.
Every locale inherits the same generated technical layer described on SEO automation, and the same AI visibility artifacts.
Limits
What we do not promise
Localization is where overpromising is most expensive, because the mistakes surface in a language your team may not read.
Transcreation is not certified human translation
For regulated content — medical, legal, safety documentation — you should still commission a qualified human translator. What ships here is marketing-grade localization, and every locale remains fully editable so a professional translator can work directly in the admin panel.
Correct hreflang does not guarantee market rankings
Annotations tell a search engine which version belongs to which audience. They remove a technical failure mode; they do not overcome a stronger local competitor or a domain with no history in that market.
Language is not the whole of a market
Currency, payment methods, shipping terms, local proof and legal disclosures are business decisions the software cannot make for you. We build the site; the market-entry judgement stays yours.
Plan limits apply to language count
Up to 10 languages per site on Starter, 30 on Pro and 100 on Agency. The exact figures are on the pricing page and are the same numbers you are billed against — no hidden per-language fees.
Standards we build against
Primary sources
The specifications that define correct language annotation. Worth reading before commissioning any multilingual build, from us or anyone else.
- Localized versions of your pages (hreflang) — Google Search Central
- BCP 47 — Tags for Identifying Languages (IETF)
- Declaring language in HTML — W3C Internationalization
- Build and submit a sitemap — Google Search Central
Related case: an export manufacturer site built for international buyers.
Localization questions
What is website localization?
Website localization is adapting a site for another market so it reads as though it was written there: the copy is rewritten by meaning rather than translated word for word, search terms are researched for that market, and the technical annotations that tell search engines which version serves which audience are generated correctly.
How is this different from translating my site with a plugin?
Three differences. Plugins translate words, so they inherit English keyword choices into markets that phrase the same need differently. Their hreflang is frequently incomplete or asymmetric, which makes language versions compete with each other. And a resync commonly overwrites corrections your local team made. Here, keywords are researched per market, hreflang is generated as part of the build, and hand-edited translations are never overwritten.
Should I use one site with language subpaths or separate market sites?
Use language subpaths on one site when markets share positioning and you want the whole domain to accumulate authority together. Use separate market sites when a market needs its own domain, distinct positioning or a separate commercial entity. Both are fully supported, and the choice is made when the site is planned rather than being forced by the tooling.
Are right-to-left languages properly supported?
Yes. Arabic, Hebrew, Persian and Urdu render with correct text direction and logical layout properties, rather than a design mirrored as an afterthought. RTL locales count the same as any other language against your plan limit.
Can my local team edit the translations?
Yes, and that is the intended workflow. Every locale is editable in the built-in admin panel, edits go live immediately, and the translation manager marks which pages are current or stale. Auto-translate on publish is optional, and anything your team has hand-edited is never overwritten by a later automated pass.
Build one market free, then decide
Building and previewing costs nothing. Inspect the generated hreflang, the localized sitemap and the transcreated copy before you publish anything.