سرچ کنسول را هفتگی چطور بخوانیم: ۵ گزارشی که تصمیم می‌سازد

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

این راهنما پنج گزارشی را جدا می‌کند که تصمیم می‌سازند، و بعد سراغ چیزهایی می‌رود که بیشتر راهنماهای فارسی از کنارشان رد می‌شوند: چرا جمع جدول با نمودار یکی نیست، چرا کوئری‌های رتبهٔ ۱۱ تا ۳۰ در جدول پیدایشان نمی‌کنی، و از کجا بفهمی تغییری که دادی اثر داشت یا فقط نوسان بود. آستانه‌ها و اعداد فنی این متن از مستندات رسمی خود گوگل است، و هر جا روش کاری اضافه شده، از داده جدا نوشته شده است.

سرچ کنسول چه چیزی را نشان می‌دهد و چه چیزی را نه

سرچ کنسول دادهٔ جست‌وجوی گوگل را می‌دهد. یعنی چه چیزی در نتایج جست‌وجو دیده شده، چند بار، و چند بار روی آن کلیک شده. هیچ‌چیز دربارهٔ بعد از کلیک نمی‌گوید؛ آن ماجرا از صفحهٔ فرود به بعد است و در ابزار دیگری اندازه‌گیری می‌شود.

آنچه در گزارش‌ها هست:

• Performance: کلیک، ایمپرشن، CTR و میانگین رتبه، جدا به تفکیک کوئری، صفحه، کشور، دستگاه و نوع نتیجه. نمای پیش‌فرض سه ماه گذشته است.
• Page indexing: کدام آدرس‌ها ایندکس شده‌اند، کدام نشده‌اند و دلیل ثبت‌شده‌شان چیست.
• Core Web Vitals: تجربهٔ واقعی کاربران، فقط برای آدرس‌های ایندکس‌شده.
• Sitemaps: وضعیت خواندن فایل سایتمپ؛ چه زمانی خوانده شده و چه خطایی داشته.
• Manual actions و Security issues: این دو گزارش خبری نیستند، هشدارند. اگر قرمز شدند، بقیهٔ کارها تعطیل است.

و آنچه در گزارش‌ها نیست — این فهرست مهم‌تر است:

• رفتار بعد از کلیک. سرچ کنسول نمی‌داند کاربر ماند یا رفت؛ کلیک یعنی کلیک.
• همهٔ کوئری‌ها. کوئری‌هایی که بسیار کم جست‌وجو شده‌اند بی‌نام می‌شوند و از جدول حذف می‌شوند. فهرست کامل هم ذخیره نمی‌شود: سرچ کنسول فقط مهم‌ترین ردیف‌ها را نگه می‌دارد و بقیه در خروجی انبوه قابل بازیابی‌اند، نه در رابط کاربری.
• علت. سرچ کنسول می‌گوید چه شد؛ نمی‌گوید چرا. هر جمله‌ای که با «چون» شروع شود، فرضیه است نه داده.
• رقبا و نتایج دیگران. رتبه را می‌دهد، فاصله با رقیب را نه.
• موتورهای دیگر. بینگ و بقیه در این گزارش نیستند.

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

پنج گزارشی که هر هفته باید بخوانی

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

ترتیب خواندن، وقتی وقت کم است:

1. نمودار ایمپرشن سایت در ۹۰ روز. یک نگاه. اگر شکل کلی سالم است، برو مرحلهٔ بعد. اگر شکسته است، امروز بقیهٔ گزارش‌ها را با این فرض بخوان که یک اتفاق سیستمی رخ داده.
2. Page indexing. تعداد آدرس‌های ایندکس‌نشده با دلیل‌های مشخص. هر افزایش ناگهانی، پیش از هر تحلیل محتوایی، باید توضیح فنی داشته باشد.
3. تب Pages در Performance. کدام آدرس‌ها بیشترین افت ایمپرشن را دارند؛ بیشتر از سه مورد را در یک هفته دنبال نکن.
4. تب Queries. فقط برای همان آدرس‌های مرحلهٔ ۳ و برای کوئری‌های رتبهٔ ۱۱ تا ۳۰.
5. Core Web Vitals. هفته‌ای یک نگاه کافی است؛ این گزارش با پنجرهٔ ۲۸ روزه حرکت می‌کند و هفتگی عوض نمی‌شود.

URL Inspection گزارش نیست، ابزار است: وقتی یک آدرس مشکوک شد، همان‌جا وضعیت پوشش، کنونیکال انتخاب‌شدهٔ گوگل و نتیجهٔ آزمایش زنده را می‌بینی. این ابزار را برای پرسش به کار ببر، نه برای گشتن.

تفاوت دادهٔ نهایی و دادهٔ تازه و چرا عدد امروز دروغ می‌گوید

دادهٔ سرچ کنسول لحظه‌ای نیست. مستندات گوگل می‌گوید دادهٔ جمع‌آوری‌شده معمولاً در ۲ تا ۳ روز در دسترس قرار می‌گیرد. پس عدد امروز، عدد یک روز کامل نیست؛ تصویری از یک روز در حال تکمیل است.

سه لایهٔ متفاوت در کار است و بیشتر اشتباه‌ها از قاطی کردنشان می‌آید:

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

در API همین تفکیک صریح است: پارامتر dataState با مقدار all دادهٔ تازه را هم برمی‌گرداند و با final فقط دادهٔ تثبیت‌شده را. اگر با all کار می‌کنی، پاسخ فیلد metadata.first_incomplete_date را هم دارد: اولین تاریخی که داده‌اش هنوز در حال تکمیل است. مستندات گوگل صریح می‌گوید همهٔ مقادیر بعد از این تاریخ ممکن است به‌طور محسوس تغییر کنند. یعنی مرز «قابل استناد» و «غیرقابل استناد» را خودِ پاسخ API به تو می‌دهد؛ کافی است بخوانی.

یک تلهٔ دوم هم هست که کمتر دیده می‌شود: منطقهٔ زمانی. دادهٔ روزانه در گزارش Performance با وقت اقیانوس آرام برچسب می‌خورد، نه وقت تهران. فقط نمای ۲۴ ساعته از ساعت محلی مرورگر تو استفاده می‌کند. برای خوانندهٔ ایرانی این یعنی یک روز سرچ کنسول حدود ساعت ۱۱ صبح تهران شروع می‌شود: ۱۰:۳۰ در تابستان و ۱۱:۳۰ در زمستان. اگر تحلیلت را با گزارش مشتری یا با Analytics روی مرز نیمه‌شب تهران هم‌تراز کنی، همیشه یک اختلاف یک‌روزه می‌بینی که واقعی نیست.

قاعدهٔ عملی: هر بازه‌ای که برای تصمیم‌گیری انتخاب می‌کنی، سه روز آخر را کنار بگذار. امروز فقط برای دیدن این است که «داده می‌آید یا نه»؛ برای قضاوت نیست.

گزارش Pages: تفکیک ایندکس‌شده و ایندکس‌نشده

گزارش Page indexing دو سبد دارد و یک درس: سبد ایندکس‌شده معمولاً حوصله‌برانگیز است، سبد ایندکس‌نشده تصمیم‌ساز. هر آدرس ایندکس‌نشده یک دلیل ثبت‌شده دارد و همان دلیل است که مسیر کار را تعیین می‌کند.

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

• Discovered – currently not indexed: گوگل آدرس را می‌داند — از یک لینک یا از سایتمپ — ولی هنوز خزشش نکرده. یعنی مشکل «یافتن» حل شده و مشکل «اولویت خزش» مانده. صفحه‌ای که از هیچ‌جای سایت لینک ندارد، حتی وقتی در سایتمپ هست، دیرتر خزیده می‌شود؛ روش پیدا کردنشان در راهنمای صفحات یتیم آمده است. اقدام: لینک داخلی از صفحه‌های مرتبط، نه درخواست ایندکس دوباره.
• Crawled – currently not indexed: خزیده شده و ایندکس نشده. اینجا بحث اولویت خزش نیست، بحث ارزش صفحه است: محتوای نازک، تکرار، یا شباهت زیاد با صفحه‌ای که از قبل ایندکس شده. اقدام: یکی کردن، غنی کردن، یا کنار گذاشتن.
• Duplicate, Google chose different canonical: گوگل آدرس دیگری را کانونیکال دانسته. این وضعیت همیشه خرابی نیست؛ ولی باید بدانی و آگاهانه انتخابش کنی. اگر صفحهٔ انتخابی گوگل اشتباه است، تفاوت محتوا و لینک داخلی را درست کن، نه فقط تگ کنونیکال را.
• Alternate page with proper canonical tag: صفحهٔ تکراری با کنونیکال درست. کاری لازم نیست؛ فقط مطمئن شو صفحهٔ اصلی واقعاً همان است که می‌خواهی.
• Excluded by «noindex» tag: خودت گفته‌ای ایندکس نشود. رایج‌ترین منبع این وضعیت، تنظیم قدیمی یک افزونهٔ سئو است که فراموش شده.
• Blocked by robots.txt و Blocked due to unauthorized request: دسترسی بسته است. اول robots یا احراز هویت سرور را چک کن.
• Soft 404 و Not found (404): صفحهٔ خالی یا حذف‌شده. اگر صفحه ارزش دارد، بازگردان؛ اگر نه، ریدایرکت به نزدیک‌ترین صفحهٔ مرتبط.
• Server error (5xx) و Redirect error: خطای سرور و زنجیرهٔ ریدایرکت شکسته. اینجا کار سئو نیست، کار سرور است؛ فهرست خطاهای رایج وردپرس نقطهٔ شروع است.

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

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

کوئری‌هایی که در بازهٔ ۱۱ تا ۳۰ گم می‌شوند

کوئری‌های رتبهٔ ۱۱ تا ۳۰ عجیب‌اند: ایمپرشن دارند، کلیک تقریباً ندارند. صفحهٔ دوم و ابتدای صفحهٔ سوم، همان جایی است که بیشترین فاصله با یک جهش واقعی وجود دارد و همان جایی که در نمای پیش‌فرض گزارش پیدایشان نمی‌کنی.

دلیلش سه چیز است، و هر سه در مستندات آمده:

1. مرتب‌سازی جدول بر اساس کلیک است. جدول Performance به‌طور پیش‌فرض بر پایهٔ تعداد کلیک نزولی مرتب می‌شود. کوئری‌ای که کلیک ندارد، هر چقدر هم ایمپرشن داشته باشد، ته فهرست می‌افتد.
2. جدول سقف دارد. جدول حداکثر ۱٬۰۰۰ ردیف نشان می‌دهد؛ ردیف‌های کم‌تکرار و دم‌بلند در جدول نمی‌آیند، هرچند در جمع نمودار حساب می‌شوند.
3. کوئری‌های کم‌جست‌وجو بی‌نام می‌شوند. کوئری‌هایی که تعداد کمی جست‌وجو شده‌اند از جدول حذف می‌شوند و فقط در جمع نمودار می‌مانند — مگر اینکه فیلتر کوئری اعمال کرده باشی. علاوه بر آن، سرچ کنسول فقط مهم‌ترین ردیف‌ها را ذخیره می‌کند و فهرست کامل را باید از خروجی انبوه گرفت.

پس روش درست، «نگاه کردن» نیست؛ «خروجی گرفتن» است:

1. در تب Queries، بازهٔ ۲۸ روزه با پایان سه روز قبل انتخاب کن.
2. خروجی بگیر. اگر ردیف‌های بیشتری می‌خواهی، از خروجی انبوه (Bulk data export) استفاده کن؛ در API هم سقف rowLimit تا ۲۵٬۰۰۰ ردیف است و صفحه‌بندی با startRow انجام می‌شود.
3. در صفحه‌گسترده، ستون Position را بین ۱۱ و ۳۰ فیلتر کن، ستون Impressions را نزولی مرتب کن. سرچ کنسول فیلتر «موقعیت» در رابط کاربری ندارد؛ این کار در فایل انجام می‌شود.
4. هر کوئری را به صفحه‌اش وصل کن (ستون Page) و آن‌هایی را بردار که صفحه‌شان واقعاً ارزش دارد.

حالا دو نوع مسئله را از هم جدا کن:

• ایمپرشن بالا، CTR نزدیک صفر: مشکل عنوان و توضیح است. کاربر نتیجه را می‌بیند و رد می‌کند. اینجا سریع‌ترین برد ممکن است.
• ایمپرشن بالا، رتبهٔ ۱۵ تا ۳۰: مشکل محتوا و ارتباط است. بازنویسی عنوان کمکی نمی‌کند؛ بخش گمشدهٔ صفحه یا لینک داخلی لازم است.

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

افت ناگهانی ایمپرشن: چهار علت رایج و ترتیب بررسی

افت ایمپرشن از افت کلیک بدتر است: کلیک می‌تواند به‌خاطر CTR پایین بیفتد، ولی ایمپرشن یعنی دیده‌شدن؛ وقتی دیده‌شدن کم می‌شود، ماجرا بزرگ‌تر از یک عنوان ضعیف است. و بیشتر افت‌هایی که «جریمه» خوانده می‌شوند، جریمه نیستند.

ترتیبی که باید بررسی کنی، از ارزان به گران:

1. آیا واقعی است؟ بازه را روی دادهٔ نهایی بگذار (پایان سه روز قبل) و ببین افت در کل سایت است یا در یک آدرس. افت یک آدرس با ایمپرشن کل ثابت، معمولاً نوسان است. صفحه‌ای که روزی یک یا دو ایمپرشن دارد، در بازهٔ سه‌روزه هیچ سیگنالی نمی‌دهد.
2. آیا قبل از تغییری که یادت هست شروع شده؟ تاریخ شروع افت را با تاریخ آخرین تغییر سایت مقایسه کن. اگر افت دو روز قبل از تغییر شروع شده، تغییر مقصر نیست.
3. فنی را چک کن. URL Inspection برای همان آدرس: ایندکس است؟ کنونیکال همان است که می‌خواهی؟ آزمایش زنده همان چیزی را برمی‌گرداند که باید؟ اگر وضعیت پوشش «ایندکس‌شده» است، افت رتبه‌ای است نه ایندکسی.
4. بخش‌بندی کن. ایمپرشن افت کرده یا CTR؟ اگر CTR افتاده و ایمپرشن نه، ماجرا در نتایج است نه در سایت تو. بخشی از این تغییرها بعد از تغییر چیدمان نتایج و گسترش پاسخ‌های هوش مصنوعی رخ می‌دهد؛ گزارش سه‌ماههٔ گوگل اندازهٔ این جابه‌جایی را نشان می‌دهد.
5. و فقط در آخر سراغ فرضیهٔ به‌روزرسانی الگوریتم برو. اگر مراحل یک تا چهار چیزی پیدا نکردند، باز هم «جریمه» نتیجهٔ قطعی نیست؛ فرضیه‌ای است که باید با دادهٔ هفته‌های بعد تأیید یا رد شود.

چطور یک تغییر را درست بسنجیم (پنجرهٔ ۱۴ روزه)

بیشتر «تحلیل‌ها» یک جملهٔ قصه‌گویی‌اند: چیزی عوض شد، عدد بالا رفت، پس کار کرد. برای اینکه این جمله ارزش داشته باشد، چهار چیز باید از قبل تعیین شده باشد.

• معیار. کدام عدد؟ کلیک، ایمپرشن، یا میانگین رتبه؟ فقط یکی را معیار اصلی بگذار.
• بخش. کدام آدرس یا کدام دستهٔ کوئری؟ اثر یک تغییر روی کل سایت تقریباً همیشه در نویز گم می‌شود.
• پنجره. ۱۴ روز قبل و ۱۴ روز بعد از تغییر.
• فرضیه. یک جمله که اگر نتیجه برعکس شد، رد شود. «انتظار دارم میانگین رتبهٔ این سه کوئری بهتر شود» فرضیه است؛ «انتظار دارم بهتر شود» نه.

روش اجرا:

1. تاریخ تغییر را یادداشت کن و فقط یک چیز را عوض کن. هم‌زمان عوض کردن عنوان، ساختار و لینک‌ها، هیچ نتیجه‌ای قابل نسبت‌دادن نمی‌سازد.
2. سه روز صبر کن تا دادهٔ نهایی برسد. این سه روز، بخشی از پنجرهٔ بعد است، نه بخشی از سنجش.
3. بازهٔ قبل و بعد را با همان طول و همان ترکیب روزهای هفته بگیر. هفتهٔ کاری و تعطیلات، الگوی ایمپرشن را عوض می‌کنند.
4. معیار دوم را هم نگاه کن، ولی تصمیم را با معیار اصلی بگیر. اگر ایمپرشن بالا رفت و کلیک نه، تغییر نیمه‌کاره بوده.
5. اگر تفاوت در حد چند درصد و در حد نوسان بود، «بی‌اثر» ثبت کن و برو سراغ قدم بعد. تغییرهای کوچک روی صفحه‌ای با ترافیک کم، هیچ‌وقت قابل اندازه‌گیری نیستند.

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

گزارش Core Web Vitals را کِی جدی بگیریم

این گزارش با بقیه فرق دارد: دادهٔ آزمایشگاهی نیست، دادهٔ واقعی کاربران است. سه متریک دارد — LCP، INP و CLS — و هر کدام را با صدک ۷۵ در ۲۸ روز گذشته می‌سنجد. یعنی عددی که می‌بینی، وضعیت ۷۵٪ بازدیدها است، نه میانگین.

آستانه‌ها:

• LCP: تا ۲٫۵ ثانیه خوب، تا ۴ ثانیه نیاز به بهبود، بیشتر از ۴ ثانیه ضعیف.
• INP: تا ۲۰۰ میلی‌ثانیه خوب، تا ۵۰۰ نیاز به بهبود، بیشتر از ۵۰۰ ضعیف.
• CLS: تا ۰٫۱ خوب، تا ۰٫۲۵ نیاز به بهبود، بیشتر از ۰٫۲۵ ضعیف.

سه نکته که خواندن این گزارش را عوض می‌کند:

• گروه آدرس، نه آدرس. گزارش بر اساس گروه‌هایی از آدرس‌های مشابه ساخته می‌شود و وضعیت هر گروه، بدترین متریکش است. اگر یک گروه CLS ضعیف داشته باشد، کل گروه «ضعیف» برچسب می‌خورد.
• گروه بدون دادهٔ کافی حذف می‌شود. صفحه‌ای که ترافیک کمی دارد، در این گزارش دیده نمی‌شود. نبودنش یعنی «خوب نیست»، یعنی «نمی‌دانیم».
• فقط آدرس‌های ایندکس‌شده. اگر صفحه‌ای ایندکس نیست، انتظار دیدنش را نداشته باش.

پس کِی جدی بگیریم؟ وقتی یک گروه در وضعیت Poor باشد و آن گروه شامل صفحه‌هایی باشد که برایت درآمد یا ترافیک می‌آورند، و این وضعیت در دو یا سه دورهٔ متوالی تکرار شود. یک روز قرمز روی یک گروه کم‌ترافیک، دستور کار نیست. تغییر قالب یا افزونه هم دلیل خوبی برای نگاه کردن است، چون معمولاً همان‌جا LCP یا CLS خراب می‌شود.

برای تفکیک دادهٔ میدانی از آزمایشگاهی، همین صفحه را در PageSpeed Insights باز کن: آنجا شرایط آزمایشگاهی و قابل تکرار است، در حالی که سرچ کنسول تجربهٔ واقعی کاربران را می‌دهد. عدد آزمایشگاهی برای پیدا کردن علت است، عدد میدانی برای تصمیم. بعد از اصلاح، اعتبارسنجی ۲۸ روزه طول می‌کشد؛ انتظار تغییر فردا را نداشته باش.

سایتمپ و درخواست ایندکس: کجا اثر دارد و کجا نه

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

کجا واقعاً کمک می‌کند:

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

درخواست ایندکس (Request indexing در URL Inspection) هم ابزار دقیقی است، نه دکمهٔ جادویی:

• برای چند آدرس مهم خوب است: صفحهٔ خدمات اصلی، صفحهٔ محصول تازه، مقاله‌ای که همین امروز منتشر شده.
• برای انبوه آدرس‌ها کار نمی‌کند. این ابزار برای بررسی موردی ساخته شده، نه برای فهرست هزارتایی.
• تکرارش اثر ندارد. زدن دوبارهٔ درخواست روی همان آدرس، صف را جلو نمی‌اندازد.
• مشکل کیفیت را حل نمی‌کند. صفحهٔ نازک، تکراری، یا با کنونیکال اشتباه، با درخواست ایندکس ایندکس نمی‌شود.

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

هفت عددی که در داشبورد ماهانه باید ثبت شود

هدف داشبورد ماهانه، به‌یاد آوردن نیست؛ قابل مقایسه کردن است. هفت عدد، با تعریف ثابت و بازهٔ ثابت. اگر تعریف عوض شود، ستون تاریخ بی‌ارزش می‌شود.

دو چیز را کنار هر عدد بنویس: تاریخ ثبت، و آخرین روزی که داده داشته. بدون این دو، سه ماه بعد نمی‌دانی ستون‌ها قابل مقایسه‌اند یا نه. اگر از خروجی استفاده می‌کنی، یادت باشد مقادیر نشان‌داده‌شده با علامت‌های ~ و - در فایل صفر می‌شوند؛ یعنی «داده نداریم» و «صفر» در فایل یکی می‌شوند. این تفاوت را در داشبورد دستی نگه دار.

اشتباه‌هایی که تحلیل را بی‌اعتبار می‌کند

این‌ها را در فهرست اشتباه‌ها گذاشتم چون هر کدام به‌تنهایی کافی است که یک گزارش ماه کامل بی‌ارزش شود:

• مقایسهٔ امروز با دیروز. امروز دادهٔ ناقص است. بازه‌ای که به سه روز آخر می‌رسد، در حال مقایسهٔ دو چیز نابرابر است.
• قاطی کردن نمودار و جدول. نمودار در سطح property جمع می‌زند و جدول در سطح صفحه. نتیجه: جمع جدول با نمودار یکی نیست و این اختلاف طبیعی است. مثال مستندات گوگل روشن است: سه نتیجه از یک سایت در یک صفحهٔ نتایج، در تجمیع property یک ایمپرشن حساب می‌شود و در تجمیع page سه ایمپرشن؛ CTR هم ۱۰۰٪ در برابر ۳۳٪ و رتبه ۱ در برابر ۲ می‌شود. اگر این را ندانی، هر ماه دنبال خطایی می‌گردی که وجود ندارد.
• مقایسهٔ CTR بین دو کوئری با رتبهٔ متفاوت. CTR به جایگاه و چیدمان نتایج وابسته است؛ مقایسهٔ آن بین کوئری‌های بی‌ربط، عدد تولید می‌کند نه بینش.
• جمع زدن CTR. CTR را میانگین نمی‌گیرند؛ کلیک کل تقسیم بر ایمپرشن کل است.
• نادیده گرفتن کوئری‌های بی‌نام و برش داده. جمع بسته‌های مختلف جدول، همیشه کمتر از واقعیت است. اگر روی اختلاف چند ده کلیک تصمیم بگیری، ممکن است فقط سهم کوئری‌های حذف‌شده باشد.
• عوض کردن چند چیز هم‌زمان. نتیجه‌اش یک عدد است بدون علت.
• نادیده گرفتن تقویم. تعطیلات، آخر هفته و فصل فروش، الگوی ایمپرشن را عوض می‌کنند. مقایسهٔ دو بازهٔ ۱۴ روزه بدون همراستا کردن روزهای هفته، تقریباً همیشه گمراه‌کننده است.
• حذف صفحه بر اساس ایمپرشن صفر. ایمپرشن کم می‌تواند یعنی کوئری کم، یا بی‌نام شدن کوئری، یا نبودن در نتایج. سه چیز کاملاً متفاوت با سه اقدام متفاوت.
• مقایسهٔ مستقیم با Analytics بدون حساب منطقهٔ زمانی. دادهٔ روزانهٔ Performance با وقت اقیانوس آرام است و Analytics با ساعت بازدیدکننده؛ Analytics هم فقط کاربران با جاوااسکریپت را می‌بیند و حریم خصوصی، بخشی از داده را حذف می‌کند. اختلاف این دو ابزار طبیعی است.
• نتیجه‌گیری از یک هفته. یک هفته برای بیشتر تغییرها کوتاه است؛ پنجرهٔ ۱۴ روزه کمینهٔ معقول است.

جمع‌بندی: چک‌لیست هفتگی

همان پانزده دقیقه، در ده قدم. اگر وقت بیشتری داشتی، ترتیب را نشکن؛ اگر وقت کمتری داشتی، قدم‌های ۱ تا ۴ را نگه دار.

1. تاریخ آخرین به‌روزرسانی گزارش را بخوان و بازه را روی دادهٔ نهایی بگذار (پایان سه روز قبل).
2. نمودار ایمپرشن ۹۰ روزه را نگاه کن: روند سالم است یا شکسته؟
3. گزارش Page indexing را با فیلتر «ارسال‌شده» باز کن و آدرس‌های تازهٔ ایندکس‌نشده را یادداشت کن.
4. برای هر آدرس مهم ایندکس‌نشده، دلیل ثبت‌شده را بخوان و یک اقدام انتخاب کن: لینک داخلی، کنونیکال، یا حذف.
5. در تب Pages، سه آدرس با بیشترین افت ایمپرشن را بردار.
6. برای همان سه آدرس، در تب Queries ببین افت در ایمپرشن است یا در CTR.
7. فهرست کوئری‌های رتبهٔ ۱۱ تا ۳۰ را از خروجی به‌روز کن و سه تا پنج کوئری برای این هفته انتخاب کن.
8. هر تصمیم را با یک فرضیه و یک تاریخ شروع ثبت کن؛ فقط یک تغییر در هفته برای هر صفحه.
9. گزارش Core Web Vitals را ماهی یک بار ببین؛ فقط گروه‌های Poor مرتبط با صفحه‌های مهم.
10. هفت عدد داشبورد را با تاریخ ثبت و تاریخ آخرین داده به‌روز کن.

اگر این چک‌لیست را دو ماه ادامه بدهی، بیشتر چیزی که به دست می‌آوری داده نیست؛ می‌دانی کدام عدد را ندیده بگیری. و همین، تفاوت بین کسی است که گزارش می‌خواند و کسی که با گزارش تصمیم می‌گیرد.

بیشتر بخوانید

• بررسی سلامت سئو سایت وردپرس
• پیدا کردن رتبهٔ صفحه در گوگل
• چک‌لیست فنی سئو ۲۰۲۶
• سرورهای MCP سئو و Search Console
• پرسش از هوش مصنوعی دربارهٔ ترافیک سایت: GA4 و Search Console

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

دادهٔ سرچ کنسول چند روز تأخیر دارد؟

معمولاً ۲ تا ۳ روز. دادهٔ جمع‌آوری‌شده در این فاصله در دسترس قرار می‌گیرد و تا آن موقع، عدد روزهای آخر ناقص است. برای تصمیم‌گیری، بازه‌ای انتخاب کن که سه روز آخرش را کنار گذاشته باشی.

چرا جمع جدول با نمودار یکی نیست؟

چون نمودار در سطح property جمع می‌زند و جدول در سطح صفحه. سه نتیجه از یک سایت در یک صفحهٔ نتایج، در تجمیع property یک ایمپرشن و در تجمیع page سه ایمپرشن است. سقف ۱٬۰۰۰ ردیف و حذف کوئری‌های بی‌نام هم اختلاف را بیشتر می‌کند.

چرا کوئری‌ای که می‌دانم ایمپرشن دارد در تب Queries نیست؟

سه دلیل دارد: کوئری‌های کم‌جست‌وجو بی‌نام می‌شوند، جدول فقط مهم‌ترین ردیف‌ها را نگه می‌دارد، و جدول حداکثر ۱٬۰۰۰ ردیف نشان می‌دهد. فهرست کامل‌تر را از خروجی انبوه یا API بگیر.

درخواست ایندکس را چند بار بزنم؟

یک بار، برای آدرس‌هایی که واقعاً مهم‌اند. تکرار درخواست روی همان آدرس صف را جلو نمی‌اندازد و مشکل کیفیت، کنونیکال یا noindex را حل نمی‌کند.

تغییرم را با پنجرهٔ چند روزه بسنجم؟

۱۴ روز قبل و ۱۴ روز بعد از تغییر، با پایان سه روز قبل از امروز. کمتر از این، نویز را به‌جای اثر اندازه می‌گیری؛ بیشتر از این، متغیرهای دیگری وارد بازی می‌شوند.