Ich teile eine Zahl, die mich nachts wach hielt: 3.540. Das sind 30 Sprachen multipliziert mit 118 Seiten. Wenn wir alle gleichzeitig auf Deluxe Astrology gelauncht hätten, hätte Google Tausende von dünnen, unübersetzten oder maschinell generierten Seiten indexiert. Unsere Rankings wären eingebrochen. Stattdessen bauten wir ein zweistufiges Übersetzungs-Gating-System, das Sprachen progressiv ausrollt, Claude Haiku für Batch-Übersetzungen für etwa 22 Dollar pro Sprache nutzt und die Qualität mit Winston AI Scoring kontrolliert. Das Ganze läuft auf Next.js mit next-intl Middleware, Locale-bewussten kanonischen URLs und Hreflang-Tags sowohl im HTML Head als auch in XML-Sitemaps. Dies ist die vollständige Aufschlüsselung, wie wir es gemacht haben -- jede Middleware-Config, jeder Sitemap-Eintrag, jede Kostenberechnung.

Inhaltsverzeichnis

Hreflang-Tags in Next.js: Wie wir 30 Sprachen über 118 Seiten ausrollen

Warum Hreflang-Tags 2025 noch wichtig sind

Googles Spracherkennung hat sich verbessert. Das gebe ich ihnen zu. Aber „verbessert" bedeutet nicht „gelöst". Wenn Sie regionale Varianten ausführen – denken Sie an pt-BR vs pt-PT oder zh-CN vs zh-TW – benötigt Google noch explizite Signale. Ohne Hreflang werden Ihre portugiesischen Seiten aus Brasilien Ihre auf Portugal ausgerichteten Inhalte kannibalisieren und umgekehrt.

Hier ist, was die Daten uns sagen:

  • Über 60% der mehrsprachigen Websites haben Hreflang-Konfigurationsfehler (Quelle: Ahrefs-Studien zu internationalen SEO-Audits)
  • Eine ordnungsgemäße Hreflang-Implementierung kann die Klickrate in gezielten Märkten innerhalb von 4-6 Wochen um 20-30% erhöhen
  • Websites ohne Hreflang erleben unvorhersehbare Ranking-Rotationen zwischen Sprachversionen, was die Leistungsverfolgung nahezu unmöglich macht

Für Deluxe Astrology sind wir auf 30 Sprachen mit unterschiedlichen Inhalten ausgerichtet. Nicht regionale Varianten – echte verschiedene Sprachen. Das sind 30 verschiedene Zielgruppen, die die richtige Version in den Suchergebnissen finden müssen. Hreflang ist hier nicht optional. Es ist die Grundlage.

Das, was die meisten Leitfäden übersehen: Sie benötigen Hreflang sowohl im HTML <head> als auch in Ihrer XML-Sitemap. Nicht das eine oder das andere. Beides. Google hat bestätigt, dass sie Hreflang aus mehreren Quellen verarbeiten, und Redundanz hier ist keine Verschwendung – sie ist eine Versicherung.

Das 3.540-Seiten-Problem

Lassen Sie mich durch die Mathematik gehen, die unsere gesamte Architektur formte.

Deluxe Astrology hat:

  • 118 Seiten (Kerninhalt-Seiten)
  • 41 Übersetzungs-Namespaces (logische Gruppierungen übersetzter Zeichenketten)
  • 39 Locale-bewusste API-Routen
  • 30 Zielsprachen

30 × 118 = 3.540 Seitenvarianten insgesamt.

Wenn wir alle 3.540 Seiten am ersten Tag gelauncht hätten, würde Folgendes passieren:

  1. Die meisten Seiten würden englischen Fallback-Text mit einem nicht-englischen URL-Pfad enthalten. Google sieht das als dünne/doppelte Inhalte.
  2. Googlebot würde Crawl-Budget verschwenden, indem es Tausende von Low-Quality-Seiten indexiert.
  3. Das Qualitätssignal des Standorts würde in den Keller gehen und sogar die guten englischen Seiten nach unten ziehen.
  4. Benutzer, die auf unübersetzten Seiten landen, würden sofort abspringen.

Das ist nicht theoretisch. Ich habe gesehen, dass es auf Client-Websites passiert ist, die Tools wie Weglot eingebaut haben und in einer Nacht für 20 Sprachen gestartet haben. Der Traffic ging herunter, nicht hinauf.

Die Lösung: Starten Sie nicht alle Sprachen gleichzeitig. Gating sie.

Zweistufiges Übersetzungs-Gating-System

Wir haben unsere 30 Sprachen in zwei Stufen mit grundlegend unterschiedlichen Launch-Strategien aufgeteilt.

Stufe 1: TRANSLATED_LOCALES

Dies sind 15 Sprachen mit vollständig übersetzten Kernseiten, manuell überprüft von Muttersprachlern oder verifizierten Bilinguen.

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

Diese 15 Sprachen erhalten:

  • Vollständige Hreflang-Tags über alle 118 Seiten
  • Aufnahme in die XML-Sitemap
  • Indexierbare, kanonische URLs
  • Locale-bewusste Schema-Markierung

Stufe 2: DYNAMIC_TRANSLATED_LOCALES

Die verbleibenden 15 Sprachen beginnen als englischsprachige Platzhalter. Sie werden nicht indexiert. Sie erhalten keine Hreflang-Einträge. Sie existieren nicht in der 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;

Wenn eine Sprache der Stufe 2 die Übersetzungs-Pipeline abgeschlossen hat – Claude Haiku Batch-Übersetzung, Winston AI Qualitäts-Gate, optionale menschliche Überprüfung – wird sie auf Stufe 1 hochgestuft. Die Hreflang-Einträge, Sitemap-Aufnahme und Indexierungsrichtlinien werden automatisch aktualisiert.

// utils/locale-status.ts
export function isLocaleReady(locale: string): boolean {
  // Überprüfen Sie, ob alle erforderlichen Namespaces Übersetzungen haben
  // mit 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);
}

Das ist die Schlüsseleinsicht: Ihre Hreflang-Implementierung muss dynamisch sein. Sie kann nicht zur Build-Zeit hartcodiert sein (tja, sie kann es, wenn Sie neu erstellen, wenn Locales hochgestuft werden, was wir mit ISR tun).

Hreflang-Tags in Next.js: Wie wir 30 Sprachen über 118 Seiten ausrollen - Architektur

Next-intl Middleware-Konfiguration

Die Middleware ist der Ort, an dem Locale-Erkennung, Routing und die Gating-Logik zusammenkommen. Hier ist unsere aktuelle 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;
  
  // Locale aus Pfad extrahieren
  const pathnameLocale = ALL_LOCALES.find(
    (locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  );

  // Wenn Locale in Stufe 2 ist und noch nicht bereit,
  // Inhalt servieren aber noindex Header hinzufügen
  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|.*\\..*).*)'] 
};

Hier sind ein paar Dinge zu beachten:

  1. localePrefix: 'always' -- Jede URL bekommt ein Locale-Präfix. /en/horoscope, /de/horoskop, etc. Keine Mehrdeutigkeit. Dies ist kritisch für Hreflang, da jede alternative URL distinct und vorhersehbar sein muss.

  2. Stufe 2 noindex -- Unübersetzten Locales werden noch immer gerendert (Benutzer aus diesen Regionen können noch immer stöbern), aber sie erhalten einen noindex Header. Google wird nicht sein Crawl-Budget auf sie verschwenden.

  3. Der Matcher -- Wir schließen API-Routen, Next.js-Internals und statische Dateien aus. Die 39 locale-bewussten API-Routen haben ihre eigene Locale-Handhabung.

Wenn Sie etwas Ähnliches bauen, haben wir mehr über unseren Next.js-Entwicklungsansatz geschrieben und wie Middleware in die Architektur passt.

Hreflang-Implementierung im HTML Head

Next.js 14+ mit dem App Router gibt uns die generateMetadata Funktion. Hier gehen Hreflang-Tags im HTML <head> hin.

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

  // Language Alternates bauen -- nur für indexierbare Locales
  const languages: Record<string, string> = {};
  
  for (const loc of indexableLocales) {
    const localizedSlug = await getLocalizedSlug(pagePath, loc);
    languages[loc] = `${baseUrl}/${loc}${localizedSlug}`;
  }

  // x-default zeigt auf Englisch
  languages['x-default'] = `${baseUrl}/en${pagePath}`;

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

Dies generiert HTML wie:

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

Zwei kritische Details:

  1. Die kanonische URL ist locale-spezifisch. Die kanonische URL der deutschen Seite ist die deutsche URL, nicht die englische. Jede Sprachversion ist ihre eigene kanonische Seite.
  2. x-default ist immer vorhanden. Es verweist auf Englisch. Wenn Google einen Benutzer nicht einer Ihrer Hreflang-Einträge zuordnen kann, ist x-default der Fallback.

Sitemap-Generierung mit Hreflang-Einträgen

HTML <head> Hreflang ist notwendig, aber nicht ausreichend. Für eine Website mit 3.540 potenziellen Seitenvarianten benötigen Sie auch Hreflang in Ihrer XML-Sitemap. Hier ist warum: Google kann Hreflang-Beziehungen aus der Sitemap entdecken, ohne zuerst jede Seite zu 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(); // Gibt 118 Seitendefinitionen zurück

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

      // Alternates für diese spezifische Seite bauen
      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;
}

Dies generiert XML wie:

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

Mit 15 indexierbaren Locales und 118 Seiten sind das 1.770 Sitemap-Einträge. Handhabbar. Wenn alle 30 Sprachen bereit sind, werden es 3.540 sein. Immer noch innerhalb von Googles 50.000-URL-Sitemap-Limit, aber wir teilen trotzdem in Locale-spezifische Sitemaps auf, um die Google Search Console Überwachung sauberer zu machen.

Übersetzungs-Pipeline: Claude Haiku + Winston AI

Hier wird die Ökonomie interessant. Wir mussten 118 Seiten über 41 Namespaces in 30 Sprachen übersetzen. Professionelle menschliche Übersetzung wäre der Goldstandard, aber die Budget-Mathematik ist brutal.

Die Pipeline

  1. Extrahieren -- Alle übersetzungsfähigen Zeichenketten aus 41 Namespaces in strukturiertes JSON extrahieren
  2. Übersetzen -- Batch-Verarbeitung durch Claude Haiku (Anthropics schnelles, billiges Modell) mit Kontext zur Domain (Astrologie), Ton und Zielgruppe
  3. Qualitäts-Gate -- Übersetzten Inhalt durch Winston AI Inhalts-Erkennung und Qualitäts-Scoring laufen lassen. Schwellenwert: 95%+ oder ablehnen.
  4. Menschliche Überprüfung -- Wertvolle Seiten (Homepage, Landing Pages, Money Pages) erhalten manuelle Überprüfung von Muttersprachlern
  5. Hochstufen -- Sobald alle Namespaces Qualitäts-Gates bestehen, wechselt die Locale von DYNAMIC_TRANSLATED_LOCALES zu 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);
    }
  }
}

Die Pro-Sprache-Kosten mit Claude Haiku belaufen sich auf ungefähr 22 Dollar für alle 118 Seiten über 41 Namespaces. Das ist hauptsächlich Token-Kosten -- Haiku ist unglaublich billig bei $0,25 pro Million Input-Token und $1,25 pro Million Output-Token (Preisgestaltung 2025).

Kostenvergleich: Unser Ansatz vs. Alternativen

Dies ist die Tabelle, die das Deluxe Astrology Team überzeugt hat:

Ansatz Kosten für 30 Sprachen Laufende Kosten Qualität Zeit zum Start
Claude Haiku + Winston AI ~660 Dollar insgesamt (22 Dollar/Sprache) 0 Dollar (einmalig) 95%+ Qualitäts-Gate, menschliche Überprüfung für wichtige Seiten 2-3 Wochen Rollout
Weglot 0 Dollar Setup 699 Dollar/Monat (8.388 Dollar/Jahr) Maschinelle Übersetzung, editierbar Instant aber riskant
Professionelle Übersetzer 150.000-300.000 Dollar (5.000-10.000 Dollar/Sprache) 2.000-5.000 Dollar/Sprache für Updates Höchste Qualität 3-6 Monate
DeepL API ~400 Dollar insgesamt 0 Dollar (einmalig) Gut, aber kein Qualitäts-Gate 1-2 Wochen
Google Translate API ~300 Dollar insgesamt 0 Dollar (einmalig) Niedrigere Qualität für Nischen-Inhalte 1 Woche

Seien wir ehrlich: Die 660 Dollar insgesamt für Claude Haiku Übersetzung von 30 Sprachen ist fast verdächtig billig. Der Haken ist, dass Sie das Qualitäts-Gate (Winston AI) und die menschliche Überprüfungs-Schicht benötigen, um es produktionsreif zu machen. Auch mit diesen Kosten faktorisiert -- vielleicht 50-100 Dollar für Winston AI API-Aufrufe und 500-1.000 Dollar für menschliche Überprüfung von hochpreisigen Seiten -- liegen Sie immer noch unter 2.000 Dollar insgesamt. Vergleichen Sie das mit Weglots 699 Dollar/Monat. Sie würden sich in weniger als 3 Monaten amortisieren.

Der echte Killer bei Weglot und ähnlichen Diensten: Sie übersetzen alles auf einmal. Kein Gating. Keine Qualitätskontrolle pro Seite. Sie schmeißen einen Schalter um und plötzlich sieht Google 3.540 Seiten, viele davon sind mittelmäßige maschinelle Übersetzungen. Unser Ansatz lässt uns chirurgisch damit umgehen.

Wir sprechen mehr darüber, wie wir Projekte wie dieses auf unserer Preisseite angehen -- die Übersetzungs-Pipeline ist eine Komponente einer größeren Headless CMS Entwicklung Architektur.

Locale-bewusste Schema-Markierung

Das überrascht fast alle. Ihre strukturierten Daten müssen der Seitensprache entsprechen. Eine deutsche Seite mit englischem FAQ-Schema verwirrt Googles Verständnis der Seite.

// utils/schema.ts
export function generateFAQSchema(
  faqs: Array<{ question: string; answer: string }>,
  locale: string
) {
  return {
    '@context': 'https://schema.org',
    '@type': 'FAQPage',
    'inLanguage': locale, // Kritisch: muss Seiten-Locale entsprechen
    'mainEntity': faqs.map((faq) => ({
      '@type': 'Question',
      'name': faq.question, // Muss in Zielsprache sein
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': faq.answer // Muss in Zielsprache sein
      }
    }))
  };
}

Jeder Schema-Typ, der inLanguage unterstützt, sollte es verwenden. Für Deluxe Astrology gehört dazu:

  • FAQPage -- Fragen und Antworten in der Zielsprache
  • Article -- inLanguage passend zur Locale
  • WebPage -- inLanguage Eigenschaft
  • BreadcrumbList -- Breadcrumb-Namen in der Zielsprache

Übersetzen Sie nicht nur den sichtbaren Inhalt und vergessen Sie die strukturierten Daten. Google liest beides.

Häufige Fehler, die Ihre Rankings ruinieren

Fehlende x-default hreflang

Ich sehe das ständig. Websites implementieren Hreflang für alle ihre Sprachen, vergessen aber x-default. Ohne es hat Google keinen Fallback für Benutzer, deren Sprache keiner Ihrer Versionen entspricht. Immer x-default einbeziehen. Immer auf Ihre Hauptsprache zeigen (normalerweise Englisch).

Inkonsistente Locale in URL vs. Inhalt

Wenn Ihre URL /fr/horoscope sagt, aber der Seiten-Inhalt auf Englisch ist, weil die Übersetzung nicht geladen oder zurückgefallen ist, wird Google dies als weiche 404 oder dünne Inhalte kennzeichnen. Das ist genau der Grund, warum wir das zweistufige Gating-System gebaut haben -- Eine Seite bekommt keine französische URL, bis sie französische Inhalte hat.

Alle Sprachen gleichzeitig starten

Ich habe diesen Punkt bereits schon wiederholt, aber er verdient Wiederholung. 30 Sprachen gleichzeitig zu starten ist der einzelne häufigste Fehler in internationaler SEO. Auch wenn Ihre Übersetzungen perfekt sind, bitten Sie Google, Tausende neuer Seiten in einer Nacht zu crawlen, zu indexieren und zu bewerten. Rollen Sie sie in Batches von 3-5 Sprachen aus. Überwachen Sie die Indexierung in der GSC. Dann fügen Sie mehr hinzu.

Nicht-gegenseitige Hreflang-Tags

Wenn Seite A (Englisch) über Hreflang auf Seite B (Deutsch) zeigt, muss Seite B zurück auf Seite A zeigen. Wenn dieser Rück-Link fehlt, ignoriert Google das Hreflang ganz. Wenn Sie diese dynamisch generieren (wie wir), ist Gegenseitigkeit automatisch. Aber wenn Sie sie manuell verwalten, prüfen Sie regelmäßig.

Self-referencing hreflang fehlend

Jede Seite muss sich selbst in ihren eigenen Hreflang-Set einbeziehen. Die deutsche Seite muss hreflang="de" auf sich selbst auflisten. Das ist in manuellen Implementierungen leicht zu übersehen.

Hreflang an nur einer Stelle

Hreflang nur im <head> oder nur in der Sitemap zu platzieren ist ein Fehler. Benutzen Sie beides. Gürtel und Hosenträger. Google verarbeitet beide Quellen, und wenn eine nicht gecrawlt wird, dient die andere als Sicherung.

Für Projekte in dieser Größenordnung hilft ein erfahrenes Team, diese Fallstricke zu vermeiden. Wenn Sie einen mehrsprachigen Build planen, freuen wir uns, die Herangehensweise zu besprechen.

FAQ

Benötige ich Hreflang-Tags, wenn ich nur Sprachenunterschiede habe (nicht regional)?

Ja. Während sich Googles Spracherkennung 2025 verbessert hat, ist Hreflang immer noch das definitive Signal zum Erzählen von Suchmaschinen, welche Sprachversion Sie servieren möchten. Ohne sie riskieren Sie, dass Google Ihre englische Seite französischsprachigen Benutzern zeigt, einfach weil die englische Version mehr Backlinks hat. Hreflang wird noch wichtiger, wenn Sie 10+ Sprachen haben -- die Wahrscheinlichkeit von Cross-Language-Kannibalisierung nimmt mit der Skalierung dramatisch zu.

Wie viele Hreflang-Einträge sind zu viel für eine einzelne Seite?

Google hat kein offizielles Limit veröffentlicht, aber praktische Tests zeigen, dass Sie über 50 Sprach-Varianten pro Seite hinaus sinkende Erträge und gelegentliche Parsing-Probleme sehen. Für unsere 30-Sprachen-Einrichtung hat jede Seite 31 Hreflang-Einträge (30 Sprachen + x-default), was gut in der sicheren Zone ist. Wenn Sie mit 50+ regionalen und Sprach-Kombinationen umgehen, erwägen Sie, nur das XML-Sitemap-Ansatz zu verwenden, um die <head> Größe handhabbar zu halten.

Sollte ich Hreflang im HTML Head, XML Sitemap oder HTTP Headers verwenden?

Für Next.js Anwendungen verwenden Sie HTML <head> und XML Sitemap. HTTP Headers sind hauptsächlich nützlich für nicht-HTML Ressourcen wie PDFs. Der HTML <head> Ansatz wird zur Crawl-Zeit verarbeitet und gibt das schnellste Signal. Die Sitemap fungiert als Sicherung und hilft Google, alternative Seiten zu entdecken, die sie noch nicht gecrawlt hat. Wir empfehlen nicht, sich auf nur eine Methode zu verlassen.

Welche Kosten fallen bei der Übersetzung einer vollständigen Website mit KI in 2025 an?

Mit Claude Haiku übersetzen wir 118 Seiten über 41 Namespaces für ungefähr 22 Dollar pro Sprache. Für 30 Sprachen sind das etwa 660 Dollar insgesamt. Addieren Sie Winston AI Qualitäts-Gating mit ungefähr 50-100 Dollar für API-Aufrufe und optionale menschliche Überprüfung für hochpreisige Seiten mit 500-1.000 Dollar, und Ihre All-In-Kosten liegen unter 2.000 Dollar. Vergleichen Sie dies mit Weglot mit 699 Dollar/Monat oder professionellen Übersetzungsdiensten mit 5.000-10.000 Dollar pro Sprache.

Warum ein zweistufiges Übersetzungs-Gating-System verwenden, anstatt alles auf einmal zu übersetzen?

Google behandelt dünne Inhalte als negatives Qualitätssignal, das Ihre gesamte Domain nach unten ziehen kann. Wenn Sie 30 Sprachen starten, aber nur 15 qualitativ hochwertige Übersetzungen haben, erstellen diese 15 schlecht übersetzten Sprachen etwa 1.770 Low-Quality-Seiten. Das zweistufige System stellt sicher, dass nur Seiten, die einen 95%+ Qualitätsschwellenwert erfüllen, indexiert werden. Sprachen werden von Stufe 2 zu Stufe 1 hochgestuft, wenn Übersetzungen Qualitäts-Gates bestehen, und schützen Ihre Domain-Autorität während des gesamten Rollouts.

Wie handele ich unübersetzten Seiten für ein Locale, das teilweise übersetzt ist?

Für Locales, wo einige Namespaces übersetzt sind, andere aber nicht, fallen wir auf englische Inhalte zurück und fügen über Middleware ein noindex Meta-Tag hinzu. Die URL wird immer noch aufgelöst (Benutzer können sie zugreifen), aber Google wird die gemischte Sprachenseite nicht indexieren. Sobald alle erforderlichen Namespaces Qualitäts-Gates bestehen, wird das noindex Tag entfernt und Hreflang-Einträge hinzugefügt. Dies verhindert, dass teilweise Übersetzungen Ihren Index kontaminieren.

Welchen Qualitäts-Score-Schwellenwert sollte ich für KI-Übersetzungen verwenden?

Wir verwenden Winston AI mit einem 95%+ Qualitäts-Score-Schwellenwert. Alles darunter wird zur menschlichen Überprüfung oder Re-Übersetzung mit angepassten Prompts gekennzeichnet. In der Praxis erreicht Claude Haiku 95%+ bei etwa 85% der Namespace-Batches beim ersten Versuch. Die verbleibenden 15% scheitern typischerweise aufgrund von Domain-spezifischer Terminologie (Astrologie-Begriffe, die nicht direkt übersetzt werden) oder komplexen Satzstrukturen. Ein 90% Schwellenwert würde merklich unangenehme Phrasierungen durchlassen.

Kann ich Astro statt Next.js für mehrsprachige Sites mit Hreflang verwenden?

Absolut. Astro hat seit Astro 4.0+ ausgezeichnete i18n-Unterstützung eingebaut, und sein Static Generation Modell vereinfacht tatsächlich die Hreflang-Implementierung, da alle URLs zur Build-Zeit bekannt sind. Wir haben mehrsprachige Projekte mit beiden Frameworks gebaut. Für Sites mit schweren dynamischen Inhalten und API-Routen (wie Deluxe Astrologys 39 locale-bewusste Endpoints) ist Next.js der bessere Fit. Für Inhalts-reiche Sites mit weniger Interaktivität kann Astro-Entwicklung schneller und leistungsiger sein. Die Hreflang-Prinzipien sind unabhängig vom Framework identisch.