وقتی یک صفحه در گوگل دیده نمی‌شود، اولین واکنش بسیاری از مدیران سایت این است که دوباره آدرس را برای ایندکس ارسال کنند؛ اما «درخواست ایندکس» فقط آخرین حلقه زنجیر است. تا وقتی گوگل نتواند URL را پیدا کند، صفحه را بخزد، محتوای آن را پردازش کند و نسخه مناسب را به‌عنوان canonical انتخاب کند، ارسال چندباره آدرس مشکل را حل نمی‌کند. در این راهنما، علت‌های رایج ایندکس نشدن سایت را از مرحله تشخیص تا اقدام اصلاحی بررسی می‌کنیم؛ به‌طوری‌که بدانید هر پیام Search Console دقیقاً چه معنایی دارد و برای آن چه کاری باید انجام دهید.

پاسخ کوتاه: ایندکس نشدن معمولاً از یکی از این پنج ناحیه می‌آید: گوگل هنوز صفحه را کشف نکرده است، دسترسی خزنده با robots.txt یا خطای سرور محدود شده، دستور noindex فعال است، canonical به URL دیگری اشاره می‌کند، یا کیفیت و تمایز صفحه برای ورود به فهرست گوگل کافی تشخیص داده نشده است. مسیر درست، بررسی URL Inspection، کنترل دسترسی فنی، اصلاح سیگنال‌های canonical و تقویت ارزش واقعی صفحه است؛ نه تکرار بی‌هدف Request Indexing.

ایندکس شدن دقیقاً چیست و چرا با خزش فرق دارد؟

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

این تفکیک برای عیب‌یابی حیاتی است. اگر وضعیت «Discovered – currently not indexed» را می‌بینید، گوگل URL را می‌شناسد ولی هنوز آن را نخزیده است. در «Crawled – currently not indexed»، صفحه دریافت شده اما فعلاً وارد ایندکس نشده است. اگر «Excluded by noindex tag» نمایش داده شود، دستور مستقیمی برای جلوگیری از ایندکس وجود دارد. در وضعیت canonical نیز ممکن است URL موردنظر شما نسخه تکراری تشخیص داده شده و URL دیگری انتخاب شده باشد.

ابزار URL Inspection در Search Console نقطه شروع تشخیص است. این ابزار اطلاعات نسخه ثبت‌شده در ایندکس، امکان آزمایش نسخه زنده، وضعیت خزش، دسترسی به ایندکس و canonical انتخابی گوگل را نشان می‌دهد. توجه کنید که نتیجه مثبت Live Test فقط قابلیت دسترسی فنی را تأیید می‌کند و تضمین نمی‌کند صفحه حتماً ایندکس یا در نتایج دیده شود.

قبل از هر تغییر، مشکل را درست تشخیص دهید

ابتدا URL کامل همان صفحه را در نوار URL Inspection وارد کنید. فقط بررسی دامنه یا جست‌وجوی site: برای تصمیم فنی کافی نیست. در گزارش، چهار بخش را به‌ترتیب بخوانید: آیا URL برای گوگل شناخته شده است؟ آیا Crawl allowed برابر Yes است؟ آیا Page fetch موفق بوده؟ و آیا Indexing allowed برابر Yes است؟ سپس User-declared canonical و Google-selected canonical را مقایسه کنید.

بعد از آن «Test live URL» را اجرا کنید. گزارش ایندکس ممکن است مربوط به آخرین خزش باشد و با نسخه فعلی صفحه فرق داشته باشد؛ آزمایش زنده نشان می‌دهد گوگل در همین لحظه به چه نسخه‌ای دسترسی دارد. اگر تغییر تازه‌ای مانند حذف noindex، اصلاح پاسخ سرور یا تغییر canonical انجام داده‌اید، اختلاف گزارش ایندکس و آزمایش زنده طبیعی است.

یک جدول تصمیم سریع برای پیام‌های رایج

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

robots.txt، noindex و دسترسی خزنده را بررسی کنید

فایل robots.txt برای مدیریت خزش است، نه روشی مطمئن برای حذف یک صفحه از ایندکس. اگر مسیر مهمی با Disallow مسدود شده باشد، Googlebot نمی‌تواند محتوای صفحه و دستورهای داخل آن را ببیند. بر اساس مستندات رسمی robots meta tag، دستور noindex زمانی قابل خواندن و اجراست که خزنده اجازه دسترسی به صفحه را داشته باشد. بنابراین ترکیب هم‌زمان Disallow و noindex می‌تواند نتیجه‌ای متفاوت از انتظار ایجاد کند.

در وردپرس، گزینه «از موتورهای جست‌وجو درخواست کن تا محتوای سایت را بررسی نکنند» در تنظیمات خواندن را کنترل کنید؛ به‌خصوص بعد از انتقال سایت از محیط آزمایشی به دامنه اصلی. افزونه‌های سئو نیز می‌توانند برای نوشته، دسته، برچسب یا نوع محتوای سفارشی noindex تولید کنند. فقط کد HTML ظاهری را نبینید؛ هدر HTTP با نام X-Robots-Tag نیز ممکن است دستور noindex داشته باشد، به‌ویژه برای فایل‌ها یا تنظیمات سطح سرور.

چک فنی کوتاه

• URL باید بدون ورود، رمز یا محدودیت IP برای کاربران و خزنده قابل دسترس باشد.
• پاسخ صفحه اصلی باید 200 باشد؛ زنجیره ریدایرکت طولانی، 5xx و timeout را برطرف کنید.
• منبع HTML و هدر پاسخ را برای noindex بررسی کنید.
• robots.txt نباید فایل‌های ضروری رندر، مسیر نوشته‌ها یا بخش‌های مهم را ناخواسته مسدود کند.
• تنظیمات محیط staging نباید پس از انتقال روی سایت اصلی باقی مانده باشد.

خطاهای موقت سرور نیز مهم‌اند. اگر هاست در زمان مراجعه Googlebot کند، بی‌ثبات یا محدودکننده باشد، خزش به تعویق می‌افتد. گزارش Crawl Stats و لاگ سرور کمک می‌کنند بفهمید پاسخ‌های 5xx، 429 یا زمان انتظار بالا در چه بازه‌ای رخ داده‌اند. قبل از افزایش منابع، کش، پایگاه داده، افزونه‌های سنگین و قوانین فایروال را بررسی کنید؛ چون علت همیشه کمبود سخت‌افزار نیست.

canonical، ریدایرکت و نسخه‌های تکراری را همسو کنید

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

نمونه رایج، صفحه‌ای است که canonical آن به آدرس دیگری اشاره می‌کند اما در سایت‌مپ قرار دارد و لینک‌های داخلی هم به همان صفحه فرعی داده شده‌اند. نمونه دیگر، وجود نسخه‌های HTTP و HTTPS، www و بدون www، پارامترهای فیلتر، صفحات چاپ یا URLهای دارای اسلش متفاوت است. هدف این است که برای هر محتوای اصلی، یک URL پایدار داشته باشید و همه نشانه‌ها به همان نسخه اشاره کنند.

برای صفحات حذف‌شده یا ادغام‌شده، ریدایرکت 301 به نزدیک‌ترین جایگزین مرتبط مناسب است. همه URLهای قدیمی را به صفحه اصلی نفرستید؛ این کار برای کاربر و موتور جست‌وجو معنای دقیقی ندارد و ممکن است به‌عنوان soft 404 برداشت شود. اگر جایگزین واقعی وجود ندارد، پاسخ 404 یا 410 روشن‌تر است. در پروژه‌های تازه یا بازطراحی‌شده، برنامه‌ریزی URL و ریدایرکت باید بخشی از فرایند باشد؛ راهنمای نکات مهم در طراحی سایت نیز دید کامل‌تری درباره تصمیم‌های اولیه ساختار سایت می‌دهد.

کشف URL را با سایت‌مپ و لینک‌سازی داخلی تقویت کنید

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

در Search Console گزارش Sitemaps را باز کنید، آدرس سایت‌مپ را ثبت کنید و وضعیت آخرین خواندن را ببینید. اگر سایت‌مپ با خطا دریافت می‌شود، ابتدا دسترسی عمومی، فرمت XML و پاسخ سرور را اصلاح کنید. تاریخ lastmod فقط زمانی مفید است که واقعاً با تغییر معنادار محتوا به‌روز شود؛ تغییر روزانه و صوری تاریخ‌ها سیگنال قابل اتکایی نمی‌سازد.

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

معماری مناسب برای یک مقاله جدید

1. مقاله را در دسته تخصصی درست منتشر کنید.
2. از یک یا دو مطلب قدیمی مرتبط به آن لینک بدهید.
3. در متن جدید نیز به منابع داخلی مکمل لینک طبیعی بسازید.
4. صفحه را در سایت‌مپ XML نگه دارید و از ایجاد URLهای برچسبی بی‌ارزش پرهیز کنید.
5. پس از انتشار، مسیر کلیک از صفحه اصلی یا آرشیو وبلاگ تا مقاله را آزمایش کنید.

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

وقتی صفحه خزیده شده ولی ایندکس نمی‌شود، کیفیت را بررسی کنید

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

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

محتوای جاوااسکریپتی نیز باید در نسخه رندرشده برای گوگل قابل مشاهده باشد. در URL Inspection بخش View tested page را ببینید و HTML رندرشده، منابع بارگذاری‌نشده و تصویر صفحه را کنترل کنید. اگر متن اصلی فقط پس از تعامل کاربر یا درخواست مسدودشده نمایش داده می‌شود، ممکن است گوگل نسخه ناقصی دریافت کند. راه‌حل پایدار معمولاً رندر سمت سرور، HTML اولیه معنادار و دسترسی درست به فایل‌های ضروری است.

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

چک‌لیست نهایی رفع مشکل ایندکس نشدن سایت

1. وضعیت را ثبت کنید: از هر گروه خطا یک URL نمونه در Page Indexing و URL Inspection بردارید.
2. نسخه زنده را آزمایش کنید: Crawl allowed، Page fetch و Indexing allowed را بررسی کنید.
3. کد پاسخ را اصلاح کنید: صفحه اصلی 200، انتقال دائمی 301 و صفحه حذف‌شده 404 یا 410 معنادار داشته باشد.
4. موانع را بردارید: robots.txt، meta robots، X-Robots-Tag، فایروال و محدودیت ورود را کنترل کنید.
5. canonical را همسو کنید: لینک داخلی، سایت‌مپ، ریدایرکت و canonical باید یک URL اصلی را تقویت کنند.
6. کشف را بهتر کنید: صفحه یتیم نباشد و از آرشیو و مطالب مرتبط لینک دریافت کند.
7. ارزش محتوا را بسنجید: صفحه باید هدف مستقل، پاسخ کامل و تفاوت روشن با صفحات مشابه داشته باشد.
8. رندر را ببینید: نسخه مشاهده‌شده توسط گوگل نباید متن یا منابع اصلی را از دست بدهد.
9. یک‌بار درخواست ایندکس بدهید: بعد از رفع علت، Request Indexing یا سایت‌مپ را استفاده کنید و زمان کافی بدهید.
10. نتیجه را پایش کنید: تاریخ آخرین خزش، canonical انتخابی و روند تعداد صفحات ایندکس‌شده را هفتگی بررسی کنید.

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

ایندکس شدن یک کلید روشن و خاموش نیست؛ حاصل هماهنگی زیرساخت، معماری اطلاعات، سیگنال‌های فنی و کیفیت صفحه است. Search Console علت را به‌صورت سرنخ نشان می‌دهد، اما تصمیم درست زمانی گرفته می‌شود که گزارش ابزار را با HTML، هدر پاسخ، لاگ سرور و ساختار داخلی سایت کنار هم ببینید.

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

آخرین بررسی منابع: ۲۴ تیر ۱۴۰۵. منابع اصلی این راهنما مستندات رسمی Google Search Central و Search Console هستند.