The site exists in thirty country versions. Twenty-six of them are the same English text with a different phone number in the footer, generated automatically when the region was added to the system. All thirty compete with one another for the same wordings, and the one that surfaces for a buyer in one country is regularly the version written for another.
This is what a global site looks like after a decade of adding markets, and nobody decided on it. Each country version was created because a country needed a presence, the fastest route was to clone the template, and the alternative — writing genuinely different material for thirty markets — was never funded. The result is technically correct, commercially defensible, and structurally the worst possible arrangement.
Thirty versions, four of them different
Nobody discovers this through falling numbers. It shows up as a complaint from a country manager: a customer found the wrong country's page, saw prices in the wrong currency or a contact who cannot serve them, and gave up. Everyone treats it as an isolated case. It is not — it is what happens when thirty near-identical pages compete and the system has to pick one.
| Country version | How it differs | How the system reads it |
|---|---|---|
| The four large markets | Own text, own examples, own contacts | As four distinct pages |
| Markets with translated text | Genuinely different language | As distinct, if declared correctly |
| English clones with local footer | A phone number | As near-duplicates of each other |
| Versions created and never filled | Placeholder text still in place | As thin pages, if at all |
Row three is the largest group and the one causing the damage. Twenty-six versions of the same English page do not divide the audience between them; they compete, and the system resolves that competition by choosing one and largely ignoring the rest. Which one it chooses is not something the regional office influences, and it frequently is not the one a given buyer needed.
The markup that pairs the versions
Every version names all the others
Each page declares its counterparts in the other markets, all pointing at addresses that resolve directly, and each declaration is returned in kind.
- Versions stop competing
- Each is served to its own market
Declarations that point nowhere
Half the pairs reference addresses changed in the last migration, or declare a counterpart that does not declare back. The whole set is then disregarded.
- Versions keep competing
- Invisible without checking directly
This is the single highest-return technical item on an international site and it is almost never verified after launch. The declarations are set up once, they work, and then a migration renames a section on four country versions and half the pairs break silently. Nothing reports the failure. The only symptom is that the wrong country's page starts appearing, which gets attributed to almost anything else.
The submission limits, plainly stated
Daily rate and batch size
On a thirty-country site these are genuinely binding, unlike on most sites.
- One thousand a day, belonging to the account. Everything held under it draws from the same figure — thirty country versions of the same site included.
- A batch holds up to ten thousand. Accepted whole, then processed against the daily limit, which puts ten thousand at roughly two working weeks.
- Two processing, twenty queued. Where thirty markets each want something submitted, the order has to be set by somebody rather than by filing time.
- Three levels of nesting, a thousand sitemaps per batch. Adequate for a country-by-country structure, provided each country index is actually linked.
What thirty versions cost in capacity
The multiplication nobody performs before planning a migration.
- Four hundred pages times thirty countries is twelve thousand addresses. At the daily rate that is twelve days for a site holding four hundred pages of distinct information.
- A template change touches all thirty at once. Which is exactly what a global relaunch is, and why they run so much longer than the plan allows.
- Resubmitting everything on every release. A pipeline that files the full set whenever the template changes will occupy the queue permanently.
- Filing before the declarations are repaired. Submitting thirty competing versions makes the competition faster, not smaller.
These figures explain something regional offices experience regularly and rarely understand: a global relaunch announced for six weeks takes four months, and nobody at headquarters can say why. The arithmetic above is usually the whole answer, and it is available before the project starts to anybody who divides page count by country count by daily allowance.
Markets where the content genuinely differs
A different language, different regulation, different availability, different pricing. Each of these gives a version something to say that no other version says.
- Six to eight of them, typically
- Declare and submit deliberately
Markets differing only in contact details
One regional English version, with a contact page per country carrying the local details. The information survives; the duplication does not.
- Twenty or more of them
- Retire and redirect
Not every market needs a full copy
The uncomfortable resolution is that thirty country versions is the wrong number for almost every group. A version is worth having where something about it genuinely differs — language, pricing, regulation, product availability, service capability. Where the only difference is a phone number, a version is a liability rather than an asset.
| Situation | Treatment | Reasoning |
|---|---|---|
| Different language | Full version, declared correctly | Genuinely serves a different audience |
| Different regulation or availability | Full version, own text | The content genuinely differs |
| Same language, only local contacts | One regional version plus a contact page | A phone number is not a page |
| Created and never filled | Retire and redirect | A placeholder helps nobody |
Recording the decision per market in a shared overview — which versions survive, which are retired, and why — stops the next country launch from cloning the template again out of habit.
Applied honestly this typically reduces thirty versions to six or eight, with the remaining markets served by a regional English version carrying a proper contact page per country. That is a smaller site, a faster migration, and — the part that persuades headquarters — a set of pages that no longer competes with itself.
It is worth being clear about what is not being proposed. Nobody loses a local presence in this arrangement: the contact page for each country remains, with the local numbers, the local address and the local team named on it. What disappears is a duplicate copy of the product description that differed from twenty-five others only in its footer. Framing the change that way matters, because framed as "removing your country's website" it will be refused in every market simultaneously, and framed as "removing a duplicate that was competing with yours" it usually is not.
The versions nobody ever finished
Every large rollout leaves them: country versions created when a market was added to the plan, populated with placeholder text or with an untranslated copy, and never completed because the market opened later than expected or not at all. They sit live for years, carrying the brand and containing nothing.
- Find them by looking for the placeholder wording. Whatever the template used — a stock sentence, an untranslated heading, a contact block with no number. One search finds all of them at once.
- Retire rather than complete. Completing thirty of them is a translation project nobody will fund. Retiring them is an afternoon and produces most of the benefit.
- Redirect to the regional version. Not to the global home page. A visitor who reached a country page wanted that region, and the regional English version is the nearest honest answer.
- Remove them from the declarations too. A declaration pointing at a retired version is worse than no declaration, because it can invalidate the whole set for that page.
The fourth point is the one that gets missed and then causes a fortnight of confusion. Retiring a version without removing it from the pairing markup leaves every remaining version declaring a counterpart that no longer resolves — and where the declarations are inconsistent, the system commonly disregards all of them. The clean-up and the markup change belong in the same release. Tracking which versions have been dealt with in one workspace keeps a job spanning thirty markets from stalling at market eleven.
There is a further category worth checking while the placeholders are being found: country versions for markets the group has since exited. They behave identically — live, carrying the brand, describing an offering nobody can buy — and they additionally create a support problem when somebody in that market makes contact. The same afternoon's work covers both, and the list of exited markets is one the regional office can produce in minutes.
Redirects multiplied by thirty
A global site that has been through one platform migration accumulates redirect chains, and here every chain exists thirty times over. The migration pointed old country paths at new ones; a later restructure moved the new ones again. What remains are addresses passing through two or three stops, replicated across every market.
Here, unlike on a small site, the wasted capacity is significant. Eight hundred legacy addresses per market across thirty markets, each resolving through two hops, asks for roughly seventy-two thousand requests where twenty-four thousand would do. Against a daily allowance of one thousand, that difference is measured in weeks. Collapsing the chains is scripted work — the pattern is identical in every market — and it returns the capacity immediately.
One further note on chains: on a site of this shape they should be checked after every platform change rather than once. Each migration adds a layer, and a layer on top of an existing chain lengthens it instead of replacing it — thirty times over. An automated test that fails the build when any address resolves through more than one hop takes an hour to write and prevents the problem from ever accumulating again, which on a thirty-country site is worth considerably more than the hour it costs.
Establishing that anything changed
Submitting an address is a request and guarantees nothing. Confirmation arrives only when it appears in reporting with impressions attached, and that takes weeks. In between sits a blank period in which nothing can be established — and that is exactly where teams resubmit out of impatience, spending capacity that a thirty-country site cannot spare.
A workable discipline: submit once, wait a full week, then check coverage. Where a fortnight has passed and a correctly submitted address is still absent, look at the page rather than the process. On an international site the usual answer is the third possibility — the page is a near-duplicate of twenty-five others, and the system has chosen a different one. Following the sequence inside a connected environment shows which case applies, without a spreadsheet alongside.
Doing the steps in a workable order
Order counts for more here than on any single-market site, because each stage invalidates the measurements before it. Submitting before the duplicate versions are resolved wastes the submission thirty times over; repairing declarations before deciding which versions survive means repairing declarations twice.
| Step | Task | Effort |
|---|---|---|
| One | Confirm the text ships in the delivered source | A morning |
| Two | Decide which country versions genuinely differ | A day with the regional managers |
| Three | Retire the placeholders and near-duplicates | An afternoon, scripted |
| Four | Repair the pairing declarations across the survivors | Development work, one week |
| Five | Collapse redirect chains, then submit | Days, against the allowance |
Step two is the only one requiring a decision rather than execution, and it is the one that stalls. It needs regional managers to accept that their market does not warrant its own English copy, which is easier to obtain when the argument is presented as pages competing with one another rather than as a market being downgraded. Which country wordings are genuinely reachable per market comes from keyword research rather than from the sales plan; whether the pages ship correctly is a technical review matter; and what the surviving country pages should actually contain belongs to content strategy. Running all three from a single account keeps the sequence intact.
A closing note on expectations, because this work is unusually easy to misjudge. Consolidating country versions does not create new demand. It stops existing demand being divided between pages that were competing with one another, and it makes the surviving pages the ones buyers actually reach. The effect therefore shows up less as growth in the aggregate and more as a redistribution: the retired versions fall to zero while the survivors rise. Anybody looking only at the total will conclude nothing happened. Anybody looking market by market will see the point of the exercise, which is one more reason the market split described earlier has to exist before the work starts rather than after it.
Check which country version is actually surfacing
Questions from regional and global teams
Should every market have its own version?
Only where something genuinely differs — language, regulation, availability, pricing. Where the only difference is a phone number, a version competes with twenty-five others for the same wordings and none of them wins. One regional version plus a proper contact page per country serves those markets better and is a smaller site to maintain.
Our pairing declarations were set up at launch. Do they still work?
Check rather than assume. Every migration and every section rename breaks some of them silently, and where the declarations are inconsistent the whole set for that page tends to be disregarded. The check is mechanical — every declared counterpart should resolve directly, without a redirect — and it belongs in the release checklist rather than in an annual audit.
Does each country version get its own daily allowance?
No. The allowance belongs to the account and thirty country versions draw from the same thousand a day. This is why a global relaunch announced for six weeks takes months — four hundred pages across thirty markets is twelve thousand addresses, which is twelve days at best and considerably longer in practice.
What do we do with country versions that were never completed?
Retire them and redirect to the regional version, not to the global home page. Then remove them from the pairing declarations in the same release — a declaration pointing at a retired version can invalidate the entire set for that page, which turns a clean-up into a fortnight of confusion.
A page has not appeared two weeks after submission. Why?
On an international site the usual cause is that it is a near-duplicate of twenty-five other versions and a different one was chosen. Check that before anything else. The other two possibilities — nothing links to it, or the content is assembled in the browser — apply as well but are less common here.
How do we persuade regional managers to give up their version?
By presenting it as competition rather than as a downgrade. Twenty-six identical English pages do not each serve their market; they compete, and the system picks one. Showing which version currently surfaces in a given market usually settles the discussion faster than any argument about resources, because it demonstrates that the version being defended is already not the one buyers see.