Translating a WordPress site sounds like a content task: take the posts, translate them, publish. In practice, a complete multilingual site has seven distinct layers that need translation - content, taxonomies, menus, interface strings, media, SEO metadata, and URLs - and most multilingual projects stall halfway because nobody listed those layers before starting. The posts get translated, the navigation stays in the original language, the search engine sees two half-finished sites, and the project quietly loses momentum.
This guide walks through the full scope of translating a WordPress site: what actually needs translating, how to choose between human, machine, and AI translation, which URL structure to use, and the technical SEO work that decides whether your translated content ever ranks. It is written for site owners and developers planning a serious multilingual launch, not a quick widget-based patch.
What Actually Needs Translating
Before choosing tools or workflows, inventory the layers. Every one of these exists on a typical WordPress site, and every one needs a plan:
Posts, pages, and custom post types. The obvious layer, and usually the largest by volume. Custom post types are easy to forget: products, events, portfolios, and testimonials all need the same treatment as blog posts.
Taxonomies. Categories, tags, and custom taxonomies carry visible names and descriptions, and they appear in archive pages, breadcrumbs, and widgets. An English category label on a Danish page is one of the most common signs of an incomplete translation.
Menus. Navigation labels are short, high-visibility strings. Each language typically needs its own menu, both because labels differ and because the information architecture sometimes should too - not every page exists in every language.
Theme and plugin strings. "Read more," "Search results for," "Add to cart," form labels, error messages. These come from the theme and from every active plugin, and they are the layer most likely to leak the original language into an otherwise translated site.
Media. Alt text and captions need translating for accessibility and image search. Some images need replacing entirely: screenshots of an interface, graphics with embedded text, or region-specific photography.
SEO metadata. Meta titles, meta descriptions, and social sharing tags must be written per language, not machine-copied. A translated page with an untranslated meta title loses the click before anyone sees the content.
URLs and slugs. Whether
/about-us/becomes/om-os/is partly an SEO decision and partly a user-trust decision. Translated slugs read more naturally and can carry keyword value in the target language.
The inventory matters because it sets expectations. A site that translates only the first layer is not multilingual; it is a site with translated posts. Users notice the difference immediately, and so do search engines.
Choosing a Translation Approach
There are three realistic ways to produce the translations themselves, and the honest answer for most sites is a combination.
Professional Human Translation
Human translation remains the quality ceiling. A professional translator working into their native language handles idiom, tone, and cultural context in ways no automated system reliably matches. The costs are equally real: professional rates typically run per word, timelines stretch with volume, and ongoing content (a weekly blog, a growing product catalog) turns translation into a permanent line item. Human translation makes clear sense for legal pages, high-stakes marketing copy, and any content where nuance carries commercial weight.
Machine Translation
Classic machine translation - the "translate everything automatically" button - is fast and cheap, and it shows. Unedited machine output tends to read stiffly, mishandles terminology, and can damage trust on pages where credibility matters. Publishing large volumes of unreviewed machine translation is also a quality risk with search engines, which have become notably better at recognizing content produced at scale without human oversight.
AI Translation With Human Review
The pragmatic middle, and the right default for most sites, is AI-generated drafts reviewed by a person who speaks the target language. Modern large language models translate substantially better than the previous generation of machine translation, particularly for tone and sentence flow, but they still make mistakes a native reviewer catches in seconds. The workflow that works: generate the draft automatically, review and correct it, then publish. The review step is not optional polish; it is the difference between a translation workflow and a liability. Whatever tooling you choose should support this by saving automated translations as drafts rather than publishing them directly.
URL Strategy: Directories, Subdomains, or Country Domains
Every multilingual site needs to answer one structural question early, because changing it later means migrating URLs: where does each language live?
Directories (
example.com/en/,example.com/da/) keep every language on one domain. All authority signals consolidate on a single domain, setup requires no DNS changes, and one SSL certificate covers everything. This is the default recommendation for most sites, and the reason most major multilingual sites use it.Subdomains (
en.example.com,da.example.com) separate languages at the host level. They allow different server configurations per language and a cleaner separation for large organizations, at the cost of DNS setup and a somewhat weaker consolidation of authority than directories.Country domains (
example.com,example.dk) send the strongest geotargeting signal and the strongest local-trust signal - a Danish customer recognizes.dkinstantly. The trade-off is significant: each domain builds authority separately, and you are maintaining multiple domains, certificates, and registrations indefinitely.
Choose directories unless you have a specific reason not to. The specific reasons are real - established country domains with existing authority, legal entities per market, or genuinely different regional offerings - but they apply to a minority of projects.
Technical SEO for Multilingual Sites
Translated content does not rank on translation quality alone. Three technical pieces decide whether search engines understand and serve your language versions correctly.
Hreflang Tags
The hreflang attribute tells search engines which language and region each version of a page targets, and how the versions relate to each other. Done correctly, it ensures a Danish searcher lands on the Danish page and prevents your language versions from competing with each other as near-duplicates. Done incorrectly - non-reciprocal annotations, wrong language codes, missing self-references - it silently does nothing. The details and the common failure modes are covered in the dedicated guide to hreflang tags for international SEO; the practical takeaway here is that hreflang should be generated automatically by your multilingual tooling, because hand-maintained hreflang breaks the first time someone adds a page and forgets it.
Per-Language Sitemaps
Search engines discover translated content faster when your XML sitemap covers every language version. Whether that is one sitemap with all languages or a sitemap per language matters less than completeness: if the Danish pages are not in any sitemap, you are relying entirely on internal-link crawling to get them discovered and indexed.
The Auto-Redirect Trap
It is tempting to detect a visitor's browser language or IP address and redirect them to "their" version automatically. Resist the forced version of this. Search engine crawlers typically visit from US infrastructure with English-language headers, which means an aggressive auto-redirect can prevent them from ever crawling your other language versions. It also overrides user intent - a Danish speaker who deliberately opened the English page gets bounced away from it. The safer pattern is a dismissible suggestion ("This page is available in Danish") or an opt-in redirect the user can decline, with the language switcher always visible as the explicit control.
String Translation and the Last 10 Percent
Almost every multilingual site goes through the same phase: the content is translated, the menus are translated, and the site still feels 90 percent done. The missing 10 percent is interface strings - the "Previous post" link, the comment form labels, the cookie notice, the search placeholder, the WooCommerce checkout field names. These strings come from the theme and from plugins, they are scattered across dozens of sources, and no single translation pass catches them all.
The workable approach is iterative: use a string translation interface that scans for translatable strings, translate what it finds, then browse the site in the target language and note what still appears untranslated. Two or three passes usually get a site to genuinely complete. This layer is also where internationalization (i18n) quality in your theme and plugins pays off - well-internationalized code exposes its strings for translation, while hardcoded strings can only be fixed in the code itself.
RTL Languages and Encoding
If your language list includes Arabic, Hebrew, Persian, or Urdu, layout enters the picture: right-to-left languages mirror the reading direction, and a theme that has never been tested in RTL mode will show misaligned icons, broken floats, and text crowding the wrong margin. Test your theme in an RTL language before committing to one, not after.
Encoding, by contrast, is mostly a solved problem on modern WordPress - UTF-8 throughout handles every script in common use - but it still deserves a checkbox: confirm the database and any custom integrations handle non-Latin characters correctly, especially anything that processes or stores content outside WordPress core. The broader discipline of adapting content, formats, and conventions per market is localization (l10n), and it extends past translation into dates, currencies, and imagery.
Choosing the Tooling
The translation layers above are exactly the checklist to evaluate a multilingual plugin against. A tool worth committing to should translate all seven layers, not just posts; generate hreflang and per-language sitemaps automatically; offer a string translation interface; support your URL strategy; and - if it automates translation - save the output as drafts for review rather than publishing unreviewed text.
Signocore Multilanguage was built against that checklist. The free version is a complete implementation of the fundamentals: up to 2 active languages from a catalog of 67, translation of posts, pages, custom post types, taxonomies, menus, and strings, automatic hreflang tags, a language switcher, per-language sitemaps, and a setup wizard that gets a site multilingual in a few minutes. The Pro version, a one-time €49 for unlimited sites with lifetime updates, removes the language limit and adds one-click AI translation using your own OpenAI, Anthropic, Gemini, or Mistral API key - with every AI translation saved as a draft for review, which is the workflow this guide recommends regardless of tooling. Pro also adds the subdomain and custom domain URL strategies and dedicated WooCommerce and Elementor integrations. If you are weighing it against the established options, the comparison of WPML and Polylang covers how the three differ on pricing and features.
A Realistic Launch Plan
Put together, a well-run WordPress translation project looks like this. Inventory the seven layers first, so the scope is visible before any translation starts. Decide the URL strategy second, because it is the one decision that is expensive to reverse. Translate the content with AI drafts and human review, or professional translation where the stakes justify it, and work through taxonomies, menus, and metadata alongside the posts rather than after them. Run the string translation passes until browsing the site in the target language surfaces nothing untranslated. Verify hreflang and sitemaps before announcing anything, since discovery is slowest at launch when it matters most.
None of these steps is difficult in isolation. What separates multilingual sites that work from the abandoned half-translations is simply that someone treated translation as a site-wide project with a defined scope, rather than a button to press. Plan the layers, pick tooling that covers all of them, and the launch is a checklist rather than a discovery process.
