معماری سئوی چندزبانه برای کلینیکها: خطاهای hreflang در TR/EN/AR و پلیبوک اصلاح
رایجترین خطاهای hreflang در سایت کلینیکهای ترکی/انگلیسی/عربی، تعارضهای canonical و ترتیب درست اصلاح با یک منبع حقیقت واحد.
نوشته Roozbeh Nazari · CEO
سایت کلینیکی که بیمار بینالمللی هدف گرفته، معمولاً دستکم به سه زبان منتشر میکند: ترکی، انگلیسی و عربی؛ و اغلب روسی یا فارسی هم اضافه میشود. این تنوع با معماری درست یک قوت است و با معماری غلط یک زیان خاموش: صفحههای عربی که هرگز ایندکس نمیشوند، صفحه انگلیسی که در نتایج عربی میآید، یا دو زبانی که ترافیک هم را میخورند — نشانههایی که معمولاً به یک ریشه برمیگردند. این مقاله سه چیز را به ترتیب بررسی میکند: تصمیمهای معماری، خطاهای hreflang که در میدان بیش از همه میبینیم، و ترتیبی که باید با آن اصلاحشان کرد.
از تصمیم معماری شروع کنیم. برای بیشتر کلینیکها پیشفرض درست، زیرشاخههای زبانی زیر یک دامنه است: /tr/، /en/، /ar/. یک دامنه، اعتبار کسبشده را به همه زبانها منتقل میکند و زیرساخت را یکجا نگه میدارد. دامنههای کشوری ccTLD سیگنال محلی قوی میفرستند اما هر دامنه باید اعتبارش را از صفر بسازد؛ سابدامنهها هم بار مدیریت را زیاد و مزیت تجمیع را کم میکنند. کد زبان در URLها باید یکدست باشد؛ نوشتن اسلاگ عربی و فارسی با خط خودشان مشکلی ندارد — مرورگرها آن را با درصدنگاری منتقل میکنند. مهم این است که هر صفحه فقط یک شکل canonical داشته باشد. اگر سایت موجودی را به این ساختار منتقل میکنید، تغییر URL را یک پروژه مهاجرت مستقل بدانید: جابجایی بدون نقشه یکبهیک ریدایرکت 301 برای هر زبان، ممکن است بهای دستاورد معماری را با ماهها افت رتبه بپردازد.
کار hreflang اتصال نسخههای زبانی و منطقهای یک محتواست؛ یک سیگنال است، نه فرمان. نحو آن ساده به نظر میرسد اما ترکیب دو استاندارد است: ISO 639-1 برای زبان و بهصورت اختیاری ISO 3166-1 Alpha-2 برای منطقه. «ar» همه کاربران عربزبان را هدف میگیرد؛ «ar-AE» فقط کاربران عربزبان امارات را. رایجترین خطای مفهومی، زبان پنداشتن کد کشور است: زبانی به نام «ae» وجود ندارد و چنین تگی بیسروصدا نادیده گرفته میشود.
خطاهایی که بیش از همه به آنها برمیخوریم: اول، نبودن تگ برگشت — صفحه ترکی به نسخه عربی اشاره میکند اما صفحه عربی به ترکی اشاره نمیکند؛ Google این جفت را نامعتبر میشمارد و این رفتار مستند است. دوم، اشاره hreflang به ریدایرکت، 404 یا صفحه noindex؛ وقتی بدیل در دسترس نیست، اتصال کار نمیکند. سوم، تعارض canonical با hreflang؛ اینکه همه زبانها را به نسخه ترکی canonical کنید و در hreflang بدیل اعلام کنید، همزمان به Google میگوید «اینها صفحههای جدا هستند» و «همه در واقع یک صفحهاند». چهارم، URL نسبی؛ مقادیر hreflang باید مطلق باشند. پنجم، نبود x-default. ششم، قالبی که برای ترجمههای ناموجود هم تگ میزند؛ اگر صفحهای نسخه عربی ندارد، نباید بدیل عربی اعلام شود.
x-default و تقسیم عربی دقت بیشتری میخواهند. x-default نسخهای را مشخص میکند که وقتی هیچ زبانی مطابقت ندارد نمایش داده شود؛ اگر صفحه انتخاب زبان دارید همان را نشان دهید، وگرنه نسخه انگلیسی معمولاً انتخاب معقولی است. واکنش رایج در عربی، بازکردن نسخهای جدا برای هر کشور حاشیه خلیج است: ar-SA، ar-AE، ar-KW و ادامه. اگر محتوا واقعاً فرق نمیکند — یعنی قیمت، راه ارتباطی یا مقررات بر اساس کشور عوض نمیشود — تجمیع در یک نسخه «ar» هم بار نگهداری و هم خطر رقابت با خودتان را کم میکند. همین منطق برای فارسیای که بعداً اضافه میکنید هم برقرار است: با یک «fa» شروع کنید. نسخه منطقهای را فقط وقتی باز کنید که تفاوت محتوایی واقعی و ظرفیت نگهداریاش را دارید؛ هر نسخهای که باز میکنید، ردیف تازهای در ماتریس hreflang است که نگهداریاش بر عهده شماست.
اینکه hreflang را کجا بگذارید هم یک تصمیم است: تگهای link در head یا در XML sitemap. هر دو معتبرند؛ مشکل وقتی شروع میشود که هر دو را با هم به کار بگیرید. دو منبع به مرور از هم فاصله میگیرند و سیگنالهای متعارض، پردردسرترین دسته خطاها را میسازند. یک منبع حقیقت انتخاب کنید: در سایت کلینیکی معمولی با چندصد صفحه، مدیریت در head ساده است؛ وقتی تعداد صفحهها به هزارها رسید، سمت sitemap راحتتر خودکار میشود.
برای کشفشدن، hreflang بهتنهایی کافی نیست؛ نسخههای زبانی باید با لینکهای معمولی هم به هم وصل باشند. انتخابگر زبان در هدر یا فوتر باید با تگهای a قابل خزش ساخته شود، نه منوی JavaScript بدون href؛ هر صفحه باید به بدیلهای خودش لینک واقعی بدهد. در سمت sitemap هم URL همه زبانها باید کامل فهرست شود؛ چه برای هر زبان فایل جدا داشته باشید چه یک فایل واحد، مطمئن شوید همه به Search Console ارسال شدهاند. کوتاهترین راه برای سپردن کشف یک نسخه زبانی به شانس این است که تنها مسیر رسیدن به آن، یک منوی کرکرهای غیرقابل خزش باشد.
در سمت تشخیص باید ابزار درست انتخاب کنید، چون Search Console دیگر مثل گذشته کمکی نیست: گزارش International Targeting در سال 2022 حذف شد و GSC امروز صفحهای که خطاهای hreflang را مستقیم گزارش کند ندارد. روش عملی، استفاده از خزندهای مثل Screaming Frog و گزارشهای hreflang آن است تا تگهای برگشت ناقص، بدیلهای دردسترسنبوده و تعارضهای canonical بیرون کشیده شود؛ بعد صفحههای مشکوک با URL Inspection تأیید شوند. ترتیب اصلاح مهم است: اول canonicalها را همراستا کنید، بعد تگهای برگشت را کامل کنید، و در آخر x-default را اضافه کنید. اگر برعکس بروید، هر اصلاح ممکن است قبلی را پنهان کند. در Screaming Frog مشخصاً سه گزارش را ببینید: تگهای برگشت ناقص، URLهای hreflang که پاسخی غیر از 200 میدهند، و کدهای زبان پشتیبانینشده. این سهتایی بیشتر خطاهایی را که در میدان میبینیم در یک خزش بیرون میآورد؛ باقی معمولاً در همراستایی canonical و منطق قالب پنهان است.
سیگنالهای کیفیت زبان هم به اندازه اتصال فنی، بخشی از معماریاند. در هر نسخه مقدار html lang باید درست باشد و در صفحههای عربی و فارسی dir="rtl" به کار رود؛ صفحههای عربی نیمهترجمه با منوی انگلیسی، هم اعتماد کاربر و هم سیگنال اینکه صفحه به کدام زبان خدمت میکند را ضعیف میکنند. صفحههای ترجمه ماشینی که هیچ ویراستاری ندیدهاند، در حوزههای YMYL مثل سلامت ریسک مضاعف دارند؛ چارچوب ارزیابی کیفیت Google در این حوزه به اعتمادپذیری سختگیرانهتر نگاه میکند. اگر بودجه ترجمه محدود است، خوب ترجمهکردن صفحات کم همیشه بهتر از بد ترجمهکردن صفحات زیاد است. برای سنجش کیفیت ترجمه یک روتین ساده کافی است: هر فصل، چند صفحه تصادفی از هر زبان را به یک گویشور بومی بدهید بخواند و یادداشتهای اصلاحی را به تقویم محتوا برگردانید.
یک یادداشت میدانی آخر: این پلیبوک کاری نیست که یک بار اجرا و بسته شود. با اضافهشدن صفحات خدمات، مطالب بلاگ و صفحات کمپین، خطاها برمیگردند؛ توصیه ما ممیزی کامل فصلی و در فاصله آن، کنترل نقطهای صفحات تازهمنتشرشده است. در خدمات سئوی تکنیکال SEO Evaluate ممیزی چندزبانه بخشی از دامنه استاندارد است؛ hreflang، canonical و لایه ایندکس را در یک گذر بررسی میکنیم، چون این سه وقتی جداجدا اصلاح شوند معمولاً همدیگر را خراب میکنند. خروجی ممیزی را هم به یک فهرست تغییرات مکتوب گره بزنید: کدام تگ در کدام صفحه عوض شد، چه کسی تأیید کرد، کی لایو رفت. این سابقه در ممیزی بعدی در چند دقیقه نشان میدهد دقیقاً چه چیزی پسرفت کرده.