Hreflang Tags in Next.js: Hoe We 30 talen over 118 pagina's implementeren

Ik wil een getal met je delen dat me uit mijn slaap hield: 3.540. Dat zijn 30 talen vermenigvuldigd met 118 pagina's. Als we deze allemaal tegelijk hadden gelanceerd op Deluxe Astrology, zou Google duizenden dunne, onvertaalde of machine-gegenereerde pagina's hebben geïndexeerd. Onze rankings zouden zijn ingestort. In plaats daarvan hebben we een tweelaags vertaalgating-systeem gebouwd dat talen progressief uitrolt, Claude Haiku gebruikt voor batchvertaling tegen ongeveer $22 per taal, en kwaliteit vaststelt met Winston AI-scoring. Het hele systeem draait op Next.js met next-intl middleware, locale-aware canonieke URL's en hreflang-tags zowel in de HTML-head als in XML-sitemaps. Dit is de volledige analyse van hoe we het hebben gedaan -- elke middleware-configuratie, elk sitemap-item, elke kostencalculatie.

Inhoudsopgave

Hreflang Tags in Next.js: Hoe We 30 talen over 118 pagina's implementeren

Waarom Hreflang Tags nog steeds belangrijk zijn in 2025

Googles taaldetectie is beter geworden. Dat geef ik ze. Maar "beter" betekent niet "opgelost". Als je regionale varianten gebruikt -- denk aan pt-BR versus pt-PT, of zh-CN versus zh-TW -- heeft Google nog steeds expliciete signalen nodig. Zonder hreflang zie je je Portugese pagina's uit Brazilië je op Portugal gericht content kanibaliseren, en vice versa.

Dit is wat de gegevens ons vertellen:

  • Meer dan 60% van meertalige websites heeft hreflang-configuratiefouten (bron: Ahrefs-studies over internationale SEO-audits)
  • Juiste hreflang-implementatie kan klik-through-rates met 20-30% verhogen in gerichte markten binnen 4-6 weken
  • Sites zonder hreflang ondervinden onvoorspelbare rankingrotaties tussen taalversies, waardoor prestatiebewaking bijna onmogelijk wordt

Voor Deluxe Astrology richten we ons op 30 talen met onderscheidende content. Niet regionale varianten -- werkelijke verschillende talen. Dat zijn 30 verschillende doelgroepen die de juiste versie in zoekresultaten moeten vinden. Hreflang is hier niet optioneel. Het is de basis.

Het wat de meeste handleidingen missen: je hebt hreflang nodig in zowel de HTML <head> als je XML-sitemap. Niet de een of de ander. Beiden. Google heeft bevestigd dat ze hreflang uit meerdere bronnen verwerken, en redundantie hier is geen verspilling -- het is verzekering.

Het 3.540 paginaprobleem

Laat me de wiskunde doorlopen die onze hele architectuur heeft bepaald.

Deluxe Astrology heeft:

  • 118 pagina's (kerncontentpagina's)
  • 41 vertaal-naamruimten (logische groeperingen van vertaalbare strings)
  • 39 locale-aware API-routes
  • 30 doeltalen

30 × 118 = 3.540 totale paginavarianten.

Als we alle 3.540 pagina's op dag één zouden lanceren, zou dit gebeuren:

  1. De meeste pagina's zouden Engelse fallback-tekst met een niet-Engelse URL-pad bevatten. Google ziet dit als dunne/gedupliceerde content.
  2. Googlebot zou crawlbudget verspillen door duizenden pagina's met lage kwaliteit te indexeren.
  3. Het kwaliteitssignaal van de site zou instorten, zelfs de goede Engelse pagina's meesleuren.
  4. Gebruikers die op onvertaalde pagina's belanden zouden onmiddellijk vertrekken.

Dit is niet theoretisch. Ik heb dit zien gebeuren op clientsites die Weglot of vergelijkbare tools hebben ingeplugd en de schakelaar voor 20 talen in één keer hebben omgezet. Het verkeer nam af, niet toe.

De oplossing: zet niet alle talen tegelijk in. Gate ze.

Tweelaags vertaalgating-systeem

We hebben onze 30 talen in twee lagen opgedeeld met fundamenteel verschillende lanceerstrategieën.

Laag 1: TRANSLATED_LOCALES

Dit zijn 15 talen met volledig vertaalde kernpagina's, handmatig beoordeeld door native speakers of geverifieerde tweetaligen.

// 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;

Deze 15 talen krijgen:

  • Volledige hreflang-tags over alle 118 pagina's
  • Opname in de XML-sitemap
  • Indexeerbare, canonieke URL's
  • Locale-aware schema markup

Laag 2: DYNAMIC_TRANSLATED_LOCALES

De overige 15 talen beginnen als Engelse-alleen placeholders. Ze worden niet geïndexeerd. Ze krijgen geen hreflang-items. Ze bestaan niet in de 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;

Als een Laag 2-taal de vertaalpipeline voltooit -- Claude Haiku batch-vertaling, Winston AI kwaliteitgate, optionele menselijke beoordeling -- promoveert het naar Laag 1. De hreflang-items, sitemap-opname en indexeringsdirectieven werken automatisch bij.

// utils/locale-status.ts
export function isLocaleReady(locale: string): boolean {
  // Check if all required namespaces have translations
  // with Winston AI scores >= 95%
  const status = getTranslationStatus(locale);
  return status.completedNamespaces >= REQUIRED_NAMESPACES
    && status.minQualityScore >= 0.95;
}

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

Dit is het belangrijkste inzicht: je hreflang-implementatie moet dynamisch zijn. Het kan geen statische lijst zijn die hardcoded is op buildtijd (nou ja, dat kan het als je herbouwt wanneer locales promoveren, wat we doen met ISR).

Hreflang Tags in Next.js: Hoe We 30 talen over 118 pagina's implementeren - architectuur

Next-intl Middleware-configuratie

De middleware is waar locale-detectie, routing en de gating-logica allemaal samenkomen. Dit is onze werkelijke middleware.ts:

// 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;
  
  // Extract locale from path
  const pathnameLocale = ALL_LOCALES.find(
    (locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  );

  // If locale is in Tier 2 and not yet ready, 
  // serve content but add noindex header
  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|.*\\..*).*)'] 
};

Een paar dingen om op te merken hier:

  1. localePrefix: 'always' -- Elke URL krijgt een locale-prefix. /en/horoscope, /de/horoskop, enz. Geen ambiguïteit. Dit is cruciaal voor hreflang omdat elke afwisselende URL onderscheiden en voorspelbaar moet zijn.

  2. Laag 2 noindex -- Onvertaalde locales renderen nog steeds (gebruikers uit die regio's kunnen nog steeds bladeren), maar ze krijgen een noindex-header. Google zal geen crawlbudget verspillen aan hen.

  3. The matcher -- We sluiten API-routes, Next.js-internals en statische bestanden uit. De 39 locale-aware API-routes hebben hun eigen locale-verwerking.

Als je iets soortgelijks bouwt, hebben we meer geschreven over onze Next.js-ontwikkelingsbenadering en hoe middleware in de architectuur past.

Hreflang-implementatie in HTML Head

Next.js 14+ met de App Router geeft ons de generateMetadata-functie. Dit is waar hreflang-tags in de HTML <head> gaan.

// 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();

  // Build language alternates -- only for indexable locales
  const languages: Record<string, string> = {};
  
  for (const loc of indexableLocales) {
    const localizedSlug = await getLocalizedSlug(pagePath, loc);
    languages[loc] = `${baseUrl}/${loc}${localizedSlug}`;
  }

  // x-default points to English
  languages['x-default'] = `${baseUrl}/en${pagePath}`;

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

Dit genereert HTML als:

<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 meer indexeerbare locales ... -->
<link rel="alternate" hreflang="x-default" href="https://deluxeastrology.com/en/horoscope" />

Twee kritische details:

  1. De canonieke URL is locale-specifiek. De canonieke Duitse pagina is de Duitse URL, niet de Engelse. Elke taalversie is een eigen canonieke pagina.
  2. x-default is altijd aanwezig. Het verwijst naar Engels. Als Google een gebruikerstaal niet kan matchen met een van je hreflang-items, is x-default de fallback.

Sitemap-generatie met Hreflang-items

HTML <head> hreflang is noodzakelijk maar niet voldoende. Voor een site met 3.540 mogelijke paginavarianten heb je ook hreflang in je XML-sitemap nodig. Dit is waarom: Google kan hreflang-relaties uit de sitemap ontdekken zonder eerst elke pagina te crawlen.

// 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(); // Returns 118 page definitions

  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}`;

      // Build alternates for this specific page
      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;
}

Dit genereert XML als:

<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>

Met 15 indexeerbare locales en 118 pagina's zijn dat 1.770 sitemap-items. Beheersbaar. Als alle 30 talen klaar zijn, worden het 3.540. Nog steeds binnen Googles limiet van 50.000 URLs per sitemap, maar we splitsen toch in per-locale sitemaps voor schonere Google Search Console-bewaking.

Vertaalpipeline: Claude Haiku + Winston AI

Dit is waar de economie interessant wordt. We moeten 118 pagina's over 41 naamruimten in 30 talen vertalen. Professionele menselijke vertaling zou de gouden standaard zijn, maar de budgetberekening is genadeloos.

De Pipeline

  1. Extractie -- Alle vertaalbare strings uit 41 naamruimten halen in gestructureerde JSON
  2. Vertaling -- Batch-verwerking via Claude Haiku (Anthropics snelle, goedkope model) met context over het domein (astrologie), toon en doelgroep
  3. Kwaliteitgate -- Vertaalde content door Winston AI's inhoudsdetectie en kwaliteitsscoring. Drempel: 95%+ of afwijzen.
  4. Menselijke beoordeling -- Waardevolle pagina's (startpagina, landingspagina's, geldpagina's) krijgen handmatige beoordeling door native speakers
  5. Promoveren -- Als alle naamruimten kwaliteitsgates passeren, promoveert de locale van DYNAMIC_TRANSLATED_LOCALES naar TRANSLATED_LOCALES
// scripts/translate-locale.ts
async function translateLocale(targetLocale: string) {
  const namespaces = await getNamespaces(); // 41 namespaces
  
  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: `You are a professional translator specializing in astrology content. 
               Translate from English to ${getLanguageName(targetLocale)}. 
               Maintain astrological terminology accuracy. 
               Preserve all interpolation variables like {name} and {date}.`,
      messages: [{
        role: 'user',
        content: `Translate these JSON key-value pairs. Return valid JSON only:\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);
    }
  }
}

De kosten per taal met Claude Haiku bedragen ongeveer $22 voor alle 118 pagina's over 41 naamruimten. Dat zijn vooral tokenkosten -- Haiku is ongelooflijk goedkoop tegen $0,25 per miljoen invoertokens en $1,25 per miljoen uitvoertokens (2025 prijzen).

Kostenvergelijking: ons benadering vs alternatieven

Dit is de tabel die het Deluxe Astrology-team overtuigde:

Benadering Kosten voor 30 talen Doorlopende kosten Kwaliteit Tijd tot lancering
Claude Haiku + Winston AI ~$660 totaal ($22/taal) $0 (eenmalig) 95%+ kwaliteitgate, menselijke beoordeling voor sleutelpagina's 2-3 weken rolling
Weglot $0 instelling $699/maand ($8.388/jaar) Machinevertaling, bewerkbaar Onmiddellijk maar risicovol
Professionele vertalers $150.000-$300.000 ($5.000-10.000/taal) $2.000-5.000/taal voor updates Hoogste kwaliteit 3-6 maanden
DeepL API ~$400 totaal $0 (eenmalig) Goed maar geen kwaliteitgate 1-2 weken
Google Translate API ~$300 totaal $0 (eenmalig) Lagere kwaliteit voor niche-content 1 week

Laten we eerlijk zijn: de $660 totaal voor Claude Haiku-vertaling van 30 talen is bijna verdacht goedkoop. De catch is dat je de kwaliteitgate (Winston AI) en menselijke beoordelinglaag nodig hebt om het productieklaar te maken. Zelfs met die kosten meegenomen -- misschien $50-100 voor Winston AI API-calls en $500-1.000 voor menselijke beoordeling van waardevolle pagina's -- zit je nog onder de $2.000 totaal. Vergelijk dat met Weglots $699/maand. Je breekt zelfs in onder de 3 maanden.

De echte killer met Weglot en vergelijkbare services: ze vertalen alles tegelijk. Geen gating. Geen kwaliteitscontrole per pagina. Je zet een schakelaar om en plotseling ziet Google 3.540 pagina's, waarvan veel middelmatige machinevertaling. Onze benadering laat ons chirurgisch zijn.

We praten meer over hoe we projecten als deze benaderen op onze prijspagina -- de vertaalpipeline is één onderdeel van een grotere headless CMS development architectuur.

Locale-aware schema markup

Dit ene vangen bijna iedereen verrast. Je gestructureerde gegevens moeten overeenkomen met de paginataal. Een Duitse pagina met Engelse FAQ-schema verwarrt Googles begrip van de pagina.

// utils/schema.ts
export function generateFAQSchema(
  faqs: Array<{ question: string; answer: string }>,
  locale: string
) {
  return {
    '@context': 'https://schema.org',
    '@type': 'FAQPage',
    'inLanguage': locale, // Critical: must match page locale
    'mainEntity': faqs.map((faq) => ({
      '@type': 'Question',
      'name': faq.question, // Must be in target language
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': faq.answer // Must be in target language
      }
    }))
  };
}

Elk schematype dat inLanguage ondersteunt, zou het moeten gebruiken. Voor Deluxe Astrology, dat includes:

  • FAQPage -- Vragen en antwoorden in de doeltaal
  • Article -- inLanguage die overeenkomt met de locale
  • WebPage -- inLanguage-eigenschap
  • BreadcrumbList -- Breadcrumb-namen in de doeltaal

Vertaal niet alleen de zichtbare content en vergeet de gestructureerde gegevens. Google leest beide.

Veelvoorkomende fouten die je rankings zullen vernietigen

Ontbrekende x-default hreflang

Ik zie dit constant. Sites implementeren hreflang voor al hun talen maar vergeten x-default. Zonder het heeft Google geen fallback voor gebruikers wiens taal niet overeenkomt met een van je versies. Voeg het altijd toe. Wijs het altijd naar je primaire taal (meestal Engels).

Inconsistente locale in URL vs content

Als je URL /fr/horoscope zegt maar de pagina-inhoud is in het Engels omdat de vertaling niet is geladen of terug is gevallen, zal Google dit markeren als soft 404 of dunne content. Dit is precies waarom we het tweelaags gating-systeem hebben gebouwd -- een pagina krijgt geen Franse URL totdat het Franse inhoud heeft.

Alle talen tegelijk lanceren

Ik heb dit al vaak herhaald, maar het verdient herhaling. Alle 30 talen tegelijk lanceren is de meest voorkomende fout in internationale SEO. Zelfs als je vertalingen perfect zijn, vraag je Google om duizenden nieuwe pagina's in één nacht te crawlen, indexeren en evalueren. Roll ze in batches van 3-5 talen uit. Monitor indexering in GSC. Voeg dan meer toe.

Niet-reciproke hreflang-tags

Als pagina A (Engels) via hreflang naar pagina B (Duits) verwijst, moet pagina B terug naar pagina A verwijzen. Als deze wederkerige link ontbreekt, negeert Google de hreflang volledig. Wanneer je deze dynamisch genereert (zoals we doen), is wederkerigheid automatisch. Maar als je ze handmatig beheert, audit regelmatig.

Self-referencing hreflang ontbreekt

Elke pagina moet zichzelf in zijn eigen hreflang-set opnemen. De Duitse pagina moet hreflang="de" vermelden die naar zichzelf wijst. Dit is gemakkelijk over het hoofd te zien in handmatige implementaties.

Hreflang op slechts één locatie

Hreflang alleen in de <head> of alleen in de sitemap plaatsen is een fout. Gebruik beide. Riem en bretels. Google verwerkt beide bronnen, en als de ene niet kan worden gecrawld, dient de ander als backup.

Voor projecten van deze omvang helpt een ervaren team om deze valkuilen te vermijden. Als je een meertalige build plant, helpen we graag het benadering door te nemen.

Veelgestelde vragen

Heb ik hreflang-tags nodig als ik alleen taalgerschillen heb (niet regionaal)? Ja. Hoewel Googles taaldetectie in 2025 is verbeterd, is hreflang nog steeds het definitieve signaal voor het vertellen aan zoekmachines welke taalversie ze moeten serveren. Zonder ze riskeer je dat Google je Engelse pagina aan Franstalige gebruikers toont simpelweg omdat de Engelse versie meer backlinks heeft. Hreflang wordt nog kritischer wanneer je 10+ talen hebt -- de kans op cross-language kanibalisatie neemt dramatisch toe met schaal.

Hoeveel hreflang-items zijn te veel voor een enkele pagina? Google heeft geen officiële limiet gepubliceerd, maar praktisch testen toont aan dat je voorbij 50 taalkombinaties per pagina afnemende opbrengsten en af en toe parsefouten begint te zien. Voor onze 30-talenopstelling heeft elke pagina 31 hreflang-items (30 talen + x-default), wat goed binnen de veilige zone ligt. Als je met 50+ regionale en taalcombinaties omgaat, overweeg dan alleen de XML-sitemap-benadering om de grootte van <head> beheersbaar te houden.

Zou ik hreflang in de HTML head, XML-sitemap of HTTP-headers moeten gebruiken? Voor Next.js-toepassingen, gebruik zowel HTML <head> als XML-sitemap. HTTP-headers zijn vooral nuttig voor niet-HTML-resources zoals PDF's. De HTML <head>-benadering wordt op crawltijd verwerkt en geeft het snelste signaal. De sitemap fungeert als backup en helpt Google afwisselende pagina's te ontdekken die het nog niet heeft gecrawld. We raden niet aan om je op slechts één methode te verlassen.

Wat zijn de kosten van volledige website-vertaling met AI in 2025? Met Claude Haiku vertalen we 118 pagina's over 41 naamruimten voor ongeveer $22 per taal. Voor 30 talen zijn dat ongeveer $660 totaal. Voeg Winston AI-kwaliteitsgate toe aan ongeveer $50-100 voor API-calls, en optionele menselijke beoordeling voor waardevolle pagina's aan $500-1.000, en je all-in kosten zijn onder de $2.000. Vergelijk dit met Weglots $699/maand of professionele vertaalsservices tegen $5.000-10.000 per taal.

Waarom een tweelaags vertaalgating-systeem gebruiken in plaats van alles tegelijk te vertalen? Google behandelt dunne content als een negatief kwaliteitssignaal dat je hele domein kan meeslepen. Als je 30 talen lanceert maar slechts 15 hebben kwaliteitsvertalingen, creëren die 15 slecht vertaalde talen ongeveer 1.770 pagina's met lage kwaliteit. Het tweelaags systeem zorgt ervoor dat alleen pagina's die een drempel van 95%+ kwaliteit halen, worden geïndexeerd. Talen promoveren van Laag 2 naar Laag 1 als vertalingen kwaliteitsgates passeren, je domeinautoriteit beschermend gedurende de rollout.

Hoe ga ik om met onvertaalde pagina's voor een locale die gedeeltelijk is vertaald? Voor locales waar sommige naamruimten zijn vertaald maar anderen niet, vallen we terug op Engelse inhoud en voegen we een noindex-metatag toe via middleware. De URL wordt nog steeds opgelost (gebruikers kunnen deze benaderen), maar Google indexeert de gemengde-taal pagina niet. Als alle vereiste naamruimten kwaliteitsgates passeren, wordt de noindex-tag verwijderd en worden hreflang-items toegevoegd. Dit voorkomt dat gedeeltelijke vertalingen je index vervuilen.

Welke kwaliteitsscore-drempel moet ik gebruiken voor AI-vertalingen? We gebruiken Winston AI met een drempel van 95%+ kwaliteitsscore. Alles eronder wordt gemarkeerd voor menselijke beoordeling of hervertaling met aangepaste prompts. In de praktijk bereikt Claude Haiku 95%+ op ongeveer 85% van naamruimtebatches in de eerste pass. De resterende 15% mislukt meestal vanwege domeinspecifieke terminologie (astrologiebegrippen die niet direct vertalen) of complexe zinsstructuren. Een drempel van 90% zou merkbaar ongemakkelijke formulering doorlaten.

Kan ik Astro gebruiken in plaats van Next.js voor meertalige sites met hreflang? Absoluut. Astro heeft sinds Astro 4.0+ uitstekende i18n-ondersteuning ingebouwd, en zijn static-generatiemodel vereenvoudigt eigenlijk hreflang-implementatie omdat alle URL's op buildtijd bekend zijn. We hebben meertalige projecten met beide frameworks gebouwd. Voor sites met zware dynamische inhoud en API-routes (zoals Deluxe Astrology's 39 locale-aware endpoints) is Next.js de betere keuze. Voor contentrijke sites met minder interactiviteit kan Astro development sneller en performanter zijn. De hreflang-principes zijn identiek ongeacht het framework.