DEV Community: Léo Guillaume (Dibodev)

Auto-translating a static Nuxt blog into FR/EN/ES: hreflang, sitemap, and the duplicate-canonical trap

Léo Guillaume (Dibodev) — Fri, 04 Sep 2026 01:14:24 +0000

I run my freelance site as a fully static Nuxt (SSG) blog. Content is authored in French in a headless CMS, and I wanted English and Spanish versions — without hand-translating every post, and without maintaining three copies in the CMS.

Here's the setup I landed on, and the one SEO gotcha nobody warns you about.

The constraint: static, one source of truth

Nuxt in SSG mode (everything prerendered to static files).
Articles authored in French only, in the CMS.
I didn't want a second/third CMS locale to keep in sync. So: French is the single source of truth; EN/ES are generated from it.

The translation pipeline

A small admin page has a single "Translate EN + ES" button. When I press it:

It sends the French article to an LLM.
It gets back the translated title, excerpt, metaTitle, metaDescription, tags and rich-text content.
It writes them to JSON files committed to the repo, keyed by the French slug:

// content/translations/articles.es.json
{
  "blog/mon-article-en-francais": {
    "title": "Mi artículo en español",
    "excerpt": "…",
    "metaTitle": "…",
    "metaDescription": "…",
    "tags": ["…"],
    "content": { "type": "doc", "content": [ /* rich text */ ] }
  }
}

Because the site is static, saving a translation pushes to GitHub, which triggers a rebuild. No runtime translation, no per-request cost, nothing to break in production.

Rendering: overlay the translation at build time

The article page fetches the French story from the CMS, then overlays the JSON translation when the current locale is en or es:

let article = mapStory(storyResponse.story) // FR from CMS

if (locale.value === 'en' || locale.value === 'es') {
  const translations = await $fetch(`/api/translations/articles/${locale.value}`)
  const t = translations[`blog/${slug}`]
  if (t) article = { ...article, ...t } // title, excerpt, content, meta, tags
}

One template, one data path, three languages.

Routing: prefix_except_default

With @nuxtjs/i18n and strategy: 'prefix_except_default', the default locale stays clean and the others get a prefix:

FR → /blog/my-slug
EN → /en/blog/my-slug
ES → /es/blog/my-slug

One deliberate choice: for articles I keep the same slug across locales — only the content is translated. My category pages do translate the slug (via customRoutes: 'meta' and a per-locale slug map), but for blog posts a shared slug is simpler and works fine.

SEO plumbing: self-canonical + hreflang + sitemap

Each locale canonicalises to itself, not to the French version:

useHead(() => ({
  link: [{ rel: 'canonical', href: `${site}${localePath(article.route)}` }],
}))

A global composable emits the full reciprocal hreflang cluster (fr-FR, en-US, es-ES, plus x-default → FR), and the sitemap is an index with one sub-sitemap per locale, each entry carrying <xhtml:link rel="alternate" hreflang="…">.

I checked the rendered <head> on a live ES page and it was textbook-correct: lang="es", self-canonical to the /es/ URL, and all four hreflang links present.

The gotcha nobody warns you about

Here's the part I wish I'd known earlier. Even with a correct self-canonical, a complete reciprocal hreflang cluster, and every URL in the sitemap with hreflang, Google Search Console still flagged a bunch of my ES/EN pages as:

Duplicate, Google chose a different canonical than the user.

In other words, Google overrode my (correct) canonical and consolidated the translated page into the French original.

Why does this happen? On low-authority sites with machine-translated content, Google often decides the translation doesn't add enough unique value and folds it into the source URL — regardless of what your canonical says. Your canonical is a hint, not a command.

What actually moves the needle (and what doesn't):

❌ A translated slug doesn't fix it. Google consolidates on content and signals, not on the URL string.
✅ Real signals do: internal links pointing to the /en/ and /es/ versions, overall domain authority, and translations that are genuinely useful rather than thin.
✅ Time. It's frequently transient and clears as Google recrawls and trusts the domain more.

Takeaway: technically-perfect hreflang and canonical are necessary but not sufficient. On a young, low-authority multilingual site, Google will keep consolidating your translated pages until you earn its trust — and "Duplicate, Google chose a different canonical" is a neutral status (your original is still indexed), not a penalty.

This setup powers the blog on my site, dibodev.fr — I'm a freelance web developer near Rennes (France) building custom business tools, SaaS and internal apps for small companies. Happy to dig into any part of the pipeline in the comments.

One Vue app, three homes: desktop with Tauri, Android with Capacitor, and the web

Léo Guillaume (Dibodev) — Tue, 18 Aug 2026 23:23:27 +0000

I wanted a Reddit client that lived on my desktop and my phone — without maintaining two separate apps. So I built one Vue app and gave it three homes: Tauri (Rust) wraps it as a desktop app for Windows/macOS/Linux, Capacitor wraps it for Android, and it still runs as a plain web app. One UI, one set of Reddit API calls, one OAuth flow — three targets.

It works. But "just wrap your web app" hides a few things. Here's the reality.

The shape

A single Vue.js frontend: the whole UI, the Reddit API calls, the OAuth.
Tauri for desktop — the webview is the OS's native one, the backend is Rust.
Capacitor for Android — desktop got Tauri, Android got Capacitor. Use the wrapper that's mature for each target instead of forcing one tool everywhere.
Plain web for anyone who just wants a URL.

Gotcha 1: you can't cross-compile

You cannot build a Windows .msi on your Mac. Tauri leans on each platform's native toolchain:

.msi / .exe → built on Windows
.dmg / .app → built on macOS
.deb / .AppImage → built on Linux

"Ship for all platforms" really means a CI matrix with one runner per OS. Plan for it early — it shapes your whole release pipeline.

Gotcha 2: WebView2 on older Windows

Tauri doesn't ship a browser engine; it uses the system webview. Windows 11 has WebView2; Windows 7–10 might not — and a missing webview means users open the app to a blank white window. Bundle the WebView2 bootstrapper in your installer so it self-installs. Tiny detail, terrible first impression if you miss it.

Gotcha 3: OAuth redirect is the fiddly part

In a browser, OAuth is easy: Reddit redirects to your callback URL, you read the code, done. In a packaged app there's no web server at that URL. So you register a custom scheme / deep link, let the OS hand the redirect back to the app, and pull the code out of the incoming URL — on desktop and Android, each with its own quirks. Easily the most time-consuming part, and the bit tutorials skip.

Gotcha 4: a default Rust release binary is chunky

A handful of Cargo.toml flags make a real dent:

[profile.release]
panic = "abort"      # drop the unwinding machinery
codegen-units = 1    # compile as one unit so the optimizer can do more
lto = true           # link-time optimization
opt-level = "s"      # optimize for size
strip = true         # strip symbols from the binary

Free size win, no code changes.

Was it worth it?

Yes. One Vue codebase, native apps on desktop and Android, plus a web version — without three projects to keep in sync. If you're a web dev eyeing desktop/mobile, Vue + Tauri + Capacitor is a very reasonable way in — just budget time for the packaging and OAuth reality, not the happy-path demo.

I do this kind of cross-platform / custom-tooling work as a freelance dev at dibodev.fr. Happy to get into the OAuth deep-linking or the CI matrix in the comments.

My static Nuxt blog publishes itself: drafts, scheduled "drip", and auto-rebuilds

Léo Guillaume (Dibodev) — Tue, 18 Aug 2026 22:45:55 +0000

I run my freelance site as a fully static (SSG) Nuxt site. It's fast, cheap to host, and boring in the good way. But static sites are genuinely bad at one thing: publishing an article next Tuesday at 9am. There's no server rendering each request, so "schedule this post" doesn't exist — something has to rebuild the site at the right moment.

I also write in bursts. Some evenings I'll draft two or three articles at once, and I don't want them all going live the same day. So I bolted a small publishing engine onto my existing stack: drafts, a scheduled queue (a "drip"), and automatic rebuilds. Here's how the pieces fit.

The stack

Nuxt 4, prerendered (SSG) for every public page
Storyblok as the headless CMS — the source of truth for content
A Nitro server (the same Nuxt app) on a small VPS under PM2 — the always-on part
GitHub Actions for the deploy/rebuild

The whole thing rests on one realization: on an SSG site, "publish" is two actions, not one — (1) put the content in the CMS, and (2) rebuild the static site so it actually shows up. Scheduling is just doing both later, automatically.

1. Drafts: write now, decide later

The dashboard has a markdown editor. Drafts are saved server-side (Nitro's storage layer), each with a status (draft / scheduled / published) and a publish date. Nothing touches the live site yet — a draft is just a row waiting for its moment.

2. The queue and the "drip"

The fun part. A Nitro scheduled task runs every hour and asks one question: is anything due?

// nuxt.config.ts
export default defineNuxtConfig({
  nitro: {
    experimental: { tasks: true },
    scheduledTasks: {
      '5 * * * *': ['articles:process-queue'], // every hour, at :05
    },
  },
})

// server/tasks/articles/process-queue.ts
export default defineTask({
  meta: { name: 'articles:process-queue' },
  async run() {
    const due = await getDueScheduledArticles() // publishDate <= now
    if (!due.length) return { result: 'nothing due' }

    for (const article of due) {
      await publishToStoryblok(article) // markdown -> richtext -> CMS
    }
    await triggerSiteRebuild() // ONE rebuild for the whole batch
    return { result: `published ${due.length}` }
  },
})

That's the entire scheduler. No queue service, no cron box, no extra infra — just a task the Nitro server already knows how to run.

3. Markdown → CMS → rebuild

When a post is due, it's converted from markdown to Storyblok's richtext format, pushed to the CMS, and then — the non-negotiable step on a static site — the site is rebuilt. No rebuild, no article. I trigger it with a workflow_dispatch call to my deploy workflow:

async function triggerSiteRebuild() {
  await $fetch(
    'https://api.github.com/repos/<owner>/<repo>/actions/workflows/deploy.yml/dispatches',
    {
      method: 'POST',
      headers: {
        Authorization: `Bearer ${process.env.REPO_ACCESS_TOKEN}`, // needs `actions: write`
        Accept: 'application/vnd.github+json',
      },
      body: { ref: 'main' },
    },
  )
}

Three gotchas I hit

There's still a server. The scheduled task only fires if something is actually running. It's easy to forget an SSG site has no always-on backend by default — the Nitro server under PM2 exists purely so the scheduler (and the admin) stay alive.
One rebuild per batch, not per article. If three posts are due in the same run, publish all three then rebuild once. Otherwise you kick off three deploys back to back for nothing.
Timezones. "9am" means nothing until you pin the timezone. Ask me how I know.

The payoff

Now I can draft on a Sunday, spread posts across the next two weeks, and close the laptop. They go live on their own, the site rebuilds itself, and I stop babysitting a "publish" button.

It powers the blog on my freelance site, dibodev.fr — building this kind of custom tooling (and business apps / SaaS) for small companies is basically my day job.

Happy to dig into the Nitro task or the rebuild trigger in the comments.