اگر در روزهای اخیر تلاش کردهاید کمپین گوگل ادز اجرا کنید، احتمالاً متوجه شدهاید که استراتژیهای معمول دیگر جواب نمیدهند. ما با یک بنبست تکنیکال مواجهیم که در آن یا کمپین توسط گوگل رد (Disapproved) میشود و یا تایید میشود اما ورودی سایت عملاً صفر است.مشکل اصلی در تضاد بین “لوکیشن سرور” و “دسترسی شبکه” است. اکثر متخصصین دیجیتال مارکتینگ و سئو در حال حاضر سرگردانند که سرور را کجا قرار دهند تا هم گوگل را راضی نگه دارند و هم کاربر ایرانی را. در ادامه این مقاله از آژانس هشتپا راهکاری فنی را بررسی میکنیم که این گره کور را باز میکند.
آناتومی بحران و شکست کمپینها
برای درک راه حل، ابتدا باید بدانیم چرا روشهای فعلی شکست میخورند. مسئله دقیقاً در مسیردهی (Routing) ترافیک است.
سناریوی میزبانی روی سرورهای ایران
در این حالت فایلهای سایت روی دیتاسنترهای داخلی است. کاربران ایرانی که به اینترنت ملی (اینترانت) متصل هستند، سایت را با سرعت بالا و پینگ پایین باز میکنند. اما رباتهای گوگل (Google Crawlers) که از گیتویهای اروپا یا آمریکا تلاش میکنند به سایت برسند، با در بسته مواجه میشوند. نتیجه این است که گوگل تصور میکند سایت شما در دسترس نیست (Site Down) و تمام ادزها را با خطای Destination Mismatch رد میکند.
سناریوی میزبانی روی سرورهای خارج
در این حالت شما سایت را به هاست اروپایی منتقل میکنید. رباتهای گوگل به راحتی سایت را اسکن و ادز را تایید (Approve) میکنند. اما مشکل اصلی زمانی شروع میشود که کاربر ایرانی روی تبلیغ کلیک میکند. به دلیل اختلال روی پورتها و آیپیهای خارجی، کاربر با صفحه سفید یا Time-out مواجه میشود. در این سناریو، شما هزینه کلیک را پرداخت میکنید اما هیچ Session واقعی روی سایت شکل نمیگیرد و نرخ پرش (Bounce Rate) صد در صد میشود.
راهکار فنی: معماری دسترسی دوگانه (Dual-Access Strategy)
راه حلی که کمتر کسی در اکوسیستم فعلی از آن اطلاع دارد، تغییر هاست نیست، بلکه تغییر معماری دسترسی است. شما نباید سایت را صرفاً جابجا کنید، بلکه باید ساختاری ایجاد کنید که سایت برای “داخل” روی بستر ملی باشد و همزمان برای “خارج” (گوگل) روی بستر بینالملل در دسترس باشد.این متد از تکنیکهای Tunneling یا Reverse Proxy هوشمند استفاده میکند تا یک سایت واحد، دو در ورودی متفاوت داشته باشد.
منطق اجرایی راهکار
برای پیادهسازی این روش باید از یک ساختار لایهبندی شده استفاده کنید. مراحل فنی به شرح زیر است:
سورس اصلی روی ایران (Origin Server) فایلهای اصلی سایت، دیتابیس و پردازشهای اصلی باید روی سرور ایران باقی بمانند. این موضوع حیاتی است تا کاربرانی که فقط به اینترنت ملی دسترسی دارند، بدون نیاز به عبور از گیتویهای مسدود شده بینالملل، مستقیماً به محتوا دسترسی داشته باشند.
ایجاد لایه واسط خارجی (The External Relay) شما نیاز به یک نود (Node) یا سرور واسط در خارج از ایران دارید. این میتواند یک VPS کوچک یا کانفیگ خاصی در سطح CDN باشد. وظیفه این لایه صرفاً دریافت درخواستهای خارجی و انتقال آنهاست.
برقراری تانل ارتباطی (Tunneling) بین سرور خارجی و سرور داخلی یک تانل امن و اختصاصی برقرار میشود. زمانی که ربات گوگل درخواست ارسال میکند، این درخواست به IP خارجی برخورد میکند. سرور خارجی درخواست را از طریق تانل به سرور ایران میرساند، پاسخ را میگیرد و به گوگل تحویل میدهد.
چرا این متد تنها راه نجات است؟
استفاده از این معماری ترکیبی، دو مزیت حیاتی ایجاد میکند که هیچ روش دیگری ندارد:
جلوگیری از Disapproved شدن چون لبهی بیرونی (Edge) سایت شما در خارج از کشور قرار دارد، سیستمهای نظارتی گوگل همواره سایت را آنلاین و در دسترس میبینند. رباتها بدون برخورد به فایروال ملی، صفحات فرود را کرال میکنند.
تضمین دسترسی کاربر داخلی چون سورس اصلی در ایران است، حتی اگر اینترنت بینالملل کاملاً قطع شود، کاربر داخلی همچنان سایت را باز میکند. در واقع درخواست کاربر ایرانی اصلاً از کشور خارج نمیشود که بخواهد مسدود شود.
جمعبندی
در شرایط ناپایدار شبکه، اصرار بر استفاده از روشهای سنتی هاستینگ (تک لوکیشنی) اشتباه است. با پیادهسازی این معماری هیبریدی، شما عملاً یک سایت دارید که دو مسیر ورودی مجزا دارد: یکی برای گوگل و کاربران خارج از کشور، و دیگری برای کاربران داخل ایران. این تنها روشی است که در حال حاضر امکان روشن نگه داشتن چراغ ادز و دریافت ورودی واقعی را فراهم میکند.
