ایندکس گوگل چیست؟ دلایل ایندکس نشدن سایت

ایندکس گوگل چیست؟

ایندکس (Index) در لغت به معنای فهرست یا نمایه است. در دنیای موتورهای جستجو، ایندکس گوگل یک پایگاه دادهٔ عظیم است که در آن، برای هر صفحه‌ای که گوگل تصمیم گرفته نگه دارد، یک نمایهٔ پردازش‌شده ذخیره می‌شود: متن صفحه، عنوان، تصاویر، لینک‌های خروجی، دادهٔ ساختاریافته، زبان، منطقهٔ جغرافیایی هدف، سیگنال‌های کیفیت و صدها ویژگی دیگر. وقتی کاربری چیزی جستجو می‌کند، گوگل کل وب را نمی‌گردد؛ فقط همین ایندکس را می‌گردد.

پس ایندکس شدن یعنی اینکه صفحهٔ شما وارد این فهرست شده و شانس نمایش در نتایج جستجو را پیدا کرده است. سه نکته اینجا هست که سوءتفاهم‌های رایج را از بین می‌برد و بهتر است از همین ابتدا روشن شود:

ایندکس شدن مساوی رتبه گرفتن نیست. یک صفحه می‌تواند کاملاً ایندکس شده باشد و برای هیچ کلمهٔ کلیدی‌ای در صد نتیجهٔ اول نباشد. ایندکس شرط لازم است، نه کافی.

ایندکس شدن مساوی خزیده شدن نیست. گوگل روزانه میلیاردها آدرس را می‌خزد و بخش بزرگی از آن‌ها را هرگز ایندکس نمی‌کند. خزش یک عمل مکانیکی است؛ ایندکس یک تصمیم است.

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

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

کاربردهای ایندکس گوگل گسترده است. مهم‌ترینش بهبود تجربهٔ کاربری است: با وجود ایندکس، گوگل می‌تواند نتایج جستجو را در کسری از ثانیه و با دقت بالا ارائه دهد. کاربرد دوم، مستقیماً به کار ما مربوط است — بهینه‌سازی موتور جستجو. وب‌سایت‌ها با بهینه‌سازی محتوای خود برای ایندکس گوگل می‌توانند جایگاهشان را در نتایج بهبود دهند و ترافیک بیشتری جذب کنند. کاربرد سوم، تحلیل داده است: گوگل با استفاده از داده‌های ایندکس‌شده می‌تواند الگوهای جستجو و رفتار کاربران را تحلیل کند و گزارش‌های مفیدی در اختیار کسب‌وکارها بگذارد.

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

تفاوت خزش، رندر، ایندکس و رتبه‌بندی در گوگل

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

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

روند ایندکس شدن سایت در گوگل چگونه است؟

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

کشف آدرس ← صف خزش ← دانلود HTML ← صف رندر ← اجرای جاوااسکریپت ← استخراج لینک‌های جدید ← خوشه‌بندی صفحات مشابه ← انتخاب نسخهٔ کنونیکال ← ارزیابی کیفی ← ایندکس یا رد شدن ← بازارزیابی دوره‌ای ← نگه‌داشتن یا حذف از ایندکس

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

مرحلهٔ اول: کشف (Discovery)

گوگل هیچ فهرست مرکزی از همهٔ آدرس‌های وب ندارد؛ باید آن‌ها را پیدا کند. سه مسیر اصلی کشف وجود دارد:

۱. لینک از صفحات شناخته‌شده. مهم‌ترین و طبیعی‌ترین مسیر. گوگل هنگام خزش هر صفحه، تگ‌های <a href> را استخراج می‌کند و آدرس‌های جدید را به صف اضافه می‌کند. توجه کنید: فقط <a href> واقعی. دکمه‌ای که با onclick یا با فراخوانی روتر جاوااسکریپتی کاربر را جابه‌جا می‌کند، از دید گوگل لینک محسوب نمی‌شود.

۲. سایت‌مپ XML. فهرست صریحی که خودتان به گوگل می‌دهید. سایت‌مپ یک پیشنهاد است، نه دستور — اما در سایت‌های بزرگ یا سایت‌هایی با لینک‌دهی داخلی ضعیف، تنها مسیر کشف بخشی از صفحات است.

۳. مسیرهای جانبی. لینک از سایت‌های دیگر، ارجاع در فیدهای RSS و ارسال دستی از طریق ابزار URL Inspection.

خرابی‌های رایج در این مرحله عبارت‌اند از: صفحاتی که هیچ لینک داخلی به آن‌ها نیست (صفحات یتیم یا orphan pages)، ناوبری کاملاً جاوااسکریپتی بدون لینک واقعی، سایت‌مپی که هرگز به‌روز نمی‌شود، و صفحاتی که عمق کلیکشان از صفحهٔ اصلی بیش از چهار یا پنج کلیک است.

برای تشخیص: اگر در URL Inspection پیام «URL is not on Google – Unknown to Google» ببینید، مشکل در مرحلهٔ کشف است، نه کیفیت. راه‌حل لینک داخلی و سایت‌مپ است، نه بازنویسی محتوا. برای پیدا کردن صفحات یتیم هم فهرست آدرس‌های سایت‌مپ را با فهرست آدرس‌هایی که خزندهٔ شما (مثلاً Screaming Frog) از طریق لینک‌های داخلی پیدا کرده مقایسه کنید؛ تفاوت این دو، صفحات یتیم شماست.

مرحلهٔ دوم: خزش (Crawling)

گوگل‌بات درخواست HTTP می‌فرستد و پاسخ سرور را دریافت می‌کند. پیش از هر درخواست، فایل robots.txt را بررسی می‌کند (نسخهٔ کش‌شده، معمولاً تا ۲۴ ساعت اعتبار دارد). واکنش گوگل به کد وضعیتی که سرور شما برمی‌گرداند، تعیین‌کنندهٔ سرنوشت صفحه است:

دو مفهوم ظرفیت خزش شما را تعیین می‌کنند و دانستنشان برای عیب‌یابی ضروری است:

سقف ظرفیت خزش (Crawl Capacity Limit) حداکثر باری است که گوگل حاضر است به سرور شما تحمیل کند. اگر سرور سریع پاسخ دهد و خطا ندهد، این سقف بالا می‌رود؛ اگر خطای 5xx یا 429 ببیند یا زمان پاسخ بالا برود، سقف پایین می‌آید. این سازوکار محافظتی است، نه تنبیهی — گوگل عمداً طوری برنامه‌ریزی شده که سایت را از پا درنیاورد.

تقاضای خزش (Crawl Demand) میزان علاقهٔ گوگل به خزیدن سایت شماست و تابع سه عامل است: موجودی ادراک‌شده (اگر گوگل ببیند سایت پر از آدرس‌های تکراری و بی‌ارزش است، تقاضا کم می‌شود)، محبوبیت (آدرس‌های پرلینک و پرترافیک بیشتر خزیده می‌شوند)، و کهنگی (گوگل تلاش می‌کند صفحاتی را که احتمال تغییرشان بیشتر است زودتر دوباره بخزد).

بودجهٔ خزش نهایی، کمینهٔ این دو است. نکتهٔ عملی مهم: در بیشتر سایت‌های زیر ده هزار آدرس، هیچ‌کدام از این‌ها گلوگاه نیست و وقت گذاشتن روی «بهینه‌سازی بودجهٔ خزش» عملاً اتلاف وقت است.

مرحلهٔ سوم: رندر (Rendering)

گوگل‌بات ابتدا HTML خام را می‌گیرد. سپس صفحه به یک صف جداگانه می‌رود تا در یک مرورگر Chromium بدون رابط گرافیکی، جاوااسکریپت اجرا شود و HTML نهایی تولید گردد. به این سرویس Web Rendering Service یا به‌اختصار WRS گفته می‌شود.

چند نکتهٔ کلیدی که کمتر گفته می‌شود:

• گوگل تمام صفحات با کد ۲۰۰ را به صف رندر می‌فرستد، مگر آنکه در HTML خام تگ noindex دیده باشد. یعنی اگر noindex را با جاوااسکریپت حذف کنید، دیر شده است.
• عکس این هم درست است: اگر جاوااسکریپت شما noindex اضافه کند، گوگل بعد از رندر آن را می‌بیند و اعمال می‌کند.
• فاصلهٔ بین خزش و رندر معمولاً کوتاه است (دقیقه تا چند ساعت) اما برای سایت‌های ضعیف می‌تواند روزها طول بکشد.
• WRS تعاملی نیست: کلیک نمی‌کند، اسکرول نمی‌کند، فرم پر نمی‌کند. محتوایی که فقط با کلیک روی «بیشتر بخوانید» بارگذاری می‌شود، دیده نمی‌شود.
• WRS از حافظهٔ محلی مرورگر، کوکی‌های پایدار و درخواست‌های مجوز (موقعیت مکانی، نوتیفیکیشن) پشتیبانی نمی‌کند یا آن‌ها را رد می‌کند.

برای تشخیص مشکلات رندر، در سرچ کنسول به URL Inspection بروید، Test Live URL را بزنید، سپس View Tested Page و تب HTML را باز کنید. این HTML رندرشده است. اگر متن اصلی صفحه در آن نیست، مشکل رندر دارید. بخش More Info و زیربخش Page resources هم منابعی را که بارگذاری نشده‌اند نشان می‌دهد — این بخش را جدی بگیرید، چون یک فایل جاوااسکریپت بلاک‌شده در robots.txt می‌تواند کل محتوای صفحه را نامرئی کند.

مرحلهٔ چهارم: کنونیکال‌سازی (Canonicalization)

گوگل صفحات با محتوای مشابه را در یک خوشه می‌گذارد و از هر خوشه یک نماینده را به‌عنوان کنونیکال انتخاب می‌کند. فقط کنونیکال در نتایج نمایش داده می‌شود؛ بقیه در ایندکس هستند اما به‌عنوان نسخهٔ جایگزین.

سیگنال‌هایی که گوگل در انتخاب کنونیکال وزن می‌دهد، به ترتیب اهمیت تقریبی: تگ rel="canonical" که خودتان اعلام کرده‌اید (که یک پیشنهاد است نه دستور)، ریدایرکت‌ها، آدرس موجود در سایت‌مپ، الگوی لینک‌دهی داخلی، HTTPS در برابر HTTP، کوتاهی و تمیزی آدرس، و لینک‌های خارجی.

وقتی تگ کنونیکال شما با بقیهٔ سیگنال‌ها در تناقض باشد، گوگل نادیده‌اش می‌گیرد و در گزارش، وضعیت «Duplicate, Google chose different canonical than user» ظاهر می‌شود. خطاهای رایج کنونیکال که در پروژه‌های واقعی زیاد دیده‌ایم:

• کنونیکال همهٔ صفحات به صفحهٔ اصلی اشاره کند — خطای فاجعه‌بار و متأسفانه رایج، معمولاً نتیجهٔ یک قالب یا افزونهٔ بد پیکربندی‌شده
• کنونیکال به صفحه‌ای اشاره کند که خودش noindex است
• کنونیکال به صفحه‌ای اشاره کند که ریدایرکت می‌شود
• زنجیرهٔ کنونیکال: صفحهٔ الف به ب و ب به ج
• کنونیکال نسبی اشتباه که به دامنهٔ دیگری تفسیر شود
• صفحات صفحه‌بندی‌شده که کنونیکالشان به صفحهٔ اول است — این باعث می‌شود محصولات صفحات بعدی هرگز کشف نشوند

مرحلهٔ پنجم: ایندکس و انتخاب کیفی

اینجاست که تصمیم اصلی گرفته می‌شود. گوگل محتوا را تحلیل می‌کند و از خودش می‌پرسد: آیا نگه‌داشتن این صفحه در ایندکس، ارزش هزینهٔ ذخیره‌سازی و پردازشش را دارد؟

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

کیفیت کل سایت، نه فقط صفحه. این نکته‌ای است که نمایندگان گوگل بارها تأکید کرده‌اند: وقتی سیستم‌های گوگل نگرانی جدی دربارهٔ کیفیت کلی یک سایت داشته باشند، به گفتهٔ جان مولر «احتمالاً خیلی کمتر می‌خزیم و خیلی کمتر ایندکس می‌کنیم». یعنی صفحهٔ خوب شما ممکن است قربانی هزار صفحهٔ ضعیف کنارش شود.

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

تقاضای جستجو. اگر گوگل تشخیص دهد هیچ‌کس هرگز چنین چیزی جستجو نمی‌کند، انگیزهٔ کمی برای نگه‌داشتنش دارد.

مرحلهٔ ششم: سرو (Serving)

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

برای بررسی این حالت، در گزارش Performance سرچ کنسول فیلتر Page را روی آن آدرس بگذارید. اگر تعداد نمایش (Impressions) صفر است، مشکل مرتبط‌بودن یا کیفیت است، نه ایندکس.

اصطلاحات کلیدی مربوط به ایندکس گوگل

هر کاری اصطلاحات خودش را دارد و دانستن این اصطلاحات یعنی فهمیدن بهتر آن موضوع. اصطلاحاتی که در زمینهٔ ایندکس باید بشناسید:

• Crawler: خزندهٔ موتور جستجو که وظیفهٔ پیمایش وب را بر عهده دارد.
• Crawl: خزش؛ همان کاری که خزنده‌ها انجام می‌دهند و به آن کراول هم گفته می‌شود.
• Googlebot: خزندهٔ گوگل. دو نسخهٔ اصلی دارد: Smartphone که امروز پیش‌فرض است و Desktop.
• Indexed: صفحه یا سایتی که ایندکس شده باشد.
• Crawl Rate: نرخ خزش؛ نشان می‌دهد خزنده‌های گوگل چقدر به سایت شما مراجعه می‌کنند.
• Crawl Budget: بودجهٔ خزش؛ مجموع آدرس‌هایی که گوگل می‌تواند و می‌خواهد از سایت شما بخزد.
• Canonical: نسخهٔ منتخب از میان صفحات مشابه که در نتایج نمایش داده می‌شود.
• Rendering: اجرای جاوااسکریپت و تولید HTML نهایی توسط سرویس رندر گوگل.
• WRS: سرویس رندر گوگل مبتنی بر Chromium.
• Soft 404: صفحه‌ای که کد ۲۰۰ برمی‌گرداند اما محتوایش عملاً «یافت نشد» است.
• Orphan Page: صفحهٔ یتیم؛ صفحه‌ای که هیچ لینک داخلی به آن وجود ندارد.
• Index Bloat: تورم ایندکس؛ حضور تعداد زیادی صفحهٔ کم‌ارزش در ایندکس.
• Zombie Page: صفحهٔ زامبی؛ صفحه‌ای که ایندکس است اما هیچ ترافیک یا ارزشی تولید نمی‌کند.
• TTFB: زمان تا دریافت اولین بایت پاسخ سرور؛ شاخص کلیدی سرعت پاسخ‌گویی.
• X-Robots-Tag: هدر HTTP معادل متا تگ robots، قابل اعمال روی فایل‌های غیر HTML مثل PDF.

مدت زمان ایندکس شدن سایت در گوگل

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

عوامل مؤثر بر سرعت ایندکس شدن:

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

گوگل با توجه به اولویتی که برای سایت شما در نظر می‌گیرد به‌صورت دوره‌ای مراجعه می‌کند و در یک بازهٔ زمانی مشخص، تعداد مشخصی صفحه ایندکس می‌کند. چند اصل تجربی در این زمینه:

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

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

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

چطور بفهمیم گوگل سایت ما را ایندکس کرده است؟

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

بررسی ایندکس سایت با دستور site:

ساده‌ترین و سریع‌ترین راه. در نوار جستجوی گوگل عبارت site:example.com را وارد کنید (به‌جای example.com دامنهٔ خود را بگذارید). اگر صفحات سایت شما ایندکس شده باشند، فهرستی از آن‌ها نمایش داده می‌شود. از همین روش می‌توانید برای بررسی ایندکس شدن یک صفحهٔ خاص هم استفاده کنید: کافی است آدرس کامل صفحه را بعد از site: بنویسید.

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

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

سرچ کردن مستقیم لینک صفحه در گوگل

به‌جای دستور site: می‌توانید خود لینک را در گوگل جستجو کنید. صفحهٔ موردنظر را در مرورگر کروم باز کنید، روی ابتدای نوار آدرس کلیک کنید، زبان کیبورد را روی انگلیسی بگذارید، کلیدهای Shift و علامت سؤال را بزنید و Enter کنید. اگر نتیجهٔ اول همان صفحهٔ شما بود، یعنی ایندکس شده است.

ابزار URL Inspection در سرچ کنسول

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

1. وارد حساب Google Search Console خود شوید.
2. در منوی بالا روی نوار URL Inspection کلیک کنید.
3. آدرس صفحهٔ موردنظر را وارد کنید.
4. اگر صفحه ایندکس شده باشد پیام «URL is on Google» و در غیر این صورت «URL is not on Google» نمایش داده می‌شود.

اما اطلاعات واقعی این ابزار زیر همین پیام است و اکثر افراد از آن استفاده نمی‌کنند. این ابزار دو حالت دارد که فرقشان حیاتی است:

• حالت پیش‌فرض: آنچه گوگل آخرین بار دیده است. برای فهمیدن اینکه چرا صفحه در وضعیت فعلی قرار دارد.
• Test Live URL: آنچه همین الان اگر بخزد می‌بیند. برای تأیید اینکه رفع مشکل جواب داده است.

اگر این دو با هم فرق داشته باشند، یعنی مشکل رفع شده ولی گوگل هنوز دوباره نخزیده است — و باید صبر کنید، نه اینکه تغییر دیگری بدهید.

اطلاعات کلیدی که حتماً باید در این ابزار بخوانید: بخش Discovery که می‌گوید گوگل این آدرس را از کجا پیدا کرده (سایت‌مپ یا صفحهٔ ارجاع‌دهنده)، بخش Last crawl که تاریخ آخرین خزش را نشان می‌دهد، بخش‌های Crawl allowed و Page fetch که می‌گویند آیا اصلاً دانلود موفق بوده، و مهم‌تر از همه مقایسهٔ User-declared canonical با Google-selected canonical. اگر این دو متفاوت باشند، شما مشکل کنونیکال دارید حتی اگر همه‌چیز عادی به نظر برسد.

گزارش Page Indexing برای بررسی کل سایت

روش‌های بالا برای بررسی یک یا چند صفحه خوب هستند، اما اگر سایت شما صدها یا هزاران صفحه دارد، باید از گزارش Page Indexing (که پیش‌تر Coverage نامیده می‌شد) استفاده کنید. این گزارش قلب کار یک سئوکار در حوزهٔ ایندکس است.

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

مشکل از جایی شروع می‌شود که صفحات مهم شما — دسته‌بندی‌ها، محصولات، مقالات — در فهرست ایندکس‌نشده‌ها باشند. بنابراین باید تمام دلایل را تک‌به‌تک بررسی کنید و بفهمید کدام صفحات واقعاً باید ایندکس می‌شدند و نشده‌اند.

سه نکته در خواندن درست این گزارش که بسیاری نمی‌دانند:

• داده‌ها با تأخیر چند روزه به‌روز می‌شوند. بعد از رفع مشکل، فوراً انتظار تغییر نداشته باشید.
• برای هر دلیل حداکثر هزار نمونه آدرس نشان می‌دهد، اما عدد کل درست است.
• فیلتر بالای صفحه بین «All known pages» و «All submitted pages» را حتماً استفاده کنید. اگر صفحه‌ای در سایت‌مپ فرستاده‌اید و ایندکس نشده، این یک سیگنال جدی است. اما اگر آدرس‌های عجیبی که خودتان نفرستاده‌اید ایندکس نشده‌اند، معمولاً طبیعی است. این تفکیک، سریع‌ترین راه برای جدا کردن مشکل واقعی از نویز است.

و پس از هر اصلاح، حتماً دکمهٔ VALIDATE FIX را بزنید. این اعتبارسنجی صف خزش را برای آن دسته اولویت‌بندی می‌کند و روند بازیابی را تسریع می‌کند.

وضعیت‌های گزارش Page Indexing و راهکار هرکدام

این بخش را می‌توانید به‌عنوان مرجع کنار دستتان نگه دارید. برای هر وضعیت، معنی دقیق، علل واقعی و اقدام درست آورده شده است.

وضعیت‌های «ایندکس نشده» در سرچ کنسول

Server error (5xx) — خطای سرور

معنی: سرور موقع درخواست گوگل، کد ۵۰۰ تا ۵۹۹ برگردانده است.

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

اقدام: لاگ خطای سرور را برای همان بازهٔ زمانی بررسی کنید (نه لاگ دسترسی). در Crawl Stats ببینید آیا خطا در ساعت خاصی متمرکز است. اگر خطا فقط برای گوگل‌بات رخ می‌دهد، تقریباً همیشه مقصر محدودسازی نرخ درخواست یا فایروال است. زمان پاسخ سرور را زیر ۳۰۰ میلی‌ثانیه بیاورید و بعد از رفع، Validate Fix بزنید.

هشدار: خطای 5xx گسترده و طولانی، مستقیم‌ترین مسیر به ایندکس‌زدایی انبوه است. گوگل ابتدا نرخ خزش را کم می‌کند، سپس صفحات را حذف می‌کند.

Redirect error — خطای ریدایرکت

معنی: زنجیرهٔ ریدایرکت خیلی طولانی، حلقهٔ بی‌نهایت، آدرس بیش از حد بلند، یا ریدایرکت به آدرس نامعتبر.

اقدام: زنجیره را با این دستور ببینید:

curl -sIL -A "Googlebot" https://example.com/page | grep -E "^(HTTP|location)"

قانون کلی: حداکثر یک پرش. زنجیره‌های بیش از سه پرش را مستقیم کنید. حلقه‌ها معمولاً از تداخل قوانین می‌آیند — مثلاً یک قانون HTTP را به HTTPS می‌برد و قانون دیگری اسلش انتهایی را حذف یا اضافه می‌کند.

URL blocked by robots.txt — مسدود شده با robots.txt

معنی: گوگل به‌خاطر قانون Disallow اصلاً درخواستی نداده است.

علل واقعی: انتقال Disallow: / از محیط استیجینگ به پروداکشن (کلاسیک‌ترین فاجعه در تاریخ سئو)، الگوی wildcard بیش‌ازحد گسترده، افزونه‌ای که خودکار قانون اضافه می‌کند، و بلاک کردن مسیر منابعی مثل /wp-content/ که رندر را خراب می‌کند.

اقدام: فایل robots.txt خود را مستقیم در مرورگر باز کنید و الگوها را در ابزار تست robots.txt سرچ کنسول بررسی کنید.

هشدار مهم: robots.txt مانع خزش است، نه ایندکس. اگر لینک‌های زیادی به یک صفحهٔ بلاک‌شده وجود داشته باشد، گوگل ممکن است آن را بدون محتوا ایندکس کند. برای جلوگیری از ایندکس، noindex لازم است — و برای دیدن noindex، گوگل باید اجازهٔ خزش داشته باشد. این دو را هرگز با هم روی یک آدرس نگذارید، چون یکدیگر را خنثی می‌کنند.

URL marked ‘noindex’ — علامت‌گذاری شده با noindex

معنی: گوگل دستور noindex را دیده و اطاعت کرده است.

علل واقعی: تیک «Discourage search engines» در وردپرس، تنظیمات پیش‌فرض افزونهٔ سئو روی برخی نوع‌محتواها، تگ باقی‌مانده از محیط استیجینگ، هدر X-Robots-Tag در سطح سرور یا CDN، و تزریق تگ با جاوااسکریپت.

اقدام: هر دو مسیر را بررسی کنید:

curl -sI -A "Googlebot" https://example.com/page | grep -i "x-robots-tag"
curl -s -A "Googlebot" https://example.com/page | grep -i "robots"

اگر تگ در HTML نبود، حتماً هدر HTTP را چک کنید. X-Robots-Tag در سطح Nginx یا Apache یا Cloudflare از دید افزونه‌های سئو و ابزارهای مرورگری کاملاً پنهان می‌ماند و یکی از سخت‌ترین موارد برای پیدا کردن است.

Soft 404 — صفحهٔ ۴۰۴ نرم

معنی: صفحه کد ۲۰۰ برمی‌گرداند اما گوگل تشخیص داده محتوایش عملاً «چیزی پیدا نشد» است.

علل واقعی: صفحهٔ خطای سفارشی که کد ۲۰۰ می‌دهد، صفحات محصول ناموجود، نتایج جستجوی خالی، دسته‌بندی بدون محصول، صفحات اپلیکیشن تک‌صفحه‌ای که برای مسیرهای نامعتبر کد ۲۰۰ می‌دهند، و صفحات با محتوای بسیار کم.

اقدام: برای محتوای واقعاً حذف‌شده کد ۴۰۴ یا ۴۱۰ برگردانید. برای محصول موقتاً ناموجود، صفحه را نگه دارید اما محتوای واقعی اضافه کنید: توضیحات، نظرات، محصولات مشابه، تاریخ تخمینی بازگشت. برای صفحات دسته‌بندی خالی، یا محتوا اضافه کنید یا noindex بگذارید.

Blocked due to unauthorized request (401) و access forbidden (403)

معنی: گوگل با درخواست احراز هویت یا منع دسترسی مواجه شده است.

علل واقعی: محافظت HTTP Basic روی استیجینگ، محدودسازی جغرافیایی IP، حالت Bot Fight در Cloudflare، قوانین ModSecurity، افزونه‌های امنیتی وردپرس که «ربات‌ها» را بلاک می‌کنند، و — بسیار مهم برای سایت‌های ایرانی — بلاک IPهای خارجی در سطح هاست یا فایروال.

اقدام: این تست را انجام دهید:

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/page

اگر با User-Agent گوگل‌بات کد ۴۰۳ می‌گیرید ولی با مرورگر عادی ۲۰۰، مقصر پیدا شده است. محدودهٔ IPهای رسمی گوگل‌بات را در فایروال و CDN به فهرست سفید اضافه کنید.

Not found (404) — یافت نشد

معنی: آدرس کد ۴۰۴ برمی‌گرداند.

اقدام: اگر صفحه جابه‌جا شده، ۳۰۱ به معادل واقعیاش بدهید — نه به صفحهٔ اصلی. اگر عمداً حذف شده، ۴۰۴ درست است و نیازی به اقدام نیست. اما اگر آدرس‌های ۴۰۴ در سایت‌مپ شما هستند، این خطای جدی است که به اعتبار سایت‌مپ ضربه می‌زند. همچنین در URL Inspection بررسی کنید این ۴۰۴ها از کجا کشف شده‌اند؛ اگر لینک داخلی شکسته دارید، اصلاحش کنید.

Blocked due to other 4xx issue

معنی: کد 4xx غیر از موارد بالا، مثل ۴۰۰، ۴۰۵، ۴۱۰ یا ۴۲۹.

اقدام: با curl کد دقیق را بگیرید. کد ۴۲۹ یعنی سرور شما گوگل را محدود می‌کند و باید فوری رفع شود. کد ۴۱۰ اگر عمدی باشد کاملاً درست است.

Alternate page with proper canonical tag

معنی: این صفحه خودش اعلام کرده که نسخهٔ جایگزین صفحهٔ دیگری است.

اقدام: معمولاً هیچ. این وضعیت سالم است. فقط تأیید کنید صفحهٔ کنونیکالش واقعاً ایندکس شده و تعداد این صفحات به‌طور غیرعادی زیاد نیست.

Duplicate without user-selected canonical

معنی: گوگل تشخیص داده صفحه تکراری است و شما هیچ کنونیکالی اعلام نکرده‌اید.

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

Duplicate, Google chose different canonical than user

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

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

Page with redirect

معنی: این آدرس ریدایرکت می‌شود، پس خودش ایندکس نمی‌شود.

اقدام: طبیعی است. فقط مطمئن شوید مقصد ایندکس شده و آدرس‌های ریدایرکتی در سایت‌مپ نیستند.

وضعیت‌های «ایندکس‌شده با هشدار»

Indexed, though blocked by robots.txt

معنی: گوگل بدون خزیدن ایندکسش کرده، صرفاً بر اساس لینک‌های ورودی. معمولاً بدون توضیحات معنادار در نتایج ظاهر می‌شود.

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

Page indexed without content

معنی: گوگل صفحه را ایندکس کرده اما نتوانسته محتوایش را بخواند.

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

اقدام: Test Live URL و بررسی HTML رندرشده. این وضعیت تقریباً همیشه نشانهٔ یک مشکل فنی جدی است.

تفاوت Discovered و Crawled – currently not indexed

این دو وضعیت بیشترین سؤال و بیشترین تشخیص اشتباه را در سئو تولید می‌کنند، بنابراین جداگانه و مفصل بررسی می‌شوند.

وضعیت Discovered – currently not indexed یعنی چه؟

معنی دقیق: گوگل آدرس را می‌شناسد اما هنوز نخزیده است. هیچ قضاوتی دربارهٔ محتوای صفحه انجام نشده، چون اصلاً محتوایش را ندیده.

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

علل واقعی، به ترتیب فراوانی:

1. سرور کند یا ناپایدار است. گوگل صفحه را در صف گذاشته اما وقتی خواسته بخزد، ظرفیت سرور اجازه نداده یا خطا گرفته. شایع‌ترین علت است.
2. حجم آدرس نامتناسب با اعتبار سایت. سایتی که پانصد هزار آدرس تولید می‌کند اما اعتبار یک سایت پنج هزار صفحه‌ای را دارد.
3. کیفیت پایین ادراک‌شدهٔ کل سایت. گوگل تقاضای خزش را برای کل دامنه کاهش داده است.
4. صفحه در عمق زیاد و با لینک‌دهی ضعیف است. گوگل اولویت پایینی برایش قائل شده.
5. الگوی آدرس شبیه چیزی است که قبلاً بی‌ارزش بوده. اگر ده هزار آدرس با الگوی /tag/ قبلاً بی‌ارزش بوده‌اند، آدرس جدید با همان الگو اولویت پایینی می‌گیرد.

اقدام درست:

اقدام غلط: بازنویسی محتوا، اضافه کردن کلمهٔ کلیدی، و درخواست ایندکس تکراری روزانه.

وضعیت Crawled – currently not indexed یعنی چه؟

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

مهم است بدانید این وضعیت دو حالت کاملاً متفاوت را در خود جمع کرده که گوگل تفکیکشان نمی‌کند:

حالت الف — هرگز ایندکس نشده. صفحهٔ جدیدی که خزیده شده و رد شده است.

حالت ب — قبلاً ایندکس بوده و حالا حذف شده. این حالت خطرناک است و از ظاهر گزارش قابل تشخیص نیست. برای تفکیک، باید تاریخچهٔ گزارش Performance آن آدرس را ببینید: اگر در گذشته نمایش داشته و حالا ندارد، حالت ب است — یعنی صفحه‌ای را از دست داده‌اید، نه اینکه هرگز به دست نیاورده باشید. این تفاوت، تفاوت بین «هنوز موفق نشده‌ام» و «داشتم و از دست دادم» است و واکنش متفاوتی می‌طلبد.

علل واقعی:

1. محتوای کم‌ارزش یا نازک. صفحه‌ای که چیزی به وب اضافه نمی‌کند.
2. شباهت محتوایی با صفحات دیگر سایت خودتان. ده مقاله دربارهٔ موضوعی که همگی حرف مشابهی می‌زنند.
3. محتوای قالبی. صفحات محصول با توضیحات یکسان کارخانه، یا صفحات «خدمات در شهر ایکس» که فقط نام شهر عوض شده است.
4. کیفیت کلی سایت. حتی صفحهٔ خوب در سایت ضعیف رد می‌شود.
5. عدم تطابق با هدف جستجو. اگر کلمهٔ کلیدی‌ای که برای صفحه در نظر گرفته‌اید با نوع صفحه‌ای که گوگل برای آن کوئری نشان می‌دهد نخواند، احتمالاً ایندکس نمی‌شود.
6. عدم تقاضای جستجو. موضوعی که کسی دنبالش نیست.
7. محتوای تولیدشده با هوش مصنوعی بدون ارزش افزوده. گوگل با محتوای هوش مصنوعی مشکل ذاتی ندارد، اما با محتوای بی‌ارزش دارد.
8. لینک‌سازی داخلی ضعیف. اگر خود شما به صفحه لینک نداده‌اید، چرا گوگل باید فکر کند مهم است؟
9. صفحه تازه است. گاهی صرفاً باید صبر کرد.

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

اقدام درست، به ترتیب اثربخشی:

1. صادقانه ارزیابی کنید. اگر خودتان کاربر بودید و این صفحه را باز می‌کردید، چیزی یاد می‌گرفتید که در پنج نتیجهٔ اول گوگل نبود؟ اگر پاسخ منفی است، مشکل فنی نیست و راه‌حل فنی هم ندارد.
2. ادغام کنید. به‌جای پانزده مقالهٔ نازک دربارهٔ یک موضوع، یک مقالهٔ عمیق بسازید و بقیه را با ۳۰۱ به آن ریدایرکت کنید. این مؤثرترین اقدام ممکن است و معمولاً نتیجهٔ سریعی می‌دهد.
3. حذف کنید. صفحاتی که هیچ‌وقت ارزش ایندکس شدن نداشته‌اند — تگ‌های خودکار، آرشیو نویسنده، صفحات نتایج جستجوی داخلی — را noindex کنید یا حذف کنید.
4. لینک داخلی از صفحات معتبر بسازید. به گوگل نشان می‌دهد این صفحه در نظر خودتان مهم است. تا جایی که ممکن است لینک‌سازی داخلی را دستی و با انکرتکست درست انجام دهید، نه با افزونه‌های خودکار.
5. حجم و عمق محتوا را کافی کنید. برای صفحات محصول و دسته‌بندی هم حداقل ۳۰۰ تا ۵۰۰ کلمه محتوای واقعی بنویسید تا گوگل هدف صفحه را بفهمد.
6. تمایز واقعی ایجاد کنید. داده، تصویر اختصاصی، تجربهٔ دست‌اول، جدول مقایسه، ابزار — چیزی که کپی‌شدنی نباشد.
7. هدف جستجو را درست انتخاب کنید. در زمان تحقیق کلمات کلیدی، نوع صفحه‌ای که برای هر کلمه می‌سازید باید با نوع صفحاتی که گوگل در نتایج آن کلمه نشان می‌دهد یکی باشد.

جمله‌ای که باید همیشه در ذهن داشته باشید: وقتی درصد بالایی از سایت در وضعیت Crawled – currently not indexed است، مشکل به‌ندرت در تک‌تک صفحات است؛ مشکل در نسبت «صفحات ارزشمند به کل صفحات» سایت است.

درخت تصمیم: چرا این صفحه ایندکس نمی‌شود؟

وقتی می‌پرسند «چرا این صفحه ایندکس نمی‌شود؟»، این ترتیب را طی کنید و هرگز از وسط شروع نکنید:

1. آیا آدرس درست است؟ پروتکل، www، اسلش انتهایی، حروف بزرگ و کوچک. اگر بله، برو به مرحلهٔ بعد.
2. در URL Inspection پیام Unknown to Google می‌بینید؟ اگر بله، مشکل کشف است: لینک داخلی بسازید و آدرس را در سایت‌مپ بگذارید.
3. آیا robots.txt اجازه می‌دهد؟ اگر Crawl allowed برابر No است، robots.txt را اصلاح کنید.
4. آیا Page fetch موفق است و کد ۲۰۰ برمی‌گردد؟ اگر نه، مشکل سرور، فایروال یا احراز هویت است.
5. آیا noindex وجود دارد؟ هم متا تگ و هم هدر X-Robots-Tag را بررسی کنید.
6. در Test Live URL، آیا محتوای اصلی در HTML رندرشده هست؟ اگر نه، مشکل رندر و جاوااسکریپت است.
7. آیا Google-selected canonical با آدرس شما یکی است؟ اگر نه، مشکل محتوای تکراری یا کنونیکال است.
8. آیا صفحه لینک داخلی معنادار دارد و عمق کلیکش کم است؟ اگر نه، معماری لینک داخلی را اصلاح کنید.
9. اگر تا اینجا همه‌چیز سالم بود، مشکل کیفیت است. این پرارجاع‌ترین حالت است و راه‌حلش محتوایی است، نه فنی.

دلایل ایندکس نشدن سایت توسط گوگل

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

بلاک شدن خزنده با robots.txt یا htaccess

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

User-agent: *
Disallow: /

این دو خط، شایع‌ترین علت فاجعه‌های ایندکس در تاریخ سئو است و معمولاً از انتقال ناخواستهٔ فایل robots.txt محیط توسعه به سایت اصلی می‌آید. توصیهٔ عملی: فایل robots.txt را در کنترل نسخه بگذارید و در فرآیند انتشار، یک بررسی خودکار قرار دهید که وجود Disallow: / در محیط اصلی را تشخیص دهد و انتشار را متوقف کند.

ایندکس نشدن به دلیل تنظیمات نادرست در فایل htaccess

یکی از دلایلی که کمتر به آن توجه می‌شود، تنظیمات نادرست در فایل .htaccess است. مواردی که باید بررسی کنید:

• دستورات اضافی یا خطاهای تایپی که می‌توانند مانع دسترسی خزنده‌ها شوند
• تنظیمات محافظت با رمز که ناخواسته فعال مانده است
• دستورات مسدودکننده بر اساس User-Agent یا IP که گوگل‌بات را هم شامل می‌شوند
• قوانین ریدایرکت متناقض که حلقه یا زنجیرهٔ طولانی می‌سازند

برای رفع، فایل را ویرایش کنید و دستورات اضافی را حذف کنید. همیشه پیش از ویرایش یک نسخهٔ پشتیبان بگیرید، چون یک خطای کوچک در این فایل می‌تواند کل سایت را از دسترس خارج کند.

تگ noindex در متا تگ یا هدر سرور

اگر صفحه‌ای از سایت شما ایندکس نمی‌شود، ممکن است این دستور در کد صفحه وجود داشته باشد:

<meta name="robots" content="noindex, nofollow">

دستور noindex به موتورهای جستجو می‌گوید این صفحه را در نتایج نشان ندهند و nofollow می‌گوید لینک‌های داخل صفحه را دنبال نکنند. اما همان‌طور که پیش‌تر گفتیم، این تگ می‌تواند در سه جای مختلف باشد: در HTML صفحه، در هدر HTTP به شکل X-Robots-Tag، یا تزریق‌شده با جاوااسکریپت. اگر در HTML پیدایش نکردید، حتماً دو مورد دیگر را بررسی کنید.

مقادیر پرکاربرد متا تگ robots که یک سئوکار باید بشناسد:

نبود یا به‌روز نبودن نقشهٔ سایت

اگر به‌تازگی سایت را راه‌اندازی کرده‌اید و مدتی است ایندکس نشده، حتماً سایت‌مپ بسازید و در سرچ کنسول ثبت کنید. اگر سایت شما وردپرسی است، افزونه‌های سئو مثل Yoast و RankMath یا افزونه‌های تخصصی مثل XML Sitemap Generator for Google این کار را برایتان انجام می‌دهند.

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

پارامترهای URL و تولید انبوه آدرس تکراری

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

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

عدم تطابق صفحه با هدف جستجوی کاربر

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

خطاهای اتصال، DNS و انقضای گواهی SSL

زمانی که خزنده‌های گوگل به هر دلیلی نتوانند به سرور شما دسترسی پیدا کنند، این مشکل رخ می‌دهد. شاید هاست شما در حال تعمیرات باشد، یا سایت را به‌تازگی به سرور دیگری منتقل کرده باشید و تنظیمات DNS به‌درستی منتشر نشده باشد. انقضای گواهی SSL هم — حتی برای چند ساعت — می‌تواند اثر قابل‌توجهی بگذارد.

برای بررسی این موضوع در سرچ کنسول این مسیر را طی کنید: وارد سرچ کنسول شوید، سایت خود را انتخاب کنید، روی Settings کلیک کنید، در بخش Crawl stats روی Open report بزنید، سپس Host status و در نهایت DNS resolution را ببینید.

جریمهٔ ارثی دامنه و سابقهٔ قبلی آن

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

خطاهای خزش و مشکلات سمت سرور

اگر تمام موارد بالا را بررسی کردید و مشکلی نبود، احتمالاً علت به خطاهای خزش برمی‌گردد. مهم‌ترین آن‌ها خطاهای سمت سرور هستند که می‌توانند ناشی از در دسترس نبودن سرور، کندی بیش از حد، یا محدودیت منابع باشند. مسیر بررسی: سرچ کنسول، انتخاب سایت، Settings، بخش Crawl stats و Open report.

حجم بالای محتوای تکراری در سایت

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

همیشه این را در ذهن داشته باشید: خزیدن صفحات و ذخیره‌سازی اطلاعاتشان برای گوگل هزینهٔ واقعی دارد. بنابراین طبیعی است که رفتار خزنده‌هایش را در مواجهه با محتوای تکراری بهینه کند. اگر محتوای تکراری داشته باشید، یا صفحاتتان ایندکس نمی‌شوند، یا ایندکس می‌شوند ولی جایگاه مناسبی نمی‌گیرند و بعد از مدتی تبدیل به صفحات زامبی می‌شوند که فقط بودجهٔ خزش را هدر می‌دهند.

نکتهٔ مهمی که باید بدانید: محتوای تکراری «جریمه» ندارد. گوگل صرفاً یکی از نسخه‌ها را انتخاب می‌کند و بقیه را نمایش نمی‌دهد. اما نتیجهٔ عملی برای شما همان است — صفحه دیده نمی‌شود.

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

شاید این مطلب هم برای شما جالب باشد:

مسائل جاوااسکریپت و AJAX

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

سرعت پایین پاسخ سرور و کیفیت هاستینگ

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

• تجربهٔ کاربری ضعیف: صفحات کند باعث ترک سریع سایت توسط کاربران می‌شوند.
• کاهش بودجهٔ خزش: اگر صفحات کند بارگذاری شوند، گوگل در زمان محدود خود نمی‌تواند همهٔ صفحات را بخزد.
• خطاهای سمت سرور: گوگل پارامتری به نام Average page response time for a crawl در نظر می‌گیرد. منظور از این پارامتر، مدت زمانی است که طول می‌کشد تا سرور شما به درخواست گوگل پاسخ اولیه بدهد. توجه کنید که این زمان شامل بارگذاری منابع صفحه مثل اسکریپت‌ها و تصاویر نمی‌شود و فقط زمان پاسخ اولیهٔ سرور را در بر می‌گیرد. هدف مطلوب: زیر ۳۰۰ میلی‌ثانیه.

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

کیفیت پایین هاستینگ

در برخی موارد علت ایندکس نشدن به کیفیت هاست برمی‌گردد. سرعت و پایداری هاست خود را بررسی کنید و در صورت بروز اختلالات مکرر، آن را تغییر دهید. یک نکتهٔ مهم که در بخش مسائل سایت‌های ایرانی به آن برمی‌گردیم: سرعت پاسخ‌گویی هاست شما به درخواست‌های بین‌المللی ممکن است کاملاً متفاوت از سرعتی باشد که خودتان تجربه می‌کنید.

مشکل ایندکس نشدن سایت وردپرسی

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

برای بررسی، از پیشخوان وردپرس به بخش تنظیمات و سپس تب خواندن بروید. گزینهٔ مربوط به جلوگیری از نمایه‌سازی موتورهای جستجو نباید تیک داشته باشد.

نکتهٔ مهم: وقتی این تیک فعال است، وردپرس یک noindex سراسری روی کل سایت اعمال می‌کند. بنابراین اگر در گزارش Page Indexing دستهٔ «URL marked noindex» ناگهان با هزاران آدرس رشد کرده، اولین جایی که باید نگاه کنید همین گزینه است.

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

این بخش دربارهٔ بدترین سناریوی روزمرهٔ یک سئوکار است: صبح می‌آیید و می‌بینید تعداد صفحات ایندکس‌شده از چهل هزار به نه هزار رسیده است. این وضعیت روش برخورد کاملاً متفاوتی نسبت به «یک صفحه ایندکس نمی‌شود» می‌طلبد.

آیا افت ایندکس واقعاً مشکل است یا پاک‌سازی سالم؟

قبل از هر اقدامی این سؤال را جواب دهید، چون در بخش قابل‌توجهی از موارد، افت تعداد صفحات ایندکس‌شده اصلاً مشکل نیست.

نمودار نمایش (Impressions) و کلیک در گزارش Performance را کنار نمودار صفحات ایندکس‌شده بگذارید:

این تفکیک اهمیت زیادی دارد، چون گوگل از سال ۲۰۲۵ به‌طور محسوسی سخت‌گیرتر شده است. در دوره‌ای که در صنعت به «پاک‌سازی ایندکس» معروف شد و از اواخر ماه می ۲۰۲۵ آغاز گردید، رصدهای مستقل نشان دادند حدود ۲۵ درصد از صفحات تحت پایش از ایندکس خارج شدند و سایت‌های منفرد بین ۱۵ تا ۷۵ درصد صفحات ایندکس‌شده‌شان را از دست دادند. مشخصهٔ مشترک صفحات حذف‌شده این بود که در دوازده ماه گذشته کلیک و نمایش صفر یا نزدیک به صفر داشتند. نکتهٔ جالب اینکه بسیاری از این سایت‌ها هیچ افت ترافیکی تجربه نکردند؛ یکی از موارد ثبت‌شده ۷۵ درصد صفحاتش را از دست داد و ترافیکش صعودی ماند.

پس اولین کاری که می‌کنید این است: فهرست آدرس‌های حذف‌شده را بگیرید و ببینید چند درصدشان اصلاً هرگز ترافیکی داشته‌اند. اگر جواب «تقریباً هیچ‌کدام» است، شما یک بحران ندارید؛ یک صورت‌حساب دارید بابت انتشار انبوه محتوای بی‌مصرف. و پاسخ درست به این صورت‌حساب، تلاش برای ایندکس مجدد آن صفحات نیست — تغییر استراتژی تولید محتواست.

تعیین دامنهٔ آسیب: کدام بخش سایت از ایندکس خارج شده؟

اگر افت واقعی است، از گزارش Page Indexing دلایلی را که بیشترین رشد را داشته‌اند شناسایی کنید و سپس این سه سؤال را جواب دهید:

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

پروتکل ۷۲ ساعت اول بعد از افت ناگهانی ایندکس

وقتی افت واقعی است، به این ترتیب پیش بروید. هدف، رد کردن سریع علل فاجعه‌بار و برگشت‌پذیر است.

ساعت صفر تا دو: بررسی‌های فوری

۱. فایل robots.txt. دنبال Disallow: / بگردید و تاریخچهٔ فایل را در کنترل نسخه یا بایگانی وب بررسی کنید.

curl -s https://example.com/robots.txt

۲. متا تگ و هدر noindex در نمونه‌ای از صفحات مختلف. فقط یک صفحه را چک نکنید؛ از هر نوع صفحه (اصلی، محصول، دسته‌بندی، مقاله) یک نمونه بگیرید.

curl -sI -A "Googlebot" https://example.com/page | grep -i "x-robots-tag"
curl -s -A "Googlebot" https://example.com/page | grep -io '<meta[^>]*robots[^>]*>'

۳. کد وضعیت با User-Agent گوگل‌بات. اگر با نتیجهٔ مرورگر عادی فرق دارد، مشکل را پیدا کرده‌اید.

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -o /dev/null -w "%{http_code}\n"

۴. ابزار Removals در سرچ کنسول. بررسی کنید کسی درخواست حذف موقت با الگوی پیشوندی ثبت نکرده باشد. یک درخواست اشتباه با پیشوند می‌تواند کل یک بخش سایت را از نتایج پنهان کند.

۵. تنظیمات وردپرس. همان تیک بخش خواندن.

۶. اعتبار گواهی SSL و دسترس‌پذیری دامنه.

ساعت دو تا بیست‌وچهار: بررسی‌های عمیق‌تر

• Crawl Stats: آیا افت خزش پیش از افت ایندکس شروع شده؟ اگر بله، مشکل در دسترس‌پذیری است نه کیفیت.
• لاگ سرور: کد وضعیتی که گوگل‌بات واقعاً دریافت کرده در بازهٔ حادثه. بین لاگ سرور و سرچ کنسول، همیشه لاگ حقیقت را می‌گوید.
• کنونیکال‌ها: نمونه‌گیری از بیست صفحه. آیا همه به یک آدرس اشاره می‌کنند؟ آیا به دامنهٔ دیگری اشاره می‌کنند؟
• رندر: Test Live URL روی چند صفحه از الگوهای مختلف.
• Manual Actions و Security Issues: دو گزارشی که دقیقاً در لحظهٔ بحران فراموش می‌شوند. حتماً باز کنید.
• تاریخچهٔ DNS و CDN: تغییر رکورد، انقضای دامنه، تغییر تنظیمات فایروال.

ساعت بیست‌وچهار تا هفتادودو: اگر هنوز علتی پیدا نشده

• کل سایت را با یک خزندهٔ حرفه‌ای و با User-Agent گوگل‌بات بخزید و با خزش پیش از حادثه مقایسه کنید. اگر خزش تاریخی ندارید، از امروز عادت کنید ماهانه یکی بگیرید — این عادت روزی شما را نجات می‌دهد.
• الگوی دقیق آدرس‌های حذف‌شده را استخراج کنید.
• تاریخ حادثه را با فهرست آپدیت‌های اعلام‌شدهٔ گوگل تطبیق دهید.
• بایگانی وب را برای همان تاریخ‌ها بررسی کنید تا ببینید سایت در آن روزها چه شکلی بوده است.

یازده سناریوی ایندکس‌زدایی انبوه و درمان هرکدام

سناریو ۱ — انتقال Disallow از استیجینگ

نشانه: افت ناگهانی و شدید طی چند روز؛ رشد انفجاری دستهٔ «Blocked by robots.txt».

درمان: اصلاح فایل، زدن Validate Fix و ارسال مجدد سایت‌مپ.

زمان بازیابی: یک تا سه هفته برای بخش عمده.

سناریو ۲ — noindex سراسری

نشانه: رشد شدید دستهٔ «URL marked noindex».

علت: تیک وردپرس، تنظیم غلط افزونهٔ سئو، قالب جدیدی که تگ را دارد، یا هدر X-Robots-Tag در سطح سرور یا CDN.

درمان: حذف تگ و درخواست ایندکس دستی برای صفحات حیاتی.

زمان بازیابی: دو تا شش هفته.

سناریو ۳ — ناپایداری یا کندی سرور

نشانه: افت تدریجی طی چند هفته. در Crawl Stats زمان پاسخ بالا رفته، تعداد درخواست‌ها پایین آمده و درصد خطای 5xx زیاد شده است.

درمان: ارتقای زیرساخت، کش سمت سرور، CDN و بهینه‌سازی دیتابیس. هدف: میانگین زمان پاسخ زیر ۳۰۰ میلی‌ثانیه.

زمان بازیابی: چهار تا دوازده هفته، چون گوگل باید دوباره اعتماد کند که سرور پایدار شده است.

نکته: این علت به‌شدت کم‌تشخیص داده می‌شود چون تدریجی است و کسی آن را به یک رویداد مشخص نسبت نمی‌دهد.

سناریو ۴ — فایروال، WAF یا CDN که گوگل‌بات را بلاک می‌کند

نشانه: رشد خطای ۴۰۳ یا ۵۰۳ در Crawl Stats، در حالی که سایت برای شما کاملاً سالم است.

علت: حالت Under Attack یا Bot Fight در Cloudflare، قوانین ModSecurity، افزونه‌های امنیتی وردپرس، محدودسازی نرخ درخواست، یا بلاک جغرافیایی.

درمان: IPهای رسمی گوگل‌بات را در فهرست سفید بگذارید و ربات‌های تأییدشده را مجاز کنید.

زمان بازیابی: دو تا شش هفته.

سناریو ۵ — مهاجرت ناقص

نشانه: افت شروع‌شده دقیقاً از تاریخ مهاجرت؛ رشد ۴۰۴ و «Page with redirect».

درمان: فهرست کامل آدرس‌های قدیمی را از چند منبع (سرچ کنسول، آنالیتیکس، ابزارهای بک‌لینک، بایگانی وب) استخراج و نگاشت یک‌به‌یک بسازید. ریدایرکت انبوه به صفحهٔ اصلی به‌عنوان soft 404 تلقی می‌شود و هیچ ارزشی منتقل نمی‌کند.

زمان بازیابی: دو تا شش ماه.

سناریو ۶ — تغییر معماری کنونیکال

نشانه: رشد دسته‌های «Alternate page with proper canonical tag» یا «Duplicate, Google chose different canonical».

علت: قالب یا افزونهٔ جدیدی که کنونیکال همهٔ صفحات را به صفحهٔ اصلی یا دسته‌بندی می‌فرستد.

زمان بازیابی: سه تا هشت هفته.

سناریو ۷ — تولید انبوه آدرس و رقیق شدن سایت

نشانه: تعداد کل آدرس‌های شناخته‌شده رشد انفجاری کرده و درصد ایندکس‌شده سقوط کرده است.

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

درمان: هدف را روی بالا بردن نسبت «آدرس‌های ارزشمند به کل آدرس‌ها» بگذارید.

زمان بازیابی: دو تا چهار ماه.

سناریو ۸ — پاک‌سازی کیفی گوگل

نشانه: رشد تدریجی «Crawled – currently not indexed» طی ماه‌ها. صفحات حذف‌شده تقریباً همگی صفحاتی هستند که هرگز کلیک نگرفته‌اند و ترافیک کل تقریباً بدون تغییر مانده است.

درمان: این را مشکل ندانید، بازخورد بدانید. محتوای بی‌مصرف را حذف یا ادغام کنید، بودجهٔ محتوا را از «تعداد» به «عمق» منتقل کنید، و صفحاتی را که واقعاً ارزش دارند اما بی‌ترافیک‌اند با لینک داخلی و به‌روزرسانی تقویت کنید.

سناریو ۹ — جریمهٔ دستی یا مشکل امنیتی

نشانه: افت ناگهانی و کامل، همراه با پیام در گزارش Manual Actions یا Security Issues.

علت: هک شدن، تزریق اسپم، لینک‌سازی مصنوعی، یا محتوای اسپم.

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

زمان بازیابی: دو هفته تا چند ماه.

سناریو ۱۰ — شکست رندرینگ بعد از انتشار نسخهٔ جدید

نشانه: افت شروع‌شده از تاریخ یک انتشار فرانت‌اند؛ رشد «Crawled – currently not indexed» یا «Page indexed without content».

علت: به‌روزرسانی فریم‌ورک که رندر سمت سرور را شکسته، مسیر API که در robots.txt بسته شده، یا خطای جاوااسکریپت در محیط بدون رابط گرافیکی.

زمان بازیابی: سه تا هشت هفته.

سناریو ۱۱ — مشکلات دامنه، DNS و SSL

نشانه: افت کامل و ناگهانی؛ سایت گاهی در دسترس است و گاهی نه.

علت: انقضای موقت دامنه، تغییر نیم‌سرور، پیکربندی غلط DNS، یا انقضای گواهی SSL.

پیشگیری: یک هشدار خودکار برای انقضای دامنه و گواهی SSL بگذارید. این ساده‌ترین بیمه‌ای است که می‌توانید بخرید.

نقشهٔ راه ۹۰ روزهٔ بازیابی ایندکس

بعد از رفع علت، بازیابی خودکار و آنی نیست. این برنامه را دنبال کنید.

هفتهٔ اول — توقف خون‌ریزی: علت ریشه‌ای رفع و با curl و URL Inspection تأیید شده باشد. برای همهٔ دسته‌های مرتبط Validate Fix بزنید. سایت‌مپ‌ها را به‌روز و دوباره ارسال کنید. برای ده تا بیست صفحهٔ حیاتی درخواست ایندکس دستی بدهید. Crawl Stats را روزانه پایش کنید.

هفتهٔ دوم تا چهارم — تسهیل خزش مجدد: زمان پاسخ سرور را زیر ۳۰۰ میلی‌ثانیه تثبیت کنید. یک سایت‌مپ اختصاصی برای آدرس‌های در حال بازیابی بسازید و جداگانه ارسال کنید تا آمارش قابل رصد باشد. از صفحهٔ اصلی و صفحات پرقدرت به دسته‌های آسیب‌دیده لینک موقت بدهید. آدرس‌های بی‌ارزش را از سایت‌مپ حذف کنید تا سیگنال تمیزتر شود.

ماه دوم — پاک‌سازی ساختاری: یک حسابرسی محتوا انجام دهید و هر آدرس را در یکی از چهار دستهٔ «نگه‌داشتن، به‌روزرسانی، ادغام، حذف» بگذارید. ادغام‌ها را با ۳۰۱ انجام دهید. صفحات بی‌ارزش اما لازم (سبد خرید، حساب کاربری، نتایج جستجو) را noindex کنید. عمق کلیک صفحات مهم را به زیر چهار برسانید.

ماه سوم — تثبیت و پایش: گزارش مقایسه‌ای بگیرید (ایندکس، خزش و ترافیک نسبت به پیش از حادثه). تحلیل لاگ انجام دهید تا سلامت الگوی خزش را تأیید کنید. پایش خودکار تعریف کنید. و حادثه را مستند کنید: چه شد، چرا شد، چه کردیم، چطور دیگر رخ ندهد.

انتظار واقع‌بینانه از زمان بازیابی:

بازیابی معمولاً پله‌ای است نه خطی: چند روز هیچ اتفاقی نمی‌افتد و بعد یک جهش رخ می‌دهد. این طبیعی است و به معنای بی‌اثر بودن اقدامات شما نیست.

ابزارهای کنترل ایندکس و کاربرد درست هرکدام

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

فایل robots.txt و کاربرد درست آن

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

یک نمونهٔ ساختار سالم:

User-agent: *
Disallow: /wp-admin/
Disallow: /cart/
Disallow: /*?sort=
Disallow: /*?filter=
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/sitemap_index.xml

نکاتی که باید بدانید:

• هر زیردامنه فایل robots.txt مستقل خودش را دارد.
• گوگل تا ۵۰۰ کیبی‌بایت اول فایل را می‌خواند.
• در تعارض قوانین، قانون خاص‌تر برنده است، نه قانونی که اول نوشته شده.
• منابع لازم برای رندر — فایل‌های CSS، جاوااسکریپت و تصاویر — را هرگز نبندید.
• دستور crawl-delay را گوگل نادیده می‌گیرد. این دستور فقط برای برخی موتورهای دیگر معنا دارد.
• آدرس بلاک‌شده می‌تواند از طریق لینک‌های ورودی و بدون محتوا ایندکس شود.

متا تگ robots و هدر X-Robots-Tag

برای جلوگیری واقعی از ایندکس شدن، این روش درست است. دو شکل دارد:

<meta name="robots" content="noindex, follow">

یا در سطح هدر HTTP، که برای فایل‌های غیر HTML مثل PDF تنها گزینه است:

X-Robots-Tag: noindex, nofollow

نکتهٔ کلیدی که ارزش تکرار دارد: گوگل برای دیدن noindex باید بتواند صفحه را بخزد. اگر همان صفحه در robots.txt بسته باشد، دستور هرگز دیده نمی‌شود و صفحه ممکن است بدون محتوا در نتایج بماند.

تگ rel=canonical برای مدیریت محتوای تکراری

<link rel="canonical" href="https://example.com/page/">

قواعد استفادهٔ درست: همیشه آدرس مطلق بنویسید، هر صفحه باید کنونیکال خودارجاع داشته باشد، به یاد داشته باشید که کنونیکال یک پیشنهاد است و گوگل می‌تواند ردش کند، و بدانید که بین صفحاتی که محتوایشان واقعاً متفاوت است کار نمی‌کند. برای صفحات صفحه‌بندی‌شده هم هر صفحه باید کنونیکال خودش باشد، نه صفحهٔ اول.

سایت‌مپ XML و قواعد ساخت آن

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

آیا نقشهٔ سایت به رتبهٔ شما کمک می‌کند؟ خیر، تفاوت مستقیمی در رتبه ایجاد نمی‌کند. اما به سریع‌تر ایندکس شدن کمک قابل‌توجهی می‌کند. در دو تصویر زیر می‌توانید تفاوت زمان خزش سایت بدون نقشهٔ سایت و با نقشهٔ سایت را ببینید:

ساختار یک ورودی سایت‌مپ:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/page/</loc>
    <lastmod>2026-07-20T10:30:00+03:30</lastmod>
  </url>
</urlset>

قواعدی که رعایتشان تفاوت ایجاد می‌کند:

• حداکثر پنجاه هزار آدرس یا پنجاه مگابایت غیرفشرده در هر فایل؛ بیشتر از آن باید با فایل شاخص سایت‌مپ مدیریت شود.
• فقط آدرس‌های کنونیکال با کد ۲۰۰. هیچ آدرس ریدایرکتی، ۴۰۴ی یا noindex‌داری نباید داخل سایت‌مپ باشد. سایت‌مپ کثیف، اعتماد گوگل را از بین می‌برد.
• تاریخ lastmod را فقط برای تغییرات معنادار به‌روز کنید. اگر همهٔ تاریخ‌ها را روزانه به امروز تغییر دهید، گوگل کلاً به lastmod شما بی‌اعتماد می‌شود و این مزیت را از دست می‌دهید.
• مقادیر priority و changefreq نادیده گرفته می‌شوند؛ وقت صرفشان نکنید.
• سایت‌مپ را تفکیک کنید. به‌جای یک فایل غول‌پیکر، فایل‌های جدا برای محصولات، دسته‌بندی‌ها و مقالات بسازید. دلیلش صرفاً نظم نیست: سرچ کنسول نرخ ایندکس را به تفکیک هر سایت‌مپ نشان می‌دهد و این قدرتمندترین ابزار تشخیصی رایگان شماست. اگر ۹۵ درصد مقالات ایندکس شده و ۳۰ درصد محصولات، در چند ثانیه می‌فهمید کجا را باید بگردید.
• آدرس سایت‌مپ را در فایل robots.txt اعلام کنید.

معرفی نقشهٔ سایت در سرچ کنسول

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

یک نکتهٔ تشخیصی: ستون تعداد آدرس‌های کشف‌شده را با تعداد واقعی آدرس‌های داخل سایت‌مپ مقایسه کنید. اگر خیلی کمتر است، سایت‌مپ شما خطای پارس دارد.

صفحاتی که نباید ایندکس شوند

بعضی صفحات سایت شما فقط جنبهٔ کاربردی دارند و نباید در نتایج جستجو ظاهر شوند:

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

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

برای آشنایی بیشتر با نحوهٔ کار با فایل robots.txt، مطالب زیر را ببینید:

شاید این مطلب هم برای شما جالب باشد:

بودجهٔ خزش (Crawl Budget) و راه‌های مدیریت آن

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

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

اهرم‌های افزایش بودجه

1. سرعت پاسخ سرور. مؤثرترین اهرم. هر کاهش در زمان پاسخ مستقیماً سقف ظرفیت خزش را بالا می‌برد.
2. پشتیبانی از کش HTTP. با هدرهای ETag و Last-Modified و پاسخ ۳۰۴ می‌توانید بخش قابل‌توجهی از بودجه را آزاد کنید. این تکنیک به‌شدت کم‌استفاده است و در سایت‌های بزرگ تفاوت چشمگیری ایجاد می‌کند.
3. حذف خطاها. هر خطای 5xx و ۴۲۹ مستقیماً ظرفیت را کاهش می‌دهد.

اهرم‌های کاهش هدررفت

1. کاهش تعداد آدرس‌های بی‌ارزش. بزرگ‌ترین برد. فیلترها، مرتب‌سازی، پارامترهای رهگیری، نتایج جستجوی داخلی و آرشیو تگ‌های خودکار.
2. حذف زنجیرهٔ ریدایرکت. هر پرش اضافه یک درخواست هدررفته است.
3. کد وضعیت درست برای صفحات حذف‌شده. کد ۴۰۴ یا ۴۱۰، نه ریدایرکت به صفحهٔ اصلی و نه صفحهٔ خالی با کد ۲۰۰.
4. سایت‌مپ تمیز و lastmod قابل اعتماد.
5. حذف soft 404ها.

آنچه بودجهٔ خزش را افزایش نمی‌دهد

افزودن priority یا changefreq به سایت‌مپ، ارسال مکرر سایت‌مپ، فشرده‌سازی تصاویر (که روی تجربهٔ کاربر اثر دارد اما روی بودجهٔ خزش تقریباً هیچ)، دستور crawl-delay در robots.txt، و استفاده از noindex به‌جای robots.txt برای صرفه‌جویی — چون noindex خودش نیازمند خزش است و صرفه‌جویی نمی‌کند.

پایش وضعیت خزش در گزارش Crawl Stats

برای بررسی اینکه گوگل چه مقدار از سایت شما را می‌خزد، به بخش Crawl Stats در تنظیمات سرچ کنسول بروید.

سه نمودار کلیدی که باید بخوانید:

• Total crawl requests: روند کلی خزش. افت ناگهانی زنگ خطر است.
• Average response time: اگر بالای ۶۰۰ میلی‌ثانیه است، سقف ظرفیت خزش شما محدود شده است.
• تفکیک‌ها: بخش By response توزیع کدهای وضعیت را نشان می‌دهد؛ اگر درصد بالایی 5xx یا ۴۰۳ می‌بینید، همهٔ کارهای دیگر را رها کنید و اول این را حل کنید. بخش By purpose هم نسبت Refresh به Discovery را نشان می‌دهد و می‌گوید گوگل چقدر از وقتش را صرف کشف صفحات جدید می‌کند در برابر بازبینی قدیمی‌ها.

هرچه تعداد خزش‌های روزانه بیشتر و زمان پاسخ کمتر باشد، بهتر است. اگر نمودار خزش شما رو به کاهش است، به‌جای انتشار محتوای بیشتر، اول علت کاهش را پیدا کنید — معمولاً مشکل سمت سرور یا کیفیت است، نه کمبود محتوا.

لاگ سرور: تنها منبع حقیقت

سرچ کنسول نمونه‌گیری‌شده، تأخیردار و محدود است. لاگ سرور نیست. برای هر پروژهٔ جدی، تحلیل لاگ غیرقابل جایگزین است. از لاگ می‌توانید بفهمید گوگل‌بات واقعاً کدام آدرس‌ها را و با چه فرکانسی می‌خزد، چه درصدی از بودجه صرف آدرس‌های بی‌ارزش می‌شود، گوگل‌بات چه کد وضعیتی دریافت می‌کند (که می‌تواند با آنچه شما در مرورگر می‌بینید متفاوت باشد)، و کدام صفحات ماه‌هاست خزیده نشده‌اند.

چند دستور کاربردی برای تحلیل سریع:

grep "Googlebot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50
grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

یک هشدار مهم: بسیاری از رکوردهایی که در User-Agent خود Googlebot دارند جعلی‌اند. برای تأیید هویت واقعی، جستجوی معکوس DNS انجام دهید؛ نتیجه باید به دامنهٔ googlebot.com ختم شود و جستجوی مستقیم روی آن نام، همان IP اولیه را برگرداند. گوگل همچنین محدودهٔ IPهای رسمی خزنده‌هایش را به‌صورت عمومی منتشر می‌کند.

لینک‌سازی داخلی: موتور واقعی ایندکس

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

اصول عملی که باید رعایت کنید:

• عمق کلیک را کم کنید. هر صفحهٔ مهم باید حداکثر با سه تا چهار کلیک از صفحهٔ اصلی قابل دسترسی باشد. صفحاتی که در عمق هفت و هشت هستند، در عمل ایندکس نمی‌شوند.
• صفحات یتیم را از بین ببرید. فهرست سایت‌مپ را با فهرست خزش داخلی مقایسه کنید و تفاوت را برطرف کنید.
• لینک‌های واقعی بسازید. فقط تگ <a href> واقعی. دکمهٔ جاوااسکریپتی و رویداد کلیک روی یک span، از دید گوگل لینک نیستند.
• انکرتکست توصیفی بنویسید. عبارت «اینجا کلیک کنید» به گوگل هیچ اطلاعاتی نمی‌دهد.
• ساختار ناوبری منطقی بسازید. مسیر باید از صفحهٔ اصلی به دسته‌بندی‌ها و از آنجا به صفحات زیرمجموعه برسد. مثلاً: صفحهٔ اصلی، سپس خدمات طراحی وب، سپس طراحی وردپرس. این مسیر هم برای کاربر و هم برای گوگل معنا دارد.
• ساختار خوشه‌ای بسازید. یک صفحهٔ محوری که به صفحات تخصصی لینک می‌دهد و آن‌ها متقابلاً به آن و به هم لینک می‌دهند. این ساختار هم ایندکس و هم درک موضوعی گوگل از سایت شما را تقویت می‌کند و یکی از پایه‌های سئوی داخلی موفق است.
• صفحه‌بندی را درست پیاده کنید. لینک به صفحات دوم و سوم باید <a href> واقعی باشد. اسکرول بی‌نهایت بدون لینک‌های واقعی، همهٔ محتوای بعد از صفحهٔ اول را غیرقابل کشف می‌کند.
• از صفحات پرقدرت به صفحات جدید لینک بدهید. یک باکس «تازه‌ترین‌ها» در صفحهٔ اصلی، یکی از ساده‌ترین و مؤثرترین شتاب‌دهنده‌های ایندکس است.
• لینک‌سازی داخلی خودکار را محدود کنید. افزونه‌هایی که خودکار کلمات را به لینک تبدیل می‌کنند معمولاً ارتباط معنایی درستی نمی‌سازند. لینک‌سازی دستی در مقالات مرتبط، هم به درک بهتر گوگل کمک می‌کند و هم احتمال کلیک واقعی کاربر را بالا می‌برد.

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

ایندکس سایت‌های جاوااسکریپتی و SPA

گوگل جاوااسکریپت را اجرا می‌کند، اما این به معنای بی‌خطر بودن اتکای کامل به آن نیست. انتخاب استراتژی رندر یکی از تصمیم‌های تعیین‌کننده برای سرنوشت ایندکس سایت شماست:

توصیهٔ عملی ساده است: اگر صفحه‌ای باید در گوگل رتبه بگیرد، محتوای اصلی‌اش باید در HTML اولیه باشد.

چک‌لیست فنی که پیش از انتشار هر پروژهٔ جاوااسکریپتی باید بررسی شود:

• محتوای اصلی در HTML اولیه موجود باشد
• ناوبری با <a href> واقعی پیاده شده باشد، نه با رویداد کلیک
• مسیریابی با History API انجام شود، نه با قطعهٔ هش در آدرس
• سرور برای مسیرهای نامعتبر کد وضعیت صحیح برگرداند، نه ۲۰۰ برای صفحهٔ خطا
• هیچ منبع لازم برای رندر در robots.txt بسته نباشد
• عنوان، توضیحات و کنونیکال برای هر مسیر یکتا باشد
• دادهٔ ساختاریافته در HTML اولیه یا تزریق‌شده پیش از پایان رندر باشد
• بارگذاری تنبل تصاویر به اسکرول کاربر وابسته نباشد
• هیچ وابستگی به حافظهٔ محلی مرورگر، کوکی یا مجوز کاربر وجود نداشته باشد

برای تست سریع اینکه محتوای شما در HTML اولیه هست یا نه:

curl -s -A "Googlebot" https://example.com/page | grep -c "بخشی از متن اصلی صفحه"

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

ایندکس در سایت‌های فروشگاهی و چالش صفحات بی‌نهایت

فروشگاه‌ها بیشترین مشکلات ایندکس را دارند، چون معماری‌شان به‌طور طبیعی آدرس تولید می‌کند.

فیلترها و فست‌نویگیشن: تولید بی‌نهایت آدرس

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

1. تصمیم بگیرید کدام ترکیب‌ها ارزش ایندکس دارند. معمولاً فقط ترکیب‌های تک‌فیلتری با تقاضای جستجوی واقعی — مثلاً «کفش ورزشی مردانه» — ارزش دارند. این‌ها را به صفحات مستقل با محتوای اختصاصی تبدیل کنید.
2. بقیه را در robots.txt ببندید با الگوهایی مثل بستن پارامترهای رنگ، سایز و مرتب‌سازی.
3. لینک‌های فیلتر را nofollow کنید یا طوری پیاده کنید که آدرس جدید تولید نکنند.
4. کنونیکال ترکیب‌های چندفیلتری را به صفحهٔ دسته‌بندی پایه بدهید.

صفحه‌بندی

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

مدیریت محصولات ناموجود و حذف‌شده

هرگز صدها محصول حذف‌شده را به صفحهٔ اصلی یا دسته‌بندی ریدایرکت نکنید؛ گوگل این را soft 404 تلقی می‌کند و هیچ ارزشی منتقل نمی‌شود.

محتوای تکراری صفحات محصول

اگر توضیحات محصول همان چیزی است که کارخانه به صد فروشگاه دیگر هم داده، دلیلی برای ایندکس شدن صفحهٔ شما وجود ندارد. فرض کنید سه هزار محصول به فروشگاه اضافه می‌کنید — به هیچ عنوان از یک متن یکسان برای همه استفاده نکنید. متن هر محصول را بر اساس مشخصات خودش بنویسید.

برای تسریع این کار می‌توانید از ابزارهای هوش مصنوعی مثل ChatGPT، Copilot یا Gemini به‌عنوان نقطهٔ شروع استفاده کنید و سپس خروجی را با اطلاعات واقعی محصول، تجربهٔ فروش و نکات اختصاصی خودتان بهینه کنید. اما دو نکته را در نظر داشته باشید: اول اینکه گوگل با محتوای هوش مصنوعی مشکل ذاتی ندارد، با محتوای بی‌ارزش مشکل دارد — پس صرفاً یکتا بودن متن کافی نیست و باید ارزش افزودهٔ واقعی داشته باشد. دوم اینکه بهترین تمایز، چیزی است که اصلاً قابل تولید خودکار نیست: تصویر اختصاصی، نظرات واقعی کاربران، جدول مقایسه، و ویدئوی معرفی. برای آشنایی با ابزارهای هوش مصنوعی تصویری می‌توانید به مقالهٔ سایت هوش مصنوعی عکس چهره مراجعه کنید.

مهاجرت سایت بدون از دست دادن ایندکس

مهاجرت — چه تغییر دامنه، چه تغییر ساختار آدرس، چه تغییر پلتفرم — پرخطرترین عملیات سئو است.

پیش از مهاجرت

1. فهرست کامل آدرس‌های فعلی را از چند منبع جمع کنید، چون هیچ منبعی کامل نیست: خزش کامل سایت، همهٔ آدرس‌های دارای نمایش در شانزده ماه گذشته از سرچ کنسول، همهٔ صفحات دارای بازدید از آنالیتیکس، صفحات دارای بک‌لینک از ابزارهای تحلیل لینک، و سایت‌مپ فعلی.
2. نگاشت یک‌به‌یک بسازید. هر آدرس قدیمی باید مقصدی داشته باشد که معادل محتوایی آن است.
3. وضعیت پایه را ثبت کنید: تعداد صفحات ایندکس‌شده، ترافیک ارگانیک، رتبه‌های کلیدی و سرعت خزش.
4. در استیجینگ کامل تست کنید با noindex یا محافظت با رمز — و یادداشتی بگذارید که فراموش نکنید در زمان انتشار برداریدشان.

حین و پس از مهاجرت

• ریدایرکت‌های ۳۰۱ در یک پرش، نه زنجیره
• سایت‌مپ جدید ارسال شود و سایت‌مپ قدیمی موقتاً نگه داشته شود تا گوگل ریدایرکت‌ها را کشف کند
• در صورت تغییر دامنه، ابزار Change of Address سرچ کنسول استفاده شود
• هر دو پراپرتی قدیم و جدید در سرچ کنسول فعال بمانند
• robots.txt و noindex محیط استیجینگ برداشته شده باشد — این را دو بار چک کنید
• منابع داخلی مثل تصاویر و فایل‌های CSS به مسیر جدید اشاره کنند
• ریدایرکت‌ها را حداقل یک سال نگه دارید

در ماه اول پس از مهاجرت، افت ده تا بیست درصدی موقت طبیعی است و نباید باعث تصمیم‌های عجولانه شود.

مسائل خاص سایت‌های ایرانی در ایندکس گوگل

این بخش را در راهنماهای خارجی پیدا نمی‌کنید، اما در عمل بخش قابل‌توجهی از مشکلات ایندکس سایت‌های ایرانی از این موارد ناشی می‌شود.

بلاک شدن گوگل‌بات در سطح هاست یا فایروال

بسیاری از هاست‌های داخلی یا پیکربندی‌های امنیتی، ترافیک IPهای خارجی را محدود می‌کنند. نتیجه این است که گوگل‌بات کد ۴۰۳ یا تایم‌اوت می‌گیرد، در حالی که سایت برای کاربر ایرانی کاملاً سالم است. این یکی از رایج‌ترین علل ایندکس‌زدایی تدریجی در سایت‌های ایرانی است و چون از داخل ایران قابل مشاهده نیست، معمولاً ماه‌ها تشخیص داده نمی‌شود.

برای تست، این دستور را اجرا کنید و مهم‌تر از آن، همین تست را از یک سرور خارج از ایران هم تکرار کنید. تفاوت نتیجه، مشکل را آشکار می‌کند:

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/ -w "\nHTTP: %{http_code} | Time: %{time_total}s\n" -o /dev/null

راه‌حل: محدودهٔ IPهای رسمی گوگل‌بات را در فایروال، افزونهٔ امنیتی و CDN به فهرست سفید اضافه کنید.

تنظیمات تهاجمی Cloudflare

حالت Under Attack و Bot Fight Mode گوگل‌بات را با چالش جاوااسکریپتی مواجه می‌کنند که خزنده از آن عبور نمی‌کند. نتیجه، ایندکس‌زدایی تدریجی و گسترده است. راه‌حل: حالت Under Attack را خاموش کنید، Bot Fight Mode را غیرفعال کنید یا برای ربات‌های تأییدشده استثنا بگذارید، و در قوانین فایروال یک قانون صریح برای اجازه دادن به ربات‌های تأییدشده تعریف کنید.

کندی سرور برای درخواست‌های بین‌المللی

سروری که برای کاربر داخلی در دویست میلی‌ثانیه پاسخ می‌دهد، ممکن است برای درخواست از دیتاسنتر گوگل دو ثانیه طول بکشد. این مستقیماً سقف ظرفیت خزش را پایین می‌آورد. راه‌حل: استفاده از CDN با نقاط حضور بین‌المللی، یا میزبانی در دیتاسنتری با مسیریابی بهتر.

محتوای فارسی و مسائل زبانی

• تگ <html lang="fa" dir="rtl"> را درست تنظیم کنید.
• از نویسه‌های صحیح فارسی استفاده کنید: «ی» فارسی نه «ي» عربی، و «ک» فارسی نه «ك» عربی. ناسازگاری نویسه‌ها روی تطبیق کوئری با محتوای شما اثر می‌گذارد و می‌تواند باعث شود صفحه برای کلمهٔ کلیدی هدفتان اصلاً مرتبط تشخیص داده نشود.
• نیم‌فاصله را یکدست به کار ببرید.
• اعداد فارسی و انگلیسی را در آدرس و محتوا یکدست کنید.

آدرس‌های فارسی

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

دسترسی به ابزارها

برخی ابزارهای گوگل از IP ایران در دسترس نیستند و برای کار پایدار با سرچ کنسول به اتصال بدون قطعی نیاز دارید. اما نکتهٔ مهم‌تر این است: مطمئن شوید تنظیماتی که برای مدیریت این محدودیت‌ها روی سرور گذاشته‌اید — پروکسی معکوس، فیلتر IP، قوانین مسیریابی — خودشان گوگل‌بات را مسدود نمی‌کنند. در پروژه‌های زیادی دیده‌ایم که راه‌حل یک مشکل، خودش تبدیل به علت مشکل بعدی شده است.

روش‌های تسریع ایندکس صفحات جدید

حالا که علل ایندکس نشدن را می‌شناسید، به سراغ روش‌های تسریع می‌رویم. این روش‌ها را به ترتیب اثربخشی مرتب کرده‌ایم.

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

۲. سایت‌مپ با lastmod دقیق. گوگل سایت‌مپ سایت‌های فعال را مکرر بررسی می‌کند. اما همان‌طور که گفتیم، اعتبار lastmod شما سرمایه‌ای است که با دستکاری از دست می‌رود.

۳. درخواست ایندکس از URL Inspection. برای تک‌صفحات مهم مناسب است. وارد سرچ کنسول شوید، به بخش URL Inspection بروید، آدرس صفحهٔ جدید را وارد کنید و روی Request Indexing کلیک کنید. این روش محدودیت روزانه دارد و برای حجم بالا کاربردی نیست. نکتهٔ مهم: تکرار درخواست برای یک آدرس هیچ اثر افزایشی ندارد و صرفاً سهمیهٔ روزانهٔ شما را مصرف می‌کند.

۴. انتشار محتوای باکیفیت و منحصربه‌فرد. محتوای ارزشمند نه‌تنها شانس ایندکس شدن خودش را بالا می‌برد، بلکه ارزیابی گوگل از کیفیت کل سایت را بهبود می‌دهد و روی ایندکس شدن بقیهٔ صفحات هم اثر مثبت می‌گذارد. این نکته‌ای است که اغلب نادیده گرفته می‌شود: کیفیت یک سرمایهٔ مشترک در کل دامنه است.

۵. بهبود سرعت پاسخ سرور. مستقیم‌ترین اهرم روی ظرفیت خزش. سایت‌هایی که سریع پاسخ می‌دهند، بیشتر و عمیق‌تر خزیده می‌شوند.

۶. اشتراک‌گذاری در شبکه‌های اجتماعی. لینک‌های شبکه‌های اجتماعی معمولاً nofollow هستند، اما ترافیک واقعی و مسیرهای کشف جانبی می‌سازند. اشتراک‌گذاری محتوا در شبکه‌های اجتماعی، ارسال به خبرنامه و انتشار در پلتفرم‌های ویدیویی، همگی سیگنال‌هایی هستند که به کشف سریع‌تر کمک می‌کنند.

۷. راه‌اندازی و به‌روزرسانی وبلاگ. محتوای وبلاگ معمولاً سریع‌تر و راحت‌تر از صفحات ایستا ایندکس می‌شود، چون به‌طور طبیعی تازه است و مرتب به‌روز می‌شود. سایت‌هایی که وبلاگ فعال دارند، تعداد صفحات ایندکس‌شده و لینک‌های ورودی به‌مراتب بیشتری دارند.

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

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

۹. معرفی سایت به موتورهای جستجو. برای معرفی سایت جدید، وارد سرچ کنسول شوید و سایت را ثبت و تأیید کنید؛ برای بینگ هم فرآیند مشابهی وجود دارد. اما دربارهٔ سرویس‌هایی که وعدهٔ «ارسال همزمان به صدها موتور جستجو» می‌دهند، هشدار جدی می‌دهیم: این سرویس‌ها ارزش عملی ندارند و برخی از آن‌ها با ساخت لینک‌های بی‌کیفیت می‌توانند به سایت شما آسیب برسانند.

۱۰. اشتراک‌گذاری در انجمن‌ها و پلتفرم‌های تجمیع‌کننده. پلتفرم‌هایی مثل Reddit و Medium در سطح جهانی، و انجمن‌های تخصصی داخلی، می‌توانند مسیر کشف و ترافیک ورودی بسازند. محتوای مناسب برای این پلتفرم‌ها معمولاً متفاوت است: ویدئو، اینفوگرافیک، راهنماهای گام‌به‌گام و فهرست‌های کاربردی بهتر جواب می‌دهند.

۱۱. معرفی به دایرکتوری‌های معتبر. ثبت در دایرکتوری‌ها می‌تواند به کشف سریع‌تر کمک کند، اما فقط اگر دایرکتوری معتبر باشد. توجه داشته باشید که گوگل از سال ۲۰۱۲ بسیاری از دایرکتوری‌های بی‌کیفیت را از نتایج حذف کرد و لینک گرفتن از آن‌ها امروز بیشتر ریسک است تا فرصت.

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

Indexing API گوگل: واقعیت در برابر تبلیغات

اینجا باید صریح باشیم، چون بازار پر از ادعاهای نادرست است. Indexing API گوگل رسماً فقط برای دو نوع محتوا کار می‌کند: صفحاتی با دادهٔ ساختاریافتهٔ JobPosting یعنی آگهی شغلی، و BroadcastEvent تعبیه‌شده در VideoObject یعنی پخش زنده. سهمیهٔ پیش‌فرض برای راه‌اندازی و آزمایش دویست درخواست است و بیشتر از آن نیاز به تأیید دارد.

استفاده از این API برای صفحات معمولی خلاف مستندات رسمی گوگل است. ابزارهایی که «ایندکس فوری با API گوگل» می‌فروشند، یا از این API سوءاستفاده می‌کنند — که ممکن است به قطع دسترسی شما منجر شود — یا صرفاً همان درخواست ایندکس معمولی را می‌فرستند و چیز خاصی به شما نمی‌دهند.

IndexNow: مفید، اما نه برای گوگل

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

پس ارزشش چیست؟ اگر بخشی از ترافیک شما از بینگ می‌آید، یا برایتان مهم است که در دستیارهای هوش مصنوعی که به ایندکس بینگ متکی‌اند دیده شوید، پیاده‌سازی IndexNow ارزان و ارزشمند است. اما انتظار اثر روی گوگل نداشته باشید.

روش‌هایی که برای تسریع ایندکس کار نمی‌کنند:

• سرویس‌های «ایندکس فوری» که بک‌لینک اسپم می‌سازند
• پینگ کردن مکرر سایت‌مپ
• درخواست ایندکس روزانهٔ یک آدرس ثابت
• افزودن کلمهٔ کلیدی به صفحه‌ای که در وضعیت Discovered گیر کرده است
• استفادهٔ افراطی از کلمات کلیدی در متا تگ‌ها — متا تگ keywords سال‌هاست از سوی گوگل منسوخ شده و هیچ نقشی در رتبه‌بندی ندارد

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

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

یکی از مؤثرترین راه‌های افزایش نرخ خزش و ایندکس، به‌روزرسانی محتوای قدیمی است. گوگل مشتاق است تغییرات را در کمترین زمان دریافت کند، بنابراین وقتی محتوای قدیمی را به‌روز می‌کنید، خزنده‌ها دوباره به سراغش می‌آیند.

در دنیای امروز اطلاعات و آمارها به‌سرعت منقضی می‌شوند. راه‌های عملی برای به‌روزرسانی:

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

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

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

پایش ماهانهٔ ایندکس و رفع خطاهای خزش

دو ابزار رایگان گوگل، ستون فقرات پایش ایندکس شما هستند و باید هر دو روی سایت فعال باشند.

Google Analytics رفتار کاربران را بررسی می‌کند: تعداد بازدیدکننده، مدت حضور در سایت، صفحاتی که می‌بینند، و مسیری که از آن آمده‌اند.

Google Search Console سایت را از دید موتور جستجو بررسی می‌کند: خطاهای خزش، وضعیت ایندکس، مسائل امنیتی، عملکرد در نتایج جستجو و دادهٔ ساختاریافته.

بررسی تعداد صفحات ایندکس‌شده سایت و رقبا

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

دو رویکرد وجود دارد:

• بدون دسترسی به سرچ کنسول: با دستور site: می‌توانید تخمینی از تعداد صفحات ایندکس‌شده به دست آورید. این روش برای بررسی رقبا تنها گزینهٔ شماست، اما به یاد داشته باشید که عدد نمایش‌داده‌شده تخمینی و اغلب نادقیق است.
• با دسترسی به سرچ کنسول: گزارش Page Indexing عدد دقیق و تفکیک‌شده را به شما می‌دهد. توجه کنید که گزارش قدیمی Index Status سال‌هاست حذف شده و جایگزینش همین گزارش Page Indexing است.

بررسی و رفع ماهانهٔ خطاهای خزش

بهتر است ماهی یک‌بار تمام خطاهای سایت را بررسی و برطرف کنید، چون سلامت این بخش مستقیماً روی تکرار خزش اثر می‌گذارد. مواردی که باید ماهانه بررسی شوند:

• خطاهای خزش و کدهای وضعیت غیرعادی
• آمار خزش گوگل‌بات در بخش Crawl Stats
• صفحات مهمی که ایندکس نشده‌اند و نیاز به بررسی دستی دارند
• وضعیت دادهٔ ساختاریافته در بخش Enhancements

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

برای آشنایی بیشتر با ابزارهای تحلیل و پایش سایت، مطالب زیر را ببینید:

شاید این مطالب هم برای شما جالب باشد:

شاخص‌های کلیدی سلامت ایندکس

عدد «تعداد صفحات ایندکس‌شده» به‌تنهایی گمراه‌کننده است. این شاخص‌ها را رصد کنید:

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

پایش خودکار

یک اسکریپت روزانه بنویسید که فایل robots.txt را دانلود و با نسخهٔ مورد انتظار مقایسه کند، نمونه‌ای از صفحات کلیدی را با User-Agent گوگل‌بات درخواست بزند و کد وضعیت و وجود noindex را بررسی کند، انقضای گواهی SSL و دامنه را چک کند، و از API سرچ کنسول تعداد صفحات ایندکس‌شده را بگیرد و افت بیش از آستانه را هشدار بدهد.

این چند ده خط کد، فاصلهٔ بین «فهمیدن بعد از سه روز» و «فهمیدن بعد از سه ماه» است — و در حادثهٔ ایندکس، این فاصله معادل ماه‌ها ترافیک از دست رفته است.

چک‌لیست‌های اجرایی ایندکس

چک‌لیست راه‌اندازی سایت جدید

• فایل robots.txt بررسی شده و Disallow: / ندارد
• تیک «جلوگیری از نمایه‌سازی» در تنظیمات وردپرس برداشته شده
• هیچ noindex سراسری در قالب یا هدر سرور وجود ندارد
• سرچ کنسول با پراپرتی Domain تأیید شده است
• سایت‌مپ ساخته، تفکیک‌شده و ارسال شده است
• آدرس سایت‌مپ در robots.txt اعلام شده است
• کنونیکال خودارجاع روی همهٔ صفحات وجود دارد
• یک نسخهٔ واحد از دامنه انتخاب شده و بقیه ریدایرکت می‌شوند
• گواهی SSL معتبر است و هشدار انقضا تنظیم شده
• صفحهٔ ۴۰۴ سفارشی واقعاً کد ۴۰۴ برمی‌گرداند
• با User-Agent گوگل‌بات تست شده و کد ۲۰۰ می‌دهد
• محتوای اصلی در HTML اولیه موجود است
• ناوبری با لینک واقعی پیاده شده است
• عمق کلیک صفحات مهم زیر چهار است
• IPهای گوگل‌بات در فایروال و CDN در فهرست سفید هستند

چک‌لیست پیش از انتشار هر صفحهٔ جدید

• آدرس کوتاه، خوانا و پایدار است
• کنونیکال خودارجاع دارد
• هیچ noindex ندارد
• عنوان و توضیحات یکتا دارد
• حداقل دو لینک داخلی ورودی از صفحات مرتبط دارد
• در سایت‌مپ با تاریخ صحیح ثبت شده است
• محتوا واقعاً چیزی دارد که در نتایج موجود نیست
• با محتوای موجود سایت خودتان هم‌پوشانی زیاد ندارد
• هدف جستجوی کاربر با نوع صفحه هم‌خوانی دارد
• دادهٔ ساختاریافتهٔ مرتبط دارد
• در HTML اولیه قابل مشاهده است

چک‌لیست ممیزی ماهانهٔ ایندکس

• روند صفحات ایندکس‌شده در گزارش Page Indexing
• نرخ ایندکس به تفکیک هر سایت‌مپ
• بررسی رشد غیرعادی در دسته‌های «ایندکس نشده»
• آمار Crawl Stats: زمان پاسخ، تعداد درخواست و توزیع کدها
• تعداد آدرس‌های یکتای دارای نمایش، نه فقط تعداد ایندکس‌شده
• خالی بودن گزارش‌های Manual Actions و Security Issues
• لینک‌های داخلی شکسته
• صفحات یتیم
• صفحات با ترافیک صفر در دوازده ماه به‌عنوان کاندید ادغام یا حذف
• خزش کامل سایت و مقایسه با ماه قبل

چک‌لیست تشخیص فوری ایندکس‌زدایی انبوه

• فایل robots.txt
• متا تگ noindex
• هدر X-Robots-Tag
• کد وضعیت با User-Agent گوگل‌بات
• درصد خطای 5xx و ۴۰۳ در Crawl Stats
• ابزار Removals
• گزارش‌های Manual Actions و Security Issues
• وضعیت گواهی SSL و DNS
• تنظیمات فایروال و CDN
• نمونه‌گیری از کنونیکال‌ها
• بررسی HTML رندرشده
• مقایسهٔ نمودار ترافیک با نمودار ایندکس

باورهای غلط رایج دربارهٔ ایندکس

«اگر در سایت‌مپ بگذارم حتماً ایندکس می‌شود.» سایت‌مپ فقط کمک به کشف است. گوگل صریحاً می‌گوید ارسال سایت‌مپ یک راهنمایی است و خزش یا ایندکس را تضمین نمی‌کند.

«با robots.txt جلوی ایندکس شدن را می‌گیرم.» robots.txt جلوی خزش را می‌گیرد، نه ایندکس. صفحهٔ بلاک‌شده می‌تواند از طریق لینک‌های ورودی ایندکس شود.

«هر روز درخواست ایندکس بزنم زودتر ایندکس می‌شود.» درخواست‌های تکراری برای یک آدرس هیچ اولویت اضافه‌ای ایجاد نمی‌کنند.

«ایندکس شدن یعنی رتبه گرفتن.» ایندکس شرط لازم است. صدها میلیون صفحهٔ ایندکس‌شده هرگز یک بازدید نمی‌گیرند.

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

«بودجهٔ خزش برای همه مهم است.» برای سایت‌های زیر ده هزار آدرس، تقریباً هرگز گلوگاه نیست.

«محتوای تکراری جریمه دارد.» جریمه‌ای وجود ندارد. گوگل فقط یکی از نسخه‌ها را انتخاب می‌کند و بقیه را نمایش نمی‌دهد.

«با Indexing API گوگل هر صفحه‌ای را فوری ایندکس می‌کنم.» این API رسماً فقط برای آگهی شغلی و پخش زنده است.

«IndexNow به ایندکس گوگل کمک می‌کند.» گوگل از IndexNow پشتیبانی نمی‌کند. بینگ و چند موتور دیگر می‌کنند.

«محتوای هوش مصنوعی ایندکس نمی‌شود.» گوگل با روش تولید کاری ندارد؛ با بی‌ارزش بودن محتوا کار دارد. محتوای هوش مصنوعی که ارزش افزودهٔ واقعی دارد ایندکس می‌شود و محتوای انسانی بی‌ارزش نمی‌شود.

«افت تعداد صفحات ایندکس‌شده همیشه بد است.» اگر صفحات حذف‌شده هیچ ترافیکی نداشته‌اند و ترافیک کل تغییر نکرده، این یک پاک‌سازی سالم است.

«دستور crawl-delay سرعت خزش گوگل را کنترل می‌کند.» گوگل این دستور را نادیده می‌گیرد.

«مقادیر priority و changefreq در سایت‌مپ اثر دارند.» گوگل نادیده می‌گیرد. فقط lastmod اهمیت دارد، آن هم فقط اگر ثابت کنید قابل اعتماد است.

نتیجه‌گیری

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

سه اصلی که اگر از این مقاله فقط سه چیز به یاد بماند، بهتر است همین‌ها باشد:

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

دوم، کیفیت یک سرمایهٔ مشترک در کل دامنه است. صفحات بی‌ارزش شما فقط خودشان ایندکس نمی‌شوند؛ شانس ایندکس شدن صفحات خوبتان را هم کاهش می‌دهند. بنابراین حذف و ادغام محتوای بی‌مصرف، درست به اندازهٔ تولید محتوای جدید ارزش دارد — و اغلب بیشتر.

سوم، پایش را خودکار کنید. تفاوت بین یک حادثهٔ کوچک و یک فاجعه، معمولاً تفاوت بین سه روز و سه ماه است. یک اسکریپت ساده که robots.txt، وضعیت noindex، کد پاسخ برای گوگل‌بات و انقضای گواهی را روزانه چک کند، ارزان‌ترین بیمه‌ای است که می‌توانید برای سایتتان بخرید.

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

در صورتی که سایت شما به‌درستی در دسترس نباشد، حتی بهترین محتوا هم شانس دیده شدن ندارد—به همین دلیل استفاده از GEO DNS نقش مهمی در بهبود فرآیند ایندکس شدن در گوگل دارد.