سئوی بین‌المللی: ccTLD، زیرپوشه یا زیردامنه؟

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

گوگل واقعاً چه چیزی را مستند کرده است

راهنمای گوگل برای مدیریت سایت‌های چندمنطقه‌ای و چندزبانه چهار ساختار URL را مقایسه می‌کند. دامنه ویژه یک کشور (example.de) هدف‌گذاری جغرافیایی را بدون ابهام می‌کند، به محل سرور وابسته نیست و جدا کردن سایت‌ها را آسان می‌کند، اما ممکن است پرهزینه و گاهی دشوار برای تهیه باشد، زیرساخت بیشتری بخواهد، شرایط ثبت سخت‌گیرانه داشته باشد و فقط یک کشور را هدف بگیرد. زیردامنه روی دامنه عمومی (de.example.com) سریع راه‌اندازی می‌شود، محل‌های متفاوت سرور را مجاز می‌کند و سایت‌ها را جدا نگه می‌دارد، اما کاربران ممکن است از روی نشانی نفهمند «de» زبان است یا کشور. زیرپوشه (example.com/de/) چون یک میزبان را شریک است سریع و کم‌نگهداری است، اما هدف‌گذاری جغرافیایی برای کاربران کم‌تر دیده می‌شود، یک محل سرور به کار می‌رود و جدا کردن نسخه‌ها دشوارتر است. پارامترهای URL هم به‌عنوان روش توصیه‌نشده علامت خورده‌اند.

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

خواندن مبادله‌ها به‌عنوان محدودیت

راه مفید خواندن فهرست این است که آنها را محدودیت‌هایی بدانید که یا دارید یا ندارید. وقتی نسخه کشور باید عملیات جداگانه باشد، یعنی شخصیت حقوقی، میزبانی، ارز، کاتالوگ یا تیم محلی خودش را دارد، ccTLD انتخاب کنید. بهایش این است که هر دامنه سایتی مستقل است که باید نگهداری، ایمن، لینک‌سازی و پایش شود و یک دامنه فقط به یک کشور خدمت می‌کند. وقتی یک برند، یک تیم و یک CMS به چند بازار خدمت می‌کنند زیرپوشه انتخاب کنید؛ یک میزبان را نگه می‌دارید و برای سیگنال موقعیت به hreflang و محتوای بومی‌شده تکیه می‌کنید. زیردامنه را بیشتر وقتی انتخاب کنید که زیرساخت مجبورتان کند، مثلاً پلتفرم جداگانه برای هر بازار. در عمل به‌ندرت دلیلی مبتنی بر محتوا برای زیردامنه می‌بینیم.

قاعده تصمیم چهارسؤالی

1. آیا نسخه کشور باید عملیاتی جداگانه با شخصیت حقوقی، میزبانی، قیمت‌ها یا تیم خودش باشد؟ اگر بله، ccTLD (یا دست‌کم یک سایت جدا) مناسب است.
2. یک کشور را هدف می‌گیرید یا یک زبان را در چند کشور؟ زبانی که در چند کشور رایج است روی یک ccTLD جا نمی‌گیرد و این به زیرپوشه‌های زبانی اشاره دارد.
3. آیا تیم شما می‌تواند چند دامنه را با گواهی‌ها، تحلیل‌ها، ویژگی‌های Search Console و پروفایل لینک‌های جداگانه نگه دارد؟ اگر نه، راه‌اندازی چنددامنه‌ای با گذر زمان فرسوده می‌شود.
4. آیا پلتفرم شما ساختار URL را ثابت می‌کند، مثلاً یک پشته جدا برای هر بازار؟ آن‌گاه زیردامنه ممکن است گزینه واقع‌بینانه باشد.

اگر هیچ‌کدام از این چهار صدق نکرد، پیش‌فرض را یک زیرپوشه برای هر زبان (یا زبان و کشور) روی یک دامنه بگذارید. ترتیب مهم است: نیازهای جداسازی اول می‌آیند چون همان‌هایی هستند که بعداً نمی‌توانید درباره‌شان چانه بزنید.

یک مثال کاربردی

کسب‌وکاری را در نظر بگیرید با مخاطبان ترکی، انگلیسی، عربی و فارسی، یک تیم، یک CMS و بدون شخصیت حقوقی جدا برای هر کشور. پرسش اول: خیر. پرسش دوم: زبان‌هایی در چند کشور، پس هیچ ccTLD واحدی نمی‌تواند به همه خدمت کند. پرسش سوم: تیم کوچک، پس چند دامنه بار اضافه است. پرسش چهارم: CMS از پوشه‌ها پشتیبانی می‌کند. پاسخ زیرپوشه‌های زبانی است که ساختار سایت خود ما هم همین است: انگلیسی زیر /en/، عربی زیر /ar/، فارسی زیر /fa/ و ترکی در ریشه. گروهی که در آلمان شخصیت حقوقی ثبت‌شده، انبار و قیمت‌گذاری دارد به پرسش اول پاسخ دیگری می‌دهد و می‌تواند یک دامنه آلمانی را توجیه کند.

پیش از تعهد: یک چک‌لیست کوتاه

• هر بازار را به یک زبان، یک ارز و یک مالک حقوقی نگاشت کنید و یادداشت کنید کجا تفاوت دارند.
• تصمیم بگیرید hreflang کجا باشد: برچسب‌های HTML، هدرهای HTTP یا نقشه سایت XML. گوگل این سه را هم‌ارز می‌داند، پس آن را انتخاب کنید که می‌توانید یکدست نگه دارید.
• صفحه جایگزین را برای بازدیدکنندگانی که زبانشان با هیچ نسخه‌ای نمی‌خواند (x-default) تعریف کنید، که معمولاً یک انتخابگر زبان است.
• تصمیم ساختار و دلایلش را بنویسید تا هر انتقال بعدی بر پایه محدودیت‌ها بحث شود نه سلیقه.

آنچه این انتخاب حل نمی‌کند

ساختار URL فقط تعیین می‌کند نسخه‌ها کجا قرار دارند. hreflang را درست نمی‌کند و محتوا را خوب ترجمه نمی‌کند و بیشتر مشکلات عملی همان‌جا پیش می‌آید؛ فهرست ما از رایج‌ترین خطاهای hreflang نشان می‌دهد چگونه پیدا می‌شوند. تغییر ساختار در آینده یک مهاجرت سایت با نقشه ریدایرکت است، پس ارزش دارد یک بار با دقت تصمیم بگیرید. جنبه فنی این کار در خدمت سئوی فنی ما قرار دارد و تصویر گسترده‌تر ورود به بازارها در خدمت سئوی بین‌المللی و نمای کلی خدمات.

منابع

• Google Search Central — Managing multi-regional and multilingual sites: گزینه‌های ساختار URL، هدف‌گذاری جغرافیایی و hreflang.
• Google Search Central — Localized versions of your pages: hreflang، x-default، پیوندهای متقابل و روش‌های پشتیبانی‌شده.