Indexing API گوگل؛ کاربرد مجاز، محدودیت‌ها و جایگزین درست

Indexing API گوگل راهی برای اطلاع‌دادن مستقیم تغییرات دو نوع صفحه به گوگل است: آگهی‌های شغلی و صفحات پخش زنده. این API برای فرستادن همه مقاله‌ها، محصولات یا صفحات خدمات ساخته نشده و استفاده از آن به معنی ایندکس قطعی یا رتبه‌گرفتن سریع‌تر نیست.

اگر صفحه‌ای عادی منتشر کرده‌اید، مسیر درست معمولاً ترکیبی از لینک داخلی قابل خزش، sitemap به‌روز، پاسخ فنی سالم و محتوای ارزشمند است. برای تعداد کمی URL نیز می‌توان از گزینه Request Indexing در URL Inspection استفاده کرد. انتخاب ابزار باید براساس نوع صفحه و مشکل واقعی انجام شود، نه وعده «ایندکس فوری».

این راهنما محدوده مجاز API، تفاوت ابزارهای گوگل و روند عیب‌یابی را توضیح می‌دهد. هدف آن اجرای میان‌بر نیست. در پروژه‌های سئو سایت در گوگل ابتدا مشخص می‌شود URL کشف نشده، خزیده نشده یا پس از خزش برای ایندکس انتخاب نشده است؛ چون هر وضعیت راه‌حل جداگانه‌ای دارد.

Indexing API گوگل دقیقاً چه کاری انجام می‌دهد؟

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

در درخواست به API، یک URL و نوع اعلان ارسال می‌شود. نوع URL_UPDATED برای صفحه تازه یا ویرایش‌شده و URL_DELETED برای صفحه حذف‌شده است. پاسخ موفق فقط دریافت اعلان را تأیید می‌کند. از روی کد موفق درخواست نمی‌توان نتیجه گرفت که Googlebot صفحه را دیده یا نسخه تازه آن را ایندکس کرده است.

API امکان بررسی آخرین اعلان ثبت‌شده برای یک URL را نیز دارد. این وضعیت با گزارش ایندکس یکسان نیست. ممکن است اعلان امروز ثبت شده باشد، ولی صفحه هنوز خزیده نشده باشد. ممکن است صفحه خزیده شود و به‌دلیل canonical، noindex، کیفیت ناکافی یا شباهت زیاد با URL دیگری وارد ایندکس نشود.

درخواست‌های تکی را می‌توان در یک batch تا سقف صد فراخوانی HTTP کنار هم گذاشت. batch فقط تعداد اتصال‌ها را کم می‌کند و سهمیه را دور نمی‌زند. هر URL همچنان یک اعلان مستقل محسوب می‌شود. ساخت چند حساب برای عبور از سهمیه نیز برخلاف راهنمای گوگل است و می‌تواند دسترسی را متوقف کند.

چه صفحاتی اجازه استفاده از Indexing API را دارند؟

طبق مستندات رسمی گوگل، این API فقط برای صفحه دارای داده ساختاریافته JobPosting یا BroadcastEvent جاسازی‌شده در VideoObject مجاز است. وجود یک ویدئو یا آگهی ساده کافی نیست؛ صفحه باید واقعاً همان نوع محتوا را ارائه کند و داده ساختاریافته آن با محتوای قابل مشاهده هماهنگ باشد.

صفحه فرصت شغلی معمولاً عمر محدود دارد و بعد از تکمیل ظرفیت باید سریع به‌روزرسانی یا حذف شود. پخش زنده نیز زمان‌بندی حساس دارد. همین ماهیت کوتاه‌عمر دلیل طراحی API است. گوگل می‌خواهد تغییر این صفحات را زودتر بداند تا نتیجه منقضی‌شده یا رویداد پایان‌یافته مدت زیادی در جست‌وجو نماند.

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

آیا Indexing API باعث ایندکس فوری یا رتبه بهتر می‌شود؟

خیر. API اعلان تغییر را سریع‌تر به صف بررسی گوگل می‌رساند، اما ایندکس فوری، ماندگاری در نتایج یا افزایش رتبه را تضمین نمی‌کند. گوگل پس از دریافت اعلان هنوز باید URL را بخزد، محتوای آن را تحلیل کند، نسخه canonical را انتخاب کند و ارزش نگهداری صفحه در ایندکس را بسنجد.

تفاوت خزش و ایندکس در اینجا تعیین‌کننده است. خزش یعنی Googlebot پاسخ URL را دریافت کرده؛ ایندکس یعنی سامانه‌های گوگل آن نسخه را برای فهرست جست‌وجو انتخاب کرده‌اند. راهنمای ایندکس شدن سایت در گوگل این مراحل را جدا توضیح می‌دهد. API فقط در بخش اطلاع‌رسانی و زمان‌بندی خزش نقش دارد.

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

عبارت‌هایی مانند «ایندکس تضمینی با API» یا «ارسال روزانه همه URLها» با توضیح رسمی گوگل هم‌خوان نیستند. اگر ابزار یا افزونه‌ای چنین گزینه‌ای دارد، باید بررسی کنید دقیقاً چه endpointی را صدا می‌زند، برای چه نوع صفحه‌ای و با چه حسابی. نصب افزونه به‌تنهایی استفاده را مجاز یا نتیجه را قابل تضمین نمی‌کند.

تفاوت Indexing API، URL Inspection، sitemap و لینک داخلی چیست؟

این چهار روش یک مسئله را حل نمی‌کنند. Indexing API اعلان صفحات کوتاه‌عمر واجد شرایط را می‌فرستد؛ URL Inspection وضعیت یک URL را بررسی می‌کند و برای چند آدرس امکان درخواست خزش دارد؛ sitemap فهرست URLهای مهم را معرفی می‌کند؛ لینک داخلی مسیر کشف و درک رابطه صفحات را می‌سازد.

در URL Inspection می‌توان نسخه موجود در ایندکس، آخرین خزش، canonical انتخاب‌شده و برخی موانع را دید. دکمه Request Indexing برای چند URL مهم مناسب است، ولی تکرار آن سرعت را بیشتر نمی‌کند. API مربوط به URL Inspection نیز فقط داده وضعیت ایندکس را برمی‌گرداند و endpoint عمومی برای ثبت درخواست ایندکس ندارد.

Sitemap برای مجموعه‌ای از URLهای canonical و قابل ایندکس ساخته می‌شود. ثبت یک URL در sitemap تضمین خزش یا ایندکس نیست، اما به کشف و تشخیص تغییرات کمک می‌کند. مقدار lastmod باید زمان تغییر معنادار محتوا را نشان دهد. تغییر صوری تاریخ بدون ویرایش واقعی سیگنال قابل اتکایی ایجاد نمی‌کند.

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

پیش‌نیازهای استفاده درست از Indexing API چیست؟

برای راه‌اندازی باید یک پروژه در Google Cloud بسازید، Indexing API را فعال کنید، service account ایجاد کنید و ایمیل آن را به‌عنوان مالک در property مربوط به Search Console اضافه کنید. سپس با اعتبارنامه همان حساب، access token می‌گیرید و درخواست را فقط برای URLهای همان سایت می‌فرستید.

افزودن service account به Search Console بخش مهم مجوز است. داشتن فایل JSON به‌تنهایی مالکیت سایت را ثابت نمی‌کند. این فایل کلید خصوصی دارد و نباید در مخزن عمومی، پوشه قابل دانلود وردپرس یا پیام‌های تیم قرار بگیرد. دسترسی آن را محدود کنید و در صورت افشا، کلید را باطل و جایگزین کنید.

پیش از ارسال اعلان، URL باید پاسخ واقعی و قابل دریافت داشته باشد. آگهی شغلی منتشرشده باید داده ساختاریافته معتبر، اطلاعات قابل مشاهده و وضعیت استخدام درست داشته باشد. صفحه پخش زنده نیز باید زمان و داده رویداد را دقیق ارائه کند. API خطای محتوایی یا اسکیما ناسازگار را جبران نمی‌کند.

سهمیه پیش‌فرض برای آزمایش و شروع محدود است و افزایش آن نیازمند درخواست جداگانه است. مقدار سهمیه را در کنسول پروژه ببینید، نه در یک آموزش قدیمی. اگر تعداد اعلان‌های شما غیرعادی زیاد است، ابتدا منطق برنامه را بررسی کنید؛ شاید هر بازدید یا تغییر جزئی بی‌دلیل یک اعلان تازه می‌فرستد.

روند صحیح ارسال، به‌روزرسانی و حذف URL چگونه است؟

هنگام انتشار یا تغییر معنادار یک صفحه واجد شرایط، اعلان URL_UPDATED بفرستید. وقتی آگهی یا پخش زنده حذف شد و URL دیگر وجود ندارد، ابتدا وضعیت واقعی سرور و داده صفحه را اصلاح کنید و سپس URL_DELETED بفرستید. اعلان باید بازتاب وضعیت واقعی URL باشد، نه جایگزین آن.

برای آگهی استخدامی پایان‌یافته دو سناریو دارید. اگر صفحه باقی می‌ماند، باید وضعیت و داده ساختاریافته آن نشان دهد فرصت بسته شده است. اگر صفحه حذف می‌شود، سرور باید وضعیت مناسب مانند ۴۰۴ یا ۴۱۰ بدهد. فرستادن URL_DELETED در حالی که صفحه با محتوای قبلی و کد ۲۰۰ باز است، پیام‌های متناقض می‌سازد.

پس از پاسخ موفق API، زمان درخواست، URL، نوع اعلان و کد پاسخ را در لاگ نگه دارید. این لاگ برای عیب‌یابی ضروری است و نشان می‌دهد برنامه چه چیزی فرستاده، اما معیار ایندکس نیست. وضعیت واقعی را بعداً در Search Console، URL Inspection و در صورت نیاز لاگ سرور بررسی کنید.

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

برای صفحات عادی چه جایگزینی بهتر است؟

برای مقاله، محصول یا صفحه خدمات، ابتدا قابلیت کشف و ایندکس‌پذیری را درست کنید. URL باید از یک صفحه مرتبط لینک داشته باشد، در sitemap canonical قرار بگیرد، پاسخ ۲۰۰ بدهد، noindex نداشته باشد و canonical آن به مقصد دیگری اشاره نکند. سپس کیفیت و تمایز محتوا را بررسی کنید.

در کنترل انتشار، فقط سبزشدن افزونه سئو کافی نیست. وضعیت HTTP، متای robots، canonical، رندر موبایل، لینک‌های داخلی و حضور URL در sitemap باید از خروجی نهایی بررسی شوند. یک روند کنترل کیفیت سئو پیش از انتشار جلوی بسیاری از صفحاتی را می‌گیرد که ظاهراً منتشر شده‌اند ولی برای گوگل پیام متناقض دارند.

اگر تنها چند صفحه مهم تازه منتشر شده‌اند، URL Inspection را باز کنید و پس از تست زنده، یک‌بار درخواست ایندکس بدهید. برای صدها URL از sitemap و ساختار لینک داخلی استفاده کنید. ثبت دستی گسترده زمان‌بر است و علت اصلی کشف ضعیف، صفحات یتیم یا معماری نامنظم را پنهان می‌کند.

صفحه تازه باید از نظر هدف با URLهای موجود فرق داشته باشد. چند مقاله با پاسخ تقریباً یکسان می‌توانند انتخاب canonical و ارزیابی ارزش صفحه را دشوار کنند. پیش از تولید، نتایج سایت را برای موضوع نزدیک ببینید و مشخص کنید صفحه تازه چه سؤال یا مسئله‌ای را حل می‌کند که محتوای فعلی پوشش نداده است.

اگر صفحه ایندکس نمی‌شود از کجا عیب‌یابی کنیم؟

از گزارش Page Indexing و URL Inspection شروع کنید و وضعیت را به سه مرحله تقسیم کنید: کشف، خزش و انتخاب برای ایندکس. اگر URL کشف نشده، مسیر لینک و sitemap را اصلاح کنید. اگر خزیده نمی‌شود، دسترسی و ظرفیت سرور را ببینید. اگر خزیده اما ایندکس نشده، کیفیت، تکرار و canonical را بررسی کنید.

در مرحله کشف، وجود URL در sitemap و لینک داخلی را تأیید کنید. لینک باید در HTML قابل خزش باشد و مقصد نهایی را مستقیم باز کند. لینک جاوااسکریپتی ناقص، مسیر چندمرحله‌ای یا صفحه‌ای که فقط از فیلتر داخلی قابل دسترسی است، کشف را ضعیف می‌کند. sitemap نیز نباید URL ریدایرکت، noindex یا نسخه غیرcanonical را فهرست کند.

در مرحله خزش، کد وضعیت، robots.txt، خطاهای DNS و سرور، زمان پاسخ و رفتار CDN را ببینید. پاسخ‌های ۵xx، محدودیت اشتباه فایروال و چالش ضدربات می‌توانند Googlebot را متوقف کنند. تست زنده URL Inspection و لاگ سرور دو زاویه متفاوت می‌دهند: یکی پاسخ گوگل و دیگری درخواست واقعی خزنده را ثبت می‌کند.

در مرحله انتخاب، canonical اعلامی و انتخابی گوگل را مقایسه کنید. محتوای بسیار مشابه، صفحه کم‌عمق، soft 404 یا نبود تقاضای مشخص می‌تواند باعث شود URL پس از خزش وارد ایندکس نشود. افزودن چند پاراگراف عمومی کافی نیست؛ صفحه باید پاسخ متمایز، شواهد مناسب و نقش روشنی در ساختار سایت داشته باشد.

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

اشتباه‌های رایج در استفاده از Indexing API چیست؟

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

خطای بعدی، ارسال مکرر URL بدون تغییر واقعی است. اگر Googlebot صفحه را می‌بیند ولی آن را انتخاب نمی‌کند، اعلان بیشتر کیفیت یا تمایز محتوا را عوض نمی‌کند. ابتدا دلیل وضعیت را از Search Console و خروجی صفحه پیدا کنید. هر بار فقط متغیری را اصلاح کنید که با همان دلیل ارتباط دارد.

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

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

جمع‌بندی

Indexing API گوگل ابزار عمومی برای ایندکس سریع همه صفحات نیست. استفاده مجاز آن به آگهی شغلی دارای JobPosting و پخش زنده دارای BroadcastEvent در VideoObject محدود است. برای صفحات عادی، لینک داخلی، sitemap معتبر، خروجی فنی سالم، محتوای متمایز و بررسی URL Inspection مسیر درست‌تری می‌سازند. پاسخ موفق API را نیز فقط تأیید دریافت اعلان بدانید و وضعیت ایندکس را جدا اندازه بگیرید.

سوالات متداول

منابع

• Google Search Central: Indexing API Quickstart
• Google Search Central: Ask Google to recrawl your URLs
• Google Search Console API: URL Inspection index.inspect