Multilingual website launches in Europe: a buyer’s acceptance checklist

A European website brief becomes easier to estimate when it names the release the buyer can actually accept. "Add German" leaves open which pages are translated, who approves them, what a returning visitor sees and which version reaches search. A language menu alone cannot answer those questions.

This guide is for UK, Irish and continental European product teams commissioning a multilingual company website or public catalogue. It connects language choices, editorial ownership and technical acceptance. The worked catalogue is fictional; it is a discovery exercise, not a customer result or a claim about search demand.

Choose a buyer journey before a list of countries

Start with one complete task: a visitor finds a product, reads the relevant specification and sends an enquiry to the right owner. List the language of each step, including confirmation messages and the reply the team can support. A translated product page followed by an unexplained form in another language leaves that task unfinished.

For a UK or Irish company, one shared English site may be a sensible starting point if its offer and support route are the same. A team expanding into Germany or the Netherlands can select a specific German or Dutch journey to review. For Switzerland, distinguish the intended language from a regional variant: use a tag such as de-CH only when the Swiss version has a defined purpose. For Denmark, Finland, Norway or Sweden, agree the actual language and operating owner for the selected market; do not infer that one English release covers every buyer task.

These are scoping choices, not a prescribed language bundle. The W3C language-tag guidance recommends adding regional subtags only when they make a useful distinction. Language selection also does not decide currency, product availability or the commercial terms the business approves.

Ask what the portfolio actually demonstrates

Curiosive's Miray Yapım case, recorded in Türkiye, describes a bilingual Next.js website with a Sanity-managed production catalogue and a detail page for each production. It supplies evidence for connecting design, structured content and two-language publishing. It does not establish a German, Swiss or Nordic delivery.

The Lizzt case is recorded in the Netherlands. Its Next.js frontend rebuild retained an existing Supabase backend and includes Dutch and English alongside shared event workflows. That is multilingual application evidence; it is not evidence that every public-page search or translation-release policy in this guide was implemented there.

This is HCD in Ireland separates Sanity-managed editorial content from member activity in Supabase. It is relevant to ownership of maintained content, without implying that the project delivered the multilingual catalogue proposed below. Ask a supplier to make these boundaries visible before treating a neighbouring project as proof of your full brief.

Give shared facts and translated copy separate owners

Write a small content register for the first product. A stable product reference, approved image and document revision may be shared. The product name, description, image alternative text, page title and enquiry instructions may need a separate approved value per language. Record which fields may differ by market rather than duplicating the whole catalogue by default.

Name a language reviewer and a publishing owner. Decide what happens when a shared specification changes after a translation was accepted. The translation may remain valid, need another review or be withdrawn; that decision belongs to the responsible owner and should be visible in the release record. A translator's completed draft and permission to publish are different states.

Sanity's localization documentation distinguishes field-level and document-level approaches. A document per language can support independent publication, while shared fields and references require deliberate modelling. Choose the model around the team's release workflow. Before approving it, ask an editor to change one shared fact and identify the affected language versions without engineering assistance.

Agree the URL and the missing-translation behavior

Create a URL map for the selected item before reviewing page layouts. For a fictional product P-104, /en/products/p-104 and /de/produkte/p-104 can be two public destinations connected to the same product identity. Their wording differs; their relationship should not depend on matching the visible title.

Decide what the language switch does when the German page is still a draft. It can explain that the translation is unavailable and offer the approved English page. It should not present English body copy at a URL labelled as an approved German translation. Apply the same decision to navigation, search results and an older saved link. Check that a visitor can return to the original item after switching languages.

Google's multilingual-site guidance recommends separate language URLs and explicit language links. It also cautions against automatic language redirection. For acceptance, open each URL directly in a fresh browser session; the language the buyer requested should remain accessible without a particular cookie or IP location.

Review search annotations against the published pages

Ask for a small annotated URL inventory, not a screenshot of an SEO plugin. For each published version, record its canonical URL, language, title, description and alternate-language destinations. A genuine translated page should have an agreed canonical policy that preserves its intended public destination. Investigate a German page whose canonical unexpectedly points to an unrelated English item.

If hreflang is used, test the whole set of equivalent published pages. Google's localized-version documentation requires return links between alternates and describes self-references, full URLs and supported language/region codes. An unpublished translation should not appear in that set. A language tag alone does not establish a country's commercial availability.

Check the canonical, sitemap and language links together after publication. Page annotations must describe the approved content actually served at their destinations. Record how the team removes a withdrawn version from alternate links and the sitemap. This inspection validates implementation; it does not promise indexing, a ranking position or an increase in enquiries.

Keep public delivery and private operations separate

Public descriptions and specifications can be prepared when an editor publishes. Enquiries, accounts and restricted documents may require their own application behavior. Identify that boundary in the quote so that adding a language does not quietly turn every public visit into another content-fetch or translation job.

Next.js static-export documentation describes HTML generated during the build and served by a static host. For a suitable public catalogue, agree which URLs are generated, how a content change triggers a reviewed release and how staff check the delivered revision. Interactive or server-dependent requirements need their own assessment; a static export does not support every application feature.

Ask to inspect the initial HTML of the sample pages and a repeat request from the cache. The accepted copy, headings and links should be available in the delivered page. Test any language-specific enquiry path separately with fictional data and a controlled destination. A cached public page and a successful private handoff are separate acceptance evidence.

Rehearse one correction before expanding the catalogue

Use this fictional packet during a supplier review:

• Product P-104 has shared specification revision R3 and an approved English page. Its German translation is awaiting the named reviewer. English can be public; the German draft is excluded from public navigation, the sitemap and alternate-language annotations.
• The reviewer accepts the German copy against R3. The publishing owner releases it. Direct visits, language switching, title and description, enquiry context and reciprocal alternate links all identify the intended product.
• The specification changes to R4. Under this example's agreed policy, the German version returns to review. The team demonstrates what visitors see and which links remain available while that review is pending. That policy is a proposed requirement, not a universal CMS default.
• A corrected German version is approved and published. The public response shows the accepted revision, while the release record retains the previous approval reference. If rollback is required, restore a coherent set of pages and links rather than only reverting one text field.

Give each observation an owner and a pass condition. A useful handover includes the content register, URL map, reviewer decisions, release identifier and recovery procedure. It should let another authorized editor repeat the correction without relying on the original developer's memory.

Start with a bounded European release

A first engagement can cover one catalogue family, two agreed languages, a working enquiry path and the correction rehearsal above. Name the content the buyer supplies, the translation and review responsibilities, the publishing owner and the delivery environment. Keep later languages and integrations visible as separate scope decisions.

Curiosive works remotely with engineering led from Ankara, Türkiye. The UK content-product page, Irish content-platform page and Dutch existing-product page describe relevant published references and engagement choices. They do not imply local offices. Germany, Switzerland and Nordic markets are prospective audiences for this guide, not invented portfolio locations.

For a website brief, explore website development, Sanity CMS development and technical SEO. Bring a representative item, its current URLs and the people who can approve each language to the first conversation.

Sources and scope

Primary documentation checked on 15 October 2026: W3C language tags, Sanity localization, Google Search Central's multilingual-site and localized-version guidance, and Next.js static exports, linked beside the claims they support. The acceptance packet and buying recommendations are Curiosive's analysis. No search-volume estimates, customer results, translation-quality certification or legal compliance guarantees are claimed. Market-specific contractual or regulatory requirements should be supplied by the responsible business owner and qualified advisers; this is an engineering procurement guide.