DEV Community: Léo Guillaume (Dibodev)

My French homepage showed up in English on Google. A default Nuxt i18n option was the reason.

Léo Guillaume (Dibodev) — Sun, 27 Sep 2026 17:10:00 +0000

This week I searched for my own brand on Google, and my French homepage came up with an English title and a "Translate this page" link under it.

My site is French first. The homepage at / serves French, the English version lives at /en, and the Spanish one at /es. So why was Google showing the English page for the French URL?

The site is a static Nuxt 4 build (SSG) with @nuxtjs/i18n and the prefix_except_default strategy. I started with the boring checks.

Everything looked right

The raw HTML of / was French:

curl -s https://dibodev.fr/ | grep -o 'lang="[a-z]*"\|<title>[^<]*</title>' | head -2
# lang="fr"
# <title>Dibodev — Développeur Web Freelance à Rennes</title>

The canonical pointed to /, and the hreflang tags were correct: fr-FR → /, en-US → /en, es-ES → /es, x-default → /. Even with a Googlebot user agent, the server returned the same French page with a 200.

So the server side was fine. The problem had to be in the browser.

Reproducing it with a browser in English

Google doesn't just download your HTML: it renders the page in a headless Chrome and executes your JavaScript. A crawler doesn't tell you it speaks French. So I opened the homepage in Playwright with an English browser locale:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    for locale in ["fr-FR", "en-US"]:
        page = browser.new_context(locale=locale).new_page()
        page.goto("https://dibodev.fr/", wait_until="networkidle")
        print(locale, "->", page.url, "|", page.title())
    browser.close()

fr-FR -> https://dibodev.fr/ | Dibodev — Développeur Web Freelance à Rennes
en-US -> https://dibodev.fr/en | Dibodev — Freelance Web Developer in Rennes

There it was. Any browser set to English landed on /, got the French HTML, and was redirected to /en right after hydration. Same result with a Googlebot user agent. As far as the renderer was concerned, the content of / was the English page.

The culprit: a default option

I never asked for a language redirect. But @nuxtjs/i18n has a detectBrowserLanguage option, and it is enabled by default. By default it only acts on the root path, and it remembers the choice in a cookie. For real visitors, that's a nice touch: an English speaker lands on the English site.

On a prerendered site, though, the redirect can't happen on the server: the HTML is already generated. It happens in the browser, once the app is running. And a headless browser with an English locale and no cookie gets the redirect every single time.

My config never mentioned the option:

// nuxt.config.ts (before, simplified)
i18n: {
  locales: [
    { code: 'fr', language: 'fr-FR', file: 'fr.json' },
    { code: 'en', language: 'en-US', file: 'en.json' },
    { code: 'es', language: 'es-ES', file: 'es.json' },
  ],
  defaultLocale: 'fr',
  strategy: 'prefix_except_default',
},

The fix: one line

// nuxt.config.ts (after)
i18n: {
  // ...same as before
  strategy: 'prefix_except_default',
  // No redirect to the browser language: crawlers render in English and were sent from / to /en.
  detectBrowserLanguage: false,
},

Visitors can still switch languages with the selector, and search engines already know about every version through hreflang. That's also what Google recommends: don't redirect users to a language version based on their browser, link the versions and let people choose.

After deploying, the same Playwright script gives:

fr-FR -> https://dibodev.fr/ | Dibodev — Développeur Web Freelance à Rennes
en-US -> https://dibodev.fr/ | Dibodev — Développeur Web Freelance à Rennes

Why I care: AI search too

I noticed this because I'm working on how my site shows up in AI answers (ChatGPT, Copilot, Perplexity, Google's AI mode). Copilot and ChatGPT lean on Bing's index, and Bing renders pages with a browser too. A homepage that "becomes English" when rendered is exactly the kind of mixed signal that makes a small French business harder to recommend for French queries.

It's the second rendering trap I found on this site in two days. The first one: some project descriptions were rendered client-side, and AI crawlers like GPTBot or PerplexityBot don't run JavaScript at all, so for them that text simply didn't exist.

Takeaways

@nuxtjs/i18n enables detectBrowserLanguage by default. On a static or SEO-critical site, decide explicitly whether you want it.
Test your pages with a browser in another language, not just with curl: redirects after hydration don't show up in the raw HTML.
Crawlers render your site without your cookies and often without your language. Check what they get, not what you get.

I'm asking Google to recrawl the homepage, and I'll update this post when the French title is back in the results.

I'm a freelance developer in Rennes, France, building custom business tools and websites for small businesses. The site this happened on, and more write-ups like this one: dibodev.fr.

My Nuxt pages were prerendered. Why were they still calling the CMS in the browser?

Léo Guillaume (Dibodev) — Sat, 26 Sep 2026 11:47:17 +0000

Last week, Google Search Console flagged three of my five newest blog posts: "Duplicate, Google chose different canonical than user". That happens. What doesn't usually happen is Google picking the same canonical for all three: an older, unrelated post. A post about B2B software pricing, one about time tracking and one about online booking for driving schools, all folded into an article about small businesses in Rennes.

Three different topics collapsing into one URL doesn't look like "similar content". It looks like Google saw the same page three times.

My site is a static Nuxt 4 build (SSG) with Storyblok as the CMS. So I started with the boring checks:

Each URL returns a 200 with its own <title>, <h1>, canonical and hreflang tags.
The static HTML contains the full article.
Search Console's "Test live URL" renders every article correctly.

All fine. Then I opened the Network tab on one of those prerendered articles.

Two CMS calls on every page view

The article was already in the HTML, yet the browser called the Storyblok API twice on every visit:

GET https://api.storyblok.com/v2/cdn/spaces/me?token=…
GET https://api.storyblok.com/v2/cdn/stories/blog%2F<slug>?token=…&cv=…

The culprit was how the page loaded its data:

<!-- pages/blog/[slug].vue (before, simplified) -->
<script setup lang="ts">
const route = useRoute()
const slug = String(route.params.slug)
const article = ref<Article | null>(null)

try {
  const response = await StoryblokArticleService.getArticleBySlug(slug)
  article.value = mapStoryblokArticle(response.story)
} catch {
  throw createError({ statusCode: 404, statusMessage: 'Article not found', fatal: true })
}
</script>

A top-level await in <script setup> does run during prerendering, so the generated HTML is complete. But <script setup> runs again in the browser when the page hydrates, and nothing tells Nuxt that this data already exists. useAsyncData and useFetch store their result in the page payload; a bare await doesn't. So every visit fetched the story again, plus the spaces/me call my service uses to get Storyblok's cache version.

The catch made it worse. If that browser request failed (rate limit, flaky network, a blocked request), the fatal 404 replaced a perfectly good prerendered article with the error page.

Why it can matter for indexing

Googlebot renders JavaScript. It fetches the HTML, then runs the app like a browser would, often for many URLs in a row. If the CMS call fails while it renders, every affected URL shows the same error screen. The same content on several URLs is exactly what gets clustered as duplicates, with one canonical picked for the whole group.

To be honest, I can't prove that's what happened here. The live test renders fine today, and older posts running the same code did get indexed. But it's a real failure mode, the fix is small, and it removes two API calls from every page view anyway.

The fix: let the payload do its job

<!-- pages/blog/[slug].vue (after, simplified) -->
<script setup lang="ts">
const route = useRoute()
const { locale } = useI18n()
const slug = String(route.params.slug)

const { data: article } = await useAsyncData(
  `blog-article-${locale.value}-${slug}`,
  () => StoryblokArticleService.getLocalizedArticle(slug, locale.value),
)

if (!article.value) {
  throw createError({ statusCode: 404, statusMessage: 'Article not found', fatal: true })
}
</script>

During nuxt generate, the handler runs once and its result is written to /blog/<slug>/_payload.json. When the page hydrates, and when you navigate to a prerendered route client-side, Nuxt reads that payload instead of running the handler again. The service now returns null instead of throwing, and since the browser reads the payload, the 404 only fires when the story really doesn't exist at build time.

Two details that matter:

The key must be identical on the server and in the browser, and unique per page (locale + slug here).
My project pages had the exact same pattern, so they got the same fix.

Result: zero Storyblok calls in the browser, on first load and on internal navigation.

Bonus: each article shipped 217 KB of JSON

While I was in there, I looked at the payload itself. Each article page weighed 217 KB. The "related articles" block was fed by a list of 24 articles, with their full rich-text bodies, just to render three cards.

// composables/useArticlesWithTranslations.ts
function withoutContent(article: Article): Article {
  return { ...article, content: null }
}

const articles = response.stories
  .map(mapStoryblokArticle) // reading time is computed here, from the body
  .map(withoutContent) // cards only need title, excerpt, cover, tags and date

An article payload went from 217 KB to 32 KB, and the blog index from 112 KB to 12 KB.

How to check your own Nuxt site

Open a prerendered page with DevTools, Network tab, filtered on your CMS or API host. On a static page, it should stay empty.
Or paste this in the console:

performance.getEntriesByType('resource')
  .filter((entry) => entry.name.includes('api.storyblok.com')) // your CMS or API host
  .map((entry) => entry.name)

Look for top-level await calls in your pages that aren't wrapped in useAsyncData or useFetch.
Check the size of /<route>/_payload.json: it's downloaded and parsed on every visit.
In Search Console, "Test live URL" then "View tested page" shows what Googlebot actually rendered.

Takeaways

In a prerendered Nuxt app, a bare await in <script setup> runs twice: at build time and in the browser.
Wrap data loading in useAsyncData or useFetch so the payload feeds hydration.
Don't throw a fatal error from code that can run in the browser for data you already prerendered.
Keep list payloads lean: cards don't need article bodies.

I've asked Google to recrawl the three posts. I'll update this article with what Search Console says.

I'm a freelance developer in Rennes, France, building custom business tools and websites for small businesses. The site this happened on, and more write-ups like this one: dibodev.fr.

First-touch attribution on a cookieless static Nuxt site

Léo Guillaume (Dibodev) — Mon, 21 Sep 2026 00:51:39 +0000

I run a small static Nuxt site (SSG + Storyblok) with cookieless analytics: no consent banner, nothing stored server-side about who visits. Great for privacy, but it left me blind on the one question every freelancer or small business asks: where does each lead actually come from?

When someone fills my contact form, I want to know: Google organic? A referral from another site? A specific campaign? Cookieless tools (PostHog in memory mode, Umami) give me aggregate referrers, but they cannot easily tell me which source this specific contact came from. So I added a tiny first-touch attribution layer (no cookies, no library) that tags each contact with where the visitor first landed.

Here is the whole thing.

Capture first-touch once, in localStorage

First-touch means the very first time someone lands on the site, I record the external document.referrer, the landing path, and the UTM params. I store it once, so a visitor who found me via Google last week and returns direct today is still attributed to Google: real first-touch, not last-click.

// app/composables/useLeadSource.ts
const KEY = 'lead_source'

export function useLeadSource() {
  function captureLeadSourceOnce(): void {
    if (typeof window === 'undefined') return
    try {
      if (window.localStorage.getItem(KEY)) return // already captured
      const params = new URLSearchParams(window.location.search)
      const referrer = document.referrer
      const isExternal = referrer !== '' && !referrer.startsWith(window.location.origin)
      window.localStorage.setItem(KEY, JSON.stringify({
        referrer: isExternal ? referrer : null,
        landingPage: window.location.pathname || null,
        utmSource: params.get('utm_source'),
        utmMedium: params.get('utm_medium'),
        utmCampaign: params.get('utm_campaign'),
      }))
    } catch {
      // localStorage throws in private mode or blocked storage: never crash a page over analytics
    }
  }

  function getLeadSource() {
    if (typeof window === 'undefined') return null
    try {
      const raw = window.localStorage.getItem(KEY)
      return raw ? JSON.parse(raw) : null
    } catch {
      return null
    }
  }

  return { captureLeadSourceOnce, getLeadSource }
}

Two details that matter:

The isExternal check. document.referrer on an internal navigation is your own domain. Keep it only when it is a real external referrer; otherwise it is null (direct).
try/catch everywhere. localStorage throws in private mode or when storage is blocked. Analytics should never take down a page.

Fire it once, client-side

// app/plugins/lead-source.client.ts
import { useLeadSource } from '~/composables/useLeadSource'

export default defineNuxtPlugin(() => {
  useLeadSource().captureLeadSourceOnce()
})

It is a .client.ts plugin because localStorage and document.referrer do not exist during SSG prerender. The guard inside the composable makes it idempotent, so SPA navigations and reloads never overwrite the first touch.

Attach it to the contact form

On submit (and even on a contact intent, the first time they blur the email field before they finish), read the stored source and send it with the payload:

const { getLeadSource } = useLeadSource()

const payload = {
  // ...name, email, message...
  source: getLeadSource(), // { referrer, landingPage, utmSource, ... } or null
}

Server-side, turn it into a one-line label for the notification email:

function formatAcquisitionSource(source) {
  if (!source) return ''
  if (source.utmSource) {
    const base = source.utmMedium ? `${source.utmSource} / ${source.utmMedium}` : source.utmSource
    return source.utmCampaign ? `${base} (${source.utmCampaign})` : base
  }
  if (source.referrer) return source.referrer
  return 'Direct / unknown'
}

Now every contact email arrives with Acquisition source: google.com and the landing page, so I know where each lead came from, per lead, without a single cookie.

Why not just read PostHog or GA?

Cookieless analytics already capture $referrer and UTM on events, which is perfect for aggregate dashboards. Two gaps this fills:

Per-lead. Correlating one specific submission to a source in the analytics UI is fiddly. Having it in the email is instant.
First-touch persistence. With in-memory or cookieless persistence, the tool often cannot stitch a returning visitor back to their original source. localStorage does that cheaply for the one thing I care about: leads.

Around 40 lines, zero dependencies, no cookie, no consent banner. For a small business or freelance site, that is the attribution problem solved well enough.

I build these small, boring-but-useful things for small businesses as a freelance dev. More of them (and the site this runs on): dibodev.fr.

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.