
Website Information Architecture for SEO and Real Users
Build a page map that helps visitors find answers without multiplying thin pages or confusing navigation.
Read article →Plan multilingual website SEO with separate language URLs, equivalent page mapping, reciprocal hreflang, human-reviewed translations, and a visible language switcher.

Ascendweb Editorial Team
Website development and SEO
A multilingual website needs more than a translated navigation bar. Visitors need a complete page in a language they can use, and search engines need stable URLs that make the language versions discoverable. Multilingual website SEO starts with a page-by-page plan: which content has an equivalent, what each version says, and how users can switch languages.
Language targeting and country targeting are different decisions. An English page does not automatically mean a business serves every English-speaking country. Keep the business location, contact information, pricing currency, and actual service area explicit.
Use distinct URLs for distinct language content, such as a language folder or a clearly mapped localized path. Avoid showing different languages at the same URL based only on cookies, IP address, or browser preferences. Google recommends separate URLs because automatic variation can make it harder for crawlers and users to reach all versions.
Create a route map before translating. A source page may map to a localized URL with a different slug, but the destination should satisfy the same page purpose. A home page should map to a home page; a pricing page should map to equivalent pricing information. When a page has no real translation or equivalent, link the language switcher to the appropriate language home instead of inventing an alternate.
| Source language | English route | Alternate status |
|---|---|---|
| /tentang-kami | /en/about | Equivalent if both explain the same business |
| /harga | /en/pricing | Equivalent if current package scope and prices match |
| /artikel/local-guide | No English version yet | Do not emit hreflang until the full English equivalent exists |
Keep each page predominantly in one language. Translate the visible content, navigation, form labels, validation messages, image alternatives, metadata, and structured data where appropriate. A page with an English title, Indonesian body, and mixed-language controls is harder for visitors to use and does not become a full English page because its URL contains `/en/`.
Use a human review for meaning, terminology, currency, legal notes, product names, and calls to action. Keep brand names and technical terms where they are normally used. Do not add claims about foreign customers, international delivery, local offices, or regional support unless those facts have been confirmed.
For pages that are genuine language alternatives, add reciprocal `hreflang` annotations. Each version should identify itself and the other available versions with complete absolute URLs. Do not connect a page to a superficially similar page with a different purpose, and do not create country-specific variants unless the content is actually tailored to those regions.
Open each language route directly in a clean browser session and confirm it does not depend on a prior cookie. Inspect the language declared in the document, the visible language of the main content, the self-canonical URL, and the alternate links. A user should be able to switch to the equivalent page and still understand the page without referring back to the other language.
Use Search Console to monitor each URL and query over time. Indexing is not guaranteed simply because a page appears in a sitemap. Check for accidental noindex tags, duplicate routes, untranslated sections, and broken alternate links before diagnosing performance as a keyword problem.
Source: Google Search Central: managing multilingual and multi-regional sites
A language switch should be easy to find and should preserve context when a genuine equivalent exists. If someone is reading an English service page, send them to that service in Indonesian rather than resetting them to the home page. If a complete equivalent has not been written, make the fallback clear and predictable. Do not silently replace an English page with Indonesian copy based on location or a browser preference; that can disrupt a visitor and make the URL harder to share.
Review the entire path in each language: navigation, breadcrumbs, forms, confirmation messages, buttons, error text, support details, and legal or privacy information. Images that contain words may need localized versions, while alternative text should describe the image naturally in the page's language. Check that prices and measurement units are labeled clearly and that translation has not changed a promise, limitation, or eligibility rule.
Treat translations as part of the content workflow rather than a one-time export. Give each language version an owner, a source of truth, a review date, and a list of facts that must remain synchronized, such as package scope, business contact details, and location. When the source changes, identify affected translations and review them before publishing inconsistent information. A shared content model can help, but language-specific prose should still be edited and checked by someone who understands the intended reader.
For every launch, keep a small checklist of language-specific verification: the correct localized route, a complete translation, language declaration, title and description, social preview, canonical, and any alternate links. Check how text fits the existing design at common screen sizes, because English and Indonesian wording may have different lengths. The goal is to preserve the same usable interface while allowing each language to read naturally.
Ask a reviewer to complete a real task in each version, such as finding a price, contacting the business, or locating a service detail. A fluent review catches awkward terminology and missing context that a technical crawl cannot. Recheck business facts against the approved source before shipping the revision.

Ascendweb Editorial Team
Website development and SEO
Ascendweb's editorial team prepares practical guides about website planning, content, and implementation. Business claims and package details should be checked against current published information.

Build a page map that helps visitors find answers without multiplying thin pages or confusing navigation.
Read article →
Plan the URL map and content review before design work, then check redirects, indexing, and enquiries after launch.
Read article →