- اشتراک
وقتی یک صفحه در گوگل دیده نمیشود، بسیاری از افراد سریع سراغ تولید محتوای بیشتر، خرید بکلینک یا ثبت چندباره درخواست ایندکس میروند. اما مشکل ممکن است خیلی قبلتر از رتبهبندی اتفاق افتاده باشد؛ شاید گوگل هنوز URL را پیدا نکرده، اجازه خزیدن در آن را ندارد، محتوای صفحه را بهدرستی Render نمیکند یا پس از بررسی، تصمیم گرفته است صفحه را وارد ایندکس نکند.
برای همین، تحلیل سرچ کنسول باید مرحلهبهمرحله انجام شود. مسیر حضور یک صفحه در گوگل معمولاً اینطور است:
در این مقاله همین مسیر را با زبان عملی بررسی میکنیم: Crawlability، Indexability، robots.txt، Sitemap، Canonical، Rendering و Core Web Vitals. در پایان هم یک چکلیست دارید که میتوانید برای بررسی ایندکسنشدن صفحات استفاده کنید.
گوگل چگونه یک صفحه را پیدا و پردازش میکند؟
گوگل ابتدا باید URL را کشف کند. بعد Googlebot تلاش میکند صفحه را Crawl کند؛ یعنی درخواست بفرستد و پاسخ سرور را دریافت کند. سپس در بسیاری از صفحات، مخصوصاً سایتهای JavaScript محور، گوگل صفحه را Render میکند تا نسخه نهایی محتوا را ببیند. بعد از آن، در مرحله Indexing، تصمیم میگیرد اطلاعات صفحه را در ایندکس خود نگه دارد یا نه. تازه بعد از این مراحل، موضوع رتبهگرفتن صفحه مطرح میشود.
پس اگر صفحهای رتبه ندارد، لزوماً مشکل آن «ضعف محتوا» نیست. ممکن است اصلاً وارد ایندکس نشده باشد. اگر وارد ایندکس نشده، ممکن است مشکل از Crawl باشد. اگر Crawl شده اما Index نشده، احتمالاً باید سراغ کیفیت محتوا، Canonical، Render، Duplicate Content یا Soft 404 بروید.
یک جمله ساده برای بهخاطر سپردن این مسیر:
Discovery یا کشف URL چیست؟
پیش از Crawl، گوگل باید بفهمد این URL وجود دارد. کشف URL معمولاً از روشهای زیر اتفاق میافتد:
- لینکهای داخلی سایت
- Sitemap XML
- لینک از سایتهای دیگر
- URLهایی که گوگل قبلاً شناخته است
- ریدایرکت از یک URL قدیمی
- درخواست ایندکس از طریق URL Inspection
لینکهای داخلی فقط برای انتقال اعتبار یا کمک به رتبهبندی نیستند. گوگل از لینکها برای پیدا کردن صفحات جدید نیز استفاده میکند. به همین دلیل، صفحات مهم سایت باید از طریق لینکهای HTML عادی و قابلخزش در دسترس باشند.
صفحهای که هیچ لینک داخلی معناداری به آن وجود ندارد، اصطلاحاً صفحه یتیم یا Orphan Page نامیده میشود. چنین صفحهای ممکن است داخل Sitemap باشد، اما جایگاه آن در معماری سایت برای گوگل روشن نیست.
آیا قراردادن URL در Sitemap برای ایندکسشدن کافی است؟
خیر. Sitemap فقط یک سیگنال یا پیشنهاد برای گوگل است، نه دستور قطعی. در واقع ارسال Sitemap تضمین نمیکند که:
- گوگل همه URLها را Crawl کند؛
- همه صفحات وارد ایندکس شوند؛
- صفحات ایندکسشده رتبه بگیرند.
Crawl چیست؟
Crawl یا خزش یعنی Googlebot یک URL را درخواست کند و پاسخ آن را از سرور دریافت کند.
برای مثال، وقتی Googlebot وارد این URL میشود:
https://example.com/technical-seo
- 200: صفحه با موفقیت در دسترس است.
- 301 یا 308: صفحه به URL دیگری منتقل شده است.
- 404 یا 410: صفحه وجود ندارد یا حذف شده است.
- 403: دسترسی Googlebot ممنوع شده است.
- 5xx: سرور نتوانسته پاسخ سالمی ارائه کند.
Crawlability چیست؟
- دستورات robots.txt
- لینکهای داخلی
- کد وضعیت HTTP
- دسترسی Googlebot
- عملکرد سرور
- ریدایرکتها
- ساختار URL
- دسترسی به فایلهای JavaScript و CSS ضروری
- آیا گوگل URL را پیدا کرده است؟
- آیا robots.txt اجازه Crawl میدهد؟
- آیا URL پاسخ 200 میدهد؟
- آیا سرور برای Googlebot خطای 403 یا 5xx ایجاد نمیکند؟
- آیا URL درگیر حلقه یا زنجیره ریدایرکت نیست؟
- آیا لینک قابلخزشی به صفحه وجود دارد؟
تا اینجا با مفهوم Crawl یک URL توسط googlebot آشنا شدید. در ادامه به بررسی مفهوم Index یک url میپردازیم.
Index چیست؟
Index یا ایندکس، درواقع یک پایگاه داده یا دیتابیسی است که گوگل اطلاعات صفحات وب را در آن پردازش کرده و نگهداری میکند.
وقتی یک صفحه ایندکس میشود، به این معنا نیست که حتماً در صفحه اول گوگل نمایش داده خواهد شد. تنها به این معناست که گوگل صفحه را شناخته و امکان استفاده از آن را در نتایج جستوجو دارد.
- ممکن است صفحهای Crawl شود: اما Index نشود؛
- ممکن است صفحه ای Index شود؛ اما برای کلمات مهم رتبه نگیرد؛
- ممکن است صفحه ای Index شود: اما نسخه دیگری بهعنوان Canonical انتخاب شود؛
- ممکن است صفحه ای مدتی ایندکس باشد؛ اما بعد از ایندکس خارج شود.
این مراحل را نباید با یکدیگر اشتباه گرفت!
Indexability چیست؟
وقتی به این سوال فکر میکنیم که «آیا یک صفحه پس از Crawl شدن، از نظر فنی و محتوایی امکان ورود به ایندکس گوگل را دارد؟» به این معنی است که در خصوص Indexability دچار شک شده ایم… در این خصوص باید بدانیم که چه موارد میتوانند مانع Indexability شوند:
- وجود noindex
- ارسال X-Robots-Tag: noindex
- Canonical به URL دیگر
- محتوای تکراری
- انتخاب نسخه دیگری بهعنوان Canonical توسط گوگل
- Soft 404
- محتوای بسیار ضعیف یا فاقد ارزش مستقل
- صفحه خطا با پاسخ ظاهراً سالم
- نیاز به ورود، رمز عبور یا دسترسی خصوصی
- محتوای اصلی غیرقابلمشاهده پس از Render
گاهی هم نیاز هست از ایندکس شدن یک صفحه جلوگیری کنید؛ مثلا نیاز نیست صفحه login یک وبسایت توسط گوگل index شود. در این صورت از تگ Meta Robots در header صفحه استفاده کنید:
برای جلوگیری از ایندکس صفحه میتوان از Meta Robots استفاده کرد:
<meta name="robots" content="noindex, follow">
تفاوت Crawlability و Indexability چیست؟
این دو مفهوم از مهمترین مباحث سئو تکنیکال هستند؛ به همین دلیل باز هم به بررسی این دو میپردازیم…
Crawlability پاسخ این سؤال است:
- آیا گوگل میتواند وارد صفحه شود؟
Indexability پاسخ این سؤال است:
- آیا گوگل بعد از ورود، اجازه و شرایط لازم برای ذخیره صفحه را دارد؟
<meta name="robots" content="noindex">
User-agent: *
Disallow: /private/
خلاصه تفاوت Crawl و Index
| مفهوم | سؤال اصلی | نمونه مانع |
|---|---|---|
| Discovery | آیا گوگل URL را میشناسد؟ | نبود لینک داخلی و Sitemap |
| Crawlability | آیا گوگل میتواند URL را دریافت کند؟ | robots.txt، خطای سرور یا 403 |
| Renderability | آیا محتوای نهایی قابلمشاهده است؟ | خطای JavaScript یا API |
| Indexability | آیا صفحه اجازه و شرایط ورود به ایندکس را دارد؟ | noindex، canonical یا محتوای تکراری |
| Ranking | آیا صفحه برای جستوجوی موردنظر مناسب است؟ | ضعف محتوا، ارتباط یا اعتبار |
robots.txt چیست و چه کاری انجام میدهد؟
این فایل به خزندهها اعلام میکند کدام مسیرها را میتوانند درخواست کنند و کدام مسیرها برای Crawl محدود شدهاند.
نمونه رایج در وردپرس:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml
robots.txt برای مدیریت دسترسی خزندهها مفید است، اما روش مطمئنی برای حذف URL از نتایج گوگل نیست. اگر URL از طریق لینکهای دیگر شناخته شده باشد، ممکن است بدون Crawl کامل محتوا همچنان در نتایج دیده شود.
برای خارجکردن یک صفحه از ایندکس، بسته به شرایط، معمولاً باید یکی از این روشها بررسی شود:
- noindex
- حذف صفحه با پاسخ مناسب مثل 404 یا 410
- محافظت با رمز عبور
- استفاده از ابزار Removals برای حذف موقت و سریع
- Canonical برای مدیریت نسخههای تکراری، نه برای پنهانکردن اطلاعات محرمانه
اشتباه رایج: Disallow همراه با noindex
فرض کنید در header یک صفحهای به آدرس /old-page/ چنین دستوری وجود دارد:
<meta name="robots" content="noindex">
اما همان صفحه در robots.txt هم مسدود شده است:
Disallow: /old-page/
در این شرایط ممکن است Googlebot نتواند صفحه را Crawl کند و دستور noindex را ببیند. بنابراین برای خارجکردن یک URL از ایندکس، مسدودکردن Crawl همیشه انتخاب درستی نیست.
Sitemap چیست؟
Sitemap XML فایلی است که URLهای مهم و ترجیحاً قابلایندکس سایت را به موتور جستوجو معرفی میکند.
نمونه ساده:
<url>
<loc>https://example.com/seo-training/</loc>
<lastmod>2026-07-10</lastmod>
</url>
Sitemap باید تا حد امکان تمیز باشد. بهتر است URLهای زیر داخل Sitemap قرار نگیرند:
- صفحات noindex
- URLهای Redirect
- صفحات 404 یا 410
- URLهای دارای Canonical به صفحه دیگر
- صفحات جستوجوی داخلی
- URLهای پارامتری کمارزش
- صفحات تکراری
- صفحات خصوصی یا رمزدار
ویژگیهای یک URL مناسب برای Sitemap
یک URL مناسب برای Sitemap معمولاً باید پاسخ 200 داشته باشد، قابل Crawl و قابل Index باشد، Canonical آن به خودش اشاره کند، محتوای مستقل داشته باشد و در معماری لینک داخلی سایت حضور داشته باشد.
Canonical چیست و چه ارتباطی با ایندکس دارد؟
Canonical به گوگل اعلام میکند که از میان چند URL مشابه، کدام نسخه ترجیحی است.
مثلاً ممکن است این URLها محتوای مشابهی داشته باشند:
/product/
/product/?color=red
/product/?utm_source=instagram
<link rel="canonical" href="https://example.com/product/">
برای بررسی Canonical یک صفحه، وارد Google Search Console شوید و URL کامل صفحه را در کادر URL Inspection بالای صفحه وارد کنید. سپس در بخش جزئیات ایندکس، دو گزینه ژ را بررسی کنید.
User-declared canonical آدرسی است که سایت بهعنوان نسخه اصلی معرفی کرده و Google-selected canonical آدرسی است که گوگل واقعاً انتخاب کرده است. اگر این دو متفاوت باشند، باید ناسازگاری میان سیگنالهایی مانند Canonical، لینکهای داخلی، Sitemap، ریدایرکتها و محتوای صفحات را بررسی کنید.
Crawl Budget چه زمانی مهم میشود؟
Crawl Budget را میتوان تعداد و الگوی درخواستهایی دانست که گوگل در یک بازه زمانی برای Crawl سایت در نظر میگیرد.
این مفهوم بیشتر برای سایتهای بزرگ، فروشگاههای دارای فیلترهای متعدد، مارکتپلیسها، سایتهای خبری پرتعداد و سایتهایی با میلیونها URL اهمیت دارد.
برای یک سایت شرکتی با چند ده یا چند صد صفحه، معمولاً Crawl Budget اولین مسئله نیست. در این سایتها بهتر است ابتدا لینک داخلی، Sitemap، noindex، Canonical، کیفیت محتوا و خطاهای فنی بررسی شود.
بهطور ساده، Crawl Budget تحت تأثیر دو عامل است:
۱. ظرفیت Crawl؛
سرور سایت چه تعداد درخواست را بدون کندی یا خطا تحمل میکند؟
اگر درخواستهای Googlebot باعث خطای سرور یا افزایش شدید زمان پاسخ شوند، گوگل ممکن است برای جلوگیری از فشار بیشتر، سرعت Crawl را کاهش دهد.
۲. تقاضای Crawl
گوگل تا چه اندازه نیاز دارد صفحات سایت را دوباره بررسی کند؟
صفحات مهم، محبوب، مرتباً بهروزشونده و دارای لینکهای قوی ممکن است بیشتر Crawl شوند. در مقابل، URLهای کمارزش یا تکراری معمولاً تقاضای کمتری برای Crawl دارند.
چه چیزهایی Crawl Budget را هدر میدهند؟
- فیلترهای ترکیبی فروشگاه
- Faceted Navigation کنترلنشده
- پارامترهای مرتبسازی
- صفحات جستوجوی داخلی
- Session ID در URL
- تقویمهای بینهایت
- صفحات تکراری
- URLهای ساختهشده توسط اسکریپتها
- زنجیرههای ریدایرکت
- خطاهای 404 گسترده ناشی از لینک داخلی
- Soft 404
- صفحات کمارزش و قابلخزش
- مسیرهای بینهایت یا Trapهای خزنده
برای مثال، یک فروشگاه ممکن است برای یک دسته محصول صدها ترکیب URL ایجاد کند:
/shoes?color=black
/shoes?color=white
/shoes?size=42
/shoes?sort=price
/shoes?color=black&size=42&sort=price
چطور Crawl Budget را با سرچ کنسول بررسی کنیم؟
برای مشاهده گزارش Crawl Stats، ابتدا Property موردنظر را در Google Search Console انتخاب کنید. سپس از منوی سمت چپ وارد Settings شوید و در بخش Crawling، گزینه Crawl stats را باز کنید.
این گزارش آمار خزش گوگل در ۹۰ روز گذشته را نشان میدهد؛ از جمله تعداد درخواستهای Crawl، حجم داده دانلودشده، میانگین زمان پاسخ سرور، کدهای وضعیت HTTP، انواع فایلهای دریافتشده، هدف خزش، نوع Googlebot و وضعیت دسترسی به هاست.
توجه داشته باشید که Crawl Stats در منوی اصلی Search Console نمایش داده نمیشود. همچنین ممکن است در برخی Propertyهای جدید یا کمفعالیت، هنوز داده کافی برای نمایش گزارش وجود نداشته باشد. اگر این گزینه را نمیبینید، ابتدا مطمئن شوید Property صحیح را انتخاب کردهاید، سایت تأیید مالکیت شده است و دسترسی کافی به تنظیمات Property دارید.
مسیر دسترسی: Search Console → Settings → Crawling → Crawl stats.
مسیر پیشنهادی بررسی Crawl Budget
پیش از هر چیز باید مشخص کنید که آیا واقعاً با مشکل Crawl Budget روبهرو هستید یا خیر.
پایین بودن تعداد صفحات ایندکسشده همیشه به معنی کمبود بودجه خزش نیست. در بسیاری از سایتهای کوچک و متوسط، مشکل اصلی به کیفیت صفحات، لینکسازی داخلی، Canonical یا تنظیمات ایندکس مربوط میشود.
مرحله اول: مشکلات سادهتر را بررسی کنید
ابتدا این موارد را کنترل کنید:
- آیا صفحات مهم از داخل سایت لینک دریافت میکنند؟
- آیا صفحات دارای تگ noindex نیستند؟
- آیا Canonical آنها به URL صحیح اشاره میکند؟
- آیا صفحات محتوای تکراری یا بسیار مشابه ندارند؟
- آیا هر صفحه ارزش و هدف مستقلی دارد؟
- آیا فقط URLهای اصلی و قابلایندکس داخل Sitemap قرار گرفتهاند؟
اگر پاسخ یکی از این موارد منفی باشد، احتمالاً مشکل اصلی Crawl Budget نیست.
مرحله دوم: گزارش Crawl Stats را بررسی کنید
از مسیر زیر وارد گزارش شوید:
Search Console → Settings → Crawling → Crawl stats
در این گزارش به تغییرات غیرعادی توجه کنید؛ برای مثال:
- افزایش خطاهای سرور مانند 5xx
- افزایش میانگین زمان پاسخ سرور
- کاهش ناگهانی تعداد درخواستهای Crawl
- Crawlشدن تعداد زیادی URL پارامتری
- مشکل در دسترسی گوگل به DNS، robots.txt یا Host
برای مثال، اگر همزمان با کندشدن سرور تعداد درخواستهای گوگل نیز کاهش پیدا کرده باشد، ممکن است مشکل از ظرفیت یا پایداری هاست باشد.
مرحله سوم: URLهای غیرضروری را پیدا کنید
در سایتهای بزرگ، ممکن است Googlebot زمان زیادی را صرف URLهایی کند که ارزش مستقلی برای نتایج جستوجو ندارند، مانند:
- صفحات فیلتر و مرتبسازی
- URLهای دارای پارامتر
- صفحات جستوجوی داخلی
- نسخههای تکراری یک صفحه
- زنجیرههای ریدایرکت
- صفحات 404
- صفحات بسیار کمارزش
برای نمونه، یک فروشگاه ممکن است برای یک دسته محصول، URLهای زیادی با رنگ، قیمت و روش مرتبسازی مختلف تولید کند. اگر این URLها بدون کنترل در دسترس Googlebot باشند، بخش زیادی از خزش سایت صرف صفحات غیرضروری میشود.
مرحله چهارم: سیگنالهای سایت را اصلاح کنید
بسته به نوع مشکل، این اقدامات میتوانند مفید باشند:
- حذف لینک داخلی به URLهای غیرضروری
- اصلاح ساختار فیلترهای فروشگاه
- استفاده صحیح از Canonical
- جلوگیری از تولید URLهای بینهایت
- حذف زنجیرههای ریدایرکت
- اصلاح خطاهای 404 و Soft 404
- پاکسازی Sitemap
- بهبود سرعت و پایداری سرور
مرحله پیشرفته: بررسی لاگ سرور
برای سایتهای بسیار بزرگ یا زمانی که اطلاعات Crawl Stats کافی نیست، میتوان لاگ سرور را بررسی کرد.
لاگ سرور نشان میدهد Googlebot دقیقاً کدام URLها را درخواست کرده، چه پاسخهایی دریافت کرده و بیشتر زمان خود را در کدام بخش سایت صرف کرده است.
این مرحله معمولاً به کمک توسعهدهنده، مدیر سرور یا متخصص سئو تکنیکال انجام میشود و برای بررسی اولیه سایتهای کوچک و متوسط ضروری نیست.
Rendering چیست و چرا برای سئو مهم است؟
صفحهای که Googlebot از سرور دریافت میکند، همیشه همان چیزی نیست که کاربر در مرورگر میبیند.
در سایتهای مبتنی بر JavaScript ممکن است HTML اولیه تقریباً خالی باشد و محتوای اصلی پس از اجرای JavaScript و دریافت اطلاعات از API ساخته شود.
Rendering یعنی گوگل منابع صفحه را اجرا کند و نسخه نهایی DOM را مشابه یک مرورگر بسازد. اگر محتوای اصلی فقط بعد از اجرای JavaScript ساخته شود و در این مرحله مشکلی رخ دهد، گوگل ممکن است محتوای واقعی صفحه را نبیند.
ریسکهای رایج در صفحات JavaScript محور:
- خطای JavaScript
- مسدودبودن فایل JS یا CSS
- خطای API
- نیاز به احراز هویت
- کندی شدید اجرای اسکریپت
- تولیدنشدن لینکها بهصورت قابلخزش
- تفاوت محتوای اولیه و محتوای Renderشده
- Timeout یا خطا در زمان Rendering
برای صفحات محتوایی مهم، بهتر است محتوای اصلی در HTML قابلدسترسی باشد یا با SSR و SSG به شکل قابلاعتماد به گوگل برسد. SSR بهتنهایی معجزه نمیکند، اما وابستگی کامل محتوا به اجرای JavaScript سمت کاربر را کمتر میکند.
CSR، SSR و SSG به زبان ساده
در Client-Side Rendering یا CSR، سرور معمولاً HTML محدودی ارسال میکند:
<div id="app"></div>
<script src="/app.js"></script>
بعد مرورگر JavaScript را اجرا میکند، APIها فراخوانی میشوند و محتوای صفحه ساخته میشود.
در Server-Side Rendering یا SSR، سرور HTML حاوی محتوای اصلی را تولید و ارسال میکند:
<h1>آموزش سرچ کنسول</h1>
<p>در این راهنما با گزارشهای Search Console آشنا میشوید.</p>
در Static Site Generation یا SSG، HTML صفحات هنگام Build تولید میشود و از طریق سرور یا CDN تحویل داده میشود. این روش برای صفحات محتوایی، مستندات، بلاگ و لندینگهایی که تغییر لحظهای ندارند، معمولاً گزینه مناسبی است.
در بسیاری از فریمورکهای مدرن، HTML ابتدا از سرور میرسد و بعد JavaScript تعاملات صفحه را فعال میکند. این فرایند Hydration نام دارد. اگر Hydration سنگین باشد، ممکن است LCP خوب باشد اما INP ضعیف شود؛ یعنی صفحه دیده میشود، اما دیر به کلیک یا تعامل کاربر پاسخ میدهد.
چطور Rendering را در سرچ کنسول بررسی کنیم؟
برای بررسی یک URL از ابزار URL Inspection استفاده کنید.
این ابزار دو نگاه متفاوت دارد:
- نسخه ایندکسشده: اطلاعات آخرین نسخهای را نشان میدهد که گوگل از صفحه پردازش کرده است.
- Test Live URL: نسخه فعلی صفحه را بهصورت زنده بررسی میکند.
در URL Inspection به این موارد توجه کنید:
- وضعیت Index
- زمان آخرین Crawl
- نوع Googlebot
- وضعیت Crawl Allowed
- وضعیت Page Fetch
- Canonical اعلامشده
- Canonical انتخابشده توسط گوگل
- Screenshot نسخه Renderشده
- HTML پردازششده
- منابع مسدودشده یا خطادار
اگر Screenshot ناقص است، متن اصلی در Rendered HTML دیده نمیشود، یا منابع مهم خطا دارند، مشکل فقط «ایندکس» نیست؛ احتمالاً باید سراغ Render و معماری فرانتاند بروید.
چرا یک صفحه ایندکس نمیشود؟
در تصویر دلایل index نشدن یک صفحه را نشان داده ایم و در ادامه به تفسیر ۱۰ دلیل اصلی ایندکس نشدن صفحات سایت ها میپردازیم…
۱. URL هنوز کشف نشده است
نشانههای احتمالی:
- هیچ لینک داخلی ندارد.
- در Sitemap نیست.
- تازه ساخته شده است.
- از صفحهای غیرقابلخزش لینک شده است.
- لینک آن فقط با تعامل JavaScript ساخته میشود.
۲. صفحه قابل Crawl نیست
دلایل احتمالی:
- مسدودشدن در robots.txt
- خطای DNS
- خطای سرور
- پاسخ 403
- محدودیت فایروال یا CDN
- Redirect Loop
- Timeout
- نیاز به ورود یا Cookie خاص
۳. محتوای صفحه Render نمیشود
دلایل احتمالی:
- خطای JavaScript
- خطای API
- مسدودبودن منابع
- تولید محتوا فقط پس از کلیک
- وابستگی به Local Storage
- اختلاف نسخه موبایل و دسکتاپ
- محتوای خالی در HTML و Render ناموفق
۴. صفحه noindex دارد
این دستور ممکن است از دو مسیر ارسال شود:
<meta name="robots" content="noindex">
یا:
X-Robots-Tag: noindex
۵. Canonical به صفحه دیگری اشاره میکند؛
ممکن است Canonical عمداً یا بر اثر تنظیم اشتباه افزونه سئو، قالب یا کدنویسی به URL دیگری اشاره کند.
۶. گوگل نسخه دیگری را Canonical انتخاب کرده است؛
حتی اگر Self-Canonical تنظیم شده باشد، گوگل ممکن است به دلیل شباهت زیاد محتوا و ناسازگاری سیگنالها، نسخه دیگری را انتخاب کند.
۷. صفحه Duplicate است؛
اگر چند URL محتوای تقریباً یکسان داشته باشند، گوگل ممکن است فقط یکی را وارد ایندکس اصلی کند.
۸. صفحه Soft 404 تشخیص داده شده است؛
Soft 404 صفحهای است که پاسخ 200 میدهد، اما محتوای آن شبیه صفحه خالی، خطا یا «موردی یافت نشد» است.
۹. محتوا ارزش مستقل کافی ندارد؛
مشکلاتی مثل محتوای بسیار کوتاه، صفحات شهر با متن تکراری، صفحات Tag خالی، صفحات فیلتر بدون تقاضا یا صفحات محصول بدون اطلاعات مستقل میتوانند احتمال ایندکس را کم کنند.
۱۰. گوگل هنوز صفحه را پردازش نکرده است؛
Request Indexing درخواست بررسی است، نه تضمین ایندکس فوری. بعد از اصلاح مشکل، باید Test Live URL را بررسی کنید و سپس درخواست ایندکس بدهید.
تفاوت Discovered و Crawled در گزارش Page Indexing
دو وضعیت رایج در Search Console معمولاً باعث سردرگمی میشوند.
Discovered – currently not indexed
یعنی گوگل URL را میشناسد، اما هنوز آن را Crawl یا پردازش کامل نکرده است.
موارد قابلبررسی:
- لینک داخلی
- کیفیت Sitemap
- ظرفیت و پایداری سرور
- حجم URLهای کمارزش
- اولویت صفحه در معماری سایت
- Crawl Demand
Crawled – currently not indexed
یعنی گوگل صفحه را Crawl کرده، اما فعلاً آن را وارد ایندکس نکرده است.
موارد قابلبررسی:
- کیفیت و تمایز محتوا
- Canonical
- Duplicate Content
- Soft 404
- Render نهایی
- پاسخ واقعی صفحه
- معماری لینک داخلی
- ارزش مستقل URL
نکته مهم: اسم وضعیت در گزارش، دلیل نهایی مشکل را مشخص نمیکند. باید چند URL نمونه از هر گروه را با URL Inspection بررسی کنید و الگوی مشترک را پیدا کنید.
گزارش Page Indexing را چطور درست بخوانیم؟
گزارش Page Indexing دید کلی از تعداد صفحات ایندکسشده و ایندکسنشده سایت میدهد. اما برای تصمیمگیری، فقط عدد کل کافی نیست.
هنگام بررسی این گزارش:
- روی عدد کل وسواس نداشته باشید.
- URLها را بر اساس نوع صفحه دستهبندی کنید.
- مشخص کنید کدام URLها واقعاً باید Index باشند.
- صفحات غیرقابلایندکس عمدی را از خطاهای واقعی جدا کنید.
- چند URL نمونه از هر گروه را در URL Inspection بررسی کنید.
- الگوی مشترک میان URLها را پیدا کنید.
برای مثال، وجود هزار صفحه Excluded by noindex لزوماً مشکل نیست؛ ممکن است همه آنها صفحات فیلتر، حساب کاربری یا نتایج داخلی باشند که عمداً noindex شدهاند. اما اگر صفحههای مهم دستهبندی یا مقالههای اصلی سایت در وضعیت Crawled – currently not indexed باشند، باید جدیتر بررسی شوند.
Core Web Vitals در سرچ کنسول چیست؟
Core Web Vitals مجموعهای از متریکها برای سنجش بخشهای مهم تجربه واقعی کاربر هستند. سه متریک اصلی عبارتاند از:
- LCP برای عملکرد بارگذاری
- INP برای پاسخگویی به تعامل
- CLS برای ثبات بصری
آستانههای عمومی وضعیت خوب:
- LCP حداکثر ۲.۵ ثانیه
- INP کمتر از ۲۰۰ میلیثانیه
- CLS حداکثر ۰.۱
گزارش Core Web Vitals در سرچ کنسول بر دادههای واقعی کاربران تکیه دارد، نه فقط یک تست آزمایشگاهی. به همین دلیل ممکن است تست شما در PageSpeed Insights خوب باشد، اما سرچ کنسول همچنان گروهی از URLها را در وضعیت Need improvement یا Poor نشان دهد.
برای تحلیل درست، داده میدانی و داده آزمایشگاهی را کنار هم بگذارید:
- Field Data نشان میدهد کاربران واقعی چه تجربهای داشتهاند.
- Lab Data کمک میکند علت فنی مشکل را پیدا کنید.
LCP، INP و CLS به زبان ساده
LCP زمان نمایش بزرگترین عنصر محتوایی قابلمشاهده در Viewport را اندازهگیری میکند. این عنصر معمولاً تصویر Hero، بنر اصلی، تصویر شاخص، تیتر بزرگ یا بلوک متن اصلی است.
عوامل رایج ضعف LCP:
- TTFB بالا
- تصویر Hero سنگین
- Preloadنشدن منبع اصلی
- CSS مسدودکننده Render
- JavaScript سنگین
- Lazy Load اشتباه تصویر بالای صفحه
- Renderشدن محتوای اصلی فقط در سمت Client
INP پاسخگویی صفحه به تعاملات کاربر را میسنجد؛ مثل کلیک روی منو، انتخاب فیلتر، بازکردن Modal یا تایپ در فرم.
عوامل رایج ضعف INP:
- Long Taskهای JavaScript
- Event Handler سنگین
- Re-render گسترده
- Hydration سنگین
- اسکریپتهای Third-party
- DOM بسیار بزرگ
CLS میزان جابهجایی ناگهانی عناصر صفحه را اندازهگیری میکند. مثلاً کاربر میخواهد روی دکمهای کلیک کند، اما تصویر یا بنری دیرتر لود میشود و دکمه ناگهان جابهجا میشود.
عوامل رایج ضعف CLS:
- تصاویر بدون
widthوheight - ویدئو یا iframe بدون نسبت ابعاد
- تبلیغات بدون فضای رزروشده
- فونتهایی با اختلاف ابعاد زیاد
- محتوای Async بدون Placeholder
Core Web Vitals بهتنهایی رتبه برتر را تضمین نمیکند. محتوای مرتبط، کیفیت، اعتبار، لینکها و intent کاربر همچنان اهمیت دارند. اما ضعف شدید تجربه صفحه میتواند مانع رشد شود، مخصوصاً وقتی چند صفحه از نظر محتوا و ارتباط به هم نزدیک هستند.
Mobile-first Indexing چه تأثیری دارد؟
گوگل برای ایندکس و رتبهبندی، نسخه موبایل محتوای سایت را مبنا قرار میدهد. بنابراین Responsive بودن ظاهر کافی نیست؛ نسخه موبایل باید از نظر محتوایی و فنی کامل باشد.
در نسخه موبایل بررسی کنید:
- محتوای اصلی نسخه دسکتاپ وجود دارد.
- عنوان و Meta Description درست است.
- Structured Data ضروری حفظ شده است.
- لینکهای داخلی مهم حذف نشدهاند.
- تصاویر و Altها در دسترس هستند.
- محتوا پشت تعاملهای غیرقابلدسترسی پنهان نشده است.
- Canonical و Meta Robots صحیح هستند.
اگر صفحه دسکتاپ کامل است اما نسخه موبایل ناقص، ممکن است گوگل همان نسخه ناقص را مبنای درک و رتبهبندی قرار دهد.
Crawl و Index در عصر AI Overviews
برای حضور در تجربههای جدید جستوجو مثل AI Overviews هم پایه کار تغییر نکرده است. محتوای شما باید قابلدسترسی، قابلخزش، قابلفهم و مفید باشد.
هیچ افزونه یا فایل مخفیای وجود ندارد که ضعف Crawl، Index، ساختار HTML یا کیفیت محتوا را جبران کند. اگر گوگل نتواند صفحه را ببیند، بفهمد یا بهدرستی در ایندکس نگه دارد، شانس حضور مؤثر آن در تجربههای جدید جستوجو هم محدود میشود.
چکلیست عملی بررسی ایندکسنشدن یک صفحه
برای بررسی یک URL، این مراحل را بهترتیب انجام دهید.
مرحله ۱: پاسخ URL
- آیا URL باز میشود؟
- کد وضعیت آن چیست؟
- آیا به URL دیگری Redirect میشود؟
- آیا Redirect Chain وجود دارد؟
- آیا نسخه HTTP، HTTPS، www و بدون www درست مدیریت شدهاند؟
مرحله ۲: Crawlability
- آیا robots.txt مسیر را مسدود کرده است؟
- آیا Googlebot با 403 یا 5xx روبهرو میشود؟
- آیا منابع ضروری مسدود هستند؟
- آیا URL لینک داخلی دارد؟
- آیا لینک به شکل
<a href>قابلخزش ساخته شده است؟
مرحله ۳: Indexability
- آیا Meta Robots شامل
noindexاست؟ - آیا X-Robots-Tag وجود دارد؟
- Canonical به کدام URL اشاره میکند؟
- Google-selected canonical چیست؟
- آیا صفحه رمزدار یا خصوصی است؟
مرحله ۴: Rendering
- Screenshot در URL Inspection چگونه است؟
- متن اصلی در Rendered HTML وجود دارد؟
- آیا JavaScript یا API خطا دارد؟
- آیا محتوا فقط پس از کلیک ظاهر میشود؟
- آیا نسخه موبایل محتوا را کامل نمایش میدهد؟
مرحله ۵: کیفیت و تمایز صفحه
- آیا صفحه پاسخ مستقلی به یک Intent میدهد؟
- آیا با صفحات دیگر تقریباً تکراری است؟
- آیا محتوای مفید و اختصاصی دارد؟
- آیا صفحه شبیه Soft 404 است؟
- آیا لینکهای داخلی اهمیت صفحه را نشان میدهند؟
مرحله ۶: Sitemap و لینک داخلی
- آیا URL قابلایندکس داخل Sitemap قرار دارد؟
- آیا
lastmodواقعی است؟ - آیا از صفحات مرتبط لینک دریافت میکند؟
- آیا Anchor Text لینکها موضوع صفحه را توضیح میدهد؟
- آیا عمق کلیک صفحه بیش از حد زیاد است؟
مرحله ۷: درخواست بررسی
پس از اصلاح مشکلات:
- Test Live URL را اجرا کنید.
- وضعیت Crawl و Indexability را بررسی کنید.
- اگر URL سالم بود، Request Indexing بزنید.
- Sitemap را بررسی کنید.
- در روزهای بعد، وضعیت را دوباره در URL Inspection و Page Indexing کنترل کنید.
اگر این چکلیست را برای چند URL انجام میدهید، دستی جلو رفتن ممکن است کافی باشد. اما اگر قرار است دهها یا صدها URL را بررسی کنید، بهتر است از پالت کمک بگیرید تا صفحات را بر اساس اهمیت و نوع مشکل دستهبندی کنید.
سئو سایتت رو به ما بسپر
ما در پالت کمک میکنیم کسبوکارها از طراحی سایت و سئو تا مشاوره رشد، مسیر حرفهایتر و دقیقتری داشته باشند.
با ما تماس بگیریدسوالات پرتکرار
آیا ایندکسنشدن صفحه همیشه مشکل فنی است؟
آیا Request Indexing باعث ایندکس فوری میشود؟
آیا Sitemap باعث ایندکس قطعی صفحات میشود؟
تفاوت Crawled - currently not indexed و Discovered - currently not indexed چیست؟
آیا Core Web Vitals مستقیماً رتبه را تضمین میکند؟
جمعبندی
برای حضور مؤثر یک صفحه در گوگل، انتشار محتوا کافی نیست.
گوگل باید URL را پیدا کند، بتواند آن را Crawl کند، محتوای نهایی را Render کند، صفحه را قابلایندکس تشخیص دهد و در نهایت آن را برای جستوجوی کاربر مناسب بداند.
مهمترین نکته این است که Crawl، Index و Rank را یک مفهوم واحد در نظر نگیریم. ممکن است صفحه Crawl شود اما Index نشود. ممکن است Index شود اما رتبه نگیرد. همچنین ممکن است صفحه از نظر محتوایی خوب باشد، اما به دلیل noindex، Canonical اشتباه، خطای JavaScript یا ضعف لینک داخلی هرگز فرصت حضور مؤثر در نتایج را پیدا نکند.
Search Console بهترین نقطه شروع برای تشخیص این مشکلات است. اما وقتی دادهها زیاد میشوند، ارزش واقعی در تفسیر و اولویتبندی است.
