تشخیص زبان مبتنی بر لبه با استفاده از هدر Accept-Language برای ثبات سئو

وب‌سایت‌هایی که مخاطبانشان را در چندین زبان هدف می‌گیرند، دائماً بین ارائه نسخهٔ صحیح زبان به بازدیدکنندگان انسانی و فراهم کردن ساختاری پیش‌بینی‌پذیر برای خزنده‌های موتورهای جستجو تعادلی برقرار می‌کنند. مذاکرهٔ زبانی سنتی در سمت سرور می‌تواند باعث افزایش زمان تاخیر، افزودن پیچیدگی به لایه‌های کش و گاهی اوقات تولید URLهای نامنسجمی شود که موتورهای جستجو را دچار سردرگمی می‌کند.

استقرار تشخیص زبان در لبه—در جایی که درخواست برای اولین بار با شبکه توزیع محتوا (CDN) مواجه می‌شود—یک جایگزین سبک، با تأخیر کم ارائه می‌دهد. با خواندن هدر Accept‑Language (AL)، یک تابع لبه می‌تواند تصمیم بگیرد که کدام نسخهٔ محلی‌سازی‌شده را سرویس دهد، URL درخواست را بازنویسی کند یا به دارایی مخصوص به زبان هدایت شود. وقتی به‌درستی انجام شود، این رویکرد منجر به داشتن یک URL متمایز و کاننیکال برای هر زبان، نشانه‌گذاری‌های hreflang سازگار و پاسخ‌های قابل کش می‌شود که با سیاست‌های TTL CDN هم‌خوانی دارند.

در این مقاله اجزای اساسی یک لوله‌کشی تشخیص زبان مبتنی بر لبه را مرور می‌کنیم، طراحی کلید کش را بررسی می‌کنیم، مکانیزم‌های بازگشت را کاوش می‌کنیم و گام‌های پیاده‌سازی سازگار با سئو را بیان می‌کنیم.

چرا پردازش زبان در لبه؟

پردازش زبان در لبه برای سئو چندزبانه سه مزیت اصلی دارد:

1. کاهش زمان رفت‌وآمد – مکان‌های لبه به‌صورت جغرافیایی به کاربران نزدیک‌تر هستند، به‌طوری که گام اولیهٔ مذاکرهٔ زبانی زمان کمتری می‌گیرد.
2. کارایی کش – با ترکیب تصمیم زبانی در کلید کش، محتوای یکسان می‌تواند یک‌بار برای هر گونهٔ زبانی ذخیره شود و از تمایل هدر «Vary: Accept‑Language» برای عبور از کش CDN جلوگیری می‌کند.
3. URLهای پیش‌بینی‌پذیر – بازنویسی‌های لبه می‌توانند یک درخواست عمومی (example.com) را به مسیر خاص زبان (example.com/en/) نگاشت کنند و ساختار URL ایستا که موتورهای جستجو ترجیح می‌دهند را حفظ نمایند.

این مزایا به‌صورت مستقیم به بهبود Core Web Vitals، کاهش نرخ پرش و ارائه یک سیگنال واضح‌تر برای خزیدن موتورهای جستجو منجر می‌شوند.

ترکیب جریان درخواست لبه

نمودار زیر (Mermaid) یک جریان معمولی از مرورگر کاربر تا تابع لبه، از طریق تشخیص زبان، و در نهایت تا سرور منبع یا پاسخ کش‌شده را نشان می‌دهد.

  flowchart TD
    A["Client Browser"] --> B["Edge Node (CDN)"]
    B --> C["Read Accept-Language Header"]
    C --> D{"Supported Language?"}
    D -- Yes --> E["Map to Language Path"]
    D -- No --> F["Apply Fallback Logic"]
    E --> G["Construct Cache Key (URL + Lang)"]
    F --> G
    G --> H{"Cache Hit?"}
    H -- Hit --> I["Serve Cached Variant"]
    H -- Miss --> J["Fetch From Origin"]
    J --> K["Store Variant in Cache"]
    K --> I
    I --> L["Response to Client"]

این نمودار دو نقطه تصمیم‌گیری را برجسته می‌کند: تأیید اینکه زبان درخواست‌شده پشتیبانی می‌شود و مدیریت کش هیت در مقابل میس. هر شاخه به یک URL معین که می‌تواند توسط موتورهای جستجو ایندکس شود، منتهی می‌شود.

طراحی کلید کش

یک کلید کش خوب، ریشهٔ یک راه‌حل مبتنی بر لبه است. این کلید باید شامل موارد زیر باشد:

• مسیر نرمال‌شدهٔ درخواست (مثلاً /products/123/).
• کد زبان حل‌شده (مثلاً en، fr، es).

یک قالب معمولی برای کلید کش به شکل /<language>/<path> است. برای مثال، درخواست برای /products/123/ با هدر AL که نشان‑دهندهٔ زبان فرانسوی (fr) است، کلید /fr/products/123/ را تولید می‌کند.

از استفاده از هدر Vary برای زبان خودداری کنید زیرا بسیاری از CDNها Vary: Accept-Language را به‌عنوان یک عبور از کش در نظر می‌گیرند و در نتیجه کش لبه غیرفعال می‌شود. با درج مستقیم زبان در کلید کش، قابلیت سرویس‌دهی CDN به نسخه‌های کش‌شده برای هر زبان حفظ می‌شود.

پیاده‌سازی تابع لبه

در زیر یک مثال شبه‌کد برای یک زمان‌ chạy لبه عمومی (مانند Cloudflare Workers، Fastly Compute@Edge یا AWS Lambda@Edge) آورده شده است. منطق به‌طور عمدی بدون وابستگی به زبان خاصی نوشته شده و می‌تواند در هر runtime سازگار با JavaScript استفاده شود.

export async function handle(event) {
  const request = event.request
  const url = new URL(request.url)

  // 1. استخراج هدر Accept-Language
  const acceptLang = request.headers.get('Accept-Language') || ''
  
  // 2. تجزیه هدر به لیستی مرتب از برچسب‌های زبانی
  const languages = parseAccept