# Validate localized web content across routing contexts

Compare regional page content with controlled routing, language, and session assumptions. Record evidence without confusing preferences with verified outcomes.

Canonical: https://runharvester.com/use-cases/localized-content-validation

By: [RunHarvester](https://runharvester.com/about-us)

Updated: 2026-10-03

## Change one condition at a time

This example workflow compares localized content; it does not report a customer result. Geography is only one input to localization. A website may also use language headers, cookies, login state, or its own account preferences.

Set the expected language, currency, or availability for each test. Keep the URL and other conditions stable while altering the supported geographic routing preference. Validate returned routing metadata and page content independently.

1. Select regions that are actually available to the account.
2. Document language, session, and authentication assumptions.
3. Submit equivalent requests and retain their IDs and observation times.
4. Extract the visible language, currency, and availability indicators.
5. Investigate differences before treating them as a localization defect.

## Use browser rendering only when needed

If regional content surfaces after JavaScript execution, employ browser acquisition and supported waits. If values are already in the initial HTML, test if HTTP suffices. Residential routing and browser execution handle different segments of acquisition.

A target may ignore the requested geographic context or show a consent or challenge page. Record that as an inconclusive check rather than a pass or a regional product outage.

## Keep evidence interpretable and private

Store the minimum evidence needed to explain a difference. Avoid placing cookies, API keys, private page results, or expiring signed evidence links in shared reports.

For versioned interaction sequences, use Browser Workflows and its run trace. Keep comparison logic in your application and define how expired results and partial failures affect the final verdict.

- [Browser workflow evidence](https://docs.runharvester.com/concepts/browser-workflows)

## Can RunHarvester scrape JavaScript-rendered pages?

Browser mode runs the page within a browser environment. Set up supported wait conditions for the desired content and verify the outcome. Rendering a page doesn't ensure all lazy-loaded elements are visible or that the target service accepted the request.

[Documentation](https://docs.runharvester.com/concepts/protected-requests)

## Can I choose residential routing and a geographic target?

Data API capabilities include both residential and residential_browser routing modes. Available geographic options and inventory vary based on your deployment and account setup. Review the active routing contract and metadata; noting a geographic preference does not guarantee localized content delivery from the target site.

[Documentation](https://docs.runharvester.com/concepts/residential-routing)

## Where should I keep API keys?

Store API keys securely in a server-side secret manager and assign only the necessary scopes for the integration. Avoid placing credentials in public frontend code, documentation examples, or logs. Browser Workflow keys and scopes are scoped to their specific project and environment.

[Documentation](https://docs.runharvester.com/getting-started/authentication)

## Continue reading

- [Proxy routing](https://runharvester.com/proxy-network)

- [Browser Workflows](https://runharvester.com/browser-workflows)

[Source: RunHarvester documentation](https://docs.runharvester.com/concepts/residential-routing)