Let's start with an example: a Turkish manufacturer of furniture fittings decides to expand into the German and UK markets. The website gets machine-translated English and German pages bolted on, two flag icons appear in the menu, and the team waits for orders to roll in. Six months later, here's the picture: a German wholesaler searching for the product still sees the site's Turkish homepage in Google, the English pages barely show up in UK searches, and the rare visitor who does arrive from abroad leaves within seconds. The product is good, the price is competitive - but not a single quote request comes in through organic search.
This isn't a disaster story; it's the combination of problems most exporting SMB sites run into. The issue usually isn't the product or the price - it's that the signals telling Google which page belongs to which market are missing or contradictory. Multilingual SEO is exactly the work of setting up these signals correctly, and it's a step-by-step process, not a one-time technical tweak. This guide walks through that process from start to finish: from deciding on your URL structure, to setting up hreflang, to the difference between translation and localization, to the most common mistakes.
Before You Start: How Does Google Evaluate a Multilingual Site?
Before diving in, it helps to set the right mental model, because most hreflang mistakes come from a wrong expectation. Google crawls, indexes, and evaluates every language version as a separate page. The authority your Turkish homepage has earned doesn't automatically transfer to your German version; the German page competes on its own content, its own links, and its own technical health. The fundamentals of SEO apply the same way in every market; a multilingual structure is a layer on top of those fundamentals, not a shortcut around them.
Hreflang's job is also frequently misunderstood. Hreflang isn't a ranking boost - it doesn't push your pages higher in search results. What it does is matching: it defines the different language and regional versions of the same content as a set, so Google can show the German version to a user in Germany and the English version to a user in the UK. In the opening scenario, the German wholesaler seeing the Turkish page is the direct result of that matching never being set up.
As Google's Search Central documentation states plainly, hreflang is a signal, not a strict directive. If other signals contradict it, Google may disregard your tags - which is exactly why consistency in the setup matters more than getting the markup right just once.
One more critical point: Google doesn't treat different-language versions of the same content as duplicate content. You won't get penalized because your Turkish and German pages describe the same product. The risk shows up in different regional versions of the same language (say, two English pages, one for the US and one for the UK); in that case, hreflang is the mechanism that stops Google from picking one version and ignoring the other.
Step 1: Decide on Your URL Structure - ccTLD or Subdirectory?
The first and most permanent decision in international SEO is your URL architecture, because changing it later means a full-scale migration project. There are three basic options:
- Country-code domain (ccTLD): yourcompany.de, yourcompany.co.uk, and so on. This is the strongest country-targeting signal for Google and builds trust with local users. The cost is heavy: each domain builds its authority from zero, has to earn its own backlink profile, and needs to be managed as an essentially separate site.
- Subdirectory: yourcompany.com/de/, yourcompany.com/en/, and so on. All language versions share the authority the main domain has earned, management runs from a single dashboard, and technical maintenance is cheap. The country signal isn't as strong as a ccTLD's; hreflang and localized content fill that gap.
- Subdomain: de.yourcompany.com. This sits between the two approaches; Google can treat subdomains as separate sites in many cases. Unless there's a genuine technical reason (a different server infrastructure, for instance), it's usually not the preferred choice.
Here's an important, current fact worth knowing: Search Console's international targeting report and country-targeting setting were removed in 2022. That means if you're on a generic .com domain, there's no longer a panel where you can manually tell Google 'this folder targets Germany'. Today, the job of market matching falls largely on hreflang tags, the language of your content, and local signals (currency, address, phone format). That makes getting hreflang right more important than it used to be.
The decision logic for an exporting SMB
In practice, three questions settle the decision. First: are you targeting a country or a language? If you're selling to buyers based in Germany, a country target (de-DE) makes sense; if you want to reach English speakers anywhere in the world, a regionless 'en' version is enough and saves you from unnecessary duplication. Second: do you have a physical operation (warehouse, entity, sales team) in the target market? If you do, a ccTLD investment is worth considering; if not, a subdirectory is almost always the smarter choice. Third: budget and team. For an SMB expanding into two or three markets with limited SEO resources, a subdirectory structure under a single domain is the most efficient way to grow without splitting your authority. If you ever plan to move an existing structure to a ccTLD later, know that it's a serious undertaking - in that case, don't skip the steps in our website migration SEO checklist.
Step 2: Set Up Hreflang Correctly
Once your URL structure is settled, it's time to define the set. A hreflang setup has three components: the right codes, the right implementation method, and reciprocal confirmation.
Choose the right language and region codes
A hreflang value consists of an ISO 639-1 language code and, optionally, an ISO 3166-1 Alpha-2 region code. 'de' targets all German speakers; 'de-AT' targets only German speakers in Austria. Using a region code alone (just 'DE', for instance) is invalid; a language code is always required. For a typical three-market exporter, the set looks like this: 'tr' for the Turkish page, 'en' for the English page, 'de' for the German page, and an 'x-default' version for any user who doesn't match. Adding an unnecessary region code - writing 'en-GB' when you only have one English version - narrows your audience with your own hands.
Pick one of three implementation methods
Google accepts hreflang declarations through three routes, and for the sake of consistency, it recommends using only one:
- HTML link tags: Link tags listing every version in the set are added to each page's head section. This is the most common method on small and mid-sized sites; just remember that adding a new language means updating every page.
- XML sitemap: All language relationships are defined in the sitemap. This is the most manageable method as page counts grow; it doesn't bloat your HTML output and updates from a single central place.
- HTTP headers: Used for language versions of non-HTML files, like PDFs; rarely needed on a typical SMB site.
Reciprocal confirmation and x-default
Hreflang's most critical rule is reciprocity: if your Turkish page points to the German version, the German page must point back to the Turkish version. If these return tags are missing, Google may disregard the declaration entirely - a one-way claim is indistinguishable from another site declaring a version on your behalf without your consent. Every page must also reference itself; the German page's list should include the German version itself. The x-default value defines which version to show users who don't match any language in the set - usually the English page, or a language-selection page if you have one. This setup only works reliably alongside the site's overall technical health; hreflang won't function properly on a site with crawlability or indexing problems. That's why we recommend running a general health scan through our technical SEO checklist before you begin the setup.
Step 3: Localize, Don't Just Translate
Technical setup fixes the signals; but what actually earns rankings in a market is content built for that market. This is exactly where the difference between translation and localization shows up: translation repeats what your Turkish page says in another language; localization answers what the buyer in the target market is actually searching for.
Separate keyword research for every market
This is the step most often skipped. The dictionary translation of the keyword you chose for your Turkish page might be a phrase nobody in the target market ever uses. A German buyer might search with a completely different technical term than an English one; search volume, competition level, and search intent all shift from market to market. That's why every language version needs to rest on its own keyword research, done from scratch for that market. As a concrete rule: before you translate a page, find the search the target market actually uses for it; if you can't find one, don't translate the page - write a new one that answers the question that market is asking.
The machine-translation risk
As of 2026, AI-powered translation tools are impressively capable; but Google's spam policies treat automatically generated content published without human review, adding no real value, as 'scaled content abuse'. Dozens of pages launched via unreviewed machine translation can fall into that definition. This doesn't mean never use machine translation - it means drafting with a machine and then having every page checked by someone who knows the target language and industry is the practical middle ground that removes both the policy risk and the trust problem.
Local signals beyond language
Localization doesn't end with text. Currency, units of measurement, date formats, phone number conventions, shipping and customs information, and certifications relevant to the target market (CE marking or industry standards, for instance) all affect both user trust and how Google associates the page with a market. In an era where AI-powered search summaries (AI Overviews) are becoming common across many countries and languages, this clarity is especially valuable: pages that answer the question directly, in local context, improve their odds of being cited as a source in that language's summaries.
Step 4: Avoid the Most Common Hreflang Mistakes
Hreflang is one of the most error-prone areas of SEO, because mistakes don't break the page - they quietly neutralize it. The site keeps running, but Google ignores the set. Here's what we see most often in audits:
- Missing return tags: The Turkish page points to the German version, but the German page doesn't point back. This is the set's most common breaking point, and it can go unnoticed in Search Console for months.
- Made-up or incorrect codes: Writing 'en-UK' for the UK (the correct code is 'en-GB'), using a nonexistent 'eu' region code to target Europe, or writing a region code without a language code. An invalid code produces the same result as no tag at all.
- Broken targets in the set: Hreflang pointing to a page that redirects, returns a 404, or carries a noindex tag. Google expects every URL in the set to be a direct, indexable page.
- Canonical conflicts: Pointing every language version's canonical tag back to the Turkish main version. This tells Google 'don't index the other versions' and neutralizes hreflang entirely. Every language version should be its own canonical.
- Relative URLs: Hreflang values must be full URLs, including the protocol; relative paths can invalidate the declaration.
- Half-finished localization: Pages where the menu and main copy are translated but product descriptions, form labels, or blog content are still in Turkish. A mixed-language page loses users and makes it harder for Google to determine the page's language.
- Forced IP-based redirects: Automatically redirecting a user to another language version based on location. Since Googlebot crawls predominantly from the US, this setup can keep the bot from ever seeing your other versions. Google's recommendation is to offer a version switcher, not to force a redirect; that's exactly what the flag icon is for.
What all these mistakes have in common: none of them get your site penalized, but each one can quietly push your international visibility toward zero. That's exactly what happened to the company in our opening scenario - not a penalty, invisibility.
Step 5: Measure, Verify, Maintain
A hreflang setup isn't 'set it and forget it'; every new page added and every old version removed affects the set. Maintaining it comes down to three habits.
First, country-level tracking: reviewing the Search Console performance report broken down by country reveals mismatches. If your Turkish page is earning impressions in Germany while your German page sits idle, something's wrong in the set. If reading these reports regularly isn't yet a habit, our guide to using Search Console is a good place to start. Second, spot-checking: running a handful of key pages from each language version through the URL Inspection tool, and periodically crawling for return-tag errors with a crawler tool, catches silent breaks early. Third, process discipline: adding a new page to the hreflang set when it's published, and removing a page from the set when it's taken down, should become a standard step in your publishing workflow.
When measuring success, look at the right metrics too: not total traffic, but clicks, impressions, and quote requests coming from the target country. On a three-market site, that means at least three separate sets of indicators. For businesses without the time or team to run this loop in-house, outsourcing the process is a reasonable option; at Welda, we handle this as part of our SEO and search engine optimization service, covering everything from setup to ongoing monthly monitoring.
Summary: Getting the Order Right in International SEO
To wrap multilingual SEO up as a process, the sequence works like this:
- Start with the right mental model: every language version competes on its own; hreflang doesn't boost rankings, it matches the right version to the right user.
- Decide your URL structure: a subdirectory is the right starting point for most exporting SMBs; a ccTLD is for those with local operations who can invest separately in every market.
- Set up hreflang by the rules: correct codes, a single implementation method, reciprocal confirmation, and x-default.
- Don't settle for translation: separate keyword research for every market, human-reviewed content, and local trust signals.
- Audit for common mistakes, measure country by country, and make the set a standing part of your publishing workflow.
Back to our opening scenario: that company didn't need a new website or an ad budget - it needed the right URL decision, a clean hreflang set, and content written for its market. That trio is usually exactly what's missing on most sites going international.
Welda's SEO team steps in at precisely this point on multilingual projects: we audit your existing structure, help you decide on URL architecture together, set up and verify hreflang, and plan the content side - from keyword research to localization - for every target market. If you'd like to take stock of where your export-focused site currently stands, get in touch with us; we'll pin down where you are and map out a realistic roadmap.