Je partage un chiffre qui m'a tenu éveillé : 3 540. C'est 30 langues multipliées par 118 pages. Si nous avions lancé tout cela simultanément sur Deluxe Astrology, Google aurait indexé des milliers de pages minces, non traduites ou de mauvaise qualité générée par machine. Nos classements auraient chuté. Au lieu de cela, nous avons construit un système de gating de traduction à deux niveaux qui déploie les langues progressivement, utilise Claude Haiku pour la traduction par lot à environ 22 $ par langue, et contrôle la qualité avec le scoring Winston AI. Le tout fonctionne sur Next.js avec les middleware next-intl, les URL canoniques adaptées aux paramètres régionaux, et les balises hreflang à la fois dans le head HTML et les sitemaps XML. Voici le détail complet de comment nous l'avons fait -- chaque config de middleware, chaque entrée sitemap, chaque calcul de coût.

Table des matières

Balises Hreflang dans Next.js : Comment nous livrons 30 langues sur 118 pages

Pourquoi les balises Hreflang comptent toujours en 2025

La détection de langue de Google s'est améliorée. Je vais leur donner ça. Mais « meilleur » ne signifie pas « résolu ». Si vous exécutez des variantes régionales -- pensez à pt-BR vs pt-PT, ou zh-CN vs zh-TW -- Google a toujours besoin de signaux explicites. Sans hreflang, vous verrez vos pages en portugais du Brésil cannibaliser votre contenu ciblé sur le Portugal, et vice versa.

Voici ce que les données nous disent :

  • Plus de 60 % des sites multilingues ont des erreurs de configuration hreflang (source : études Ahrefs sur les audits SEO internationaux)
  • Une implémentation correcte de hreflang peut augmenter les taux de clics de 20 à 30 % sur les marchés ciblés en 4 à 6 semaines
  • Les sites sans hreflang connaissent des rotations de classement imprévisibles entre les versions linguistiques, ce qui rend le suivi des performances presque impossible

Pour Deluxe Astrology, nous ciblons 30 langues avec du contenu distinct. Pas des variantes régionales -- des langues réellement différentes. C'est 30 audiences différentes qui ont besoin de trouver la bonne version dans les résultats de recherche. Hreflang n'est pas facultatif ici. C'est la fondation.

Ce que la plupart des guides oublient : vous avez besoin de hreflang dans à la fois le <head> HTML et votre sitemap XML. Pas l'un ou l'autre. Les deux. Google a confirmé qu'il traite hreflang à partir de plusieurs sources, et la redondance ici n'est pas un gaspillage -- c'est une assurance.

Le problème des 3 540 pages

Laissez-moi vous expliquer les mathématiques qui ont façonné toute notre architecture.

Deluxe Astrology a :

  • 118 pages (pages de contenu principal)
  • 41 espaces de noms de traduction (regroupements logiques de chaînes traduisibles)
  • 39 routes API adaptées aux paramètres régionaux
  • 30 langues cibles

30 × 118 = 3 540 variantes de page au total.

Si nous avions lancé les 3 540 pages le premier jour, voici ce qui se passerait :

  1. La plupart des pages contiendraient du texte de secours en anglais avec un chemin d'URL non anglophone. Google voit cela comme du contenu mince/dupliqué.
  2. Googlebot brûlerait le budget de crawl en indexant des milliers de pages de faible qualité.
  3. Le signal de qualité global du site s'effondrerait, traînant vers le bas même les bonnes pages en anglais.
  4. Les utilisateurs atterrissant sur des pages non traduites rebondiraient immédiatement.

Ce n'est pas théorique. Je l'ai vu se produire sur des sites clients qui ont intégré Weglot ou des outils similaires et ont activé le switch pour 20 langues du jour au lendemain. Le trafic a diminué, pas augmenté.

La solution : ne lancez pas toutes les langues à la fois. Contrôlez-les.

Système de gating de traduction à deux niveaux

Nous avons divisé nos 30 langues en deux niveaux avec des stratégies de lancement fondamentalement différentes.

Niveau 1 : TRANSLATED_LOCALES

Ce sont 15 langues avec des pages principales entièrement traduites, examinées manuellement par des locuteurs natifs ou des bilingues vérifiés.

// config/locales.ts
export const TRANSLATED_LOCALES = [
  'en', 'es', 'fr', 'de', 'it', 'pt-BR', 'ja', 'ko',
  'zh-CN', 'zh-TW', 'ru', 'ar', 'hi', 'tr', 'nl'
] as const;

Ces 15 langues reçoivent :

  • Des balises hreflang complètes sur les 118 pages
  • Inclusion dans le sitemap XML
  • Des URL canoniques indexables
  • Un balisage de schéma adapté aux paramètres régionaux

Niveau 2 : DYNAMIC_TRANSLATED_LOCALES

Les 15 langues restantes commencent comme des espaces réservés en anglais uniquement. Elles ne sont pas indexées. Elles n'obtiennent pas les entrées hreflang. Elles n'existent pas dans le sitemap.

export const DYNAMIC_TRANSLATED_LOCALES = [
  'pl', 'sv', 'da', 'fi', 'no', 'cs', 'ro', 'hu',
  'el', 'th', 'vi', 'id', 'ms', 'uk', 'bg'
] as const;

export const ALL_LOCALES = [
  ...TRANSLATED_LOCALES,
  ...DYNAMIC_TRANSLATED_LOCALES
] as const;

Lorsqu'une langue du Niveau 2 complète le pipeline de traduction -- traduction par lot Claude Haiku, qualité gate Winston AI, révision humaine optionnelle -- elle se promeut au Niveau 1. Les entrées hreflang, l'inclusion sitemap et les directives d'indexation se mettent à jour automatiquement.

// utils/locale-status.ts
export function isLocaleReady(locale: string): boolean {
  // Vérifiez si tous les espaces de noms requis ont des traductions
  // avec des scores Winston AI >= 95%
  const status = getTranslationStatus(locale);
  return status.completedNamespaces >= REQUIRED_NAMESPACES
    && status.minQualityScore >= 0.95;
}

export function getIndexableLocales(): string[] {
  return ALL_LOCALES.filter(isLocaleReady);
}

C'est l'insight clé : votre implémentation hreflang doit être dynamique. Elle ne peut pas être une liste statique codée en dur au moment de la compilation (bon, elle peut si vous recompiler quand les paramètres régionaux se promeuvent, ce que nous faisons avec ISR).

Balises Hreflang dans Next.js : Comment nous livrons 30 langues sur 118 pages - architecture

Configuration du middleware Next-intl

Le middleware est l'endroit où la détection des paramètres régionaux, le routage et la logique de gating convergent tous. Voici notre middleware.ts réel :

// middleware.ts
import createMiddleware from 'next-intl/middleware';
import { NextRequest, NextResponse } from 'next/server';
import { ALL_LOCALES, TRANSLATED_LOCALES } from './config/locales';

const intlMiddleware = createMiddleware({
  locales: ALL_LOCALES,
  defaultLocale: 'en',
  localePrefix: 'always',
  localeDetection: true
});

export default function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname;
  
  // Extrayez le paramètre régional du chemin
  const pathnameLocale = ALL_LOCALES.find(
    (locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  );

  // Si le paramètre régional est au Niveau 2 et pas encore prêt,
  // servez le contenu mais ajoutez un header noindex
  if (
    pathnameLocale &&
    !TRANSLATED_LOCALES.includes(pathnameLocale) &&
    !isLocaleReady(pathnameLocale)
  ) {
    const response = intlMiddleware(request);
    response.headers.set('X-Robots-Tag', 'noindex, nofollow');
    return response;
  }

  return intlMiddleware(request);
}

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

Quelques éléments à noter ici :

  1. localePrefix: 'always' -- Chaque URL obtient un préfixe de paramètre régional. /en/horoscope, /de/horoskop, etc. Pas d'ambiguïté. C'est critique pour hreflang car chaque URL alternative doit être distincte et prévisible.

  2. Niveau 2 noindex -- Les paramètres régionaux non traduits s'affichent toujours (les utilisateurs de ces régions peuvent toujours naviguer), mais ils reçoivent un header noindex. Google ne gaspillera pas le budget de crawl dessus.

  3. Le matcher -- Nous excluons les routes API, les composants internes de Next.js et les fichiers statiques. Les 39 routes API adaptées aux paramètres régionaux ont leur propre gestion des paramètres régionaux.

Si vous construisez quelque chose de similaire, nous avons écrit plus sur notre approche du développement Next.js et comment le middleware s'inscrit dans l'architecture.

Implémentation de Hreflang dans le head HTML

Next.js 14+ avec l'App Router nous donne la fonction generateMetadata. C'est là que les balises hreflang vont dans le <head> HTML.

// app/[locale]/[...slug]/page.tsx
import { getIndexableLocales } from '@/utils/locale-status';
import { getLocalizedSlug } from '@/utils/slugs';

type Props = {
  params: { locale: string; slug: string[] };
};

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { locale, slug } = params;
  const baseUrl = 'https://deluxeastrology.com';
  const pagePath = slug ? `/${slug.join('/')}` : '';
  const indexableLocales = getIndexableLocales();

  // Construisez les alternances linguistiques -- uniquement pour les paramètres régionaux indexables
  const languages: Record<string, string> = {};
  
  for (const loc of indexableLocales) {
    const localizedSlug = await getLocalizedSlug(pagePath, loc);
    languages[loc] = `${baseUrl}/${loc}${localizedSlug}`;
  }

  // x-default pointe vers l'anglais
  languages['x-default'] = `${baseUrl}/en${pagePath}`;

  return {
    title: await getLocalizedTitle(pagePath, locale),
    alternates: {
      canonical: `${baseUrl}/${locale}${pagePath}`,
      languages
    }
  };
}

Cela génère du HTML comme :

<link rel="canonical" href="https://deluxeastrology.com/de/horoskop" />
<link rel="alternate" hreflang="en" href="https://deluxeastrology.com/en/horoscope" />
<link rel="alternate" hreflang="de" href="https://deluxeastrology.com/de/horoskop" />
<link rel="alternate" hreflang="fr" href="https://deluxeastrology.com/fr/horoscope" />
<!-- ... 12 paramètres régionaux indexables supplémentaires ... -->
<link rel="alternate" hreflang="x-default" href="https://deluxeastrology.com/en/horoscope" />

Deux détails critiques :

  1. L'URL canonique est spécifique à la langue. L'URL canonique de la page allemande est l'URL allemande, pas celle en anglais. Chaque version linguistique est sa propre page canonique.
  2. x-default est toujours présent. Il pointe vers l'anglais. Si Google ne peut pas faire correspondre la langue d'un utilisateur à l'une de vos entrées hreflang, x-default est la solution de secours.

Génération de sitemap avec entrées Hreflang

Le hreflang du <head> HTML est nécessaire mais insuffisant. Pour un site avec 3 540 variantes de page potentielles, vous avez également besoin de hreflang dans votre sitemap XML. Voici pourquoi : Google peut découvrir les relations hreflang à partir du sitemap sans crawler chaque page d'abord.

// app/sitemap.ts
import { MetadataRoute } from 'next';
import { getIndexableLocales } from '@/utils/locale-status';
import { getAllPages } from '@/utils/pages';
import { getLocalizedSlug } from '@/utils/slugs';

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = 'https://deluxeastrology.com';
  const indexableLocales = getIndexableLocales();
  const pages = await getAllPages(); // Retourne les définitions de 118 pages

  const entries: MetadataRoute.Sitemap = [];

  for (const page of pages) {
    for (const locale of indexableLocales) {
      const localizedSlug = await getLocalizedSlug(page.path, locale);
      const url = `${baseUrl}/${locale}${localizedSlug}`;

      // Construisez les alternances pour cette page spécifique
      const alternates: Record<string, string> = {};
      for (const altLocale of indexableLocales) {
        const altSlug = await getLocalizedSlug(page.path, altLocale);
        alternates[altLocale] = `${baseUrl}/${altLocale}${altSlug}`;
      }
      alternates['x-default'] = `${baseUrl}/en${page.path}`;

      entries.push({
        url,
        lastModified: page.updatedAt,
        changeFrequency: page.changeFreq || 'weekly',
        priority: locale === 'en' ? 0.9 : 0.8,
        alternates: {
          languages: alternates
        }
      });
    }
  }

  return entries;
}

Cela génère du XML comme :

<url>
  <loc>https://deluxeastrology.com/de/horoskop</loc>
  <lastmod>2025-01-15</lastmod>
  <xhtml:link rel="alternate" hreflang="en" href="https://deluxeastrology.com/en/horoscope"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://deluxeastrology.com/de/horoskop"/>
  <xhtml:link rel="alternate" hreflang="fr" href="https://deluxeastrology.com/fr/horoscope"/>
  <xhtml:link rel="alternate" hreflang="x-default" href="https://deluxeastrology.com/en/horoscope"/>
</url>

Avec 15 paramètres régionaux indexables et 118 pages, c'est 1 770 entrées de sitemap. Gérable. Quand les 30 langues seront prêtes, ce sera 3 540. Toujours dans la limite de 50 000 URL du sitemap de Google, mais nous divisons en sitemaps par paramètre régional de toute façon pour un suivi plus clair dans Google Search Console.

Pipeline de traduction : Claude Haiku + Winston AI

C'est là que l'économie devient intéressante. Nous devions traduire 118 pages sur 41 espaces de noms en 30 langues. La traduction professionnelle humaine serait l'étalon-or, mais les mathématiques budgétaires sont brutales.

Le pipeline

  1. Extraire -- Tirez toutes les chaînes traduisibles de 41 espaces de noms en JSON structuré
  2. Traduire -- Traiter par lot via Claude Haiku (le modèle rapide et bon marché d'Anthropic) avec le contexte du domaine (astrologie), le ton et le public cible
  3. Contrôle de qualité -- Exécutez le contenu traduit via la détection de contenu et le scoring de qualité de Winston AI. Seuil : 95%+ ou rejeter.
  4. Révision humaine -- Les pages à valeur élevée (homepage, pages d'atterrissage, pages monétisables) obtiennent une révision manuelle par des locuteurs natifs
  5. Promotion -- Une fois que tous les espaces de noms passent les contrôles de qualité, le paramètre régional passe de DYNAMIC_TRANSLATED_LOCALES à TRANSLATED_LOCALES
// scripts/translate-locale.ts
async function translateLocale(targetLocale: string) {
  const namespaces = await getNamespaces(); // 41 espaces de noms
  
  for (const ns of namespaces) {
    const sourceStrings = await loadNamespace('en', ns);
    
    const translated = await claude.messages.create({
      model: 'claude-3-haiku-20240307',
      max_tokens: 4096,
      system: `Vous êtes un traducteur professionnel spécialisé dans le contenu astrologique. 
               Traduisez de l'anglais vers ${getLanguageName(targetLocale)}. 
               Maintenez l'exactitude de la terminologie astrologique. 
               Préservez toutes les variables d'interpolation comme {name} et {date}.`,
      messages: [{
        role: 'user',
        content: `Traduisez ces paires clé-valeur JSON. Retournez uniquement du JSON valide:\n${JSON.stringify(sourceStrings, null, 2)}`
      }]
    });

    const qualityScore = await winstonAI.analyze(translated.content);
    
    if (qualityScore >= 0.95) {
      await saveNamespace(targetLocale, ns, translated.content);
    } else {
      await flagForReview(targetLocale, ns, translated.content, qualityScore);
    }
  }
}

Le coût par langue avec Claude Haiku fonctionne à environ 22 $ pour les 118 pages sur 41 espaces de noms. C'est principalement des coûts de token -- Haiku est incroyablement bon marché à 0,25 $ par million de tokens d'entrée et 1,25 $ par million de tokens de sortie (tarification 2025).

Comparaison des coûts : Notre approche vs les alternatives

Voici le tableau qui a convaincu l'équipe de Deluxe Astrology :

Approche Coût pour 30 langues Coût continu Qualité Temps de lancement
Claude Haiku + Winston AI ~660 $ au total (22 $/lang) 0 $ (une seule fois) Qualité gate 95%+, révision humaine pour les pages clés 2-3 semaines en rouleau
Weglot 0 $ configuration 699 $/mois (8 388 $/an) Traduction machine, éditable Instantané mais risqué
Traducteurs professionnels 150 000 $-300 000 $ (5 000 $-10 000 $/lang) 2 000 $-5 000 $/lang pour les mises à jour Meilleure qualité 3-6 mois
API DeepL ~400 $ au total 0 $ (une seule fois) Bonne mais pas de contrôle de qualité 1-2 semaines
API Google Translate ~300 $ au total 0 $ (une seule fois) Qualité inférieure pour le contenu de niche 1 semaine

Soyons honnêtes : le coût de 660 $ au total pour la traduction via Claude Haiku de 30 langues est presque suspecte. Le problème est que vous avez besoin du contrôle de qualité (Winston AI) et de la couche d'examen humain pour le rendre prêt pour la production. Même en tenant compte de ces coûts -- peut-être 50-100 $ pour les appels API Winston AI et 500-1 000 $ pour l'examen humain des pages à valeur élevée -- vous êtes toujours en dessous de 2 000 $ au total. Comparez cela à Weglot à 699 $/mois. Vous atteindriez le seuil de rentabilité en moins de 3 mois.

Le vrai problème avec Weglot et les services similaires : ils traduisent tout à la fois. Pas de gating. Pas de contrôle de qualité par page. Vous activez le switch et soudainement Google voit 3 540 pages, dont beaucoup sont des traductions machines de qualité médiocre. Notre approche nous permet d'être chirurgicaux à ce sujet.

Nous parlons plus de comment nous abordons des projets comme celui-ci sur notre page de tarification -- le pipeline de traduction est un composant d'une architecture de développement headless CMS plus large.

Balisage de schéma adapté aux paramètres régionaux

Celle-ci en surprend presque tout le monde. Vos données structurées doivent correspondre à la langue de la page. Une page allemande avec un schéma FAQ en anglais confond la compréhension de la page par Google.

// utils/schema.ts
export function generateFAQSchema(
  faqs: Array<{ question: string; answer: string }>,
  locale: string
) {
  return {
    '@context': 'https://schema.org',
    '@type': 'FAQPage',
    'inLanguage': locale, // Critique : doit correspondre au paramètre régional de la page
    'mainEntity': faqs.map((faq) => ({
      '@type': 'Question',
      'name': faq.question, // Doit être dans la langue cible
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': faq.answer // Doit être dans la langue cible
      }
    }))
  };
}

Chaque type de schéma qui supporte inLanguage devrait l'utiliser. Pour Deluxe Astrology, cela inclut :

  • FAQPage -- Questions et réponses dans la langue cible
  • Article -- inLanguage correspondant au paramètre régional
  • WebPage -- Propriété inLanguage
  • BreadcrumbList -- Noms de chemin de navigation dans la langue cible

Ne traduisez pas seulement le contenu visible et oubliez les données structurées. Google lit les deux.

Erreurs courantes qui feront plonger vos classements

Hreflang x-default manquant

Je vois cela constamment. Les sites implémentent hreflang pour toutes leurs langues mais oublient x-default. Sans cela, Google n'a pas de solution de secours pour les utilisateurs dont la langue ne correspond à aucune de vos versions. Incluez-le toujours. Pointez-le toujours vers votre langue principale (généralement l'anglais).

Paramètre régional incohérent dans l'URL vs le contenu

Si votre URL dit /fr/horoscope mais que le contenu de la page est en anglais parce que la traduction n'a pas été chargée ou a échoué, Google signalera cela comme une soft 404 ou du contenu mince. C'est exactement pourquoi nous avons construit le système de gating à deux niveaux -- une page n'obtient une URL française que si elle a du contenu français.

Lancer toutes les langues à la fois

J'ai déjà battu ce tambour, mais cela mérite de répéter. Lancer 30 langues simultanément est l'erreur la plus courante en SEO international. Même si vos traductions sont parfaites, vous demandez à Google de crawler, indexer et évaluer des milliers de pages nouvelles du jour au lendemain. Déploirez-les par lots de 3 à 5 langues. Surveillez l'indexation dans GSC. Puis ajoutez-en d'autres.

Balises hreflang non réciproques

Si la page A (anglais) pointe vers la page B (allemand) via hreflang, la page B doit pointer en arrière vers la page A. Si ce lien réciproque manque, Google ignore entièrement le hreflang. Quand vous générez ceux-ci dynamiquement (comme nous le faisons), la réciprocité est automatique. Mais si vous les gérez manuellement, auditez régulièrement.

Auto-référencement hreflang manquant

Chaque page doit s'inclure elle-même dans son propre ensemble hreflang. La page allemande doit lister hreflang="de" pointant vers elle-même. C'est facile à manquer dans les implémentations manuelles.

Hreflang dans un seul endroit

Mettre hreflang uniquement dans le <head> ou uniquement dans le sitemap est une erreur. Utilisez les deux. Bretelles et bretelles. Google traite les deux sources, et si l'une ne peut pas être crawlée, l'autre sert de sauvegarde.

Pour les projets à cette échelle, avoir une équipe expérimentée aide à éviter ces pièges. Si vous planifiez une construction multilingue, nous sommes heureux de discuter de l'approche.

FAQ

Ai-je besoin de balises hreflang si je n'ai que des différences de langue (pas de variantes régionales) ?

Oui. Alors que la détection de langue de Google s'est améliorée en 2025, hreflang est toujours le signal définitif pour dire aux moteurs de recherche quelle version linguistique servir. Sans eux, vous risquez que Google affiche votre page en anglais à des utilisateurs francophones simplement parce que la version anglaise a plus de backlinks. Hreflang devient encore plus critique quand vous avez 10+ langues -- la probabilité de cannibalisation cross-language augmente considérablement avec l'échelle.

Combien d'entrées hreflang sont trop nombreuses pour une seule page ?

Google n'a pas publié de limite officielle, mais les tests pratiques montrent qu'au-delà de 50 variantes linguistiques par page, vous commencez à voir des rendements décroissants et des problèmes d'analyse occasionnels. Pour notre configuration de 30 langues, chaque page a 31 entrées hreflang (30 langues + x-default), ce qui est bien dans la zone sûre. Si vous avez affaire à 50+ combinaisons régionales et linguistiques, envisagez d'utiliser uniquement l'approche sitemap XML pour maintenir la taille du <head> gérable.

Dois-je utiliser hreflang dans le head HTML, le sitemap XML ou les en-têtes HTTP ?

Pour les applications Next.js, utilisez à la fois le <head> HTML et le sitemap XML. Les en-têtes HTTP sont principalement utiles pour les ressources non-HTML comme les PDF. L'approche du <head> HTML est traitée au moment du crawl et donne le signal le plus rapide. Le sitemap agit comme une sauvegarde et aide Google à découvrir les pages alternatives qu'il n'a pas encore crawlées. Nous ne recommandons pas de compter uniquement sur une seule méthode.

Quel est le coût de la traduction d'un site web complet avec l'IA en 2025 ?

Avec Claude Haiku, nous traduisons 118 pages sur 41 espaces de noms pour environ 22 $ par langue. Pour 30 langues, c'est environ 660 $ au total. Ajoutez le scoring de qualité Winston AI à environ 50-100 $ pour les appels API, et la révision humaine optionnelle pour les pages à valeur élevée à 500-1 000 $, et votre coût all-in est inférieur à 2 000 $. Comparez cela à Weglot à 699 $/mois ou les services de traduction professionnelle à 5 000 $-10 000 $ par langue.

Pourquoi utiliser un système de gating de traduction à deux niveaux au lieu de tout traduire à la fois ?

Google traite le contenu mince comme un signal de qualité négatif qui peut traîner votre domaine entier. Si vous lancez 30 langues mais que seules 15 ont des traductions de qualité, ces 15 langues mal traduites créent environ 1 770 pages de faible qualité. Le système à deux niveaux garantit que seules les pages répondant à un seuil de qualité de 95%+ sont indexées. Les paramètres régionaux passent du Niveau 2 au Niveau 1 au fur et à mesure que les traductions réussissent les contrôles de qualité, protégeant votre autorité de domaine tout au long du déploiement.

Comment gérer les pages non traduites pour un paramètre régional partiellement traduit ?

Pour les paramètres régionaux où certains espaces de noms sont traduits mais d'autres ne le sont pas, nous revenons au contenu en anglais et ajoutons une balise meta noindex via middleware. L'URL se résout toujours (les utilisateurs peuvent y accéder), mais Google n'indexera pas la page en langage mixte. Une fois que tous les espaces de noms requis passent les contrôles de qualité, la balise noindex est supprimée et les entrées hreflang sont ajoutées. Cela évite que les traductions partielles ne polluent votre index.

Quel seuil de score de qualité dois-je utiliser pour les traductions d'IA ?

Nous utilisons Winston AI avec un seuil de score de qualité de 95%+. Tout ce qui est en dessous est signalé pour révision humaine ou re-traduction avec des invites ajustées. En pratique, Claude Haiku atteint 95%+ sur environ 85 % des lots d'espaces de noms à la première tentative. Les 15 % restants échouent généralement en raison de la terminologie spécifique au domaine (termes astrologiques qui ne se traduisent pas directement) ou de structures de phrases complexes. Un seuil de 90 % laisserait passer des formulations clairement maladroites.

Puis-je utiliser Astro à la place de Next.js pour les sites multilingues avec hreflang ?

Absolument. Astro a un excellent support i18n intégré depuis Astro 4.0+, et son modèle de génération statique simplifie réellement l'implémentation hreflang puisque toutes les URL sont connues au moment de la compilation. Nous avons construit des projets multilingues avec les deux frameworks. Pour les sites avec beaucoup de contenu dynamique et des routes API (comme les 39 points de terminaison adaptés aux paramètres régionaux de Deluxe Astrology), Next.js est le meilleur choix. Pour les sites riches en contenu avec moins d'interactivité, le développement Astro peut être plus rapide et plus performant. Les principes hreflang sont identiques quel que soit le framework.