Read more

Bilingual SEO with Next.js 16 and next-intl

blog.posts.bilingualSeo.minRead min read

When we decided to ship Lumina's corporate site in Turkish and English, we thought "just translate everything". In practice, keeping a bilingual Next.js 16 site healthy on the SEO side is a chain of routing, metadata, sitemap, canonical and UX decisions. This post sketches the system we landed on.

1. Routing: as-needed prefix

next-intl supports three prefix modes: always,as-needed and never. We picked Turkish as our default (primary market) and switched to as-needed. Result:

  • / and /hakkimizda are Turkish
  • /en and /en/hakkimizda are English
  • Slugs are identical across locales (/hakkimizda)

We did not localise the slugs (e.g. /en/about). next-intl supports it via pathnames but it adds complexity: the same content has two canonical paths to manage. For v1 we kept it simple; we can revisit this later.

2. Hreflang: telling search engines about language families

Every page should carry hreflang tags for both languages:

<link rel="alternate" hreflang="tr" href="/hakkimizda" />
<link rel="alternate" hreflang="en" href="/en/hakkimizda" />
<link rel="alternate" hreflang="x-default" href="/hakkimizda" />

Next.js 16's metadata API makes this manageable through alternates.languages. We wrap it in a helper used consistently across pages.

3. Sitemap: dynamic and language-aware

Our app/sitemap.ts emits two entries per route — TR and EN — otherwise Google treats English pages as invisible:

for (const route of ROUTES) {
  for (const locale of locales) {
    entries.push({
      url: `${siteUrl}${getPath(route, locale)}`,
      lastModified: new Date(),
      alternates: {
        languages: { tr: `...`, en: `...` }
      }
    });
  }
}

4. Locale switcher UX

When the user switches languages, they should land on the equivalent page in the other language — not the homepage. We use usePathname to capture the current path and router.replace(pathname, { locale })to swap. next-intl's typed navigation helpers make this type-safe.

5. Apple-grade content standard

SEO is not just a technical discipline. The reason we got an Apple Developer Program enrollment rejection was "minimal content" — meaning page count alone is not enough; what each page contains matters. Lumina ships 21 unique routes × 2 languages = 42 pages. Each one carries the kind of content one expects from an operating company:

  • Company registry (registration, tax, address) visible in the footer
  • Engineering blog with real technical content
  • Legal pages with real text, not generic templates
  • A working contact form (Apple does test it!)

6. Wiring Lighthouse into the build pipeline

Instead of running Lighthouse on every route after each build, we pick the critical pages (home, about, products) and gate every PR on them through Lighthouse CI. Performance budget:

  • LCP < 2.0s on mobile 4G
  • CLS < 0.05
  • INP < 150ms
  • Initial JS < 200KB

Conclusion

Multilingual SEO is a problem largely solved by the joint system of Next.js 16, next-intl and Vercel. The interesting bit is that UX of language switching and content quality matter as much as the technical plumbing. Apple's "minimal content" rejection drove this home for us: search engines and humans both want to see a site that is genuinely full.