دیدن یک رتبه غیرعادی، اطلاعات کمی در اختیار ما می‌گذارد. هنوز نمی‌دانیم صفحه کمتر دیده شده، شرایط بررسی عوض شده یا داده جمع‌آوری‌شده نیاز به بررسی دارد. برای رسیدن به پاسخ، باید از همان مشاهده شروع کنیم و مسیر را تا نتیجه دنبال کنیم. تغییر محتوا در نخستین قدم، ممکن است بررسی را دشوارتر کند؛ چون دیگر نمی‌دانیم وضعیت بعدی به کدام عامل مربوط بوده است.
گزارش‌های اخیر درباره نتایج مشکوک گوگل، یک دلیل تازه برای دقت در داده رتبه‌سنج‌ها هستند. شرکت‌های ابزار از صفحاتی گفته‌اند که ظاهر معمول نتایج را دارند، اما محتوای آن‌ها با مشاهده‌های مورد انتظار متفاوت است. این توصیف را باید در محدوده گزارش همان شرکت‌ها خواند. برای بررسی سایت خودمان، همچنان به نمونه مشخص، شرایط ثبت و شواهد مرتبط نیاز داریم.
پیش از هر کاری، عبارت و نشانی هدف را ثبت کنیم. بعد مشخص کنیم افت در کدام کشور، دستگاه و زمان دیده شده و ابزار چه نوع رتبه‌ای را نمایش می‌دهد. آیا عدد مربوط به نشانی خاصی است یا هر نتیجه‌ای از دامنه؟ آیا نبودن صفحه در محدوده بررسی، با یک عدد قراردادی نشان داده شده؟ پاسخ این پرسش‌ها تعریف مساله را تغییر می‌دهد.
نشانه‌ای مانند «بالاتر از ۹۹» را هم بدون خواندن تعریف ابزار تفسیر نکنیم. ممکن است سرویس فقط تا عمق مشخصی بررسی کند. در این صورت، مشاهده ما محدود به همان محدوده است و حذف کامل صفحه از همه نتایج ثابت نشده است. برای هر عدد، بهتر است ابتدا بدانیم سرویس دقیقا چه چیزی را دیده و چه چیزی را ندیده است.
اگر تصویر نتایج یا نسخه ذخیره‌شده آن در دسترس است، نمونه را کنار اطلاعات پروژه نگه داریم. اگر نیست، از پشتیبانی درباره امکان دریافت نمونه بپرسیم. تنها داشتن نمودار، برای فهمیدن اینکه ابزار کدام نشانی‌ها را استخراج کرده کافی نیست. البته در نگهداری نمونه‌ها هم باید سیاست دسترسی و داده سازمان رعایت شود؛ فایل بررسی نباید بی‌دلیل در دسترس همه قرار بگیرد.
یک عبارت ثابت می‌تواند در شرایط متفاوت بررسی شود. ابتدا تنظیمات پروژه و درخواست تازه را کنار هم بگذاریم: کشور، شهر یا محدوده مکانی، زبان، دستگاه و نوع جست‌وجو. اگر یکی از این موارد تغییر کرده، اختلاف رتبه نیازمند توضیح متفاوتی است. بهتر است این کنترل پیش از هر بحث درباره کیفیت محتوا انجام شود.
جست‌وجوی دستی هم تنها وقتی کمک بیشتری می‌کند که شرایط آن ثبت شده باشد. نتیجه مرورگر ما، مشاهده‌ای در همان زمان و همان محیط است. اگر نتیجه با ابزار متفاوت بود، اختلاف را نگه داریم و بررسی را ادامه دهیم. تلاش برای پیدا کردن عددی که با انتظار ما سازگار باشد، تشخیص را بهتر نمی‌کند؛ باید شرایط هر مشاهده روشن بماند.
در کار گروهی، از همکاران بخواهیم تصویر نتیجه را همراه زمان و شرایط بررسی بفرستند. جمله «من هنوز سایت را می‌بینم» برای رد افت کافی نیست، همان‌طور که ندیدن سایت در یک جست‌وجو افت سراسری را ثابت نمی‌کند. هدف، جمع کردن مشاهده‌های قابل مقایسه است تا بتوانیم دامنه اختلاف را کوچک‌تر کنیم.
گاهی اختلاف از جایگاه شروع نشده است؛ از تشخیص صفحه شروع شده است. بررسی کنیم ابزار برای عبارت مورد نظر کدام URL را گزارش می‌کند. ممکن است صفحه دیگری از سایت ظاهر شده باشد یا شکل نشانی با فیلتر پروژه سازگار نباشد. تفاوت نسخه‌ها، مسیرها و پارامترها را باید در همان داده واقعی بررسی کرد و از حدس زدن پرهیز داشت.
اگر صفحه دیگری دیده می‌شود، بلافاصله برچسب رقابت داخلی نزنیم. ابتدا هدف هر دو صفحه و تغییرهای اخیرشان را بررسی کنیم. شاید نتیجه برای یک نیاز متفاوت انتخاب شده باشد یا نشانی هدف پروژه قدیمی باشد. تشخیص درست به شناخت صفحه و عبارت وابسته است؛ وجود دو نشانی برای یک موضوع، به‌تنهایی تصمیم ادغام یا حذف را توجیه نمی‌کند.
در گزارش بررسی، نشانی مورد انتظار و نشانی مشاهده‌شده را جدا بنویسیم. اگر تغییر مسیر یا انتخاب نشانی اصلی مطرح است، آن را به تیم فنی با نمونه مشخص ارجاع دهیم. این جزییات کمک می‌کند اختلاف ناشی از تنظیم پروژه را از مساله واقعی صفحه جدا کنیم و کار اصلاح به نشانی اشتباه سپرده نشود.
به‌جای نگاه کردن به یک عدد، سایت‌های حاضر در همان نتایج را هم ببینیم. آیا تنها صفحه ما جابه‌جا شده یا بخش بزرگی از دامنه‌های همیشگی عوض شده‌اند؟ آیا نتایج تازه با عبارت ارتباط دارند؟ آیا نوع صفحه‌های غالب تغییر کرده است؟ این پرسش‌ها کمک می‌کنند متوجه شویم موضوع بررسی، یک صفحه است یا کل مشاهده.
شرکت نازل در روش منتشرشده خود، نتایج را با سایت‌های معمول هر عبارت در یک دوره پایه مقایسه می‌کند. این یک معیار پژوهشی مشخص است و نباید آن را قانون عمومی برای تشخیص همه افت‌ها دانست. هر روش، نمونه و محدودیت خود را دارد؛ برای بررسی داخلی هم باید معلوم باشد مبنای مقایسه چه زمانی و با چه شرایطی ساخته شده است.
اگر سابقه قابل اتکا نداریم، همین محدودیت را ثبت کنیم. ساختن یک «حالت طبیعی» از دو مشاهده پراکنده، نتیجه را محکم نمی‌کند. می‌توان با چند مشاهده بعدی و شواهد سایت، بررسی را جلو برد، اما نباید نتیجه روش دارای سابقه را به پروژه‌ای بدون سابقه نسبت داد. داده ناکافی، نیازمند توضیح دامنه نتیجه است.
درخواست بررسی تازه، وضعیت مشاهده جدید را روشن‌تر می‌کند. اما لزوما مشخص نمی‌کند عدد قبلی در تاریخچه چه می‌شود. اگر ابزار بعد از بررسی تازه رتبه متفاوتی نشان داد، بپرسیم آیا مقدار قبلی هم بازنگری شده یا فقط آخرین مقدار تغییر کرده است. برای گزارش دوره‌ای، این تفاوت اهمیت مستقیم دارد.
شرکت SEOmonitor گفته برخی داده‌های نادرست ثبت‌شده بین ۹ تا ۱۳ اکتبر را در روز ۱۳ اکتبر بازپردازش کرده است. همچنین توضیح داده که در بعضی افت‌های شدید، ممکن است رتبه قبلی تا دو به‌روزرسانی روزانه نمایش داده شود. بنابراین باید وضعیت نمایش، زمان مشاهده و اصلاح سابقه را جداگانه از سرویس پرسید.
این رفتار را به همه ابزارها تعمیم ندهیم. هر سرویس می‌تواند قواعد متفاوتی برای نگهداری، نمایش و اصلاح داشته باشد. اگر یک عدد برای مدتی ثابت مانده، بدون مستندات نمی‌توان فهمید ثابت بودن آن حاصل مشاهده تازه است یا روال نمایش سرویس. پاسخ باید از تعریف همان محصول و نمونه همان پروژه به دست بیاید.
برای بررسی افت یک صفحه، داده کل سایت نقطه پایان مناسبی نیست. بهتر است صفحه مورد نظر را جدا کنیم و بعد، در حد امکانات گزارش، عبارت، دستگاه و کشور مرتبط را ببینیم. هدف این است که دامنه مقایسه با مشاهده رتبه‌سنج نزدیک‌تر شود. از ترکیب چند برش متفاوت، نتیجه‌ای دقیق درباره یک مشاهده خاص به دست نمی‌آید.
گزارش سرچ کنسول امکان بررسی کلیک، نمایش و جایگاه را در ابعاد مختلف می‌دهد. میانگین جایگاه آن، رتبه یک جست‌وجوی دستی مشخص نیست. برای همین، برابری عددی را شرط درست بودن داده‌ها قرار ندهیم. مهم‌تر این است که هر منبع چه تغییری را در محدوده تعریف‌شده خود نشان می‌دهد.
اگر کلیک ثابت است، هنوز نمی‌توان هر افت رتبه‌ای را رد کرد. شاید افت محدود باشد یا در برش دیگری رخ داده باشد. اگر کلیک کم شده، علت هم هنوز روشن نیست. تقاضا، شکل نتایج، رفتار کاربر و وضعیت صفحه می‌توانند در بررسی مطرح شوند. هر فرضیه باید به شاهد مناسب خودش متصل شود.
بحث درباره داده مشکوک نباید بررسی یک مشکل روشن در سایت را عقب بیندازد. اگر صفحه بارگذاری نمی‌شود، پاسخ غیرمنتظره می‌دهد یا بخشی از محتوای اصلی آن در دسترس نیست، همان مشاهده را ثبت و پیگیری کنیم. ممکن است هم مشکل داده وجود داشته باشد و هم مشکل سایت؛ لازم نیست از ابتدا یکی را به‌عنوان تنها توضیح انتخاب کنیم.
راهنمای گوگل برای بررسی افت ترافیک، علت‌های متفاوتی مانند مشکلات فنی، تغییر تقاضا و تغییرهای رتبه‌بندی را مطرح می‌کند. این چارچوب یادآوری می‌کند که شکل نمودار به‌تنهایی تشخیص قطعی نیست. در بررسی عملی، باید نشانه‌های مرتبط با هر احتمال را پیدا کنیم و نتیجه را محدود به همان شواهد بنویسیم.
برای تیم فنی، درخواست دقیق آماده کنیم: نشانی، زمان مشاهده، پاسخ مورد انتظار و نمونه پاسخ فعلی. جمله «رتبه افت کرده، سایت را بررسی کنید» دامنه کار روشنی ندارد. درخواست مشخص کمک می‌کند معلوم شود چه چیزی آزمایش شده، چه چیزی تغییر کرده و کدام بخش هنوز به بررسی نیاز دارد.
داده یک سرویس ممکن است پیش از رسیدن به گزارش، در چند مرحله داخلی پردازش شود. باید بدانیم سامانه ما پاسخ ناقص، نبود نتیجه و خطای درخواست را چگونه ذخیره می‌کند. اگر همه این حالت‌ها به یک عدد رتبه تبدیل شوند، گزارش دیگر تفاوت میان «دیده نشد» و «بررسی نشد» را نشان نمی‌دهد.
این یک پیشنهاد برای طراحی مسیر داخلی داده است: وضعیت دریافت را جدا از مقدار رتبه نگه داریم. زمان درخواست و زمان مشاهده را هم، اگر سرویس ارایه می‌کند، جدا ثبت کنیم. با این کار، وقتی اختلافی دیده می‌شود، می‌توان فهمید نتیجه از سرویس آمده یا در تبدیل و ذخیره‌سازی داخلی تغییر کرده است.
در موضوع جاری نیز سرویس SerpApi در به‌روزرسانی ۲۶ اکتبر گفته اختلال هنوز وجود دارد. این اطلاعیه درباره همان سرویس است و سلامت یا خرابی هر پاسخ مشخص را ثابت نمی‌کند. برای سامانه داخلی، همچنان باید بررسی کنیم چه تضمین‌ها و چه نشانه‌های وضعیت در همان مسیر دریافت داده وجود دارد.
درخواست پشتیبانی را با چند داده قابل استفاده بفرستیم: نام پروژه، عبارت، زمان، دستگاه، موقعیت و نمونه اختلاف. اگر بررسی دستی انجام داده‌ایم، شرایط آن را هم اضافه کنیم. از پشتیبانی بخواهیم درباره همان نمونه پاسخ دهد و مشخص کند آیا نیاز به دریافت دوباره، اصلاح سابقه یا تغییر تنظیمات وجود دارد.
در پاسخ، به دامنه اقدام توجه کنیم. اگر گفته شد «مشکل کاهش یافته»، هنوز باید بدانیم نمونه ما بررسی شده یا نه. اگر گفته شد «سوابق اصلاح شدند»، تاریخ و گزارش مربوط را بخواهیم. این پیگیری برای مقصر پیدا کردن نیست؛ برای روشن شدن داده‌ای است که قرار است در تصمیم یا گزارش بعدی استفاده شود.
نتیجه گفت‌وگو را کنار همان پرونده نگه داریم. اگر پشتیبانی محدودیتی را توضیح داده، آن را در شیوه خواندن داده اعمال کنیم. اگر نمونه‌ای برای اصلاح ارسال شده، بعد از اعلام انجام کار، خروجی را دوباره تطبیق دهیم. بستن درخواست پشتیبانی با پایان بررسی تحلیلی یکسان نیست؛ نتیجه باید در داده مورد استفاده دیده شود.
برای پروژه‌ای با عبارت‌های زیاد، بررسی دستی همه داده‌ها عملی نیست. می‌توان از صفحه‌های مهم کسب‌وکار و تغییرهای بزرگ شروع کرد و در کنار آن، چند نمونه بدون تغییر را هم دید. این نمونه‌های مقایسه‌ای کمک می‌کنند متوجه شویم اختلاف فقط در موارد افت دیده می‌شود یا شرایط کلی دریافت داده تغییر کرده است.
انتخاب نمونه را ثبت کنیم تا بعدتر، نتیجه محدود آن به تمام پروژه تعمیم داده نشود. اگر فقط عبارت‌های یک محصول روی موبایل بررسی شده‌اند، نتیجه درباره همان محدوده است. برای گسترش نتیجه، باید نمونه‌های مرتبط دیگری اضافه شوند. تعداد زیاد نمونه‌های مشابه، جای تنوع لازم برای پاسخ به پرسش بررسی را نمی‌گیرد.
اولویت تجاری هم باید روشن بماند. یک افت بزرگ در عبارتی کم‌ارتباط، لزوما از تغییر کوچک در صفحه‌ای مهم فوری‌تر نیست. بهتر است ترتیب بررسی را با ترکیبی از شدت تغییر، اهمیت صفحه و وجود شواهد دیگر تعیین کنیم. این انتخاب به تیم کمک می‌کند انرژی خود را جایی بگذارد که نتیجه بررسی می‌تواند اقدام مشخصی را تغییر دهد.
وقتی بررسی تمام شد، لازم نیست همه جزییات فنی را به مخاطب نهایی منتقل کنیم. اما باید روشن باشد گزارش از کدام نسخه داده استفاده می‌کند و چه محدودیتی دارد. اگر بخشی هنوز در حال بررسی است، همان بخش مشخص شود. توضیح مبهم درباره «اختلال کلی ابزارها» می‌تواند افت واقعی را هم پنهان کند.
برای اصلاح یک گزارش قبلی، تنها نمودار تازه نفرستیم. بنویسیم کدام عدد تغییر کرده و آیا برداشت قبلی هم عوض شده است. اگر نتیجه مدیریتی تغییری نکرده، همین را با دلیل توضیح دهیم. اگر تغییر کرده، اقدام پیشنهادی را هم بازنگری کنیم. گزارش اصلاح‌شده زمانی مفید است که اثر اصلاح بر تصمیم را نشان دهد.
در نهایت، این روال باید به یک انتخاب روشن برسد: شواهد برای اقدام کافی‌اند، بررسی مشخص دیگری لازم است یا مشاهده فعلی نتیجه قطعی نمی‌دهد. در هر حالت، قدم بعدی معلوم باشد. ارزش بررسی رتبه در این است که بتوانیم توضیح دهیم چه چیزی دیده‌ایم، چرا آن را معتبر می‌دانیم و براساس آن چه کاری انجام می‌دهیم.
تهیه شده توسط تیم تخصصی SEO سید احسان خسروی (مدیر، متخصص و مشاور استراتژیک SEO)
