What to vary by country, and what to keep identical

Two people, one in Dhaka and one in Lagos, read the equivalent page on the same website and come away with different answers about which documents they need. The requirements are identical. One page was updated in March and the other was not. That is the real cost of a multi-country website, and the invoice arrives about eighteen months after launch rather than at the end of the build. We work on the public site of an education consultancy that places international students at UK universities, with an offices directory covering sixteen countries and dedicated sections for seven of them. Almost none of the difficulty is technical.

Localisation is four jobs, not one

People say localisation and mean one of four things. They have wildly different costs and they are worth separating before anyone signs off a budget.

Translation is the words in another language. Expensive to produce and much more expensive to maintain, because every edit to the source creates a queue of retranslations, and the queue is where the drift starts.

Regionalisation is formats: currency, dates, units, phone and address shapes, the order of names in a form.

Local fact is what is genuinely different about operating in that country. Intake dates, the documents required, the name of the school leaving qualification, the office address, the route somebody has to take.

Local proof is the signal that says we are actually here. An office photo, a local phone code, a person who has done this before for somebody like you.

Most requests for a localised site are asking for the third and fourth, and get quoted for the first. Local fact and local proof are what change a reader's mind. A translated page that knows nothing specific about the reader's country is the same page in another language, with double the maintenance attached.

What earns a variant

Content	Vary by country	Why
Description of the service	No	Same service everywhere. Variants will disagree within a year
Steps of the process	No	Same, and this is what people are trying to understand
Office address, hours, phone	Yes, as data	Changes independently of anything else. Belongs in a record, not in prose
Application form fields	Yes, as configuration	Qualification names and document lists genuinely differ
Deadlines and intake dates	Yes, as data	Time sensitive, and wrong is much worse than absent
Testimonials and photography	Yes	This is the local proof, and it is the reason the page exists
Legal and privacy notices	Yes, carefully	Governed by law rather than by marketing
Fee model	No, unless it really differs	If the service is free everywhere, say that once
Frequently asked questions	Shared list, local additions	Additions only. Never a full local rewrite

The rule under the table: anything that is true everywhere must be stored once and rendered many times. A fact written into sixteen pages will be wrong in some of them inside a year, and you will hear about it from a customer rather than from a test.

Hold the variance as data

The technique that keeps this manageable is one template and a record per country, rather than sixteen pages somebody wrote by hand.

type CountryVariant = {
  code: 'BD' | 'NG' | 'PK' | 'IN' | 'NP' | 'LK' | 'EG';
  officeIds: string[];       // resolved against the offices directory
  formVariant: 'south-asia' | 'west-africa';
  intakeNote?: string;       // short, local, time sensitive
  proof: { testimonialIds: string[]; photoId: string };
  localFaq: FaqItem[];       // additions to the shared list, never overrides
  reviewedOn: string;        // ISO date, and not optional
};

Two properties of that shape matter more than the fields in it.

Anything absent from the record is identical by construction. A change to the wording of a shared step is one edit that ships everywhere, and no country can silently fall behind because there is nothing local to fall behind with.

The local list adds rather than overrides. An override is the mechanism by which one country ends up still describing a service that was withdrawn last spring, and it will not be found by anyone reviewing the shared content, because the shared content is correct.

Then there is reviewedOn, which is the field everybody leaves out. Country content is perishable and nothing about a stale page announces itself. Store the date, and render it in small print at the foot of the page. A page saying it was last reviewed in March 2025 is more useful to a reader than one silently pretending to be current, and more importantly it makes the drift visible to the person who can fix it.

Where the maintenance multiplies

Do the arithmetic before agreeing to the structure, because it is not intuitive.

Seven country sections, four page types each, one application form each. That is twenty-eight pages and seven forms. A change to one shared sentence is one edit if the sentence lives in one place and twenty-eight if it does not. Add a second language and multiply the whole thing again.

The multiplier that catches people out is not authorship, it is review. After any change somebody has to read all twenty-eight and confirm they still agree with each other. That job has no owner by default, which is precisely why it never happens.

Two rules help more than any tooling. Every country variant has one named owner, and if you cannot name that person the variant should not exist. And any variant not reviewed in twelve months is either finished or abandoned: find out which, and delete the abandoned ones. Fewer current pages beat more stale ones, for readers and for search engines alike.

Near-identical pages in the same language

Country variants written in the same language are the awkward case, because you have several very similar pages competing for the same queries.

Publish a variant only where it genuinely differs. If the Nigeria page is the UK page with a different photograph, it is not a page, it is a liability.

Declare the set with hreflang, including an x-default, and make the annotations reciprocal. Non-reciprocal hreflang is ignored, and half the implementations we have looked at are non-reciprocal.

Accept that a search engine may still show one variant to everybody. Country pages earn their traffic from campaigns, counsellor links and local sharing, not from outranking your own other pages on a generic phrase.

The drift you can see from outside

The most visible form of this problem is numbers. On the sites in this group, the counts of partner institutions, offices, staff and enrolled students do not agree between the homepage, the about page and a sister site covering other destinations. Not one of those figures was wrong when it was written. Each was accurate on its day, then one of them was updated and the others were not.

This is not unusual, it is close to universal in any organisation running more than one website. We have not repeated any of those figures in our own description of the work, and the fix is the same as everywhere else in this post: one source, rendered in many places, with a date attached.

Two systems, two release cycles

The last piece interacts with all of the above. The marketing site and the student application portal are separate systems, on separate hosting, with separate release cycles.

That separation is worth defending. Marketing pages change constantly, often in a hurry, often at the hands of people who are not engineers. An application in progress is somebody's visa timeline. Couple them and a rushed content deploy can interrupt a student halfway through a form, while a portal release has to be scheduled around a campaign.

Localisation strengthens the argument. Country variance in marketing content is copy and configuration, and the worst case is an embarrassing page. Country variance in an application flow is validation rules, document lists and states that real users are already sitting in, and the worst case is somebody's application. Different risk, different cadence, different deployment.

The site described here is AHZ Associates.