مشکلات ایندکس در سئوی فنی: جریان تشخیص و اصلاح
یک جریان واحد برای پاسخ به اینکه چرا صفحه ایندکس نشده: خواندن وضعیتهای Search Console، تأیید با ابزار بازرسی URL، یافتن علت ریشهای و اثبات اصلاح.
نوشته Roozbeh Nazari · CEO
جمله «صفحه ما در Google نمیآید» پرشنیدهترین و کماطلاعترین شکایت در سئوی فنی است. ممکن است صفحه خزیده نشده باشد، خزیده شده اما ایندکس نشده باشد، ایندکس شده اما در سایه URL دیگری مانده باشد، یا در ایندکس باشد اما در عبارت جستوجوشده دیده نشود. اصلاح این چهار وضعیت کاملاً با هم فرق دارد و اولین کار فهمیدن این است که در کدامیک هستید. این مقاله برای این کار یک جریان تشخیص ثابت پیشنهاد میدهد: هر بار با همان ترتیب، با همان ابزارها.
این جریان نسخه مکتوب ترتیبی است که در کارهای سئوی فنی روی هر شکایت ایندکس اجرا میکنیم. برای چکلیست گستردهتر در سمت خزش، مقاله چکلیست 20 موردی production را ببینید.
گام 1: شکایت را به یک وضعیت تبدیل کنید
گزارش ایندکس صفحه در Search Console هر URL را در وضعیتی قرار میدهد که خود Google نامگذاری کرده است. این نامها زبان تشخیصاند و اولین گام جریان، ترجمه شکایت به یکی از این نامهاست. وضعیتهای گزارش تقریباً به چهار خوشه تقسیم میشوند.
- مانع دسترسی: خطای سرور (5xx)، خطای ریدایرکت، مسدود شده توسط robots.txt، مسدودی 401 و 403، یافت نشد (404)، 404 نرم.
- دستور صریح: علامتگذاریشده با noindex.
- انتخاب Google: خزیده شده اما فعلاً ایندکس نشده، کشف شده اما فعلاً ایندکس نشده.
- مدیریت نسخه تکراری: صفحه جایگزین با تگ canonical مناسب، نسخه تکراری بدون canonical انتخابشده توسط کاربر، نسخه تکراری که Google canonical متفاوتی از کاربر انتخاب کرده، صفحه دارای ریدایرکت.
معنای هر خوشه فرق دارد. مانع دسترسی یک خرابی فنی است، دستور صریح تصمیمی است که شما گرفتهاید، انتخاب Google سیگنال کیفیت یا ظرفیت است و مدیریت نسخه تکراری یک مشکل معماری. شروع اصلاح پیش از یافتن نام در گزارش، یعنی حدس زدن اینکه در کدام خوشه هستید.
گام 2: روی یک URL تأیید کنید
گزارش تصویر تجمعی میدهد و با تأخیر بهروز میشود. تشخیص باید روی یک URL، با ابزار بازرسی URL تأیید شود. ابزار دو چیز میگوید: نسخه ایندکسشده Google درباره این صفحه چه میداند و وقتی تست زنده انجام شود آیا صفحه امروز قابل ایندکس است یا نه. تفاوت این دو نشان میدهد آیا مشکل هنوز ادامه دارد؛ اگر نسخه ایندکسشده معیوب اما تست زنده تمیز است، یعنی اصلاح انجام شده و خزش مجدد در انتظار است.
تست زنده یک خروجی هم دارد که نادیده گرفته میشود: HTMLای که Google رندر کرده است. صفحهای که در مرورگر میبینید و صفحهای که Google رندر میکند لزوماً یکی نیستند؛ اگر عنوان، canonical و محتوای اصلی در HTML رندرشده نباشد، پیش از رفتن به بقیه تشخیص باید علت این تفاوت را پیدا کرد. بیشتر وقتها علت، مؤلفهای است که در سمت کلاینت دیر بار میشود یا لایهای که به بات پاسخ متفاوتی میدهد.
در تست زنده باید به دو فیلد نگاه کرد: آیا خزش مجاز است و canonical انتخابشده صفحه کدام است. در سایتهای چندزبانه فیلد دوم پر از غافلگیری است؛ مواردی که Google برای صفحه ترکی نسخه انگلیسی را canonical انتخاب میکند، اغلب از ناهمخوانی hreflang و canonical ناشی میشود.
گام 3: علت ریشهای را بر اساس خوشه جستوجو کنید
در خوشه مانع دسترسی علت ریشهای تقریباً همیشه در زیرساخت است. خطاهای 5xx در لایه سرور یا اپلیکیشن؛ خطاهای ریدایرکت در زنجیره یا حلقه؛ مسدودی robots.txt در خود فایل، گاهی در بیرون رفتن فایل محیط اشتباه به production همراه با یک استقرار. 404 نرم، یعنی اینکه صفحه 200 برمیگرداند اما محتوایش خالی یا «یافت نشد» است، اغلب از این ناشی میشود که محتوای بارشده در سمت کلاینت برای Googlebot خالی میرسد.
سرورهایی هم هستند که با بات و کاربر متفاوت رفتار میکنند. سایتهایی که بر اساس زبان کاربر ریدایرکت خودکار میکنند، Googlebot را هم ریدایرکت میکنند و بخشی از نسخههای زبانی هرگز خزیده نمیشوند. این مورد را در سایت خودمان تجربه کردیم و همراه با روش تست در مقاله ریدایرکت خودکار زبان توضیح دادیم؛ در این گام از جریان، مقایسه پاسخی که Googlebot میگیرد با پاسخی که کاربر میگیرد الزامی است.
در خوشه دستور صریح، علت ریشهای یک تگ یا هدر noindex است. سؤال اینجا «تگ کجاست» نیست، «تگ را چه کسی و چرا گذاشته» است. ممکن است قالبی باشد که از محیط تست به production منتقل شده، تنظیمی در سطح صفحه در CMS، یا پیشفرض افزونه سئو. اگر پیش از برداشتن تگ منبعش را پیدا نکنید، با استقرار بعدی برمیگردد.
خوشه انتخاب Google سختترین است، چون از نظر فنی همهچیز درست به نظر میرسد. «کشف شده اما ایندکس نشده» اغلب ظرفیت خزش یا ضعف لینک داخلی است؛ «خزیده شده اما ایندکس نشده» اغلب این است که صفحه نسبت به بقیه سایت بهاندازه کافی متمایز تشخیص داده نشده. اصلاح اینجا فنی نیست: لینک دادن به صفحه از درون سایت، ادغام صفحههای مشابه، یا واقعاً متفاوت کردن محتوا.
در خوشه مدیریت نسخه تکراری، علت ریشهای در معماری است: URLهای پارامتردار، تفاوت اسلش انتهایی، نسخههای http و https، انتشار همان محتوا زیر دو نسخه زبانی بدون canonical. اینکه Google canonical متفاوتی از کاربر انتخاب میکند خطای Google نیست، تناقض دو سیگنال است؛ ریدایرکت، canonical و hreflang باید همه به یک URL اشاره کنند.
گام 4: اصلاح را اثبات کنید، فرض نکنید
بعد از اصلاح سه مدرک لازم است. اول، تمیز درآمدن تست زنده در ابزار بازرسی URL. دوم، اینکه Googlebot واقعاً بعد از اصلاح صفحه را دوباره گرفته باشد، که در لاگ سرور دیده میشود؛ بدون این، وضعیت ایندکس تغییر نمیکند. سوم، تغییر وضعیت در گزارش؛ این مدرک سوم میتواند روزها یا هفتهها طول بکشد و تنها ابزار کوتاه کردن این مدت، درخواست ایندکس از ابزار بازرسی URL است.
درخواست ایندکس را نباید ابزار اصلاح دستهجمعی دید. برای صفحههای مهم بهصورت تکی جواب میدهد؛ برای صدها صفحه، کاری که باید کرد بهروز بودن نقشه سایت و رسیدن واقعی لینکهای داخلی به آن صفحههاست. مستندات robots.txt گوگل نکتهای را که زیاد اشتباه گرفته میشود روشن مینویسد: robots.txt ابزاری برای بیرون نگه داشتن یک صفحه از Google نیست؛ برای این کار noindex یا محافظت با رمز لازم است. این در جهت عکس هم صادق است: گذاشتن noindex روی صفحهای که با robots.txt مسدود شده اثری ندارد، چون Google نمیتواند صفحه را بخزد تا تگ را ببیند.
چرا جریان را ثابت نگه میداریم
اجرای این چهار گام هر بار با همان ترتیب، بیش از آنکه برای سرعت تشخیص باشد، برای جلوگیری از اصلاح اشتباه است. رایجترین خطایی که میبینیم، تغییر canonical برای صفحهای در وضعیت «خزیده شده اما ایندکس نشده» یا بازنویسی محتوا برای «کشف شده اما ایندکس نشده» است؛ هر دو از خواندن اشتباه خوشه ناشی میشوند و هفتهها هدر میدهند. چون جریان هر اصلاح را به یک نام وضعیت و یک مدرک گره میزند، سابقه اینکه چه شد و چرا شد هم خودبهخود شکل میگیرد.
نتیجه
مشکل ایندکس یک مشکل نیست، وضعیتی است که در یکی از چهار خوشه میافتد. جریان تشخیص با ترجمه شکایت به وضعیتی که Search Console نامگذاری کرده شروع میشود، با تست زنده روی یک URL تأیید میشود، علت ریشهای بر اساس خوشه جستوجو میشود و اصلاح با سه مدرک بسته میشود. تیمهایی که این ترتیب را بدون شکستن اجرا میکنند، همان صفحه را یک بار اصلاح میکنند نه سه بار.