Multilingual WordPress SEO Architecture After an AI Site Migration

An AI-built website that is migrated to WordPress often becomes multilingual at the same moment: the team that had one English landing page in Lovable or Bolt now wants Dutch, German, Spanish and perhaps Arabic versions in a CMS that can manage them. Multilingual SEO is one of the most technically demanding areas of search optimisation. Mistakes do not usually cause dramatic errors; they cause quiet ones — pages that are indexed in the wrong country, translations treated as duplicates, or entire language versions that never appear in search results. This guide covers the architecture you need after a migration: URL structure, hreflang, canonicals, the HTML lang attribute, right-to-left languages and a realistic indexing strategy.

1. Choosing a URL structure

Search engines need to identify each language version by its URL. There are three common structures:

• Subdirectories — example.com/nl/, example.com/de/. One domain, shared authority, simple hosting. This is the recommended default for most projects.
• Subdomains — nl.example.com. Slightly more separation, but authority is partly split and configuration is more complex.
• Country-code domains — example.nl, example.de. The strongest geographic signal, but each domain has to build authority on its own and costs more to operate.

Avoid language selection by cookie, browser language detection or query parameters (?lang=nl) as the only mechanism. Crawlers do not send cookies, typically crawl from the United States with English headers, and may never see the other versions. Every language version must have its own crawlable URL. Automatic redirects based on Accept-Language should be avoided entirely for the same reason; offer a visible language switcher instead.

2. Hreflang implementation

Hreflang tells search engines which URLs are equivalent pages in different languages or regions. It does not boost rankings; it ensures the right version is shown to the right user and prevents translations from competing with each other.

The rules are strict:

1. Every page lists every version, including itself. The English page lists English, Dutch and German; the Dutch page lists the same three.
2. Annotations must be reciprocal. If the English page points to the Dutch page but the Dutch page does not point back, Google ignores the pair.
3. Use valid codes. Language codes follow ISO 639-1 (nl, de, ar); optional region codes follow ISO 3166-1 alpha-2 (nl-BE, en-GB). en-UK is a common and invalid mistake.
4. Use absolute URLs that return HTTP 200 and are canonical. Pointing hreflang at a redirect or a non-canonical URL invalidates it.
5. Add x-default for the version shown when no language matches — usually the English page or a language selector.

Hreflang can be implemented in three places: <link rel="alternate" hreflang="…"> elements in the HTML head, HTTP headers (useful for PDFs), or xhtml:link entries in the XML sitemap. For sites with many languages, the sitemap method keeps the HTML lighter and is easier to audit centrally; using both head and sitemap is acceptable as long as they agree. A site with 40 languages generates 41 annotations per page — which is precisely why it should be generated by code or a plugin, never maintained by hand.

3. Canonical structure

The canonical tag tells search engines which URL is the preferred version of a page. In multilingual setups, the single most damaging mistake is pointing all translations' canonicals at the English page. That instructs Google to treat the translations as duplicates of the English original and drop them from the index.

The correct pattern is simple: each language version is self-canonical. The Dutch page's canonical points to the Dutch URL; the German page's canonical points to the German URL. Hreflang then connects them as a cluster. Canonicals should also be absolute, use the exact preferred host (with or without www, consistently), use HTTPS and match the trailing-slash convention of the site.

After a migration from an AI builder there is a second canonical risk: the old hosting domain (a .lovable.app, .vercel.app or .replit.app URL) may remain online and indexable. Either redirect it with 301s to the new WordPress domain or make sure it serves a canonical pointing to the new domain. Otherwise Google may choose the old domain as canonical.

4. The HTML lang attribute

The lang attribute on the <html> element declares the language of the page content. Google states that it does not use lang for language detection in ranking, but other search engines such as Bing do weigh it, and it is essential for accessibility: screen readers choose pronunciation rules based on it, and browsers use it for hyphenation, spell checking and translation prompts.

Single-page applications exported from AI builders very often hard-code <html lang="en"> in their one index.html, regardless of route. After migration, every language version must render the correct attribute in the server-side HTML: lang="nl" on Dutch pages, lang="de" on German pages. In WordPress, multilingual plugins such as WPML, Polylang and TranslatePress set this automatically through language_attributes(), provided the theme's header.php or block template outputs it correctly. Verify it by viewing the page source, not the DOM inspector, since JavaScript-set values do not count for crawlers that do not render.

5. Right-to-left languages and RTL parsing

Arabic, Hebrew, Persian and Urdu are written right to left. Supporting them correctly requires more than translation:

• Set dir="rtl" on the <html> element for those languages. WordPress does this automatically when the site or the active language is RTL, and loads an rtl.css stylesheet if the theme provides one.
• Use CSS logical properties — margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, text-align: start instead of left. Layouts then mirror automatically. Tailwind's ms-/me- utilities and modern theme.json spacing support this approach.
• Mirror directional icons such as arrows and chevrons, but not logos, media controls or numbers.
• Check mixed content: brand names, URLs and code inside RTL text may need <bdi> or dir="ltr" wrappers to display in the correct order.
• Choose fonts that properly support the script; many Latin web fonts fall back to system fonts for Arabic and look inconsistent.

For SEO, RTL pages follow the same hreflang and canonical rules as any other language. The most common issue we see after migrations is not search-related but visual: a layout that was built with physical left/right properties renders awkwardly in RTL. This is a small, fixable issue that should not delay publishing.

6. Translation quality and the scaled-content problem

Search engines increasingly evaluate whether multilingual content is genuinely useful. Machine-translated text that has not been reviewed, or dozens of language versions that are word-for-word clones with no local relevance, can be treated as low-value scaled content. Localise rather than translate: adapt titles, meta descriptions and headings to the search terms people actually use in that language, use local examples, currencies and date formats, and make sure each version has a clear purpose. Supporting pages — an about page, contact details, a privacy policy and in-depth guides — strengthen the site's overall trust signals and help the language versions get indexed.

7. XML sitemaps for multilingual sites

Every language URL should appear in the XML sitemap, and for large clusters the sitemap is the cleanest place to declare hreflang. Each <url> entry lists its own <loc> plus <xhtml:link rel="alternate" hreflang="…"> entries for every version, including itself and x-default. Declare the xmlns:xhtml namespace in the urlset element. Reference the sitemap in robots.txt and submit it in Google Search Console and Bing Webmaster Tools under the exact property — including www or not — that the site actually uses.

8. Indexing strategy after migration

A new or newly migrated multilingual site does not get indexed in one day. Google discovers URLs, queues them, crawls them according to the site's perceived importance and then decides which to index. A realistic strategy:

1. Launch with correct canonicals, hreflang, lang attributes and a complete sitemap from day one. Fixing them later costs re-crawl time.
2. Set up 301 redirects from every old URL and from the old builder domain.
3. Submit the sitemap and request indexing for the homepage and the main language entry pages in Search Console.
4. Build internal links: a visible language switcher on every page, and links from guides and supporting pages to the main language versions.
5. Monitor the "Pages" report. Status "Discovered – currently not indexed" is normal for weeks on a new site; "Duplicate, Google chose different canonical" signals a canonical or hreflang problem that needs attention.
6. Earn a few relevant external links. Crawl priority follows authority.

9. Tooling in WordPress

WPML, Polylang and TranslatePress handle language URLs, hreflang, lang attributes and language switchers. SEO plugins such as Yoast, Rank Math or SEOPress integrate with them to output localised titles, descriptions and multilingual sitemaps. Choose one multilingual plugin and one SEO plugin that officially support each other, and avoid stacking overlapping plugins that each emit their own hreflang tags.

Conclusion

Multilingual SEO after an AI site migration comes down to a few strict principles: one crawlable URL per language, self-referencing canonicals, complete and reciprocal hreflang with x-default, a correct server-rendered lang and dir attribute, and a sitemap that mirrors it all. Get those right at launch, localise your content rather than cloning it, and give search engines time. In our testing, Convert2WP.net produced the best starting point for this work, with clean markup that multilingual plugins can extend without fighting the theme.