۷ ابزار URL Inspection سرچ کنسول گوگل برای بهبود سئو

ابزار URL Inspection: فراتر از بررسی وضعیت ایندکس بودن یا نبودن

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

این ابزار به شما موارد زیر را نشان می‌دهد:

• آیا یک صفحه ایندکس شده است.
• صفحه چطور خزش (crawl) شده است.
• چه منابعی مسدود شده‌اند.
• چه داده‌های ساختاریافته (structured data) توسط گوگل شناسایی شده‌اند.
• صفحه برای Googlebot چگونه رندر (render) می‌شود.

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

اما بیشتر متخصصان سئو فقط از بخش کوچکی از قابلیت‌های این ابزار استفاده می‌کنند.

این راهنما هفت روش عملی برای استفاده از ابزار URL Inspection را پوشش می‌دهد تا بتوانید:

• مشکلات ایندکس شدن را حل کنید.
• مشکلات رندر شدن (نمایش) را کشف کنید.
• درستی و اعمال شدن تغییرات مهم را تایید کنید.
• تصمیمات فنی هوشمندانه‌تری بگیرید.

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

ابزار URL Inspection چیست و چرا سئوکارها باید از آن استفاده کنند؟

برای شروع استفاده از این ابزار، کافیه آدرس کامل صفحه (URL) مورد نظرتون رو توی نوار URL Inspection که بالای Google Search Console قرار داره، کپی کنید.

بررسی دقیق وضعیت صفحات وب شما در گوگل

ابزار URL Inspection در Google Search Console به شما این امکان رو می‌ده که ببینید Googlebot (ربات خزنده گوگل) چطور یک صفحه خاص رو خزش (crawl)، رندر (render) و ایندکس (index) می‌کنه.

این ابزار هم نسخه ایندکس شده (که از آخرین خزش هست) و هم یک تست زنده رو در اختیارتون قرار می‌ده که نشون می‌ده صفحه شما در حال حاضر چطور به نظر می‌رسه. در ادامه مواردی که این ابزار به شما نشون می‌ده رو می‌بینید:

• وضعیت ایندکس (Index status): آیا URL مورد نظر شما ایندکس شده یا نه، و اگر نه، دلیلش چیه (مثلاً noindex، خطاهای خزش یا redirect).
• اطلاعات خزش (Crawl information): تاریخ آخرین خزش، موفقیت یا شکست خزش، و اینکه کدوم Googlebot (موبایل یا دسکتاپ) برای خزش استفاده شده.
• اجازه ایندکس شدن (Indexing allowed): آیا صفحه بر اساس meta tags یا HTTP headers اجازه ایندکس شدن داره یا نه.
• کنونیکال اعلام‌شده توسط کاربر در مقابل کنونیکال انتخاب‌شده توسط گوگل (User-declared vs. Google-selected canonical): مقایسه URL canonical که شما تنظیم کردید با اون چیزی که گوگل واقعاً انتخاب کرده.
• اطلاعات کشف (Discovery info): گوگل چطور این URL رو پیدا کرده – از طریق sitemap یا صفحه(های) ارجاع‌دهنده، اگه مشخص باشه.
• نتایج تست زنده (Live test results): یک تست لحظه‌ای از URL فعلی برای بررسی قابلیت خزش، وضعیت رندر و قابلیت ایندکس شدن.
• HTML رندر شده (Rendered HTML): HTML نهایی صفحه بعد از اینکه Googlebot کدهای JavaScript رو اجرا می‌کنه.
• اسکرین‌شات صفحه (Page screenshot): تصویری از اینکه Googlebot بعد از رندر کردن، صفحه رو چطور می‌بینه.
• پیام‌های کنسول JavaScript (فقط در تست زنده) (JavaScript console messages (live test only)): هر گونه خطا یا هشدار JS در طول رندر که ممکنه روی محتوا یا چیدمان صفحه تأثیر بذاره.
• منابع صفحه (Page resources): لیستی از تمام فایل‌های درخواست شده (CSS, JS, fonts و غیره)، که نشون می‌ده هر کدوم بارگذاری شده، با شکست مواجه شده یا مسدود شده.
• داده‌های ساختاریافته (بهبودها) (Structured data (enhancements)): انواع schema شناسایی شده که برای نمایش rich results مناسب هستند، به همراه وضعیت اعتبارسنجی (معتبر، هشدار، خطا).
• هدرهای پاسخ HTTP (HTTP response headers): پاسخ کامل سرور، شامل کد وضعیت، X-Robots-Tag، Cache-Control، Content-Type و موارد دیگه.

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

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

سئوکاران حرفه‌ای از آن برای موارد زیر استفاده می‌کنند:

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

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

در ادامه به برخی از کاربردهای عملی این ابزار می‌پردازیم.

۱ - بررسی وضعیت ایندکس شدن یک آدرس اینترنتی (URL) در گوگل

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

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

• "URL در گوگل است": این به این معنی است که صفحه شما ایندکس شده و می‌تواند در نتایج جستجو نمایش داده شود.
• "URL در گوگل نیست": این یعنی صفحه شما ایندکس نشده و در نتایج جستجو ظاهر نخواهد شد.

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

درک اینکه چگونه Googlebot (ربات جستجوی گوگل) URLهای وب‌سایت شما را کشف می‌کند، به آن‌ها دسترسی می‌یابد و آن‌ها را crawl می‌کند (یعنی محتوایشان را می‌خواند)، از مفاهیم بنیادی در حوزه Technical SEO (بهینه‌سازی فنی موتور جستجو) به شمار می‌رود.

ابزار URL Inspection tool اطلاعات بسیار جزئی و مفیدی در این خصوص ارائه می‌دهد که عمده آن در بخش Page indexing (وضعیت ایندکس شدن صفحه) گزارش مربوط به هر URL قابل دسترسی است:

• Discovery (کشف): این بخش نحوه کشف URL توسط گوگل را شرح می‌دهد. این اطلاعات می‌تواند شامل Sitemaps (نقشه‌های سایت) که URL در آن‌ها قرار گرفته، یا Referring page(s) (صفحات ارجاع‌دهنده) که به آن لینک داده‌اند، باشد. در صورتی که گوگل URL را از منابع دیگری کشف کرده باشد که به طور خاص گزارش نمی‌شوند، ممکن است پیام "URL might be known from other sources that are currently not reported" (URL ممکن است از منابع دیگری که در حال حاضر گزارش نشده‌اند، شناخته شده باشد) نمایش داده شود.
• Last crawl (آخرین خزش): این فیلد تاریخ و زمان دقیق آخرین باری را که گوگل اقدام به crawl URL نموده است، معمولاً بر اساس زمان محلی شما، نمایش می‌دهد. در صورتی که URL هنوز crawl نشده باشد، عبارت N/A (مخفف Not Applicable به معنای قابل اجرا نیست/موجود نیست) نمایش داده خواهد شد.
• Crawled as (خزیده شده به عنوان): این بخش مشخص می‌کند که کدام user-agent (عامل کاربر) از Googlebot برای عملیات crawl استفاده شده است.
• Crawl allowed? (خزش مجاز است؟): این وضعیت نشان می‌دهد که آیا عملیات crawling برای URL مجاز است (Yes) یا مسدود شده است (No)، برای مثال به دلیل وجود دستورات در فایل robots.txt. همچنین ممکن است در صورت عدم تلاش برای crawl یا نامشخص بودن وضعیت، N/A نمایش داده شود.
• Page fetch (واکشی صفحه): این قسمت نتیجه تلاش گوگل برای دریافت محتوای صفحه را تشریح می‌کند. وضعیت‌ها می‌توانند شامل موارد زیر باشند:
  • Successful (موفقیت‌آمیز): به معنای موفقیت در دریافت محتوا.
  • Failed: Soft 404: به معنای عدم یافتن صفحه با وجود عدم بازگشت کد خطای ۴۰۴ صریح از سرور.
  • Failed: Not found (404): به معنای عدم یافتن صفحه (خطای استاندارد ۴۰۴).
  • Failed: Crawl anomaly: به معنای وجود ناهنجاری یا مشکل نامشخص در فرآیند crawl.
  • Failed: Redirect error: به معنای مشکل در دنبال کردن redirectها (تغییر مسیرها) توسط گوگل.
• Indexing allowed? (ایندکس شدن مجاز است؟): این فیلد مشخص می‌کند که آیا indexing (قرار گرفتن صفحه در فهرست جستجوی گوگل) برای URL مجاز است یا خیر. این امر معمولاً بر اساس meta robot tags (مانند noindex) یا HTTP headers (سربرگ‌های پاسخ HTTP) تعیین می‌گردد.
• Canonical: این بخش، Canonical URL (نسخه اصلی و مرجع URL) که توسط شما اعلام شده است را با Canonical URL که توسط گوگل برای آن صفحه انتخاب شده است، مقایسه می‌کند.

اگر یک صفحه کلیدی در وب‌سایت شما وضعیت "URL is not on Google" (URL در گوگل نیست) را نشان می‌دهد، باید به دقت فیلدهای مربوطه را بررسی کنید تا علت این امر را بیابید.

این مشکل می‌تواند ناشی از دلایل ساده‌ای مانند وجود noindex tag (برچسب عدم ایندکس) یا مسدود شدن توسط robots.txt، یک redirect (تغییر مسیر)، و یا مسائل مهم‌تری مانند محتوایی باشد که از دید گوگل کیفیت پایینی دارد.

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

• Crawl blocks (محدودیت‌های خزش): موانعی که جلوی Googlebot را برای خواندن صفحات شما می‌گیرند.
• Misconfigured tags (تگ‌های اشتباه پیکربندی شده): برچسب‌هایی که به اشتباه تنظیم شده‌اند و مانع ایندکس شدن می‌شوند.
• حتی site-wide quality problems (مشکلات کیفی در سطح کل سایت).

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

ابزار URL Inspection tool بسیار مفید است، اما بی‌نقص نیست. هنگام بررسی وضعیت ایندکس شدن، این محدودیت‌ها را در نظر داشته باشید:

• این ابزار آخرین نسخه indexed شده را نشان می‌دهد، نه نسخه زنده و فعلی را. اگر اخیراً تغییراتی اعمال کرده‌اید، آن‌ها نمایش داده نمی‌شوند مگر اینکه یک live test (آزمایش زنده) اجرا کنید.
• "URL is on Google" به معنای قابل مشاهده بودن در جستجو نیست. همانطور که قبلاً گفته شد، این فقط به این معنی است که صفحه واجد شرایط نمایش است، اما تضمینی برای ظاهر شدن آن نیست. برای اطمینان، URL دقیق را در گوگل جستجو کنید.

اگر URL مورد نظر شما ریدایرکت (تغییر مسیر) می‌شود، گزارش وضعیت URL اصلی را نشان می‌دهد، نه آدرس نهایی که به آن هدایت می‌شود. برای بررسی وضعیت آدرس مقصد، باید آن URL را به صورت جداگانه بازرسی کنید.

عبارت "URL is on Google, but has issues" (URL در گوگل است، اما مشکلاتی دارد) به این معناست که صفحه شما ایندکس شده است، اما enhancements (بهبودهایی) مانند structured data (داده‌های ساختاریافته) با مشکل مواجه هستند. برای مشاهده جزئیات مشکلات پرچم‌گذاری شده، بخش‌های مربوطه را گسترش دهید.

باید دقیقاً همان URLی را بازرسی کنید که متعلق به Property (ویژگی) تایید شده شما در Search Console است. بازرسی نسخه اشتباه (مثلاً https:// در مقابل http://، یا www در مقابل نسخه بدون www) منجر به بازگشت داده‌های نامعتبر یا از دست رفته خواهد شد.

۲ - درخواست از گوگل برای ایندکس کردن صفحات جدید و به‌روز شده

دکمه "Request Indexing" (درخواست ایندکس شدن) در ابزار URL Inspection tool به شما این امکان را می‌دهد که از گوگل بخواهید یک URL خاص را مجدداً crawl (بررسی) کند.

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

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

نکاتی که باید به خاطر داشته باشید:

• هیچ میانبری وجود ندارد: ارسال‌های مکرر، سرعت crawling را افزایش نمی‌دهند.
• ایندکس شدن تضمین شده نیست: اگر صفحه کیفیت پایینی داشته باشد، مسدود شده باشد، یا خراب باشد، گوگل از آن صرف‌نظر خواهد کرد.
• محدودیت سهمیه اعمال می‌شود: شما حدود ۱۰ تا ۱۲ ارسال دستی در روز برای هر property (سایت) در رابط GSC (Google Search Console) دارید. اگر از این حد فراتر بروید، با پیام "Quota exceeded" (سهمیه شما تمام شده است) مواجه خواهید شد.
• برای ایندکس کردن انبوه، از URL Inspection API استفاده کنید (۲۰۰۰ درخواست در روز، ۶۰۰ درخواست در دقیقه).

این قابلیت (درخواست ایندکس شدن) زمانی بهترین کارایی را دارد که به صورت استراتژیک و برای محتوای دارای اولویت بالا یا پس از رفع مشکلات مهم استفاده شود. صرفاً درخواست ایندکس کردن، صفحات خراب را اصلاح نخواهد کرد.

شما باید اطمینان حاصل کنید که صفحه مورد نظر:

• از نظر فنی بدون نقص است
• دارای لینک‌های داخلی است.
• در XML sitemap (نقشه سایت XML) شما قرار دارد.
• محتوای ارزشمندی ارائه می‌دهد.

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

۳ - مشاهده آنچه گوگل می‌بیند

ابزار URL Inspection tool فقط به شما نمی‌گوید که آیا یک صفحه ایندکس شده است یا خیر؛ بلکه نشان می‌دهد که Googlebot (ربات گوگل) چگونه صفحه شما را رندر (پردازش و نمایش) می‌کند و آن را می‌فهمد.

این ویژگی به ویژه برای وب‌سایت‌هایی که به شدت از جاوا اسکریپت استفاده می‌کنند، بسیار مفید است؛ چرا که محتوای حیاتی یا structured data (داده‌های ساختاریافته) ممکن است تنها پس از رندر شدن ظاهر شوند.

شما می‌توانید با کلیک بر روی "View crawled page" (مشاهده صفحه خزش شده) برای نسخه ایندکس شده، یا "View tested page" (مشاهده صفحه تست شده) پس از اجرای یک live test (آزمایش زنده)، به این نما دسترسی پیدا کنید

این ابزار (هم نسخه indexed و هم live test) یک تجزیه و تحلیل کامل از نحوه مشاهده صفحه توسط Googlebot را ارائه می‌دهد، از جمله:

• Rendered HTML: این همان DOM نهایی (ساختار سند وب) است که پس از اجرای جاوا اسکریپت ایجاد می‌شود. این بخش برای بررسی اینکه آیا محتوای تزریق شده توسط JS frameworks (مثل React، Vue و غیره) واقعاً برای گوگل قابل مشاهده است یا خیر، ضروری است.
• Screenshot: یک پیش‌نمایش بصری از آنچه ربات های گوگل پس از rendering "می‌بیند". این برای تشخیص طرح‌بندی‌های به هم ریخته یا محتوای از دست رفته مفید است.
• Page resources: لیستی از تمام فایل‌های CSS، JS، تصویر، یا فونت که صفحه سعی در بارگذاری آن‌ها دارد، به همراه وضعیت بارگذاری آن‌ها (بارگذاری شده، مسدود شده، یا ناموفق).
• JavaScript console messages: این پیام‌ها فقط در live tests قابل مشاهده هستند. آن‌ها خطاهای اسکریپت یا هشدارهایی را نشان می‌دهند که ممکن است مانع از بارگذاری محتوا شوند.
• Page type: نوع محتوا (مانند text/html، application/pdf) را تأیید می‌کند که بر نحوه پردازش صفحه توسط گوگل تأثیر می‌گذارد.

اگر ربات های گوگل نتوانند یک اسکریپت کلیدی را بارگذاری کند یا یک resource حیاتی مانند CSS توسط robots.txt مسدود شده باشد، ممکن است صفحه را به درستی render نکند یا اصلاً آن را ایندکس نکند. منابع از دست رفته می‌توانند طرح‌بندی‌های موبایل را به هم بریزند، structured data را غیرفعال کنند و محتوای مهم را پنهان نمایند.

خروجی JavaScript console (فقط از live tests) گنجینه‌ای برای شناسایی خطاهایی است که در غیر این صورت متوجه آن‌ها نمی‌شوید، مانند:

• Broken third-party scripts (اسکریپت‌های شخص ثالث خراب).
• Missing modules (ماژول‌های از دست رفته).
• Rendering failures (شکست در رندرینگ) که مانع از دیدن محتوای شما توسط گوگل می‌شوند.

همچنین می‌توانید نشانه‌های اولیه مشکلات سایت، مانند اسکریپت‌های شخص ثالث غیرمجاز یا کد تزریق شده را تشخیص دهید. اگر rendered HTML یا لیست منابع ناآشنا یا متفاوت از برند شما به نظر می‌رسد، می‌تواند نشانه‌ای باشد که چیزی عمیق‌تر، مانند plugin conflict (تداخل افزونه) یا حتی malicious code (کد مخرب)، سایت شما را تحت تأثیر قرار داده است.

اگر صفحه شما برای نمایش عناصر کلیدی به جاوا اسکریپت وابسته است، حتماً یک live test اجرا کنید. تنها در این صورت است که پیام‌های JS console را خواهید دید و می‌توانید تأیید کنید که محتوای شما واقعاً render و index می‌شود. برای وب‌سایت‌های مدرن، این یکی از مهم‌ترین بررسی‌ها در جعبه ابزار SEO شما محسوب می‌شود.

۴. اجرای "تست زنده" برای بررسی وضعیت لحظه‌ای صفحه

ویژگی "Test Live URL" (تست URL زنده) در سرچ کنسول گوگل به شما این امکان را می‌دهد که ببینید ربات گوگل در همین لحظه چگونه با صفحه شما تعامل می‌کند. این کار به شما کمک می‌کند تا اصلاحات را تأیید کرده یا مشکلات فوری را بدون انتظار برای re-crawl (خزش مجدد) برطرف نمایید.

این بخش، بازخورد فنی و لحظه‌ای از تلاش Googlebot برای crawl و render (پردازش) نسخه زنده صفحه شما را ارائه می‌دهد:

• Indexability status: تأیید می‌کند که آیا صفحه در حال حاضر قابل crawl و index شدن است یا خیر.
• Rendered screenshot: نشان می‌دهد که صفحه پس از rendering، از نظر بصری چگونه برای Googlebot ظاهر می‌شود.
• JavaScript output and console errors: مشکلات اسکریپت را که ممکن است مانع از بارگذاری محتوا شوند، برجسته می‌کند (فقط در live test).
• HTTP headers: کد‌های وضعیت، قوانین cache و دستورالعمل‌های indexing مانند X-Robots-Tag را نمایش می‌دهد.
• Structured data: هر گونه schema markup شناسایی شده و واجد شرایط بودن برای rich results (نتایج غنی) را لیست می‌کند.

در اینجا مواردی را که live test (تست زنده) نشان نمی‌دهد، آورده‌ایم – دانستن این نکات بسیار مهم است تا نتایج را به اشتباه تفسیر نکنید:

• این تست بررسی نمی‌کند که آیا صفحه در sitemap (نقشه سایت) وجود دارد یا دارای internal links (لینک‌های داخلی) است.
• نسخه‌های canonical (اصلی) را ارزیابی نمی‌کند و صفحات duplicate (تکراری) را تشخیص نمی‌دهد.
• برخی از مشکلات (مثلاً quality signals یا سیگنال‌های کیفی) تنها در طول فرآیند indexing (ایندکس شدن) ارزیابی می‌شوند، نه در live testing.
• موفقیت‌آمیز بودن یک تست به این معنی نیست که گوگل صفحه را حتماً index خواهد کرد – فقط به این معناست که این امکان وجود دارد.

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

live test به شما تأیید فوری می‌دهد که مشکل حل شده و صفحه اکنون از نظر فنی indexable (قابل ایندکس شدن) است.

همچنین می‌توانید نسخه live (زنده) را با نسخه indexed (ایندکس شده) مقایسه کنید. این نمایش کنار هم به شما کمک می‌کند تا به این سؤالات پاسخ دهید:

• آیا مشکل قبلاً حل شده و فقط منتظر reindexing (ایندکس شدن مجدد) است؟
• یا اینکه مشکل هنوز وجود دارد و نیاز به کار بیشتری دارد؟

به عنوان مثال، اگر نسخه indexed عبارت "Blocked by robots.txt" را نشان می‌دهد، اما live test می‌گوید "Crawl allowed: Yes"، یعنی اصلاحات شما جواب داده است – فقط باید درخواست reindexing بدهید. اما اگر هر دو حالت نشان‌دهنده مسدود بودن باشند، هنوز مشکل شما برطرف نشده است.

live test ابزار debugging (عیب‌یابی) لحظه‌ای شماست. این ابزار تصمیمات نهایی گوگل برای indexing را پیش‌بینی نمی‌کند، اما به شما یک پاسخ قاطع بله یا خیر در مورد اینکه آیا صفحه شما از نظر فنی آماده است، می‌دهد.

۵. مقایسه URLهای Canonical اعلام شده و انتخاب شده

این ویژگی به شما کمک می‌کند تا تأیید کنید که آیا گوگل rel=canonical tag شما را در نظر می‌گیرد یا آن را با یک نسخه دیگر جایگزین می‌کند.

Canonicalization (مشخص کردن نسخه اصلی) بخش اساسی technical SEO (سئو فنی) است. وقتی چندین صفحه با محتوای مشابه یا تکراری دارید (مثلاً tracking URLs، صفحات محصولات فیلتر شده، یا نسخه‌های بومی‌شده)، از یک canonical tag استفاده می‌کنید تا به گوگل بگویید کدام نسخه باید indexed و ranked شود.

در بخش Page indexing ابزار URL Inspection tool، موارد زیر را مشاهده خواهید کرد:

• User-declared canonical: نسخه‌ای که شما از طریق rel=canonical، HTTP header، یا sitemap مشخص کرده‌اید.
• Google-selected canonical: نسخه‌ای که گوگل واقعاً برای indexing و ranking انتخاب کرده است.

اگر این دو (نسخه اعلام شده توسط شما و نسخه انتخاب شده توسط گوگل) با هم مطابقت داشته باشند، عالی است – سیگنال‌های شما هم‌راستا هستند. اما اگر مطابقت نداشته باشند، یعنی گوگل سیگنال‌های متناقضی می‌بیند یا معتقد است صفحه دیگری authoritative (معتبرتر) است.

گوگل ممکن است canonical شما را در شرایط زیر نادیده بگیرد:

• Canonical اعلام شده شما thin (محتوای کم)، duplicate (تکراری) یا کمتر مرتبط باشد.
• Internal links (لینک‌های داخلی) به نسخه دیگری اشاره داشته باشند.
• Redirect chains (زنجیره‌های ریدایرکت)، canonicals متناقض، یا تضادهای hreflang سیگنال‌ها را مبهم کرده باشند.

این مشکل به خصوص در وب‌سایت‌های ecommerce (تجارت الکترونیک) که URL parameters (پارامترهای URL)، فیلترها و انواع محصولات به سرعت افزایش می‌یابند، رایج است.

با تشخیص این عدم تطابق‌ها، متخصصان SEO می‌توانند:

• اطمینان حاصل کنند که صفحه درست indexed و ranked می‌شود.
• ranking signals (سیگنال‌های رتبه‌بندی) مانند لینک‌ها و ارتباط محتوا را در یک URL واحد تجمیع کنند.
• از رقابت صفحات duplicate یا رقیب با یکدیگر که باعث کاهش دیده شدن می‌شوند، جلوگیری کنند.

یک نکته مهم: live tests (تست‌های زنده) canonical انتخاب شده توسط گوگل را نشان نمی‌دهند – این اطلاعات را فقط برای صفحاتی که از قبل indexed شده‌اند، مشاهده خواهید کرد.

۶. بررسی داده‌های ساختاریافته (Structured Data) و واجد شرایط بودن برای نتایج غنی

Structured data به گوگل کمک می‌کند تا محتوای شما را بهتر درک کند و می‌تواند صفحات شما را برای نمایش به صورت rich results (نتایج غنی) واجد شرایط سازد. این نتایج غنی شامل مواردی مانند:

• Review stars (ستاره‌های بررسی)
• FAQs (سوالات متداول)
• Breadcrumbs (مسیرهای پیمایش)
• Product listings (فهرست‌های محصولات)
• و موارد دیگر می‌شوند.

این لیست‌های بهبود یافته می‌توانند نرخ کلیک (CTR) را افزایش داده و به محتوای شما کمک کنند تا در نتایج جستجو برجسته شود.

ابزار URL Inspection tool نشان می‌دهد که گوگل چه نوع structured data را در یک صفحه خاص تشخیص داده و آیا آن داده‌ها معتبر هستند یا خیر. این اطلاعات را می‌توانید در بخش Enhancements (بهبودها) هنگام بازرسی یک URL پیدا کنید.

ابزار بازرسی URL (URL Inspection tool) اطلاعات زیر را نمایش می‌دهد:

• انواع اسکیما (Schema) شناسایی‌شده و واجد شرایط برای نتایج غنی (Rich Results) (مانند FAQPage، Product، Review، Breadcrumb).
• وضعیت اعتبار هر نوع اسکیما؛ اینکه آیا معتبر است، دارای هشدار است یا شامل خطا می‌شود.
• خلاصه‌ای مشابه آنچه در Rich Results Test مشاهده می‌کنید.
• پیامی مانند "URL has no enhancements" (URL هیچ بهبود خاصی ندارد) در صورتی که هیچ اسکیمای پشتیبانی‌شده‌ای یافت نشود.
• وضعیت ارائه صفحه از طریق HTTPS.

این بررسی به شما کمک می‌کند تا تأیید کنید که گوگل نشانه‌گذاری (markup) شما را به درستی مشاهده می‌کند و مشکلاتی را که می‌توانند مانع از ظاهر شدن rich results شوند، شناسایی کنید.

• خطاها (Errors) به طور کامل مانع از واجد شرایط شدن برای rich results می‌شوند.
• هشدارها (Warnings) مانع از واجد شرایط شدن نمی‌شوند، اما فیلدهای پیشنهادی از دست رفته را برجسته می‌کنند که می‌توانند نحوه نمایش snippet شما را بهبود بخشند.

با استفاده از live test (تست زنده)، می‌توانید structured data را در صفحات تازه منتشر شده یا اخیراً به‌روزرسانی شده قبل از re-crawl (خزش مجدد) آن‌ها بررسی کنید. این روش برای شناسایی زودهنگام مشکلات، به ویژه هنگام اضافه کردن schema برای SEO یا تبدیل‌ها، ایده‌آل است.

هشدارها را نادیده نگیرید – اغلب آن‌ها فرصت‌های آسانی برای بهبود هستند. بسیاری از انواع schema شامل فیلدهای اختیاری اما توصیه‌شده هستند. اضافه کردن آن‌ها می‌تواند یک snippet ساده را به چیزی دقیق‌تر، مفیدتر و قابل کلیک‌تر تبدیل کند.

برای مثال:

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

در حالی که ابزار URL Inspection برای تأیید آنچه گوگل می‌بیند و ایندکس کرده عالی است، اما یک مجموعه کامل اعتبارسنجی نیست. برای تست گسترده‌تر schema:

• از Schema Markup Validator برای اعتبارسنجی هر نوع نشانه‌گذاری schema.org استفاده کنید.
• از Rich Results Test برای پیش‌نمایش واجد شرایط بودن و ظاهر rich resultهای خاص گوگل استفاده کنید.
• از ابزار URL Inspection برای تأیید آنچه واقعاً توسط گوگل در صفحه زنده یا ایندکس شده شما مشاهده شده است، استفاده کنید.

این ابزارها با هم کمک می‌کنند تا اطمینان حاصل شود که structured data شما نه تنها صحیح، بلکه قابل مشاهده، معتبر و ارزشمند است.

شما می‌توانید از Rich Results Test برای انجام live test روی URLهایی که در Google Search Console کنترل نمی‌کنید، استفاده کنید.

۷. بررسی هدرهای HTTP و پاسخ‌های سرور

برای کارهای عمیق در SEO فنی، یکی از ارزشمندترین (و اغلب نادیده گرفته‌شده‌ترین) ویژگی‌ها در ابزار URL Inspection، قابلیت آن در نمایش full HTTP response headers (هدرهای کامل پاسخ HTTP) است که Googlebot هنگام crawl کردن صفحه شما دریافت کرده است.

این اطلاعات از طریق "View crawled page" (مشاهده صفحه خزش شده) یا "View tested page" (مشاهده صفحه تست شده) > "More info" (اطلاعات بیشتر) قابل دسترسی است.

این headers (هدرها) دقیقاً نشان می‌دهند که سرور – یا هر لایه بین مبدأ شما و Googlebot – چگونه پاسخ داده است. این داده‌ها می‌توانند موارد زیر را آشکار یا تأیید کنند:

• Indexing issues (مشکلات ایندکس شدن)
• Rendering errors (خطاهای رندرینگ)
• Redirect logic (منطق ریدایرکت)
• Caching behavior (رفتار کش)
• و موارد دیگر

در اینجا به چند مورد اشاره می‌کنیم که ممکن است در HTTP headers به دنبال آن‌ها باشید:

• Status code (کد وضعیت): کد پاسخ واقعی HTTP را تأیید می‌کند – برای مثال، ۲۰۰ OK (موفقیت‌آمیز)، ۳۰۱ Moved Permanently (به طور دائم منتقل شده)، ۴۰۴ Not Found (یافت نشد)، یا ۵۰۳ Service Unavailable (سرویس در دسترس نیست).
• X-Robots-Tag: می‌تواند شامل دستورالعمل‌هایی مانند noindex (ایندکس نشود)، nofollow (دنبال نشود)، یا nosnippet (اسنیپت نمایش داده نشود) باشد که بر meta tags (متا تگ‌ها) ارجحیت دارند. یک noindex پنهان در اینجا یک مسدودکننده رایج indexing است.
• Link header: اغلب برای اعلام rel=”canonical” یا rel=”alternate” hreflang links استفاده می‌شود – این مورد به ویژه برای non-HTML files (فایل‌های غیر HTML) مانند PDFها یا زمانی که تغییر HTML امکان‌پذیر نیست، اهمیت دارد.
• Content-type: به گوگل می‌گوید با چه نوع فایلی سروکار دارد (مثلاً text/html، application/pdf). عدم تطابق می‌تواند منجر به پردازش نادرست شود.
• Cache-control / Expires / Pragma: کنترل می‌کنند که محتوا چه مدت cached (ذخیره موقت) شود. مقادیر اشتباه پیکربندی شده می‌توانند باعث تأخیر در reindexing (ایندکس شدن مجدد) یا مشاهده محتوای قدیمی توسط گوگل شوند.
• Vary: نشان می‌دهد که محتوا بر اساس مواردی مانند user-agent یا accept-language تغییر می‌کند. این مورد برای SEO موبایل و چندزبانه ضروری است.
• Content-encoding: نشان می‌دهد که محتوا فشرده شده است یا خیر و چگونه (مانند gzip، br).
• Server: نرم‌افزار سرور (Apache، Nginx، IIS) را نشان می‌دهد – برای debugging (عیب‌یابی) رفتارهای خاص پلتفرم مفید است.
• Redirect headers (هدرهای ریدایرکت): اگر صفحه ریدایرکت می‌شود، location header آدرس مقصد و کد وضعیت (مثلاً ۳۰۱، ۳۰۲) را نشان می‌دهد. این مورد برای بررسی زنجیره‌های ریدایرکت و حلقه‌ها کلیدی است.

دستورالعمل‌های سطح Header در کد منبع (source code) نامرئی هستند اما می‌توانند به طور قابل توجهی بر crawling (خزش) و indexing تأثیر بگذارند. ابزار URL Inspection یکی از تنها راه‌هایی است که می‌توانید ببینید Googlebot واقعاً چه چیزی دریافت کرده است، که ممکن است با آنچه شما یا تیم توسعه‌دهنده شما فکر می‌کنید ارائه می‌شود، متفاوت باشد.

موارد استفاده رایج برای SEOs:

• کشف مسدودکننده‌های پنهان ایندکسینگ: یک noindex در X-Robots-Tag می‌تواند از indexing جلوگیری کند – حتی اگر meta tags درست به نظر برسند.
• اعتبارسنجی تنظیمات canonical یا hreflang: به ویژه زمانی که از طریق headers به جای HTML یا sitemap اعلام شده‌اند، مفید است.
• عیب‌یابی محتوای قدیمی: Cache-Control headers بیش از حد تهاجمی ممکن است باعث شود گوگل re-crawling صفحات به‌روز شده شما را به تأخیر بیندازد.
• عیب‌یابی ریدایرکت‌ها: Headers را بررسی کنید تا کد وضعیت صحیح ۳۰۱ و مقصدهای نهایی را تأیید کنید – این برای یافتن حلقه‌ها یا پرش‌های میانی مفید است.
• شناسایی تداخلات CDN یا Proxy: اگر Googlebot headersی را دریافت می‌کند که با آنچه سرور مبدأ شما ارسال می‌کند متفاوت است، چیزی در زنجیره تحویل شما (مثلاً Cloudflare، Fastly) ممکن است دستورالعمل‌های کلیدی را بازنویسی یا حذف کند.

اگرچه بخشی از indexing نیستند، اما headersی مانند Strict-Transport-Security، Content-Security-Policy، X-Frame-Options و X-Content-Type-Options می‌توانند نشان‌دهنده سلامت خوب سایت باشند. گوگل اعلام کرده است که این‌ها فاکتورهای رتبه‌بندی مستقیم نیستند، اما صفحات امن و قابل اعتماد از تجربه کاربری بهتر پشتیبانی می‌کنند، که بخشی از ارزیابی کلی گوگل است.

از داده‌های header برای مقایسه دیدگاه Googlebot با server logs (گزارش‌های سرور) خود استفاده کنید. اگر مطابقت ندارند، چیزی – احتمالاً یک CDN، edge function یا reverse proxy – در حال تغییر headers شماست. این عدم تطابق می‌تواند مشکلات indexing ایجاد کند که در غیر این صورت تشخیص آن‌ها دشوار است.

اگر در حال troubleshooting (عیب‌یابی) جدی SEO هستید، داده‌های header در ابزار URL Inspection گنجینه‌ای از اطلاعات است. اینجاست که مسائل نامرئی پنهان می‌شوند – و بسیاری از ابهامات indexing حل می‌شوند.

محدودیت‌های ابزار URL Inspection

با وجود اینکه ابزار URL Inspection بسیار کاربردی است، اما یک تحلیلگر کامل SEO نیست. به خاطر داشته باشید که این ابزار نمی‌تواند:

• رتبه‌بندی‌ها را پیش‌بینی کند یا ایندکس شدن را تضمین کند: این ابزار فقط صلاحیت فنی صفحه را تأیید می‌کند.
• کیفیت کلی سایت، اسپم، یا امنیت را قضاوت کند: برای این موارد از سایر گزارش‌های Search Console یا اسکنرهای تخصصی استفاده کنید.
• مشکلات بزرگ خزش یا معماری سایت را آشکار کند: برای این کار به Full-site crawlers (خزنده‌های کامل سایت) و تحلیل لاگ‌ها نیاز دارید.
• انتخاب canonical زنده را نشان دهد: فقط نمای indexed (ایندکس شده) نشان‌دهنده canonical انتخاب شده توسط گوگل است.
• داده‌های کامل کشف را ارائه دهد: بیشتر internal links (لینک‌های داخلی)، external backlinks (بک‌لینک‌های خارجی) و sitemap‌های غیرلیست شده در اینجا نامرئی هستند.
• هر نوع Schema.org را اعتبارسنجی کند: برای بررسی‌های گسترده‌تر به Rich Results Test یا Schema Markup Validator اعتماد کنید.
• هدرهای امنیتی از دست رفته را پرچم‌گذاری کند: باید HTTP headers را به صورت دستی بررسی کنید.
• از ورودها، مسدودسازی‌های IP یا فایروال‌ها عبور کند: URLها برای تست باید به صورت عمومی قابل دسترسی باشند.
• مشکلات را به صورت خودکار برطرف کند: شما همچنان باید robots.txt را به‌روزرسانی کنید، noindex را حذف کنید، redirectها را اصلاح کنید، یا markup را خودتان تنظیم کنید.

نتیجه نهایی: از URL Inspection برای تأیید وضعیت فنی صفحات تکی استفاده کنید، اما آن را با سایر گزارش‌های Search Console، ابزارهای SEO شخص ثالث و بررسی‌های دستی محتوا ترکیب کنید تا تصویر کاملی از وب‌سایت خود به دست آورید.