Going multilingual is a real SEO opportunity, but only if the technical foundations are right. Miss one of these and you end up with the wrong pages ranking, duplicate-content confusion, or translated pages that are never indexed at all. Work through the list in order — the early items are the ones that break the later ones.
1. Pick a clean URL structure
Use language subdirectories (/de/, /fr/) unless you have a specific reason not to. Google supports subdirectories, subdomains and country-code top-level domains for multi-regional sites, and treats all three as valid — the trade-offs are operational rather than algorithmic (Google Search Central).
Subdirectories win for most sites because everything stays on one hostname: one certificate, one set of DNS records, and link equity that accrues to a single domain rather than being split across several. ccTLDs give the strongest geographic signal but mean running genuinely separate properties. Compare the shapes with the URL structure previewer.
Whatever you choose, choose it before launch. Changing URL structure later means a full redirect map and a re-indexing cycle.
2. Set the correct lang and dir attributes
Each page must declare its language on the <html> element: <html lang="de">. This is what screen readers use to select a voice and what browsers use to offer translation — it is an accessibility requirement as much as an SEO one.
For right-to-left languages such as Arabic, Hebrew, Persian and Urdu, also set dir="rtl" and confirm your theme actually mirrors: navigation, alignment, icons, and any absolute positioning in custom CSS. A page with dir="rtl" and a left-aligned layout is worse than no RTL support at all, because it looks broken rather than untranslated.
3. Implement reciprocal hreflang with x-default
Every page needs a complete, reciprocal set of hreflang annotations — including a self-reference and an x-default. Missing return links can cause Google to disregard the annotations entirely, so this is pass/fail rather than a matter of degree.
Build the tags with the hreflang generator, confirm them with the hreflang checker, and see adding hreflang in WordPress for implementation.
4. Get canonicals right per language
Each language version needs a self-referencing canonical pointing at itself — never at the source-language page. This is the single most damaging mistake on the list, because it is silent: the pages exist, they are crawlable, and they are quietly being consolidated into the original.
A cross-language canonical also directly contradicts your hreflang, which asserts the pages are distinct alternates. Given contradictory signals, you cannot predict which one wins.
5. Translate titles and meta descriptions
Don't leave English titles and meta descriptions on translated pages. These are the two lines a searcher actually reads before deciding whether to click, and an English snippet under a German URL reads as a broken or careless site.
Translate Open Graph and Twitter Card tags too — they are what appears when someone shares the page. If you run Yoast or Rank Math, verify their generated meta is translated rather than duplicated from the source language; SEO plugins store their titles and descriptions separately from post content, so a translation layer that only handles post content can miss them entirely.
6. Provide language-aware sitemaps
Include every language URL in your XML sitemap. Ideally, use xhtml:link alternate annotations so each entry declares its counterparts — a valid way to express hreflang at scale without markup on every page (Google Search Central, sitemaps.org).
Note that WordPress core's built-in sitemaps do not include alternate-language annotations, so this generally comes from your SEO or multilingual plugin.
7. Use readable, localized slugs
Give each translated page a clean, transliterated slug rather than a percent-encoded string — especially for non-Latin scripts, where an untransliterated slug becomes an unreadable escape sequence in the address bar and in any shared link. The slug transliterator handles the conversion.
Decide early, because changing slugs after indexing costs you redirects.
8. Translate structured data and alt text
Product, Article and FAQ schema should reflect the translated content — a German page carrying English schema descriptions sends mixed signals about what the page is. Image alt text should be localized too, which serves both image search and screen-reader users in that language.
9. Don't auto-redirect by IP or browser language
Automatically redirecting visitors to a language based on IP geolocation or Accept-Language is a well-known way to cause problems. It traps users who want a different version — someone in Germany who prefers English cannot reach the English page — and it can prevent crawlers from seeing versions other than the one their request location resolves to.
Offer a clearly visible language switcher and let people choose. If you want to suggest a language, show a dismissible banner rather than performing the redirect.
10. Don't machine-translate and forget
Machine translation has become genuinely good, but quality is uneven across the parts of a page that matter most. Review the highest-leverage strings by hand: navigation labels, calls to action, page titles, pricing and legal text, and anything with a brand term or a product name in it.
Make sure your tooling protects those human edits, so a later re-sync does not silently overwrite a correction someone made deliberately.
11. Keep translations in sync with the source
Translations drift. You edit an English page, and four translations quietly become stale — still indexed, still ranking, now describing a product you no longer sell. Whatever approach you use needs an answer to "what changed since this was translated?", whether that is automatic re-translation on edit or a report of stale content to review.
12. Verify indexing per language
After launch, confirm in Google Search Console that each language version is actually being crawled and indexed, and that the International Targeting report is not accumulating hreflang errors. Check coverage per URL pattern — /de/ separately from /fr/ — because a whole language can fail to index while the others are healthy, and a site-wide average hides that completely.
Make it automatic
Most of this list — hreflang, per-language canonicals, translated meta, language-aware sitemaps, lang and dir attributes, localized slugs — is mechanical, and mechanical work is exactly what decays when done by hand across a growing site. Gloty generates all of it automatically for every page, which turns multilingual SEO into a setup step rather than a standing chore. For the wider picture, start with the pillar guide on making WordPress multilingual.