صفحه وردپرس اشتباهی noindex شده؛ چطور جلوی حذف آن از گوگل را بگیریم؟

در گزارش Search Console برای یکی از صفحه‌های مهم عبارت Excluded by noindex tag می‌بینید. این پیام معمولاً یعنی گوگل در یکی از بررسی‌های قبلی، دستوری برای ایندکس‌نکردن آن نشانی دیده است. اگر صفحه باید در نتایج جست‌وجو باشد، باید محل صدور دستور را پیدا و اصلاح کنید؛ اما اگر صفحه خصوصی یا آزمایشی است، حذف محدودیت می‌تواند ناخواسته آن را در معرض جست‌وجو قرار دهد.

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

نشانی کامل را از گزارش کپی کنید: پروتکل، دامنه، زیر‌دامنه، مسیر و در صورت وجود پارامتر اهمیت دارند. example.com و www.example.com یا صفحه اصلی و نسخه آزمایشی ممکن است تنظیم جداگانه داشته باشند. ابتدا صفحه را در پنجره خصوصی باز کنید و ببینید آیا همان محتوای مورد انتظار و بدون نیاز به ورود نمایش داده می‌شود.

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

دستور noindex به موتور جست‌وجوی پشتیبان می‌گوید آن صفحه را در نتایج نشان ندهد. این دستور می‌تواند در تگ meta داخل HTML یا در سربرگ HTTP با نام X-Robots-Tag باشد. فایل robots.txt در درجه اول به خزنده درباره دسترسی و خزش مسیرها راهنمایی می‌دهد و همان ابزار تنظیم ایندکس نیست.

اگر robots.txt خزش صفحه را مسدود کند، خزنده ممکن است نتواند noindex موجود در خود صفحه را ببیند. مسدودکردن با robots.txt نیز تضمین نمی‌کند نشانی هرگز در نتایج ظاهر نشود. مستند رسمی گوگل درباره noindex این تفاوت را توضیح می‌دهد. پس صرف افزودن یا حذف یک خط robots.txt، بدون بررسی هدف صفحه، راه‌حل کامل نیست.

با حساب مدیر وارد پیشخوان شوید و به تنظیمات ← خواندن بروید. گزینه‌ای با مفهوم «از موتورهای جست‌وجو درخواست کن محتوای سایت را بررسی نکنند» یا Search engine visibility را بررسی کنید. در یک سایت عمومی که باید ایندکس شود، فعال‌بودن اشتباهی این گزینه می‌تواند علت باشد. پیش از تغییر، مطمئن شوید در سایت اصلی هستید، نه نسخه آزمایشی.

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

اگر این گزینه از ابتدا خاموش بوده، لزوماً مشکل جای دیگری نیست؛ افزونه، قالب، هدر سرور یا نسخه‌ای که گوگل قبلاً دیده نیز می‌تواند نقش داشته باشد. همه تنظیمات سئو را به حالت پیش‌فرض برنگردانید.

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

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

پس از ذخیره، صفحه را در پنجره خصوصی باز کنید و از گزینه View page source یا نمایش منبع صفحه استفاده کنید. در متن منبع به دنبال noindex و نام‌های robots یا googlebot بگردید. وجود چند تگ یا تنظیم متناقض می‌تواند سردرگم‌کننده باشد؛ یک تگ مجاز لزوماً محدودیت تگ دیگر را خنثی نمی‌کند. منبعی که مرورگر می‌بیند را با وضعیت صفحه‌ای که گوگل بررسی کرده تطبیق دهید.

اگر در HTML چیزی پیدا نکردید، ممکن است دستور در سربرگ HTTP باشد. مدیر می‌تواند از ترمینال با نشانی واقعی، پاسخ را مشاهده کند:

در خروجی دنبال X-Robots-Tag و وضعیت پاسخ بگردید. این فرمان بدنه را ذخیره نمی‌کند و سربرگ درخواست فعلی را نمایش می‌دهد. اگر صفحه به نشانی دیگری ریدایرکت شود، مقصد نهایی و هر پاسخ مرتبط را جداگانه بررسی کنید؛ نتیجه یک درخواست لزوماً همان پاسخی نیست که خزنده در زمان دیگری از مسیر CDN دیده است. نام نمونه را با صفحه واقعی عوض کنید.

اگر خطای گواهی دریافت کردید، اول اعتبار HTTPS را حل کنید و بررسی امنیتی را خاموش نکنید. اگر هدر از CDN، تنظیم وب‌سرور یا افزونه صادر می‌شود، مالک همان لایه باید منبع را مشخص کند. ویرایش تصادفی همه هدرها یا پاک‌کردن تنظیمات امنیتی سایت لازم نیست.

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

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

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

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

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