A multilingual website quote depends on what the team will publish, how language versions relate to each other and who will maintain them after launch. Counting languages alone leaves out the work that often changes the project most: content coverage, page templates, editorial approvals, URL migration and the states visitors can reach.
This guide helps a marketing lead prepare a scoped request for a multilingual website or content platform. It gives a way to compare proposals without pretending that a language count produces a reliable price. Translation production and review can be separate services; name their owner and budget boundary explicitly.
Count published content, not only languages
Create a spreadsheet with one row per existing or planned URL. Add its business purpose, source language, requested language versions, template, content owner, translator/reviewer, integration and desired launch status. Include navigation, forms, validation, confirmation messages, downloadable files and legal or transactional text where they are part of the visitor journey.
Then classify each page:
- Shared structure and content: the page has the same offer and meaning across languages.
- Translated with local review: wording changes, but product scope stays equivalent.
- Market-specific: details such as contact information, availability, legal text or terms differ by region and need an authorized owner.
- Not planned for a locale yet: the page should not appear as a complete translation until its readiness rule is clear.
Language and market are different decisions. An English page can serve several markets, while one market can require multiple languages. Add a country-specific version only when the content or business requirements call for it.
Estimate the work in separate buckets
Use these buckets to ask vendors what is included. They are effort drivers, not a formula that predicts a price.
Page and template build: How many distinct layouts, page states, navigation structures and responsive components are needed?
Content migration: How many URLs, media files and structured content records need to move? Which pages change path?
Locale model: Are language subpaths, domains or another URL structure required? Do locales share templates and content fields?
Editorial workflow: Who submits, reviews, approves and publishes each version? Are roles, preview, version history or scheduled release needed?
Search and URL continuity: Which pages must remain indexable? What canonical and alternate-language relationships should each page expose?
Integrations and enquiries: Do forms, CRM fields, notifications, booking tools or search need language-aware labels and routing?
Quality and handoff: Which devices, languages, browser settings and real user journeys need acceptance checks? Who owns future content and technical care?
The platform choice changes operating work. A small site with a named editor and occasional approved updates may fit a lightweight publishing workflow. Multiple editors, frequent releases, market-specific variants, approval stages or large catalogs may need stronger roles, preview and versioning. Ask the team to demonstrate the routine task an editor will own after launch.
Choose URLs and publishing rules before content migration
Decide whether locale versions will use paths such as /sq/services/, separate hostnames or another maintainable pattern. Document how a visitor reaches an equivalent page with the language switcher and what happens when that page has not been translated.
Next.js supports localized routing with subpaths or domains and passes the locale through the route structure. The framework does not create the translations or editorial process; those are product and publishing decisions. See the Next.js internationalization guide.
For eligible alternate pages, Google documents how hreflang relationships should include each version itself and its corresponding alternates with fully qualified URLs. Test the generated page source or sitemap after implementation. A translated navigation label does not prove that the article, metadata, contact route and form messages are available in that language. Google's localized-version guidance
If the new site changes existing URLs, add a mapping for each old route, its new destination or deliberate retirement, and the redirect behavior. For a multilingual move, update alternate URLs alongside canonicals, links and sitemap entries. Google recommends directly relevant permanent redirects where URLs change; search reprocessing can take time and results are not guaranteed.
Work through a hypothetical quote request
Imagine a consulting firm wants English and Albanian versions of a 20-page website. Its inventory finds five templates: home, service, case study, article and contact. Six pages are market-specific, and the old blog has 40 indexed or externally linked URLs. The contact form feeds an existing team inbox.
The quote should distinguish building or adapting five templates from migrating 20 current pages and mapping the 40 blog URLs. It should name who supplies and approves the translations, how six market-specific pages receive their business details, how untranslated articles are handled and what happens to old URLs. The inbox flow needs language labels and delivery tests, while translation fees can be stated separately from development.
This example does not imply a particular price, schedule or translation quality. Those depend on the actual CMS, source material, locale requirements, access and review responsibilities. It shows which facts a vendor needs before a meaningful scope can be approved.
Compare proposals by acceptance criteria
Ask a prospective team to state:
- The page, locale, template and content counts included in the quote.
- The URL structure and behavior when a requested locale page is missing.
- Which content is migrated, translated, edited or supplied by your team.
- The people responsible for translation quality, legal review and local commercial details.
- The editor roles and publishing steps available after handoff.
- The redirect map, canonical and alternate-language implementation, sitemap and launch checks.
- Whether forms, search, notifications and integrations vary by language or market.
- The language-specific acceptance cases and who signs them off.
- Excluded work, third-party costs, change approval and ongoing content or technical support.
Acceptance should use real sample pages in each language. Review longer translated headings, accents, line wrapping, menu states, error messages and submitted enquiry details. Test direct URL visits and language-switcher destinations with a keyboard and on mobile. Have a fluent reviewer confirm the meaning; a developer cannot approve translation quality by inspecting code.
Know when the project needs a discovery stage
Start with discovery if the current URL inventory is incomplete, the content platform is undocumented, several teams own language decisions, or a connected form and CMS have no test environment. Agree what access is needed and what discovery will produce: a route map, content model, integration constraints, acceptance set and implementation proposal.
A fixed implementation quote is easier to compare when these inputs are defined. If the scope remains uncertain, ask for the uncertain assumptions and decision points in writing. Do not treat a low headline estimate as comparable when one proposal excludes content migration, editorial setup or URL handling.
Plan multilingual delivery with BrainGlow
BrainGlow's multilingual websites and content platforms service covers language-aware page structure, publishing templates, technical SEO, migration planning and editor handoff. Translation production and review are agreed separately. Related capabilities include web development, web design and UX and headless CMS migration.
The APRON Group bilingual site example and AgroPortal multilingual platform example show different portfolio directions. Their presence does not promise a particular search or commercial outcome.
Discuss a multilingual website scope with your URL inventory, target languages, CMS access and named content reviewers. For release-specific checks, see the multilingual launch checklist.