حفظ دسترسی Googlebot در زمان اختلال اینترنت بینالملل با Custom PopSite Rule
اگر سایت از داخل کشور باز شود، الزاماً یعنی برای Googlebot هم قابل دسترس است؟ نه. در زمان اختلال ارتباط بینالملل، ممکن است کاربران داخلی سایت را ببینند اما گوگل در زمان Crawl با Timeout، خطای DNS، مشکل TLS یا پاسخهای 5xx مواجه شود.
Crawlability
حفظ امکان خزیدن گوگل حتی در شرایط اختلال ارتباط بینالملل.
Availability
تفکیک دسترسی کاربران داخلی، خارجی و رباتهای موتور جستجو.
Multi-Origin
استفاده از Origin داخلی و خارجی پشت یک دامنه واحد.
SEO Safety
حفظ Canonical، Sitemap، robots.txt و وضعیت HTTP صحیح.
سئو فنی در زمان اختلال اینترنت بینالملل
تحلیل مسئله از نگاه SEO، Crawlability و Availability
یکی از خطاهای رایج در ارزیابی سلامت سایت این است که فقط دسترسی کاربران داخلی بررسی میشود. در حالی که از نگاه SEO، مهمترین سؤال این است: آیا Googlebot هم میتواند همان صفحات را با پاسخ سالم دریافت کند؟
در زمان اختلال ارتباط بینالملل، مسیر کاربر ایرانی تا سرور داخلی ممکن است فعال و پایدار باشد؛ اما Googlebot که از خارج کشور درخواست ارسال میکند، نتواند به همان Origin برسد. نتیجه این وضعیت میتواند کاهش Crawl Rate، افزایش Crawl Error، تأخیر در ایندکس و نوسان رتبههای ارگانیک باشد.
دسترسی کاربران داخلی با دسترسی Googlebot برابر نیست؛ سایت میتواند برای کاربران داخل کشور فعال باشد، اما از نگاه گوگل غیرقابل Crawl محسوب شود.
- کاهش نرخ Crawl صفحات مهم
- افزایش Crawl Error در Google Search Console
- تأخیر در ایندکس شدن صفحات جدید
- نوسان رتبههای ارگانیک
- کاهش Organic Visibility
- احتمال خروج صفحات از Index در اختلالهای طولانی
مسیر فنی درخواست از Googlebot تا Origin Server
برای طراحی راهکار درست، باید زنجیره فنی درخواست را بشناسیم. Googlebot ابتدا دامنه را Resolve میکند، سپس به لایه CDN یا Reverse Proxy میرسد و در نهایت درخواست به Origin Server ارسال میشود.
لایه DNS
دامنه را به مقصد شبکهای تبدیل میکند، اما معمولاً درخواست HTTP واقعی، Headerها، User-Agent و وضعیت دقیق Origin را نمیبیند.
لایه شبکه
Routing، TCP Handshake، TLS Negotiation، Latency و Packet Loss در این مرحله نقش اصلی دارند.
لایه CDN / Proxy
میتواند کش، SSL، امنیت، مسیریابی و Ruleهای سفارشی را مدیریت کند؛ اما در Cache Miss همچنان باید به Origin درست وصل شود.
لایه Origin
از نگاه گوگل، مهم است که صفحه پاسخ سالم، محتوای قابل Crawl، Canonical صحیح و وضعیت HTTP پایدار داشته باشد.
بررسی معماریهای جایگزین و تحلیل GeoDNS
برای حفظ دسترسی Googlebot چند معماری قابل بررسی است؛ اما هر مدل باید از نظر پایداری Crawl، تجربه کاربر داخلی، پیچیدگی عملیاتی و ریسک SEO ارزیابی شود. در ادامه، علاوه بر توضیح خلاصه، مسیر هر معماری نیز بهصورت بصری نمایش داده شده است.
Single-Origin داخلی
ساده، سریع برای کاربران داخلی و کمهزینه؛ اما در زمان اختلال مسیر بینالملل میتواند برای Googlebot غیرقابل دسترس شود.
Single-Origin خارجی
برای Googlebot مناسبتر است، اما کاربران داخلی ممکن است Latency بالاتر یا دسترسی ناپایدارتر تجربه کنند.
CDN-Based
برای کش و سرعت مفید است، اما اگر درخواست Cache Miss باشد و CDN نتواند به Origin وصل شود، مشکل همچنان باقی میماند.
Mirror / Static Fallback
برای سایتهای محتوایی مفید است، اما در سایتهای پویا میتواند چالش Canonical، Sitemap، قیمت، موجودی و Duplicate Content ایجاد کند.
جمعبندی این چهار مدل این است که هیچکدام بهتنهایی برای همه سایتها ایدهآل نیستند: Single-Origin داخلی برای کاربر داخلی خوب است اما Crawl را تهدید میکند؛ Single-Origin خارجی برای Googlebot بهتر است اما تجربه داخلی را ضعیف میکند؛ CDN در Cache Miss همچنان به Origin وابسته است؛ و Mirror/Static Fallback نیازمند Sync و کنترل SEO دقیق است.
GeoDNS در ظاهر منطقی است، اما تصمیمگیری آن در لایه DNS انجام میشود؛ جایی که معمولاً IP واقعی کاربر دیده نمیشود و DNS Provider بیشتر با IP Recursive Resolver سروکار دارد. استفاده از Public DNS، محدودیت EDNS Client Subnet، کش DNS، شبکههای Anycast، VPN، Proxy و خطاهای GeoIP باعث میشوند GeoDNS برای سناریوی حساس حفظ دسترسی Googlebot بهتنهایی کافی نباشد.
- تصمیمگیری بر اساس Resolver بهجای Client واقعی
- وابستگی به DNS Cache و TTL
- ندیدن User-Agent، Header و Path درخواست
- احتمال شکست Resolve در اختلال بینالملل
- خطای GeoIP Database یا Anycast Routing
- کنترل عملیاتی محدود نسبت به لایه Proxy/CDN
GeoDNS ابزار مفیدی است، اما در معماریهای حساس SEO بهتر است تصمیمگیری اصلی تا حد امکان به درخواست واقعی HTTP نزدیکتر باشد.
راهکار اصلی: Multi-Origin Architecture با Custom PopSite Rule
راهکار پیشنهادی، استفاده از دو Origin پشت یک دامنه واحد است. کاربران داخل کشور از Domestic Origin پاسخ میگیرند و Googlebot، کاربران خارجی و ابزارهای بینالمللی از International Origin.
در این معماری، دامنه سایت تغییر نمیکند و از نگاه کاربر و موتور جستجو همچنان یک URL واحد وجود دارد. تفاوت اصلی در پشت صحنه است: لایه Proxy/CDN قبل از رسیدن درخواست به Origin تصمیم میگیرد که درخواست باید به کدام سرور ارسال شود. این تصمیم میتواند بر اساس کشور درخواست، IP واقعی، هدرها، مسیر URL، سیاستهای امنیتی، وضعیت سلامت Originها یا Ruleهای اختصاصی انجام شود.
مزیت اصلی Custom PopSite Rule نسبت به GeoDNS این است که تصمیمگیری به لایهای نزدیکتر به درخواست واقعی HTTP منتقل میشود. در این نقطه، سیستم فقط با IP Resolver سروکار ندارد، بلکه میتواند رفتار واقعی درخواست، مسیر صفحه، نوع ترافیک، وضعیت Cache، وضعیت Origin و حتی سیاستهای متفاوت برای بخشهای مختلف سایت را در نظر بگیرد.
در سناریوی عملی، Domestic Origin میتواند همان سرور اصلی سایت باشد که برای کاربران داخلی سرعت و پایداری بهتری دارد. در مقابل، International Origin میتواند یک نسخه همگامشده، Read-Only، Mirror کنترلشده یا Replica از صفحات مهم سایت باشد که از بیرون کشور قابل دسترس است. به این ترتیب، اگر مسیر بینالملل به Origin داخلی دچار اختلال شود، Googlebot همچنان میتواند نسخه قابل Crawl را از مسیر خارجی دریافت کند.
این معماری برای انواع سایتها قابل استفاده است؛ از وردپرس و سایتهای محتوایی گرفته تا سایتهای اختصاصی، وباپلیکیشنها، فروشگاهها، سایتهای Static و سیستمهای Headless. نکته مهم این است که PopSite Rule نباید صرفاً بر اساس نام Googlebot برای نمایش محتوای متفاوت طراحی شود؛ بلکه باید هدف آن حفظ دسترسی فنی به همان محتوای اصلی باشد تا ریسک Cloaking ناخواسته ایجاد نشود.
تصمیمگیری در لایه Proxy/CDN انجام میشود؛ نزدیکتر به درخواست واقعی HTTP و با کنترل عملیاتی بهتر. این مدل امکان تعریف Ruleهای دقیقتر برای کشور، IP، Path، Header، وضعیت Origin و سناریوهای Failover را فراهم میکند.
تصمیمگیری در لایه DNS انجام میشود؛ معمولاً بدون دید کامل نسبت به Client واقعی، Header، User-Agent، مسیر URL و وضعیت Origin. به همین دلیل برای حفظ دسترسی Googlebot در سناریوهای حساس، بهتنهایی کافی نیست.
در این مدل، هدف فریب موتور جستجو نیست؛ هدف حفظ دسترسی فنی Googlebot به همان محتوای اصلی سایت در شرایطی است که Origin داخلی از بیرون قابل اتکا نیست.
Custom PopSite Rule دقیقاً چه کاری انجام میدهد؟
این Rule مانند یک لایه تصمیمگیری هوشمند عمل میکند. وقتی درخواست وارد Proxy/CDN میشود، سیستم قبل از ارسال درخواست به سرور مقصد بررسی میکند که این ترافیک از کجا آمده، برای چه مسیری است، چه نوع کاربری آن را ارسال کرده و کدام Origin برای پاسخدهی مناسبتر است. سپس بدون تغییر URL نهایی، درخواست را به Origin داخلی یا خارجی هدایت میکند.
- هدایت کاربران داخلی به Domestic Origin برای سرعت بهتر
- هدایت Googlebot و ترافیک خارجی به International Origin
- امکان تعریف Rule برای مسیرهای خاص مثل بلاگ، محصول یا Sitemap
- کنترل بهتر روی Cache Miss و وضعیت سلامت Originها
- کاهش وابستگی تصمیمگیری به DNS Resolver
- حفظ دامنه واحد و جلوگیری از پراکندگی URLها
نکته مهم: Sync خودکار وجود ندارد
داشتن دو Origin به معنی همگامسازی خودکار محتوا نیست. معمولاً Domestic Origin نسخه اصلی عملیاتی باقی میماند و International Origin بهعنوان نسخه پشتیبان برای SEO، Crawl و دسترسی بینالملل استفاده میشود.
اگر سایت محتوایی باشد، میتوان صفحات مهم را بهصورت Static Export یا Sync دورهای به نسخه خارجی منتقل کرد. اگر سایت فروشگاهی یا داینامیک باشد، بهتر است نسخه خارجی فقط نقش Read-Only یا Catalog Mode داشته باشد تا قیمت، موجودی، پرداخت، ورود کاربران و عملیات حساس باعث تناقض بین دو Origin نشود.
- Backup / Restore دورهای
- Static Export برای سایتهای محتوایی
- Selective Sync برای صفحات مهم SEO
- همگامسازی فایلهای Media
- Read-Only Replica برای نسخه خارجی
- کنترل اختلاف محتوا بین دو Origin
ملاحظات SEO در معماری Multi-Origin
پیادهسازی Multi-Origin فقط یک مسئله زیرساختی نیست. اگر نسخه خارجی از نظر SEO ناقص، ناسازگار یا متناقض باشد، ممکن است بهجای حل مشکل، ریسکهای جدیدی ایجاد کند.
در هر دو Origin باید Canonical صفحات یکسان باشد و به دامنه اصلی اشاره کند.
<link rel="canonical" href="https://example.com/page/" />
فایل robots.txt باید در نسخه خارجی نیز قابل دسترس باشد و Googlebot را بلاک نکند.
https://example.com/robots.txt
Sitemap باید روی دامنه اصلی قابل دسترس باشد و URLهای آن به دامنه اصلی اشاره کنند.
https://example.com/sitemap.xml
صفحهای که در Domestic Origin مقدار 200 دارد، در International Origin نباید 404، 403 یا 500 باشد.
Domestic: 200 OK
International: 200 OK
محتوای اصلی، عنوان، متا و لینکهای مهم باید تا حد امکان هماهنگ باشند.
Same Content
Same Meta
Same Canonical
نسخه خارجی نباید بهاشتباه noindex یا X-Robots-Tag نامناسب ارسال کند.
X-Robots-Tag: index, follow
Schemaهای محصول، مقاله، Breadcrumb، Organization و سایر دادههای ساختاریافته باید معتبر باشند.
Product / Article / Breadcrumb
لینکها نباید به localhost، IP داخلی، دامنه Staging یا مسیرهای غیرقابل دسترس اشاره کنند.
https://example.com/category/sample/
برای فروشگاهها بهتر است نسخه خارجی بهصورت Read-Only یا Catalog Mode طراحی شود.
Product: indexable
Checkout: restricted
جمعبندی نهایی
در زمان اختلال اینترنت بینالملل، ممکن است سایت برای کاربران داخلی در دسترس باشد، اما Googlebot نتواند به آن برسد. این مسئله میتواند Crawl، Index و Ranking سایت را تحت تأثیر قرار دهد. راهکارهایی مثل CDN، Mirror، GeoDNS یا Single-Origin هرکدام مزایا و محدودیتهایی دارند؛ اما برای بسیاری از کسبوکارها، معماری Multi-Origin همراه با Custom PopSite Rule راهکاری عملی، قابل اجرا و کمریسکتر است.