Several things were wrong. Two of them were pure internationalization bugs that we suspect are very common, so here they are in detail.

Mistake 1: redirecting locale-less URLs with a 302

Like most multilingual sites, we redirect a request without a locale (/, /tools/numbers) to the right version based on Accept-Language. Our middleware did this:

// before
return NextResponse.redirect(new URL(`/${locale}${pathname}`, request.url));

NextResponse.redirect defaults to a temporary redirect. To Google, a temporary redirect says: "the real page is the original URL; this is just for now." So Google kept treating / as canonical and was reluctant to index /en and /ru as separate pages.

The fix is small, with one important detail:

const locale = getPreferredLocale(request);
const target = new URL(pathname === '/' ? `/${locale}` : `/${locale}${pathname}`, request.url);
target.search = request.nextUrl.search;

const response = NextResponse.redirect(target, { status: 308 });
response.headers.set('Vary', 'Accept-Language');
return response;

• 308 is the permanent equivalent of 307 (it preserves the method). Search engines treat it like a 301.
• Vary: Accept-Language matters because the response depends on a request header. Without it, a CDN or proxy may cache "redirect to /en" and serve it to Russian speakers too.

A few days after deploying, URL Inspection showed /ru and /ru/tools/numbers indexed and selected as their own canonicals.

Mistake 2: a language switcher that generated 404s

Search Console reported 96 "Not found" errors. Nearly all of them were blog posts in the wrong locale: /en/blog/kulinarnyj-ivrit, /ru/blog/binyanim-complete-guide.

The cause was the language switcher:

// before
const href = pathname.replace(`/${locale}/`, `/${nextLocale}/`);

That works for pages whose path is the same in both languages (/en/lessons ↔ /ru/lessons). It breaks for content with localized slugs. Our Russian alphabet guide is alfavit-ivrita-polnyy-gid and the English one is hebrew-alphabet-guide: a translation pair, not one URL. Swapping the prefix produced a page that doesn't exist, and Googlebot happily followed every one of those links.

The fix has two parts:

1. The switcher looks up the translation in a map of translation pairs (the same map that generates hreflang). If a post has no translation, it links to the blog index of the other locale instead of guessing.
2. The middleware redirects old wrong-locale URLs to the translation (or the index), so links already in search results stop producing 404s.

// sketch of the switcher logic
function switchHref(pathname: string, from: Locale, to: Locale) {
  const m = pathname.match(/^\/(en|ru)\/blog\/([^/]+)$/);
  if (m) {
    const translated = getTranslationSlug(m[2], from, to); // from the hreflang map
    return translated ? `/${to}/blog/${translated}` : `/${to}/blog`;
  }
  return pathname.replace(`/${from}`, `/${to}`);
}

A quick checklist for multilingual Next.js sites

1. Redirects from locale-less URLs: 301/308 only, with Vary: Accept-Language.
2. If any content has localized slugs, your language switcher must know the translation pairs.
3. Reuse one source of truth for translation pairs: hreflang, the switcher and redirects should all read from it.
4. Run your sitemap through the URL Inspection API at least once. You won't notice "55% indexed" by browsing your own site.

These weren't our only problems: orphaned blog posts and client-rendered dictionary pages mattered too. But the two i18n bugs were the cheapest to fix and the easiest to miss.

If you want to see the result, HebrewGlot is live. Questions about the implementation are welcome in the comments.