Hreflang, Domains and Setup: The Technical Side of Multilingual SEO

You have already decided to publish in more than one language. What remains is the part that silently decides whether the work pays off: the URL structure, the annotation that tells search engines which version belongs to which audience, and the canonical rules that keep near-identical pages from competing with each other.

This is where multilingual projects break. The content gets written, the pages go live, and then the wrong language version shows up in the wrong country, or two versions of the same article fight over the same query, or the whole language folder sits unindexed for months because nothing ever linked to it. None of these are content problems. They are setup problems, and they are cheap to avoid at the start and expensive to repair later.

If you are still weighing which markets deserve a blog and how to plan coverage across them, that reasoning belongs to the strategy layer — the same layer described in how topic clusters and pillar pages structure a blog that actually ranks. Here the assumption is that the decision is made. What follows is implementation: the structure choice and its consequences, hreflang written correctly, the WordPress patterns that hold up, and the duplicate-content rules that apply when the same article exists in eight languages.

Which URL structure should a multilingual blog use

Three structures are available, and the choice is close to permanent. Migrating language versions between structures later means redirect chains, re-indexing, and a visibility dip you have to budget for. Decide once, deliberately.

Country-code top-level domains

A separate domain per country — a .de, a .fr, a .es — gives the strongest geographic signal available and the clearest legal separation if different entities own different markets. It also multiplies the work: each domain builds authority from zero, with its own backlink profile, its own hosting, its own certificates, its own analytics property.

For a blog whose purpose is organic visibility, this is usually the wrong trade. Authority does not transfer between domains, so a company with eight ccTLDs is running eight small sites instead of one strong one. Pick this route when a legal or commercial reason forces it, not for SEO reasons.

Subdomains

A subdomain per language — de.example.com — separates the versions cleanly and makes it easy to point each one at different infrastructure or a different CMS install. Crawlers treat subdomains as related but partly distinct properties, so authority consolidation is weaker than with subfolders and stronger than with separate domains.

Subdomains make sense when the language versions are genuinely managed by different teams, run on different stacks, or need independent deployment cycles. They are also the natural fit when one language version is a full site and another is only a blog.

Subfolders on a single domain

A path segment per language — example.com/de/ — keeps everything on one hostname. Every link earned in any language strengthens the same domain. It is the simplest structure to host, the simplest to secure, and the simplest to measure, because one property covers the whole project.

For most companies publishing a multilingual blog, subfolders are the default answer. The geographic signal is weaker than a ccTLD, but hreflang supplies that signal explicitly, which is precisely what it exists for.

The table below condenses the comparison for the decision meeting.

Structure	Pick it when	Main cost
ccTLD (example.de)	Legal entity or brand differs per country	Authority builds separately per domain
Subdomain (de.example.com)	Separate teams, stacks or release cycles	Partial authority consolidation
Subfolder (example.com/de/)	One company, one brand, one blog programme	Weaker standalone geo signal, fixed by hreflang

Whichever row you pick, apply it consistently. Mixed structures — a ccTLD for one market and a subfolder for another — create annotation work that nobody maintains past the first quarter.

How to implement hreflang without breaking it

Hreflang is an annotation that tells a search engine: this page and that page are the same content for different audiences, serve whichever fits the user. It does not change rankings. It changes which version gets shown. Treat it as routing metadata, not as an optimisation trick.

The three places it can live

You can declare hreflang in the HTML <head> as link elements, in the HTTP response header, or in an XML sitemap. The head is the most common and the easiest to debug by viewing source. The HTTP header is the only option for non-HTML files such as PDFs. The sitemap scales best when a page has many language versions, because it keeps the markup out of every single page and centralises maintenance in one file.

Pick one method per project and stick with it. Declaring the same relationships in two places is allowed, but it doubles the chance that the two sets drift apart after a template change.

Reciprocity is the rule that catches everyone

Every annotation must point back. If the English page lists the German one, the German page must list the English one, and both must list themselves. A set of five language versions means each of the five pages carries five annotations, self-reference included. Non-reciprocal annotations are routinely ignored, which means the work produces nothing.

The self-referencing tag is the one most often forgotten. A page that lists its siblings but omits itself leaves the set incomplete and unreliable.

Language and region codes, written correctly

The value takes a language code, optionally followed by a region code: de for German everywhere, de-AT for German targeting Austria. The language part uses ISO 639-1, the region part uses ISO 3166-1 Alpha-2. The order matters and the region alone is invalid — AT on its own means nothing to a parser.

Two mistakes recur. The first is inventing region codes such as en-UK, where the correct country code is GB. The second is using a region code when the audience is linguistic rather than geographic: if you publish one Spanish version for every Spanish-speaking country, es is right and es-ES quietly excludes the rest.

Absolute URLs, indexable targets, canonical agreement

Hreflang values must be absolute URLs including the protocol. Relative paths are ignored. Every target must return a 200 status, be indexable, and not be blocked in robots.txt — an annotation pointing at a redirect, a 404 or a noindex page breaks the cluster.

Canonical and hreflang must agree. Each language version is canonical to itself. If the German page carries a canonical pointing at the English one, you have told the engine to drop the German page and simultaneously asked it to serve that page to German readers. The contradictory instruction wins by removing the page from the index.

x-default, and what it is actually for

The x-default value marks the page served when no language version matches the user. Typically that is a language selector, or the version in the company’s main language. It is optional, useful, and frequently misused as a synonym for “the English one”. Add it when a sensible fallback exists; leave it out rather than pointing it at something arbitrary.

Takeaway: before publishing, open three pages in different languages and read the source. If each one lists all siblings plus itself with absolute URLs, and the canonical points at itself, the set is sound.

How WordPress handles multiple languages in practice

WordPress offers several routes to a multilingual blog, and the technical consequences differ more than the admin interfaces suggest.

Multisite with one site per language

A multisite network with one sub-site per language gives each version its own content tables, its own media library, its own editorial workflow. Mapping sub-sites to subfolders or subdomains is a configuration choice made at network setup. The separation is real, which means a problem in one language stays in one language.

The cost is operational: plugins and themes are network-level, updates hit every site at once, and hreflang between sites is not automatic — it needs either a plugin that reads the network map or a build step that generates the annotations.

Separate installations

Independent installs per language maximise isolation and are common when different agencies or in-house teams own different markets. Every technical decision is made per install, including hreflang, which has to be generated from a shared source of truth. Without that shared source, annotations drift the moment one team restructures its URLs.

Single install with a translation layer

A single site where each post carries translations is the lightest setup to run and the one most prone to structural compromise. The language versions share the same post tables and often the same taxonomy, so URL patterns, slugs and category structures end up mirroring the original language rather than reading naturally in the target one. Translated slugs matter: a German URL containing an English path segment is a small, permanent signal that the page is a translation rather than a native resource.

Whichever pattern you adopt, verify the output rather than the settings screen. Check the rendered <head>, the sitemap, the HTTP status of every hreflang target, and the translated slugs. The admin panel reports intent; the source reports reality. If you are letting a tool write into WordPress automatically, the same verification discipline applies to safe third-party auto-publishing connections.

How to keep language versions from competing with each other

Content in two different languages is not duplicate content. The risk sits elsewhere, in three specific places.

The first is same-language variants: a British and an American English version of the same article, or Spanish for Spain and Spanish for Mexico, where the text is largely identical. This is where engines genuinely have to pick, and where correct region codes plus self-canonicals do the work. Hreflang does not merge the pages; it tells the engine which one to show to whom, and each page remains canonical to itself.

The second is machine translation of a single source. Running one blog through automatic translation produces pages that read as derivative in every target language, with the same structure, the same examples, the same internal link graph transposed word for word. They are indexable, they are technically distinct, and they are thin in the way that matters: they answer the source market’s questions, phrased in another language. Keyword patterns differ by language, and a literal translation inherits none of them.

The third is parameter and locale sprawl: session IDs, tracking parameters, or locale switches appended to URLs that generate dozens of crawlable variants per article. Canonical tags handle the symptom; a clean URL design removes the cause.

Takeaway: audit the index per language quarterly. Compare the number of pages you published in a language with the number indexed. A persistent gap points at a structural fault, not at content quality.

A setup sequence that holds up

Start by fixing the URL structure and writing it down as a rule — which segment carries the language, where it sits in the path, how slugs are translated. Then build the hreflang generation into the template or the sitemap pipeline, so the annotations are produced by code rather than maintained by hand.

Next, make every language version self-canonical and confirm no cross-language canonical survives from an earlier setup. Then verify indexability: robots.txt open, sitemaps submitted per language version, internal links present from at least one crawlable page in that language. A language folder that no internal link points to can wait a long time for a crawler.

Finally, plan the publishing side. A language version with four articles has the technical setup of a site and the content footprint of a landing page. Three articles a week per language, held without gaps, is the cadence at which a language version starts to cover its topic rather than sample it — and that applies to each language separately, because coverage in German does nothing for coverage in Polish.

Frequently asked questions

Does hreflang improve rankings?

No. Hreflang influences which language version is served to a given user, not how highly the content ranks. Its benefit is indirect: the right version reaches the right audience, which improves engagement signals and prevents two versions of the same article from being treated as interchangeable. Ranking still depends on content quality, structure and authority.

Subfolder or subdomain for a multilingual blog?

For most companies running one brand and one blog programme, subfolders are the better default: every link earned in any language strengthens the same domain, and hosting stays simple. Choose subdomains when separate teams, separate stacks or independent release cycles make the operational separation worth the weaker authority consolidation.

What happens if hreflang tags are not reciprocal?

They are generally ignored. An annotation only counts when the target page points back at the source. A one-directional set produces no routing effect at all, which is why non-reciprocal implementations look like they do nothing — they do nothing. Always include the self-referencing tag alongside the siblings.

Is machine-translated content penalised?

Automatic translation is not penalised as a category, but translated pages frequently underperform because they mirror the source market’s questions and phrasing. Search demand differs by language, so a literal translation targets terms nobody searches locally. Content written natively for each language, on that language’s actual queries, performs differently.

Can I use hreflang and canonical tags on the same page?

Yes, and you should. Each language version carries a canonical pointing at itself plus hreflang annotations listing all versions including itself. Problems arise only when the canonical points at a different language version, which instructs the engine to drop the page while hreflang asks it to serve that page.

How do I target two countries that share a language?

Use language-region codes, such as de-DE and de-AT, on pages whose content genuinely differs for each market. If the content is identical, a single language-only annotation is usually the cleaner choice. Creating near-identical regional variants with no real differences adds maintenance work without adding visibility.

Should every page of the site have hreflang?

Only pages that have equivalents in other languages. Annotating a page with no counterpart creates a broken cluster. If a blog article exists in four languages and not in a fifth, the set lists four URLs. Keep the annotations in sync with reality as new translations are published.

What the technical layer actually buys you

Hreflang and URL structure do not create visibility. They remove the conditions under which visibility leaks away: the wrong version served, two pages competing, a language folder never crawled. The upside is that these are one-time decisions with permanent effects, which makes them the highest-leverage hour of work in any multilingual project.

What the setup cannot fix is a language version that exists technically but publishes nothing. This is why running one structured project per language, each with its own topic coverage and its own publishing rhythm, works better than translating a single blog into twenty copies of itself. RankGrove is built that way across 22 European languages — separate projects, native content per language, no machine-translated mirror set to annotate around. See how the platform handles it before you commit your structure.

This article was produced and published automatically with the help of artificial intelligence.