If your business serves Indonesian and English-speaking customers, a multilingual website is more than duplicating text. You are creating two experiences that should both feel complete. Indonesian visitors need natural explanations and familiar examples. English-speaking visitors need wording, examples, and calls to action that feel written for them.
The safest approach is to design the structure before translating the sentences. Choose the primary language, decide on URL conventions, map the pages that matter, and define how language versions connect. This prevents mixed-language buttons, broken alternate links, and duplicate URLs that search engines cannot interpret clearly.
Start with a business goal
Ask three questions before opening the editor. Who is the main user today? Which pages help that person make a decision? Does the second language represent a real market, or is it only a future idea?
A global software product may use English as its primary language and Indonesian as an important option. A local Indonesian service business may use Indonesian by default and publish English pages for tourists, expatriates, or international partners. Neither approach is universally correct.
Start with the pages closest to revenue: home, services, pricing, about, contact, and one or two articles with a clear search opportunity. Six finished pages are more useful than thirty pages with untranslated placeholders.
Choose readable URLs
Google recommends separate URLs for different language versions. A folder structure is usually the simplest choice:
example.com/id/for Indonesian pagesexample.com/en/for English pagesexample.com/id/layanan-pembuatan-websitefor an Indonesian service pageexample.com/en/website-builderfor an English service page
Subdomains such as id.example.com and en.example.com can work, but they add operational and technical overhead. Separate domains may be useful when markets have different teams, prices, or legal requirements, but they are not a light choice for a small business.
Avoid changing the language only through a cookie, location, or browser language header. A crawler may see one version while visitors cannot share a stable URL for a specific language. Explicit URLs also make it easier for a content team to know which page needs updating.
The Indonesian and English slugs can differ when the search phrases differ. What matters is that metadata and alternate links explain the relationship between the versions.
Build a page map
Create a simple sheet with the page name, Indonesian URL, English URL, translation status, canonical URL, alternate link, and review date. This catches problems such as an English pricing page whose main button still leads to an Indonesian checkout path.
Pair pages carefully. An Indonesian page about a local website service may not be the same page as an English page about global subscription software. If the offer and audience differ, create separate pages instead of forcing them to be translations.
Group pages by purpose. Complete the core set first, then add search-driven blog content. Do not translate every article simply because the Indonesian version exists. Choose topics that have a real audience and a relevant offer in the second language.
Translate intent, not word order
A strong translation keeps the intent, not the original sentence order. "Prompt to website" may be natural in English, while Indonesian may need a phrase closer to "turn one sentence into a website." A button labelled "Get started" may become "Mulai sekarang" rather than a literal phrase that sounds mechanical.
Create a small glossary for product names, feature labels, payment terms, package names, and technical phrases. Decide how formal each language should sound. Review taglines, testimonials, prices, examples, dates, currencies, and contact instructions separately.
Do not translate a sales claim without checking whether it remains true in the second market. If an English page targets a global audience, add context when an Indonesian example would otherwise feel unexplained.
Design navigation and language switching
The language switcher should be visible, consistent, and labelled clearly. ID | EN is compact, while Bahasa Indonesia and English are clearer in a spacious navigation menu.
When someone is reading an Indonesian service page, the English switch should open the matching English service page, not the English home page. The same rule applies to articles. If the pair does not exist yet, use a clear fallback and avoid creating a fake URL.
Do not force a redirect based on the browser language. A visitor may be preparing English material while browsing from Indonesia. Let people choose, optionally remember their preference, and keep every language URL directly accessible.
Apply technical SEO per language
Each language version needs its own title, meta description, H1, and main content. Do not reuse an Indonesian title on an English page because the template is shared. Make sure the rendered HTML uses the intended language and that the main content stays in one language.
Use hreflang to describe the relationship between versions. An Indonesian page can reference its id URL and the English en URL. The English page should repeat the same set and reference itself. One-way annotations can be ignored.
A self-referencing canonical is usually the clearest signal for each language URL. If the Indonesian page canonicals to English, you may be telling search engines that the Indonesian page is not the version you want to keep. Validate canonical and alternate tags in live HTML, not only in local configuration.
A sitemap can help crawlers discover all URLs, but it does not guarantee indexing. Important pages should also be reachable through navigation and internal links. Submit the sitemap only after the URLs are live and placeholders are gone.
Plan a bilingual blog
A bilingual blog needs an editorial calendar, not only a language button. Indonesian and English keywords may represent different intent, examples, and questions. Start with topics that are useful for each audience.
You can begin with one core idea and adapt it locally. An Indonesian article may mention WhatsApp, local payment habits, or Indonesian customer expectations. An English version may discuss email, booking, or a global market. The structure can be related, but the opening, examples, sources, and call to action should feel original.
Link each article to a relevant product or service page in the same language. An Indonesian article that sends most readers to /en/pricing can feel like an accidental handoff. Audit your links as the content library grows so new translations do not introduce 404s.
Test before launch
Open several pages anonymously on desktop and mobile. Check whether the visible language matches the URL, whether navigation remains readable, and whether contact buttons reach the right destination. Test forms, error messages, prices, and footer links too.
Use this checklist:
- Every core page has a stable language URL.
- Title, description, H1, and main content use the intended language.
- The language switcher opens the correct page pair.
- Canonical and hreflang use full URLs and reference each other.
- Internal links do not mix languages without a reason.
- Images have natural alt text in each language.
- The sitemap contains URLs that are actually live.
- Mobile pages do not create horizontal overflow.
- Forms and calls to action reach the correct inbox or page.
- No placeholder, mixed-language, or error text remains.
If your team uses a prompt-based website builder, it can accelerate the first draft. Forgelo's workflow covers the path from brief to website, while section editing lets you refine one part without rebuilding the page. That speed does not replace language review, fact checking, or live page testing.
Common mistakes
The first mistake is translating navigation while leaving the main content in the old language. The result looks bilingual but feels incomplete. The second is using one URL for two languages, which complicates sharing and crawling.
Other common problems are one-way hreflang annotations, unreviewed machine translation, and translated prices with forms that were never tested. Another mistake is launching too many pages at once. Release a complete core set before filling the sitemap with half-finished translations.
A practical launch sequence
Set the language goal, choose the URL pattern, map page pairs, create a glossary, write the core pages, add canonical and alternate signals, generate the sitemap, and test from a visitor's perspective. Then expand the blog gradually and use search data to choose the next topics.
A strong multilingual website is not the one with the most languages. It is the one where every version feels complete, is easy to find, is easy to understand, and leads visitors to the right action. Start with two languages you can maintain consistently. Once the system is stable, a third language becomes an extension rather than a new project.
