A practical checklist for businesses preparing English, Greek, German and Arabic editions
Short answer
Plan each language as a complete customer journey with its own crawlable URL, reviewed content, navigation, forms, SEO fields and public-page QA. Decide the audiences, source language, translation owner, URL structure and Arabic RTL checks before development so incomplete or conflicting locale pages do not reach publication.
A translated homepage can look ready while its contact form still answers in another language, or its language switch sends visitors back to the homepage. If you are preparing a multilingual site, planning the complete journey now can save you from rebuilding those details later. Start with what customers need to do, then define how each language will support that task.
Start with audiences and tasks, not flags
List the people you need to serve and the action each group should be able to complete. English may support international enquiries, Greek may serve customers across Greece, while German and Arabic editions may require different examples, terminology or reading direction. A translated homepage alone is rarely enough if the service page, form confirmation, legal notice or follow-up message remains in another language.
For every language, record the priority journey: landing page, service explanation, proof or portfolio, contact step and confirmation. Localize the substance where it helps the reader, but do not create doorway pages or imply offices, demand or experience that the business does not have.
Build one page inventory for all locales
Create a simple inventory before anyone translates. Mark each page as required, optional, shared or intentionally unavailable for each language. Include navigation, footer links, forms, validation messages, search labels, cookie text, media captions, downloadable files and emails triggered by the website.
- Decide which pages launch together and which can follow later.
- Name one source language and one responsible reviewer for each target language.
- Record whether images, screenshots and files need localized alt text or replacement artwork.
- Keep private editorial notes outside the reader-facing article or page.
Choose stable URLs before publication
Google recommends separate URLs for each language version rather than changing the same URL only through cookies or browser settings. A directory pattern such as /el/, /de/ and /ar/ is understandable to users and can be managed in WordPress with a multilingual plugin, but the exact structure should be chosen before pages are published.
Do not rely on automatic redirects as the only way people or crawlers can reach a translation. Every important locale needs a crawlable URL and a visible language switch that leads to the corresponding page, not merely to another homepage.
Connect equivalent pages correctly
Equivalent language pages should reference each other through hreflang. Google’s guidance says each version should list itself and the other versions, using fully qualified URLs. Reciprocal references matter: if page A names page B but page B does not return the relationship, Google may ignore the pair. An x-default URL can provide a fallback where appropriate.
Hreflang can be supplied in HTML, HTTP headers or an XML sitemap. Choose the method the site can maintain reliably. On a WordPress site where a multilingual plugin already generates sitemap alternates, the absence of tags in the visible page head alone is not enough to diagnose an error; verify the generated sitemap and the actual translation relationships.
Plan translation as an editorial workflow
Machine translation can accelerate a first draft, but it does not replace review for service scope, calls to action, technical terms or cultural fit. The source page may also contain text from widgets, custom fields, forms, SEO fields, image metadata and menus. Decide where each string is stored and who is responsible for approving it.
A useful workflow separates four states: source approved, localized draft, locale QA passed and published with public readback. A draft document is not a published page. A WordPress save is not proof that the public URL shows the intended copy.
Treat Arabic as a complete RTL experience
Arabic quality is more than translating paragraphs. Check the document direction, menus, breadcrumbs, forms, icons, tables, numbers, phone or email fields, mixed Latin text and mobile spacing. Some components need left-to-right treatment inside an otherwise right-to-left page. Test the real public page on a narrow mobile viewport and verify that buttons, long URLs and form errors do not overflow.
Prepare locale-specific SEO fields
Each edition needs a natural title, meta description, visible heading and accessible body text in the target language. Use a self-canonical URL for an original localized page unless there is a deliberate, verified reason to do otherwise. Do not point every translation’s canonical to the source-language page, because that can conflict with the purpose of publishing distinct localized content.
Search demand, rankings and click-through rates are unknown until measured in a real source such as Search Console. Do not turn a keyword hypothesis into a claim of demand. Write first for the buyer’s question, then use verified search data to refine titles and internal links.
Multilingual website brief: decisions to record
- Languages and genuine audience for each language.
- Source language, translation owner and native reviewer.
- Required pages, forms, emails, menus, media and downloadable files.
- URL pattern, language switch behaviour and fallback page.
- Page-to-page translation relationships and hreflang method.
- SEO title, description, canonical, schema and sitemap checks for every locale.
- Desktop, mobile and Arabic RTL acceptance tests.
- Publication order, rollback owner and final public-page readback.
What to ask before development starts
Ask whether the website partner will translate only visible page copy or also menus, forms, SEO fields, media metadata and system messages. Confirm who owns the final wording, how incomplete translations are handled, and whether the language switch connects equivalent pages. For e-commerce, add product attributes, emails, checkout messages and policy pages to the inventory.
For a manageable starting point, choose one service page and its enquiry journey in each language. Confirm the wording, navigation and form response together, then use that working pattern for the remaining pages.
Frequently asked questions
Does every page need to launch in every language?
No. Prioritize the pages needed for a complete customer journey in each language, and record any intentionally unavailable pages. Do not publish a thin or unfinished translation simply to match a page count.
Should translated pages use the same URL?
No. Google recommends separate URLs for language versions. Use a stable structure and connect equivalent pages with maintainable hreflang relationships.
Is automatic translation enough for publication?
Automatic translation can produce a starting draft, but service scope, calls to action, forms, metadata, media text and Arabic RTL presentation still require fluent review and real-page QA.
Sources
- Google Search Central — Managing multi-regional and multilingual sites
- Google Search Central — Tell Google about localized versions
- WPML — Language setup
- WPML — Translating content
Plan the languages around your customers
If you are preparing a multilingual WordPress website, explore our website design service or tell us which languages and customer journeys you need. We can discuss a clear page inventory and review process before development begins.
