ایندکس در SEO چیست
برای اینکه یک صفحه بتواند در نتایج Google Search ظاهر شود، گوگل باید ابتدا URL را کشف (Discovery) کند. URL ممکن است از طریق لینک داخلی، لینک خارجی، XML Sitemap یا منابع دیگری شناخته شود. بعد Googlebot تلاش میکند صفحه را Crawl کند؛ یعنی پاسخ سرور، HTML و منابع موردنیاز را دریافت کند. اگر محتوا به JavaScript وابسته باشد، مرحله Rendering نیز اهمیت پیدا میکند.
پس از پردازش صفحه، گوگل محتوای اصلی، متادیتا، Directiveهای Robots و سیگنالهای Canonical را بررسی میکند. در این مرحله ممکن است URL وارد Index شود، ممکن است URL دیگری بهعنوان نسخه Canonical انتخاب شود، یا ممکن است صفحه فعلاً در Index نگهداری نشود. حتی عبور موفق از Crawl به معنی تضمین Index نیست.
بعد از Indexing تازه نوبت Serving و Ranking است. یعنی وقتی کاربر Query مشخصی را جستجو میکند، گوگل بین صفحات موجود در Index تصمیم میگیرد کدام نتیجه مناسبتر است. پس اگر URL Inspection نشان میدهد صفحه در Google Index وجود دارد ولی برای کلیدواژه شما دیده نمیشود، مسئله را نباید با تغییر robots.txt یا Sitemap حل کرد؛ آن مسئله بیشتر به Ranking و ارتباط صفحه با Query مربوط است.
برای درک جایگاه Indexing در معماری Technical SEO میتوانید از آموزش سئو SEO صفر تا صد استفاده کنید. این مقاله روی یک مسئله محدودتر تمرکز دارد: پیدا کردن علت ایندکس نشدن و رفع آن با ترتیب درست.
تشخیص مشکل
قبل از هر تغییری مشخص کنید با چه نوع مسئلهای روبهرو هستید. اگر کل سایت یا تعداد زیادی از URLهای مهم همزمان از Index خارج شدهاند، اولویت با مشکلات Site-wide مثل دسترسی Googlebot، تنظیم عمومی noindex، خطای DNS یا Server، تغییرات مهاجرت و تنظیمات WordPress است. اگر فقط چند صفحه یا یک الگوی مشخص مشکل دارد، بررسی باید در سطح همان URLها انجام شود.
کل سایت یا صفحه
یک URL مهم را در Google Search Console با URL Inspection بررسی کنید. اگر Search Console URL را نمیشناسد، مسیر تحقیق از Discovery شروع میشود. اگر Last Crawl وجود دارد و Fetch موفق بوده، وارد مرحله بعد میشویم. اگر تعداد زیادی URL وضعیت مشابه دارند، Page Indexing report را باز کنید و Sample URLها را مقایسه کنید تا Pattern مشترک پیدا شود.
بهجای بررسی تصادفی، URLها را گروهبندی کنید: مقالهها، برگهها، دستهها، Tagها، Productها، URLهای دارای Query String و صفحات ساختهشده توسط Plugin. اگر فقط یک گروه آسیب دیده، معمولاً تنظیم Template، Canonical، robots یا Sitemap همان گروه ارزش بررسی بیشتری از تنظیمات عمومی سایت دارد.
ایندکس یا رتبه
یکی از رایجترین خطاهای تشخیص این است که «صفحه برای کلمه X پیدا نمیشود» را مساوی «صفحه ایندکس نشده» بدانیم. وضعیت Index را از URL Inspection بگیرید، نه از جایگاه صفحه برای یک Keyword. اپراتور site: میتواند برای بررسی سریع مفید باشد، اما نتیجه آن جای اطلاعات Page-level در Search Console را نمیگیرد.
اگر URL Inspection میگوید صفحه Indexed است، وارد مسیر Indexing Troubleshooting نشوید. در چنین حالتی باید Intent، محتوا، رقابت، Internal Linking و سایر عوامل Ranking بررسی شوند. برعکس، اگر URL در Index نیست، افزایش Backlink یا تغییر Title بدون شناخت علت Indexing ممکن است مسئله اصلی را دستنخورده باقی بگذارد.
بررسی URL Inspection
URL Inspection دو دید متفاوت میدهد: اطلاعات نسخهای که Google درباره URL در Index خود دارد، و Live Test که نسخه فعلی URL را آزمایش میکند. این دو را با هم اشتباه نگیرید. ممکن است Live Test امروز سالم باشد اما آخرین نسخه ثبتشده در Index مربوط به Crawl قبلی و قبل از اصلاح شما باشد.
ویدئوی تکمیلی این بخش: ویدئوی «Getting the most out of the URL inspection tool» از کانال رسمی Google Search Central فقط Verdict سبز یا قرمز URL Inspection را نشان نمیدهد؛ Martin Splitt بخشهایی مثل View Crawled Page، Rendered HTML، HTTP Response Headers، منابع بارگذاریشده و اطلاعات Canonical را نیز بررسی میکند. این دقیقاً همان دادهای است که برای Root Cause Analysis نیاز داریم.
[PLACEHOLDER VIDEO — Getting the most out of the URL inspection tool | Google Search Central | ID: O_Of94GuC-w]
بعد از دیدن ویدئو چه چیزی یاد میگیرید؟ میتوانید بررسی کنید Google چه HTMLای دریافت کرده، پاسخ HTTP چه بوده، Canonical اعلامشده چیست و آیا منابع موردنیاز صفحه هنگام Crawl یا Render در دسترس بودهاند. این اطلاعات کمک میکند مشکل «ایندکس نشدن» را از یک حدس کلی به یک عیبیابی فنی تبدیل کنید.
در عمل، ابتدا Current Index Status را ببینید، سپس Last Crawl، Crawl Allowed، Page Fetch، Indexing Allowed و Canonical را بررسی کنید. بعد Live Test را اجرا کنید و View Tested Page را با نسخهای که کاربر در مرورگر میبیند مقایسه کنید. سالم بودن Live Test به معنی تضمین Index شدن نیست؛ Live Test برخی تصمیمهای نهایی سیستم Indexing، از جمله انتخاب Canonical یا نگهداری صفحه در Index، را پیشبینی نمیکند.
وضعیتهای سرچ کنسول
عدد بزرگ «Not indexed» بهتنهایی نشانه خرابی سایت نیست. URLهای Redirectشده، نسخههای Alternate، صفحات دارای noindex و URLهایی که عمداً نباید در نتایج باشند میتوانند کاملاً طبیعی در بخش Not indexed دیده شوند. معیار درست این است: آیا URLهایی که برای کسبوکار و کاربر مهماند و باید در Search باشند، بدون دلیل ناخواسته از Index خارج ماندهاند؟
ویدئوی رسمی این بخش: در «Help! Google Search isn’t indexing my pages» از Google Search Central، Martin Splitt وضعیت Discovered – currently not indexed را توضیح میدهد و نشان میدهد کشف URL، Crawl شدن و Index شدن سه اتفاق جدا هستند. ویدئو همچنین به نقش Googlebot، ظرفیت Crawl، لینک داخلی و کیفیت صفحات در تصمیمهای بعدی اشاره میکند.
[PLACEHOLDER VIDEO — Help! Google Search isn’t indexing my pages | Google Search Central | ID: Q5kYrmzNhcU]
چیزی که از این ویدئو میگیرید: اگر Search Console نوشته باشد Google URL را Discovered کرده، نباید فوراً نتیجه بگیرید Sitemap خراب است یا صفحه نیاز به ارسال مکرر دارد. اول باید بفهمید URL در صف Discovery/Crawl چه وضعیتی دارد و آیا الگوی سایت به گوگل دلیل کافی برای رسیدن و اولویت دادن به آن میدهد.
جدول زیر چند وضعیت پرتکرار را به شکل «معنی → اقدام» خلاصه میکند. نام دقیق Statusها ممکن است در آینده تغییر کند، اما منطق عیبیابی همچنان قابل استفاده است.
| وضعیت | معنی عملی | اقدام اصلی |
|---|---|---|
| Discovered – currently not indexed | URL شناخته شده ولی هنوز Crawl نشده است | Discovery، لینک داخلی، Sitemap و دسترسی Crawl را بررسی کنید |
| Crawled – currently not indexed | صفحه Crawl شده ولی فعلاً در Index نیست | Canonical، تکرار، Intent و ارزش مستقل صفحه را بررسی کنید |
| Page with redirect | URL به آدرس دیگری منتقل میشود | اگر Redirect عمدی است مقصد نهایی را بررسی کنید |
| Excluded by noindex | گوگل Directive منع Index دیده است | اگر URL باید Index شود منبع noindex را حذف کنید |
| Blocked by robots.txt | Crawl URL محدود شده است | در صورت نیاز Rule مربوط را اصلاح کنید |
| Duplicate / Alternate | URL دیگری بهعنوان نماینده انتخاب شده است | Canonical، Redirect، Sitemap و لینک داخلی را همسو کنید |
| Soft 404 / 404 | صفحه مفقود است یا محتوای آن شبیه صفحه مفقود تشخیص داده شده | Status و محتوای واقعی صفحه را اصلاح کنید |
| Server error (5xx) | سرور پاسخ معتبر به Googlebot نداده است | Host، PHP، CDN، WAF و Server Log را بررسی کنید |
Discovered و Crawled
Discovered – currently not indexed یعنی URL برای گوگل ناشناخته نیست، اما آخرین وضعیت گزارششده نشان میدهد هنوز Crawl انجام نشده است. اگر این وضعیت فقط برای تعداد کمی صفحه تازه دیده میشود، ممکن است صرفاً زمان لازم باشد. اگر برای تعداد زیادی URL مهم و قدیمی تکرار میشود، باید معماری Discovery، لینک داخلی، تعداد URLهای کمارزش، سلامت سرور و الگوهای Crawl را بررسی کنید.
Crawled – currently not indexed یک مرحله جلوتر است. در اینجا Googlebot صفحه را دریافت کرده اما صفحه فعلاً در Index نیست. بنابراین تکرار ارسال Sitemap یا تلاش برای «وادار کردن» Googlebot به Crawl دوباره، اولین کار منطقی نیست. سؤال مهمتر این است که آیا صفحه Canonical مناسب، محتوای مستقل، هدف روشن و جایگاه مشخص در معماری سایت دارد.
Redirect
`Page with redirect` لزوماً Error نیست. اگر URL قدیمی مقاله به نسخه جدید 301 شده است، طبیعی است که مبدأ در Index نماند و مقصد نهایی جای آن را بگیرد. مشکل وقتی است که URLی که باید خودش Index شود ناخواسته Redirect شده، مقصد اشتباه دارد، چند Redirect پشتسرهم ایجاد شده یا Loop مانع رسیدن Googlebot به صفحه نهایی میشود.
در چنین وضعیتی ابتدا Redirect Path را بررسی کنید. Sitemap و لینکهای داخلی باید تا حد امکان مستقیماً به URL نهایی اشاره کنند. نگه داشتن تعداد زیادی URL Redirectشده در Sitemap یا لینکهای داخلی، هم سیگنال معماری را مبهم میکند و هم Crawl غیرضروری میسازد.
Duplicate و Canonical
وقتی Search Console وضعیت Duplicate یا Alternate نشان میدهد، ابتدا تعیین کنید آیا انتخاب URL دیگر منطقی است. اگر مثلاً نسخه پارامتردار همان محتوا به URL تمیز Canonical شده، ممکن است همه چیز درست باشد. اگر Google-selected canonical با URL موردنظر شما فرق دارد، باید دنبال تضاد بین سیگنالهای سایت بگردید.
Canonical یک فرمان اجباری نیست؛ یک سیگنال قوی است که باید با Redirect، Internal Link، Sitemap و ساختار URL هماهنگ باشد. اگر صفحه A در Canonical خودش را نسخه اصلی اعلام میکند اما تمام لینکهای سایت به B میروند و Sitemap هم B را معرفی میکند، این تناقض میتواند انتخاب گوگل را تغییر دهد.
وضعیتهای فنی
در Statusهایی مثل noindex، robots.txt، 404، Soft 404 و 5xx باید ابتدا همان مانع مشخص را برطرف کنید. اگر صفحه 5xx میدهد، کیفیت محتوا در اولویت نیست. اگر noindex ناخواسته وجود دارد، Link Building مشکل را حل نمیکند. اگر Redirect اشتباه است، Request Indexing روی مبدأ نتیجه موردنظر را ایجاد نمیکند.
Soft 404 را هم با 404 واقعی اشتباه نگیرید. گاهی Server کد 200 میدهد اما محتوای صفحه عملاً پیام «یافت نشد» یا یک خروجی بسیار کمارزش است. اگر صفحه باید وجود داشته باشد، محتوا و Response آن را اصلاح کنید؛ اگر واقعاً حذف شده، Status معنیدار 404 یا 410 میتواند وضعیت را روشنتر کند.
موانع دسترسی
اگر Googlebot نتواند URL را درست دریافت کند، هنوز برای تحلیل کیفیت محتوا زود است. در مرحله Access باید ببینید robots.txt، meta robots، X-Robots-Tag، پاسخهای HTTP، WAF، CDN، Login، Rate Limit یا خطای شبکه جلوی Crawl و پردازش را گرفتهاند یا نه.
robots و noindex
یکی از مهمترین تفاوتها این است که robots.txt ابزار کنترل Crawl است، نه روش مطمئن برای جلوگیری از Index شدن یک صفحه HTML. وقتی URL را در robots.txt مسدود میکنید، Googlebot ممکن است نتواند محتوای صفحه را بخواند؛ اما خود URL همچنان میتواند از طریق لینکهای دیگر شناخته شود. اگر هدف این است که صفحه در Search Index نباشد، باید از روش مناسب مثل `noindex` استفاده شود و URL برای Googlebot قابل Crawl باشد تا Directive دیده شود.
نمونه معمول meta robots برای جلوگیری از Index شدن یک صفحه HTML:
<meta name="robots" content="noindex">اگر صفحه مهمی ایندکس نمیشود، Source نهایی را بررسی کنید و مطمئن شوید چنین Tagی ناخواسته توسط قالب، افزونه SEO یا تنظیمات CMS اضافه نشده است. برای فایلهای غیر HTML یا زمانی که Directive از Header ارسال میشود، `X-Robots-Tag` نیز میتواند همین اثر را داشته باشد:
X-Robots-Tag: noindexنکته مهم این است که Googlebot باید بتواند این noindex را ببیند. اگر همان URL همزمان در robots.txt مسدود باشد، Crawl انجام نمیشود و Directive موجود در HTML یا Header قابل مشاهده نیست. بنابراین ترکیب robots.txt و noindex را بدون هدف مشخص بهکار نبرید.
HTTP و سرور
صفحهای که باید ایندکس شود باید پاسخ معناداری به Googlebot بدهد. 301 یا 308 برای انتقال دائمی میتواند کاملاً صحیح باشد؛ 404 و 410 برای محتوای حذفشده طبیعیاند؛ اما 5xx، Timeout، DNS failure، Redirect Loop و پاسخهای متناوب میتوانند Crawl را مختل کنند. اینکه صفحه برای مرورگر شما باز میشود تضمین نمیکند Googlebot همیشه همان پاسخ را دریافت میکند.
در مشکلات Site-wide یا متناوب، Server Logها ارزش زیادی دارند. زمان پاسخ، کدهای 5xx، درخواستهای Googlebot، محدودیت Rate، Ruleهای WAF و رفتار CDN را بررسی کنید. اگر مشکل از Plugin، PHP یا پیکربندی WordPress ایجاد شده، راهنمای رفع خطاهای وردپرس میتواند برای عیبیابی لایه فنی مکمل این مرحله باشد.
رندر جاوااسکریپت
Google Search میتواند JavaScript را پردازش کند، اما اجرای JavaScript یک لایه اضافی به مسیر Crawl و Index اضافه میکند. اگر HTML اولیه محتوای اصلی را ندارد، API موردنیاز خطا میدهد، فایل JavaScript برای Googlebot مسدود است یا متن اصلی فقط بعد از تعامل کاربر ساخته میشود، ممکن است Rendered HTML با چیزی که شما در مرورگر میبینید متفاوت باشد.
در URL Inspection خروجی Rendered HTML را بررسی کنید. عنوان، متن اصلی، لینکهای داخلی و Canonical باید در نسخهای که Google میتواند پردازش کند قابل مشاهده باشند. در سایت WordPress معمولاً بخش زیادی از محتوای اصلی Server-side تولید میشود، اما Page Builder، Lazy Rendering، Optimization Plugin یا Scriptهای شخص ثالث میتوانند شرایط را تغییر دهند.
کنونیکال و تکرار
وجود چند URL مشابه در وب طبیعی است و گوگل برای مدیریت آنها یک URL را بهعنوان نماینده یا Canonical انتخاب میکند. Duplicate بودن بهتنهایی به معنی پنالتی نیست. مشکل زمانی ایجاد میشود که صفحهای که باید مستقل باشد، عملاً نسخهای شبیه URL دیگر باشد یا سیگنالهای سایت درباره نسخه اصلی با هم تناقض داشته باشند.
انتخاب Canonical
`rel=”canonical”` به Google ترجیح شما را اعلام میکند، اما انتخاب نهایی را تحمیل نمیکند. اگر Self-canonical دارید ولی Internal Linkها، Redirectها و Sitemap نسخه دیگری را تقویت میکنند، Google-selected canonical ممکن است متفاوت باشد. همینطور اگر محتوای دو صفحه تقریباً یکسان باشد، صرف تغییر Tag لزوماً باعث نمیشود هر دو مستقل Index شوند.
برای صفحهای که باید نسخه اصلی خودش باشد، نمونه استاندارد Canonical به شکل زیر است:
<link rel="canonical" href="https://example.com/final-page">بعد از دیدن اختلاف Canonical در Search Console، چهار چیز را کنار هم بررسی کنید: تگ Canonical، Redirectها، URLهای موجود در Sitemap و مقصد لینکهای داخلی. بهترین وضعیت زمانی است که همه این سیگنالها یک URL واحد را تقویت کنند.
نسخههای URL
یک محتوا ممکن است از چند مسیر قابل دسترسی باشد: HTTP و HTTPS، www و non-www، با یا بدون trailing slash، Query Parameterها، Tracking URLها یا مسیرهای قدیمی. اگر همه نسخهها بدون کنترل وارد لینک داخلی و Sitemap شوند، Crawl و Canonicalization پیچیده میشود.
یک نسخه نهایی را بهعنوان URL اصلی انتخاب کنید. نسخههای منسوخ را در صورت نیاز با Redirect دائمی به مقصد درست منتقل کنید، Canonical را با همان مقصد هماهنگ نگه دارید و لینک داخلی را مستقیم به URL نهایی بدهید. این رویکرد از ایجاد Redirect chain و سیگنالهای متناقض جلوگیری میکند.
کشف و خزش
گاهی URL هیچ مانع فنی ندارد اما در ساختار سایت کمرنگ است. اگر صفحه مهم فقط در Sitemap باشد و هیچ لینک Contextual از صفحات دیگر نگیرد، Google همچنان میتواند آن را پیدا کند، اما شما یک مسیر طبیعی Discovery و درک موضوعی را از دست دادهاید. Sitemap و Internal Linking باید یکدیگر را تکمیل کنند.
سایت مپ ( نقشه سایت )
XML Sitemap برای معرفی URLهای مهم به موتور جستجو مفید است، اما وجود URL در Sitemap تضمین Crawl یا Index نیست. اگر Sitemap با وضعیت Success ثبت شده و صفحه همچنان Not indexed است، ارسال دوباره همان فایل معمولاً اطلاعات جدیدی به گوگل نمیدهد. علت Page-level را از URL Inspection پیدا کنید.
در Sitemap اصلی، URLهای Canonical و قابل Index را نگه دارید. URLهای 404، noindex، Redirect و نسخههای تکراری که نمیخواهید در Search باشند بهتر است بهعنوان مقصد اصلی معرفی نشوند. اگر `lastmod` دارید، تاریخ را با تغییر معنادار محتوا هماهنگ کنید؛ تغییر مصنوعی آن برای همه URLها ارزش تشخیصی Sitemap را کم میکند.
لینک داخلی
لینک داخلی به Googlebot مسیر Discovery میدهد و به موتور جستجو کمک میکند رابطه بین صفحات را بفهمد. مقاله مهم باید از صفحه یا Cluster مرتبط لینک داشته باشد، نه اینکه فقط از طریق جستجوی داخلی سایت قابل دسترسی باشد. در DJH.ir، ارتباط این موضوع با Pillar آموزش سئو نمونه واضح Parent → Cluster است.
Orphan Pageها، لینکهای شکسته، لینکهای ساختهشده به شکلی که Crawler نتواند مقصد را از یک عنصر استاندارد لینک استخراج کند و عمق بیشازحد صفحه را بررسی کنید. Anchor Text نیز باید توضیح دهد مقصد درباره چیست؛ لینکهای مبهم و تکراری ارزش ساختاری کمتری دارند.
Crawl Budget
Crawl Budget وجود دارد، اما برای هر سایت کوچک یا متوسط اولین علت ایندکس نشدن نیست. قبل از ورود به بحث Crawl Budget، موانع سادهتر مثل robots.txt، Server Error، Internal Link، Sitemap، URLهای تکراری و کیفیت Inventory سایت را بررسی کنید. مدیریت Crawl Budget بیشتر برای سایتهای بسیار بزرگ، سریعالتغییر یا دارای حجم بالای URLهای کمارزش مهم میشود.
در سایتهای بزرگ، Faceted Navigation، پارامترهای بیپایان، صفحات فیلتر، تقویمهای مولد URL و Redirect chain میتوانند Crawl را روی بخشهای کماهمیت مصرف کنند. هدف این نیست که با ترفند خاص «بودجه» را زیاد کنیم؛ هدف کاهش Crawl Waste و روشن کردن مسیر URLهای مهم است.
کیفیت صفحه
وقتی صفحه Crawl میشود، Response سالم دارد، noindex ندارد و Canonical هم منطقی است، هنوز تضمینی برای Index وجود ندارد. در این مرحله سؤال اصلی از «کدام تنظیم خراب است؟» به «آیا این URL ارزش و نقش مستقلی دارد؟» تغییر میکند. این بخش مخصوصاً برای Crawled – currently not indexed مهم است.
محتوای تکراری
تکرار فقط Copy/Paste کامل نیست. صفحات شهری که فقط نام شهر عوض شده، آرشیوهای بسیار شبیه، Tagهای کممحتوا، Variantهای محصول، صفحات فیلتر و مقالههایی که همان Intent را با تفاوت ناچیز پوشش میدهند ممکن است ارزش مستقل محدودی داشته باشند. در چنین وضعیتی تلاش برای Index کردن تمام URLها لزوماً تصمیم درستی نیست.
اگر دو صفحه تقریباً یک سؤال را جواب میدهند، مالکیت موضوعی را روشن کنید. ممکن است ادغام محتوا و Redirect یک صفحه ضعیفتر به صفحه اصلی، نتیجه معماری بهتری از نگهداری دو URL مشابه ایجاد کند. اگر هر دو باید باقی بمانند، تفاوت Intent و ارزش آنها باید در خود محتوا و لینکهای داخلی قابل فهم باشد.
ارزش مستقل
بهجای توصیه کلی «محتوای باکیفیت بنویس»، چند تست مشخص انجام دهید. آیا صفحه یک نیاز واضح را کامل پاسخ میدهد؟ آیا اطلاعاتی دارد که نسخههای دیگر سایت ندارند؟ آیا Title، Headingها و متن اصلی حول یک Intent واحد هستند؟ آیا کاربر بدون Login، Pop-up اجباری یا تعامل پیچیده به محتوای اصلی میرسد؟ آیا صفحه فقط برای گرفتن یک Keyword ساخته شده یا واقعاً دلیل مستقلی برای وجود دارد؟
برای صفحهای که Crawl شده ولی Index نشده، افزایش تعداد کلمات بهتنهایی درمان نیست. بهبود ممکن است شامل ادغام صفحات، افزودن توضیح فنی واقعی، مثال، داده معتبر، پاسخ دقیقتر به Intent، حذف بخشهای تکراری، اصلاح Internal Linking یا حتی تصمیم به noindex کردن صفحهای باشد که ارزش حضور مستقل در Search ندارد.
مشکلات وردپرس
در WordPress چند لایه میتوانند Indexability را تغییر دهند: تنظیمات هسته، SEO Plugin، قالب، Pluginهای Staging و Maintenance، Cache، CDN و Headerهای وبسرور. به همین دلیل باید خروجی نهایی URL را بررسی کنید، نه فقط چیزی را که در صفحه ویرایش نوشته میبینید.
تنظیمات وردپرس
در Settings → Reading گزینه Search Engine Visibility را بررسی کنید. اگر «Discourage search engines from indexing this site» روی سایت Production فعال مانده باشد، WordPress میتواند برای موتورهای جستجو Directive منع Index تولید کند. این مورد مخصوصاً بعد از انتقال Staging به دامنه اصلی ارزش بررسی دارد.
بعد سراغ تنظیمات SEO Plugin بروید. Indexability نوشته، برگه، Category، Tag و Custom Post Type را جداگانه بررسی کنید. اگر همه URLهای یک Post Type مشکل مشابه دارند، احتمال خطای تنظیم گروهی بیشتر است. در Source نهایی نیز meta robots و Canonical را کنترل کنید. برای مبانی مدیریت CMS میتوانید آموزش وردپرس صفر تا صد را ببینید.
افزونه و کش
ممکن است تنظیم را اصلاح کرده باشید اما Cache یا CDN هنوز HTML یا Header قدیمی را تحویل دهد. مثال رایج، حذف noindex از محیط Staging است درحالیکه نسخه Cacheشده همچنان همان Directive را برای بعضی Requestها نگه داشته است. بعد از تغییر، Cache مرتبط را پاک کنید و Response واقعی را دوباره با Live Test و Header inspection بسنجید.
مسیر سریع WordPress را میتوان اینطور خلاصه کرد:
| بررسی | مشکل محتمل | اقدام |
|---|---|---|
| Search Engine Visibility | noindex عمومی | تنظیم Production را اصلاح و خروجی نهایی را تست کنید |
| SEO Plugin | noindex یا Canonical اشتباه | تنظیم URL و Post Type را بررسی کنید |
| XML Sitemap | URL حذف یا نسخه اشتباه | URLهای Canonical قابل Index را نگه دارید |
| Cache / CDN | HTML یا Header قدیمی | Cache را پاک و Response را دوباره بررسی کنید |
| Staging | Rule محیط تست روی Production | تنظیمات محیطها را جدا کنید |
| Plugin / Theme | تغییر Robots، Canonical یا Status | Conflict را در محیط امن عیبیابی کنید |
اگر تغییر Plugin یا Theme باعث 5xx، Redirect یا رفتار غیرمنتظره شده، تست را روی Staging انجام دهید و قبل از تغییرات جدی Backup داشته باشید. برای خطاهای عمومی این لایه، رفع خطاهای وردپرس مسیر جداگانهای برای Troubleshooting فنی ارائه میدهد.
مسیر رفع مشکل
بعد از شناخت علتها، مهمترین بخش این است که ترتیب اصلاح را حفظ کنید. مدل پنجدروازهای زیر کمک میکند از تغییرات پراکنده جلوگیری کنید: ابتدا Discovery، سپس Access، بعد Render، سپس Eligibility و در پایان Selection. در هر مرحله فقط وقتی جلو بروید که مرحله قبلی سالم باشد.
ویدئوی عملی این بخش: «Crawled – Currently Not Indexed in Google Search Console. Do you PANIC or ignore?» از Olga Zarr روی یک نکته مهم تمرکز دارد: همه URLهای Not Indexed نیاز به Fix ندارند. در Audit باید Trend و Sample URLها را ببینید، مشخص کنید کدام URL واقعاً باید Index شود و سپس Pattern مشترک صفحات مهم را پیدا کنید. ویدئو همچنین نشان میدهد ابزارهایی مثل Screaming Frog چگونه میتوانند بررسی تعداد زیادی URL را منظمتر کنند.
[PLACEHOLDER VIDEO — Crawled – Currently Not Indexed in Google Search Console. Do you PANIC or ignore? | Olga Zarr SEO | ID: hHs-dXmJPjA]
بعد از دیدن ویدئو چه چیزی بهتر میشود؟ بهجای اینکه هر URL موجود در گزارش را Error بدانید، میتوانید URLهای مهم را از صفحات آرشیوی، پارامتری، کمارزش یا صفحاتی که طبیعی است Index نشوند جدا کنید. این نگاه باعث میشود Root Cause را روی Pattern واقعی پیدا کنید و از Request Indexing تکراری برای URLهای نامناسب دور بمانید.
پنج مرحله تشخیص
این جدول مسیر اصلی عیبیابی را در یک نگاه نشان میدهد:
| مرحله | تست اصلی | قدم بعدی |
|---|---|---|
| 1. Discovery | URL شناخته شده؟ لینک داخلی و Sitemap دارد؟ | مسیر کشف URL را اصلاح کنید |
| 2. Access | robots، HTTP، WAF و Fetch سالماند؟ | مانع Crawl یا Server Error را برطرف کنید |
| 3. Render | Rendered HTML محتوای اصلی را دارد؟ | JavaScript و منابع مسدود را اصلاح کنید |
| 4. Eligibility | noindex، Canonical و Redirect درستاند؟ | Directiveها و URL اصلی را همسو کنید |
| 5. Selection | صفحه Crawl شده ولی Index نشده؟ | تکرار، Intent و ارزش مستقل را بررسی کنید |
سناریو ۱: مقاله جدید منتشر شده ولی URL Inspection هیچ Last Crawl ندارد. اول لینک داخلی، حضور Canonical URL در Sitemap، robots.txt و دسترسی Server را بررسی کنید. اگر URL مهم است و Live Test سالم است، Request Indexing میتواند برای همان صفحه استفاده شود؛ اما اگر دهها صفحه Orphan دارید، مشکل اصلی معماری Discovery است.
سناریو ۲: Last Crawl ثبت شده، Page Fetch موفق است و Status روی Crawled – currently not indexed قرار دارد. در این مرحله تکرار Sitemap یا پاک کردن Cache اولین پاسخ نیست. Google-selected canonical، شباهت با صفحات دیگر، Intent، Topic Ownership و ارزش مستقل URL را بررسی کنید.
سناریو ۳: Search Console وضعیت Page with redirect نشان میدهد. اگر URL قدیمی عمداً با 301 به URL نهایی منتقل شده، Status طبیعی است. مقصد نهایی باید در Sitemap و Internal Linkها استفاده شود. اگر صفحه اصلی مقاله ناخواسته Redirect میشود، Root Cause در Ruleهای Redirect، Plugin یا Server configuration است.
اولویت اصلاح
برای بیشتر سایتها این ترتیب عملی است: Server و دسترسی → robots/noindex → Redirect و Canonical → Sitemap و Internal Linking → Rendering → کیفیت و ارزش مستقل. این ترتیب باعث میشود برای صفحهای که 5xx دارد وقت خود را صرف بازنویسی محتوا نکنید یا برای URL دارای noindex سراغ Link Building نروید.
تغییرات Site-wide را یکباره انجام ندهید. اگر همزمان robots.txt، Cache، SEO Plugin، Redirect Rules و Canonical را عوض کنید، بعداً نمیدانید کدام تغییر نتیجه داده یا مشکل جدید ساخته است. هر اصلاح باید قابل اندازهگیری و در صورت نیاز قابل بازگشت باشد.
بعد از اصلاح
رفع علت در سایت به معنی این نیست که Google همان لحظه نسخه جدید را دیده است. باید بین «نسخه فعلی سایت» و «آخرین نسخهای که Google Crawl و پردازش کرده» تفاوت بگذارید. برای URL مهم، Live Test نشان میدهد اصلاح فعلی از نظر دسترسی و بخشی از شرایط Indexability چگونه دیده میشود؛ سپس باید منتظر Recrawl و پردازش بعدی باشید.
درخواست ایندکس
بعد از اصلاح یک URL مهم، Test Live URL را اجرا کنید. اگر Fetch، Indexing Allowed، محتوای Renderشده و Canonical با انتظار شما سازگار است، Request Indexing میتواند درخواست Crawl مجدد را ثبت کند. این درخواست تضمین نمیکند صفحه فوراً یا اصلاً وارد Index شود، و تکرار Request برای همان URL فرآیند را سریعتر نمیکند.
برای تعداد زیاد URL، Sitemap و معماری داخلی ابزار مقیاسپذیرتری هستند. اگر یک Template اشتباه روی صدها صفحه noindex ایجاد کرده، مشکل را در Template رفع کنید؛ سپس با Page Indexing و Sample URLها روند تغییر را بررسی کنید. ارسال دستی صدها URL راهحل ریشهای نیست.
بررسی نتیجه
بعد از Fix سه داده را جدا ببینید: نتیجه Live Test، Last Crawl و Index Status. ممکن است Live Test سالم شده باشد اما گزارش Index هنوز وضعیت قبلی را نشان دهد، چون Recrawl و Reprocessing انجام نشده است. همچنین گزارشهای Aggregated میتوانند با وضعیت لحظهای یک URL تفاوت زمانی داشته باشند؛ برای URL مشخص، URL Inspection مرجع تشخیصی مناسبتری است.
برای Crawl و Index زمان تضمینشدهای وجود ندارد. بهجای وعده «چند ساعت» یا «یک روز»، صحت اصلاح را تأیید و روند را مانیتور کنید. اگر Pattern مشکل بعد از Recrawl همچنان ادامه دارد، دوباره از مرحله مناسب وارد شوید؛ مثلاً برای 5xx سراغ Server Log و برای Crawled – currently not indexed سراغ Canonical، تکرار و ارزش صفحه بروید.
اگر Indexing فقط یکی از نشانههای یک مشکل بزرگتر در معماری و Technical SEO سایت است، صفحه خدمات سئو و دیجیتال مارکتینگ مسیر بررسی تخصصیتر را معرفی میکند. اگر مشکل شما بیشتر به Performance و تجربه کاربر مربوط است، تأثیر Core Web Vitals بر عملکرد سایت و SEO موضوع را جداگانه پوشش میدهد.
نتیجه عملی: برای رفع ایندکس نشدن سایت در گوگل از «ارسال دوباره» شروع نکنید؛ از تشخیص شروع کنید. اگر Google URL را پیدا نکرده، Discovery را حل کنید. اگر Crawl نمیشود، Access را اصلاح کنید. اگر Render ناقص است، خروجی نهایی را درست کنید. اگر noindex، Redirect یا Canonical مانع است، Eligibility را اصلاح کنید. و اگر صفحه Crawl شده ولی در Index نیست، بهجای تغییر تصادفی تنظیمات، ارزش مستقل و نقش آن URL را بررسی کنید.
سوالات متداول
چرا سایت در گوگل ایندکس نمیشود؟
علت میتواند در Discovery، Crawl، Rendering، noindex، Redirect، Canonical، Server Error یا تصمیم Google پس از پردازش صفحه باشد. برای URL مشخص، URL Inspection بهترین نقطه شروع عیبیابی است.
تفاوت Crawl و Index چیست؟
Crawl یعنی Googlebot صفحه را دریافت و بررسی میکند؛ Index یعنی Google بعد از پردازش تصمیم میگیرد اطلاعات آن URL را در Index نگه دارد. هر صفحه Crawlشده الزاماً Index نمیشود.
چرا صفحه Crawl شده ولی Index نشده است؟
در وضعیت Crawled – currently not indexed، Google صفحه را Crawl کرده ولی فعلاً آن را در Index نگه نداشته است. Canonical، شباهت با صفحات دیگر، Intent و ارزش مستقل URL را بررسی کنید.
Discovered – Currently Not Indexed یعنی چه؟
یعنی Google URL را میشناسد اما طبق آخرین وضعیت گزارششده هنوز آن را Crawl نکرده است. لینک داخلی، Sitemap، دسترسی Server و الگوی Discovery/Crawl را بررسی کنید.
آیا Sitemap ایندکس را تضمین میکند؟
خیر. Sitemap به Google در کشف URLها کمک میکند، اما تضمینی برای Crawl یا Index شدن همه URLهای داخل فایل نیست.
آیا robots.txt صفحه را از Index حذف میکند؟
robots.txt عمدتاً Crawl را کنترل میکند و روش مطمئن برای خارج نگه داشتن صفحه HTML از Google Index نیست. برای جلوگیری از Index معمولاً noindex یا محدودیت دسترسی مناسبتر است.
Page with Redirect همیشه خطاست؟
خیر. اگر URL قدیمی عمداً به نسخه جدید Redirect شده باشد، Index نشدن مبدأ طبیعی است. مشکل زمانی است که Redirect ناخواسته، مقصد اشتباه، Loop یا Chain ایجاد شده باشد.
چرا گوگل Canonical دیگری انتخاب میکند؟
Canonical اعلامشده فقط یکی از سیگنالهاست. اگر Redirect، Sitemap، Internal Link یا شباهت محتوا URL دیگری را تقویت کند، Google میتواند Canonical متفاوتی انتخاب کند.
آیا ایندکس نشدن یعنی سایت پنالتی شده است؟
خیر. بیشتر مشکلات Indexing به Discovery، دسترسی فنی، Canonical، تکرار یا انتخاب Index مربوطاند. بدون شواهد مشخص نباید ایندکس نشدن را به Manual Action یا پنالتی نسبت داد.
بعد از Request Indexing چقدر باید صبر کنیم؟
زمان ثابتی وجود ندارد و Crawl یا Reindex میتواند چند روز تا چند هفته طول بکشد. Request Indexing نیز تضمین ورود صفحه به Index نیست؛ رفع علت اصلی از تکرار درخواست مهمتر است.
مطالب مرتبط:
- آموزش سئو SEO صفر تا صد
- بررسی تاثیر Core Web Vitals بر عملکرد سایت و SEO
- آموزش وردپرس صفر تا صد
- رفع خطاهای وردپرس
- آموزش Google Search Console از صفر تا صد
- رفع خطای Crawled – Currently Not Indexed
- رفع خطای Discovered – Currently Not Indexed
- آموزش Canonical در سئو
- آموزش Sitemap XML
