Websites

A multilingual website: when it pays and what it costs

A multilingual site pays only with measured demand and someone to maintain the version. URLs, hreflang, information duties, update costs and real blocks.

A multilingual site pays when there is demand in another language and someone can maintain that version. Those are two conditions, not one: without the second, the translation ages and the Italian version stays the only current one.

The decision rests on data, not taste. Before opening a language, look at Search Console queries by country, at support requests arriving in English or German, and at contacts from the form. If none of those three sources shows demand, the translation is a cost with no return.

Three questions before translating

QuestionHow to measure itIf the answer is no
Is there demand in that language?Search Console queries by country and language, support requests, site contactsStay in one language and translate only the page for exported products
Does anyone answer in that language?Hours per week available for email and phone, with a named personThe translation becomes a form nobody updates
Does the content survive translation?Pages to rewrite, not just translate: prices, rules, local examplesTranslate the home page, contacts and product pages, not the blog
Does the service exist in that country?Shipping, payments, returns, support, taxesPublish an information page, not a full site

How many languages, and which

One language at a time, chosen because someone searches for it. For an Italian company selling abroad the second language is often English, but for a hotel in South Tyrol it is German and for a company working with France it is French. English as a blanket default is the easiest choice and the least useful: no French customer searches in English for an Italian supplier.

URL structure and hreflang

A subfolder on the same domain, /en/ and /de/, is the simplest shape: one domain to verify, readable canonicals and hreflang pairs, no separate project to maintain. Each version declares itself as canonical and lists all the others, itself included, with absolute URLs. The mistakes that break the pairs are described in hreflang: the common mistakes.

# quante pagine per lingua
for l in it en de; do printf "%s " $l; curl -s "https://www.esempio.it/$l/sitemap.xml" | grep -c ""; done

# la pagina tedesca dichiara la lingua giusta
curl -s https://www.esempio.it/de/ | grep -o ']*lang="[^"]*"'

# il canonical resta nella lingua della pagina
curl -s https://www.esempio.it/de/ | grep -o '<link rel="canonical" href="[^"]*"'

What to translate and what not to

  • Menus, footers, buttons and error messages: the strings users see first and the easiest to forget.
  • Privacy notice, cookie banner, terms of sale and returns policy must exist in every published language.
  • Automatic emails, from order confirmation to password reset, stay in Italian for years if nobody owns them.
  • Translate the blog only where demand exists: ten translated articles that then stop do more harm than none.
  • Titles, meta descriptions and structured data are translated with the page, not in a later pass.

The GDPR, article 12(1), asks for information in a concise, transparent and intelligible form, in clear and plain language: a notice only in Italian on a German site does not meet that sentence. Cookie consent follows the same logic: the ePrivacy Directive 2002/58/EC, article 5(3), and the Italian regulator's decision of 10 June 2021, enforceable from 10 January 2022, refer to the user's will, which is collected in the language of the interface. For a contract with an Italian consumer, pre-contractual information stays the Italian one, as the consumer code requires: the English version helps, it does not replace it.

The cost everyone forgets

The real cost is not the first translation but the doubled update: every price, opening time or rule change happens twice, and the second one arrives late. With 200 pages and twenty edits a month, the English version is always catching up. That is why you translate a stable core and leave the rest in Italian with a note. One case with language and accessibility duties is a school website.

Blocks from the catalogue

Two language switchers already in the catalogue: language-switcher-pill, MIT licence declared on the record, changes the URL without reloading the page; language-selector-dropdown declares no licence and must be checked before use. The navbar blocks show where that switcher ends up, and the header category, 18 blocks, covers the variant with language and phone. Data verified on 1 November 2026.

The limitation to state clearly

A translation does not create demand: if nobody searches in that language, a multilingual site only adds maintenance. hreflang is a hint, not an instruction, and it does not fix two versions that say different things. The catalogue has no i18n routing: the blocks are components, not a translation system. Unreviewed machine translation is paid for in support, because the customer writes in the wrong language and nobody answers.

Where to start

The technical sequence is in hreflang: the common mistakes, the canonical part in canonicalisation, and if the choice is between two stacks for a marketing site the comparison is in Next.js or Vite for a marketing site. The whole bill, translation included, is in what a website costs.

Frequently asked questions

When does a site need more than one language?

When there is measurable demand in another language and someone can answer and update that version. If either condition is missing, the translation stalls and the Italian version stays the only true one.

Subdomain, subfolder or query parameter?

A subfolder on the same domain, such as /en/. A subdomain splits the signals, a parameter is fragile and a separate domain is a project of its own. The subfolder also keeps canonical and hreflang simple.

How many languages should we open?

One, then measure. Every language adds translation, updates, support and legal text. Opening six languages with unreviewed machine translation gives six incomplete versions and more requests than you can answer.

Is hreflang enough for a multilingual site?

No. hreflang links equivalent versions and helps Google serve the right language, but it does not create demand and does not fix content that differs. You also need distinct URLs, a self-referencing canonical, real translations and a correct lang attribute.

Is machine translation enough?

For a small information site it can be, with human review of the pages that sell or carry legal weight. Without review the risk is mistranslating prices, terms and rules, and every mistake is paid for in support or in disputes.