DEV Community: Serghei Streltov

Why your hreflang tags are being ignored

Serghei Streltov — Tue, 25 Aug 2026 09:43:27 +0000

Originally published on the WeLocale blog.

Most SEO work is a matter of degree. You improve a title, you gain a little. hreflang is not like that. It either forms a valid set that search engines act on, or it does nothing at all, and the failure is completely silent. No warning, no penalty, no message in Search Console telling you the tags you carefully added are being discarded.

We build a translation widget, which means we generate hreflang tags for other people's sites. This post is what we have learned about why they get ignored, including the parts where our own approach has real limits.

The rule that breaks most setups

hreflang is not a property of a page. It is a property of a set of pages, and every page in that set has to agree.

If your English page says the German version is at /de/, the German page has to say the English version is at /. If it does not, the declaration is one-way, and one-way declarations get dropped. Google calls these return links and treats their absence as a reason to distrust the whole set.

This is why hreflang fails in a way that feels unfair. Every individual page looks correct when you inspect it. The problem only exists in the relationship between pages, which is exactly the thing you cannot see by viewing source on one URL.

The corollary catches people too: each page must list itself. A German page whose tags mention English and French but not German is an incomplete set. Incomplete sets get dropped.

The other four failure modes

en-UK. The language code comes from ISO 639-1 and the region code from ISO 3166-1. In ISO 3166-1 the United Kingdom is GB. There is no UK. The tag is silently invalid, and it is easily the most common hreflang error on the web. Same class of mistake: lowercase regions, uppercase languages, and a region with no language at all.

URLs that redirect. hreflang has to point at the final URL. If it points at http and you redirect to https, or it omits a trailing slash your server adds, the target is a redirect rather than a page, and it does not count. This one bites hardest after a migration, when everything still works fine for humans.

Targets a crawler cannot use. A page blocked in robots.txt, or carrying noindex, or canonicalised somewhere else, cannot be an hreflang target. The canonical conflict is the quiet one: your hreflang says these five pages are alternates of each other, your canonical tag says four of them are copies of the fifth. Both look right in isolation and together they cancel out.

Mixing declaration methods. You can declare hreflang in HTML link tags, in HTTP headers, or in an XML sitemap. Pick one. Declaring the same page's alternates in two places is a reliable way to produce conflicting signals.

What client-side injection can and cannot do

Here is the part where I have to be straight about our own product, because it is directly relevant.

Our widget injects hreflang tags from JavaScript, after the page loads. That has consequences worth understanding before you rely on it, whoever your vendor is.

Google renders JavaScript, so tags added this way can be picked up. But rendering happens in a second pass, separately from the initial crawl, and it is not guaranteed to happen on any particular schedule. Server-rendered tags are simply stronger. Other search engines are less reliable about running JavaScript at all.

The second consequence is the URL shape. We build alternates as a query parameter, ?lang=de, because we do not create a separate page per language. That is a deliberate trade: nothing gets duplicated in your CMS, and you do not re-translate when you edit a paragraph. What you give up is a clean path per language. A query parameter can be indexed, but a path like /de/ is a stronger signal, and tools that translate URL slugs will beat us on this specific point.

So if multilingual organic search is the main reason you are translating your site, and you want each language on its own indexable path, a tool that produces real per-language URLs fits better than we do. GTranslate serves translated sites from its own network with translated URLs. WordPress plugins such as WPML and Polylang create a post per language. Both are the right answer for that requirement, and I am not going to pretend otherwise.

Where a runtime widget makes sense is the other case: you want visitors to read the site in their language, you do not want a second copy of every page, and hreflang is a useful signal rather than the entire strategy.

How to check what you actually have

Three steps, in order of how often they find something.

First, view source on two different language versions and compare the blocks. Not one page. Two. You are checking that they reference each other and that each includes itself. This finds the return-link problem, which no single-page checker can.

Second, take every URL in the set and request it directly. Any redirect, any 404, any noindex, and that entry is dead.

Third, check that your canonical tags agree with your hreflang set rather than fighting it.

If you want the tags themselves generated and syntax-checked, we built a free hreflang generator and validator. It runs entirely in your browser, needs no account, and outputs HTML tags, an HTTP header or an XML sitemap block. It catches en-UK, case errors, relative URLs, duplicate pairs and a missing x-default. It cannot check return links, because that is a property of your whole site rather than of any tag, and a tool claiming otherwise would be lying to you.

Should you use x-default?

It is optional and worth setting. x-default tells a search engine which page to serve a visitor whose language you do not cover. Usually that is your main page or a language selector. Without it, that visitor gets whichever version the engine guesses, and the guess is often wrong for exactly the people you understand least.

If you have hit an hreflang failure mode that is not on this list, I would genuinely like to hear it.

GTranslate vs WeLocale: Which One Should You Pick in 2026?

Serghei Streltov — Fri, 17 Jul 2026 16:24:22 +0000

If you have looked into translating your website, GTranslate has probably shown up in your search results. It is one of the oldest names in this space, and it works. The question worth asking is not "does it work" but "does it fit how you actually run your site."

Here is an honest look at both, no fluff.

What GTranslate actually is

GTranslate started as a wrapper around Google Translate, and a lot of its DNA is still there. The free version shows a visible "powered by Google Translate" widget and translates on the fly, which is fine for a quick fix but rough on quality: idioms, product names, and anything technical often come out wrong. The paid tiers add proxy-based crawling, so Google can index your translated pages, plus some manual editing tools.

The tradeoff is complexity. Proxy setups mean a second layer sitting between your server and your visitors, which is more to configure and more that can break when you update your site.

What WeLocale does differently

WeLocale skips the proxy entirely. You add one script tag, and the widget scans your live DOM and swaps text in place, no separate translated copy of your site living on someone else's server. Pages stay indexable and cacheable exactly the way they already are, and new content you publish gets picked up automatically because the widget is watching the page, not a snapshot of it.

Translation quality is AI-powered rather than a raw machine-translate widget, so it holds up better on product names, brand voice, and anything domain-specific, and every string can still be edited by hand from the dashboard if something needs a human touch.

Where each one wins

GTranslate wins if: you want the absolute cheapest possible option and you do not care about translation quality, or you already run infrastructure that plays nicely with a reverse-proxy setup.

WeLocale wins if: you want the setup to take minutes instead of a dev sprint, you care about translation quality out of the box, or you are on WordPress and want a plugin that just works without touching server config.

Pricing, roughly

GTranslate's free tier is genuinely free but limited and shows the Google-Translate badge. Its paid plans that unlock SEO-indexable pages and proxy translation start climbing once you need more than a couple of languages.

WeLocale has a free plan for smaller sites, and paid plans scale with word volume rather than punishing you for adding a language. There's no "reset your word count every month and pay again" trap.

The honest bottom line

GTranslate has been around longer and that counts for something if you want a tool with a long track record. But if you want fewer moving parts, translations that read like a person wrote them, and a setup you can finish over coffee, WeLocale is the simpler bet in 2026.

Try WeLocale free at welocale.net.

How to Translate Your Website Without Code (the 2026 Way)

Serghei Streltov — Fri, 10 Jul 2026 17:08:57 +0000

Originally published on the WeLocale blog.

To translate a website without code, add a translation widget that loads from a single snippet: paste one line into your site, choose your languages, and the tool translates your pages automatically with a built-in language switcher. No developer, no duplicate pages to maintain. Here is how it works, step by step.

For years, "let's make the site multilingual" was the project nobody wanted to own. It meant duplicating pages, pulling in a developer, paying an agency, and then maintaining two or three versions of everything forever. So it stayed on the roadmap, quarter after quarter, while a chunk of your visitors quietly clicked away because the site only spoke English.

The good news is that the whole calculation has changed. You can now translate an entire website without touching the code and have it live the same afternoon. Here is how it actually works, and the one part most people get wrong.

You don't translate pages anymore, you translate the site

The old mental model was page by page: copy this page, translate it, publish a /fr/ version, repeat two hundred times. The modern approach throws that out. You add a small snippet to your site once, and a layer sits on top that reads whatever text is on the page, swaps in the right language for each visitor, and remembers their choice. Your original site never changes. You are not maintaining copies, and when you edit a page in English, the translations follow.

In practice it is three steps: paste one line of JavaScript before your closing body tag, let it scan your content, and switch on the languages you want. Most people are live in well under an hour.

The part everyone gets wrong: hreflang

This is where I watch sites quietly lose months of traffic. Translating the words is the easy ninety percent. The other ten percent, telling Google which version to show in which country, is what decides whether your French pages actually rank in France.

That job belongs to hreflang, and the rule that trips everyone up is that the tags have to be reciprocal. Your English page points at the French one, and the French one has to point back, plus an x-default for everyone else. If they only point one way, Google shrugs and ignores them. Each version also needs to point its canonical at itself, not back at your main language. Get this right and your translated pages compete on their own merits. Get it wrong and they are invisible.

A decent no-code tool injects all of this for you. If the one you are looking at does not, treat that as a real mark against it.

Where you should still pay a human

I am not going to pretend machine translation is flawless. For your blog, your product pages, and general marketing copy, it is genuinely good now, good enough to ship today. But I would still put a human on three things: anything legal or compliance-related, your handful of highest-traffic pages, and your taglines, where one slightly-off phrase reads as amateur.

The move most teams settle on is simple: machine-translate everything so you are live this week, then have a native speaker polish the five pages that actually matter. You get ninety-five percent of the upside immediately and fix the last five percent exactly where it counts.

So, should you do it?

If you have been sitting on "we should really be multilingual," there is no longer a good reason to wait for a big project. One snippet, correct hreflang, and a human pass on your top pages. That is the entire thing.

And if you want the fastest version of it, that is exactly what we built WeLocale to do: one snippet, 50+ languages, hreflang handled, and your translations stay yours. It is free to start.

FAQ

Can I translate my website without a developer? Yes. Snippet-based tools translate your site automatically after you paste one line of code, with no developer and no duplicate pages to maintain.

Is no-code website translation good for SEO? It can be, if the tool adds hreflang tags and serves each language on its own URL. Without those, search engines may not index your translated pages, so check that the tool handles them.

How long does it take? Minutes for the initial setup. You paste the snippet, pick your languages, and pages translate automatically. You can then edit any translation by hand.

Is machine translation accurate enough? Modern AI translation is a strong starting point for most marketing and informational pages. For legal or high-stakes content, have a native speaker review your top pages.

Does it work on WordPress? Yes, there's a free WeLocale plugin for WordPress. The same snippet works anywhere you can add a line of code to a site; official app-store integrations for other platforms are on the roadmap, not live yet.

How Much Does It Cost to Translate a Website in 2026?

Serghei Streltov — Fri, 10 Jul 2026 17:07:43 +0000

Originally published on the WeLocale blog.

Short answer: translating a website in 2026 ranges from almost free, if you do machine translation yourself, to several thousand dollars for a full professional agency project. Most small and mid-size sites land in between. Professional human translation runs about $0.08 to $0.30 per word, agencies usually add project minimums of $50 to $95, and subscription translation tools start around $15 per month. Your final cost comes down to three things: how many words you have, how many languages you need, and how much human quality you want.

The four ways to translate a website (and what each costs)

1. Professional human translation

Freelancers or an agency translate every page by hand.

Rate: roughly $0.08 to $0.30 per word for common language pairs, higher for rare languages or technical content.
Per page: about $25 to $100.
Add 30 to 50 percent if you want a second linguist to edit and proofread (the standard translate, edit, proofread workflow).
Most agencies charge a project minimum of $50 to $95.

Example: a 10,000-word marketing site into one language costs roughly $800 to $3,000, and that is per language. Best quality, highest price, slowest turnaround, and you pay again every time your content changes.

2. Do-it-yourself machine translation

Run your content through a machine translation API and paste the results back in.

Cost: very low on paper, sometimes free for small volumes.
The catch: you need a developer to wire it up, you get no editing workflow, no language switcher, and no SEO tags, and nothing updates when your site changes. The cheapest option on paper often costs the most in developer hours and lost quality.

3. Website translation tools (subscription widgets)

A tool translates your site automatically, gives you a language switcher, and lets you edit the results.

Cost: subscriptions typically start around $15 per month.
Watch the pricing model. Several tools, Weglot for example, bill on both words translated and page views served, so the monthly cost climbs as your traffic grows. A busy site can jump to 200 to 400 dollars per month once it outgrows the entry tier.
This is the practical middle ground: fast, no developer, AI-powered translations you can refine by hand.

4. Build it in-house

A developer adds internationalization libraries and manages translation files by hand.

Cost: no software fee, but heavy developer time up front and ongoing, and you still pay for the actual translations.
Only worth it for large teams with engineers to spare.

The hidden costs most people forget

Maintenance: every time you edit a page, that text needs translating again. With manual and agency work, you pay again each time.
SEO: to rank in other languages you need hreflang tags, one clean URL per language, and a switcher. Skip this and your translated pages never get found.
Developer time: wiring up an API or maintaining translation files is real engineering cost, even when the translation itself looks cheap.
Per-pageview pricing: tools that meter page views can turn a small bill into a large one as you grow, and make budgeting hard to predict.

How to estimate your own cost

Count your words. Most sites have 5,000 to 30,000.
Multiply by the per-word rate for human translation, or check the word allowance of a tool.
Multiply by the number of languages.
Add maintenance based on how often your content changes.

A typical small business site, around 10,000 words and 2 languages, costs roughly $1,600 to $6,000 done by humans, or from $15 per month with a translation tool.

Where WeLocale fits

WeLocale translates any website at runtime from a single snippet, with no code changes and no developer. Pricing is a flat monthly plan from $15, not a per-pageview meter, so your bill does not balloon when traffic grows. Translations are AI-powered and fully editable, your word allowance never resets each month, and your translations stay yours even if you cancel. You also get a built-in language switcher and SEO hreflang tags on paid plans, so your translated pages can actually rank.

FAQ

Is machine translation good enough? For most marketing and informational pages, modern AI translation is a strong starting point. For legal, medical, or other high-stakes content, have a native speaker review your top pages.

How much does it cost to translate a small website? Done by professional humans, a 10,000-word site into one language is roughly $800 to $3,000. With a subscription tool, it starts around $15 per month.

Why does my translation bill keep rising? Many tools charge by page views or monthly translation requests, so traffic growth pushes the cost up. Flat-rate plans avoid that surprise.

Do I need a developer? Not with a snippet-based tool. Do-it-yourself machine translation and in-house internationalization both require engineering time.

WPML vs Polylang vs WeLocale: Which WordPress Translation Plugin Is Right for You?

Serghei Streltov — Fri, 26 Jun 2026 13:20:34 +0000

If you've ever searched "WordPress translation plugin," you've hit the same three names over and over: WPML, Polylang, and (increasingly) WeLocale. They all translate your WordPress site. The similarities end there.

This guide breaks down what each tool actually does, what it costs, and who it's best suited for.

This article was originally published on the WeLocale blog.

The quick version

	WPML	Polylang	WeLocale
Price	$39-$199/yr	Free / $99/yr Pro	Free plan + paid from $19/mo
Setup time	2-4 hours	1-2 hours	Under 30 min
Translation method	Manual + machine	Manual + machine	AI-powered automatic
SEO (hreflang, URLs)	Full	Full	Auto on Pro+
Developer needed?	Sometimes	Rarely	No
Best for	Complex sites, agencies	Budget-conscious, manual control	Fast launch, no-code sites

WPML

WPML has been around since 2008. It's the most feature-complete WordPress multilingual plugin. You can translate everything: pages, posts, custom post types, menus, widgets, theme strings, plugin strings.

What's good: Mature and battle-tested. Deep WooCommerce integration. Professional translation management. Works with Yoast and RankMath.

What's frustrating: Heavy interface. Pricing stacks up ($99/yr for most sites). Historically slows down admin on large sites.

Best for: Established sites with complex content, WooCommerce stores, agencies.

Polylang

Polylang is the most popular free WordPress multilingual plugin. The free version covers the basics well: separate URLs per language (/fr/, /de/), hreflang tags, translated slugs, and Yoast/RankMath compatibility.

What's good: Free version is genuinely useful. Lighter than WPML. Clean interface. Active community.

What's frustrating: Machine translation requires Pro ($99/yr). WooCommerce support is a separate add-on ($50/yr). Manual translation takes time.

Best for: Sites wanting multilingual SEO without paying for WPML. Teams who prefer manual translation.

WeLocale

WeLocale works differently. Instead of creating duplicate pages in WordPress, it translates your site's content in real time via a small JavaScript widget. Install the plugin from WordPress.org, connect your site, and content is automatically translated — no duplicate pages, no manual entry.

What's good: Setup under 30 minutes. No duplicate page management. Automatic translations that update when content changes. Handles menus, buttons, dynamic content. Free plugin on WordPress.org, first 3,000 words free.

What's worth knowing: Word count limits apply per plan. SEO hreflang tags are automatic on Pro and Scale plans.

Best for: Small businesses, bloggers, no-code site owners who want to go multilingual fast.

How to choose

Go with WPML if you have a large WooCommerce catalog, need translation management workflows, or you're an agency.

Go with Polylang if you want proper multilingual URL structure for free and are comfortable translating manually.

Go with WeLocale if you want to be live in multiple languages today without managing duplicate page trees.

Read the full comparison with pricing details and SEO breakdown on the WeLocale blog.

How to Translate Your WordPress Site into 50+ Languages (Free Plugin, No Code)

Serghei Streltov — Fri, 19 Jun 2026 11:49:34 +0000

Most WordPress translation solutions ask you to restructure your site. WPML adds a language switcher and creates separate post copies for each language. Polylang does the same. Both require you to manage translations page by page, keep multiple versions of every post in sync, and deal with plugin conflicts when your theme or other plugins update.

The WeLocale plugin works differently. There is no per-page translation workflow, no duplicate posts, no theme editing. You install the plugin, connect it to your WeLocale account with your app key, and the site is translated at runtime, in the visitor's browser, without touching your database.

Here is how to do it.

Step 1: Install the WeLocale plugin

In your WordPress admin, go to Plugins > Add New Plugin.
Search for WeLocale.
Click Install Now, then Activate.

The plugin is free and listed at wordpress.org/plugins/welocale.

Step 2: Get your app key

If you do not have a WeLocale account yet, sign up for free at welocale.net. The free plan includes 3,000 words and 1 language, enough to see it working on your real site.

Once you are in, go to Website > Widget in the WeLocale dashboard. Copy your Public App Key (a UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Step 3: Connect the plugin

In WordPress admin, go to Settings > WeLocale.
Paste your App Key into the field.
Make sure your domain is listed under Allowed Domains in your WeLocale dashboard (Website > Settings > Allowed Domains).
Save.

Reload your site's front end. The language switcher appears automatically, no shortcode, no widget placement needed.

How it works

The plugin loads a small JavaScript widget on your front end. When a visitor selects a language, the widget retrieves stored translations and replaces text in place. Your page structure, theme, and all other plugins stay exactly as they are. Nothing is changed server-side.

Translations are stored permanently in your WeLocale account. Words are never reset at month end, once a string is translated, it stays translated.

What about SEO?

On Pro and Scale plans, WeLocale automatically injects hreflang tags in the page <head> for every language you have enabled. This tells Google which version of a page to serve to which audience, with no duplicate content penalties.

On the free and Starter plans, translations are live for visitors but hreflang tags are not added. For a small site or a test this is fine. For production multilingual SEO, upgrade to Pro.

FAQ

Will this conflict with WPML or Polylang? No. WeLocale works on the rendered front end and does not touch WordPress's content or translation data. You can run both, though there is no reason to once WeLocale is set up.

Where do I manage translations? In your WeLocale dashboard at welocale.net. You can review and edit every translation, accept or revert changes, and see which strings are pending.

Do I need to update the plugin when the widget changes? No. The widget JS auto-updates without requiring a plugin release. Plugin updates are only needed when the settings screen or integration logic changes.

Is there a free plan? Yes. 3,000 words and 1 target language, no credit card required. Start free at welocale.net.

Does it work with WooCommerce? Yes. The widget translates everything rendered on the front end, including product names, descriptions, cart text, and checkout labels.

More platforms

The WeLocale JS widget works on any website. On Webflow, add it in Site Settings > Custom Code. On Wix, use the Custom Code section in Settings. On any custom HTML site, paste the snippet from your dashboard into the <head>. A Shopify app is coming soon.

Get started

Install the free plugin from wordpress.org/plugins/welocale and sign up free at welocale.net. The free plan covers your first 3,000 words, enough to translate your most important pages and see the result live before committing to anything.