چرا صفحه ایندکس نمی‌شود؟ راهنمای عیب‌یابی Google

ایندکس نشدن صفحه در گوگل همیشه خطا نیست. صفحه فیلتر، سبد خرید، نسخه تکراری URL و محتوای حذف‌شده معمولاً نباید ایندکس شوند. مسئله زمانی است که URL مهم، Canonical و قابل‌نمایش شما پیدا یا Crawl نمی‌شود، محتوایش در Render دیده نمی‌شود، دستور noindex دارد، Duplicate تشخیص داده شده یا پس از پردازش برای Index انتخاب نشده است.

راه‌حل هم همیشه «محتوا را طولانی‌تر کن و Request Indexing بزن» نیست. ابتدا باید مرحله شکست را پیدا کنید: Discovery، Crawl، Fetch، Render، Indexing یا Serving. سپس فقط همان علت را اصلاح و با تاریخ Crawl و Evidence دوباره آزمایش کنید.

پاسخ کوتاه: مسیر عیب‌یابی در هفت سؤال

1. Intent: آیا این URL واقعاً باید در Search باشد؟
2. Discovery: Google URL دقیق را از Link یا Sitemap می‌شناسد؟
3. Crawl: robots.txt، Login یا WAF دسترسی را مسدود نکرده است؟
4. Fetch: پاسخ نهایی ۲۰۰ و پایدار است یا Redirect/4xx/5xx می‌دهد؟
5. Index control: Meta robots یا X‑Robots‑Tag اجازه Index می‌دهد؟
6. Canonical/Render: Canonical درست است و محتوای اصلی در HTML رندرشده دیده می‌شود؟
7. Selection: صفحه هدف مستقل و ارزشمند دارد یا Duplicate/Soft ۴۰۴/کم‌ارزش است؟

این هفت سؤال را به‌ترتیب پاسخ دهید. بازنویسی محتوا برای صفحه‌ای که ۵۰۳ می‌دهد یا Canonical آن به URL دیگری است، اتلاف زمان است.

Discovery، Crawl، Render، Index و Rank یکی نیستند

صفحه می‌تواند Crawl شود ولی Index نشود؛ Index شود ولی برای Query شما نمایش داده نشود؛ یا URL فرعی Index نشود چون Google نسخه Canonical را انتخاب کرده است. قبل از هر اقدام، Vocabulary گزارش را درست بخوانید.

مرحله صفر: آیا این صفحه باید ایندکس شود؟

هدف، Index coverage صددرصدی نیست. راهنمای Page indexing گوگل نیز می‌گوید Not indexed می‌تواند نتیجه درست برای Duplicate، noindex، robots، ۴۰۴ یا Variation فیلتر باشد. هدف، ایندکس‌شدن URLهای مهم و Canonical است.

یک Keyword-to-URL map بسازید: هدف، Intent، URL Canonical، وضعیت مطلوب و Owner. اگر دو URL یک هدف دارند، مسئله Indexing ممکن است در اصل Cannibalization یا Duplicate architecture باشد. برای تصمیم Merge/Keep/Redirect از راهنمای Topic Cluster و Cannibalization استفاده کنید.

چطور وضعیت دقیق یک URL را بفهمیم؟

URL Inspection مرجع URL مشخص است

راهنمای رسمی URL Inspection دو منبع داده را جدا می‌کند:

• Google Index data: آنچه Google از آخرین Crawl/Index درباره URL می‌داند؛ شامل Last crawl و Google-selected canonical.
• Live test: وضعیت همین لحظه برای Fetch و بعضی شروط Indexability؛ برای تأیید Fix مفید است اما جامع نیست.

Live test وضعیت Duplicate/Canonical انتخاب‌شده و همه مسائل کیفیت، Manual action، Removal یا Policy را بررسی نمی‌کند. «URL is available to Google» در Live test تضمین نمی‌کند صفحه Index شود.

Page indexing برای Pattern و Trend است

گزارش Page indexing URLهای شناخته‌شده را بر اساس Reason گروه‌بندی می‌کند. نمونه‌های قابل مشاهده ممکن است حداکثر ۱۰۰۰ URL باشند؛ برای هر گروه، الگو را از Template، Directory، Parameter، تاریخ انتشار یا Deploy پیدا کنید. افزایش Not indexed به‌تنهایی Incident نیست؛ افزایش در URLهای مهم با Reason غیرمنتظره مهم است.

عملگر site: ابزار تقریبی است

site: می‌تواند برای مشاهده نمونه‌ها کمک کند، اما شمارش و نبود یک نتیجه را معیار قطعی Coverage نگیرید. برای URL مشخص، URL Inspection و برای Trend، Page indexing را مبنا قرار دهید. اگر صفحه Indexed است اما با Query دلخواه دیده نمی‌شود، مسئله ممکن است Ranking یا Intent باشد، نه Indexing.

یک Evidence pack برای هر URL بسازید

قبل از تغییر، Snapshot ثبت کنید تا پس از Fix بدانید چه چیزی تغییر کرده است:

• URL دقیق و همه Variantهای http/https، www/non-www، Slash و Parameter؛
• Desired state: Index، Noindex، Redirect، ۴۰۴/۴۱۰ یا Canonical alternate؛
• Reason و Source در Page indexing؛
• Last crawl، Referring page و Sitemap discovery؛
• Crawl allowed، Page fetch و Indexing allowed؛
• User-declared و Google-selected canonical؛
• HTTP chain، Header و HTML Source؛
• Rendered HTML، Screenshot و Resource error؛
• Internal links، Sitemap membership و Template؛
• تاریخ Deploy/Content change و Server/CDN log.

در ممیزی سراسری، الگوی Issue را به جای بررسی تصادفی URLها پیدا کنید. چارچوب کامل Prioritization در چک‌لیست ممیزی سئو آمده است.

گام ۱: URL و Variant درست را بررسی کنید

ممکن است URL را با Protocol، Subdomain، Case، Slash یا Parameter اشتباه Inspect کرده باشید. این Variantها را با Fetch مستقیم مقایسه کنید:

http://example.ir/page
https://example.ir/page
https://www.example.ir/page
https://example.ir/page/
https://example.ir/page?utm_source=x

یک نسخه Canonical باید مقصد نهایی پایدار باشد. Variantها در صورت نیاز با Redirect مستقیم به آن برسند و Internal link، Sitemap، hreflang و canonical tag نسخه دیگری را پیشنهاد ندهند. Fragment مانند #section معمولاً URL محتوایی جدا برای Google نیست.

گام ۲: HTTP، DNS، Server و CDN را عیب‌یابی کنید

فقط Browser خودتان را ملاک نگیرید. Logهای Origin، CDN و WAF را برای User agent و زمان گزارش بررسی کنید. در میزبانی یا شبکه ایران ممکن است Rule ضدبات، محدودیت جغرافیایی، DNS ناسازگار یا قطعی بین‌الملل به کاربر داخلی پاسخ ۲۰۰ و به Googlebot پاسخ ۴۰۳/5xx بدهد. User agent را جعل نکنید تا Cloaking بسازید؛ دسترسی عمومی و سازگار فراهم و با URL Inspection و Log تأیید کنید.

برای تفسیر ۳۰۱/۴۰۴/۴۱۰/۴۲۹/5xx به راهنمای کدهای وضعیت HTTP مراجعه کنید.

گام ۳: robots.txt، Meta robots و X‑Robots‑Tag را جدا کنید

مستندات Robots meta و X‑Robots‑Tag می‌گوید Directive فقط وقتی خوانده می‌شود که Crawler به صفحه دسترسی داشته باشد. اگر URL را در robots.txt مسدود کنید، Google ممکن است noindex داخل آن را نبیند؛ حتی احتمال Index شدن URL براساس Linkهای بیرونی و با Snippet محدود وجود دارد.

اگر می‌خواهید URL ایندکس شود

• Rule مؤثر robots.txt را برای User agent مربوط پیدا کنید.
• Meta robotsهای تکراری و Headerهای چندلایه را جمع کنید.
• در تعارض Directiveها، Rule محدودکننده‌تر می‌تواند اعمال شود.
• Template، SEO plugin، CDN و Origin را جدا بررسی کنید.
• پس از Fix، Source و Response header نهایی را دوباره بخوانید.

برای طراحی فایل و تشخیص Patternهای Disallow از راهنمای robots.txt استفاده کنید.

گام ۴: سیگنال‌های Canonical را هم‌راستا کنید

Canonical یک Hint قوی است، نه فرمان مطلق. Google می‌تواند URL دیگری را بر اساس شباهت محتوا و سیگنال‌ها انتخاب کند. راهنمای Canonicalization گوگل روش‌های Redirect، rel="canonical" و Sitemap را توضیح می‌دهد.

Canonical cluster را Audit کنید

• URL هدف ۲۰۰ می‌دهد و Self-canonical معتبر دارد.
• Canonical به Redirect، ۴۰۴، noindex یا URL خارج Scope اشاره نمی‌کند.
• Internal linkها عمدتاً به نسخه Canonical می‌روند.
• Sitemap فقط Canonicalهای مطلوب را فهرست می‌کند.
• http/https، www، Slash، Case و Parameter Strategy سازگار دارند.
• hreflang به URLهای Canonical و متقابل اشاره می‌کند.
• محتوای URL هدف واقعاً از Cluster متمایز یا نسخه مرجع است.

وضعیت «Duplicate, Google chose different canonical than user» را با افزودن تگ دوم حل نکنید. Google-selected canonical را Inspect و اختلاف محتوا، Link، Sitemap، Redirect و Template را بررسی کنید. اگر هر دو صفحه باید Index شوند، باید Intent و محتوای واقعاً مستقل داشته باشند؛ اگر نه، Consolidate کنید.

گام ۵: HTML رندرشده و JavaScript را ببینید

در سایت JavaScript-heavy، پاسخ ۲۰۰ ممکن است Shell خالی باشد. راهنمای JavaScript SEO گوگل توضیح می‌دهد که Google صفحه را Crawl و برای Render صف‌بندی می‌کند؛ محتوایی که در HTML رندرشده دیده نشود قابل Index نیست.

Source و Render را مقایسه کنید

• Title، Meta robots، Canonical و محتوای اصلی در نسخه رندرشده درست‌اند.
• API بدون Login، Token کوتاه‌عمر، Origin محدود یا Cookie شخصی کار می‌کند.
• JS/CSS/Font لازم توسط robots، CDN یا CSP مسدود نیست.
• خطای Runtime، Hydration یا Timeout صفحه را خالی نمی‌کند.
• محتوای اصلی برای ظاهرشدن به Click، Scroll یا Hover وابسته نیست.
• Lazy loading بر مشاهده در Viewport متکی است، نه Interaction اجباری.
• Linkها عنصر <a href="..."> قابل Crawl دارند.
• SSR/SSG/Prerender با Hydration محتوای اصلی را حذف یا عوض نمی‌کند.

Screenshot به‌تنهایی کافی نیست؛ Rendered HTML و Network resourceها را هم بررسی کنید. برای PWA، Client-side routing، Cache و URL state از راهنمای سئو PWA و رندر JavaScript کمک بگیرید.

گام ۶: Soft ۴۰۴ و صفحه ظاهراً خالی را رفع کنید

Soft ۴۰۴ فقط صفحه «پیدا نشد» با Status ۲۰۰ نیست. محتوای تقریباً خالی، خطای بزرگ در Body یا صفحه‌ای که Resource اصلی آن برای Googlebot Load نشده نیز ممکن است Soft ۴۰۴ تشخیص داده شود. راهنمای خطاهای Crawl گوگل سه تصمیم را جدا می‌کند:

در فروشگاه، محصول موقتاً ناموجود لزوماً ۴۰۴ نیست؛ اگر صفحه هنوز برای کاربر ارزش، مشخصات، جایگزین یا زمان بازگشت دارد، ۲۰۰ می‌تواند درست باشد. محصول حذف‌شده بدون جانشین، تصمیم دیگری می‌خواهد. Inventory کسب‌وکار را معیار کنید.

گام ۷: هدف و ارزش مستقل صفحه را ارزیابی کنید

برای «Crawled – currently not indexed» علت واحد و دکمه جادویی وجود ندارد. صفحه Crawl شده ولی اکنون Index نشده است. ابتدا Render، Directive، Canonical cluster و Soft ۴۰۴ را رد کنید؛ سپس سؤال کنید چرا این URL باید مستقل باشد.

محتوا را فقط طولانی نکنید

• Intent و Audience صفحه با URL دیگری تکرار نشده است.
• پاسخ اصلی زود و شفاف ارائه می‌شود.
• اطلاعات، تجربه، داده، مثال یا ابزارِ مختص این صفحه وجود دارد.
• Title/H1/Body وعده یکسان می‌دهند.
• صفحه Category/List، محصول یا Location محتوای تصمیم کافی دارد.
• نسخه Programmatic فقط نام شهر/محصول را عوض نکرده است.
• محتوا Outdated، Placeholder، Scraped یا ترکیب بی‌هدف نیست.
• صفحه در معماری سایت نقش و لینک داخلی زمینه‌دار دارد.

گاهی بهترین Fix، Merge و Redirect است؛ گاهی افزودن اطلاعات یا بازطراحی Template؛ و گاهی پذیرش Noindex. برای عناصر On-page، Metadata و Intent از چک‌لیست سئو داخلی استفاده کنید.

لینک داخلی و صفحه یتیم را عیب‌یابی کنید

Sitemap جای Navigation مفید را نمی‌گیرد. Google از Linkها برای کشف و فهم رابطه صفحات استفاده می‌کند. راهنمای Link قابل Crawl توصیه می‌کند لینک معمولاً عنصر <a> با href معتبر باشد.

• URL مهم از Home یا Hub مرتبط در چند مرحله منطقی قابل دسترسی است.
• Link فقط با JavaScript handler و بدون href ساخته نشده است.
• Anchor موضوع مقصد را طبیعی توضیح می‌دهد.
• Link به Redirect/Parameter به‌جای Canonical نمی‌رود.
• Pagination و Load more مسیر Crawl برای آیتم‌ها دارند.
• صفحه فقط در Footer عظیم یا XML sitemap دفن نشده است.
• Orphanهای عمدی و ناخواسته جدا شده‌اند.

ساختار Hub/Category/Breadcrumb را برای کاربر طراحی کنید، نه «تعداد کلیک جادویی». مقاله ساختار درختی سایت اصول معماری مسیرها را تکمیل می‌کند.

Sitemap را به فهرست URLهای مطلوب تبدیل کنید

راهنمای ساخت Sitemap گوگل Sitemap را Hint می‌داند، نه تضمین Crawl یا Index. فقط URLهایی را بفرستید که ترجیح می‌دهید در Search باشند.

QA نقشه سایت

• URLها مطلق، Canonical، ۲۰۰ و Index-intended هستند.
• Redirect، ۴۰۴، noindex، Login، Filter و Duplicate حذف شده‌اند.
• سایت بزرگ در فایل‌های حداکثر ۵۰هزار URL یا ۵۰MB فشرده‌نشده تقسیم شده است.
• Encoding و XML معتبرند و Sitemap برای Google قابل Fetch است.
• lastmod فقط تغییر مهم واقعی محتوا/داده/لینک را با تاریخ درست نشان می‌دهد.
• priority و changefreq را برای Google اهرم فرض نکنید؛ Google آن‌ها را نادیده می‌گیرد.
• Sitemap index بر اساس نوع/بخش، عیب‌یابی Segment را ممکن می‌کند.

برای تاریخ شمسی صفحه، مقدار Sitemap را همچنان با قالب معتبر پروتکل تولید کنید؛ تبدیل اشتباه منطقه زمانی یا تغییر روزانه lastmod اعتماد به Signal را کم می‌کند.

Playbook وضعیت‌های رایج Search Console

Discovered – currently not indexed

ابتدا Last crawl خالی، Referring page و Sitemap را بررسی کنید. URLهای بی‌نهایت Facet/Calendar، Linkهای Parameter و ظرفیت ضعیف Host می‌توانند کشف را از Crawl جدا کنند. یک Link زمینه‌دار و Sitemap تمیز بدهید؛ Requestهای تکراری راه‌حل مقیاس نیستند.

Crawled – currently not indexed

Response و Render را در زمان Crawl ببینید. صفحه ممکن است Duplicate، Empty state، Soft ۴۰۴، محتوای ناقص به‌دلیل JS یا فاقد هدف مستقل باشد. «تعداد کلمه کم» Diagnosis نیست؛ چند URL نمونه از یک Template را با URLهای Indexed همان Template مقایسه کنید.

Duplicate و Canonical

Not indexed بودن Alternate عمدی مشکل نیست. تنها وقتی Fix کنید که URL مطلوب اشتباه انتخاب شده یا هر دو URL واقعاً نیاز مستقل دارند. Signalهای متناقض را یک‌جا اصلاح و برای Consolidation زمان بدهید.

سایت تازه یا دامنه‌ای که هیچ صفحه‌اش ایندکس نیست

1. Property درست Domain/Protocol را در Search Console تأیید کنید.
2. Home را Inspect و Live test کنید.
3. robots.txt، noindex سراسری، Login و Headerهای CDN را بررسی کنید.
4. Home و صفحات مهم ۲۰۰، Canonical و دارای محتوای قابل Render باشند.
5. Navigation قابل Crawl از Home بسازید.
6. Sitemap تمیز را Submit کنید.
7. Manual Actions و Security Issues را بررسی کنید.
8. چند URL مهم را Request Indexing کنید و به‌جای تکرار، مانیتور کنید.

خرید Link یا ثبت در دایرکتوری بی‌کیفیت پیش‌نیاز Index نیست. کسب Mention و Link واقعی می‌تواند Discovery و اعتبار کلی را کمک کند، اما هیچ Backlinkی مانع noindex، خطای Server یا محتوای خالی را درمان نمی‌کند.

افت ناگهانی Index را مثل Incident مدیریت کنید

اگر Segment مهم ناگهان افت کرد، ابتدا Change را مهار کنید:

1. زمان افت را با Deploy، Plugin، CDN/WAF، Migration و Content job تطبیق دهید.
2. Sample قبل/بعد از Templateهای آسیب‌دیده بگیرید.
3. robots، Meta/X-Robots، Canonical، Status و Sitemap diff بسازید.
4. Server/Crawl log و Host availability را بررسی کنید.
5. Render و API/Resource failure را روی Production بازتولید کنید.
6. Manual action، Security issue و Removal را کنترل کنید.
7. اگر تغییر واضح و پراثر است Rollback؛ سپس Root cause و Test اضافه کنید.

هم‌زمان صد تغییر انجام ندهید؛ Attribution از بین می‌رود. Owner فنی، SEO، محتوا و Infra را در Incident مشخص و Timeline شواهد را نگه دارید.

Faceted navigation و URLهای بی‌نهایت فروشگاه

ترکیب رنگ، سایز، Sort، قیمت، موجودی و پارامتر Tracking می‌تواند هزاران URL نزدیک بسازد. ابتدا Demand و ارزش هر Facet را دسته‌بندی کنید:

robots.txt، noindex و canonical ابزارهای قابل تعویض نیستند. اگر Google باید noindex/canonical را ببیند، Crawl را کورکورانه نبندید. در سایت بزرگ، Strategy را با Log و الگوی Crawl طراحی کنید.

Crawl budget چه زمانی واقعاً مهم است؟

برای بیشتر سایت‌های کوچک و متوسط، Sitemap به‌روز و کنترل Page indexing کافی است. مستندات جاری Crawl budget گوگل موضوع را برای سایت‌های بسیار بزرگ و پرتغییر مطرح می‌کند. بهبود سرعت Frontend به‌تنهایی «بودجه خزش» جادویی نمی‌سازد.

اگر میلیون‌ها URL، Facet بی‌نهایت، تغییر روزانه گسترده یا Log نشان‌دهنده Waste دارید:

• URL space و Parameter generation را محدود کنید.
• Duplicate، Chain، Soft ۴۰۴ و 5xx را کاهش دهید.
• Sitemap را با lastmod دقیق و Segmentهای مفید نگه دارید.
• Availability و Response time Server را پایدار کنید.
• Log را برای Googlebot معتبر و Response distribution تحلیل کنید.
• robots.txt را مرتب روشن/خاموش نکنید تا بودجه «جابجا» شود.

خطاهای رایج WordPress

• فعال‌ماندن «از موتورهای جست‌وجو درخواست کن تا محتوای سایت را بررسی نکنند» پس از Launch؛
• noindex ناخواسته در Post type، Taxonomy، Author یا Pagination افزونه SEO؛
• Canonical متناقض از Theme و دو Plugin؛
• Staging noindex که با Migration وارد Production شده است؛
• Cache/CDN که Header یا HTML قدیمی noindex را ارائه می‌دهد؛
• Redirect plugin با Loop، Chain یا Regex بیش‌ازحد گسترده؛
• Page builder که محتوای اصلی را پس از JS/API خطادار می‌سازد؛
• Sitemap شامل Attachment، Tag یا URLهای noindex/redirect؛
• محصول/مقاله منتشرشده اما بدون Link از Hub یا Category؛
• Security plugin/WAF که Googlebot یا Resource را ۴۰۳ می‌کند.

تنظیم را در Admin، HTML/Header عمومی، URL Inspection و Cache پاک‌شده تطبیق دهید. دیدن گزینه درست در افزونه ثابت نمی‌کند Response عمومی همان است.

Request Indexing را چه زمانی بزنیم؟

راهنمای Request recrawl گوگل می‌گوید Crawl می‌تواند از چند روز تا چند هفته طول بکشد و درخواست، Crawl یا Inclusion فوری را تضمین نمی‌کند. درخواست تکراری برای همان URL آن را سریع‌تر نمی‌کند و Quota وجود دارد.

Fix را چگونه Validate و مانیتور کنیم؟

1. Root cause و Desired state را در Ticket بنویسید.
2. Fix را روی Sample نماینده و Edge case آزمایش کنید.
3. HTTP، Header، HTML و Render را مستقیم تأیید کنید.
4. Live test را اجرا و تفاوت با Index data را ثبت کنید.
5. برای چند URL مهم Request و برای گروه Validation workflow را استفاده کنید.
6. منتظر Crawl جدید بمانید و Last crawl/Reason/Canonical را مقایسه کنید.
7. Trend Segment را پس از زمان کافی بسنجید؛ نه فقط یک URL.
8. Regression test را به Template، Release یا Sitemap pipeline اضافه کنید.

اگر Fix فنی پاس شد اما Indexing رخ نداد، دوباره همان دکمه را نزنید. Canonical cluster، Render و هدف مستقل صفحه را بازبینی و محدودیت عدم تضمین Index را بپذیرید.

KPIهای مفید برای عملیات Indexing

این KPIها تعریف عملیاتی داخلی‌اند و فاکتور رتبه Google نیستند. Baseline را براساس Template و نوع صفحه تفکیک کنید؛ Index lag خبر، محصول و صفحه Evergreen یکسان نیست.

برنامه هفت‌روزه عیب‌یابی

چک‌لیست نهایی حل ایندکس نشدن

• Desired state URL پیش از Fix مشخص شده است.
• URL دقیق و Variantهای Protocol/Subdomain/Slash/Parameter بررسی شده‌اند.
• Index data، Live test و تاریخ Last crawl از هم جدا خوانده شده‌اند.
• Response نهایی، Chain، DNS، Server، CDN و WAF پایدارند.
• robots.txt، Meta robots و X‑Robots‑Tag در همه لایه‌ها بررسی شده‌اند.
• User canonical، Google canonical، Sitemap و Internal link هم‌راستا هستند.
• HTML Source، Rendered HTML، Screenshot و Resource error مقایسه شده‌اند.
• محتوای اصلی بدون Interaction اجباری دیده می‌شود.
• Soft ۴۰۴ با Status/Redirect/Render درست رفع شده است.
• صفحه هدف و ارزش مستقل دارد یا Merge/Noindex شده است.
• Link قابل Crawl و مسیر معماری زمینه‌دار وجود دارد.
• Sitemap فقط URLهای Canonical، ۲۰۰ و Index-intended دارد.
• Facets، Sort، Tracking و Zero-result Strategy دارند.
• Request Indexing فقط پس از Fix و برای URL محدود استفاده شده است.
• Fix با Crawl تازه و Trend Segment Validate می‌شود.
• Template، Sitemap و Release برای Regression تست دارند.

پرسش‌های متداول

چقدر طول می‌کشد یک صفحه در گوگل ایندکس شود؟

زمان ثابت یا SLA عمومی وجود ندارد. گوگل می‌گوید Recrawl ممکن است چند روز تا چند هفته طول بکشد و Inclusion تضمین نیست. به‌جای وعده ساعت/روز، URL مهم را قابل Crawl و Index، لینک‌شده و در Sitemap نگه دارید و Last crawl/Reason را مانیتور کنید.

تفاوت robots.txt و noindex چیست؟

robots.txt درخواست Crawl را کنترل می‌کند؛ noindex دستور Index در HTML یا Header است و برای خوانده‌شدن باید Crawl ممکن باشد. مسدودکردن URL در robots.txt ابزار قطعی حذف از Index نیست و می‌تواند مانع دیدن noindex شود.

Crawled – currently not indexed یعنی محتوا بی‌کیفیت است؟

نه لزوماً. یعنی Google URL را Crawl کرده اما اکنون Index نکرده است. Render ناقص، Duplicate/Canonical، Soft ۴۰۴، صفحه خالی یا هدف کم‌تمایز از علت‌های قابل بررسی‌اند. Reason واحد یا Fix تضمینی ندارد.

آیا Sitemap ایندکس را تضمین می‌کند؟

خیر. Sitemap یک Hint برای کشف و ترجیح URL است. URLهای Canonical، ۲۰۰ و مطلوب را در آن بگذارید، lastmod را فقط برای تغییر مهم درست بنویسید و Link داخلی و کیفیت صفحه را جایگزین آن ندانید.

آیا Request Indexing را چندبار بزنیم تا سریع‌تر شود؟

خیر. Google می‌گوید درخواست تکراری همان URL Crawl را سریع‌تر نمی‌کند و Quota دارد. ابتدا مانع فنی/محتوایی را رفع، Live test را پاس و یک‌بار درخواست کنید؛ برای URLهای زیاد از Sitemap و معماری Link استفاده کنید.

جمع‌بندی

حل مشکل ایندکس با تشخیص مرحله شکست آغاز می‌شود، نه با حدس. ابتدا تعیین کنید URL باید Index شود، سپس Index data و Live test را جدا بخوانید و به‌ترتیب Discovery، HTTP/Crawl، Directive، Canonical، Render، Soft ۴۰۴ و ارزش مستقل را بررسی کنید.

Not indexed برای URL تکراری یا حذف‌شده می‌تواند نتیجه سالم باشد. موفقیت یعنی صفحات مهم، Canonical و مفید شما قابل کشف و پردازش باشند و هر Regression از طریق Log، Search Console، Sitemap و Test pipeline زود آشکار شود—نه اینکه هر URL تولیدشده به هر قیمت وارد Index شود.