Website Localization Testing: 60-Point QA Checklist

A translated website is not ready when the last sentence has been translated. It is ready when visitors can discover the correct language, understand every important message, complete every task and move between pages without seeing broken layouts or mixed-language content.

That requires website localization testing: a quality assurance process covering language, design, functionality, SEO, accessibility, performance and regional behavior.

This 2026 checklist contains 60 practical checks. Use it before a new language launch, after a redesign, when migrating translation software or whenever source content changes significantly.

What is localization testing?

Localization testing verifies that a product adapted for a specific language or market works correctly and feels natural to local users.

It overlaps with three related disciplines:

• Translation QA checks accuracy, terminology, grammar and tone.
• Internationalization testing (i18n testing) checks whether the underlying product can support different scripts, formats and text directions.
• Localization testing (l10n testing) checks the complete localized experience for one target locale.

For a website, all three matter. A perfect French sentence in a clipped button is still a defect. A beautiful German page with the wrong canonical tag is a discoverability defect. A translated checkout that rejects a local address is a functional defect.

Build a useful test matrix

Do not test every combination equally. Create a matrix based on risk.

Prioritize revenue, legal and high-traffic pages. Long-tail blog content can use sampling after automated checks pass.

A. Linguistic quality: 10 checks

• 1. Meaning is preserved. The translation communicates the source intent, not only individual words.
• 2. Terminology is consistent. Product names and feature labels use the approved vocabulary.
• 3. Tone matches the market. Formality, humor and calls to action feel appropriate.
• 4. Grammar and spelling are correct. Use a native reviewer for high-value pages.
• 5. Variables remain intact. Names, prices, placeholders and interpolation tokens render correctly.
• 6. Numbers are accurate. No quantity, percentage or plan limit changed during translation.
• 7. Links remain attached to the right words. Inline markup can shift during segmentation.
• 8. Alt text is localized. Informative images have useful text in the page language.
• 9. Hidden strings are translated. Check tooltips, validation messages, cookie banners, popups and empty states.
• 10. No mixed-language fragments remain. Search navigation, footer, forms and dynamically loaded components.

Practical tip: search each localized page for frequent source-language words such as “Submit,” “Read more,” “Privacy” or “Required.” This catches template strings that visual review misses.

B. Visual layout and responsive design: 10 checks

• 11. Buttons fit expanded text. German, French and Italian labels can be much longer than English.
• 12. Headings do not collide. Check cards, hero sections, modals and sticky banners.
• 13. Navigation remains usable. Desktop menus and mobile drawers must support longer labels.
• 14. Text wrapping is intentional. Avoid orphaned punctuation and unreadable line breaks.
• 15. Fonts contain every glyph. Accents, Arabic, Cyrillic and CJK characters must not fall back poorly.
• 16. Line height suits the script. Some scripts need more vertical room.
• 17. RTL layout is mirrored correctly. Direction, alignment, icons, breadcrumbs and carousels should make sense.
• 18. Images match the market. Screenshots with embedded source text need localized variants or neutral visuals.
• 19. Tables remain scrollable. Comparison tables often overflow on mobile.
• 20. Zoom works to 200%. Content must remain readable without overlap or loss.

Test the narrowest supported viewport first. It exposes text expansion failures quickly.

C. Functional behavior: 10 checks

• 21. The language switcher works on every template.
• 22. Switching language keeps the equivalent page. A visitor on /pricing should reach localized pricing, not the homepage.
• 23. Language preference persists. Returning visitors should not be redirected against their choice.
• 24. Automatic detection has a safe fallback. Unsupported browser languages must reach the default locale.
• 25. Forms submit successfully. Labels, validation, error and success messages must all be localized.
• 26. Local names and addresses are accepted. Test accents, hyphens, multiple surnames, postal codes and phone formats.
• 27. Search understands localized terms. Internal search should return local-language content.
• 28. Authentication flows keep the locale. Signup, login, password reset and email links should not jump language.
• 29. Dynamic content updates correctly. Modals, SPA routes, filters, carts and client-rendered components must be translated.
• 30. Third-party widgets are checked. Chat, payments, booking, cookie consent and reviews often remain in the source language.

D. Regional formats and market adaptation: 8 checks

• 31. Dates use local order and names.
• 32. Time uses the correct 12/24-hour convention and time zone.
• 33. Currency symbol, decimal and thousands separators are correct.
• 34. Units are adapted where necessary.
• 35. Phone and address examples are relevant.
• 36. Payment and delivery options match the market.
• 37. Legal notices, tax wording and consent are reviewed locally.
• 38. Cultural references, colors and imagery are appropriate.

Translation is not automatically localization. Do not change legal or commercial information purely through an AI prompt; use qualified local review.

E. Multilingual SEO: 10 checks

• 39. Every language has a stable, crawlable URL.
• 40. The page declares the correct HTML lang attribute.
• 41. Title tags are translated and unique.
• 42. Meta descriptions are localized for search intent.
• 43. Canonical tags point to the correct language page.
• 44. Hreflang links are reciprocal and use valid codes.
• 45. An appropriate x-default is present.
• 46. Localized pages appear in the XML sitemap.
• 47. Internal links stay inside the selected language where an equivalent exists.
• 48. Structured data matches visible localized content.

Also verify that localized URLs do not redirect, return a soft 404 or carry noindex. Submit the multilingual sitemap to Google Search Console and inspect representative URLs.

For a deeper technical audit, use our hreflang, multilingual sitemap and GEO guide.

F. Accessibility and performance: 7 checks

• 49. Screen readers announce the correct page language.
• 50. Keyboard users can operate the language switcher.
• 51. Focus order remains logical in RTL and responsive layouts.
• 52. Accessible names and ARIA labels are translated.
• 53. Contrast remains sufficient on localized buttons and banners.
• 54. Core Web Vitals do not regress after adding localization.
• 55. Translation loading does not create a visible flash or major layout shift.

Run Lighthouse or your performance monitoring on at least one page per major template and language family. Fonts and localized assets can change page weight significantly.

G. Publishing and operations: 5 checks

• 56. Review status is visible. The team knows what is draft, approved and published.
• 57. Source changes mark affected translations.
• 58. Rollback is possible.
• 59. Errors and untranslated strings are monitored.
• 60. A named owner handles each language after launch.

Localization is continuous. A perfect launch deteriorates if new navigation, campaign banners and product updates bypass the workflow.

Automated tests vs human review

Automation is excellent for:

• missing translations;
• source-language leakage;
• broken links;
• invalid hreflang;
• missing metadata;
• status codes and redirects;
• visual screenshot differences;
• placeholder corruption;
• layout overflow heuristics;
• performance regression.

Humans are essential for:

• meaning and tone;
• cultural relevance;
• persuasion and brand voice;
• legal nuance;
• awkward but grammatically correct text;
• choosing between several valid terms.

The strongest localization QA process combines both. Automate repeatable technical checks and spend human attention on pages where language changes trust, revenue or risk.

A lean pre-launch test plan

One week before launch

Freeze critical source copy, run automated crawls, assign native reviewers and fix all blocker defects.

Two days before launch

Retest pricing, signup, checkout, contact, navigation, SEO tags and the language switcher on mobile and desktop.

Launch day

Crawl live language URLs, verify status codes, inspect hreflang, submit the sitemap and monitor errors, speed and conversion events.

First 30 days

Review search indexing, localized queries, bounce rate, form completion, support feedback and translation edits. Fix patterns in the workflow instead of correcting the same defect page by page.

Testing a LingoJS multilingual website

LingoJS reduces several sources of localization risk by automatically detecting website content, centralizing review and publishing, and handling localized pages, metadata and language routing. Its technology-agnostic snippet also makes it possible to use one workflow across WordPress, Webflow, Shopify, React and custom sites.

Automation does not remove the need for QA. Before launch:

1. review homepage, pricing, signup and legal pages in the dashboard;
2. inspect each language on mobile and desktop;
3. test the language switcher and direct localized URLs;
4. crawl metadata and international SEO signals;
5. assign an owner for ongoing source updates.

Because LingoJS paid plans include unlimited translated words, teams can test and publish long-form content without rationing the audit around a word allowance.

See how LingoJS works on any website or start a free 30-day trial.

Frequently asked questions

Who should perform localization testing?

Use a cross-functional group: a native-language reviewer, QA or web specialist, SEO owner and the person responsible for the user journey. Legal or regulated content needs a qualified specialist.

What is pseudo-localization?

Pseudo-localization replaces source text with expanded and accented characters before real translation. It reveals hard-coded strings, text clipping, encoding issues and layout assumptions early.

How often should a multilingual website be tested?

Run automated checks on every significant release and a focused human review whenever high-value source content changes. Perform a broader audit at least quarterly for active sites.

What are the most serious localization defects?

Broken purchase or signup flows, incorrect legal text, wrong prices, missing localized pages, invalid canonical or hreflang tags, and language switching that loses the current page.

Downloadable mindset: test the journey, not only the words

The final question is not “Was every sentence translated?” It is “Can a local visitor discover, trust and complete this journey as easily as a visitor on the source site?”

Use this checklist as your release gate, adapt it to your stack and keep it in the same workflow as translation—not in a forgotten spreadsheet.