Expanding into a new country sounds easy. Then your website sprouts three English versions, two currencies, and a language switcher that sends everyone straight back to the homepage. The launch stops feeling like growth and starts feeling like an escape room, and your customers shouldn’t need detective skills to find the right page.
That’s where a decent international SEO service earns its keep. It’s less about translation and more about planning: how the site is structured, how matching pages connect, and what someone in Sydney or Kuala Lumpur actually sees when they land.
Meet Wei Ling. She’s made up, but you’ll recognise her: head of marketing at a Singapore software firm that’s about to launch in Australia and Malaysia. Her CEO’s brief fit on a sticky note: “Copy the site. Translate it. Done by Q2.” It turned out to be a bit more involved than that.
A country isn’t a language
This catches almost everyone out. Targeting a country and targeting a language are two separate decisions. Malaysia alone has people searching in English, Malay and Chinese. Meanwhile, one English page could happily serve Singapore, Australia and Malaysia. Muddle the two, and you get pages that look local but don’t really speak to anyone.
Wei Ling started with a simple grid: countries down the side, languages along the top, and notes on what actually differs, such as pricing, delivery, product range and support hours. That grid quickly showed which pages needed their own version and which could be shared.
Her “how to use the software” guide, for instance, worked fine in English for all three markets. The pricing page didn’t, because tax, payment terms, and support hours all changed. Treat every page the same, and you’ll either drown in pointless duplicates or hide the details buyers care about most.
Choose a setup you can actually live with
You’ve basically got three choices: a country domain (example.com.au), a subdomain (au.example.com), or a folder (example.com/au/). Each comes with its own upkeep, reporting, and who-owns-what headaches. The flashiest option isn’t always the one your team can keep running.
Google spells out the trade-offs. Country domains send a strong local signal but cost more and only cover one country each. Subdomains are quick to set up but can leave people unsure whether “my” means Malaysia or Malay. Folders are the easiest to maintain. Google also says URL parameters like ?loc=au aren’t a good idea, and that each language should have its own URL instead of content changing based on cookies or browser settings. That gives your team identifiable pages to manage, and gives visitors somewhere definite to land.
Wei Ling’s company runs one central platform with one small web team, so folders won. If each of your markets runs its own systems with its own people, your setup needs to reflect that before launch, not three months after.
Map the pages before anyone builds them
International sites get much easier once you’ve mapped which pages match which. For each important page, write down the main version, its alternatives, who each one is for and who’s responsible for it. That list becomes the thing everyone works from, whether they’re developers, writers or reviewers.
And no, every page doesn’t need a twin in every market. If a product isn’t sold in Malaysia, don’t build a Malaysian sales page for it just so the spreadsheet looks neat. Coverage should match what the business really offers.
A solid multilingual website strategy also decides what happens when there’s no matching page. Do you hide that option in the language switcher, or explain why it’s missing? Quietly sending someone to a random page fixes the technical problem and creates a confused customer.
AI translation: brilliant first draft, risky final copy
These days most teams start their language versions with AI translation, and for everyday copy it’s genuinely impressive. Wei Ling’s team ran the Malay and Chinese drafts through an AI tool and saved weeks.
But fluent isn’t the same as right. AI translation can sound fluent while quietly getting product terms, legal wording, or tone wrong. It also has no clue whether the support hours or delivery promise it’s translating are actually true in the new market. Her Malay pricing page came back beautifully written, and it promised 24/7 support the Malaysian team didn’t offer. Machine translation keeps getting better, and some people reckon it’s heading towards human-level translation. For pricing, contracts and anything regulated, though, you still want a fluent human to read it before it goes live.
Google makes a related point in its docs. Localised pages only count as duplicates when the main content hasn’t really been translated. A page with a translated menu and English body copy isn’t really a new version. So translate properly, have a person check the bits that matter, then localise the facts.
Get the technical tags right
Hreflang tags tell search engines which pages are language or regional alternatives of each other. They help explain how your versions relate. They don’t translate anything, and they won’t magically make you rank. Think of them as part of a well-built site, not a shortcut.
Google is strict about the details. Language codes follow ISO 639-1 and regions follow ISO 3166-1, so “en-AU” works and invented variants don’t. The tags have to point both ways: if two pages don’t reference each other, Google just ignores them. There’s also an “x-default” option for visitors who don’t match any version, which suits a language-picker page nicely. Build automated checks into your process, because eyeballing a page in the browser won’t catch it. A page can look perfect while its annotations point somewhere entirely different.
Canonical tags are a separate thing, and people often mix them up. A canonical picks the preferred version among near-identical pages. Hreflang describes alternatives for different audiences. Use them carelessly together, and you send search engines mixed messages. Ask your developers to explain the reason behind each important rule, in terms of your actual content and not just “the plugin does it.” Check a range of page types before changing anything sitewide, because what suits a product page might be wrong for a blog post.
And whenever a regional URL changes, every reference to it needs updating. International sites get fragile fast when each edit is treated like it has no knock-on effects.
Localise the stuff that sways buyers
Translation can nail every sentence and still leave the page feeling foreign. Customers hit unfamiliar terms, examples that don’t apply to them or unanswered questions about whether you even deliver to their area. The page speaks their language. It just doesn’t get them.
So focus on what drives a decision: delivery areas, support hours, payment methods, specs and how to ask for a quote. Check those details with the people who’ll actually serve that market, not by peeking at a competitor’s site.
It helps to split shared brand content from local facts. Shared stuff can follow one central standard, while local details get signed off by someone who knows how that market really works. That’s how you avoid promising things the local team can’t deliver.
Let people pick their own page
Auto-detecting someone’s location sounds clever until it sends a traveller to the wrong country’s site, or redirects someone buying for an overseas office. Where a person happens to be doesn’t always tell you which page they want. Google also recommends against automatic redirects, partly because its crawler usually visits from the US without language preferences and may never see your other versions.
Give people a clear, easy way to switch country or language. When there’s a matching page, keep them on it, so switching to “English (Australia)” doesn’t throw them back to the homepage halfway through comparing products.
Test the switcher properly, on different page types and devices. Check what happens when there’s no matching page, or when someone comes back a week later. These little moments reveal problems a homepage check never will.
Test it like a customer, not a developer
“Do the pages load?” isn’t a launch test. Follow the whole journey from a search result to the product page to an enquiry or purchase, and check that the language, currency, promises and destination stay consistent from start to finish.
Wei Ling’s team caught a classic in testing. Someone filled in the form on the Australian service page, and the confirmation email cheerfully listed Singapore office hours. Every page was correct, but the experience wasn’t. Real testing has to include forms, automated emails, and the handover to support.
Split the checking, too. A language reviewer looks at meaning and tone, an operations person checks the offer, and a technical reviewer checks the setup. Expect one person to catch everything, and plenty will slip through.
Keep it accurate once it’s live
A site that launched correctly doesn’t stay correct by itself. Products change, offices move, offers expire, and support hours shift. Without someone owning each market, regional pages slowly become a museum of old promises with perfectly working navigation.
Give every market an owner. Agree which changes need checking across all versions. Keep a list of shared pages and what depends on them, so an update to the English page doesn’t quietly leave the Malay one behind.
And start small. Launch the markets and page types your team can genuinely look after, test the journeys and sort out who maintains what, then expand. Wei Ling launched with Australia first and Malaysia six weeks later. Her CEO grumbled about the delay, right up until the support tickets stayed blissfully quiet. A global website should make buying across borders easier, not turn every small update into an international incident.
Related: RAG Index Stuck on Building? The Real Cause and Fix
