API سرچ کنسول رابط رایگان گوگل برای دریافت خودکار داده‌های جست‌وجوی سایت است. با آن می‌توان گزارش عملکرد صفحات را به‌صورت منظم ساخت، تغییر کلیک و نمایش را بین دو دوره مقایسه کرد و صفحات نیازمند بررسی را پیدا کرد. API داده را در اختیار برنامه می‌گذارد؛ دسته‌بندی، مقایسه و هشدارها را اسکریپت یا ابزار متصل به آن انجام می‌دهد.
فرض کنید می‌خواهید هر هفته بدانید کدام دسته فروشگاه افت کرده، کدام مقاله با سؤال‌های تازه دیده شده و عملکرد صفحات اصلاح‌شده چه تغییری داشته است. در پنل می‌توانید این موارد را بررسی کنید؛ با API می‌توانید دریافت داده و بخش‌های تکراری تحلیل را خودکار کنید. در این مقاله، کاربردهای عملی این کار را با مثال می‌بینیم.
منبع: رایگان‌بودن Search Console API
۱. گزارش صفحات را بدون خروجی‌گرفتن تکراری بسازید
اولین کاربرد API، دریافت منظم داده‌های عملکرد است. برنامه‌ای که به آن متصل می‌شود می‌تواند طبق زمان‌بندی، داده را بگیرد و در فایل، پایگاه داده یا داشبورد ذخیره کند.
برای مثال، یک گزارش هفتگی از صفحات خدمات بسازید که برای هر URL، کلیک، نمایش، CTR و میانگین جایگاه را کنار دوره قبل نشان دهد. لازم نیست هر هفته همان فیلترها را دوباره تنظیم و فایل‌ها را دستی به هم اضافه کنید.
- داده لازم: عملکرد به تفکیک صفحه و تاریخ.
- خروجی: جدول صفحات با مقادیر دوره فعلی، دوره قبل و میزان تغییر.
- کار بعدی: انتخاب چند صفحه با تغییر قابل‌توجه برای بررسی دقیق‌تر.
زمان آخرین دریافت موفق را هم در گزارش نمایش دهید؛ قطع‌شدن دریافت داده نباید به‌صورت صفرشدن کلیک نمایش داده شود.
۲. عملکرد دسته‌های سایت را جدا از هم ببینید
عدد کل سایت ممکن است افت یک بخش را پشت رشد بخش دیگری پنهان کند. با داده API می‌توانید گزارش مقاله‌ها، محصولات، دسته‌بندی‌ها و صفحات خدمات را جدا بسازید.
اگر ساختار URL منظم باشد، مسیر صفحه به دسته‌بندی کمک می‌کند؛ در غیر این صورت، فهرست URLها را از وردپرس بگیرید و نوع صفحه را در فایل تحلیل به آن اضافه کنید. «دسته محصول» یا «نام نویسنده» را نباید فیلد آماده سرچ کنسول فرض کرد؛ این اطلاعات از سایت خودتان می‌آیند.
| گروه صفحه | سؤال گزارش | بررسی بعدی |
|---|---|---|
| صفحات دسته‌بندی فروشگاه | کدام دسته کمتر از قبل ورودی می‌گیرد؟ | تغییر عبارت‌ها، جایگاه و وضعیت کالاها |
| مقاله‌های آموزشی | کدام موضوع بیشتر دیده شده است؟ | ارتباط سؤال‌های کاربران با پاسخ مقاله |
| صفحات خدمات | کدام صفحه با عبارت‌های مرتبط دیده می‌شود اما کلیک کمی می‌گیرد؟ | جایگاه، عنوان، نوع جست‌وجو و رقبا |
مقایسه را تا جای ممکن در همان گروه انجام دهید. رفتار جست‌وجوی یک آموزش رایگان با صفحه فروش یک محصول یکسان نیست.
۳. تغییرات مهم را در میان صدها صفحه پیدا کنید
با مقایسه دو دوره می‌توانید فهرستی از صفحه‌های دارای افت یا رشد بسازید. API خودش علت تغییر را اعلام نمی‌کند؛ برنامه شما داده دو دوره را کنار هم قرار می‌دهد تا دامنه بررسی کوچک‌تر شود.
برای شروع، دو بازه هم‌طول با ترکیب روزهای هفته مشابه انتخاب کنید و فقط روزهایی را مقایسه کنید که داده نهایی دارند. برای فعالیت‌های فصلی، مقایسه با دوره قبل را در کنار زمینه تقاضا بخوانید.
| الگوی مشاهده‌شده | چه چیزی را بررسی کنیم؟ |
|---|---|
| کلیک کمتر، نمایش تقریباً ثابت | جایگاه، ترکیب عبارت‌ها، عنوان و تغییر شکل نتایج |
| کلیک و نمایش هر دو کمتر | تقاضا، رتبه، پوشش عبارت‌ها و وضعیت صفحات |
| نمایش بیشتر، کلیک تقریباً ثابت | آیا صفحه برای عبارت‌های تازه یا در جایگاه‌های پایین‌تر دیده شده است؟ |
| افت محدود به موبایل | داده عبارت‌ها و صفحات در همان دستگاه و سپس وضعیت تجربه موبایل |
اگر خروجی را به ابزار هشدار وصل می‌کنید، تغییر عددی و درصدی را با هم لحاظ کنید. افت از دو کلیک به یک کلیک، ۵۰ درصد است؛ اما لزوماً مهم‌ترین مسئله سایت نیست.
مثال عملی: چرا کلیک کمتر همیشه به معنی افت رتبه نیست؟
اعداد جدول زیر فرضی‌اند و عملکرد یک گروه ثابت از صفحات فروشگاهی را در دو بازه ۲۸ روزه نشان می‌دهند. نوع جست‌وجو و فیلتر دستگاه در دو گزارش یکسان است.
| شاخص | دوره قبل | دوره فعلی |
|---|---|---|
| نمایش | ۲۰٬۰۰۰ | ۲۰٬۰۰۰ |
| کلیک | ۸۰۰ | ۵۰۰ |
| CTR | ۴٪ | ۲٫۵٪ |
| میانگین جایگاه | ۵٫۲ | ۵٫۳ |
کلیک ۳۷٫۵ درصد کم شده؛ آیا رتبه صفحات افت کرده است؟
«کلیک کم شده، پس رتبه‌ها افت کرده‌اند و باید متن همه صفحات را بازنویسی کنیم.»
«نمایش تقریباً ثابت است و میانگین جایگاه تغییر کمی دارد. ابتدا افت کلیک را به تفکیک صفحه، عبارت و دستگاه بررسی کنیم؛ شاید ترکیب جست‌وجوها یا انتخاب کاربران در نتایج تغییر کرده باشد. میانگین کل هم می‌تواند افت بعضی عبارت‌ها را پنهان کند.»
کار بعدی: استخراج صفحه‌ها و عبارت‌های دارای بیشترین کاهش کلیک و بررسی نتایج همان جست‌وجوها.
نتیجه قابل‌اتکا: این جدول محل شروع بررسی را نشان می‌دهد؛ علت افت هنوز اثبات نشده است.
در یک گزارش خودکار، می‌توان همین محاسبه را برای همه گروه‌های صفحه تکرار کرد و فقط موارد نیازمند بررسی را در خروجی آورد. اگر بررسی به مشکل ایندکس رسید، ادامه کار باید روی وضعیت فنی URL متمرکز شود.
۴. سؤال‌های کاربران را کنار صفحه پاسخ‌دهنده قرار دهید
ترکیب صفحه و عبارت جست‌وجو کمک می‌کند ببینید هر مقاله با چه سؤال‌هایی دیده شده است. در فایل تحلیل می‌توانید عبارت‌های پرسشی را جدا کنید و پاسخ همان صفحه را بررسی کنید.
مثلاً اگر یک راهنمای نصب افزونه با عبارت «چرا افزونه فعال نمی‌شود» نمایش می‌گیرد، متن آن را از نظر خطاهای فعال‌سازی مرور کنید. اگر پاسخ وجود ندارد و سؤال با موضوع مقاله مرتبط است، افزودن یک بخش عیب‌یابی می‌تواند مفید باشد. اگر پاسخ از قبل کامل است، صرف دیدن عبارت جدید دلیل اضافه‌کردن متن نیست.
این بررسی را برای عبارت‌هایی که در چند دوره دیده می‌شوند و نمایش قابل بررسی دارند در اولویت بگذارید. داده API به شما می‌گوید کجا را نگاه کنید؛ تشخیص اینکه یک سؤال به همان صفحه تعلق دارد یا به راهنمای مستقل نیاز دارد، به محتوا و نیت کاربر وابسته است.
۵. عملکرد صفحات اصلاح‌شده را پیگیری کنید
وقتی تاریخ و نوع تغییر صفحه را کنار داده جست‌وجو ذخیره کنید، می‌توانید عملکرد قبل و بعد از اصلاح را منظم‌تر بررسی کنید. تاریخ ویرایش و توضیح تغییر از سیستم مدیریت محتوا یا یادداشت شما می‌آید، نه از API سرچ کنسول.
یک جدول ساده کافی است: URL، تاریخ تغییر، توضیح اصلاح، بازه قبل، بازه بعد و نتیجه بررسی. «تکمیل پاسخ سؤال پرتکرار» با «تغییر عنوان» دو اقدام متفاوت‌اند؛ آن‌ها را با عنوان مبهم «آپدیت شد» ثبت نکنید.
بعد از اصلاح، کلیک، نمایش و عبارت‌های مرتبط را بررسی کنید. افزایش کلیک پس از ویرایش به‌تنهایی ثابت نمی‌کند ویرایش علت رشد بوده است؛ تغییر تقاضا و نتایج جست‌وجو را هم لحاظ کنید. گروهی از صفحات مشابهِ بدون تغییر می‌تواند زمینه مقایسه بدهد، اما جای آزمون کنترل‌شده را نمی‌گیرد.
۶. وضعیت ایندکس یک فهرست URL را مرور کنید
برای بررسی ایندکس، بخش URL Inspection API از گزارش عملکرد جداست. می‌توانید فهرستی از صفحات مهم را به آن بدهید، پاسخ هر URL را ذخیره کنید و موارد نیازمند بررسی را جدا ببینید؛ تعداد درخواست‌ها تابع سهمیه است.
این کاربرد برای مرور صفحات تازه‌منتشرشده یا URLهای مهمی که در گزارش عملکرد تغییر کرده‌اند مفید است. پاسخ API درباره اطلاعات نسخه ایندکس‌شده است؛ تست زنده یا درخواست ایندکس انجام نمی‌دهد.
منبع: معرفی URL Inspection API
نکته‌ای که در ساخت گزارش نباید نادیده بگیرید
جزئیات بیشتر همیشه به معنی گزارش کامل‌تر نیست. گوگل توضیح می‌دهد که هنگام دریافت داده به تفکیک صفحه یا عبارت، ممکن است بخشی از داده حذف شود؛ API هم بازگشت همه ردیف‌ها را تضمین نمی‌کند.
پیشنهاد ما این است که گزارش مجموع سایت را از جدول جزئیات صفحه‌ـ‌عبارت جدا نگه دارید. برای مجموع، یک درخواست بدون ابعاد و فیلترهای صفحه و عبارت با تجمیع مناسب property داشته باشید؛ برای یافتن فرصت‌ها، گزارش جزئی را جدا دریافت کنید. کنار هر گزارش، فیلترها و نوع تجمیع را ثبت کنید تا بعداً اختلاف اعداد را با افت واقعی ترافیک اشتباه نگیرید. جمع ردیف‌های جدول جزئی را به‌اجبار جای عدد کل سایت ننشانید.
مبنای فنی: روش دریافت داده Performance
اشتباهات رایج در تحلیل خودکار سرچ کنسول
میانگین ساده گرفتن از CTR صفحه‌ها: برای ردیف‌های هم‌سطح و غیرهم‌پوشان، مجموع کلیک را بر مجموع نمایش تقسیم کنید. میانگین درصدها وزن نمایش هر ردیف را نادیده می‌گیرد.
مقایسه داده ناقص با دوره کامل: برای مقایسه دوره‌ای، داده نهایی و بازه‌های قابل‌مقایسه را به کار ببرید.
تفسیر ردیف غایب به‌عنوان صفر: نبود یک ردیف در خروجی لزوماً به معنی صفر بودن عملکرد آن نیست؛ دریافت ناموفق و محدودیت داده را بررسی کنید.
اجرای پیشنهاد بدون دیدن صفحه: هشدار یا اولویت ابزار، نقطه شروع بررسی است؛ دستور قطعی برای حذف، ادغام یا بازنویسی نیست.
چطور این کاربردها را روی سایت خودمان شروع کنیم؟
با یک گزارش مشخص شروع کنید؛ مثلاً مقایسه هفتگی صفحات خدمات. URLها، بازه مقایسه و شاخص‌های لازم را تعیین کنید و یک نمونه را دستی در پنل بررسی کنید. سپس دریافت و ذخیره همان داده را با یک اسکریپت یا ابزار متصل به API تکرار کنید.
حسابی که ابزار با آن به سرچ کنسول وصل می‌شود باید به property دسترسی داشته باشد. برای جزئیات اتصال و نمونه درخواست، راهنمای فنی API سرچ کنسول در سایت سبا بصیری را ببینید.
سایتتان هنوز به سرچ کنسول متصل نیست؟
پیش‌نیاز دریافت داده با API، دسترسی به سایت در سرچ کنسول است. اگر در مرحله اتصال و تنظیم Google Search Console به کمک نیاز دارید، سرویس «اتصال سایت به سرچ کنسول» پالت را بررسی کنید. پس از این مرحله می‌توانید مسیر احراز هویت و دریافت داده API را دنبال کنید.
در وردپرس، پالت دیتا آنالیزر برای دریافت و تحلیل داده سرچ کنسول و اولویت‌بندی بررسی صفحات طراحی شده است. معرفی افزونه را ببینید تا مشخص شود کدام قابلیت آن با بررسی موردنظر شما مرتبط است.
داده سرچ کنسول دارید؛ اول کدام صفحه را بررسی می‌کنید؟
پالت دیتا آنالیزر برای کوتاه‌کردن مسیر دریافت داده تا اولویت‌بندی بررسی صفحات ساخته شده است. اگر می‌خواهید قابلیت‌های تحلیل و روش استفاده از افزونه را بشناسید، معرفی آن را بخوانید و تناسبش را با نیاز سایت خود بسنجید.
پرسش‌های رایج درباره کاربرد API سرچ کنسول
آیا خود API گزارش یا هشدار آماده می‌سازد؟
خیر. API داده را برمی‌گرداند. زمان‌بندی دریافت، مقایسه دوره‌ها، نمودار و هشدار را برنامه یا ابزار متصل به آن پیاده می‌کند.
آیا برای چند صفحه هم به API نیاز داریم؟
برای بررسی موردی، پنل معمولاً کافی است. API زمانی کاربرد بیشتری دارد که همان بررسی را مرتب تکرار کنید یا بخواهید داده چند گروه صفحه را کنار هم بگذارید.
می‌توان داده چند سایت را در یک گزارش آورد؟
بله؛ ابزار می‌تواند داده propertyهایی را که به آن‌ها دسترسی دارید جداگانه بگیرد و کنار هم نمایش دهد. نام سایت و تنظیمات هر گزارش باید مشخص بماند.
آیا API داده فروش و موجودی کالا را هم می‌دهد؟
خیر. این اطلاعات باید از فروشگاه یا منبع مربوط دریافت و در مرحله تحلیل به داده صفحات متصل شوند.
آیا استفاده از API رتبه را افزایش می‌دهد؟
خود اتصال چنین اثری ندارد. فایده API در منظم‌شدن دریافت داده و زودتر پیداکردن تغییرات است؛ اقدام مناسب بعد از بررسی می‌تواند به بهبود سایت کمک کند.
جمع‌بندی
API سرچ کنسول زمانی مفید است که یک کار تکراری را از دوش شما بردارد: ساخت گزارش صفحات، مقایسه دوره‌ها، دنبال‌کردن تغییرها یا مرور وضعیت URLهای مهم. از یک کاربرد مشخص شروع کنید، خروجی را با نمونه‌های واقعی کنترل کنید و بعد دامنه گزارش را گسترش دهید. هر عدد باید به یک سؤال روشن درباره سایت کمک کند.
