← بازگشت به وبلاگ

پیگیری موقعیت خود به جای Topvisor و Serpstat: محاسبه هزینه برای 1000 کلمه کلیدی در روز

هزینه پارسینگ مستقل نتایج یاندکس و گوگل برای ۱۰۰۰ درخواست در روز را بررسی می‌کنیم و زمان‌هایی که استفاده از ردیاب موقعیت شخصی به صرفه‌تر از اشتراک آماده است.

📅۹ آبان ۱۴۰۵

آژانس‌های سئو و بازاریابان داخلی دیر یا زود یک سوال مشابه می‌پرسند: چرا باید برای اشتراک ردیاب موقعیت هزینه کنیم، در حالی که می‌توانیم یک پارسر مستقل برای نتایج جمع‌آوری کنیم؟ پاسخ به این سوال به سادگی به نظر نمی‌رسد — هزینه نظارت مستقل فقط شامل سرورها نیست، بلکه شامل پروکسی‌ها، کپچا و زمان برای پشتیبانی از اسکریپت‌ها نیز می‌شود. در این مقاله ریاضیات واقعی را با مثال بررسی 1000 عبارت کلیدی در روز بررسی خواهیم کرد.

چرا آژانس‌ها ردیاب موقعیت خود را می‌سازند

خدمات آماده مانند Topvisor، Serpstat، SE Ranking یا Rush Analytics راحت هستند: نیازی به فکر کردن درباره پروکسی، کپچا و سرورها نیست — فقط کلیدها را وارد می‌کنید و گزارش را دریافت می‌کنید. اما این راحتی هزینه‌ای دارد که به طور متناسب با تعداد عبارات و مناطق بررسی شده افزایش می‌یابد. اگر یک آژانس 15-20 مشتری داشته باشد و هر کدام 500-2000 کلید داشته باشند، هزینه اشتراک به سرعت به مبلغی می‌رسد که با حقوق یک متخصص جوان قابل مقایسه است.

دلیل دوم — انعطاف‌پذیری. در یک سرویس آماده نمی‌توانید فرکانس بررسی را برای کلیدهای خاص تغییر دهید، منطق سفارشی اضافه کنید (به عنوان مثال، نه تنها موقعیت، بلکه اسنیپت، وجود لینک‌های سریع یا نظرات را پیگیری کنید)، یا داده‌های خام را به سیستم BI خود منتقل کنید. ردیاب خود این مشکلات را حل می‌کند، اما به زیرساخت نیاز دارد: سرور، پایگاه داده، اسکریپت‌های پارسینگ و، مهم‌تر از همه، پروکسی برای دور زدن حفاظت موتورهای جستجو از درخواست‌های خودکار.

دلیل سوم — کنترل بر داده‌ها. آژانس‌هایی که با مشتریان بزرگ تحت NDA کار می‌کنند، همیشه آماده نیستند که لیست عبارات کلیدی و دامنه‌ها را به خدمات ابری خارجی منتقل کنند. ردیاب خود اجازه می‌دهد همه چیز را در زیرساخت خود نگه دارید.

هزینه بررسی موقعیت‌ها از چه چیزی تشکیل می‌شود

قبل از محاسبه هزینه‌ها، باید مکانیک را درک کنید: برای دانستن موقعیت یک وب‌سایت برای یک عبارت کلیدی، پارسر باید یک درخواست به نتایج یاندکس یا گوگل ارسال کند، صفحه HTML نتایج را دریافت کند و دامنه مورد نظر را در آن پیدا کند. برای 1000 کلید در روز — این حداقل 1000 درخواست است، و اگر هر دو موتور جستجو و چندین منطقه را بررسی کنید، این عدد 2-4 برابر می‌شود.

موتورهای جستجو به شدت درخواست‌های خودکار از یک IP را مسدود می‌کنند: پس از 20-50 درخواست متوالی از یک آدرس، یاندکس شروع به نمایش کپچا می‌کند و گوگل — IP را به طور موقت برای چند ساعت مسدود می‌کند. بنابراین هر درخواست باید از طریق یک پروکسی جداگانه یا پروکسی که به طور مکرر تغییر می‌کند، انجام شود. از این رو، هزینه اصلی — نه سرور و نه اسکریپت، بلکه به طور خاص زیرساخت پروکسی است.

ساختار کامل هزینه‌ها به این صورت است:

  • پروکسی برای چرخش IP — هزینه متغیر اصلی، بستگی به حجم درخواست‌ها دارد
  • سرور یا VPS برای اجرای اسکریپت‌ها بر اساس زمان‌بندی — مبلغ ثابت و کمی
  • حل کپچا (خدمات ضد کپچا) — هزینه اضافی، اگر پروکسی‌ها کیفیت کافی نداشته باشند
  • زمان توسعه‌دهنده برای نوشتن و پشتیبانی از پارسر — هزینه یک‌باره و دوره‌ای
  • ذخیره‌سازی و تجسم داده‌ها — پایگاه داده، داشبورد، معمولاً هزینه‌های حداقلی

اشتراک در مقابل ردیاب خود: مقایسه بر اساس هزینه‌ها

برای ارزیابی اینکه چه زمانی ردیاب خود بهتر از اشتراک است، راحت است که هزینه‌ها را به طور مستقیم مقایسه کنید. در زیر — جدول خلاصه‌ای بدون وابستگی به تعرفه‌های خاص، که منطق انتخاب را نشان می‌دهد.

پارامتر سرویس آماده (اشتراک) ردیاب موقعیت خود
هزینه برای 1000 کلید/روز به طور متناسب با طرح تعرفه افزایش می‌یابد، مبلغ ثابت ماهانه از ترافیک پروکسی + اجاره سرور تشکیل می‌شود، به آرامی مقیاس‌پذیر است
انعطاف‌پذیری تنظیمات محدود به عملکرد سرویس کامل — هر فرکانس، منطقه، عمق نتایج
نیاز به توسعه‌دهنده خیر بله، در شروع و به طور دوره‌ای برای پشتیبانی
ریسک مسدود شدن/کپچا بر عهده سرویس است بر عهده شماست، با پروکسی و تأخیرها حل می‌شود
نقطه سر به سر — معمولاً از 3000-5000 کلید در روز و بالاتر

نتیجه‌گیری از جدول ساده است: در حجم کم کلیدها (تا 2000-3000 در روز) اشتراک تقریباً همیشه به صرفه‌تر است، زیرا هزینه‌های توسعه و پشتیبانی از راه‌حل خود جبران نمی‌شود. اما در حجم‌های بالا — از چند هزار کلید در روز، به ویژه اگر نیاز به بررسی چندین بار در روز یا در مناطق مختلف باشد — زیرساخت خود شروع به برنده شدن از نظر اقتصادی می‌کند.

محاسبه پروکسی برای 1000 کلید در روز

سوال اصلی در هزینه — چند پروکسی برای 1000 درخواست در روز بدون مسدود شدن و کپچا نیاز است. بیایید محدودیت‌های ایمن متوسطی را که در عمل توسط پارسرهای نتایج استفاده می‌شود، در نظر بگیریم:

  • یاندکس: 30-50 درخواست از یک IP در روز بدون ریسک کپچا با تأخیرهای تصادفی بین درخواست‌ها 10-30 ثانیه
  • گوگل: 15-25 درخواست از یک IP در روز، سیستم سریع‌تر و سخت‌تر مسدود می‌کند

اگر فقط 1000 کلید را در یاندکس بررسی می‌کنید، با محدودیت 40 درخواست در IP به حداقل 25 آدرس منحصر به فرد در روز نیاز دارید. با در نظر گرفتن تلاش‌های مجدد در صورت درخواست‌های ناموفق و ذخیره‌ای برای مسدودیت‌های موقت، 30-40 IP را در نظر بگیرید. اگر هر دو موتور جستجو را بررسی می‌کنید، این عدد دو برابر می‌شود — به حدود 60-80 IP در روز نیاز خواهید داشت.

نکته مهم: هنگام کار با یک مجموعه IP با چرخش بر اساس درخواست (نه بر اساس جلسه)، یک سرور پروکسی فیزیکی می‌تواند "بیشتر" آدرس‌های IP را "ببندد"، اگر ارائه‌دهنده چرخش دینامیک ارائه دهد. در این صورت محاسبه بر اساس حجم ترافیک انجام می‌شود — معمولاً یک بررسی موقعیت 50-200 کیلوبایت HTML وزن دارد، یعنی 1000 درخواست در روز — این 50-200 مگابایت ترافیک است، که بار غیر بحرانی‌ای حتی برای تعرفه متوسط است.

مثال محاسبه برای 1000 کلید در روز (یاندکس + گوگل):

2000 درخواست در روز ÷ (30 درخواست به طور متوسط در IP) ≈ 65-70 IP منحصر به فرد در روز. با وزن متوسط صفحه نتایج 100 کیلوبایت، ترافیک کل حدود 200 مگابایت در روز خواهد بود، یا حدود 6 گیگابایت در ماه — این عددی است که باید هنگام انتخاب تعرفه ترافیک از ارائه‌دهنده پروکسی در نظر بگیرید.

چه پروکسی‌هایی برای یاندکس و گوگل نیاز است

نوع پروکسی به طور مستقیم بر تعداد کپچا و مسدودیت‌هایی که دریافت می‌کنید تأثیر می‌گذارد، و بنابراین بر هزینه واقعی بررسی. بیایید سه گزینه را بررسی کنیم.

پروکسی‌های دیتاسنتر — ارزان‌ترین گزینه از نظر هزینه ترافیک، اما آنها در پایگاه‌های داده موتورهای جستجو شهرت بدی دارند: IP‌های دیتاسنتر به طور گسترده‌ای برای پارسینگ استفاده می‌شوند، بنابراین یاندکس و گوگل به سرعت آنها را شناسایی کرده و پس از چند درخواست کپچا را نمایش می‌دهند. برای بررسی کم‌فرکانس تعداد کمی از کلیدها پروکسی‌های دیتاسنتر هنوز هم می‌توانند استفاده شوند، اما در حجم 1000+ درخواست در روز، سهم کپچا بسیار بالا می‌رود و صرفه‌جویی در ترافیک با هزینه‌های ضد کپچا جبران می‌شود.

پروکسی‌های مسکونی — آدرس‌های IP کاربران واقعی خانگی، که موتورهای جستجو آنها را به عنوان ترافیک عادی در نظر می‌گیرند. سهم کپچا در اینجا به طور قابل توجهی کمتر است، که در حجم‌های بزرگ بررسی حیاتی است. برای پارسینگ نتایج برای 1000 و بیشتر کلید در روز، پروکسی‌های مسکونی معمولاً بهترین نسبت هزینه و ثبات را ارائه می‌دهند، به ویژه هنگام کار با گوگل، که سخت‌ترین مسدودیت‌ها را برای آدرس‌های دیتاسنتر اعمال می‌کند.

پروکسی‌های موبایلی — از IP‌های اپراتورهای موبایل استفاده می‌کنند، که اغلب در میان هزاران مشترک واقعی تغییر می‌کنند (NAT)، بنابراین یک آدرس می‌تواند "مال" کاربران مختلف در طول روز باشد. این امر در پارسینگ تهاجمی حداکثر زنده‌مانی را فراهم می‌کند، اما هزینه بیشتری دارد. پروکسی‌های موبایلی توجیه‌پذیر هستند اگر شما موقعیت‌ها را در نتایج موبایل به طور جداگانه از دسکتاپ بررسی کنید یا با درخواست‌های منطقه‌ای خاص یاندکس کار کنید.

نوع پروکسی سهم کپچا در 1000 درخواست کی استفاده شود
دیتاسنتر بالا تا 200-300 کلید در روز، فرکانس پایین
مسکونی پایین 1000+ کلید در روز، گوگل و یاندکس
موبایلی حداقل نتایج موبایل، مناطق پیچیده

تنظیمات مرحله به مرحله ردیاب خود

فرآیند ساخت ردیاب موقعیت خود را مرحله به مرحله بررسی می‌کنیم — بدون غوطه‌وری عمیق در کد، در سطح معماری راه‌حل.

  1. انتخاب منبع داده. مشخص کنید که آیا شما به طور مستقیم نتایج موتور جستجو را از طریق درخواست‌های HTTP پارس می‌کنید یا از مرورگر بدون سر (به عنوان مثال، از طریق Puppeteer/Playwright) برای شبیه‌سازی کاربر واقعی استفاده می‌کنید. گزینه دوم در برابر حفاظت ضد ربات قابل اعتمادتر است، اما کندتر و از نظر منابع سرور گران‌تر است.
  2. تنظیم مجموعه پروکسی. یک ارائه‌دهنده پروکسی با چرخش IP بر اساس درخواست یا زمان را متصل کنید. برای یاندکس و گوگل بهتر است از مجموعه‌های پروکسی مختلف استفاده کنید، زیرا آستانه‌های مسدودسازی سیستم‌ها متفاوت است.
  3. منطق تلاش‌های مجدد. اگر درخواست کپچا یا خطا برگرداند، اسکریپت باید به طور خودکار IP را تغییر داده و درخواست را تکرار کند، نه اینکه فقط خطا را ثبت کند.
  4. پارسینگ نتیجه. موقعیت دامنه مورد نظر در نتایج از HTML دریافت شده استخراج می‌شود — معمولاً از طریق جستجو در تگ‌های لینک و مقایسه با دامنه مشتری.
  5. ذخیره‌سازی تاریخچه. نتایج در پایگاه داده با تاریخ بررسی ذخیره می‌شوند تا بتوان گراف‌های دینامیک موقعیت‌ها را ساخت.
  6. برنامه‌ریزی زمان‌بندی. اسکریپت به صورت روزانه (یا بیشتر) از طریق cron یا برنامه‌ریز وظایف اجرا می‌شود، به طور یکنواخت 1000 درخواست را در زمان توزیع می‌کند تا بار اوج بر روی مجموعه پروکسی ایجاد نشود.

مثال کد بررسی موقعیت‌ها با پایتون

در زیر — یک مثال ساده از منطق درخواست به نتایج جستجو از طریق پروکسی با چرخش. این یک چارچوب نمایشی است که اصل کار را نشان می‌دهد، نه یک راه‌حل آماده.

import requests
import random
import time

PROXY_LIST = [
    "http://user:[email protected]:8000",
    "http://user:[email protected]:8000",
    # ... مجموعه پروکسی از صدها آدرس
]

HEADERS = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

def check_position(keyword, domain, search_engine="yandex"):
    proxy = random.choice(PROXY_LIST)
    proxies = {"http": proxy, "https": proxy}

    if search_engine == "yandex":
        url = f"https://yandex.ru/search/?text={keyword}"
    else:
        url = f"https://www.google.com/search?q={keyword}"

    try:
        response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=10)
        if "captcha" in response.text.lower():
            return None  # نیاز به چرخش IP و تکرار درخواست
        position = find_domain_position(response.text, domain)
        return position
    except requests.RequestException:
        return None

def find_domain_position(html, domain):
    # منطق ساده برای جستجوی موقعیت دامنه در نتایج
    results = extract_links(html)
    for i, link in enumerate(results, start=1):
        if domain in link:
            return i
    return None

for keyword in keyword_list:
    pos = check_position(keyword, "example.com")
    save_to_db(keyword, pos)
    time.sleep(random.uniform(5, 15))  # تأخیر تصادفی بین درخواست‌ها
  

در یک پروژه واقعی، به جای پارسینگ دستی HTML، معمولاً از مرورگر بدون سر با تغییر User-Agent و fingerprint استفاده می‌شود، و مجموعه پروکسی از طریق ارائه‌دهنده با چرخش خودکار در سطح endpoint متصل می‌شود — این نیاز به نگهداری لیست آدرس‌ها به صورت دستی را از بین می‌برد و مقیاس‌پذیری را تا چند هزار درخواست در روز تسهیل می‌کند.

چقدر واقعاً می‌توان صرفه‌جویی کرد

برای پاسخ به سوال صرفه‌جویی، باید دو مدل هزینه را در دینامیک با افزایش حجم کلیدها مقایسه کرد.

در حجم کم — تا 1000-2000 کلید در روز — هزینه اشتراک برای ردیاب آماده معمولاً با هزینه‌های کل توسعه و پشتیبانی از راه‌حل خود قابل مقایسه یا حتی کمتر است، اگر زمان متخصص را در نظر بگیرید. توسعه یک پارسر حداقلی قابل استفاده از صفر تا چند روز تا چند هفته طول می‌کشد، به علاوه پشتیبانی دوره‌ای در صورت تغییر در طراحی نتایج جستجو — و یاندکس و گوگل به طور مکرر طراحی نتایج را تغییر می‌دهند.

نقطه عطف زمانی است که حجم بررسی به چند هزار کلید در روز افزایش یابد یا نیاز به بررسی موقعیت‌ها چندین بار در روز، در مناطق و دستگاه‌های مختلف (دسکتاپ/موبایل) باشد. در این سناریو، هزینه اشتراک آماده به طور خطی یا حتی پیشرفته با حجم افزایش می‌یابد، در حالی که هزینه‌های ردیاب خود به مراتب کندتر افزایش می‌یابد — هزینه اصلی (ترافیک پروکسی) به شدت افزایش نمی‌یابد، مانند طرح‌های تعرفه خدمات SaaS هنگام انتقال به سطح بعدی بسته.

راهنمای عملی برای آژانس‌ها: اگر شما موقعیت‌های 5-10 و بیشتر مشتری را به طور همزمان پیگیری می‌کنید، حجم کل معمولاً بیش از 5000-10000 عبارت کلیدی در روز می‌شود — دقیقاً در این مقیاس، ردیاب خود تقریباً همیشه به صرفه‌تر از هر اشتراک آماده‌ای است، به شرطی که در تیم کسی باشد که بتواند پارسر را پشتیبانی کند.

اشتباهات رایج در پارسینگ مستقل

در عمل، بیشتر مشکلات با ردیاب موقعیت خود به کد مربوط نمی‌شود، بلکه به کم‌ارزشی زیرساخت‌های زیرساختی مربوط می‌شود.

  • صرفه‌جویی در پروکسی. تلاش برای صرفه‌جویی در پروکسی‌های ارزان دیتاسنتر منجر به کپچاهای فراوانی می‌شود که باید از طریق خدمات ضد کپچا خارجی حل شوند — در نهایت، هزینه‌های کل بالاتر از استفاده از پروکسی‌های با کیفیت بهتر در ابتدا خواهد بود.
  • عدم وجود تأخیر بین درخواست‌ها. درخواست‌های متوالی بسیار سریع از یک IP بلافاصله توجه سیستم‌های ضد ربات را جلب می‌کند، حتی اگر IP با کیفیت باشد.
  • نادیده گرفتن منطقه‌ای. یاندکس نتایج متفاوتی را بسته به منطقه کاربر نشان می‌دهد — بدون جغرافیای صحیح پروکسی، داده‌های مربوط به موقعیت‌ها نادرست خواهد بود.
  • عدم وجود نظارت بر سلامت پارسر. موتورهای جستجو به طور دوره‌ای طراحی صفحه نتایج را تغییر می‌دهند، و بدون هشدارها در مورد کاهش موفقیت پارسینگ، ممکن است هفته‌ها داده‌های خالی یا نادرست جمع‌آوری کنید، بدون اینکه متوجه شوید.
  • نادیده گرفتن نتایج موبایل. نتایج دسکتاپ و موبایل اغلب متفاوت هستند، و اگر موقعیت موبایل برای مشتری مهم باشد، به یک خط پارسینگ جداگانه با User-Agent‌های مربوطه و، در ایده‌آل، IP‌های موبایل نیاز است.

نتیجه‌گیری

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

اگر قصد دارید ردیاب موقعیت برای 1000 و بیشتر کلید در روز بسازید، با محاسبه ترافیک و مجموعه آزمایشی پروکسی برای یک نمونه کوچک شروع کنید. برای پارسینگ پایدار یاندکس و گوگل در چنین حجم‌هایی، منطقی است که بلافاصله پروکسی‌های مسکونی را در نظر بگیرید — آنها حداقل سهم کپچا را با هزینه مناسب ترافیک ارائه می‌دهند و به خوبی با افزایش تعداد مشتریان تحت پیگیری مقیاس‌پذیر هستند.