A multilingual website is more than a language switcher and a translated home page. Each language version needs a defined audience, complete content, usable navigation, accurate metadata and an ongoing process for keeping information aligned.
This multilingual website checklist for Malta businesses helps project owners plan language versions before design and development begin. It covers the business, content, technical and operational decisions that prevent incomplete translations, duplicate pages and confusing customer journeys.
1. Separate language from market
Begin by deciding whether the website is multilingual, multi-regional or both. A multilingual site presents content in more than one language. A multi-regional site targets people in different countries or regions, sometimes using the same language with different offers, legal information or contact details.
Do not assume that every language version needs different regional content. Likewise, do not assume one English page serves every market if delivery terms, currencies, services or customer expectations differ.
- Which languages do customers actually need?
- Is each language aimed at Malta, another market or both?
- Will services, pricing, contacts or policies differ by market?
- Who owns content accuracy for each language?
Google also distinguishes multilingual sites from multi-regional sites in its international-site guidance. Making this distinction early helps determine URL structure, page relationships and content ownership.
2. Confirm the language scope page by page
Create a content inventory and mark which pages will exist in each language. Include service pages, forms, confirmation messages, menus, footer content, legal pages, downloadable files, error pages and automated emails.
A language selector that leads visitors into partly translated journeys creates friction. For example, a translated service page should not send someone to an untranslated enquiry form unless that limitation is made clear.
Record one of four statuses for every page and language: required, optional, not applicable or pending a business decision. This exposes gaps before the design team duplicates templates and before translators receive incomplete source material.
3. Choose a clear source language
Nominate the version that acts as the approved source for translation. Agree who can change it, how changes are communicated and whether translation begins before or after final approval.
Translating unstable drafts creates repeated work and increases the chance that versions diverge. Use a simple status such as draft, under review, approved for translation and published. Keep terminology decisions with the source material so translators do not have to guess repeatedly.
Our website content checklist for Malta businesses can help organise page purpose, copy, images, approvals and content ownership before translation starts.
4. Build a terminology guide
Prepare a short glossary covering company names, service names, technical terms, calls to action, place names and phrases that should remain untranslated. Include preferred tone, formality and spelling conventions for each language.
Terms used in navigation, forms and buttons need particular care because they repeat throughout the site. Consistent language makes the interface easier to learn and reduces review time. If the business operates in a regulated sector, identify statements that require specialist or legal review rather than ordinary translation.
5. Decide how translation quality will be controlled
Choose the appropriate combination of professional translation, internal subject-matter review and translation technology. Machine-generated text can help a workflow, but someone accountable for the target language and business context should review public content before publication.
- Who translates each content type?
- Who checks terminology and factual accuracy?
- Who approves regulated, contractual or legal wording?
- How are corrections recorded and reused?
- What happens when a reviewer is unavailable?
A fluent translation can still be commercially wrong if it changes the scope of a service, weakens a qualification or promises something the business does not provide. Review meaning and operational accuracy, not grammar alone.
6. Use a stable URL structure
Each language version should have its own crawlable URL. Common structures include subdirectories such as example.com/mt/, subdomains or separate country domains. The right choice depends on governance, hosting, markets and the ability to maintain the structure consistently.
Google recommends separate URLs for language versions rather than changing page language only through cookies or browser settings. A predictable structure also makes pages easier to share, analyse and troubleshoot.
Do not change existing URLs casually. If a live site is restructured, map every old URL to its correct replacement and plan redirects, internal-link updates and sitemap changes. Our website redesign SEO checklist covers migration safeguards in more detail.
7. Implement hreflang relationships correctly
Hreflang annotations tell Google about alternate language or regional versions of a page. Each version should reference itself and the corresponding alternatives using supported language or language-region codes. The references must be reciprocal.
Do not add hreflang links between pages that are not genuine equivalents. A translated service page should normally point to the matching service page, not simply to the other language’s home page.
Google supports hreflang through HTML, HTTP headers or XML sitemaps and states that one correctly managed method is sufficient. Its localized-page documentation also explains the optional x-default value for a fallback selector or general page.
8. Set canonical URLs with care
Translated pages are not duplicates merely because they communicate the same idea in different languages. Each properly translated page will normally use a canonical pointing to itself, while hreflang connects it to the alternatives.
Regional pages in the same language may contain very similar content. If a canonical is required, it should be planned together with hreflang and the intended search market. Avoid automatically canonicalising every language version to the source-language page, as that can undermine the purpose of publishing distinct versions.
9. Let visitors choose their language
Provide an obvious language selector that uses readable language names. Keep the visitor on the equivalent page when they switch, where that page exists. If it does not exist, explain the limitation or send them to a useful language landing page rather than creating a silent loop.
Avoid forcing a language purely from IP address or browser settings. Automatic suggestions can be useful, but visitors should be able to override them. Google also warns that locale-adaptive delivery can make some versions difficult to crawl if they are not available through separate URLs and explicit links.
10. Declare page language for accessibility
The HTML language attribute helps browsers and assistive technologies interpret pronunciation, writing conventions and other language-specific behaviour. Set the primary language on the html element and mark passages in another language when appropriate.
W3C advises declaring the default language on the HTML element and using language attributes around content that changes language. Review its guidance on declaring language in HTML.
11. Localise the complete customer journey
Translation should extend beyond page paragraphs. Review navigation, search, forms, validation errors, thank-you messages, cookie controls, account screens, checkout steps, invoices and transactional emails.
Confirm whether telephone support, consultations or fulfilment are available in each published language. Do not imply a service capability that the operational team cannot deliver. Set expectations clearly where written support exists but spoken support does not, or where response times differ.
12. Translate SEO elements intentionally
Do not copy a source keyword into another language and assume people search the same way. Research the terminology, intent and phrasing used by the target audience. Then write a useful page title, main heading and description for that version.
- Use unique titles that describe the translated page.
- Translate image alternatives according to the image’s purpose and context.
- Use descriptive internal-link text in the target language.
- Include each indexable language version in the correct sitemap setup.
- Check that robots and canonical settings do not block the new version.
13. Test before launch
Review the website with native or highly competent target-language users on mobile and desktop. Test every selector, menu, form, link and automated response. Look for truncated buttons, broken layouts, untranslated fragments and pages that switch back to the source language unexpectedly.
Technical checks should include status codes, canonicals, hreflang reciprocity, indexability, XML sitemaps, language attributes and redirects. Use a representative page set first, then crawl the full language section before publication.
14. Plan ongoing translation maintenance
Assign an owner for detecting source-content changes and initiating translation updates. Record whether urgent corrections can be published in one language before others and how the temporary difference will be communicated.
Review outdated offers, staff information, legal text, downloads and metadata across every version. When a page is retired, decide what should happen to each alternate URL and update hreflang links accordingly. A multilingual site needs a continuing content process, not a one-time translation project.
Questions for your website proposal
- Which pages and functions are included in each language?
- Who provides, reviews and approves translations?
- Which URL structure and language codes will be used?
- How will hreflang, canonicals and sitemaps be implemented?
- How will forms and automated messages be localised?
- How are future content changes identified and translated?
- Who tests each language version before launch?
Plan the language operation, not only the translation
A successful multilingual website gives each audience a complete, discoverable and maintainable journey. The most important decisions concern scope, ownership and ongoing updates. Technical annotations support that plan, but they cannot repair missing or poorly governed content.
If you are planning a multilingual website, use this checklist alongside DCP’s website development brief. You can also review our web design services in Malta or contact the team.
