The outcome is not a translated website. The outcome is a localized website that can be reviewed, published, indexed, and maintained without breaking the original site.
Website localization works best when content, SEO, design, engineering, and legal review are planned before strings move. That keeps translated pages from becoming disconnected files with no owner.
The 7-step website localization process
Use this sequence before launch:
- Page inventory: URLs, templates, forms, downloads, and media.
- Market request: target language, target country, audience, and regulated terms.
- SEO map: page title, meta description, H1, internal links, and hreflang plan.
- Content extraction: CMS export, spreadsheet, HTML, JSON, XML, or XLIFF.
- Translation and review: term list, style notes, reviewer owner, and comments format.
- Build check: layout expansion, navigation, buttons, forms, and file names.
- Publish check: canonical, sitemap, redirects, analytics, and search index status.
Those 7 steps turn localization into a controlled release instead of a late copy task.
Scoping: what actually gets translated
The inventory step is where budgets are won or lost. Most sites contain far more translatable content than the visible page copy:
| Area | Often forgotten? | Why it matters |
|---|---|---|
| Body copy and headings | No | The obvious scope |
| Navigation, buttons, form labels | Sometimes | Users cannot complete tasks without them |
| Validation and error messages | Often | A form that errors in English reads as broken |
| SEO titles, meta descriptions, slugs | Often | Localized pages cannot rank without them |
| Image alt text and captions | Often | Accessibility and image search |
| PDFs and downloadable files | Often | Support and legal exposure |
| Confirmation emails and thank-you states | Often | The post-conversion experience |
| Cookie banner and legal notices | Sometimes | Compliance in the target market |
Price the full set or decide explicitly what stays in English. The expensive outcome is discovering the forgotten rows after launch.
What teams often miss
Teams often translate visible page copy but miss form labels, validation messages, image alt text, PDF downloads, cookie banners, confirmation emails, and SEO metadata. Those small fields affect trust and findability.
Another common gap is reviewer ownership. If the reviewer is not named before translation starts, feedback arrives late and in several formats. A single feedback contact and one comments format help the project close cleanly.
A third gap is text expansion. German and Finnish strings commonly run 30-40% longer than English; buttons and navigation items designed tight to English will overflow. The build check step exists to catch this on staging, not in production screenshots from a user.
Extraction formats, compared
The extraction format decides how cleanly translations return to the site:
| Format | Best for | Watch out for |
|---|---|---|
| CMS export (JSON, CSV, XLIFF) | Structured sites with a real CMS | Field mapping must be documented |
| Spreadsheet with URL + string columns | Small sites, marketing pages | Context loss; translators need screenshots |
| HTML file set | Static sites | Tags must survive round-trip intact |
| XLIFF via TMS connector | Ongoing, updating sites | Requires connector setup effort up front |
For a one-time marketing-site localization, a well-built spreadsheet with screenshots is often enough. For a site that updates weekly, invest in the connector. The website localization services page describes how DD handles both patterns.
What to send for a quote
Send the page list, target language, source files or CMS export, launch date, term list if available, and reviewer contact. If the site has SEO pages, include the target URLs and metadata fields.
A complete request package:
- URL list or sitemap export marking in-scope pages
- Target languages and countries (language alone is not enough — pt-BR and pt-PT differ)
- Source files in the chosen extraction format
- Term list, style guide, or prior translations if they exist
- Named reviewer with authority to approve wording
- Launch date and any campaign date driving it
- Regulated content flags: legal, medical, financial pages needing specialist review
A 9-point launch QA checklist
Before localized pages go live, check these 9 items on the staging site:
- Page title, meta description, H1, and canonical are present for every localized URL.
- Hreflang targets point to live or approved staging URLs, not draft URLs.
- Navigation labels, buttons, forms, and validation messages are translated.
- Images, captions, alt text, and downloadable files match the target language.
- Layout expansion is checked on mobile and desktop for the longest translated labels.
- Contact forms, thank-you states, and confirmation messages go to the correct team.
- Legal, privacy, cookie, and regulated-language fields have a named feedback contact.
- XML sitemap and internal links include the localized URLs after approval.
- Analytics, conversion tags, and search-console tracking are mapped before launch day.
The checklist is intentionally simple: 9 items, 1 owner, 1 staging pass before launch. That catches common localization misses before users or search engines see them. The same list is available as the downloadable website localization QA checklist.
Frequently asked questions
Should URLs be translated?
Usually keep slugs stable and ASCII-safe; translate them only when the SEO plan calls for it and redirects are mapped. A translated slug without a redirect plan breaks existing links and loses accumulated ranking.
How do we handle content that updates weekly?
Separate the one-time launch scope from the ongoing update flow. Launch uses the 7-step process above; ongoing updates need a defined handoff (CMS connector, scheduled exports, or a change-notification rule) so new English strings do not silently ship untranslated.
Machine translation plus review, or full human translation?
Depends on the page’s risk. Product and legal pages justify full human translation with independent review. Low-risk, high-volume content can use machine translation with postediting when the reviewer is qualified and the error categories are defined. Decide per content tier, not per site.
Who should the reviewer be?
Someone with authority over wording in the target market — an in-country marketer, a distributor, or a qualified reviewer the vendor provides. The worst arrangement is “anyone who speaks the language” with no decision power; feedback loops never close.
How long does a typical marketing-site localization take?
A 20-40 page site in one language commonly runs 3-6 weeks including review and staging QA, assuming source files and a reviewer are ready. The schedule slips when extraction or reviewer availability is unplanned, not when translation itself is slow. Add roughly one extra week per additional language when the same reviewer pool covers all of them.
Dynamic Dialects plans website localization across 250+ languages, including translation, SEO field review, file handling, and publication-ready deliverables. Start with the localization service overview or send the page list through the contact form.