Lost in Translation? App Router i18n Setups That Don't Break SEO by Ralph SanchezLost in Translation? App Router i18n Setups That Don't Break SEO by Ralph Sanchez

Lost in Translation? App Router i18n Setups That Don't Break SEO

Ralph Sanchez

Frontend Engineer

Web Developer

SEO Specialist

Next.js

React

Google Analytics

Small SEO Tools

Computer Software

Lost in Translation? App Router i18n Setups That Don't Break SEO

Going global with your Next.js app is thrilling. You're opening doors to millions of new users across different languages and cultures. But here's the thing - internationalization can quickly turn into a nightmare if you don't plan for SEO from day one.

Picture this: You've built an amazing app, translated it into five languages, and launched it worldwide. A month later, your search rankings tank. Google's confused about which version to show users. Your French content appears for Spanish searchers. Duplicate content penalties start rolling in. Not exactly the global success story you imagined, right?

The good news? With the right i18n setup in Next.js App Router, you can avoid these pitfalls entirely. This guide walks you through building a multilingual app that search engines actually understand. And once you've mastered i18n, you might want to spin up a headless store in a day to serve your global customers at lightning speed. For deeper insights into your international audience, consider building real-time analytics dashboards that track user behavior across regions. When you're ready to scale your multilingual platform, you can always hire Next.js developers who specialize in international applications.

Why SEO-Friendly i18n is Non-Negotiable

Let's get one thing straight - if your internationalization strategy doesn't consider SEO, you're basically building a house on sand. Search engines need clear signals about your content's language and target audience. Without these signals, even the best translations won't reach the right users.

Think about it from Google's perspective. The search engine crawls billions of pages daily, trying to match content with user intent. When it encounters your multilingual site without proper i18n setup, it's like reading a book with pages randomly shuffled between languages. Confusing for Google means invisible for users.

The Dangers of Duplicate Content

Here's a scenario that keeps developers up at night. You build a slick app that detects the user's browser language and serves content accordingly. English speakers see English content at /about. French speakers see French content at... /about. Same URL, different content.

Google's crawler visits your site. It sees English content at /about. Later, it crawls again from a different location and sees French content at the same URL. The algorithm scratches its digital head. Is this duplicate content? Which version should it index? Often, it picks one randomly and ignores the others.

The result? Your carefully translated French content never appears in French search results. Your Spanish users keep landing on the English version. Your organic traffic drops like a stone. All because you tried to be too clever with language detection.

Signaling Language and Region to Google

Enter hreflang tags - your multilingual site's best friend. These HTML attributes tell search engines exactly which language and region each page targets. They're like little signs saying "Hey Google, this page is for French speakers in Canada" or "This one's for Spanish speakers everywhere."

Without hreflang tags, search engines play a guessing game. They might look at your content and try to detect the language. They might check your server location. But why leave it to chance? Clear signals mean your French content appears for French searches, your German content for German searches, and so on.

The beauty of hreflang is that it creates connections between translated versions of the same page. Google understands that /en/about and /fr/a-propos are the same content in different languages. It can then serve the right version to the right user based on their language preferences and location.

The User Experience Factor

SEO isn't just about pleasing algorithms - it's about creating great user experiences. And nothing says "professional international site" like clear, language-specific URLs. Compare these two scenarios:

Scenario A: Maria from Spain shares your article with a friend. The URL is yoursite.com/blog/article. Her friend clicks it and lands on the English version because their browser is set to English. Confusion ensues.

Scenario B: Maria shares yoursite.com/es/blog/articulo. Her friend immediately sees it's the Spanish version. They click and get exactly what they expect. Trust builds. Engagement increases.

Clear URL structures also boost your credibility. Users see /de/ in the URL and know they're getting German content. They can bookmark language-specific pages. They can share them on social media without worrying about language confusion. All these positive user signals feed back into better SEO performance.

The Best Practice: Locale in the URL Path

After years of experimentation, the web development community has reached a consensus. For most applications, especially those built with Next.js, putting the locale in the URL path is the way to go. It's clean, it's clear, and it just works.

Why Path-Based Routing Wins

You've got three main options for structuring multilingual URLs. You could use different domains (example.fr, example.de). You could use subdomains (fr.example.com, de.example.com). Or you could use path segments (example.com/fr, example.com/de).

Different domains sound professional but they're a pain to manage. You need to buy and maintain multiple domains. SSL certificates multiply. Cookie sharing becomes complex. And users might not trust that example.de is really your site.

Subdomains are better but still tricky. They can complicate your hosting setup. Some CDNs charge extra for multiple subdomains. And from an SEO perspective, Google sometimes treats subdomains as separate sites, diluting your domain authority.

Path-based routing? Chef's kiss. One domain to rule them all. Simple SSL setup. Easy cookie sharing. Clear URL structure. And Next.js App Router makes it incredibly straightforward to implement. Your domain authority stays consolidated, and users always know they're on your official site.

Introducing the `[locale]` Dynamic Segment

The magic of Next.js App Router i18n starts with a simple folder structure. Instead of putting your pages directly in the app directory, you create a dynamic segment called [locale]. This becomes the foundation of your entire internationalization strategy.

Here's what it looks like:

app/
  [locale]/
    page.tsx
    about/
      page.tsx
    blog/
      page.tsx

That [locale] folder is a dynamic route segment. When users visit /en/about, Next.js knows that locale = 'en'. When they visit /fr/about, locale = 'fr'. This parameter becomes available throughout your app, letting you load the right translations, generate the correct metadata, and build language-aware features.

The beauty is its simplicity. You're not fighting the framework or adding complex routing logic. You're using Next.js's built-in routing system exactly as designed. Every page automatically becomes multi-language capable just by living inside the [locale] folder.

Implementing i18n with `next-intl`

While you could build i18n from scratch, why reinvent the wheel? next-intl has become the go-to library for Next.js App Router internationalization. It handles the heavy lifting while giving you flexibility where you need it.

Installation and Configuration

Getting started with next-intl takes just a few minutes. First, install the package:

npm install next-intl

Next, create your i18n configuration. Start with a simple i18n.config.ts file in your project root:

export const locales = ['en', 'es', 'fr', 'de'] as const;
export const defaultLocale = 'en' as const;

export type Locale = (typeof locales)[number];

This defines your supported languages and sets a default. Keep it simple at first - you can always add more locales later.

Now create an i18n.ts file to handle message loading:

import {notFound} from 'next/navigation';
import {getRequestConfig} from 'next-intl/server';
import {locales} from './i18n.config';

export default getRequestConfig(async ({locale}) => {
  if (!locales.includes(locale as any)) notFound();

  return {
    messages: (await import(`./messages/${locale}.json`)).default
  };
});

This configuration tells next-intl where to find your translation files. When a user visits /fr/about, it loads messages from /messages/fr.json. Simple and predictable.

Creating the Middleware

Middleware is where the magic happens. It intercepts requests and handles locale detection and routing. Create a middleware.ts file in your project root:

import createMiddleware from 'next-intl/middleware';
import {locales, defaultLocale} from './i18n.config';

export default createMiddleware({
  locales,
  defaultLocale,
  localePrefix: 'always'
});

export const config = {
  matcher: ['/((?!api|_next|_vercel|.*\\..*).*)']
};

This middleware does several crucial things. It checks the Accept-Language header to detect user preferences. It validates that the requested locale actually exists. And it handles redirects - if someone visits /about, it redirects them to /en/about (or their preferred language).

The localePrefix: 'always' setting ensures every page has a locale in its URL. This consistency is crucial for SEO - search engines always see clear, unambiguous URLs for each language version.

Structuring Translation Files

Organization is key when managing translations. Create a messages folder in your project root with JSON files for each locale:

messages/
  en.json
  es.json
  fr.json
  de.json

Structure your translations logically. Instead of one giant file, break them into sections:

{
  "common": {
    "welcome": "Welcome",
    "signIn": "Sign In",
    "signOut": "Sign Out"
  },
  "home": {
    "title": "Build Amazing Apps",
    "subtitle": "Start your journey today"
  },
  "about": {
    "title": "About Us",
    "mission": "Our mission is to..."
  }
}

This nested structure keeps translations manageable. You can easily find and update specific strings. Translators can work on one section at a time. And your components can import only the translations they need.

Translating Your Content: Server and Client Components

Next.js App Router's component model adds a layer of complexity to translations. Server Components and Client Components handle translations differently, and understanding this distinction is crucial for performance.

Translating in Server Components with `useTranslations`

Server Components are your performance powerhouse. Translations happen on the server, so users receive fully rendered HTML with their language already applied. No JavaScript needed, no hydration delays.

Using translations in Server Components is straightforward:

import {useTranslations} from 'next-intl';

export default function AboutPage() {
  const t = useTranslations('about');
  
  return (
    <div>
      <h1>{t('title')}</h1>
      <p>{t('mission')}</p>
    </div>
  );
}

The useTranslations hook loads only the translations you need. In this example, it loads the 'about' section from your messages file. This keeps your component bundles lean and improves performance.

You can also use translations with rich formatting:

const t = useTranslations('home');

return (
  <p>
    {t.rich('welcome', {
      strong: (chunks) => <strong>{chunks}</strong>,
      name: 'Sarah'
    })}
  </p>
);

This renders a message like "Welcome, Sarah!" with proper HTML formatting, all handled on the server.

Handling Client Components with Providers

Client Components need translations too, but they can't use the server-side useTranslations hook directly. Instead, you pass messages down from a Server Component parent.

First, create a client provider component:

'use client';

import {NextIntlClientProvider} from 'next-intl';

export default function ClientProvider({
  children,
  messages,
  locale
}: {
  children: React.ReactNode;
  messages: any;
  locale: string;
}) {
  return (
    <NextIntlClientProvider messages={messages} locale={locale}>
      {children}
    </NextIntlClientProvider>
  );
}

Then use it in your layout:

import {useMessages} from 'next-intl';
import ClientProvider from './ClientProvider';

export default function RootLayout({
  children,
  params: {locale}
}: {
  children: React.ReactNode;
  params: {locale: string};
}) {
  const messages = useMessages();
  
  return (
    <html lang={locale}>
      <body>
        <ClientProvider messages={messages} locale={locale}>
          {children}
        </ClientProvider>
      </body>
    </html>
  );
}

Now your Client Components can use translations:

'use client';

import {useTranslations} from 'next-intl';

export default function InteractiveWidget() {
  const t = useTranslations('widget');
  
  return (
    <button onClick={() => alert(t('success'))}>
      {t('clickMe')}
    </button>
  );
}

Building a Language Switcher

Every multilingual site needs a language switcher. Here's a Client Component that lets users change their language:

'use client';

import {useLocale} from 'next-intl';
import {useRouter, usePathname} from 'next/navigation';
import {locales} from '@/i18n.config';

export default function LanguageSwitcher() {
  const locale = useLocale();
  const router = useRouter();
  const pathname = usePathname();

  const handleChange = (newLocale: string) => {
    const newPath = pathname.replace(`/${locale}`, `/${newLocale}`);
    router.push(newPath);
  };

  return (
    <select value={locale} onChange={(e) => handleChange(e.target.value)}>
      {locales.map((loc) => (
        <option key={loc} value={loc}>
          {loc.toUpperCase()}
        </option>
      ))}
    </select>
  );
}

This component reads the current locale, displays available options, and navigates to the same page in the selected language. The URL structure makes this navigation predictable and SEO-friendly.

The SEO Gold Standard: Metadata and `hreflang`

This is where your i18n setup either shines or falls apart. Proper metadata and hreflang implementation can make the difference between ranking well globally or disappearing into search engine obscurity.

Dynamic Titles and Descriptions with `generateMetadata`

Every page needs translated metadata. Search results show your title and description, so they must match the user's language. Next.js's generateMetadata function makes this dynamic generation clean and efficient.

Here's how to implement it in a page:

import {useTranslations} from 'next-intl/server';
import {Metadata} from 'next';

export async function generateMetadata({
  params: {locale}
}: {
  params: {locale: string};
}): Promise<Metadata> {
  const t = await useTranslations({locale, namespace: 'metadata'});
  
  return {
    title: t('home.title'),
    description: t('home.description'),
  };
}

export default function HomePage() {
  const t = useTranslations('home');
  
  return (
    <main>
      <h1>{t('headline')}</h1>
      {/* Page content */}
    </main>
  );
}

This approach ensures your metadata always matches your content language. Google sees Spanish titles for Spanish pages, French descriptions for French pages. No mixed signals, no confusion.

For dynamic pages like blog posts, you can combine locale-based translations with dynamic content:

export async function generateMetadata({
  params: {locale, slug}
}: {
  params: {locale: string; slug: string};
}): Promise<Metadata> {
  const t = await useTranslations({locale, namespace: 'metadata'});
  const post = await getPost(slug, locale);
  
  return {
    title: `${post.title} | ${t('blog.suffix')}`,
    description: post.excerpt,
  };
}

Generating `hreflang` Links Automatically

Here's where many i18n setups fail. hreflang tags tell search engines about all language versions of a page. Miss one, and you're leaving SEO value on the table.

The key is automation. Manually maintaining hreflang tags across hundreds of pages is a recipe for errors. Instead, generate them dynamically:

import {locales, defaultLocale} from '@/i18n.config';

export async function generateMetadata({
  params: {locale}
}: {
  params: {locale: string};
}): Promise<Metadata> {
  const baseUrl = 'https://yoursite.com';
  const currentPath = '/about'; // Or get dynamically
  
  const languages = locales.reduce((acc, loc) => {
    acc[loc] = `${baseUrl}/${loc}${currentPath}`;
    return acc;
  }, {} as Record<string, string>);
  
  return {
    alternates: {
      languages,
      canonical: `${baseUrl}/${defaultLocale}${currentPath}`,
    },
  };
}

This generates proper hreflang links for all your supported languages. Search engines see the connections between translated pages and can serve the right version to each user.

Don't forget the x-default tag for users whose language you don't support:

return {
  alternates: {
    languages: {
      ...languages,
      'x-default': `${baseUrl}/${defaultLocale}${currentPath}`,
    },
  },
};

Setting the `lang` Attribute

The lang attribute on your HTML tag might seem minor, but it's a crucial accessibility and SEO signal. Screen readers use it to pronounce content correctly. Search engines use it as another language indicator.

In your root layout, set it dynamically based on the locale:

export default function RootLayout({
  children,
  params: {locale}
}: {
  children: React.ReactNode;
  params: {locale: string};
}) {
  return (
    <html lang={locale}>
      <body>{children}</body>
    </html>
  );
}

For more specific regional targeting, use full locale codes:

const localeMap = {
  'en': 'en-US',
  'es': 'es-ES',
  'fr': 'fr-FR',
  'de': 'de-DE',
};

return (
  <html lang={localeMap[locale] || locale}>
    <body>{children}</body>
  </html>
);

This tells browsers and search engines not just the language, but the regional variant. It's the difference between "British English" and "American English" - subtle but important for truly localized experiences.

Conclusion

Building a multilingual Next.js app doesn't have to be a battle against SEO. With the right setup - locale-based routing, proper metadata generation, and clear hreflang implementation - your international content can thrive in search results across the globe.

The key is thinking about SEO from the start, not as an afterthought. Every decision, from URL structure to translation organization, impacts how search engines understand and rank your content. Get it right, and you're not just translating words - you're opening doors to millions of users in their native languages.

Start simple. Pick a few core languages. Implement the basics we've covered. Test thoroughly. Then expand. Your global audience is waiting, and now you have the tools to reach them without getting lost in translation.

Remember, internationalization is an ongoing journey. Languages evolve, new markets emerge, and user expectations change. But with a solid foundation built on SEO best practices and Next.js App Router's powerful features, you're ready for whatever the global web throws your way.

References

Next.js 13/14 App Router Localization with next-intl - Phrase

Internationalize your Next.js app with next-intl in App Router | Hygraph

Next.js 15 App Router Localization with next-intl

Like this project

Posted Jun 19, 2025

Go global without sacrificing your rank. Learn how to implement SEO-friendly internationalization (i18n) in the Next.js App Router using best practices.

Likes

Views

Lost in Translation? App Router i18n Setups That Don't Break SEO

Ralph Sanchez

Frontend Engineer

Web Developer

SEO Specialist

Next.js

React

Google Analytics

Small SEO Tools

Computer Software

Lost in Translation? App Router i18n Setups That Don't Break SEO

Why SEO-Friendly i18n is Non-Negotiable

The Dangers of Duplicate Content

Signaling Language and Region to Google

The User Experience Factor

Scenario B: Maria shares yoursite.com/es/blog/articulo. Her friend immediately sees it's the Spanish version. They click and get exactly what they expect. Trust builds. Engagement increases.

The Best Practice: Locale in the URL Path

Why Path-Based Routing Wins

Introducing the `[locale]` Dynamic Segment

Here's what it looks like:

app/
  [locale]/
    page.tsx
    about/
      page.tsx
    blog/
      page.tsx

Implementing i18n with `next-intl`

Installation and Configuration

Getting started with next-intl takes just a few minutes. First, install the package:

npm install next-intl

Next, create your i18n configuration. Start with a simple i18n.config.ts file in your project root:

export const locales = ['en', 'es', 'fr', 'de'] as const;
export const defaultLocale = 'en' as const;

export type Locale = (typeof locales)[number];

This defines your supported languages and sets a default. Keep it simple at first - you can always add more locales later.

Now create an i18n.ts file to handle message loading:

import {notFound} from 'next/navigation';
import {getRequestConfig} from 'next-intl/server';
import {locales} from './i18n.config';

export default getRequestConfig(async ({locale}) => {
  if (!locales.includes(locale as any)) notFound();

  return {
    messages: (await import(`./messages/${locale}.json`)).default
  };
});

This configuration tells next-intl where to find your translation files. When a user visits /fr/about, it loads messages from /messages/fr.json. Simple and predictable.

Creating the Middleware

Middleware is where the magic happens. It intercepts requests and handles locale detection and routing. Create a middleware.ts file in your project root:

import createMiddleware from 'next-intl/middleware';
import {locales, defaultLocale} from './i18n.config';

export default createMiddleware({
  locales,
  defaultLocale,
  localePrefix: 'always'
});

export const config = {
  matcher: ['/((?!api|_next|_vercel|.*\\..*).*)']
};

The localePrefix: 'always' setting ensures every page has a locale in its URL. This consistency is crucial for SEO - search engines always see clear, unambiguous URLs for each language version.

Structuring Translation Files

Organization is key when managing translations. Create a messages folder in your project root with JSON files for each locale:

messages/
  en.json
  es.json
  fr.json
  de.json

Structure your translations logically. Instead of one giant file, break them into sections:

{
  "common": {
    "welcome": "Welcome",
    "signIn": "Sign In",
    "signOut": "Sign Out"
  },
  "home": {
    "title": "Build Amazing Apps",
    "subtitle": "Start your journey today"
  },
  "about": {
    "title": "About Us",
    "mission": "Our mission is to..."
  }
}

Translating Your Content: Server and Client Components

Translating in Server Components with `useTranslations`

Using translations in Server Components is straightforward:

import {useTranslations} from 'next-intl';

export default function AboutPage() {
  const t = useTranslations('about');
  
  return (
    <div>
      <h1>{t('title')}</h1>
      <p>{t('mission')}</p>
    </div>
  );
}

You can also use translations with rich formatting:

const t = useTranslations('home');

return (
  <p>
    {t.rich('welcome', {
      strong: (chunks) => <strong>{chunks}</strong>,
      name: 'Sarah'
    })}
  </p>
);

This renders a message like "Welcome, Sarah!" with proper HTML formatting, all handled on the server.

Handling Client Components with Providers

Client Components need translations too, but they can't use the server-side useTranslations hook directly. Instead, you pass messages down from a Server Component parent.

First, create a client provider component:

'use client';

import {NextIntlClientProvider} from 'next-intl';

export default function ClientProvider({
  children,
  messages,
  locale
}: {
  children: React.ReactNode;
  messages: any;
  locale: string;
}) {
  return (
    <NextIntlClientProvider messages={messages} locale={locale}>
      {children}
    </NextIntlClientProvider>
  );
}

Then use it in your layout:

import {useMessages} from 'next-intl';
import ClientProvider from './ClientProvider';

export default function RootLayout({
  children,
  params: {locale}
}: {
  children: React.ReactNode;
  params: {locale: string};
}) {
  const messages = useMessages();
  
  return (
    <html lang={locale}>
      <body>
        <ClientProvider messages={messages} locale={locale}>
          {children}
        </ClientProvider>
      </body>
    </html>
  );
}

Now your Client Components can use translations:

'use client';

import {useTranslations} from 'next-intl';

export default function InteractiveWidget() {
  const t = useTranslations('widget');
  
  return (
    <button onClick={() => alert(t('success'))}>
      {t('clickMe')}
    </button>
  );
}

Building a Language Switcher

Every multilingual site needs a language switcher. Here's a Client Component that lets users change their language:

'use client';

import {useLocale} from 'next-intl';
import {useRouter, usePathname} from 'next/navigation';
import {locales} from '@/i18n.config';

export default function LanguageSwitcher() {
  const locale = useLocale();
  const router = useRouter();
  const pathname = usePathname();

  const handleChange = (newLocale: string) => {
    const newPath = pathname.replace(`/${locale}`, `/${newLocale}`);
    router.push(newPath);
  };

  return (
    <select value={locale} onChange={(e) => handleChange(e.target.value)}>
      {locales.map((loc) => (
        <option key={loc} value={loc}>
          {loc.toUpperCase()}
        </option>
      ))}
    </select>
  );
}

This component reads the current locale, displays available options, and navigates to the same page in the selected language. The URL structure makes this navigation predictable and SEO-friendly.

The SEO Gold Standard: Metadata and `hreflang`

Dynamic Titles and Descriptions with `generateMetadata`

Here's how to implement it in a page:

import {useTranslations} from 'next-intl/server';
import {Metadata} from 'next';

export async function generateMetadata({
  params: {locale}
}: {
  params: {locale: string};
}): Promise<Metadata> {
  const t = await useTranslations({locale, namespace: 'metadata'});
  
  return {
    title: t('home.title'),
    description: t('home.description'),
  };
}

export default function HomePage() {
  const t = useTranslations('home');
  
  return (
    <main>
      <h1>{t('headline')}</h1>
      {/* Page content */}
    </main>
  );
}

This approach ensures your metadata always matches your content language. Google sees Spanish titles for Spanish pages, French descriptions for French pages. No mixed signals, no confusion.

For dynamic pages like blog posts, you can combine locale-based translations with dynamic content:

export async function generateMetadata({
  params: {locale, slug}
}: {
  params: {locale: string; slug: string};
}): Promise<Metadata> {
  const t = await useTranslations({locale, namespace: 'metadata'});
  const post = await getPost(slug, locale);
  
  return {
    title: `${post.title} | ${t('blog.suffix')}`,
    description: post.excerpt,
  };
}

Generating `hreflang` Links Automatically

Here's where many i18n setups fail. hreflang tags tell search engines about all language versions of a page. Miss one, and you're leaving SEO value on the table.

The key is automation. Manually maintaining hreflang tags across hundreds of pages is a recipe for errors. Instead, generate them dynamically:

import {locales, defaultLocale} from '@/i18n.config';

export async function generateMetadata({
  params: {locale}
}: {
  params: {locale: string};
}): Promise<Metadata> {
  const baseUrl = 'https://yoursite.com';
  const currentPath = '/about'; // Or get dynamically
  
  const languages = locales.reduce((acc, loc) => {
    acc[loc] = `${baseUrl}/${loc}${currentPath}`;
    return acc;
  }, {} as Record<string, string>);
  
  return {
    alternates: {
      languages,
      canonical: `${baseUrl}/${defaultLocale}${currentPath}`,
    },
  };
}

This generates proper hreflang links for all your supported languages. Search engines see the connections between translated pages and can serve the right version to each user.

Don't forget the x-default tag for users whose language you don't support:

return {
  alternates: {
    languages: {
      ...languages,
      'x-default': `${baseUrl}/${defaultLocale}${currentPath}`,
    },
  },
};

Setting the `lang` Attribute

In your root layout, set it dynamically based on the locale:

export default function RootLayout({
  children,
  params: {locale}
}: {
  children: React.ReactNode;
  params: {locale: string};
}) {
  return (
    <html lang={locale}>
      <body>{children}</body>
    </html>
  );
}

For more specific regional targeting, use full locale codes:

const localeMap = {
  'en': 'en-US',
  'es': 'es-ES',
  'fr': 'fr-FR',
  'de': 'de-DE',
};

return (
  <html lang={localeMap[locale] || locale}>
    <body>{children}</body>
  </html>
);

Conclusion

References

Next.js 13/14 App Router Localization with next-intl - Phrase

Internationalize your Next.js app with next-intl in App Router | Hygraph

Next.js 15 App Router Localization with next-intl

Like this project

Posted Jun 19, 2025

Go global without sacrificing your rank. Learn how to implement SEO-friendly internationalization (i18n) in the Next.js App Router using best practices.

Likes

Views

Lost in Translation? App Router i18n Setups That Don't Break SEO

Lost in Translation? App Router i18n Setups That Don't Break SEO

Why SEO-Friendly i18n is Non-Negotiable

The Dangers of Duplicate Content

Signaling Language and Region to Google

The User Experience Factor

The Best Practice: Locale in the URL Path

Why Path-Based Routing Wins

Introducing the [locale] Dynamic Segment

Implementing i18n with next-intl

Installation and Configuration

Creating the Middleware

Structuring Translation Files

Translating Your Content: Server and Client Components

Translating in Server Components with useTranslations

Handling Client Components with Providers

Building a Language Switcher

The SEO Gold Standard: Metadata and hreflang

Dynamic Titles and Descriptions with generateMetadata

Generating hreflang Links Automatically

Setting the lang Attribute

Conclusion

References

Lost in Translation? App Router i18n Setups That Don't Break SEO

Lost in Translation? App Router i18n Setups That Don't Break SEO

Why SEO-Friendly i18n is Non-Negotiable

The Dangers of Duplicate Content

Signaling Language and Region to Google

The User Experience Factor

The Best Practice: Locale in the URL Path

Why Path-Based Routing Wins

Introducing the [locale] Dynamic Segment

Implementing i18n with next-intl

Installation and Configuration

Creating the Middleware

Structuring Translation Files

Translating Your Content: Server and Client Components

Translating in Server Components with useTranslations

Handling Client Components with Providers

Building a Language Switcher

The SEO Gold Standard: Metadata and hreflang

Dynamic Titles and Descriptions with generateMetadata

Generating hreflang Links Automatically

Setting the lang Attribute

Conclusion

References

Introducing the `[locale]` Dynamic Segment

Implementing i18n with `next-intl`

Translating in Server Components with `useTranslations`

The SEO Gold Standard: Metadata and `hreflang`

Dynamic Titles and Descriptions with `generateMetadata`

Generating `hreflang` Links Automatically

Setting the `lang` Attribute

Introducing the `[locale]` Dynamic Segment

Implementing i18n with `next-intl`

Translating in Server Components with `useTranslations`

The SEO Gold Standard: Metadata and `hreflang`

Dynamic Titles and Descriptions with `generateMetadata`

Generating `hreflang` Links Automatically

Setting the `lang` Attribute