سایت به کاربر انگلیسی‌زبان از ایالات متحده یک صفحه نشان می‌دهد، در حالی که Googlebot که به‌طور فیزیکی در مرکز داده Mountain View نشسته است — صفحه‌ای کاملاً متفاوت. به‌طور رسمی این موضوع به‌عنوان کلاکیگ شناخته می‌شود، حتی اگر شما فقط می‌خواستید محتوای خود را برای منطقه‌ای خاص تنظیم کنید. به بررسی 6 اشتباه رایج در تغییرات جغرافیایی می‌پردازیم که باعث می‌شود سایت‌ها موقعیت‌های خود را از دست بدهند، تحریم‌های دستی دریافت کنند و دامنه‌های کامل در شبکه‌های شریک مسدود شوند.
تغییر جغرافیایی چیست و چرا برای کسب‌وکار ضروری است
تغییر جغرافیایی یک مکانیزم است که به‌طور خودکار کاربر را به نسخه‌ای از سایت که برای کشورش تنظیم شده است، هدایت می‌کند: زبان، ارز، قیمت‌ها، پیشنهادات متفاوت. فروشگاه‌های اینترنتی از آن استفاده می‌کنند تا خریدار از آلمان به‌طور مستقیم به نسخه آلمانی با قیمت‌های یورو هدایت شود، نه اینکه کاتالوگ را با قیمت‌های دلار مرور کند. آربیتراژکنندگان از تغییرات جغرافیایی در ترکیب‌ها استفاده می‌کنند تا پیشنهادات متفاوتی را بسته به ترافیک جغرافیایی نشان دهند — به‌عنوان مثال، به کاربران از کشورهای Tier-1 یک لندینگ، و به سایرین — یک صفحه خنثی یا محصول دیگری.
مشکل این است که همان منطقی که کشور کاربر را بر اساس IP تعیین می‌کند، به Googlebot نیز اعمال می‌شود. و IP آدرس‌های ربات‌های گوگل به‌طور فیزیکی در ایالات متحده قرار دارند، صرف‌نظر از اینکه آیا آن‌ها صفحه‌ای را برای نتایج روسی، قزاقستانی یا آلمانی ایندکس می‌کنند. اگر سیستم تغییر جغرافیایی نتواند خزنده را از یک انسان زنده تشخیص دهد، نتیجه یکی خواهد بود — گوگل صفحه‌ای را می‌بیند که بازدیدکنندگان واقعی نمی‌بینند. این تعریف رسمی کلاکیگ طبق توصیه‌های Google Search Central است و مجازات آن — از کاهش رتبه در نتایج تا حذف کامل دامنه از ایندکس.
چرا Googlebot و انسان صفحات متفاوتی می‌بینند
اختلاف به‌طور همزمان به سه دلیل ایجاد می‌شود و معمولاً این دلایل بر یکدیگر تأثیر می‌گذارند. اولاً، Googlebot سایت را با IP آدرس‌هایی که متعلق به گوگل هستند، خزیده و این آدرس‌ها تقریباً در 100% موارد به‌عنوان آمریکایی توسط خدمات جغرافیایی (MaxMind، IP2Location و مشابه) شناسایی می‌شوند. ثانیاً، Googlebot User-Agent خود را ارسال می‌کند که اغلب توسط یک شاخه کد جداگانه پردازش می‌شود — گاهی به‌طور عمدی، تا ایندکس‌گذاری را خراب نکند، و گاهی اوقات به‌سادگی به‌خاطر اشتباه توسعه‌دهنده. ثالثاً، رفتار Googlebot در هنگام رندرینگ JS با رفتار مرورگر متفاوت است: خزنده ممکن است تغییراتی را که به JavaScript سمت کلاینت وابسته است، انجام ندهد و در نتیجه نسخه‌ای کاملاً متفاوت از صفحه را ایندکس کند که یک انسان با JS فعال می‌بیند.
به این موارد کش CDN را اضافه کنید که ممکن است بر روی نسخه‌ای برای یک کشور «چسبیده» و آن را به همه ارائه دهد، و شما به وضعیتی می‌رسید که حتی بدون نیت بد صاحب سایت، موتور جستجو محتوایی را ایندکس می‌کند که با آنچه مخاطب می‌بیند، مطابقت ندارد. در زیر — شش سناریوی خاص که در آن این موضوع بیشتر اتفاق می‌افتد.
اشتباه 1: تغییر بر اساس IP بدون بررسی User-Agent ربات
رایج‌ترین اشتباه — منطق تغییر به‌طور انحصاری بر اساس تعیین کشور بر اساس IP ساخته می‌شود، بدون هیچ‌گونه بررسی که چه کسی درخواست را انجام می‌دهد: انسان یا خزنده. در نتیجه Googlebot که از یک دامنه IP آمریکایی وارد می‌شود، به‌طور خودکار به نسخه US سایت هدایت می‌شود، حتی اگر صفحه در ابتدا برای درخواست‌های روسی یا قزاقستانی ترویج شده باشد. پس از چند هفته خزیدن، ایندکس گوگل با «نسخه نادرست» پر می‌شود و موقعیت‌ها در مناطق هدف بدون دلیل واضح شروع به کاهش می‌کنند.
راه‌حل — همیشه User-Agent و دامنه‌های IP شناخته‌شده ربات‌های جستجو (Googlebot، Bingbot، YandexBot) را از تغییرات جغرافیایی مستثنی کنید و نسخه کانونی صفحه را بدون توجه به کشور مشخص شده به آن‌ها ارائه دهید. بررسی User-Agent یک مانع ضروری است، اما کافی نیست، زیرا به‌راحتی قابل جعل است، بنابراین پروژه‌های جدی به‌طور اضافی IP را از طریق جستجوی DNS معکوس (reverse DNS lookup) تأیید می‌کنند، همان‌طور که خود مستندات گوگل برای تأیید Googlebot توصیه می‌کند.
اشتباه 2: آزمایش با IPهای مرکز داده به جای کاربران واقعی
اشتباه دوم در مرحله بررسی رخ می‌دهد. توسعه‌دهنده یا بازاریاب تغییرات جغرافیایی را از طریق پروکسی یا VPN معمولی مرکز داده آزمایش می‌کند و منطق به‌گونه‌ای عمل می‌کند که گویی این یک کاربر واقعی از کشور مورد نظر است. اما IPهای مرکز داده به‌راحتی از ترافیک خانگی قابل تشخیص هستند — بسیاری از CDN و سیستم‌های ضد تقلب آن‌ها را با یک پرچم جداگانه علامت‌گذاری می‌کنند و بخشی از منطق هدف‌گذاری جغرافیایی ممکن است برای چنین آدرس‌هایی به‌طور متفاوتی عمل کند تا برای آدرس‌های IP خانگی معمولی.
در نتیجه، آزمایش «موفق» است، تغییر در سرور توسعه به‌خوبی کار می‌کند، اما در تولید، کاربران واقعی از کشور هدف نسخه نادرستی را دریافت می‌کنند زیرا پایگاه داده جغرافیایی ارائه‌دهنده یا قاعده CDN IP آن‌ها را به‌طور متفاوتی تفسیر می‌کند نسبت به آدرس مرکز داده آزمایش. برای بررسی صحیح، باید از پروکسی‌های مسکونی استفاده کنید — آن‌ها IPهای واقعی ارائه‌دهندگان خانگی در کشور مورد نظر را دارند و خدمات جغرافیایی آن‌ها را به‌گونه‌ای شناسایی می‌کنند که گویی یک کاربر زنده است. این تصویر صادقانه‌ای از آنچه که بازدیدکننده واقعی سایت خواهد دید، ارائه می‌دهد و نه نسخه ساده‌شده‌ای برای IP مرکز داده «معمولی».
اشتباه 3: کش و عدم وجود Vary-zagolovkov
اگر سایت پشت CDN (Cloudflare، Fastly، Akamai) قرار داشته باشد و تغییر جغرافیایی در سطح سرور اصلی پیاده‌سازی شده باشد، نه خود CDN، به‌راحتی ممکن است به وضعیتی برسید که CDN اولین نسخه ارسال شده صفحه را کش کند و آن را به همه ارائه دهد — بدون توجه به کشور بازدیدکننده بعدی. این موضوع زمانی اتفاق می‌افتد که در پاسخ سرور هدر Vary: Accept-Language یا کلید کش جغرافیایی مشابه به‌درستی مشخص نشده باشد.
در این حالت، Googlebot ممکن است «نسخه صحیح» را در اولین بازدید خود ببیند، آن را در سیستم‌های ایندکس‌گذاری خود کش کند و سپس هفته‌ها همان نسخه را در بازدیدهای بعدی دریافت کند، حتی اگر محتوا برای کشورهای دیگر مدت‌هاست تغییر کرده باشد. در این زمان، کاربران نسخه‌ای به‌روز و متفاوت را می‌بینند — عدم هم‌زمانی به‌طور تدریجی افزایش می‌یابد و تشخیص آن بدون مقایسه مستقیم پاسخ‌های سرور برای جغرافیای مختلف از طریق ابزارهایی مانند curl با تغییر هدرها یا از طریق پروکسی با جغرافیای مورد نظر دشوار است.
اشتباه 4: JS-redirect که ربات به‌طور متفاوتی تفسیر می‌کند
Googlebot می‌تواند JavaScript را اجرا کند، اما این کار را با تأخیر قابل توجهی انجام می‌دهد (موج دوم رندرینگ ممکن است روزها طول بکشد) و همیشه به‌طور یکسان با مرورگر کاربر عمل نمی‌کند. اگر تغییر جغرافیایی از طریق JS سمت کلاینت پیاده‌سازی شده باشد — به‌عنوان مثال، از طریق window.location پس از درخواست fetch به geo-API — خطر این وجود دارد که در اولین عبور خزنده صفحه را قبل از فعال شدن تغییر ایندکس کند، یعنی نسخه «نادرست» برای منطقه خاص.
این موضوع به‌ویژه برای لندینگ‌های تک‌صفحه‌ای (SPA) که تمام منطق شخصی‌سازی در سمت کلاینت قرار دارد، بحرانی است. رویکرد صحیح — انجام شناسایی جغرافیایی و تغییر در سمت سرور (عملکرد edge CDN، middleware در Node.js، قاعده در Nginx) است، تا Googlebot و کاربر HTTP-redirect 302 را قبل از اینکه صفحه در مرورگر شروع به رندر شود، دریافت کنند. این وابستگی به اینکه خزنده چگونه JS را در زمان خاصی پردازش می‌کند، حذف می‌کند.
اشتباه 5: یک URL بدون hreflang برای نسخه‌های زبانی مختلف
پنجمین اشتباه — تلاش برای خدمات‌دهی چندین نسخه زبانی در یک URL بدون نشانه‌گذاری hreflang. گوگل به‌طور مستقیم توصیه می‌کند: اگر محتوا در یک URL بسته به محلی که کاربر دارد متفاوت است، باید یا URLهای متفاوتی برای هر نسخه (زیر دامنه‌ها، زیر پوشه‌ها یا دامنه‌های جداگانه) با نشانه‌گذاری hreflang متقابل ارائه دهید، یا به‌طور صادقانه یک نسخه یکسان را به همه، از جمله ربات‌ها، نشان دهید و امکان تغییر زبان به‌صورت دستی را اضافه کنید.
بدون hreflang، گوگل به‌طور فیزیکی نمی‌تواند درک کند که /product به زبان روسی و /product به زبان انگلیسی — این‌ها به‌طور عمدی محتوای متفاوتی برای مخاطبان مختلف هستند و نه تلاش برای پنهان کردن یک نسخه از ایندکس به‌خاطر دیگری. نتیجه این است که یک نسخه تصادفی به ایندکس می‌رسد (معمولاً آنچه که در آخرین خزیدن برای ربات در دسترس بود) و همین نسخه در تمام مناطق به‌طور همزمان رتبه‌بندی می‌شود، که تأثیر منفی بر مرتبط بودن نتایج و تبدیل دارد.
اشتباه 6: عدم وجود fallback برای کاربران با VPN و پروکسی‌های موبایل
ششمین اشتباه بیشتر به کاربران واقعی مربوط می‌شود تا Googlebot — اما این موضوع به‌طور مستقیم با تغییرات جغرافیایی مرتبط است، زیرا اغلب تلاش برای «اصلاح» رفتار برای ربات‌ها، آن را برای انسان‌های زنده با VPN یا اینترنت موبایل خراب می‌کند. کاربران اپراتورهای موبایل اغلب از طریق CGNAT (Carrier-Grade NAT) به اینترنت متصل می‌شوند، زمانی که ده‌ها هزار مشترک از یک IP خارجی یکسان استفاده می‌کنند و پایگاه داده جغرافیایی ممکن است چنین IP را به‌عنوان متعلق به کشور همسایه یا حتی به‌طور اشتباه شناسایی کند.
اگر در سایت هیچ سوئیچ دستی برای کشور/زبان به‌عنوان fallback وجود نداشته باشد، کاربر با IP «نادرست» شناسایی شده در نسخه نامربوطی گیر می‌کند بدون اینکه بتواند آن را تغییر دهد — و به سادگی خارج می‌شود. برای آزمایش دقیق چنین سناریویی، باید رفتار سایت را از طریق پروکسی‌های موبایل بررسی کنید که IPهای واقعی اپراتورهای موبایل را با رفتار جغرافیایی خاص CGNAT شبیه‌سازی می‌کنند — این به شناسایی مشکل قبل از اینکه کاربران واقعی آن را پیدا کنند و به پشتیبانی گزارش دهند، کمک می‌کند.
چگونه تغییر جغرافیایی را از دیدگاه گوگل از کشورهای مختلف بررسی کنیم
ابزار اصلی برای تشخیص اولیه — عملکرد «مشاهده به‌عنوان Googlebot» در Google Search Console (ابزار بررسی URL) است که نشان می‌دهد کدام HTML واقعاً توسط خزنده گوگل دریافت می‌شود. اگر نسخه‌ای که در آنجا نمایش داده می‌شود، همان نسخه‌ای نیست که شما در مرورگر خود از کشور خود می‌بینید — مشکل تأیید شده است. اما Search Console همیشه از IPهای آمریکایی خزیده می‌شود، بنابراین برای مقایسه رفتار سایت در مناطق مختلف به یک لایه آزمایش جداگانه نیاز است.
در عمل، بازاریابان و متخصصان SEO چندین پروفایل در مرورگر ضد تشخیص — Dolphin Anty، AdsPower، Multilogin یا GoLogin — ایجاد می‌کنند و به هر پروفایل پروکسی کشور مورد نظر را متصل می‌کنند تا به‌طور دستی مسیر کاربر را طی کنند: سایت را باز کنند، ببینند کدام نسخه بارگذاری شده، کدام هدر Accept-Language ارسال شده، آیا تغییر کار کرده و به کدام URL رفته است. برای چنین بررسی‌هایی، پروکسی‌های مسکونی با انتخاب دقیق شهر یا اپراتور مناسب هستند — آن‌ها شبیه‌سازی صادقانه‌تری از بازدیدکننده واقعی ارائه می‌دهند، بر خلاف آدرس‌های مرکز داده که برخی از خدمات ممکن است قبل از ارزیابی جغرافیایی به‌عنوان مشکوک علامت‌گذاری کنند.
| نوع پروکسی | برای کدام بررسی مناسب است | ریسک نتیجه نادرست |
|---|---|---|
| پروکسی‌های مسکونی | شبیه‌سازی کاربر خانگی معمولی در کشور/شهر مورد نظر | پایین |
| پروکسی‌های موبایل | بررسی رفتار در هنگام CGNAT و جغرافیای موبایل | پایین |
| پروکسی‌های مرکز داده | بررسی سریع واقعیت وقوع تغییر بر اساس کشور | بالاتر: بخشی از پایگاه‌های جغرافیایی IP را به‌گونه‌ای علامت‌گذاری می‌کند که با خانگی متفاوت است |
برای بررسی رفتار منطق سرور (نه رندر بصری) مفید است که پاسخ خام سرور را از طریق curl با تغییر User-Agent به Googlebot و هدر X-Forwarded-For به IP کشور مورد نظر مشاهده کنید — این نشان می‌دهد که کدام وضعیت HTTP و Location سرور قبل از هرگونه رندرینگ JS ارائه می‌دهد و به شما اجازه می‌دهد اشتباه 4 و اشتباه 1 را از لیست بالا تنها با یک فرمان شناسایی کنید.
چک‌لیست تنظیمات ایمن تغییرات جغرافیایی
- Googlebot، Bingbot و YandexBot از منطق تغییر جغرافیایی بر اساس User-Agent مستثنی شده و از طریق DNS معکوس تأیید شده‌اند
- تغییر در سمت سرور (302/307) پیاده‌سازی شده و نه تنها از طریق JavaScript سمت کلاینت
- هدر
Varyبرای کش صحیح CDN بر اساس جغرافیا/زبان تنظیم شده است - برای هر نسخه زبانی یک URL جداگانه با نشانه‌گذاری hreflang متقابل وجود دارد
- یک سوئیچ دستی قابل مشاهده برای کشور/زبان به‌عنوان fallback برای IP نادرست شناسایی شده وجود دارد
- آزمایش از طریق پروکسی‌های مسکونی و موبایل از کشورهای مورد نظر انجام می‌شود، نه فقط از طریق آدرس‌های مرکز داده
- هر سه ماه یک‌بار بررسی می‌شود که Google Search Console چه چیزی نشان می‌دهد — نسخه با آنچه کاربران واقعی می‌بینند مطابقت دارد
نتیجه‌گیری
اختلاف بین آنچه Googlebot می‌بیند و آنچه کاربر می‌بیند به‌ندرت یک فریب عمدی برای موتور جستجو است — بیشتر این موضوع به بدهی فنی انباشته شده مربوط می‌شود: تغییر بر اساس IP بدون بررسی ربات، کش بدون هدر Vary، تغییر JS که خزنده فرصت اجرای آن را ندارد، و عدم وجود hreflang برای نسخه‌های زبانی. هر یک از این اشتباهات به‌تنهایی به‌نظر جزئی می‌رسد، اما با هم تصویری کلاسیک از کلاکیگ در چشم گوگل ایجاد می‌کنند — با تحریم‌های مربوطه.
تنها راه مطمئن برای اطمینان از اینکه سایت به‌طور یکسان به ربات‌ها و انسان‌ها رفتار می‌کند، بررسی منظم آن با IPهای واقعی کشورهای مورد نظر است. برای این تشخیص، توصیه می‌کنیم از پروکسی‌های مسکونی برای شبیه‌سازی کاربر خانگی معمولی و پروکسی‌های موبایل برای بررسی سناریوهای CGNAT استفاده کنید — این تصویر صادقانه‌تری از آنچه که واقعاً مخاطب شما در هر منطقه می‌بیند، ارائه می‌دهد و به شناسایی مشکل قبل از اینکه الگوریتم گوگل آن را پیدا کند، کمک می‌کند.