How to Check the Quality and Completeness of Translated Pages

For search engine optimization (SEO) of translated pages, check four things separately: whether the translation preserves meaning, whether the page includes all expected content and functions, whether it fits the intended market, and whether search engines can reach the correct language version. A page can read naturally but omit key details, or contain a complete translation that search engines cannot find.

Localization means adapting content and page details for a specific language or market, such as dates, measurements, examples, and contact information. A reliable review compares the source and translated pages, checks the translated page in its live layout, and then verifies its search access. Each check answers a different question; passing one does not prove the others.

Compare the translated page with the source

Start with an inventory of what the target page should contain. Record the main text, titles and headings, and navigation. Include buttons, forms, notices, and images with text, along with links and relevant page metadata. Note details that need market-specific treatment. These include currency and units, as well as dates, addresses, and phone numbers. Mark each item as present, translated or intentionally unchanged, reviewed, and functional.

Use the inventory to find omissions, not to enforce identical wording or length. Translated text often takes up more or less space than the source, so word-count parity is a poor test of completeness. Compare the information and actions each page needs to provide. If a source page has a pricing explanation and a sign-up form, for example, confirm that the translated page includes both the explanation and working form messages.

A reviewer who understands the target language should compare the translation with the source to check its meaning, terminology, consistency, and fit for the audience. The reviewer should also flag unclear source wording that makes an accurate translation difficult. Review the text in context: a translated button label can be correct in a spreadsheet yet confusing or clipped on the page. Microsoft’s localization testing guidance separates linguistic review from functional and visual checks.

Review the live page, not just the text

Open each translated page in a browser and check its layout and controls on desktop and mobile. Look for clipped text or broken line wrapping. Check for missing characters and incorrect fonts, and inspect images for source-language wording. Test forms and buttons, including messages that explain what users need to correct and those that confirm an action. Follow internal links to check that they lead to the intended language or market.

Check local formats and details as well. A translation can preserve the words while displaying a date, measurement, or contact detail in a form that does not fit the intended audience. For right-to-left languages, review text direction and the layout of mixed-language content. W3C’s internationalization tips cover text expansion and direction, while Microsoft’s guidance includes checks for truncation and fonts. It also covers layout and locale-specific formats.

Automated checks help catch repeatable display or functional defects, but they cannot establish that the translation conveys the intended meaning. Pair them with target-language review and an in-context visual check. The W3C Internationalization Checker can help identify some internationalization issues; its results do not replace a language or usability review.

Check language URLs and search access

Give each language version a stable URL. Google recommends separate URLs rather than serving different language content at one URL based only on browser settings or cookies, because Google may not find every variation. Avoid automatic redirects that prevent a visitor or crawler from reaching another language version. See Google’s guidance on managing multilingual sites.

When pages have language or regional alternatives, use hreflang annotations, page code that lists those alternatives, to tell Google how the URLs relate. The annotations should identify the relevant versions and include the page itself. They should also point to working URLs. Google says each version should refer back to the others so it can understand the relationship. If a page lacks a return link, Google may ignore the annotations. A language switcher should also take visitors to the corresponding translated page when one exists. Google explains the requirements in its documentation on localized page versions.

Treat hreflang as a relationship signal, not a language-quality check. Google says it determines a page’s language from its content, rather than from hreflang, the HTML lang attribute, or the URL alone. Check that the page’s visible content is in the intended language, as well as checking the language annotations.

If you have Search Console access, inspect translated URLs with the URL Inspection tool. Review whether Google crawled the URL and stored the page in its search index. Also check how Google rendered it and which URL Google selected as canonical. A canonical URL is the address Google treats as the main version when similar pages exist. The indexed report shows the last version Google processed. The live test checks the current page, but it does not check every possible issue. Google’s URL Inspection documentation also makes clear that being indexed means a page can appear in Search, not that it will appear for a particular query.

A sitemap can help Google discover URLs and understand language alternatives, but submitting one does not guarantee a crawl or indexing. Google’s sitemap guidance describes sitemaps as a discovery aid, not a guarantee of search visibility.

Interpret the evidence without overclaiming

Each review method answers a limited question. Use the results to identify what to investigate next, rather than treating any one signal as an overall quality score.

Search Console impressions, or how often a translated page appears in search results, and clicks help measure search visibility, not translation quality. Low visibility does not by itself show that the wording is wrong or content is missing. Check language quality and page completeness alongside crawl and index information before deciding what to change.

Google’s spam policies describe a risk when publishers create large numbers of pages mainly to manipulate rankings and provide little or no value to readers. This includes low-value automated changes, such as translation. The policy does not judge a page based on its translation method alone. Assess whether the translated page serves its intended readers and provides useful content. See Google’s spam policies.

Prioritize reviews across many pages

Reviewing every page gives the clearest evidence, but a large site may need to choose which pages to review first. Review high-risk pages first, including pages with payment, safety, legal, product, or conversion-critical content. Add pages with complex layouts, frequent updates, or known localization problems. Then select a random sample across the remaining languages and page types so that the review does not focus only on obvious problem areas.

Record how you chose the sample, what you checked, and which pages remain unreviewed. Sampling helps prioritize work; it does not prove unchecked pages are correct. The Microsoft guidance allows sampling when reviewing every item is impractical, but it does not set a universal sample size or pass-rate threshold. Set your review scope according to the risks and page types on your site, and state what the review did not cover.

What translated-page quality means for AI search

Google says a page must meet Search technical requirements and be indexed to be eligible for its generative AI features. Eligibility does not guarantee that Google will crawl, index, or display the page. That makes search-access checks relevant to a translated page’s potential eligibility, but it does not establish that translation creates AI visibility or that a special optimization technique will help. Google’s guidance on generative AI features emphasizes useful content and does not call for a special page length or a separate writing format for those features.

Key Takeaways

• Compare meaning and required elements: Use a source-to-translation inventory to find omissions, then have a target-language reviewer check accuracy and context.
• Review the live page: Test layout, links, forms, local formats, and language switching in the browser; text review alone misses functional and display problems.
• Check search access separately: Verify stable language URLs, working language links, hreflang relationships, and Search Console crawl and index details.
• Treat metrics as evidence for investigation: Impressions, clicks, and index status do not grade translation quality or explain a performance change on their own.
• Use sampling carefully: Prioritize high-risk pages, include random samples, and record which pages remain unchecked.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com