نشانه‌گذاری hreflang در کد صفحه — یک چیز است و آنچه که واقعاً بازدیدکننده‌ای از آلمان، لهستان یا برزیل دریافت می‌کند — کاملاً متفاوت است. گوگل می‌تواند تگ‌ها را نادیده بگیرد، CDN ممکن است به مکان نادرستی ریدایرکت کند و سرور — نسخه نادرستی را بر اساس IP ارائه دهد. تنها راه اطمینان از اینکه همه چیز به درستی کار می‌کند — بررسی وب‌سایت به صورت «زنده» از کشورهای مختلف است، نه اینکه به نشانه‌گذاری روی کاغذ اعتماد کنیم.
hreflang چیست و چرا تگ‌ها در کد کافی نیستند
hreflang یک ویژگی است که به موتورهای جستجو می‌گوید کدام نسخه زبانی یا منطقه‌ای از صفحه برای کدام کاربران طراحی شده است. از نظر فنی، این به صورت مجموعه‌ای از لینک‌ها در <head> یا در sitemap.xml ظاهر می‌شود، جایی که هر صفحه به نسخه‌های جایگزین خود اشاره می‌کند: ru-RU، en-US، de-DE و غیره.
مشکل این است که بررسی از طریق اعتبارسنجی کد (Screaming Frog، Ahrefs، Semrush) فقط آنچه را که در نشانه‌گذاری نوشته شده نشان می‌دهد. این به سوال اصلی پاسخ نمی‌دهد: وقتی یک شخص زنده از ورشو یا مادرید وب‌سایت شما را باز می‌کند، واقعاً چه اتفاقی می‌افتد؟ آیا ریدایرکت به محلی مناسب فعال می‌شود؟ آیا CDN کاربر را به نسخه انگلیسی به دلیل کش هدایت می‌کند؟ آیا geo-IP به درستی کشور را شناسایی می‌کند، اگر کاربر از طریق اپراتور موبایل وارد شود؟
برای بازاریاب‌ها و متخصصان SEO که وب‌سایت‌های چند منطقه‌ای، لندینگ‌پیج‌های مختلف یا کمپین‌های تبلیغاتی در Google Ads و Facebook Ads برای کشورهای خاص را آزمایش می‌کنند، این موضوع حیاتی است. اگر hreflang به درستی تنظیم نشده باشد، کاربر از کشور مورد نظر ممکن است نسخه نادرستی از وب‌سایت را ببیند، تبدیل را از دست بدهد و موتور جستجو — URL نادرستی را در نتایج این کشور ایندکس کند.
چرا hreflang «دروغ می‌گوید»: 5 دلیل متداول
در عمل، تفاوت بین نشانه‌گذاری و رفتار واقعی وب‌سایت به چند دلیل ایجاد می‌شود و بیشتر آنها را نمی‌توان فقط با نگاه کردن به کد صفحه شناسایی کرد.
- ریدایرکت Geo-IP hreflang را نادیده می‌گیرد. سرور کشور را بر اساس IP شناسایی کرده و به طور اجباری به محلی ریدایرکت می‌کند، حتی اگر کاربر به وضوح نسخه زبانی دیگری را از طریق لینک مستقیم باز کرده باشد.
- CDN کش‌کننده نسخه قدیمی را ارائه می‌دهد. Cloudflare یا دیگر CDNها ممکن است HTML را بدون توجه به کشور درخواست کش کنند و همه کاربران یک نسخه یکسان را دریافت می‌کنند، صرف‌نظر از جغرافیا.
- عدم تطابق کدهای زبان و منطقه. در نشانه‌گذاری
enذکر شده، در حالی که بایدen-GBوen-USبه طور جداگانه ذکر شوند — در نتیجه کاربران از بریتانیا و ایالات متحده یک نسخه را می‌بینند. - عدم وجود تگ خودارجاعی. صفحه به خود در لیست hreflang اشاره نمی‌کند، به همین دلیل گوگل ممکن است نشانه‌گذاری را به عنوان معتبر در نظر نگیرد.
- متغیرهای مختلف URL با www و بدون آن، http و https. تگ‌ها به یک پروتکل اشاره می‌کنند، در حالی که سرور واقعاً ریدایرکت را به دیگری ارائه می‌دهد، که زنجیره بررسی را خراب می‌کند.
همه این مشکلات فقط در زمان ورود واقعی با IP کشور مورد نظر بروز می‌کنند. بنابراین تنها راه مطمئن برای آزمایش — شبیه‌سازی بازدیدکننده‌ای از هر کشور هدف و مشاهده آنچه که وب‌سایت واقعاً ارائه می‌دهد.
برای بررسی از 10 کشور چه چیزی لازم است
برای بررسی hreflang به صورت «زنده»، باید به صورت فیزیکی یا برنامه‌نویسی IP آدرس از هر کشور هدف را دریافت کرده و ببینید که سرور کدام نسخه وب‌سایت را به این IP ارائه می‌دهد. برای این کار سه روش عملی وجود دارد:
- سرورهای پروکسی با وابستگی جغرافیایی به کشور مورد نظر — انعطاف‌پذیرترین و مقیاس‌پذیرترین روش، مناسب برای بررسی دستی و همچنین اتوماسیون.
- مرورگرهای ضد شناسایی (Dolphin Anty، AdsPower، Multilogin، GoLogin، Octo Browser) — زمانی که نیاز به حفظ پروفایل‌های جداگانه مرورگر برای هر کشور و مقایسه بصری بدون سردرگمی در کوکی‌ها و کش دارید، راحت هستند.
- ابزارهای خط فرمان (curl، httpie) با پروکسی — برای بررسی سریع HTTP headers، ریدایرکت‌ها و پاسخ‌های سرور بدون بارگذاری رابط کاربری.
برای آزمایش hreflang از 10 کشور، بهترین گزینه‌ها پروکسی‌های مسکونی هستند — آنها از IP کاربران واقعی کشور خاص استفاده می‌کنند، بنابراین سرویس‌های geo-IP و CDN آنها را مانند یک بازدیدکننده عادی وب‌سایت شناسایی می‌کنند. پروکسی‌های دیتاسنتر گاهی اوقات در لیست سیاه سرویس‌های جغرافیایی قرار می‌گیرند و ممکن است نتیجه نادرستی ارائه دهند، زمانی که سرور آنها را نه بر اساس کشور اعلام شده، بلکه به عنوان «دیتاسنتر، کشور ناشناخته» شناسایی می‌کند.
تنظیم پروکسی در مرورگر ضد شناسایی
عملی‌ترین روش برای بازاریاب بدون مهارت‌های برنامه‌نویسی — ایجاد پروفایل‌های جداگانه در مرورگر ضد شناسایی برای هر یک از 10 کشور هدف و اجرای بررسی hreflang به صورت بصری از طریق آنها است.
به صورت مرحله به مرحله در Dolphin Anty یا AdsPower اینگونه است:
- یک پروفایل جدید مرورگر ایجاد کنید و آن را به نام کشور نام‌گذاری کنید، به عنوان مثال «hreflang-DE» برای آلمان.
- در تنظیمات پروفایل، بخش «پروکسی» را باز کرده و نوع
HTTP/SOCKS5را انتخاب کنید. - اطلاعات پروکسی با وابستگی جغرافیایی به آلمان را وارد کنید: IP یا هاست، پورت، نام کاربری و رمز عبور.
- پروفایل را ذخیره کنید و منتظر بررسی بمانید — مرورگر ضد شناسایی موقعیت جغرافیایی، منطقه زمانی و IP خاصی را نشان می‌دهد.
- پروفایل را راه‌اندازی کرده و وب‌سایت خود را با URL مستقیم باز کنید، بدون اینکه از جستجو وارد شوید.
- بررسی کنید که کدام نسخه باز شده است: URL در نوار آدرس، زبان محتوا، مقادیر hreflang از طریق «مشاهده کد صفحه».
- این کار را برای هر یک از 10 کشور هدف تکرار کنید و برای هر کدام یک پروفایل جداگانه ایجاد کنید.
این روش به این دلیل راحت است که پروفایل‌ها ذخیره می‌شوند و می‌توانید پس از یک هفته یا یک ماه به آنها بازگردید تا بررسی کنید که آیا رفتار وب‌سایت پس از به‌روزرسانی CDN یا استقرار نسخه جدید تغییر کرده است یا خیر. برای این کار، پروکسی‌های مسکونی با وابستگی به شهر خاص، نه فقط به کشور، بسیار مناسب هستند — این امر شبیه‌سازی دقیق‌تری از بازدیدکننده واقعی ارائه می‌دهد.
بررسی از طریق خط فرمان و curl
اگر نیاز به بررسی سریع HTTP headers، ریدایرکت‌ها و پاسخ‌های سرور دارید، مرورگر همیشه تصویر کاملی ارائه نمی‌دهد — بخشی از منطق در هدرهای پاسخ پنهان است. برای این کار، استفاده از curl با پروکسی راحت است.
بررسی پایه‌ای از طریق پروکسی با وابستگی به کشور مورد نظر:
curl -x http://login:password@proxy-host:port \
-I https://example.com/ \
-H "Accept-Language: de-DE"
پرچم -I فقط هدرهای پاسخ را نشان می‌دهد، بدون محتوای صفحه. این امکان را فراهم می‌کند که به سرعت کد ریدایرکت (301 یا 302)، هدر Location که نشان می‌دهد سرور به کجا ریدایرکت می‌کند و هدر Vary که نشان می‌دهد آیا Accept-Language در کش در نظر گرفته می‌شود یا خیر، مشاهده کنید.
برای استخراج خود HTML و پیدا کردن تگ‌های hreflang در پاسخ سرور، -I را حذف کرده و خروجی را فیلتر کنید:
curl -x http://login:password@proxy-host:port \
-s https://example.com/ | grep -i hreflangاین درخواست تمام خطوطی که به hreflang اشاره دارند را مستقیماً از HTML ارائه شده توسط سرور استخراج می‌کند، نه از آنچه که در مستندات انتظار می‌رود. اگر نتیجه بسته به اینکه درخواست از طریق پروکسی کدام کشور ارسال شده متفاوت باشد، به این معنی است که سرور واقعاً محتوا را بر اساس IP تغییر می‌دهد، نه اینکه فقط این را در نشانه‌گذاری استاتیک اعلام کند.
برای اتوماسیون بررسی همه 10 کشور، می‌توان یک اسکریپت ساده نوشت که لیست پروکسی‌ها را مرور کرده و پاسخ هر درخواست را در یک فایل جداگانه برای مقایسه ذخیره کند:
for country in de fr es it pl nl br mx jp kr; do
curl -x "http://login:password@${country}.proxy-host:port" \
-s https://example.com/ | grep -i hreflang > "result_${country}.txt"
doneپس از اجرای اسکریپت، تنها کاری که باقی می‌ماند مقایسه فایل‌ها است — اگر در همه جا مجموعه یکسانی از تگ‌های hreflang وجود داشته باشد، به این معنی است که سرور نشانه‌گذاری را بر اساس جغرافیا تغییر نمی‌دهد، که می‌تواند رفتار مورد انتظار (نشانه‌گذاری استاتیک و جهانی) یا یک مشکل باشد (اگر انتظار می‌رفت که کانونیکال‌سازی متفاوتی برای مناطق مختلف وجود داشته باشد).
بررسی از طریق مرورگر و DevTools
برای بررسی بصری و تحلیل تجربه کاربری، بهتر است از یک مرورگر معمولی با پروکسی تنظیم شده و ابزارهای توسعه‌دهنده باز استفاده کنید. این نیاز به کد ندارد و برای بازاریاب‌ها مناسب است که می‌خواهند با چشمان خود ببینند که کاربر چه می‌بیند.
مراحل کار:
- پروکسی را در مرورگر از طریق افزونه (به عنوان مثال، FoxyProxy) یا از طریق تنظیمات شبکه سیستم تنظیم کنید و IP کشور بررسی را مشخص کنید.
- وب‌سایت را باز کرده و بلافاصله F12 را فشار دهید تا DevTools باز شود، سپس به تب «Network» بروید.
- صفحه را دوباره بارگذاری کنید و اولین درخواست سند را پیدا کنید (معمولاً به همان نام دامنه وب‌سایت است).
- در پنل سمت راست، تب «Headers» را باز کرده و بخش «Response Headers» را برای وجود ریدایرکت‌ها و مقدار
Content-Languageبررسی کنید. - تب «Elements» را باز کرده و از طریق Ctrl+F تمام موارد
hreflangرا در کد منبع صفحه پیدا کنید. - URL در نوار آدرس را با آنچه که انتظار داشتید برای این کشور ببینید مقایسه کنید.
این روش به ویژه زمانی مفید است که نیاز به بررسی همزمان صحت فنی نشانه‌گذاری و نمایش بصری محتوا باشد — به عنوان مثال، آیا ارز، فرمت تاریخ یا بنرهای محلی‌سازی شده به درستی برای کشور خاص نمایش داده می‌شوند یا خیر.
کدام پروکسی‌ها را برای آزمایش هدف‌گذاری جغرافیایی انتخاب کنیم
همه انواع پروکسی به یک اندازه برای بررسی hreflang مناسب نیستند. تفاوت در این است که چگونه سرویس‌های شناسایی جغرافیایی IP را شناسایی می‌کنند و اینکه پروکسی چقدر به کشور اعلام شده پایبند است.
| نوع پروکسی | دقت geo-IP | کی استفاده کنیم |
|---|---|---|
| پروکسی‌های مسکونی | بالا، IP واقعی ارائه‌دهندگان | شبیه‌سازی دقیق بازدیدکننده زنده از کشور و شهر |
| پروکسی‌های موبایل | بالا، IP اپراتورهای ارتباطی | بررسی رفتار برای ترافیک موبایل و نسخه‌های AMP |
| پروکسی‌های دیتاسنتر | پایین‌تر، گاهی به عنوان دیتاسنتر علامت‌گذاری می‌شوند | بررسی سریع هدرها و ریدایرکت‌ها از طریق curl، جایی که دقت جغرافیایی بحرانی نیست |
برای بررسی نهایی قبل از راه‌اندازی وب‌سایت چند زبانه یا کمپین تبلیغاتی بین‌المللی در Google Ads، بهتر است از پروکسی‌های مسکونی یا موبایل استفاده کنید — زیرا آنها نتایجی را ارائه می‌دهند که به واقعیت نزدیک‌تر است و کاربر واقعی از کشور هدف چه می‌بیند.
چک‌لیست بررسی hreflang برای 10 کشور
برای اینکه چیزی را در بررسی انبوه از دست ندهید، از لیست زیر برای هر یک از 10 کشور استفاده کنید:
- پروکسی با IP دقیقاً از این کشور متصل شده است، موقعیت جغرافیایی از طریق IP-checker تأیید شده است.
- URL مستقیم وب‌سایت باز شده است (بدون ورود از جستجو و بدون referrer).
- URL نهایی پس از تمام ریدایرکت‌ها بررسی شده است — آیا با محلی که انتظار می‌رفت مطابقت دارد.
- در کد صفحه، hreflang خودارجاعی به خود وجود دارد.
- در لیست hreflang، تمام 9 نسخه زبانی دیگر بدون نقص ذکر شده‌اند.
- کدهای زبان و منطقه مطابق با استاندارد ISO هستند (به عنوان مثال،
pt-BR، نه فقطpt، اگر نیاز به تمایز بین برزیل و پرتغال باشد). - هدر
Vary: Accept-Languageوجود دارد، اگر محتوا به زبان مرورگر وابسته باشد. - محتوای صفحه (ارز، قیمت‌ها، بنرها) با منطقه اعلام شده مطابقت دارد.
- تگ کانونیکال
rel="canonical"به خود اشاره می‌کند، نه به محلی دیگر. - بررسی مجدد پس از یک هفته — پس از به‌روزرسانی کش CDN، نتیجه به طور غیرمنتظره تغییر نکرده است.
خطاهای متداول در هنگام آزمایش
در هنگام بررسی دستی hreflang از طریق پروکسی، بازاریاب‌ها اغلب چندین خطای تکراری مرتکب می‌شوند که نتیجه آزمایش را تحریف می‌کند.
اولاً، بررسی از حساب کاربری لاگین شده یا با جلسه ذخیره شده انجام می‌شود — در این صورت، سرور ممکن است محتوای شخصی‌سازی شده را نشان دهد، نه آنچه که یک بازدیدکننده جدید خواهد دید. همیشه در حالت ناشناس یا در پروفایل تمیز مرورگر ضد شناسایی بدون تاریخچه بررسی کنید.
ثانیاً، فراموش می‌کنند که کش DNS و مرورگر را بین تغییر پروکسی پاک کنند، به همین دلیل نسخه قدیمی صفحه همچنان نمایش داده می‌شود، در حالی که IP قبلاً تغییر کرده است. از بارگذاری سخت صفحه (Ctrl+Shift+R) در هر بار تغییر جغرافیا استفاده کنید.
ثالثاً، فقط صفحه اصلی را آزمایش می‌کنند و بخش‌های داخلی و کارت‌های محصولات را نادیده می‌گیرند — و دقیقاً در آنجا است که معمولاً نشانه‌گذاری hreflang به دلیل تولید دینامیک URL در لحظه خراب می‌شود.
رابعاً، از یک پروکسی یکسان برای همه 10 کشور استفاده می‌کنند و فقط هدر Accept-Language را تغییر می‌دهند — این معادل واقعی geo-IP نیست و می‌تواند نتیجه مثبت کاذب بدهد، اگر سرور واقعاً به IP تکیه کند، نه به زبان مرورگر.
نتیجه‌گیری
بررسی hreflang از طریق کد صفحه فقط نیمی از تصویر را ارائه می‌دهد. برای درک اینکه کاربر از یک کشور خاص واقعاً چه می‌گیرد، باید بازدید او را از طریق IP آن کشور شبیه‌سازی کرد — با استفاده از پروکسی، مرورگر ضد شناسایی یا یک درخواست ساده curl. این رویکرد مشکلاتی را که نمی‌توان در یک حسابرسی استاتیک پیدا کرد، آشکار می‌کند: ریدایرکت‌های geo-IP، کش CDN بدون توجه به منطقه، عدم تطابق کدهای زبان و خراب شدن تگ‌های خودارجاعی.
اگر شما به طور منظم وب‌سایت‌های چند زبانه را آزمایش می‌کنید یا کمپین‌های تبلیغاتی برای 10 کشور یا بیشتر آماده می‌کنید، توصیه می‌کنیم پروکسی‌های مسکونی را امتحان کنید — آنها دقیق‌ترین شبیه‌سازی از بازدیدکننده واقعی برای هر کشور هدف را ارائه می‌دهند و به شما اجازه می‌دهند hreflang را به گونه‌ای بررسی کنید که کاربر زنده می‌بیند، نه ربات جستجو.