عیب یابی ایندکس با سرچ کنسول: کشف و خزش، noindex، robots، canonical و وضعیت های رایج، همراه با اولویت اصلاح صفحه های مهم.

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

این آموزش عیب یابی یک صفحه است و مکمل ۲۰ نکته طلایی سئو محسوب می شود. پیش از اصلاح، وضعیت و هدف صفحه را ثبت کنید.

بررسی صفحات سایت برای ورود به فهرست گوگل

کشف، خزش و ایندکس جدا هستند

گوگل از نشانی مطلع می شود، در صورت امکان آن را می خزد و درباره نگهداری در ایندکس تصمیم می گیرد. لینک و نقشه سایت فقط بخشی از مسیرند. باز شدن صفحه در مرورگر شما ثابت نمی کند Googlebot همان دسترسی و محتوای نهایی را داشته است.

۱. URL دقیق را بررسی کنید

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

۲. پیام گزارش را به بررسی مناسب تبدیل کنید

وضعیت	معنی	بررسی
Excluded by noindex	عدم ایندکس دستور داده شده	عمدی بودن دستور
Blocked by robots.txt	خزش محدود است	هدف قواعد robots
Page with redirect	URL به مقصد دیگری می رود	درستی مقصد
Alternate page with proper canonical	نسخه جایگزین معرفی شده	درستی صفحه اصلی
Discovered – currently not indexed	کشف شده، خزش نشده	دسترسی و ساختار سایت
Crawled – currently not indexed	خزش شده، فعلا ایندکس نشده	محتوا و ارزش مستقل

این جدول تشخیص قطعی علت نیست. گوگل برای Crawled – currently not indexed می گوید صفحه ممکن است در آینده ایندکس شود یا نشود و درخواست دوباره خزش لازم نیست. این پیام به تنهایی اثبات جریمه یا کوتاه بودن مقاله نیست.

۳. noindex و robots را تفکیک کنید

اگر صفحه باید عمومی باشد، noindex در متاتگ و هدر HTTP را بررسی کنید؛ افزونه یا قالب هم ممکن است آن را تولید کند. robots.txt خزش را محدود می کند و جایگزین دستور حذف از ایندکس نیست. وقتی خزش مسدود باشد، گوگل ممکن است نتواند noindex تازه را بخواند. تغییر را مطابق هدف واقعی صفحه انجام دهید.

۴. پاسخ سرور و محتوا

خطای سرور، نیاز به ورود، 403، 404 و صفحه فاقد محتوای اصلی نیاز به بررسی دارد. پاسخ 200 به تنهایی کافی نیست. اگر فایروال یا افزونه امنیتی خزش را محدود کرده، علت را از مسیر مجاز تنظیمات بررسی کنید. صفحه ای که برای کاربر عادی قابل دسترس نیست، الزاماً برای جستجو آماده نیست.

۵. canonical را مقایسه کنید

canonical اعلام شده و منتخب گوگل را در URL Inspection مقایسه کنید. اگر گوگل صفحه دیگری انتخاب کرده، شباهت محتوا، لینک داخلی، ریدایرکت و نقشه سایت را ببینید. canonical علامت ترجیح است. مقاله مستقل را صرف ارتباط موضوعی به والد canonical نکنید.

۶. ارزش پاسخ را بازبینی کنید

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

۷. مسیر کشف را تقویت کنید

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

۸. پس از اصلاح

تاریخ و نوع تغییر را ثبت کنید.
وضعیت زنده URL را بررسی کنید.
در صورت مناسب بودن از درخواست بررسی یا خزش مرتبط استفاده کنید.
Validate fix گروهی را با درخواست یک URL یکی ندانید.
تاریخ خزش را با تاریخ اصلاح مقایسه کنید.

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

پیش از عیب یابی، انتظار درست را تعیین کنید

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

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

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

سناریو اول: مقاله تازه منتشر شده است

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

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

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

سناریو دوم: صفحه قدیمی از دید خارج شده است

اگر یک صفحه قدیمی قبلا دیده می شد، فهرست تغییرات اخیر را بررسی کنید. تغییر قالب، افزونه، نشانی، وضعیت انتشار یا تنظیمات ایندکس می تواند سرنخ باشد. این سرنخ اثبات علت نیست؛ باید با خروجی صفحه و زمان گزارش تطبیق داده شود. افت کلیک به تنهایی ثابت نمی کند صفحه از ایندکس خارج شده است. قبل از هر اصلاح، حضور و وضعیت همان URL را از گزارش مربوط بررسی کنید.

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

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

سناریو سوم: خزش انجام شده اما ایندکس نشده است

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

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

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

تحویل پرونده عیب یابی به تیم فنی یا محتوا

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

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