How a global trading platform reviews website changes across 18 languages and multiple locations

The team had just completed a large-scale migration to Webflow, moving 5,800+ pages and 18 language versions across multiple subdomains. Maintaining all of it after launch was the harder problem.

At this scale, a single change to a shared component could ripple across hundreds of pages. A layout that looked fine in English might render incorrectly in French. A cookie banner might disappear in one region and go unnoticed until a visitor ran into it.

The QA and Webflow teams worked together, but their process was manual. A team of four, including two QA engineers and two Webflow designers, checked thousands of pages by hand. It took hours each time.

Environments made it harder. Staging and production had drifted apart in both pages and design, with some changes live on production and others still sitting on staging. Without a full-site snapshot of each environment, the team could not reliably tell which version was current.

They needed a way to confirm that the live site matched their intended design in every language, before publishing.

The site also served a global audience, so they needed to see how it rendered from different regions, since the view could differ from where the team was reviewing.

Their previous visual testing setup was built for developers. It relied on manually created baselines and custom comparison scripts, and it covered only a handful of landing pages. For a full multilingual site, it was too slow and too dependent on engineering time.

Sitepager handled the baseline setup automatically. The QA and Webflow teams could capture staging and production as separate full-site scans by entering their URLs, then review each environment themselves without needing a developer.

That gave the team a repeatable review workflow they could run before every publish.

On one release, a scan caught the main navigation menu missing on mobile in certain languages and locations. Without checking each language version separately, it could have shipped unnoticed. On a site with 20M+ monthly visits, that means meaningful traffic could have hit a broken navigation.

Issues like this are common when changes touch shared components at scale. Catching them before users do is exactly what the review process is for.

Working at this scale surfaced problems smaller teams usually do not run into. The team shared those issues directly, and two Sitepager features came out of that feedback.

The first was page review tracking. Reviews happened across multiple sessions and multiple people, so it was easy to lose track of which pages had already been checked. That led to Mark as Done.

The second was bulk scan runs. Starting scans one by one across every language, device, and environment was slow. The team needed a way to launch multiple scans in one action, so Sitepager added bulk scan runs.

Both features are now part of Sitepager.

What used to take hours of manual checking now takes under 20 minutes of review. Across more than 1,400 completed scan runs and 149,000+ page checks, Sitepager became part of the team’s release review process.

The team now has a structured, repeatable way to review changes across the entire site. Updates to one language no longer require re-checking everything. Each scan is scoped to the pages that matter, reducing noise from sections like the blog or newsroom that change on their own schedule.

Scans run twice a week, aligned with the team’s release schedule. Before any update goes live, there is a clear record of what changed, and every release has a review step.

The workflow stays consistent. Every language version gets reviewed the same way before updates go live.