Next.js i18n and SEO: hreflang, locales, and metadata

Multilingual sites need more than translated strings. Search engines must understand which URL targets which language or region, how pages relate to each other, and which version is canonical when similar content exists in multiple locales.

A common pattern for Next.js portfolios is locale-prefixed routes such as /en/blog and /tr/blog. This keeps URLs readable, makes analytics segmentation easy, and maps cleanly to per-locale metadata generation.

Decide early whether Turkish and English posts are direct translations with paired URLs or independent articles. Paired content should use consistent translation keys and alternate links; independent content should not claim false equivalences.

Google’s localized versions documentation recommends indicating language and regional URLs so search engines can surface the correct version to users. In Next.js Metadata API, alternates.languages is the structured place to declare these relationships.

Each localized page should reference its equivalents, including a self-referencing alternate. For a bilingual portfolio, English and Turkish homepages, blog indexes, and paired articles should all expose consistent reciprocal links.

Keep slugs localized when it helps readability and keywords, but keep the translation mapping in one source of truth so sitemaps, metadata, and internal links do not drift apart during refactors.

Titles and meta descriptions must match the visible language of the page. A Turkish title with an English description confuses users and weakens click-through rates from search results.

Use generateMetadata on locale-aware routes to produce title, description, canonical, Open Graph locale, and alternates from the same content record. Blog posts should pull keywords and descriptions from the localized post object, not from a shared English-only constant.

Remember character limits: aim for roughly 50–60 characters in titles and about 150–160 characters in meta descriptions so snippets do not truncate awkwardly in search results.

Localized pages are not duplicates by default, but they can look like duplicates if canonical tags are wrong or if both locales compete for the same query without clear targeting.

Each locale URL should canonicalize to itself. Include localized URLs in the sitemap with alternate language entries when supported. Internal navigation should make it easy for users—and crawlers—to move between languages intentionally.

Avoid machine-translated thin pages. High-quality localized copy, local examples, and locale-specific slugs perform better than automatic translation with no editorial review.

Centralize locale config, translation keys, and slug maps. Generate static params for every localized blog route. Keep robots and sitemap routes in sync with the route tree.

Test social previews per locale. Open Graph locale values should match the page language. Structured data inLanguage fields should follow the same rule.

International SEO is maintainability work. When metadata, sitemaps, hreflang, and content models share one source of truth, adding a third language later becomes a content task instead of a routing rewrite.