Multilingual Export Website: URL Structure and hreflang

Your leadership team decides the website needs English, Spanish, German, Japanese and Arabic. Marketing starts shopping for a translation plugin, and a developer asks the question nobody can answer: should the Spanish site live at es.yourcompany.com or yourcompany.com/es/? Three months later the site launches. English is solid. Japanese is a homepage and nothing else. Half the German product pages are still in English. The Arabic menu sits on the wrong side of the screen.

That story is common among small and midsize manufacturers, and the root cause is rarely translation quality. It is the set of architecture decisions made before anyone translated a word: how many languages to support, how URLs are organized, how search engines learn which page is a translation of which, and how visitors switch between versions. Get those wrong, and fixing them later usually costs more than adding a language would have.

This guide covers architecture only. If you want the workflow for producing multilingual content with AI assistance, we cover it in our AI-assisted multilingual SEO playbook. If you are still deciding whether to build a new site at all, start with the export website build guide. Every claim about Google in this article comes from Google Search Central's own documentation, linked inline so you can check it yourself.

1. How many languages? Work backward from buyers, not forward from ambition

Short answer: the number of languages should be set by the languages your current and target buyers actually use to make purchasing decisions, not by the number of countries you hope to sell into. Every added language multiplies the product pages, spec sheets, FAQs, certification documents and pricing notes you must maintain. A language you cannot maintain is worse than no language at all.

Language count often gets treated as a proxy for how international a company looks. But each language version is an asset that needs care for as long as the site exists. In our published Manufacturer H case study, 118 products across four languages produced 472 product pages, and roughly 660 pages once category pages were added. Every new SKU and every spec change after launch is four units of work, not one. That is not an argument against going multilingual. It is a reminder that language count is a multiplier on everything you will ever publish.

Selling into North America: English is table stakes, Spanish depends on the channel

If North America is your main market, English is non-negotiable, and for most B2B purposes it covers a lot of ground. The U.S. Census Bureau's 2018 to 2022 American Community Survey found that 78.3% of people age 5 and older spoke only English at home. Among working-age adults (18 to 64) who spoke another language at home, 61.0% spoke Spanish, and 58.3% of those Spanish speakers said they speak English "very well." For a procurement audience, an excellent English site reaches most U.S. buyers. Whether Spanish is worth adding depends on your channel: do your distributors serve Spanish-speaking end users, or are you also building business in Mexico and Latin America?

Canada is different. Éducaloi, a Quebec legal-information organization, explains that a business with an address in Quebec that offers products or services to Quebecers must have a French version of its website. Many manufacturers selling into Canada have no Quebec address, so the rule may not apply to you directly. But if a Quebec distributor wants to reuse your product content, French comes up quickly. Treat this as background rather than legal advice, and confirm the details with counsel in Quebec.

If you are a North American manufacturer going the other direction, adding languages for export markets, the same logic applies in reverse. Start from where orders and inquiries actually come from today, not from a map of every country you could theoretically ship to.

Use evidence, not instinct: three sources

Three sources tell you whether another language is justified. First, inquiry history: over the last two years, which countries did RFQs, trade-show contacts and marketplace inquiries come from, and what language were they written in? Second, Search Console and GA4 country and language data: which countries already read your English pages, and how do those visitors engage and convert? Third, sales capacity: if you publish a Japanese site and a buyer writes to you in Japanese, can anyone on your team reply in Japanese? If not, the Japanese site simply creates a disappointing first contact.

Language preference is real. CSA Research surveyed 8,709 online consumers in 29 countries in 2020 and found that 76% prefer to buy products with information in their own language, and 40% never buy from websites in other languages. Note the caveat: that is a consumer survey, not a B2B one. Industrial buyers often read professional English and buy by committee. The number is a good reminder that language affects trust. It is not proof that every market needs a native-language site.

A language decision table

The table below maps common situations to a starting recommendation. It is not a formula; it gives your team a shared starting point for the internal discussion.

Here is a myth worth retiring: more languages means more search traffic. Back in 2020, Microsoft Bing's Fabrice Canel publicly advised against duplicating URLs just to tag them for language-markets, summing it up as "less is more". Thin, half-translated language versions do not earn traffic. They dilute site quality and drain the attention of whoever maintains them.

The organizational question: who owns each language?

The most common way a multilingual site decays is not a technical failure. It is that nobody owns it. On launch day every language is complete. Six months later the main language has ten new products, English has five of them, and Spanish has none. When you decide how many languages to support, also decide who owns each one and what happens when a new product is added: either every language version goes live together, or the product is explicitly flagged as not yet available in certain languages. That rule does more to keep a multilingual site alive than any plugin.

When you do not need multiple languages yet

If nearly all your international orders arrive through agents or trading companies and buyers rarely visit your site, one complete English site matters far more than five partial ones. If even your English site is a five-year-old catalog, fix English first. Add a second language when inquiry data shows a non-English market genuinely growing. That sequence lets you test each language's value at the lowest possible cost.

2. URL structure: subdirectories, subdomains or country-code domains

Short answer: Google's documentation lists subdirectories (example.com/de/), subdomains (de.example.com) and country-code domains (example.de) as valid options, each with trade-offs, and does not say that any of them ranks better. The only approach Google explicitly marks "not recommended" is URL parameters (?loc=de). For most small manufacturers, subdirectories carry the lowest maintenance burden.

Google Search Central's page on managing multi-regional and multilingual sites compares these structures in a table. We have reproduced Google's pros and cons faithfully below and added three operational factors that small teams care about. The rows marked "per Google" follow the documentation; the rows marked "operational" reflect our project experience and are not a Google ranking assessment.

Myth check: subdirectories are not a Google bonus

You will often read that subdirectories always beat subdomains, or that a subdomain is treated as a separate site that starts from zero. Google's documentation does not say that; it simply lists trade-offs. We recommend subdirectories for most small manufacturers for operational reasons: one system, one domain and one set of reports are easier for a small team to run. Not because Google awards extra credit. If you have run a subdomain setup for years with healthy indexing and steady inquiries, there is no reason to rebuild your URL structure because of this myth.

How Google decides which country a page is for

The same documentation lists the signals Google uses to determine a page's target audience: country-code top-level domains, described as a strong signal; hreflang annotations in tags, headers or sitemaps; server location, which Google calls "not a definitive signal" because many sites use CDNs; and other signals such as local addresses and phone numbers, local language and currency, and links from other local sites. Google also states that it ignores locational meta tags such as geo.position.

One change many site owners missed: Search Console used to include an International Targeting report where you could set a country target for a whole site. Google deprecated that report, saying the ability to target countries this way "was determined to have little value for the ecosystem," while confirming continued support for hreflang. Search Engine Roundtable covered the deprecation when it was announced in 2022. In practice, if you use subdirectories or subdomains, there is no longer a settings switch that tells Google "this folder is for the U.S." Correct hreflang and genuinely local content are what you have left.

The home-country domain question

Plenty of manufacturers run their English site on their home country's domain: .it, .de, .com.tw, .co.kr. According to Google, a country-code domain is a strong signal to users and search engines that a site is intended for a specific country. Google does treat a short list of country codes as generic, including .io, .co, .ai, .me and .tv, because people tend to see them as generic. Most national domains are not on that list. So if your main buyers are in North America and your English pages sit on another country's domain, you are sending a regional signal that does not match your target market.

That does not mean those pages cannot rank in the U.S. Language, content quality and links still matter. Nor does it mean you should change domains tomorrow. A domain change is a full migration: every old URL needs a 301 redirect, verified one by one, or you lose the search equity you built. Our redesign vs. rebuild decision framework walks through that call. Our advice: if you are rebuilding anyway and export is most of your revenue, evaluate moving the main site to a .com with your home-market language in a subdirectory. If the current site works and English inquiries are steady, one mismatched signal is not worth a migration.

Two approaches to avoid: URL parameters and cookies

Some sites switch languages with a parameter like ?lang=en, or serve different languages at the same URL based on cookies or browser settings. Google's table marks URL parameters "not recommended," and the documentation says Google recommends different URLs for each language version rather than using cookies or browser settings to adjust content language. The reason is simple: one URL gets indexed as one version, so the other languages effectively do not exist for search. Some translation plugins swap text in place at the same URL, so confirm that a plugin creates a separate URL per language before you commit to it.

Should the words in the URL be translated?

Google says it is fine to use localized words in the URL, as long as you use UTF-8 encoding and escape URLs properly when linking to them. In practice, non-Latin URLs often turn into long percent-encoded strings when pasted into email or chat. We usually recommend one shared set of English slugs across languages, such as /en/products/valve-a and /es/products/valve-a, which makes it easy to match versions during maintenance. Localized slugs in Latin-script languages like Spanish or German are also fine. What matters is that once you choose, you do not change them.

You can see the management cost in Search Console

A concrete difference: a Search Console Domain property covers every subdomain and protocol under a domain, but the top-level domain is part of the property name, so a Domain property for example.com does not include example.org. Subdirectories and subdomains can be monitored under one property; every country-code domain needs its own verification and its own reports. For a team where one or two people run the website, that is a real weekly cost.

3. Setting up hreflang: purpose, x-default and return links

Short answer: hreflang tells Google that a set of URLs are language or regional versions of the same content. Every version must list itself and all other versions, and the links must be reciprocal or Google may ignore them. Add an x-default entry as the fallback for visitors whose language you do not support.

What hreflang does and does not do

Google's documentation on telling Google about localized versions of your page says hreflang helps Google understand that pages are localized variations of the same content, so it can point searchers to the most appropriate version. Two points are widely misunderstood.

First, hreflang does not determine a page's language. Google says it does not use hreflang or the HTML lang attribute to detect language; it uses algorithms. Its multi-regional guide is more specific: Google uses the visible content of your page to determine its language, not code-level information such as lang attributes or the URL. If half your "English" page is still in another language, perfect hreflang will not make it a good English page. Google recommends using a single language for content and navigation on each page and avoiding side-by-side translations.

Second, translated pages are not duplicate content. Google states that localized versions of a page are only considered duplicates if the main content remains untranslated. The worry that your English and Spanish versions will compete with each other does not apply to real translations. What deserves worry is a page where only the navigation and footer were translated.

Three implementation methods: pick one

Google supports three ways to declare language versions: HTML link elements, HTTP headers and XML sitemaps. Google says the three methods are equivalent and that using all three brings no benefit in Search while making maintenance harder. HTML or sitemaps work for normal pages. HTTP headers exist for non-HTML files such as PDFs, which is useful for manufacturers whose spec sheets and catalogs are often PDFs.

For a product page with U.S. English and Spanish versions, both pages carry the identical set of tags in the head:

<link rel="alternate" hreflang="en-US" href="https://www.example.com/en/products/valve-a" />
<link rel="alternate" hreflang="es" href="https://www.example.com/es/products/valve-a" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/en/products/valve-a" />

On happycxo.com, every page declares zh-TW, en-US and x-default, and the sitemap carries the same mappings. Google says one method is enough; we mirror them in the sitemap because it makes automated auditing easier.

The rules, straight from Google

1. Each language version must list itself as well as all other language versions.
2. Alternate URLs must be fully qualified, including https://, not /en/page.
3. Alternate URLs do not need to be on the same domain, so country-code domains can reference each other.
4. If two pages do not both point to each other, the tags will be ignored. This stops other sites from claiming to be alternates of your pages.
5. Language codes use ISO 639-1; optional region codes use ISO 3166-1 Alpha 2. A country code on its own is not valid.
6. Codes outside those standards are not supported; Google specifically names es-419, often used for Latin American Spanish. Reserved codes such as EU, UN and UK are ignored; the United Kingdom is GB.
7. Scripts can be specified with ISO 15924, for example zh-Hant for Traditional Chinese.

Google's documentation also allows a helpful bit of flexibility. If maintaining a complete set of bidirectional links for every language becomes difficult, you can omit some languages on some pages and Google will still process the pairs that point to each other. But newly added language versions must link bidirectionally with your original, dominant language version. For manufacturers with large catalogs who translate only core pages into a new language at first, that means you can expand gradually instead of translating everything at once.

x-default: a landing spot for unmatched visitors

x-default is a reserved value used when a visitor's browser language matches none of your versions. Google notes that you can use x-default for any page, but it was designed for language selector pages and works best there. Small manufacturers usually do one of two things: point x-default at a language selector if the homepage is one, or otherwise point it at the main export language, usually English.

Common hreflang errors

hreflang looks simple and breaks easily. Ahrefs studied hreflang across 374,756 domains and found that 67% of hreflang implementations had issues. The table combines the errors Google's documentation calls out with what we see in site audits.

The canonical row deserves a note. Google's guide to consolidating duplicate URLs says that if you use hreflang, specify a canonical page in the same language, or the best possible substitute language if no same-language page exists. Some plugins and themes point every language's canonical at the primary language, which effectively asks Google to fold your translations into it.

To check an existing site for these and other issues, see our self-check for nine common website technical problems.

4. Do not auto-redirect by IP: designing the language switcher

Short answer: Google advises against automatically redirecting visitors from one language version to another based on what you think their language is, and against using IP analysis to adapt content. Give each language version a fixed URL and put a clear language switcher on every page so visitors choose for themselves.

Why auto-redirects make half your site disappear

Google's multilingual guide is direct: avoid automatically redirecting users from one language version of a site to a different language version, because such redirects can prevent users and search engines from seeing all versions of your site. The same page says not to use IP analysis to adapt content, because IP location analysis is difficult and generally not reliable.

The technical reason is where the crawler comes from. Google explains that for sites that change content by perceived country or language, Googlebot's default IP addresses appear to be based in the USA, and the crawler sends requests without setting an Accept-Language header, so Google might not crawl, index or rank all your content for different locales. Google does crawl from some non-U.S. IP addresses too, but if you send every U.S. visitor to English, Googlebot will mostly see English, and your other versions may rarely be seen. Google's recommendation is clear: separate locale URLs, annotated with hreflang.

There is also a human problem. A buyer from Chicago visits a supplier's plant in Monterrey or Milan and opens the supplier's site on hotel Wi-Fi. If the site redirects by IP, she lands in Spanish or Italian and has to hunt for the switcher. If the switcher is hard to find, she may simply close the tab. IP tells you where someone is, not what they read.

The W3C view: negotiate if you like, but always allow an override

The W3C Internationalization group takes a slightly different view. It considers guiding readers to their preferred language via the browser's Accept-Language setting usually helpful, but insists on adding links to each page so users can change languages easily, and remembering their choice. Put Google and W3C side by side and a workable compromise emerges: no forced redirects. If you want to act on browser language, show a dismissible banner ("Looks like you prefer Spanish. Switch?") and let the visitor decide.

Six principles for the language switcher

1. Use language names, not flags. W3C puts it plainly: flags represent countries, not languages. Many countries share a language and many countries have more than one official language. English does not belong only to the U.S., and Spanish does not belong only to Spain.
2. Write each language in itself: English, Español, Français, العربية.
3. Switch to the equivalent page, not the homepage. A buyer reading a valve spec should see the same valve in the other language.
4. If no equivalent exists, go to the nearest parent, such as the category page, and say so. Never land the visitor on a 404.
5. Keep it in the same place: top right of the header and again in the footer, on every page.
6. Remember the choice without overriding the URL: a cookie can remember the last language as a hint, but each version's URL must stay fixed so shared links open in the language they were shared in.

5. Translation is not localization: give buyers specs they do not have to convert

Short answer: translating a page is step one. Buyers need pages written in the units, standards, certification names and argument order they already use: metric and inch-pound side by side, the exact standard your product conforms to, the right market for each certification, unambiguous dates, and applications and specs ahead of company history.

Units: the U.S. does not mandate metric, so give both

The National Institute of Standards and Technology notes that because metrication is not required in the United States, many businesses operate in both SI and U.S. customary units, and using two systems at the same time often causes unit errors. That cuts both ways. A foreign supplier listing only millimeters, kilograms and bar forces a U.S. engineer to convert. A U.S. manufacturer listing only inches, pounds and psi forces a European engineer to convert. Every conversion is a chance for error and a signal that the supplier did not think about the reader. Show both systems, mark which value is the design basis and which is converted, and let engineering, not the translator, decide the rounding.

Standards and certifications: CE is not a North American passport

Certification names are where translation gets the words right and the meaning wrong. The European Commission describes the CE marking as something manufacturers affix after conformity assessment for products placed on the extended single market of the EEA. It is a European rule. In the U.S., electrical equipment used in workplaces falls under OSHA's Nationally Recognized Testing Laboratory program, in which recognized private laboratories certify products to the test standards within their scope and apply their own registered certification marks.

So an English page cannot simply say "CE Certified" and stop there. Ask which certifications your product needs in each target market, which ones you actually hold, and list each with a certificate number or a way to verify it. Never list a certification you do not have. The same goes for material and test standards: if a product is made to JIS or DIN, say so, and do not imply equivalence to an ASTM or ASME specification unless your engineering team has confirmed it.

Dates, currency and document formats

W3C points out that the MM/DD/YY date format is unique to the United States, though sometimes used in Canada, while most of Europe uses DD/MM/YY. "03/04/26" is March 4 to an American reader and April 3 to a European one. For lead times, quote validity and document revision dates, use ISO 8601 (2026-04-03) or spell out the month. For pricing or freight notes, state the currency and the Incoterm rather than a bare number.

Argument order: specs before history

We have no official statistic for this one; it is a pattern we see repeatedly when rewriting manufacturers' sites. Many company sites open with the founding year and a statement of values, and the translated version keeps that order. But a buyer opening a product page first wants to know whether it fits the application, what the specs and tolerances are, what it is made of, the minimum order and lead time, and which certifications apply. Company history is a trust signal, but it belongs on the About page, not in front of the specs. For more on what North American buyers look for, see our guide to buyer trust signals, and for writing spec pages that AI search can parse, see our product page AEO guide.

Translation vs. localization at a glance

That last row is the most commonly missed piece of localization. Our guide to B2B inquiry form design breaks down form fields that do not scare international buyers away.

As for machine translation: it makes a useful first draft, but someone who knows the industry must review it before it goes live. The workflow for producing multilingual content with AI and placing human review checkpoints is in the multilingual SEO playbook, so we will not repeat it here.

6. Arabic and other right-to-left languages: support the layout from day one

Short answer: Arabic is written right to left, and the entire page layout mirrors with it. Navigation, breadcrumbs, table column order and form input positions all change. It has to be handled at the architecture and stylesheet stage; a translation plugin cannot fix it.

Right-to-left is more than right-aligned text

W3C's internationalization guidance lists what happens when you add dir="rtl" to the html element: blocks align right, bidirectional text flows correctly right to left, punctuation lands in the right place, table columns progress right to left, and form input starts at the right. If the stylesheet is written correctly, the layout mirrors automatically. The same article sets out three principles:

1. Set direction with the HTML dir attribute, never with CSS for base direction, because direction is part of the content's meaning and must survive even without the stylesheet.
2. Use logical properties: start and end instead of left and right, such as margin-inline-start instead of margin-left, so switching to RTL does not require rewriting the stylesheet.
3. lang does not imply direction. Declaring Arabic with lang does not make the page right-to-left; direction must be declared separately with dir.

All three have to be followed from the first line of CSS. If your site already relies on hard-coded left and right values, absolute positioning and directional icons, adding Arabic later means reworking the entire stylesheet.

Case H: a four-language rebuild including Arabic

Our Manufacturer H case study covers a car-care chemicals manufacturer running an own brand alongside OEM and ODM work. The audit of the legacy site found no language declared on the HTML element and an English sitemap that returned a 404. Not one of the URLs the sitemap did list was an English page, and more than a dozen Chinese pages had no English counterpart at all. For an export-driven manufacturer, that meant being effectively unfindable in the language its buyers use.

The rebuilt site is statically generated in English, Traditional Chinese, Spanish and Arabic: 118 products across four languages gives 472 product pages, and around 660 pages including category pages. Arabic needed genuine right-to-left layout support, which is not something a translation plugin solves; the layout had to accommodate it from the start. Before the move, all 360 legacy URLs were captured so nothing existing would quietly vanish, and around three hundred redirects were verified one at a time to confirm each landed on a real page rather than a 404 or a chain of hops.

The lesson: multilingual problems rarely come from translation alone. A broken English sitemap, an undeclared page language and missing counterpart pages are architecture problems, and right-to-left layout is an architecture decision that is hard to retrofit if nobody planned for it.

Before an Arabic launch, also check

• Model numbers and figures: Arabic sentences containing Latin model numbers are bidirectional text. Check the display order in a real browser, especially in spec tables.
• Directional icons: next arrows, breadcrumb separators and carousel direction all need to flip.
• Forms: user input can run either direction; W3C recommends dir="auto" on form fields so the browser detects direction.
• Fonts: confirm the Arabic font renders on every device rather than relying on whatever the visitor has installed.
• PDF catalogs: an Arabic PDF needs right-to-left layout, not just swapped text.

For perspective, W3Techs data from September 28, 2026 shows that among websites whose content language is known, Arabic accounts for 0.6% and English for 49.5%. That figure does not translate directly into opportunity, but it suggests that suppliers with complete Arabic spec content are not common. If you have Middle East customers, doing it well gets noticed. If you do not, you do not need Arabic just to look international.

7. Pre-launch checklist for a multilingual site

Short answer: before launch, verify language scope, URL structure, hreflang, canonicals, sitemaps, redirects, the language switcher, localized content and tracking. Paste the table below into your acceptance document; every row has a pass condition.

The sitemap row is exactly what went wrong on Manufacturer H's legacy site: the English sitemap returned a 404. That kind of error is invisible on screen. Everyone who looks at the site thinks it is fine, and it only shows up when someone checks with tools. Fold this table into your build contract's acceptance criteria; our website RFP and acceptance checklist shows how.

After launch, watch indexing and impressions by language for the first few weeks to confirm the new language pages are actually indexed and that traffic comes from the markets you expected. For what to measure and when to adjust, see the first 90 days after launching an export website.

Conclusion: get one language right before adding the next

Multilingual architecture comes down to four decisions. Buyers set the number of languages. URL structure has trade-offs that Google documents, and subdirectories suit most small manufacturers. hreflang must be reciprocal, with same-language canonicals. And visitors choose their language rather than having an IP lookup choose for them. The localization details (units, certifications, dates, argument order and right-to-left layout) decide whether a buyer finishes reading and thinks "this supplier understands us" or "this is a translation."

If you have a large product line to organize, continue with structuring a manufacturer's product catalog website. If you sell on Alibaba.com and wonder whether you still need your own multilingual site, read Alibaba store vs. your own website.

HappyCXO Studio's website development service starts with exactly these decisions: inventory your buyers and existing URLs, settle languages, URL structure and hreflang, and only then move to design and translation. Whether or not you work with us, run the checklist above before you build. The most expensive multilingual mistake is rarely a bad page; it is the wrong architecture chosen on day one.