برای پیدا کردن علت ایندکس نشدن صفحات وردپرس، ابتدا آدرس دقیق صفحه را در سرچ کنسول بررسی کنید. اگر صفحه دستور noindex دارد، رفع مانع فنی اولویت دارد. اگر گوگل آن را خزش کرده اما ایندکس نکرده، باید وضعیت محتوا، نسخههای مشابه و انتخاب آدرس اصلی را بررسی کنید. نصب افزونهٔ تازه یا زدن مکرر دکمهٔ درخواست ایندکس، جای تشخیص علت را نمیگیرد.
ممکن است یک نوشته در پیشخوان «منتشرشده» باشد، برای بازدیدکننده هم باز شود، اما هنوز در فهرست گوگل نباشد. این وضعیت لزوماً به معنی جریمه یا خرابی وردپرس نیست. مسئله را برای یک صفحهٔ مشخص بررسی کنید و بعد ببینید آیا همان الگو در صفحات دیگر هم تکرار میشود.
اول مطمئن شوید مشکل از ایندکس است، نه رتبه
وقتی نام محصول یا موضوع مقاله را جستوجو میکنید و سایتتان را نمیبینید، هنوز نمیتوانید نتیجه بگیرید که صفحه ایندکس نشده است. شاید گوگل صفحه را در فهرست دارد، اما برای آن عبارت جایگاه مناسبی ندارد. در این حالت، تغییر دستورهای ایندکس راهحل مسئله نیست.
جستوجوی آدرس با عملگر site یک بررسی اولیه است. بااینحال، گوگل توضیح میدهد که خروجی این جستوجو فهرست کاملی از صفحات ایندکسشده نیست. تعداد نتایج آن را هم معیار دقیق سلامت سایت نگذارید. برای بررسی یک نشانی، سراغ URL Inspection بروید.
پیش از شروع، آدرس را از صفحهٔ عمومی کپی کنید، نه از دکمهٔ پیشنمایش پیشخوان. نسخهٔ دارای https، مسیر کامل و اسلش پایانی را همانطور که سایت باز میکند نگه دارید. بررسی نسخهای متفاوت از آدرس اصلی میتواند شما را به تشخیص اشتباه دربارهٔ صفحه برساند.
از URL Inspection چه اطلاعاتی برداریم؟
در حساب سرچ کنسول مربوط به سایت، نشانی کامل را در نوار بررسی URL وارد کنید. وضعیت ثبتشده، تاریخ آخرین خزش، اجازهٔ دسترسی و اجازهٔ ایندکس را بخوانید. اگر صفحه نسخهٔ مشابهی دارد، آدرس کنونیکالی را که گوگل انتخاب کرده هم یادداشت کنید.
گزارش موجود، وضعیت آخرین بررسی ثبتشده را نمایش میدهد. پس از اصلاح سایت، با Test Live URL وضعیت فعلی را آزمایش کنید. موفقیت تست زنده به معنی ثبت قطعی صفحه در فهرست نیست و انتخاب نهایی کنونیکال را هم پیشبینی نمیکند. نتیجهٔ نسخهٔ ثبتشده و تست زنده را با هم اشتباه نگیرید.
یک یادداشت کوتاه بسازید: آدرس، وضعیت فعلی، تاریخ آخرین خزش و تغییری که قصد اجرای آن را دارید. برای شروع، یک مقاله، یک محصول و یک برگهٔ خدمات را نمونه بگیرید. این انتخاب پیشنهادی برای عیبیابی است؛ لازم نیست پیش از فهمیدن علت، تنظیمات صدها صفحه را دستکاری کنید.
پیام سرچ کنسول مسیر بررسی را مشخص میکند
| وضعیت | معنی کوتاه | مسیر بررسی |
|---|---|---|
| Discovered – currently not indexed | گوگل نشانی را شناخته، اما هنوز آن را خزش نکرده است. | کشف صفحه، دسترسی و وضعیت سرور را بررسی کنید. |
| Crawled – currently not indexed | گوگل صفحه را خزش کرده، اما فعلاً در فهرست قرار نداده است. | محتوا و نسخههای مشابه را بررسی کنید؛ علت واحدی را فرض نکنید. |
| Excluded by noindex | صفحه دستور منع ایندکس دارد. | اگر باید در جستوجو باشد، منشأ دستور را پیدا کنید. |
| Alternate page with proper canonical tag | گوگل نسخهٔ اصلی دیگری را پذیرفته است. | اگر انتخاب آگاهانه بوده، الزاماً اصلاحی لازم نیست. |
همهٔ نشانیهای خارج از فهرست مشکل نیستند. برای مثال، لازم نیست سبد خرید یا نسخههای تکراری فیلترها را به اجبار وارد نتایج کنید. فهرست بررسی را از صفحاتی آغاز کنید که پاسخ مستقلی برای مخاطب دارند و میخواهید از جستوجو ورودی بگیرند.
تنظیمات خواندن وردپرس را بررسی کنید
در پیشخوان به «تنظیمات» و سپس «خواندن» بروید. اگر گزینهٔ «از موتورهای جستوجو درخواست کن تا محتوای سایت را بررسی نکنند» فعال است، بررسی کنید سایت هنوز آزمایشی است یا برای استفادهٔ عمومی آماده شده است. برای سایتی که باید در گوگل دیده شود، این گزینه نباید ناخواسته فعال مانده باشد.
این تنظیم را با ابزار امنیتی اشتباه نگیرید؛ فعالکردنش مانع ورود کاربران به سایت نمیشود. برای محیط آزمایشی دارای اطلاعات خصوصی، محدودکردن دسترسی راه جداگانهای میخواهد. بعد از تغییر تنظیم و ذخیره، خروجی صفحه را دوباره بررسی کنید؛ صرف برداشتن تیک، تأیید ایندکس نیست.
مثال فرضی: طراح هنگام ساخت سایت این گزینه را فعال کرده و بعد از تحویل فراموش کرده آن را تغییر دهد. در چنین وضعیتی، نوشتن ده مقالهٔ تازه قبل از بررسی تنظیمات، علت اصلی را برطرف نمیکند. در چکلیست تحویل سایت، مسئول بررسی این گزینه را مشخص کنید تا همین اشتباه در بازطراحی بعدی تکرار نشود.
دستور noindex ممکن است از جای دیگری آمده باشد
حتی با تنظیم درست بخش خواندن، یک برگه میتواند دستور noindex داشته باشد. این دستور ممکن است در متای robots یا هدر HTTP با نام X-Robots-Tag قرار بگیرد. گوگل برای دیدن آن باید بتواند صفحه را بخزد؛ افزودن همزمان ممنوعیت خزش، روش مناسبی برای اجرای noindex نیست.
تنظیم همان نوشته و تنظیمات عمومی نوع محتوا را در افزونهٔ سئوی فعال بررسی کنید. نام و جای گزینهها با افزونه و نسخهٔ آن فرق میکند. اگر تنظیم نوشته درست است اما خروجی هنوز noindex دارد، از مسئول فنی بخواهید منشأ آن را در قالب، کد سفارشی یا پاسخ سرور پیدا کند.
قبل از تغییر دستهجمعی، مشخص کنید چرا این دستور فعال شده است. شاید نویسنده عمداً یک صفحهٔ موقت را از جستوجو خارج کرده باشد. از تنظیم قبلی نسخهٔ پشتیبان بگیرید، فقط مورد نامطلوب را اصلاح کنید و پس از پاککردن کش مربوط، دوباره خروجی عمومی همان صفحه را ببینید.

robots.txt و دسترسی سرور را جداگانه کنترل کنید
فایل robots.txt برای مدیریت دسترسی خزنده است؛ وجود یک قانون Disallow بهتنهایی روش قابلاتکایی برای حذف نشانی از نتایج نیست. اگر قانون گستردهای مسیر مقالهها یا محصولات را مسدود کرده، همان قانون را با فرد مسئول سایت بررسی کنید. کل فایل را برای رفع مشکل یک صفحه حذف نکنید.
بازشدن سایت برای مدیر هم ثابت نمیکند که خزنده همان پاسخ را میگیرد. وضعیت پاسخ HTTP را بررسی کنید. خطاهای ۴۰۴، ۴۰۳ و ۵۰۰ مسئلههای متفاوتی دارند. در خطای ۴۰۴ دنبال نشانی اشتباه یا محتوای حذفشده بگردید؛ در ۴۰۳، محدودیت دسترسی را بررسی کنید؛ برای خطای ۵۰۰ از مسئول هاست بررسی گزارش خطای سرور را بخواهید.
اگر مشکل پس از تغییر فایروال یا CDN شروع شده، زمان تغییر را همراه با چند نشانی نمونه برای پشتیبانی بفرستید. همهٔ ابزارهای امنیتی را خاموش نکنید. از پشتیبانی بخواهید محدودیت ناخواسته را تشخیص دهد و هویت خزنده را هم بررسی کند؛ نام Googlebot در یک درخواست، بهتنهایی مدرک هویت آن نیست.
برای یک صفحهٔ واقعی و عمومی، پاسخ موفق و محتوای اصلی لازم است. صفحهای که ظاهراً باز میشود اما فقط پیام خطا یا محتوای خالی دارد، مسئله را حل نکرده است. نتیجهٔ بررسی فنی را با توضیح واضح ثبت کنید، مثلاً «قانون مسدودکنندهٔ مسیر محصولات اصلاح شد»، نه فقط «سرور درست شد».
کنونیکال اشتباه، گوگل را به نسخهٔ دیگری ارجاع میدهد
اگر صفحه محتوای مستقلی دارد، بررسی کنید کنونیکال آن ناخواسته به صفحهٔ اصلی، محصول دیگری یا دامنهٔ آزمایشی اشاره نکند. کنونیکال، انتخاب ترجیحی شما برای نسخهٔ اصلی است؛ گوگل ممکن است نسخهٔ دیگری را برگزیند. وجود آن بهتنهایی تضمین انتخاب آدرس دلخواه نیست.
آدرس اصلی را در لینکهای داخلی، نقشهٔ سایت و تنظیم کنونیکال هماهنگ نگه دارید. وقتی این نشانهها به نسخههای متفاوت اشاره میکنند، ابتدا تناقض را برطرف کنید. برای صفحهای که واقعاً نسخهٔ تکراری است، تلاش برای ایندکس مستقل الزاماً هدف مناسبی نیست.
مثال فرضی: دو برگهٔ یکسان برای یک خدمت ساختهاید و فقط نامک آنها فرق دارد. پیش از تغییر کنونیکال، تصمیم بگیرید کدام نسخه باید بماند و هر نسخه چه کاربردی دارد. اگر قصد حذف نسخهٔ اضافی را دارید، روش انتقال را با مسئول فنی انتخاب کنید؛ تغییر نامک بدون برنامه میتواند لینکهای قبلی را هم تحتتأثیر قرار دهد.
صفحه را از مسیرهای واقعی سایت قابلکشف کنید
در نقشهٔ سایت، وجود نشانی اصلی مقاله یا محصول را بررسی کنید. نقشه باید در دسترس باشد و آدرسهای موردنظر را معرفی کند. ثبت نقشه در سرچ کنسول، تضمین خزش یا ایندکس همهٔ نشانیهای آن نیست. اگر نشانی مهمی جا افتاده، تنظیمات خروجی نقشه را در ابزار مربوط بررسی کنید.
برای صفحهٔ جدید، از یک مقالهٔ مرتبط یا دستهبندی مناسب لینک داخلی بگذارید. متن لینک باید مقصد را توضیح دهد و لینک استاندارد دارای href باشد. دکمهای که فقط با اجرای کد جاوااسکریپت کار میکند، لزوماً همان مسیر قابلخزش یک لینک عادی را فراهم نمیکند.
بهجای افزودن لینک صفحه به همهٔ نوشتهها، جای مرتبط آن را انتخاب کنید. مثلاً راهنمای انتخاب کفش میتواند به دستهٔ کفش پیادهروی پیوند بدهد. مخاطب باید بداند با کلیک چه چیزی میبیند. یک صفحهٔ مفید که فقط از پنل مدیریت به آن دسترسی دارید، هنوز در مسیر طبیعی مرور سایت قرار نگرفته است.
اگر صفحه خزش شده، محتوا را با سؤال مخاطب مقایسه کنید
وضعیت Crawled – currently not indexed بهتنهایی حکم «محتوای بیکیفیت» نیست. پس از بررسی موانع فنی، ببینید مخاطب در این صفحه چه پاسخ تازه و مستقلی میگیرد. زیادکردن تعداد کلمات یا تکرار عبارت هدف، ارزش مستقل ایجاد نمیکند.
در مقالهٔ آموزشی، مراحل قابلاجرا، شرط انجام هر مرحله و روش بررسی نتیجه را توضیح بدهید. برای محصول، اطلاعاتی را بنویسید که خریدار برای تصمیم نیاز دارد: مشخصات واقعی، تفاوت مدلها و محدودیت استفاده. اطلاعات سازنده را با دادهٔ ساختگی یا ادعای تجربهٔ شخصی تکمیل نکنید.
رسیدگی به ایندکس یکی از بخشهای سئو وردپرس است. مسئول سایت باید هم موانع فنی را بررسی کند و هم محتوای صفحه را با نیاز جستوجوکننده بسنجد. اگر چند صفحه پاسخ مشابهی میدهند، پیش از نوشتن متن تازه، تفاوت کاربرد آنها را مشخص کنید.
مثال فرضی: عنوان صفحه «انتخاب کفش مناسب پیادهروی طولانی» است، اما بدنه فقط چند محصول و یک توضیح عمومی دارد. میتوانید معیار انتخاب، روش اندازهگیری و تفاوت کاربرد مدلها را با اطلاعات معتبر توضیح دهید. افزودن چند پاراگراف دربارهٔ اهمیت خرید اینترنتی، پاسخ این سؤال را کامل نمیکند.

اصلاحات را محدود و قابلپیگیری اجرا کنید
وقتی چند نفر روی سایت کار میکنند، از هرکدام یک تغییر جداگانه نخواهید بدون اینکه نتیجه را ثبت کنند. برای هر مشکل، مسئول و نشانی نمونه مشخص کنید. اول مانع تأییدشده را برطرف کنید و بعد نتیجه را بسنجید. تغییر همزمان قالب، افزونهٔ سئو و ساختار آدرسها، تشخیص اثر هر اصلاح را دشوار میکند.
یک برگهٔ پیگیری ساده کافی است: نشانی صفحه، وضعیت پیش از اصلاح، اقدام انجامشده، تاریخ اجرا و وضعیت بررسی بعدی. اگر مسئله در همهٔ محصولات مشترک است، قبل از اجرای سراسری، اصلاح را روی نمونهای کنترل کنید. برای تصمیمی که ممکن است صفحات زیادی را از جستوجو خارج کند، نسخهٔ پشتیبان و امکان بازگشت داشته باشید.
اگر بررسی را به مجموعهای مانند شرکت سئو سئودو میسپارید، همین خروجیها را در شرح کار بخواهید: علت مستند، صفحات درگیر، پیشنهاد اصلاح و روش کنترل نتیجه. گزارش قابلبررسی از وعدهٔ «ایندکس فوری همهٔ صفحات» مفیدتر است؛ هیچ ارائهدهندهای تصمیم نهایی گوگل را در اختیار ندارد.
برای ارسال اطلاعات به پشتیبانی هم کمترین دسترسی لازم را بدهید. معمولاً میتوانید بررسی اولیه را با نشانی عمومی و تصویر گزارش شروع کنید. رمز مدیریت را داخل متن عمومی، تیکت نامطمئن یا مقاله قرار ندهید. اگر دسترسی مدیریتی لازم شد، آن را محدود، قابللغو و از مسیر مورداعتماد ارائه کنید.
بعد از اصلاح، چه چیزی را دوباره بررسی کنیم؟
پس از رفع مانع، تست زنده را اجرا کنید و نتیجه را با یادداشت قبلی مقایسه کنید. برای تعداد کمی صفحهٔ اصلاحشده میتوانید از Request Indexing استفاده کنید. گوگل برای خزش دوباره زمان ثابت تضمین نمیکند؛ این فرایند ممکن است چند روز تا چند هفته طول بکشد و درخواست هم به معنی پذیرش قطعی نیست.
درخواست یک آدرس را پشتسرهم تکرار نکنید؛ این کار خزش را سریعتر نمیکند. برای مجموعهای از صفحات، نقشهٔ سایت و مسیرهای داخلی را درست نگه دارید. نشانی صفحه را هم صرفاً برای ارسال دوباره به گوگل عوض نکنید. بعداً وضعیت ثبتشده را ببینید و نتیجه را با تاریخ آخرین خزش تفسیر کنید.
مثال فرضی: امروز دستور noindex را برداشتهاید، اما گزارش قبلی هنوز همان خطا را دارد. ابتدا بررسی کنید تست زنده دیگر آن دستور را نبیند. تا وقتی گوگل نسخهٔ تازه را دوباره بررسی نکرده، از باقیماندن گزارش قدیمی نتیجه نگیرید که تغییر شما بیاثر بوده است.
جمعبندی
برای رفع مشکل ایندکس، از نشانی دقیق و دلیل ثبتشده در سرچ کنسول شروع کنید. تنظیمات خواندن، noindex، دسترسی، کنونیکال و کشف صفحه را براساس همان دلیل بررسی کنید. سپس یک اصلاح مشخص انجام دهید و نتیجه را ثبت کنید. هدف، حضور صفحات مفید و مستقل است؛ تعداد بیشتر نشانیهای ایندکسشده بهتنهایی معیار موفقیت نیست.
پرسشهای متداول
آیا برای رفع مشکل باید افزونهٔ سئو را عوض کنیم؟
بدون تشخیص منشأ مشکل، تعویض افزونه پیشنهاد مناسبی نیست. ابتدا خروجی همان صفحه و تنظیمات فعال را بررسی کنید. اگر تصمیم به مهاجرت گرفتید، انتقال تنظیمات، کنونیکالها و نقشهٔ سایت را هم در برنامه بگذارید.
برای صفحات ورود و سبد خرید هم درخواست ایندکس بدهیم؟
هدف این صفحهها انجام کار مشخص برای کاربر است. صرف بیشترشدن تعداد صفحات، دلیل مناسبی برای واردکردن آنها به نتایج نیست. فهرست اولویت را بر پایهٔ کاربرد هر صفحه و نیاز جستوجوکننده تنظیم کنید.
چه اطلاعاتی را قبل از درخواست بررسی تخصصی آماده کنیم؟
چند نشانی نمونه، وضعیت سرچ کنسول، زمان شروع مشکل و فهرست تغییرات اخیر سایت را آماده کنید. مشخص کنید مشکل فقط در نوشتههای جدید دیده میشود یا صفحات قدیمی هم از فهرست خارج شدهاند. اطلاعات محرمانه را از تصاویر گزارش حذف کنید.
منابع
راهنمای رسمی گوگل دربارهٔ گزارش Page indexing و ابزار URL Inspection؛ مستندات Google Search Central دربارهٔ noindex، robots.txt، کنونیکال، نقشهٔ سایت، لینکهای قابلخزش و درخواست خزش مجدد؛ مستندات وردپرس دربارهٔ Settings Reading. تصاویر این مطلب مفهومی و تولیدشده با هوش مصنوعیاند و اسکرینشات یک سایت یا نتیجهٔ واقعی پروژه نیستند.

نظر شما میتواند به کاملتر شدن این مطلب کمک کند؛ دیدگاه خود را با ما به اشتراک بگذارید. موضوع این مطلب در دسته «کسب و کار» قرار دارد.
دیدگاه شما ثبت شد!
پس از بررسی و تایید مدیر نمایش داده خواهد شد
هنوز دیدگاهی ثبت نشده است!
اولین نفری باشید که برای این مطلب دیدگاه مینویسد.