WordPress Multilingual Without a Plugin: 3 Real Options

You want your WordPress site in a second language, but you are tired of plugin stacks that slow down the admin, break on updates and lock your content into their own database tables. Good news: making a WordPress site multilingual without a plugin is possible and often perfectly reasonable for small business sites. This guide shows you the three approaches that actually work, the code you need for the manual route and the trade-offs that decide which one fits your site.

Why WordPress does not do this on its own

WordPress core still has no built-in way to link an English page to its German or Spanish counterpart. The official WordPress roadmap lists “Multilingual” as Phase 4 of the Gutenberg project, the last phase on the list, with no timeline attached. Plans for that phase go back years: at the 2018 State of the Word, Matt Mullenweg said Phase 4 would aim to develop an official way for WordPress to support multilingual sites, as WP Tavern reported.

What about the language dropdown under Settings? The WordPress documentation for the General Settings screen describes Site Language simply as the dashboard language. It switches the language of WordPress itself, not your pages. Your content stays in whatever language you wrote it in.

So “multilingual without a plugin” always means one of three things: you structure translated pages yourself, you run one site per language or you let an external service translate the pages.

Why it is worth the effort

If you sell anything online, language is not a cosmetic detail. In a CSA Research survey of 8,709 consumers in 29 countries, 76% of online shoppers said they prefer products with information in their native language and 40% said they never buy from websites in other languages. In Germany, 57% of respondents buy only from local-language websites, the highest share in that study.

The same survey found that 65% prefer content in their language even if the quality is poor. That is a useful reminder: a solid translation that ships this month beats a perfect one that never leaves your to-do list.

Option 1: Manual language folders with pages and menus

This is the purest “no plugin” approach. You keep one WordPress installation and build each language as its own branch of pages.

Set up the structure

  1. Create a parent page called “de” (or “es”, “fr” and so on) and publish it. With pretty permalinks active, its URL becomes example.com/de/.
  2. Duplicate each page you want to translate, translate the content and set the “de” page as its parent. The German “About” page then lives at example.com/de/ueber-uns/.
  3. Create a second navigation menu for the German pages and assign it in your theme. Block themes let you place a separate navigation block in a German page template. Classic themes may need a small conditional in the header.
  4. Add a plain link to the other language in the header or footer so visitors can switch.

That last step matters more than it looks. Google’s guide on managing multilingual sites advises against redirecting visitors automatically based on what you guess their language is, because those redirects can stop people and search engines from reaching all versions. Visible links let everyone choose.

Tell browsers and Google which language is which

Two small snippets in a child theme’s functions.php handle this. The first sets the lang attribute on German pages through the language_attributes filter, which controls the attributes in the <html> tag:

add_filter( 'language_attributes', function ( $output ) {
    $german_pages = array( 48, 51 ); // IDs of your German pages
    if ( in_array( get_queried_object_id(), $german_pages, true ) ) {
        return 'lang="de-DE"';
    }
    return $output;
} );

The second adds hreflang annotations. Google’s documentation on localized versions requires that every version lists itself and all other versions. If page A points to page B but B does not point back, Google ignores the tags. A simple map of page IDs takes care of that:

add_action( 'wp_head', function () {
    $pairs = array(
        12 => 48, // English page ID => German page ID
        15 => 51,
    );
    $id = get_queried_object_id();
    $en = isset( $pairs[ $id ] ) ? $id : array_search( $id, $pairs, true );
    if ( ! $en ) {
        return;
    }
    $de = $pairs[ $en ];
    printf( '<link rel="alternate" hreflang="en" href="%s" />' . "\n", esc_url( get_permalink( $en ) ) );
    printf( '<link rel="alternate" hreflang="de" href="%s" />' . "\n", esc_url( get_permalink( $de ) ) );
    printf( '<link rel="alternate" hreflang="x-default" href="%s" />' . "\n", esc_url( get_permalink( $en ) ) );
} );

The x-default line marks the fallback page for visitors whose language you do not offer.

Where it hurts

The manual method is free and transparent, but it scales badly. Every new page means a duplicate, a translation and a new entry in your ID map. Theme strings such as “Read more” or the search placeholder stay in the site language. Blog archives, categories and shop pages mix languages unless you build separate categories too. For a brochure site with ten pages, that is fine. For a WooCommerce shop with 300 products, it is a part-time job.

Option 2: WordPress Multisite with one site per language

Multisite is part of WordPress core, so it counts as “no plugin”. You run a network and give each language its own subsite, for example example.com/de/ and example.com/fr/. Each subsite has its own pages, menus and settings, which means the dashboard language and many theme strings can follow the language of that subsite.

What you need to know before you start

The official guide to creating a network asks you to back up your files and database, confirm pretty permalinks work, deactivate all plugins and then add WP_ALLOW_MULTISITE to wp-config.php. After that, a Network Setup screen appears under Tools where you choose between subdomains and subdirectories.

That choice has restrictions. According to the network preparation guide, you cannot pick subdirectories if your installation has been running for more than a month, because of conflicts with existing permalinks. Subdomains, in turn, need wildcard DNS for on-demand sites and do not work when WordPress sits in a subfolder, on localhost or on an IP address. On shared hosting, you may have to ask your host for help with these requirements.

The trade-offs

Multisite gives you clean separation, but nothing connects the subsites. WordPress does not know that the German “Kontakt” page and the English “Contact” page belong together, so you still add hreflang links yourself (the snippet above works across sites if you hardcode full URLs instead of page IDs). You also maintain every page twice. Some hosts and themes handle Multisite less gracefully than a single site. It is a strong choice when your language versions really differ, such as separate teams, products or legal texts per country.

Option 3: A translation script or proxy

The third route skips WordPress content management entirely. You add a translation service’s script tag to your theme (through a child theme or the theme’s header area) and the service translates your pages for visitors. Some services work as a proxy in front of your site instead of a script.

This approach shines when you have many pages, frequent updates or other platforms besides WordPress. You write in one language and the translations follow. It also means no duplicated pages and no ID maps.

There are two questions to ask any vendor before you sign up.

  1. Does each language get its own URL? Google recommends different URLs for each language version instead of switching the language through cookies or browser settings, partly because Googlebot usually crawls from the USA without sending a language preference. If a script only swaps text on the same URL, search engines may never see your translations.
  2. What does the translated page look like after rendering? Google renders JavaScript with a headless Chromium, but content that is not visible in the rendered HTML cannot be indexed.

Quality also deserves a thought. Google’s spam policies name automated translation among the techniques that count as scaled content abuse when the pages provide little value to users. Machine translation is fine as a starting point, but someone should review the pages that matter most.

heylingo is one example of this category: you add one script tag, it translates into 30+ languages with AI and a translation memory and you can correct wording inline on your live site. The price is EUR 20 per 1,000,000 translated characters per month. Ask about the URL setup for your languages before you commit, as you would with any script vendor.

Comparison: which approach fits your site

The table below sums up how the three options differ for a typical small business site.

Manual language folders Multisite Translation script or proxy
Extra software None None (core feature) External service
Setup effort Low for few pages Medium to high Low
Ongoing effort Every page twice Every page twice Mostly review
Theme strings translated No Partly, per subsite Usually yes
Separate URLs per language Yes Yes Depends on vendor
hreflang Your code Your code Ask the vendor
Best for Small brochure sites Distinct country sites Larger or fast-changing sites

If your site has a handful of pages that rarely change, the manual route costs you nothing but an afternoon. Multisite makes sense when each language version is really its own business. Once you publish weekly or run a shop, the maintenance load of the first two options usually outweighs the convenience of avoiding a service. For a broader view of tools and pitfalls, see our guide to common website translation mistakes.

FAQ

Can WordPress translate my content without a plugin?

Not by itself. The Site Language setting changes the dashboard language, not your pages. You either create the translated pages yourself, run one subsite per language or connect an external translation service.

Is the manual method bad for SEO?

No, as long as each language has its own URL, the lang attribute is correct and your hreflang tags point both ways. Google’s guidance favors separate URLs per language, which the manual method gives you by design.

Should I redirect visitors to their language automatically?

Google advises against automatic redirects based on a guessed language because they can hide versions from users and crawlers. Offer clear links to each language instead and let visitors choose.

Does Multisite work with an existing site?

Yes, but with limits. If your installation is older than a month, you can only use subdomains, not subdirectories. Back up everything and deactivate plugins before you enable the network.

When will WordPress support multilingual sites natively?

Nobody knows yet. The official roadmap lists multilingual support as Phase 4 without a date, so plan with the tools available today.

Conclusion

Making WordPress multilingual without a plugin comes down to how much manual work you are willing to carry. Language folders with a few lines of PHP are ideal for small, stable sites. Multisite suits businesses whose language versions are truly separate. A translation script or proxy takes the duplication off your plate, as long as you confirm that every language gets its own URL. Pick the option that matches your page count and update rhythm, then work through our website localization checklist before you announce the new languages.

Want your WordPress site in 30+ languages with one script tag? See heylingo pricing.

Sources

JE

Written by

Jermaine builds and runs heylingo single-handedly from Germany and answers every support email personally.

More from the blog