Search for evidence that localizing a product grows it and you will find plenty of numbers. Try to check one and most of them come apart in your hands: no window, no instrument, no reachable source, or a vendor quoting a customer who never published anything themselves. globalize.now is AI-powered localization infrastructure, and we keep a tracker of the cases that survived a check, because our other posts cite them and you are entitled to see the working.

This page is that tracker, opened up. Three neighbouring questions already have their own pages and this one does not repeat them. Whether translated pages help you in search, and what has to be true technically, is does localizing your app help SEO. What the playbook earned when a funded team ran it is the growth playbook then and now. Whether this is a tactic one person can carry to a finish is the sorting test. This page is about the evidence underneath all three.

What does a number have to do to get used here?

Four things, and a figure that misses any one of them gets cut rather than softened.

It needs a source you can open, not a citation of a citation. It needs an observation date, because a traffic figure is a reading taken on a day and not a property of the company. It needs a named instrument: Search Console, GA4, a sitemap crawl, somebody's own dashboard. And it needs its caveats travelling with it, in the same sentence, rather than parked in a footnote where the figure can be lifted away from them.

Each case also carries a status. Verified means a primary or first-party source that we fetched on the date shown. Secondhand means a vendor or press retelling, usable only while labelled as one. There is a third status, ours, for a first-party customer result. Nothing holds it yet, and the section at the end of this page says so plainly.

The rule that does the most work is the dull one: re-fetch on the day you publish. Vendor case-study pages get edited quietly, and a claim that no longer resolves gets removed from the post rather than hedged.

Case one: how good is the vendor case study everyone cites?

Status secondhand, and it is still the strongest outcome figure anyone has published.

As reported by OneSky's published case study for Smallpdf, re-fetched on 15 October 2026, monthly users over SEO rose by 60%, going from 6 million in 2016 to over 9.5 million in 2017. Over 70% of users were from non-English speaking countries, and Thai was the most lucrative of the three languages added, with an increase in user base of over 500% in traffic in one year. Smallpdf offered its services in 17 languages at that point. All of it is one vendor's account of one customer over one year.

Now the part that shows you what checking actually involves. That same page disagrees with itself. The banner at the top says 20 Languages. The body, in the sentence about turnaround, says all 17 languages. Both have been on the page since we first read it on 23 September 2026 and both were there again this week. We use 17, because that is what the tracker records and that is what the sentence carrying the operational detail says. We are not going to quietly pick the bigger number, and we cannot resolve the difference without a source that does not exist.

Two further claims attached to this case were cut, not softened. A peak monthly revenue figure and a profitability claim appear only in a company profile behind a paywall, and no public URL for them resolved on re-check. Nothing in any of our posts rests on them, and we are not repeating the figures here either.

Case two: what changes when the number is ours, not theirs?

Status verified, and worth reading for its provenance rather than its size.

Localazy is running the free-tool and language matrix inside this category at a scale nobody else here is. The counts in our tracker come from a sitemap crawl on 28 August 2026: 757 pages under a convert path, 1,705 under a translate path, and roughly 14,000 indexed URLs in total. A keyword pull on 23 September 2026 attached a second, independent reading to the same row.

The honest label on this one is that it is our measurement, not their claim. Localazy never published it. That cuts both ways: there is no vendor interest bending the number, and there is also nobody to correct us if the crawl missed something. Page counts from a sitemap are a snapshot of a day, which is why the row carries two dates rather than one. If you quote it, quote the dates with it.

Case three: what does a trustworthy write-up look like?

Status verified, and the most useful case we hold, mostly because of how he wrote it up.

Ken Imoto translated his blog into four languages through what he describes as a cross-language LLM pipeline, hand-edited afterwards for register and locale. His GA4 figures, as published on dev.to and re-fetched on 15 October 2026, cover a window he states as 2026-04-30 to 2026-05-21, 22 daily snapshots: Portuguese 748 pageviews and 709 sessions, English 195 and 176, Japanese 27 and 29, Spanish 7 and 7. His article counts at the time were 26 in English, 25 in Japanese, 17 in Portuguese and 10 in Spanish.

He titles the section that follows those figures "The setup, so you can discount my numbers properly", and opens it with "This is not a clean comparative experiment." That sentence is why the row is verified. He states the window, names the instrument, gives the article counts that make the comparison uneven, and tells you himself that there is no before-and-after on the same content and no pre-localization baseline. We added no caveat he had not already written. We only declined to derive a per-article figure, because he gives no normalisation and inventing one would turn his snapshot into a rate.

Spanish is the part that matters. Seven pageviews in three weeks, from ten translated articles. One of his four bets returned nothing, and he published that alongside the one that worked instead of leading with the average.

One figure in that same post is cut: a single Portuguese article's pageview count, which he quotes with no window attached. It is a real number in a verified post and we still cannot use it, because we cannot say what period it covers.

Case four: what did the case that ran the other way show?

Status verified, and it is in the tracker precisely because it points in the opposite direction.

The site behind Field Notes #3 on dev.to, re-fetched on 15 October 2026, is a solo developer's self-described agent-run site whose blog is translated by an AI pipeline. He cut twenty-one languages to six. In his words, "The cut landed on September 24", and the retained set is English, French, Spanish, Russian, Chinese, Arabic. The reason he gives is quality rather than traffic.

His Search Console figures are where the checking gets interesting. Over the trailing 28 days as published on 4 October 2026, the five kept locales drew 493 impressions and 6 clicks, and the deleted set, counting the twelve the report shows, drew roughly 850 impressions and 7 clicks. Four things have to stay attached to those numbers. He flags himself that the window straddles the cut, so part of the deleted set's count covers pages that were still live. The absolute volumes are six and seven clicks, which is too small to carry an argument in either direction. "Roughly 850" is approximate as he published it, so it stays approximate here. And his post says five kept locales while naming six, a mismatch we are not going to resolve or normalise on his behalf.

His own headline says the traffic barely noticed. His own numbers, in the same window, have the deleted languages out-impressioning the kept ones. We report the contradiction rather than picking the side that suits us, because he published the figures that undercut his framing and that is the behaviour this tracker is trying to reward.

An earlier traffic ledger in his writing covers a different month. It is absent from our posts entirely, rather than quoted with a disclaimer, because stitching two windows together is how a trend gets invented.

What did not make it into the tracker, and why?

Four cuts, and the pattern behind them is worth more than the cases themselves.

No date means no entry. A percentage with no window is unfalsifiable, which makes it useless rather than merely weak.

A paywall is not a source. If the only place a figure lives is behind a login, nobody reading your post can check it, and that is the entire job of a citation.

Different windows do not combine. Two true numbers from two periods produce a third number that nobody measured.

And the failure mode that now costs the most time: posts built to look like first-party case studies. Numeric headline, a dashboard named, a confident window, an author presented as a solo builder. We walked one of these all the way to verification this month and cut it, because the one component we could check independently was not present on the live site the post was describing. We treat that as unverifiable rather than as false, which is the only fair verdict available, and we do not name it. The practical warning is the one that generalises: these pages rank well, they are written to answer exactly the query you would type while looking for evidence, and you will usually meet one before you meet anything real.

So how should you judge the next claim you read?

Open the source, then ask the four questions in order.

Is there a date on the figure? If not, stop. Everything after this point assumes there is.

Who measured it, with what? A named tool with a window you can picture beats a styled statistic on a landing page, every time.

Did the author write the caveats, or are you supplying them? A case study that tells you where it is weak is doing something that costs the author something. That is evidence of good faith, and it is rarer than the numbers.

Does the window match the claim? Most of the damage in this category comes from a figure that is true of three weeks being read as though it were true of a year.

And one more, which only applies if you are about to act on it: does the author gain if you believe it? That is not disqualifying. The strongest case in this post is a vendor's. It just changes the label from first-party to secondhand, and it changes how loudly you are entitled to repeat it.

What can we not tell you yet?

We have no numbers of our own in this tracker, and we are not going to imply that we do.

Two customer case studies are being measured now. Until they are finished and dated, every figure here belongs to somebody else, carries whose it is, and carries the date it was last checked. When our own results land they will go into this same list, under the same status rules, including whatever in them does not flatter us.

What does it cost to produce a number of your own?

The measurement is the slow part now. The translation is not.

globalize.now converts a codebase once, in the in-app connect flow. That conversion is a single operation rather than something that runs on a schedule. Push jobs translate new catalog units as they appear afterwards, and what comes back is standard JSON or PO, the formats your i18n library already reads. Nothing about your runtime, framework or deployment changes, which is also what makes adding a locale for a quarter and reading the result a reversible thing to do. The developer and vibe coder pages cover the setup.

Pricing is on the pricing page and this page is not going to paraphrase it.

Where does this leave you?

Four cases is not many, and that is the finding. This category has been telling people to localize for a decade on the strength of a handful of numbers, most of which cannot be opened, dated or questioned. The ones that can be are smaller, messier and more useful than the headline versions, and two of the four were published by people working alone who had nothing to sell you. Check the next one you read against the four questions above. If it survives, it is worth acting on. If it does not, you have saved yourself a quarter.

globalize.now turns hardcoded app copy into translation-ready locale files and keeps them updated as you ship.

Try globalize.now free