اعتبارسنجی سرچ کنسول یا Validation به گوگل اعلام می‌کند که یک مشکل مشخص را اصلاح کرده‌اید تا نمونه‌های مرتبط را دوباره بررسی کند. Validate Fix سایت را تعمیر نمی‌کند و Passed نیز به معنی سالم بودن همهٔ بخش‌های سایت یا تضمین جایگاه در جستجو نیست.
پیش از اعتبارسنجی سرچ کنسول چه کنیم؟
نام خطا، نمونهٔ URL و زمان تشخیص را یادداشت کنید. سپس علت را در خود سایت رفع کنید. برای مثال، اگر چند مقاله پس از تغییر افزونه پاسخ ۵۰۰ می‌دهند، زدن دکمهٔ اعتبارسنجی قبل از اصلاح خطای برنامه کمکی نمی‌کند.
یک نمونهٔ مهم و چند صفحهٔ مشابه را آزمایش کنید. اگر مشکل فقط در بعضی دسته‌ها یا نسخهٔ موبایل رخ می‌دهد، تست یک صفحهٔ اصلی کافی نیست. اصلاح باید همان شرایطی را پوشش دهد که خطا در آن دیده شده است.
وضعیت‌های اصلی چه معنایی دارند؟
طبق راهنمای اعتبارسنجی گوگل، وضعیت به همان مشکل مربوط است:
- Not started: برای همهٔ نمونه‌های مسئله بررسی آغاز نشده است.
- Started: فرایند شروع شده است.
- Looking good: نمونه‌های بررسی‌شده تاکنون اصلاح شده‌اند.
- Passed: نمونه‌های شناخته‌شدهٔ مسئله رفع یا از دسترس خارج شده‌اند.
- Failed: مشکل در بررسی باقی مانده است.
- N/A: گوگل رفع مسئله را بدون درخواست اعتبارسنجی تشخیص داده است.
پس N/A را صرفاً «نامشخص» نخوانید و Looking good را نتیجهٔ نهایی ندانید. وضعیت هر URL نیز می‌تواند Pending، Passed، Failed یا Other باشد؛ Other ممکن است به خارج شدن صفحه از دسترس مربوط باشد، نه توقف کل فرایند.
درخواست را چگونه پیگیری کنیم؟
در گزارش مربوط، جزئیات خطای اصلاح‌شده را باز کنید و Validate Fix را بزنید. اگر فیلتر نقشهٔ سایت فعال است، محدودهٔ درخواست را کنترل کنید. با See details می‌توانید روند همان درخواست را ببینید؛ بررسی معمولاً تا حدود دو هفته و گاهی بیشتر زمان می‌برد.
اگر Failed شد، URL ناموفق را پیدا کنید، علت را اصلاح کنید و بعد از پایان چرخهٔ قبلی درخواست جدید بدهید. ثبت دوباره بدون تغییر واقعی، مشکل باقی‌مانده را حل نمی‌کند.
آزمون زنده با اطلاعات ایندکس فرق دارد
URL Inspection هم اطلاعات نسخهٔ شناخته‌شدهٔ گوگل و هم آزمون زنده دارد. تاریخ آخرین خزش را با زمان اصلاح مقایسه کنید. ممکن است اکنون صفحه سالم باشد ولی اطلاعات ایندکس هنوز وضعیت قبلی را نشان دهد؛ آزمون زنده نیز همهٔ شرایط حضور در جستجو را بررسی نمی‌کند.
برای مثال، رفع خطای سرور با انتخاب canonical صحیح دو کار جداست. اگر اولی تأیید شد، دومی را خودکار حل‌شده فرض نکنید. در یادداشت تیم، هر مسئله را جدا با URL، علت، اصلاح انجام‌شده و نتیجه ثبت کنید.
چه زمانی کار را تمام‌شده بدانیم؟
معیار پایان باید با هدف صفحه هماهنگ باشد. مقاله‌ای که باید عمومی بماند با حذف شدن و ناپدید شدن خطایش، الزاماً اصلاح نشده است. محتوای صفحه، دسترسی کاربران و نتیجهٔ مسئلهٔ مشخص را کنار هم بررسی کنید؛ رنگ وضعیت به‌تنهایی جای این تصمیم را نمی‌گیرد.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
