Selling into more than one country means telling Google which version of a page belongs to which market. Get it wrong and your regional sites compete against each other instead of your competitors.
These get treated as the same question and they aren't. Getting this wrong is the reason most international setups end up more complicated than they need to be.
One version of the site per language, serving everyone who speaks it regardless of where they are.
Right when your product, pricing, and terms are the same everywhere. A software company selling the same subscription worldwide usually only needs this.
A separate version per market, even where two markets share a language.
Right when prices, currency, stock, shipping, or legal terms differ by market. Three English versions is not duplication, it's three different offers.
Most companies need fewer versions than they first plan. Every extra one is another set of pages to write, maintain, and keep in sync, and a market you can't properly serve yet doesn't benefit from having a page. We'd rather start with two done well than six half finished.
This decision is hard to reverse later, so it's worth spending an hour on now rather than discovering the constraint in two years.
yoursite.de
Pick this whenLocal trust genuinely matters, or a market legally requires a local presence. Each domain starts from zero and has to earn its own links.
yoursite.com/de/
Pick this whenAlmost always, and it's what we recommend by default. Everything sits on one domain, so links earned anywhere help everywhere.
de.yoursite.com
Pick this whenDifferent markets run on separate systems or separate teams. A middle option, and usually chosen for technical reasons rather than SEO ones.
If you already have country domains and they're working, we wouldn't move you. Consolidating is a large migration with real risk, and the gain rarely justifies it unless several of those domains are sitting unused. This decision matters most when you're setting up for the first time.
These are the tags that tell Google "this page and that page are the same thing for different markets". The idea is simple. Implementing it across a few hundred pages is where it goes wrong.
Every version points at every other one
Including at itself. Missing one direction breaks the whole set.
Plus a fallback. One version marked as the default for anyone whose country doesn't have its own page. Skipping this is one of the most common gaps we find.
en-uk isn't valid, it's en-gb. Invalid codes are silently ignored rather than flagged, so the tags look fine and do nothing.International SEO attracts a lot of outdated advice. These four come up on nearly every project.
"Three English sites will be penalised for duplicate content"
Actually
There's no duplicate content penalty. The real risk is Google picking the wrong version to show, and that's exactly what hreflang exists to prevent.
"We need servers in each country"
Actually
Server location stopped being a meaningful signal a long time ago. What matters is that the site loads quickly in that market, which a content delivery network handles.
"Redirect visitors automatically by their location"
Actually
This causes real problems. It stops search engines seeing your other versions, and it traps travellers and anyone using a VPN on a site they didn't want. Suggest, don't force.
"Machine translation is good enough now"
Actually
It's fine as a starting draft and it doesn't know what people in that market search for. Translated pages target translated words rather than the terms locals actually type.
Structure first, because everything after it depends on getting that right.
Which countries you can genuinely serve now, based on demand and on whether you can actually ship, support, and invoice there.
Language or country, and which URL approach. Agreed with you and with whoever builds the site before anything is created.
Keywords researched in that language by someone who speaks it, not translated from your English list. The terms are usually different.
Hreflang added, then checked with a crawl rather than assumed. Search Console set up per market so each can be monitored on its own.
Often not. If your offer is identical everywhere and you're in one language, a single site can serve multiple countries perfectly well.
It becomes a problem when prices, currency, shipping, or legal terms differ. At that point visitors from the wrong market are landing on information that isn't true for them.
No, and starting with everything is how these projects stall. Begin with the pages that matter commercially: your main services or products, pricing, and contact.
A half-translated site where the important pages are properly done beats a fully translated one where everything reads like a machine wrote it.
Search Console reports errors, and a crawl of the site will find missing return tags and invalid codes faster than waiting for reports to update.
The practical symptom of it not working is seeing the wrong version of a page ranking in a market, or two of your own pages appearing for the same search.
Not as your international strategy. A translation widget doesn't create pages that can rank, because there's nothing for search engines to index in that language.
Machine translation as a first draft, then edited by someone who speaks the language, is a reasonable and much cheaper middle path.
Worth flagging early, because in some markets a different search engine holds most of the traffic and the rules differ considerably.
We work primarily with Google. If your target market is one where that isn't the main engine, we'd tell you that we're not the right people for it rather than take the work.
Yes, and it's most of this work. The usual findings are broken return tags, invalid codes, automatic redirects hiding half the site, and a missing fallback version.
Those are all fixable without changing your structure. Changing structure is a separate and much larger decision, covered under technical SEO.
It sits on top of the normal technical and on-page work rather than replacing it. Pricing sits on the main SEO page.
Other SEO services
Thirty minutes on the structure, what it costs to maintain, and whether you need it yet.
Or email hello@culmen.digital