سئو عربی کلینیک دندان: رفتار جستوجو در خلیج
برای بیماران حوزه خلیج، انتشار نسخه عربی کافی نیست: لهجه، نگارش لاتین و الگوهای پرسشی رفتار جستوجو را چطور تغییر میدهند؟
نوشته Roozbeh Nazari · CEO
رایجترین حرکت در کلینیکهای دندانپزشکیای که بیمار را از کشورهای حوزه خلیج جذب میکنند این است: سایت ترکی را به عربی ترجمه میکنند، زیر مسیر /ar/ میگذارند و منتظر نتیجه میمانند. صفحهها منتشر میشوند، hreflang درست است، در لایه فنی هم ایرادی دیده نمیشود — اما ترافیک نمیآید، یا ترافیکی که میآید تبدیل نمیشود.
دلیلش معمولاً کیفیت ترجمه نیست. دلیلش این است که رفتار جستوجو در زبان عربی معادل یکبهیکِ رفتار جستوجو در زبان ترکی نیست. این نوشته توضیح میدهد رفتار جستوجو در بازار کشورهای شورای همکاری خلیج (عربستان، امارات، قطر، کویت، بحرین و عمان) دقیقاً از کجا جدا میشود و این تفاوت روی خودِ صفحه باید چه معادلی پیدا کند.
عربی یک زبان جستوجوی واحد نیست
اولین تفکیکی که هنگام تولید محتوای عربی با آن روبهرو میشوید، فاصله میان زبان نوشتار و زبان گفتار است. عربی فصیح معاصر (MSA) زبان محتوای مکتوب است، اما مردم همیشه فصیح را در کادر جستوجو تایپ نمیکنند. عبارتهای لهجه خلیجی بیشتر در کوئریهای دمدراز که به زبان محاوره نزدیکاند خود را نشان میدهند.
روی این لایه، لایه دیگری هم مینشیند: عربی نوشتهشده با حروف لاتین (عربیزی) و کاربرد اصطلاحهای انگلیسی در دل جمله عربی. در عمودی دندانپزشکی این موضوع خیلی پررنگ است — اصطلاحهایی مثل «Hollywood smile»، «veneer» و «implant» بیشتر وقتها به همان شکل انگلیسی داخل کوئریهای عربی میآیند.
نتیجه عملی: خودتان را به یک مجموعه اصطلاح واحد قفل نکنید. متن صفحه را بر پایه فصیح بنویسید، اما در تیترها و بخش پرسشهای پرتکرار به گونههایی که مردم واقعاً به کار میبرند جا بدهید. عربیسازی اجباری یک گونه، رشته ارتباط با کسی را که با همان گونه جستوجو میکند پاره میکند.
ساختار کوئری: الگوهای پرسشی و وزن قیمت
در کوئریهای بازار خلیج دو الگو به چشم میآید و هر دو مستقیماً بر ساختار صفحه اثر میگذارند.
اول، وزن الگوهای پرسشی. کوئریهای عربی بیش از کوئریهای ترکی به پرسشهای جملهکامل تکیه میکنند: «چند»، «چطور»، «چقدر طول میکشد»، «درد دارد؟». یعنی قالب پرسش و پاسخ در صفحه تزئینی نیست، کارکردی است. هر پرسش باید یک تیتر باشد و هر پاسخ باید در دو جمله نخست کامل شده باشد.
دوم، اینکه کوئریهای قیمت و فرایند زودتر از آنچه انتظار دارید سر میرسند. بیماری که برای درمان به خارج سفر میکند، پیش از انتخاب کلینیک میخواهد تکلیف هزینه کل و لجستیک سفر را روشن کند. صفحهای که اطلاعات قیمت را پشت «با ما تماس بگیرید» پنهان میکند، خواننده این مرحله را نگه نمیدارد.
اینجا مرز مقرراتی مهم است: شفافیت قیمت به معنای وعده نتیجه یا ادعای برتری نیست. نوشتن متغیرهایی که قیمت را تعیین میکنند — پیچیدگی مورد، جنس متریال، تعداد جلسهها، اینکه اقامت در قیمت هست یا نه — هم با مقررات سازگار است و هم دقیقاً همان اطلاعاتی است که خواننده دنبالش میگردد.
ترجمه نکنید، معادل بسازید
ترجمه صفحه ترکی به عربی با نوشتن صفحه برای خواننده عربزبان دو کار متفاوتاند. تفاوت در چند نقطه مشخص خود را نشان میدهد:
- عناصر اعتماد عوض میشوند. برای خواننده ترک، سابقه تخصصی پزشک جلو میافتد؛ برای بیماری که از خلیج میآید، مدیریت فرایند — استقبال فرودگاهی، مترجم، اقامت، پیگیری پس از درمان — اغلب دستکم به اندازه خود درمان تعیینکننده است.
- چارچوب مرجع عوض میشود. نام شهرهای ترکیه، نشانی محلهها یا نام نهادهای محلی برای خواننده عربزبان معنایی ندارد. توضیح موقعیت بر پایه مدت پرواز و نزدیکی به فرودگاه بهمراتب کارراهاندازتر است.
- کانال ارتباطی عوض میشود. انتظار تماس بیشتر روی واتساپ است تا فرم. اینکه این کانال را چطور به اندازهگیری وصل کنید، در نوشته زنجیره انتساب از واتساپ تا رزرو به تفصیل آمده است.
- تقویم عوض میشود. ماه رمضان و ایام عید هم حجم جستوجو و هم رفتار برنامهریزی درمان را جابهجا میکنند. بستن تقویم محتوا بر اساس تقویم ترکیه یعنی از دست دادن همین موج.
به همین دلیل باید نسخه عربی را مثل یک صفحه مستقل ببینید: همان معماری اطلاعات، اما ترتیب تأکید متفاوت و مجموعه شواهد متفاوت. اینکه این تفکیک را در عمودی کلینیک چطور بنا کردهایم، در صفحه کلینیکها قابل مشاهده است.
RTL و لایه فنی
نسخه عربی از راست به چپ نوشته میشود و این فقط یک تصمیم CSS نیست.
- lang="ar" و dir="rtl" باید روی عنصر درست تعریف شوند. دادن direction فقط روی body، سیگنال زبانی لازم را برای صفحهخوانها و موتورهای جستوجو تولید نمیکند.
- متن دوجهته (اصطلاح انگلیسی یا عدد در دل جمله عربی) بدون تنظیم درست جهت، خراب رندر میشود. این یک مشکل خوانایی واقعی روی صفحه است، نه مسئلهای صرفاً ظاهری.
- اسلاگهای عربی در percent-encoding بهسرعت بزرگ میشوند: هر حرف عربی پس از کدگذاری شش کاراکتر جا میگیرد. اسلاگ کوتاه و معنادار انتخاب کنید؛ تبدیل عنوان بلند به اسلاگ به همان شکل، URLهایی میسازد که به سقف prerender میخورند.
- hreflang باید دوطرفه باشد و هر نسخه باید به خودش هم ارجاع بدهد. مستندات خود گوگل این دو شرط را صریحاً لازم میداند.
- بر اساس IP یا زبان مرورگر ریدایرکت خودکار نگذارید. اینکه چرا این کار زیانبار است و چطور باید تستش کرد، در نوشته ریدایرکت خودکار زبان توضیح دادهایم.
ساختار صفحهها: کدام صفحهها باید عربی منتشر شوند
ترجمه کل سایت به عربی برای بیشتر کلینیکها نه لازم است و نه پایدار. هزینه ترجمه یک بار پرداخت میشود، اما هزینه بهروز نگه داشتن با هر تغییر محتوا تکرار میشود. نسخه عربیِ نیمهبهروز از نسخه نداشتن هم زیانبارتر است: همان لحظه که اطلاعات قیمت، فرایند یا تیم با نسخه ترکی تناقض پیدا کند، اعتماد خواننده یکجا میرود.
یک ترتیب اولویت عملی میتواند این باشد:
- اول صفحههای درمان. بخش بزرگی از جستوجویی که از خلیج میآید از مسیر نام درمان میآید؛ صفحههایی مثل ایمپلنت، روکش و طراحی لبخند بدون معادل عربی نمیتوانند این ترافیک را پاسخ بدهند.
- بعد صفحه فرایند و لجستیک. سفر، اقامت، تعداد روز ماندن، پشتیبانی مترجم و پیگیری پس از درمان؛ این یک صفحه اغلب به اندازه صفحههای درمان بازدید میگیرد.
- بعد صفحه منطق قیمت. مجبور نیستید عدد بدهید؛ توضیح متغیرهایی که قیمت را تعیین میکنند، پرسش خواننده این مرحله را پاسخ میدهد.
- در آخر محتوای بلاگ. بلاگ در نسخه عربی معمولاً کمبازدهترین لایه است؛ اختصاص بودجه به آن پیش از تکمیل سه لایه اول، ترتیب را عوض نمیکند.
این ترتیب در عین حال یک ترتیب اندازهگیری هم هست: هر لایه را که منتشر کردید، به کیفیت ترافیک ورودی نگاه کنید و بعد سراغ لایه بعدی بروید. این الگوی سرمایهگذاری امنتر از ترجمه یکباره کل سایت و بیخبر ماندن از نتیجه است.
رقابت فرق دارد: بدانید با چه کسی میجنگید
در کوئریهای ترکی رقیب شما به احتمال زیاد یک کلینیک ترک دیگر است. در کوئریهای عربی اما سه نوع بازیگر متفاوت در نتایج حضور دارند و هرکدام با ضعف متفاوتی میآیند.
اول، کلینیکهای ترک دیگری که همان هدف را دنبال میکنند. محتوایشان اغلب با همان بازتاب ترجمهای تولید شده است؛ زمین تمایز اینجا شفافیت فرایند و عمق واقعی پرسش و پاسخ است.
دوم، سایتهای واسطه و پلتفرمها. این سایتها پوشش وسیعی دارند اما سطحیاند؛ محتوایی که به جزئیات یک درمان مشخص وارد شود تولید نمیکنند. عمق تنها تمایزی است که مقابلشان کار میکند.
سوم، کلینیکهای محلی در کشور هدف. مزیت نزدیکی با آنهاست؛ مزیت شما باید گستره خدمات و مدیریت فرایند باشد، نه هزینه — چون ادعای برتری از راه قیمت هم از نظر مقررات مسئلهساز است و هم جایگاهسازی پایداری نیست.
به همین دلیل انجام تحلیل رقبا روی SERP ترکی و بعد تعمیم آن به نسخه عربی گمراهکننده است. تصمیمهای محتوایی که بدون نگاه کردن به صفحه نتایج کشور هدف گرفته میشوند، صفحههایی میسازند که برای رقیب اشتباه بهینه شدهاند.
اندازهگیری: بدانید کدام ترافیک از کدام نسخه آمده است
اگر نمیبینید نسخه عربی کار میکند یا نه، یعنی تصمیم سرمایهگذاری را با شهود میگیرید.
خطای کلاسیک اینجا اعتماد به بُعد آماده Language در GA4 است. آن بُعد زبان مرورگر کاربر را میسنجد، نه اینکه کاربر کدام نسخه سایت را دیده است. وقتی کاربری از عربستان با مرورگر انگلیسی از صفحه عربی شما بازدید میکند، بُعد آماده آن بازدید را عربی گزارش نمیکند.
راهحل، ساختن یک custom dimension در سطح رویداد است که نسخه صفحه را صریحاً بفرستد، و خواندن قیف از روی همین بُعد. جزئیات راهاندازی را قدمبهقدم در نوشته تحلیل قیف بر پایه locale در GA4 نوشتهایم.
باید بتوانید دستکم به سه پرسش پاسخ بدهید: کاربرانی که وارد صفحههای عربی میشوند از کدام کشورها میآیند، در کدام صفحه سایت را ترک میکنند، و نرخ تبدیل به تماس واتساپیشان چه تفاوتی با نسخه ترکی دارد. اگر این سه پاسخ نباشد، حکم «سئو عربی جواب نمیدهد» یک حدس است، نه یک مشاهده.
اگر بخواهید راهاندازی را با هم پیش ببریم، کار ما در تحلیل داده دقیقاً از همینجا شروع میشود: قابل پاسخ کردن این پرسشها.