وقتی یک صفحه در نتایج گوگل دیده نمی‌شود، تغییرات جدید آن وارد نتایج جست‌وجو نمی‌شود یا با افت ناگهانی نمایش روبه‌رو می‌شود، اولین واکنش بسیاری از مدیران سایت کلیک‌کردن روی گزینه Request Indexing است. اما Request Indexing ابزار عیب‌یابی نیست. این گزینه نمی‌تواند مشکلاتی مانند مسدودبودن خزش، وجود تگ noindex، انتخاب Canonical متفاوت، خطای دریافت صفحه یا ناقص‌بودن محتوای Render شده را برطرف کند.

درواقع ابزار URL Inspection در Google Search Console به شما کمک می‌کند وضعیت یک URL مشخص را از نگاه گوگل بررسی کنید و بفهمید مشکل صفحه دقیقاً در کدام مرحله قرار دارد.

با استفاده از URL Inspection می‌توانید به این سؤال‌ها پاسخ دهید:

• آیا URL در ایندکس گوگل قرار دارد؟
• گوگل آخرین بار چه زمانی صفحه را Crawl کرده است؟
• آیا Googlebot اجازه دسترسی به صفحه را داشته است؟
• آیا دریافت صفحه با موفقیت انجام شده است؟
• آیا Canonical اعلام‌شده با Canonical انتخاب‌شده توسط گوگل یکسان است؟
• آیا نسخه فعلی صفحه برای گوگل قابل دسترسی و Renderشدن است؟
• آیا پس از اصلاح صفحه، زمان مناسبی برای Request Indexing رسیده است؟

URL Inspection چیست؟

URL Inspection یکی از ابزارهای اصلی Google Search Console برای بررسی یک صفحه مشخص است. این ابزار به شما نشان می‌دهد گوگل درباره URL موردنظر چه اطلاعاتی دارد و نسخه فعلی آن URL در یک آزمایش زنده چگونه در اختیار Googlebot قرار می‌گیرد.

به زبان ساده، URL Inspection دو سؤال متفاوت را پاسخ می‌دهد:

گوگل درباره نسخه قبلی این صفحه چه می‌داند؟

این اطلاعات ازGoogle Index بازیابی می‌شود و نتیجه آخرین Crawl و پردازش ثبت‌شده گوگل را نشان می‌دهد.

اگر گوگل همین حالا صفحه را بررسی کند، چه چیزی می‌بیند؟

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

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

چه زمانی باید از URL Inspection استفاده کنیم؟

URL Inspection برای تحلیل کل سایت طراحی نشده است. اگر صدها یا هزاران صفحه وضعیت مشابهی دارند، بهتر است ابتدا گزارش‌های Page Indexing، Sitemap و Crawl Stats را بررسی کنید. این ابزار زمانی بیشترین ارزش را دارد که بخواهید یک URL مشخص را با جزئیات بررسی کنید؛ برای مثال:

• مقاله یا لندینگ جدیدی منتشر کرده‌اید و می‌خواهید دسترسی گوگل را بررسی کنید.
• صفحه مهمی در نتایج گوگل دیده نمی‌شود.
• محتوای صفحه را تغییر داده‌اید، اما نسخه قبلی هنوز در نتایج نمایش داده می‌شود.
• URL در وضعیت Crawled – currently not indexed قرار گرفته است.
• URL در وضعیت Discovered – currently not indexed قرار دارد.
• گوگل Canonical دیگری برای صفحه انتخاب کرده است.
• صفحه با JavaScript ساخته شده و درباره Rendering آن تردید دارید.
• robots.txt، Redirect، Canonical یا تگ noindex را اصلاح کرده‌اید.
• یک خطای سرور یا اختلال زیرساختی برطرف شده است.
• Structured Data یا محتوای اصلی در نسخه Renderشده دیده نمی‌شود.
• می‌خواهید پس از رفع مشکل، درخواست Crawl مجدد ثبت کنید.

URL Inspection چه کاری انجام نمی‌دهد؟

URL Inspection به‌تنهایی مشخص نمی‌کند چرا یک محتوا از نظر کیفیت برای ایندکس یا رتبه‌گرفتن مناسب نیست. همچنین تضمین نمی‌کند که URL پس از Request Indexing وارد ایندکس شود. این ابزار اطلاعات فنی و وضعیت ثبت‌شده URL را نشان می‌دهد؛ اما تحلیل کیفیت محتوا، Search Intent، لینک‌سازی داخلی، هم‌پوشانی صفحات، Cannibalization و ارزش مستقل URL همچنان به بررسی سئو نیاز دارد.

چگونه یک URL را در سرچ کنسول بررسی کنیم؟

ابتدا وارد Property مربوط به سایت در Google Search Console شوید. سپس یکی از این دو مسیر را انتخاب کنید:

1. URL کامل صفحه را در نوار بالای Search Console وارد کنید.
2. از منوی سمت چپ وارد بخش URL Inspection شوید و URL را در نوار بررسی قرار دهید.

URL باید متعلق به همان Property باشد. برای مثال، اگر Property فقط نسخه https://www.example.com/ را پوشش می‌دهد، ممکن است URL نسخه بدون www یا یک Subdomain دیگر در همان Property قابل بررسی نباشد. پس از واردکردن URL، ابتدا پیام Retrieving data from Google Indexنمایش داده می‌شود:

در این مرحله Search Console نسخه زنده صفحه را آزمایش نمی‌کند؛ بلکه اطلاعات موجود در Google Index را بازیابی می‌کند. نتیجه معمولاً در یکی از دو حالت کلی نمایش داده می‌شود:

• URL is on Google
• URL is not on Google

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

وضعیت URL is on Google به چه معناست؟

این پیام معمولاً یعنی URL در ایندکس گوگل قرار دارد و از نظر فنی می‌تواند در نتایج جست‌وجو نمایش داده شود.

اما این وضعیت به این معنا نیست که:

• URL حتماً برای عبارت موردنظر شما رتبه دارد.
• صفحه در تمام جست‌وجوها نمایش داده می‌شود.
• آخرین تغییرات صفحه وارد ایندکس شده‌اند.
• نسخه Canonical دقیقاً همان URL بررسی‌شده است.
• محتوای صفحه بدون مشکل Render شده است.
• صفحه از نظر کیفیت، تجربه کاربری یا Core Web Vitals وضعیت مناسبی دارد.

بعد از مشاهده این وضعیت، بخش‌های Page Indexing، Last Crawl و Canonical را بررسی کنید.

اگر صفحه ایندکس شده، چرا در نتایج پیدایش نمی‌کنم؟

احتمال‌های مختلفی وجود دارد:

• صفحه برای Query موردنظر رتبه کافی ندارد.
• گوگل URL دیگری را به‌عنوان Canonical نمایش می‌دهد.
• نتایج بر اساس موقعیت، زبان، دستگاه یا سابقه جست‌وجو متفاوت‌اند.
• تغییرات اخیر هنوز وارد نسخه ایندکس‌شده نشده‌اند.
• صفحه برای جست‌وجوی متفاوتی مرتبط شناخته شده است.
• محتوا با صفحات قوی‌تر سایت یا رقبا رقابت می‌کند.

URL Inspection ابزار بررسی وضعیت Index یک URL است و جایگزین گزارش Performance، تحلیل Queryها و بررسی رتبه نیست.

وضعیت URL is not on Google به چه معناست؟

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

علت آن می‌تواند کاملاً طبیعی یا نشانه یک مشکل باشد:

• صفحه تازه منتشر شده و هنوز Crawl نشده است.
• URL با noindex از ایندکس خارج شده است.
• robots.txt مانع Crawl شده است.
• صفحه Redirect می‌شود.
• پاسخ سرور خطا دارد.
• URL نسخه تکراری صفحه دیگری است.
• گوگل Canonical دیگری انتخاب کرده است.
• صفحه Crawl شده اما برای ایندکس انتخاب نشده است.
• URL پاسخ 404 یا 410 دارد.
• Googlebot هنوز تغییرات جدید را مشاهده نکرده است.

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

تفاوت نسخه ایندکس‌شده با Test Live URL

این مهم‌ترین مفهومی است که هنگام کار با URL Inspection باید درک کنید.

نسخه ایندکس‌شده

نتیجه اولیه URL Inspection اطلاعات آخرین نسخه‌ای را نشان می‌دهد که گوگل درباره URL پردازش و ذخیره کرده است.

این بخش ممکن است شامل اطلاعات زیر باشد:

• وضعیت Index
• زمان آخرین Crawl
• نوع Googlebot
• وضعیت Crawl Allowed
• وضعیت Page Fetch
• وضعیت Indexing Allowed
• User-declared Canonical
• Google-selected Canonical

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

Test Live URL

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

Live Test برای بررسی موارد زیر کاربرد دارد:

• رفع خطای دسترسی
• حذف تگ noindex
• اصلاح robots.txt
• بررسی Redirect
• مشاهده HTML پردازش‌شده
• بررسی Screenshot نسخه Renderشده
• شناسایی منابع خطادار یا مسدودشده
• بررسی نتیجه تغییرات فنی پیش از Request Indexing

موفق‌بودن Live Test تضمین نمی‌کند که URL ایندکس شود. این آزمایش فقط نشان می‌دهد نسخه فعلی صفحه از نظر فنی در دسترس گوگل قرار دارد.

یک سناریوی ساده

فرض کنید دیروز یک صفحه دارای تگ noindex بوده و امروز آن را حذف کرده‌اید.

در نسخه ایندکس‌شده ممکن است همچنان ببینید:

URL is not on Google
Indexing allowed: No

اما Test Live URL می‌تواند نتیجه جدید زیر را نشان دهد:

URL is available to Google
Indexing allowed: Yes

این تناقض نیست. نتیجه اول درباره نسخه ثبت‌شده قبلی و نتیجه دوم درباره نسخه فعلی صفحه است.

بررسی بخش Page Indexing در URL Inspection

بخش Page Indexing مهم‌ترین اطلاعات مربوط به Crawl و Index صفحه را در اختیار شما قرار می‌دهد.

Discovery

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

نبودن Referring Page الزاماً به این معنا نیست که URL هیچ لینک داخلی ندارد. اطلاعات نمایش‌داده‌شده همیشه فهرست کاملی از تمام مسیرهای کشف URL نیست.

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

• آیا URL در Sitemap معتبر قرار دارد؟
• آیا از صفحات مرتبط به آن لینک داده شده است؟
• آیا لینک داخلی با تگ استاندارد a و ویژگی href ساخته شده است؟
• آیا صفحه Orphan نیست؟
• آیا Canonical به URL دیگری اشاره نمی‌کند؟
• آیا URL فقط پس از تعامل JavaScript ساخته نمی‌شود؟

Last Crawl

گزینه Last Crawl زمان آخرین مراجعه ثبت‌شده Googlebot به صفحه را نشان می‌دهد. این تاریخ به شما کمک می‌کند بفهمید:

• آیا گوگل پس از آخرین تغییر دوباره صفحه را Crawl کرده است؟
• نتیجه موجود مربوط به نسخه جدید است یا قدیمی؟
• اصلاح فنی شما توسط گوگل مشاهده شده است یا خیر؟

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

Last Crawl را اشتباه تفسیر نکنید

Crawlشدن به معنی Indexشدن نیست. ممکن است گوگل صفحه را دریافت کرده باشد، اما به دلیل تکراری‌بودن، Canonical متفاوت، کیفیت ناکافی یا دلایل دیگر آن را وارد ایندکس نکند.

Crawled As

این گزینه نوع Googlebot استفاده‌شده برای Crawl را نشان می‌دهد. در بیشتر سایت‌ها معمولاً Googlebot Smartphone مشاهده می‌شود.

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

Crawl Allowed

Crawl Allowed مشخص می‌کند آیا قوانین robots.txt اجازه Crawl صفحه را به Googlebot داده‌اند یا خیر.

اگر مقدار آن No باشد، موارد زیر را بررسی کنید:

• آیا مسیر URL در robots.txt مسدود شده است؟
• آیا یک قانون گسترده پوشه بزرگ‌تری را مسدود می‌کند؟
• آیا نسخه HTTP، HTTPS، www یا Subdomain فایل robots.txt متفاوتی دارد؟
• آیا CDN یا افزونه امنیتی پاسخ متفاوتی به Googlebot می‌دهد؟
• آیا فایل robots.txt با خطای سرور مواجه است؟

robots.txt ابزار حذف صفحه از ایندکس نیست. این فایل Crawl را کنترل می‌کند. اگر صفحه قبلاً ایندکس شده باشد و سپس Crawl آن را مسدود کنید، گوگل ممکن است برای مدتی URL را در نتایج نگه دارد؛ زیرا امکان مشاهده تگ noindex داخل صفحه را ندارد.

Page Fetch

Page Fetch نشان می‌دهد Googlebot توانسته محتوای URL را دریافت کند یا خیر.

دریافت ناموفق صفحه می‌تواند به دلایل زیر رخ دهد:

• خطای 5xx سرور
• خطای DNS
• Timeout
• Redirect Loop
• Redirect Chain مشکل‌دار
• مسدودشدن Googlebot توسط Firewall یا WAF
• محدودیت جغرافیایی
• اختلال CDN
• نیاز به Login، Cookie یا Session
• Rate Limiting شدید
• پاسخ متفاوت سرور به User-agent گوگل

اگر Page Fetch ناموفق است، Request Indexing راه‌حل نیست. ابتدا باید علت عدم دریافت صفحه برطرف شود.

Indexing Allowed

این گزینه مشخص می‌کند آیا نسخه فعلی صفحه اجازه ایندکس‌شدن دارد یا خیر.

اگر مقدار آن No باشد، موارد زیر را بررسی کنید:

• تگ meta robots با مقدار noindex
• هدر HTTP با مقدار X-Robots-Tag: noindex
• تنظیمات افزونه سئو
• تنظیمات وردپرس برای جلوگیری از ایندکس
• Template اختصاصی صفحات
• تنظیمات محیط Stage که به Production منتقل شده‌اند
• پاسخ متفاوت سرور برای Googlebot

بررسی User-declared Canonical و Google-selected Canonical

URL Inspection یکی از مهم‌ترین ابزارها برای تشخیص اختلاف Canonical است.

User-declared Canonical چیست؟

این URL همان صفحه‌ای است که شما از طریق تگ rel="canonical" به گوگل پیشنهاد کرده‌اید. برای مثال، در صفحه  https://example.com/product?color=blue ممکن است Canonical اعلام‌شده https://example.com/product/ باشد:

Google-selected Canonical چیست؟

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

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

حالت مطلوب

User-declared canonical:
https://example.com/page/

Google-selected canonical:
Same as user-declared canonical

حالت نیازمند بررسی

User-declared canonical:
https://example.com/page-a/

Google-selected canonical:
https://example.com/page-b/

این اختلاف همیشه خطا نیست. ممکن است چند URL مشابه داشته باشید و انتخاب گوگل منطقی باشد. اما اگر URL دیگری نباید Canonical شناخته شود، این موارد را بررسی کنید:

• آیا محتوای دو صفحه بسیار شبیه است؟
• آیا لینک‌های داخلی بیشتر به URL دیگری اشاره می‌کنند؟
• آیا Sitemap نسخه دیگری را معرفی می‌کند؟
• آیا Redirectها با Canonical تناقض دارند؟
• آیا نسخه‌های HTTP، HTTPS، www و بدون www یکپارچه هستند؟
• آیا پارامترها URLهای تکراری ساخته‌اند؟
• آیا Canonical به صفحه Redirectشونده یا نامعتبر اشاره می‌کند؟

چطور Rendering را با URL Inspection بررسی کنیم؟

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

مسیر بررسی Rendering به این صورت است:

1. URL را در URL Inspection وارد کنید.
2. گزینه Test Live URL را اجرا کنید.
3. پس از پایان آزمایش وارد View Tested Page شوید.
4. بخش‌های HTML، Screenshot و منابع بارگذاری‌شده را بررسی کنید.

در Screenshot به چه مواردی توجه کنیم؟

• آیا محتوای اصلی قابل مشاهده است؟
• آیا عنوان و ابتدای متن نمایش داده می‌شوند؟
• آیا صفحه سفید یا ناقص نیست؟
• آیا قالب و بخش‌های مهم بارگذاری شده‌اند؟
• آیا Popup یا Cookie Banner کل محتوا را نپوشانده است؟
• آیا صفحه به Login، Captcha یا صفحه خطا منتقل نشده است؟
• آیا نسخه موبایل محتوای اصلی را نمایش می‌دهد؟

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

در Rendered HTML چه چیزی را جست‌وجو کنیم؟

• عنوان اصلی صفحه
• متن اصلی و پاراگراف‌های مهم
• لینک‌های داخلی
• Meta Robots
• Canonical
• Structured Data
• نام و قیمت محصول
• اطلاعات موجودی
• محتوای FAQ
• اطلاعاتی که با JavaScript بارگذاری می‌شوند

برای جست‌وجو در HTML پردازش‌شده می‌توانید از Command + F در مک یا Control + F در ویندوز استفاده کنید.

اگر متن در مرورگر دیده می‌شود اما در Rendered HTML نیست

این وضعیت می‌تواند نشان دهد:

• محتوا فقط پس از تعامل کاربر بارگذاری می‌شود.
• درخواست API برای Googlebot شکست می‌خورد.
• فایل JavaScript مسدود یا خطادار است.
• Render صفحه به زمان زیادی نیاز دارد.
• محتوا به Cookie، Local Storage یا Session وابسته است.
• نسخه موبایل محتوا را دریافت نمی‌کند.
• سیستم ضدبات Googlebot را محدود می‌کند.
• Hydration یا اجرای JavaScript با خطا مواجه می‌شود.

در چنین حالتی، مسئله فقط ایندکس‌نشدن نیست. باید معماری Front-end، خروجی HTML، درخواست‌های API و خطاهای منابع بررسی شوند.

منابع مسدودشده یا خطادار را چگونه تحلیل کنیم؟

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

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

تجربه و تحلیل پالت؛ هنگام اختلال اینترنت ایران چه چیزی را بررسی کنیم؟

در بازار ایران همیشه نمی‌توان افت Crawl یا شکست Live Test را فقط به کد سایت نسبت داد. اختلال اینترنت بین‌الملل، مشکلات دیتاسنتر، محدودیت‌های شبکه، اختلال CDN و تنظیمات امنیتی ممکن است دسترسی Googlebot را نیز تحت تأثیر قرار دهند.

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

در چنین شرایطی، تیم سئو نباید بلافاصله robots.txt، Canonical، ساختار URL یا محتوای صفحات را تغییر دهد. ابتدا باید مشخص شود مشکل از خود صفحه است یا از زیرساخت دسترسی.

۱. دسترسی کاربران داخلی را بررسی کنید

بازشدن سایت برای کاربران داخلی فقط ثابت می‌کند مسیر دسترسی داخل کشور فعال است. این آزمایش وضعیت دسترسی Googlebot را تأیید نمی‌کند.

۲. دسترسی سایت از خارج ایران را آزمایش کنید

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

۳. Test Live URL را اجرا کنید

اگر Live Test با خطای Page Fetch، Timeout یا Server Error روبه‌رو شد، زمان و نوع خطا را ثبت کنید. آزمایش را بدون فاصله و بی‌دلیل تکرار نکنید.

۴. چند URL را بررسی کنید

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

۵. داده‌ها را با Crawl Stats تطبیق دهید

در Crawl Stats به این موارد توجه کنید:

• کاهش ناگهانی Crawl Requestها
• افزایش Average Response Time
• افزایش خطاهای Host
• تغییر الگوی پاسخ‌های 5xx

شواهدی که بهتر است ثبت شوند:

• Screenshot از URL Inspection
• نتیجه Test Live URL
• زمان دقیق خطا
• وضعیت Page Fetch
• لاگ سرور
• وضعیت CDN و Firewall
• داده‌های Crawl Stats
• پاسخ سایت از خارج ایران

اگر پس از بازگشت پایداری، Live Test سالم باشد اما نسخه Indexed همچنان وضعیت قبلی را نشان دهد، Request Indexing برای URLهای مهم می‌تواند منطقی باشد.

Request Indexing دقیقاً چه کاری انجام می‌دهد؟

Request Indexing از گوگل می‌خواهد URL را دوباره Crawl و پردازش کند. این قابلیت برای تعداد محدودی URL مهم و پس از اصلاح واقعی مشکل مناسب است.

موارد مناسب استفاده

• صفحه جدید و مهمی منتشر شده است.
• تگ noindex اشتباه حذف شده است.
• Canonical اصلاح شده است.
• خطای Page Fetch یا سرور برطرف شده است.
• Redirect اشتباه اصلاح شده است.
• محتوای صفحه به‌طور اساسی تغییر کرده است.
• Rendering صفحه اصلاح شده است.
• Live Test نتیجه سالمی نشان می‌دهد.

موارد نامناسب استفاده

• مشکل هنوز رفع نشده است.
• صدها یا هزاران URL جدید دارید.
• Sitemap می‌تواند URLها را معرفی کند.
• صفحه ارزش مستقل کافی ندارد.
• URL Duplicate است.
• Canonical عمداً به URL دیگری اشاره می‌کند.
• صفحه همچنان noindex است.
• Googlebot هنوز نمی‌تواند صفحه را دریافت کند.

فرایند استاندارد تحلیل URL در پالت

مرحله اول: هدف URL را مشخص کنید

پیش از ورود به Search Console بپرسید:

• آیا این URL باید ایندکس شود؟
• آیا صفحه ارزش مستقل دارد؟
• Canonical مورد انتظار چیست؟
• پاسخ HTTP مورد انتظار چیست؟
• صفحه در Sitemap و لینک‌های داخلی قرار دارد؟

مرحله دوم: نتیجه Google Index را بخوانید

• URL is on Google است یا URL is not on Google؟
• دلیل وضعیت چیست؟
• Last Crawl چه تاریخی است؟
• Page Fetch موفق بوده است؟
• Indexing Allowed است؟
• Canonical انتخاب‌شده چیست؟

مرحله سوم: نتیجه را با تغییرات سایت تطبیق دهید

اگر تغییرات سایت بعد از Last Crawl انجام شده‌اند، داده نسخه Indexed هنوز نماینده وضعیت فعلی صفحه نیست.

مرحله چهارم: Test Live URL را اجرا کنید

• URL اکنون قابل دسترسی است؟
• robots.txt اجازه Crawl می‌دهد؟
• noindex حذف شده است؟
• Page Fetch موفق است؟
• Screenshot و HTML درست هستند؟
• منابع کلیدی بارگذاری می‌شوند؟

مرحله پنجم: اختلاف Indexed و Live را تحلیل کنید

اشتباهات رایج هنگام استفاده از URL Inspection

• Request Indexing به‌جای عیب‌یابی: Request Indexing مشکل robots.txt، noindex، Canonical، خطای سرور یا محتوای ضعیف را حل نمی‌کند.

• برابر دانستن Live Test با Index: موفقیت Live Test به معنی ورود قطعی URL به ایندکس نیست.

• بررسی‌نکردن Last Crawl: بدون توجه به زمان آخرین Crawl ممکن است داده قدیمی را به‌عنوان وضعیت فعلی تفسیر کنید.
• تمرکز صرف بر Screenshot: ابزار Screenshot فقط یک ابزار کمکی است. Rendered HTML و منابع کلیدی را نیز بررسی کنید.
• نادیده‌گرفتن Canonical انتخابی گوگل: ممکن است URL از نظر Crawl و Indexing Allowed سالم باشد، اما گوگل صفحه دیگری را نسخه اصلی بداند.
• بررسی یک URL برای تشخیص مشکل کل سایت: یک Live Test نمی‌تواند نماینده وضعیت هزاران صفحه باشد. برای مشکلات گسترده، Page Indexing، Sitemap، Crawl Stats و چند نمونه URL را بررسی کنید.

چک‌لیست URL Inspection

وضعیت ایندکس

• آیا URL باید ایندکس شود؟
• آیا URL is on Google است؟
• دلیل عدم ایندکس چیست؟
• آیا Last Crawl بعد از آخرین تغییر انجام شده است؟

Crawl

• Crawl Allowed برابر Yes است؟
• Page Fetch موفق است؟
• پاسخ URL برابر 200 است؟
• Redirect ناخواسته وجود ندارد؟
• Firewall یا CDN مانع Googlebot نیست؟

Indexability

• Indexing Allowed برابر Yes است؟
• Meta Robots دارای noindex نیست؟
• X-Robots-Tag مانع ایندکس نیست؟
• URL صفحه خطا یا Soft 404 نیست؟

Canonical

• User-declared Canonical صحیح است؟
• Google-selected Canonical همان URL مورد انتظار است؟
• لینک‌های داخلی به نسخه Canonical اشاره می‌کنند؟
• Sitemap فقط نسخه اصلی را معرفی می‌کند؟
• Redirect و Canonical با یکدیگر تعارض ندارند؟

Rendering

• Test Live URL موفق است؟
• محتوای اصلی در Screenshot قابل تشخیص است؟
• عنوان و متن اصلی در Rendered HTML دیده می‌شوند؟
• لینک‌های داخلی در HTML پردازش‌شده وجود دارند؟
• منابع حیاتی مسدود یا خطادار نیستند؟
• نسخه موبایل محتوای کامل دارد؟

اقدام بعدی

• آیا مشکل واقعاً رفع شده است؟
• آیا Live Test نتیجه سالم دارد؟
• آیا URL اهمیت کافی دارد؟
• آیا Request Indexing منطقی است؟
• برای تعداد زیاد URL، Sitemap گزینه بهتری نیست؟

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

آیا URL is on Google یعنی صفحه حتماً در نتایج نمایش داده می‌شود؟

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

آیا URL is not on Google همیشه یک خطا است؟

خیر. بعضی URLها نباید ایندکس شوند؛ مانند صفحات تکراری، صفحات خصوصی، URLهای Redirectشده یا نسخه‌هایی که Canonical آن‌ها به صفحه دیگری اشاره می‌کند.

تفاوت URL Inspection و Page Indexing چیست؟

URL Inspection جزئیات یک URL مشخص را نشان می‌دهد. گزارش Page Indexing برای تحلیل گروه‌های بزرگ‌تری از URLها و پیدا‌کردن الگوهای مشترک استفاده می‌شود.

آیا Test Live URL باعث ایندکس صفحه می‌شود؟

خیر. Test Live URL فقط نسخه فعلی صفحه را آزمایش می‌کند. برای درخواست Crawl باید پس از پایان آزمایش از Request Indexing استفاده کنید؛ بدون اینکه ایندکس‌شدن تضمین شود.

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

برای یک تغییر مشخص، پس از رفع مشکل و موفقیت Live Test، یک درخواست کافی است. ارسال مکرر باعث Crawl سریع‌تر نمی‌شود.

چرا Live Test سالم است اما صفحه ایندکس نمی‌شود؟

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

چرا نسخه Indexed با نسخه Live متفاوت است؟

نسخه Indexed اطلاعات آخرین Crawl ثبت‌شده را نشان می‌دهد، اما نسخه Live وضعیت فعلی صفحه را آزمایش می‌کند.

آیا Screenshot ناقص به معنی مشکل قطعی Rendering است؟

نه همیشه. Screenshot ممکن است فقط بخشی از صفحه را نشان دهد. Rendered HTML، Page Fetch و منابع کلیدی را نیز بررسی کنید.

اگر Google-selected Canonical با Canonical سایت متفاوت باشد چه کنیم؟

ابتدا بررسی کنید انتخاب گوگل منطقی است یا خیر. اگر URL دیگری نباید Canonical باشد، سیگنال‌های متناقض مانند محتوای مشابه، لینک‌های داخلی، Sitemap، Redirect و Canonical صفحات را اصلاح کنید.

هنگام اختلال اینترنت ایران، Live Test چه کمکی می‌کند؟

Live Test نشان می‌دهد Googlebot در زمان آزمایش قادر به دریافت نسخه فعلی صفحه بوده است یا خیر. بااین‌حال، نتیجه باید همراه با لاگ سرور، Crawl Stats، مانیتورینگ خارجی و وضعیت CDN تحلیل شود.

جمع‌بندی

URL Inspection فقط دکمه‌ای برای فرستادن صفحه به گوگل نیست؛ بلکه ابزاری برای تشخیص وضعیت یک URL از دو زاویه متفاوت است:

• اطلاعات نسخه‌ای که گوگل قبلاً Crawl و پردازش کرده است.
• وضعیت فعلی صفحه در Test Live URL.

برای استفاده درست از این ابزار، ابتدا هدف URL را مشخص کنید. سپس وضعیت Index، Last Crawl، Crawl Allowed، Page Fetch، Indexing Allowed و Canonical را بررسی کنید.

اگر درباره JavaScript یا نسخه موبایل تردید دارید، Screenshot، Rendered HTML و منابع بارگذاری‌شده را نیز کنترل کنید.

تنها زمانی Request Indexing ارسال کنید که مشکل واقعی برطرف شده، Live Test نتیجه سالمی دارد و URL برای سایت اهمیت کافی دارد.

منابع پیشنهادی برای مطالعه بیشتر

• راهنمای رسمی URL Inspection در Google Search Console
  
• درخواست Crawl مجدد از گوگل
  
• راهنمای Canonical و مدیریت URLهای تکراری
  
• راهنمای Mobile-first Indexing