علامات Hreflang في Next.js: كيف نطلقنا 30 لغة عبر 118 صفحة

دعني أشارك رقمًا أبقاني مستيقظًا ليلاً: 3,540. هذا 30 لغة مضروبة في 118 صفحة. إذا أطلقنا كل تلك الصفحات في نفس الوقت على Deluxe Astrology، كان Google سيفهرس آلاف الصفحات الرقيقة أو غير المترجمة أو الحاوية على محتوى آلي سيء. كان ترتيبنا سينهار. بدلاً من ذلك، بنينا نظام بوابات ترجمة ثنائي المستويات يطرح اللغات تدريجياً، ويستخدم Claude Haiku للترجمة الجماعية بحوالي 22 دولار لكل لغة، ويحمي الجودة من خلال تسجيل Winston AI. يعمل كل شيء على Next.js مع middleware next-intl، وعناوين URL قانونية محلية الوعي، وعلامات hreflang في رأس HTML وخرائط مواقع XML. هذا هو الشرح الكامل لكيفية قيامنا بذلك -- كل إعدادات middleware، كل إدخال في Sitemap، كل حساب تكلفة.

جدول المحتويات

علامات Hreflang في Next.js: كيف نطلقنا 30 لغة عبر 118 صفحة

لماذا علامات Hreflang لا تزال مهمة في 2025

أصبح اكتشاف اللغة من Google أفضل. سأعترف بذلك. لكن "أفضل" لا تعني "محلول". إذا كنت تدير متغيرات إقليمية -- فكر في pt-BR مقابل pt-PT، أو zh-CN مقابل zh-TW -- فإن Google لا تزال بحاجة إلى إشارات صريحة. بدون hreflang، ستشهد صفحات البرتغالية من البرازيل وهي تقلل من محتويك الموجه للبرتغال، والعكس صحيح.

إليك ما تخبرنا به البيانات:

  • أكثر من 60% من المواقع متعددة اللغات بها أخطاء في إعدادات hreflang (المصدر: دراسات Ahrefs حول تدقيق SEO الدولي)
  • يمكن أن يؤدي تطبيق hreflang الصحيح إلى رفع معدلات النقر من خلال الظهور بنسبة 20-30% في الأسواق المستهدفة في غضون 4-6 أسابيع
  • تواجه المواقع بدون hreflang دورات ترتيب غير متوقعة بين إصدارات اللغة، مما يجعل تتبع الأداء مستحيلاً تقريباً

بالنسبة لـ Deluxe Astrology، نستهدف 30 لغة بمحتوى متميز. ليست متغيرات إقليمية -- لغات فعلية مختلفة. هذه 30 جمهور مختلف يحتاجون إلى العثور على النسخة الصحيحة في نتائج البحث. Hreflang ليست اختيارية هنا. إنها الأساس.

الشيء الذي تفتقده معظم الأدلة: أنت تحتاج إلى hreflang في كل من <head> HTML و XML sitemap. ليس أحدهما أو الآخر. كليهما. أكدت Google أنها تعالج hreflang من مصادر متعددة، والزيادة هنا ليست مضيعة -- إنها تأمين.

مشكلة الـ 3,540 صفحة

دعني أشرح الرياضيات التي شكلت معمارنا بالكامل.

يحتوي Deluxe Astrology على:

  • 118 صفحة (صفحات المحتوى الأساسية)
  • 41 مساحة ترجمة (تجميعات منطقية للسلاسل القابلة للترجمة)
  • 39 مسار API محلي الوعي
  • 30 لغة مستهدفة

30 × 118 = 3,540 إجمالي متغيرات صفحة.

إذا أطلقنا جميع صفحات الـ 3,540 في اليوم الأول، إليك ما سيحدث:

  1. ستحتوي معظم الصفحات على نص احتياطي بالإنجليزية مع مسار URL بلغة غير إنجليزية. تراه Google كمحتوى رقيق/مكرر.
  2. كان Googlebot سيحرق ميزانية الزحف بفهرسة آلاف الصفحات منخفضة الجودة.
  3. كان إجمالي إشارة جودة الموقع سينهار، مما يسحب حتى الصفحات الإنجليزية الجيدة.
  4. كان المستخدمون الذين يصلون إلى صفحات غير مترجمة سيرتدون على الفور.

هذا ليس نظري. رأيته يحدث على مواقع العملاء التي أدرجت Weglot أو أدوات مماثلة وقلبت الخيار لـ 20 لغة بين عشية وضحاها. انخفضت حركة المرور، لم تزيد.

الحل: لا تطلق جميع اللغات في نفس الوقت. ضعها خلف بوابات.

نظام بوابات الترجمة ثنائي المستويات

قسمنا لغاتنا الـ 30 إلى مستويين بأستراتيجيات إطلاق مختلفة بشكل أساسي.

المستوى 1: TRANSLATED_LOCALES

هذه 15 لغة بصفحات أساسية مترجمة بالكامل، تمت مراجعتها يدويًا من قبل متحدثين أصليين أو ثنائيي لسان موثوقين.

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

تحصل هذه 15 لغة على:

  • علامات hreflang كاملة عبر جميع صفحات الـ 118
  • إدراج في خريطة الموقع XML
  • عناوين URL قانونية قابلة للفهرسة
  • ترميز schema محلي الوعي

المستوى 2: DYNAMIC_TRANSLATED_LOCALES

اللغات الـ 15 المتبقية تبدأ كأماكن بديلة بالإنجليزية فقط. لا يتم فهرستها. لا تحصل على إدخالات hreflang. فهي غير موجودة في 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;

عندما تكمل لغة المستوى 2 خط أنابيب الترجمة -- ترجمة دفعية Claude Haiku، بوابة جودة Winston AI، مراجعة بشرية اختيارية -- تتخرج إلى المستوى 1. تتحدث إدخالات hreflang وإدراج Sitemap وتوجيهات الفهرسة تلقائياً.

// utils/locale-status.ts
export function isLocaleReady(locale: string): boolean {
  // تحقق مما إذا كانت جميع مساحات الترجمة المطلوبة تحتوي على ترجمات
  // مع درجات 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);
}

هذه هي الفكرة الأساسية: تطبيق hreflang الخاص بك يجب أن يكون ديناميكياً. لا يمكن أن تكون قائمة ثابتة مشفرة بشكل ثابت في وقت الإنشاء (حسناً، يمكن ذلك إذا أعدت الإنشاء عندما تتخرج اللغات، وهو ما نفعله مع ISR).

علامات Hreflang في Next.js: كيف نطلقنا 30 لغة عبر 118 صفحة - المعمارية

إعدادات Next-intl Middleware

Middleware هو حيث يتقارب اكتشاف اللغة والتوجيه والمنطق البوابات. إليك 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;
  
  // استخرج اللغة من المسار
  const pathnameLocale = ALL_LOCALES.find(
    (locale) => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  );

  // إذا كانت اللغة في المستوى 2 ولم تكن جاهزة بعد،
  // قدم المحتوى لكن أضف رأس 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|.*\\..*).*)'] 
};

هناك بعض الأشياء المهمة هنا:

  1. localePrefix: 'always' -- يحصل كل عنوان URL على بادئة لغة. /en/horoscope، /de/horoskop، إلخ. لا التباس. هذا حرج لـ hreflang لأن كل عنوان URL بديل يجب أن يكون متميزاً وقابلاً للتنبؤ.

  2. Tier 2 noindex -- لا تزال اللغات المترجمة ديناميكياً تعيد المحتوى (يمكن للمستخدمين من تلك المناطق تصفح الموقع)، لكنهم يحصلون على رأس noindex. لن تهدر Google ميزانية الزحف عليها.

  3. Matcher -- نستبعد مسارات API و Next.js internals والملفات الثابتة. لدى 39 مسار API محلي الوعي معالجة لغة خاصة بها.

إذا كنت تبني شيئاً مماثلاً، كتبنا المزيد حول نهج Next.js development وكيف يناسب Middleware المعمارية.

تطبيق Hreflang في رأس HTML

Next.js 14+ مع App Router يعطينا دالة generateMetadata. هنا حيث تذهب علامات hreflang في <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();

  // بناء البدائل اللغوية -- فقط للغات القابلة للفهرسة
  const languages: Record<string, string> = {};
  
  for (const loc of indexableLocales) {
    const localizedSlug = await getLocalizedSlug(pagePath, loc);
    languages[loc] = `${baseUrl}/${loc}${localizedSlug}`;
  }

  // x-default يشير إلى الإنجليزية
  languages['x-default'] = `${baseUrl}/en${pagePath}`;

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

هذا يولد HTML مثل:

<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 لغة إضافية قابلة للفهرسة ... -->
<link rel="alternate" hreflang="x-default" href="https://deluxeastrology.com/en/horoscope" />

تفاصيل حرجة:

  1. عنوان URL القانوني محلي الوعي. عنوان URL القانوني للصفحة الألمانية هو الألمانية URL، وليس الإنجليزية. كل إصدار لغة هو صفحة قانونية خاصة به.
  2. x-default موجود دائماً. يشير إلى الإنجليزية. إذا لم تتمكن Google من مطابقة لغة المستخدم مع أي من إدخالات hreflang الخاصة بك، فإن x-default هو البديل.

توليد Sitemap مع إدخالات Hreflang

Hreflang في <head> HTML ضروري لكنه غير كافٍ. بالنسبة لموقع بـ 3,540 متغير صفحة محتملة، تحتاج أيضاً إلى hreflang في خريطة الموقع XML الخاصة بك. إليك السبب: يمكن لـ Google اكتشاف علاقات hreflang من Sitemap دون الزحف إلى كل صفحة أولاً.

// 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(); // تعود إلى تعريفات صفحات 118

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

      // بناء البدائل لهذه الصفحة المحددة
      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;
}

هذا يولد XML مثل:

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

مع 15 لغة قابلة للفهرسة و 118 صفحة، هذا 1,770 إدخال Sitemap. قابل للإدارة. عندما تكون جميع 30 لغة جاهزة، ستكون 3,540. لا تزال ضمن حد Google البالغ 50,000 عنوان URL في Sitemap، لكننا نقسم إلى sitemaps لكل لغة على أي حال لمراقبة Google Search Console أنظف.

خط أنابيب الترجمة: Claude Haiku + Winston AI

هنا حيث تصبح الاقتصادات مثيرة للاهتمام. كنا بحاجة إلى ترجمة 118 صفحة عبر 41 مساحة ترجمة إلى 30 لغة. الترجمة البشرية الاحترافية ستكون المعيار الذهبي، لكن رياضيات الميزانية وحشية.

خط الأنابيب

  1. استخرج -- اسحب جميع السلاسل القابلة للترجمة من 41 مساحة ترجمة إلى JSON منظم
  2. ترجم -- معالجة دفعية من خلال Claude Haiku (نموذج Anthropic السريع والرخيص) مع السياق حول المجال (علم التنجيم)، والنبرة، والجمهور المستهدف
  3. بوابة الجودة -- قم بتشغيل المحتوى المترجم من خلال كشف المحتوى وتسجيل جودة Winston AI. الحد الأدنى: 95%+ أو رفض.
  4. المراجعة البشرية -- صفحات عالية القيمة (الصفحة الرئيسية، صفحات الهبوط، صفحات المال) تحصل على مراجعة يدوية من قبل متحدثين أصليين
  5. تخرج -- بمجرد أن تمر جميع مساحات الترجمة بوابات الجودة، تنتقل اللغة من DYNAMIC_TRANSLATED_LOCALES إلى TRANSLATED_LOCALES
// scripts/translate-locale.ts
async function translateLocale(targetLocale: string) {
  const namespaces = await getNamespaces(); // 41 مساحة ترجمة
  
  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: `أنت مترجم احترافي متخصص في محتوى علم التنجيم. 
               قم بالترجمة من الإنجليزية إلى ${getLanguageName(targetLocale)}. 
               حافظ على دقة مصطلحات علم التنجيم. 
               احفظ جميع متغيرات الاستيفاء مثل {name} و {date}.`,
      messages: [{
        role: 'user',
        content: `ترجم أزواج القيمة-المفتاح JSON هذه. أرجع JSON صحيح فقط:\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);
    }
  }
}

تبلغ تكاليف كل لغة مع Claude Haiku حوالي $22 لجميع صفحات الـ 118 عبر مساحات الـ 41 ترجمة. معظمها تكاليف الرموز -- Haiku رخيص بشكل لا يصدق بسعر $0.25 لكل مليون رمز الإدخال و $1.25 لكل مليون رمز الإخراج (تسعير 2025).

مقارنة التكاليف: نهجنا مقابل البدائل

هذا هو الجدول الذي أقنع فريق Deluxe Astrology:

النهج تكلفة 30 لغة التكلفة المستمرة الجودة الوقت حتى الإطلاق
Claude Haiku + Winston AI حوالي $660 إجمالي ($22/لغة) $0 (لمرة واحدة) جودة بوابة 95%+، مراجعة يدوية للصفحات الرئيسية 2-3 أسابيع متدحرج
Weglot $0 إعداد $699/شهر ($8,388/سنة) ترجمة آلية، قابلة للتحرير فوري لكن محفوف بالمخاطر
المترجمون المحترفون $150,000-$300,000 ($5,000-10,000/لغة) $2,000-5,000/لغة للتحديثات أعلى جودة 3-6 أشهر
DeepL API حوالي $400 إجمالي $0 (لمرة واحدة) جيدة لكن بدون بوابة جودة 1-2 أسبوع
Google Translate API حوالي $300 إجمالي $0 (لمرة واحدة) جودة أقل للمحتوى المتخصص أسبوع

دعونا نكون صريحين: $660 إجمالي لترجمة Claude Haiku لـ 30 لغة رخيص بشكل مريب تقريباً. المشكلة هي أنك تحتاج إلى بوابة الجودة (Winston AI) وطبقة مراجعة بشرية لجعله جاهزاً للإنتاج. حتى مع احتساب تلك التكاليف -- ربما $50-100 لاستدعاءات Winston AI API و $500-1,000 لمراجعة يدوية لصفحات عالية القيمة -- أنت لا تزال تحت $2,000 إجمالي. قارن ذلك بـ $699/شهر Weglot. كنت ستتعادل في أقل من 3 أشهر.

القاتل الفعلي مع Weglot والخدمات المماثلة: يترجمون كل شيء في نفس الوقت. بدون بوابات. لا يوجد تحكم في الجودة لكل صفحة. تقلب مفتاح وفجأة ترى Google 3,540 صفحة، وعدد كبير منها ترجمات آلية متوسطة. يتيح لنا نهجنا أن نكون جراحيين في الأمر.

نحن نتحدث أكثر عن كيف نتعامل مع مشاريع مثل هذه على صفحة التسعير -- خط أنابيب الترجمة هو أحد مكونات معمارية تطوير CMS بدون رأس أوسع.

ترميز Schema محلي الوعي

هذا يفاجئ تقريباً الجميع. بيانات المحتوى المنظمة الخاصة بك يجب أن تتطابق مع لغة الصفحة. صفحة ألمانية بـ FAQ schema إنجليزي يربك فهم Google للصفحة.

// utils/schema.ts
export function generateFAQSchema(
  faqs: Array<{ question: string; answer: string }>,
  locale: string
) {
  return {
    '@context': 'https://schema.org',
    '@type': 'FAQPage',
    'inLanguage': locale, // حرج: يجب أن يطابق محلية الصفحة
    'mainEntity': faqs.map((faq) => ({
      '@type': 'Question',
      'name': faq.question, // يجب أن تكون باللغة المستهدفة
      'acceptedAnswer': {
        '@type': 'Answer',
        'text': faq.answer // يجب أن تكون باللغة المستهدفة
      }
    }))
  };
}

كل نوع schema يدعم inLanguage يجب أن يستخدمه. بالنسبة لـ Deluxe Astrology، ذلك يشمل:

  • FAQPage -- الأسئلة والأجوبة باللغة المستهدفة
  • Article -- inLanguage يطابق المحلية
  • WebPage -- خاصية inLanguage
  • BreadcrumbList -- أسماء Breadcrumb باللغة المستهدفة

لا تترجم المحتوى المرئي فقط وتنسى البيانات المنظمة. Google تقرأ كليهما.

الأخطاء الشائعة التي ستدمر ترتيبك

فقدان x-default hreflang

أرى هذا باستمرار. تطبق المواقع hreflang لجميع لغاتها لكنها تنسى x-default. بدونها، ليس لدى Google بديل للمستخدمين الذين لا تطابق لغتهم أي من نسخك. قم دائماً بتضمينها. قم دائماً بتوجيهها إلى لغتك الأساسية (عادة الإنجليزية).

عدم التناسق في المحلية في URL مقابل المحتوى

إذا قال عنوان URL الخاص بك /fr/horoscope لكن محتوى الصفحة بالإنجليزية لأن الترجمة لم تُحمّل أو عادت، فإن Google ستضع علامة على هذا كـ soft 404 أو محتوى رقيق. هذا بالضبط السبب في أننا بنينا نظام البوابات ثنائي المستوى -- لا تحصل صفحة على عنوان URL فرنسي حتى تحتوي على محتوى فرنسي.

إطلاق جميع اللغات في نفس الوقت

لقد كررت هذه النقطة بالفعل، لكنها تستحق التكرار. إطلاق 30 لغة في نفس الوقت هو الخطأ الأكثر شيوعاً في SEO الدولي. حتى لو كانت ترجماتك مثالية، فأنت تطلب من Google الزحف والفهرسة والتقييم لآلاف الصفحات الجديدة بين عشية وضحاها. رتبها في دفعات من 3-5 لغات. راقب الفهرسة في GSC. ثم أضف المزيد.

علامات hreflang غير متبادلة

إذا كانت الصفحة A (إنجليزية) تشير إلى الصفحة B (ألمانية) عبر hreflang، يجب أن تشير الصفحة B إلى الصفحة A. إذا كان هذا الرابط المتبادل مفقوداً، فإن Google تتجاهل hreflang بالكامل. عندما تولد هذه ديناميكياً (كما نفعل)، يكون التبادل تلقائياً. لكن إذا كنت تديرها يدويًا، قم بتدقيق منتظم.

hreflang الإشارة الذاتية المفقودة

يجب أن تتضمن كل صفحة نفسها في مجموعة hreflang الخاصة بها. يجب أن تُدرج الصفحة الألمانية hreflang="de" تشير إلى نفسها. هذا سهل الفقدان في التطبيقات اليدوية.

Hreflang في موقع واحد فقط

وضع hreflang فقط في <head> أو فقط في Sitemap هو خطأ. استخدم كليهما. الحزام والمشابك. تعالج Google كلا المصدرين، وإذا فشل أحدها في الزحف، فإن الآخر يعمل كنسخة احتياطية.

بالنسبة للمشاريع بهذا الحجم، وجود فريق ذي خبرة يساعد في تجنب هذه الأخطاء. إذا كنت تخطط لبناء متعدد اللغات، فنحن سعداء بـ الحديث عن النهج.

الأسئلة الشائعة

هل أحتاج إلى علامات hreflang إذا كانت لدي فقط اختلافات لغوية (وليس إقليمية)؟ نعم. بينما تحسن Google في اكتشاف اللغة في 2025، hreflang لا تزال الإشارة النهائية لإخبار محركات البحث بنسخة اللغة التي يجب تقديمها. بدونها، تخاطر Google بإظهار صفحتك بالإنجليزية لمستخدمي اللغة الفرنسية ببساطة لأن نسخة الإنجليزية بها روابط خلفية أكثر. تصبح Hreflang أكثر أهمية حتى عندما يكون لديك 10+ لغات -- احتمالية حدوث تقنين متعدد اللغات تزداد بشكل كبير مع الحجم.

كم عدد إدخالات hreflang كثيرة جداً لصفحة واحدة؟ لم تنشر Google حد رسمي، لكن الاختبار العملي يظهر أنه بعد 50 متغير لغة وإقليمي لكل صفحة، تبدأ في رؤية تناقص العائدات ومشاكل الفهم العرضية. بالنسبة لإعدادنا 30 لغة، تحتوي كل صفحة على 31 إدخال hreflang (30 لغة + x-default)، وهو أقل بكثير من المنطقة الآمنة. إذا كنت تتعامل مع 50+ مزيج إقليمي ولغوي، فكر في استخدام فقط نهج Sitemap XML لإبقاء <head> قابلة للإدارة.

هل يجب أن أستخدم hreflang في رأس HTML أو Sitemap XML أو رؤوس HTTP؟ بالنسبة لتطبيقات Next.js، استخدم كل من <head> HTML و XML Sitemap. رؤوس HTTP مفيدة بشكل أساسي للموارد غير HTML مثل ملفات PDF. يتم معالجة <head> في وقت الزحف وتعطي أسرع إشارة. يعمل Sitemap كنسخة احتياطية ويساعد Google على اكتشاف صفحات بديلة لم تزحفها بعد. لا ننصح بالاعتماد على طريقة واحدة فقط.

ما هي تكلفة ترجمة موقع ويب كامل مع AI في 2025؟ باستخدام Claude Haiku، نترجم 118 صفحة عبر 41 مساحة ترجمة لحوالي $22 لكل لغة. بالنسبة لـ 30 لغة، هذا حوالي $660 إجمالي. أضف تسجيل جودة Winston AI بحوالي $50-100 لاستدعاءات API، ومراجعة بشرية اختيارية لصفحات عالية القيمة بـ $500-1,000، وتكون تكلفتك الإجمالية أقل من $2,000. قارن هذا بـ $699/شهر Weglot أو خدمات الترجمة الاحترافية بـ $5,000-10,000 لكل لغة.

لماذا نستخدم نظام البوابات ثنائي المستوى بدلاً من ترجمة كل شيء في نفس الوقت؟ تعامل Google محتوى رقيق كإشارة جودة سلبية يمكن أن تسحب مجال بأكمله. إذا أطلقت 30 لغة لكنك حصلت فقط على 15 بترجمات جودة، فإن تلك الـ 15 لغة المترجمة بشكل سيء تنشئ حوالي 1,770 صفحة منخفضة الجودة. يضمن نظام المستويين ثنائي أن فقط الصفحات التي تستوفي حد جودة 95%+ يتم فهرستها. اللغات تتخرج من المستوى 2 إلى المستوى 1 حيث تمر الترجمات بوابات الجودة، وحماية سلطة المجال طوال الطرح.

كيف أتعامل مع الصفحات غير المترجمة للغة مترجمة جزئياً؟ بالنسبة للمحليات حيث تتم ترجمة بعض مساحات الترجمة لكنها غير مترجمة، نعود إلى المحتوى الإنجليزي ونضيف علامة noindex عبر middleware. لا يزال عنوان URL يُحل (يمكن للمستخدمين الوصول إليه)، لكن Google لن تفهرس الصفحة ذات اللغات المختلطة. بمجرد أن تمر جميع مساحات الترجمة المطلوبة بوابات الجودة، يتم إزالة علامة noindex وإضافة إدخالات hreflang. هذا يمنع الترجمات الجزئية من تلويث الفهرس الخاص بك.

ما هو حد درجة الجودة الذي يجب أن أستخدمه لترجمات AI؟ نستخدم Winston AI مع حد جودة 95%+. أي شيء أقل من ذلك يُوضع علامة عليه للمراجعة البشرية أو إعادة الترجمة مع موجهات معدّلة. عملياً، يحقق Claude Haiku 95%+ على حوالي 85% من دفعات المساحة في المرة الأولى. عادة ما تفشل الـ 15% المتبقية بسبب المصطلحات الخاصة بالمجال (مصطلحات علم التنجيم التي لا تترجم بشكل مباشر) أو هياكل جمل معقدة. كان حد 90% سيسمح بعبارات محرجة بشكل ملحوظ.

هل يمكنني استخدام Astro بدلاً من Next.js لمواقع متعددة اللغات بـ hreflang؟ بالتأكيد. يحتوي Astro على دعم i18n ممتاز مدمج اعتباراً من Astro 4.0+، ونموذج الإنشاء الثابت الخاص به يبسط فعلاً تطبيق hreflang لأن جميع عناوين URL معروفة في وقت الإنشاء. بنينا مشاريع متعددة اللغات مع كلا الإطار العمل. بالنسبة للمواقع التي تحتوي على محتوى ديناميكي ثقيل ومسارات API (مثل 39 نقطة نهاية محلية Deluxe Astrology)، فإن Next.js هو البداية الأفضل. بالنسبة للمواقع الغنية بالمحتوى بتفاعل أقل، يمكن أن يكون تطوير Astro أسرع وأكثر أداءً. مبادئ hreflang متطابقة بغض النظر عن الإطار العمل.