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

تا حالا شده صفحه‌ای را با کلی زحمت منتشر کنی و ساعت‌ها منتظر باشی تا ببینی بالاخره ایندکس می‌شود یا نه؟ یا بدتر از آن، هفته‌ها بگذرد و هیچ خبری از صفحه در نتایج گوگل نباشد؟ همه‌ی ما این حس سردرگمی را تجربه کرده‌ایم؛ اینکه ندانیم مشکل دقیقاً کجاست.

اینجاست که ابزار URL Inspection در سرچ کنسول گوگل، مثل یک «چشم» متخصص، به کمک ما می‌آید. این ابزار تمام حدس و گمان‌ها (آیا مشکل از noindex است؟ آیا robots.txt جلوی ربات را گرفته؟ آیا اصلاً گوگل صفحه را دیده؟) را تمام می‌کند و به شما یک گزارش تشخیصی دقیق می‌دهد.

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

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

قبل از اینکه عمیق شویم، این جدول خلاصه‌ی تمام چیزی است که در عمل به آن نیاز دارید:

ابزار URL Inspection چیست و چرا برای سئو حیاتی است؟

این ابزار در واقع «چشم» شما در داخل گوگل است. ابزار URL Inspection (بازرسی URL) مهم‌ترین ابزار تشخیصی شما در سرچ کنسول گوگل (GSC) است که به شما اجازه می‌دهد وضعیت دقیق یک URL خاص را از دید گوگل ببینید.

اهمیت حیاتی آن در این است که تمام حدس و گمان‌ها را در مورد مشکلات فنی یک صفحه حذف می‌کند. به‌جای اینکه بپرسید “آیا گوگل صفحه مرا می‌بیند؟”، این ابزار به شما پاسخ قطعی می‌دهد و می‌گوید “چگونه” آن را می‌بیند.

تعریف ساده و کاربردی URL Inspection Tool

به زبان ساده، URL Inspection یک گزارش چکاپ کامل و زنده برای یک آدرس (URL) از وب‌سایت شماست.

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

1. داده‌های فعلی گوگل (Google Index): به شما می‌گوید که این URL در حال حاضر در دیتابیس گوگل چه وضعیتی دارد (آیا ایندکس شده یا نه).
2. تست زنده (Live Test): به شما اجازه می‌دهد همان لحظه گوگل را روی صفحه بفرستید (کراول کنید) تا ببینید آیا صفحه می‌تواند ایندکس شود و آیا مشکلات آن برطرف شده‌اند یا خیر.

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

این ابزار به کدام سوالات کلیدی شما پاسخ می‌دهد؟

وقتی URL صفحه‌ای را بررسی می‌کنید، این ابزار به مهم‌ترین سوالات فنی سئو شما پاسخ می‌دهد:

• آیا صفحه در گوگل ایندکس (Index) شده است؟ (پاسخ “URL is on Google” یا “URL is not on Google”)
• چرا صفحه ایندکس نشده است؟ (دلایل کلیدی مثل خطای noindex، مسدود شدن توسط robots.txt، خطای سرور 5xx، خطای 404، یا مشکلات Crawl Anomaly).
• آیا صفحه برای موبایل بهینه (Mobile-Friendly) است؟ (یکی از حیاتی‌ترین فاکتورها)
• گوگل کدام صفحه را به عنوان نسخه اصلی (Canonical) می‌شناسد؟ (به شما نشان می‌دهد که آیا “Google-selected canonical” با “User-declared canonical” شما یکی است یا نه).
• گوگل آخرین بار کِی صفحه را خزش (Crawl) کرده است؟
• گوگل از چه طریقی صفحه را کشف کرده است؟ (مثلاً از طریق سایت‌مپ یا لینک‌دهی داخلی).
• آیا داده‌های ساختاریافته (Schema) شما معتبر است؟ (مانند اسکیمای مقاله، محصول یا سوالات متداول).

چگونه به ابزار URL Inspection در سرچ کنسول جدید دسترسی پیدا کنیم؟

پیدا کردن این ابزار بسیار ساده است:

1. وارد اکانت سرچ کنسول خود شوید و دامنه مورد نظر را انتخاب کنید.
2. در بالاترین قسمت صفحه (در نوار جستجوی بالای داشبورد)، یک کادر جستجو با عنوان “Inspect any URL in…” وجود دارد. 3. URL کاملی را که می‌خواهید بررسی کنید (با https://www) در این کادر وارد کرده و Enter را بزنید.

روش جایگزین: همچنین می‌توانید در گزارش‌های دیگر، مانند گزارش “Pages” (ایندکس)، روی آیکون ذره‌بین کنار هر URL کلیک کنید تا مستقیماً وارد گزارش بازرسی آن URL شوید.

تفاوت کلیدی: درک گزارش «Google Index» در مقابل «Live Test»

درک تفاوت این دو بخش، کلید عیب‌یابی (Debugging) مؤثر در سئو فنی است. به‌طور خلاصه:

• Google Index (گزارش ایندکس): به شما می‌گوید گوگل در گذشته (آخرین باری که صفحه را بررسی کرده) چه چیزی دیده و در حافظه‌اش ثبت کرده است.
• Live Test (تست زنده): به شما می‌گوید گوگل در همین لحظه چه چیزی از صفحه شما می‌بیند.

حالت Google Index: صفحه‌ی شما از دید گوگل چگونه است؟

این بخش، گزارش «وضعیت فعلی» صفحه شما در دیتابیس عظیم گوگل است. این اطلاعات بر اساس آخرین باری که ربات گوگل صفحه شما را خزش (Crawl) کرده، ثبت شده است.

• کاربرد اصلی: فهمیدن اینکه صفحه‌ای که در حال حاضر (شاید) در نتایج جستجو حضور دارد، بر اساس چه اطلاعاتی رتبه‌بندی شده است.
• چه چیزی را نشان می‌دهد:
  • آیا صفحه ایندکس شده یا نه؟ (“URL is on Google” / “URL is not on Google”)
  • آخرین تاریخ خزش (Last crawl).
  • نسخه کنونیکال (Canonical) که گوگل انتخاب کرده.
  • مشکلاتی که در آن زمان وجود داشته (مثلاً خطای Mobile-Friendly یا مشکلات Schema).

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

حالت Live Test: عیب‌یابی لحظه‌ای و بررسی تغییرات جدید

همان‌طور که از اسمش پیداست، این یک تست «زنده» است. وقتی روی دکمه “Test Live URL” کلیک می‌کنید، گوگل در همان لحظه ربات خود را برای بررسی صفحه ارسال می‌کند.

• کاربرد اصلی: عیب‌یابی و تأیید اصلاحات. این ابزار برای پاسخ به این سوال است: “آیا تغییری که همین الان روی صفحه اعمال کردم (مثلاً حذف تگ noindex یا رفع خطای 404)، مشکل را حل کرد؟”
• چه چیزی را نشان می‌دهد:
  • آیا صفحه در حال حاضر قابلیت ایندکس شدن (Indexability) را دارد؟
  • آیا مشکلات فنی (مثل robots.txt، noindex، یا خطاهای موبایلی) در همین لحظه وجود دارند یا خیر.
  • آیا گوگل می‌تواند به منابع صفحه (CSS, JS) دسترسی داشته باشد؟

چرا داده‌های این دو بخش ممکن است با هم متفاوت باشند؟

این تفاوت، رایج‌ترین سناریوی عیب‌یابی است و دلیل آن فقط یک کلمه است: زمان.

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

مثال کلاسیک:

1. مشکل: شما متوجه می‌شوید صفحه‌تان ایندکس نشده است.
2. بررسی (Google Index): ابزار URL Inspection در بخش “Google Index” به شما می‌گوید: “Page is not indexed: ‘noindex’ tag detected”. (گوگل در آخرین بازدیدش یک تگ noindex دیده).
3. اقدام: شما تگ noindex را از صفحه حذف می‌کنید.
4. بررسی مجدد (Live Test): بلافاصله دکمه “Test Live URL” را می‌زنید. نتیجه تست زنده: “URL is available to Google” (صفحه مشکلی برای ایندکس ندارد).
5. نتیجه:
   • Live Test (تست زنده) به شما می‌گوید که مشکل را با موفقیت حل کرده‌اید.
   • Google Index (گزارش ایندکس) همچنان همان خطای قبلی (noindex) را نشان می‌دهد.

چرا؟ چون گوگل هنوز در پروسه خزش عادی خود به صفحه شما سر نزده تا متوجه تغییرات شود و دیتابیس خود را به‌روز کند. در این حالت، پس از تأیید موفقیت در “Live Test”، می‌توانید از گزینه “Request Indexing” استفاده کنید تا به گوگل اطلاع دهید که صفحه تغییر کرده و آن را زودتر بررسی کند.

تحلیل بخش Coverage (پوشش): آیا صفحه شما در گوگل حضور دارد؟

این بخش، مهم‌ترین بخش گزارش URL Inspection است؛ در واقع، کارنامه نهایی صفحه شماست. بخش Coverage (که حالا در سرچ کنسول جدید با عنوان Page indexing هم شناخته می‌شود) به این یک سوال حیاتی پاسخ می‌دهد: «آیا این URL در دیتابیس گوگل وجود دارد و می‌تواند در نتایج جستجو نمایش داده شود یا نه؟»

تمام تحلیل‌های فنی با جواب این سوال شروع می‌شود.

معنای وضعیت سبز «URL is on Google»

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

• معنای دقیق: این وضعیت تأیید می‌کند که گوگل صفحه شما را خزش (Crawl) کرده، آن را پردازش کرده و با موفقیت به فهرست (Index) خود اضافه کرده است.
• نکته کلیدی: این به آن معناست که صفحه شما واجد شرایط نمایش در نتایج جستجوی گوگل است. (البته این تضمینی برای رتبه گرفتن نیست، بلکه فقط به معنای «حضور» و «اجازه ورود» است).
• چه چیزهایی را نشان می‌دهد: در این حالت، گزارش به شما جزئیات مفیدی مثل تاریخ آخرین خزش (Last crawl)، نحوه کشف شدن (Discovery)، و اینکه آیا توسط نقشه سایت (Sitemap) معرفی شده یا از طریق لینک داخلی، را نشان می‌دهد.

عیب‌یابی وضعیت «URL is not on Google» (صفحه در گوگل نیست)

دیدن این وضعیت قرمز رنگ، به معنای شروع فرآیند عیب‌یابی (Debugging) است.

• معنای دقیق: این URL در حال حاضر در فهرست گوگل نیست و به هیچ وجه در نتایج جستجو نمایش داده نخواهد شد.
• نکته کلیدی: این وضعیت، خودِ «مشکل» نیست، بلکه «نشانه‌ی» یک مشکل است. دلیل اصلی ایندکس نشدن، معمولاً درست در زیر همین عبارت نوشته می‌شود (مثلاً: “Blocked by robots.txt” یا “Page with redirect”). کار شما پیدا کردن آن دلیل و رفع آن است.

تفسیر خطاهای رایج:

وقتی با وضعیت «URL is not on Google» مواجه می‌شوید، دلیل آن یکی از موارد زیر خواهد بود:

Discovered – currently not indexed (کشف شده – در حال حاضر ایندکس نشده)

• معنای ساده: گوگل لینک شما را پیدا کرده و می‌داند که چنین صفحه‌ای وجود دارد (معمولاً از طریق یک لینک داخلی یا سایت‌مپ)، اما هنوز تصمیم نگرفته که ربات‌های خود را برای خزش و بررسی محتوای آن بفرستد.
• چرا اتفاق می‌افتد؟ این معمولاً یک مسئله مربوط به اولویت‌بندی یا بودجه خزش (Crawl Budget) است. گوگل ممکن است تشخیص داده باشد که:
  1. این صفحه آنقدرها مهم نیست که منابعش را صرف آن کند.
  2. در زمانی که می‌خواسته صفحه را خزش کند، سرور شما با بار سنگین مواجه بوده (Overload) و گوگل خزش را به زمان دیگری موکول کرده.
• راه حل: تقویت لینک‌سازی داخلی به این صفحه (تا به گوگل بفهمانید مهم است) و اطمینان از سلامت و سرعت سرور.

Crawled – currently not indexed (خزش شده – در حال حاضر ایندکس نشده)

• معنای ساده: این مورد یکی از مهم‌ترین سیگنال‌هاست. گوگل صفحه شما را خزش کرده، محتوای آن را دیده و خوانده، اما آگاهانه تصمیم گرفته که آن را وارد فهرست خود نکند.
• چرا اتفاق می‌افتد؟ این تقریباً همیشه یک مشکل کیفیت محتوا است، نه یک مشکل فنی. گوگل به این نتیجه رسیده که محتوای شما:
  • ارزش افزوده‌ی خاصی ندارد (Thin Content).
  • بسیار شبیه به صفحات دیگر (چه در سایت شما و چه در سایت‌های دیگر) است (Duplicate Content).
• راه حل: این خطا با تغییرات فنی حل نمی‌شود. شما باید محتوای صفحه را به شکلی اساسی بازنویسی و غنی‌سازی کنید تا «ارزش» ایندکس شدن را پیدا کند.

Blocked by robots.txt (مسدود شده توسط robots.txt)

• معنای ساده: شما (یا تیم فنی شما) به صراحت و با یک دستور در فایل robots.txt در ریشه سایت، به ربات گوگل گفته‌اید: «حق نداری این صفحه را بخزی».
• چرا اتفاق می‌افتد؟
  1. عمدی: برای صفحاتی که نباید ایندکس شوند (مثل پنل ادمین، نتایج جستجوی داخلی سایت).
  2. سهوی: این یک اشتباه فنی رایج و البته فاجعه‌بار است. ممکن است تصادفاً کل سایت (Disallow: /) یا یک بخش مهم را مسدود کرده باشید.
• راه حل: فوراً فایل robots.txt خود را بررسی کنید و دستور Disallow مربوط به آن URL را حذف (یا اصلاح) کنید.

Not found (404)

• معنای ساده: ربات گوگل برای دیدن صفحه آمده، اما سرور شما با خطای 404 (صفحه یافت نشد) پاسخ داده است.
• چرا اتفاق می‌افتد؟
  1. شما واقعاً آن صفحه را حذف کرده‌اید.
  2. URL صفحه را تغییر داده‌اید اما آن را به آدرس جدید ریدایرکت (301) نکرده‌اید.
  3. یک لینک شکسته (Broken Link) در داخل سایت یا در سایت‌مپ شما وجود دارد که به این آدرس اشتباه اشاره می‌کند.
• راه حل: اگر صفحه عمداً حذف شده، مشکلی نیست. اما اگر صفحه باید وجود داشته باشد، یا آن را برگردانید، یا لینک شکسته را اصلاح کنید، یا آن را به آدرس صحیح ریدایرکت 301 کنید.

بررسی Page indexing (ایندکس شدن صفحه) و نقش تگ‌های Noindex و Canonical

این بخش فرعی در گزارش Coverage به شما می‌گوید که چرا گوگل تصمیمات بالا را گرفته است.

• Indexing (ایندکس): به شما نشان می‌دهد که آیا گوگل اجازه ایندکس صفحه را داشته است (Indexing allowed? Yes/No).
• تگ Noindex: اگر اجازه ایندکس “No” باشد، تقریباً همیشه به این دلیل است که یک تگ meta robots=”noindex” در هدر HTML صفحه شما پیدا شده است. این تگ یک دستور صریح به گوگل است که «این صفحه را خزش کن، اما در نتایج جستجو نشان نده».
• تگ Canonical (نسخه اصلی): این بخش حیاتی است و به شما نشان می‌دهد که گوگل کدام صفحه را به عنوان نسخه «اصلی» می‌شناسد.
  • User-declared canonical: آدرسی که شما در کد صفحه به‌عنوان نسخه اصلی معرفی کرده‌اید.
  • Google-selected canonical: آدرسی که گوگل در نهایت به‌عنوان نسخه اصلی انتخاب کرده است.
  • نکته کلیدی: اگر این دو آدرس با هم متفاوت باشند، به این معنی است که گوگل سیگنال‌های شما (تگ کنونیکال) را نادیده گرفته و به دلیل شباهت زیاد محتوا، خودش تصمیم دیگری گرفته است. این یک سیگنال قوی برای بررسی مشکلات محتوای تکراری (Duplicate Content) در سایت شماست.

بررسی بخش Enhancements (بهبودها): از موبایل تا اسکیما

این بخش در ابزار URL Inspection، کارت گزارش «امتیازات ویژه» صفحه شماست. در حالی که بخش “Coverage” به شما می‌گفت که آیا صفحه حضور دارد یا نه، بخش “Enhancements” به شما می‌گوید که آیا صفحه شما واجد شرایط نمایش به شکل «ویژه» و «بهبودیافته» در نتایج جستجو هست یا خیر.

این بخش مستقیماً بر تجربه کاربری (UX) و نرخ کلیک (CTR) شما تأثیر می‌گذارد.

اطمینان از Mobile Usability (قابلیت استفاده در موبایل)

از آنجایی که گوگل با اولویت موبایل (Mobile-First Indexing) کار می‌کند، این گزارش شاید مهم‌ترین بخش “Enhancements” باشد.

• چه چیزی را بررسی می‌کند؟ گوگل در این بخش به شما می‌گوید که آیا صفحه شما روی دستگاه موبایل به درستی نمایش داده می‌شود یا خیر.
• وضعیت سبز (“Page is mobile friendly”): به این معنی است که صفحه شما تست‌های گوگل را پاس کرده و همه‌چیز خوب است.
• وضعیت قرمز (“Page is not mobile friendly”): به این معنی است که ربات گوگل هنگام بررسی صفحه با موبایل، با مشکلاتی مواجه شده است. دلایل رایج عبارتند از:
  • Text too small to read: متن آنقدر ریز است که کاربر باید زوم کند.
  • Clickable elements too close together: دکمه‌ها یا لینک‌ها آنقدر به هم نزدیک هستند که نمی‌توان به‌راحتی روی آن‌ها کلیک کرد.
  • Content wider than screen: محتوا از صفحه موبایل بیرون زده و کاربر مجبور به اسکرول افقی است.

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

اعتبار سنجی داده‌های ساختار یافته (Schema) و ریچ ریزالت‌ها (Rich Results)

اینجا جایی است که گوگل به شما می‌گوید آیا کدهای اسکیمایی که در صفحه قرار داده‌اید، «معتبر» هستند و آیا صفحه شما «شانس» نمایش به صورت ریچ ریزالت (مثل ستاره‌های امتیاز، قیمت محصول، زمان پخت غذا یا سوالات متداول) را دارد یا نه.

• چه چیزی را بررسی می‌کند؟ گوگل به دنبال کدهای schema.org (معمولاً با فرمت JSON-LD) در صفحه شما می‌گردد.
• گزارش خطا: اگر کدهای شما ناقص باشند (مثلاً در اسکیمای محصول، price را جا انداخته باشید) یا ساختار آن‌ها اشتباه باشد، گوگل در همین بخش به شما خطا می‌دهد.
• گزارش موفقیت (Valid): اگر کدهای شما معتبر باشند، گوگل آن‌ها را شناسایی کرده و در این بخش به صورت سبز رنگ نشان می‌دهد (مثلاً: “Products: 1 valid item detected”).
• نکته مهم: «معتبر بودن» (Valid) به معنای «تضمین» نمایش ریچ ریزالت نیست. بلکه فقط به این معناست که شما «واجد شرایط» هستید و گوگل اگر تشخیص دهد برای کاربر مفید است، آن را نمایش خواهد داد.

بررسی وضعیت Breadcrumbs (مسیر راهنما)

بردکرامب (Breadcrumb) یا «مسیر راهنما» یکی از انواع خاص داده‌های ساختاریافته (Schema) است که به گوگل کمک می‌کند ساختار سایت شما را بفهمد و همچنین آن را در نتایج جستجو به شکلی مرتب نمایش دهد.

• اهمیت: گوگل به این اسکیما اهمیت ویژه‌ای می‌دهد، به طوری که آن را به صورت یک بخش مجزا در “Enhancements” نمایش می‌دهد.
• گزارش: مانند سایر اسکیماها، این بخش به شما می‌گوید که آیا کد بردکرامب شما معتبر (Valid) است یا دارای خطا (Error). اگر خطا وجود داشته باشد، به شما کمک می‌کند تا بفهمید کدام بخش از کدنویسی اسکیما را باید اصلاح کنید.

اتصال به گزارش Core Web Vitals (هسته‌های حیاتی وب)

این بخش در ابزار URL Inspection کمی متفاوت عمل می‌کند. ابزار بازرسی URL، داده‌های لحظه‌ای (Lab Data) از Core Web Vitals (CWV) را به شما نمی‌دهد.

• اتصال غیرمستقیم: در گذشته، در گزارش URL Inspection یک لینک به گزارش Core Web Vitals وجود داشت. اما حالا، داده‌های CWV به صورت مجزا در گزارش “Core Web Vitals” در سرچ کنسول نمایش داده می‌شوند.
• داده‌های میدانی (Field Data): گزارش اصلی CWV در سرچ کنسول بر اساس «داده‌های میدانی» است؛ یعنی تجربه‌ی کاربران واقعی شما در 28 روز گذشته.
• ارتباط با URL Inspection: اگر می‌خواهید وضعیت CWV یک URL خاص را ببینید، باید به گزارش Core Web Vitals بروید، روی یکی از دسته‌بندی‌ها (Good, Needs Improvement, Poor) کلیک کنید و در لیست URLهای نمونه، آدرس مورد نظر خود را پیدا کنید.

خلاصه: برای داده‌های فنی و ایندکس، از URL Inspection استفاده کنید. اما برای بررسی سرعت و تجربه کاربری (LCP, INP, CLS)، باید مستقیماً به گزارش “Core Web Vitals” مراجعه کنید.

راهنمای گام به گام: استفاده از ابزار برای حل مشکلات رایج (سناریوهای عملی)

اینجا دقیقاً جایی است که ابزار URL Inspection از یک «گزارش» به یک «آچار» همه‌کاره برای عیب‌یابی تبدیل می‌شود. بیایید چند سناریوی واقعی را با هم مرور کنیم:

سناریو ۱: انتشار یک مقاله جدید (استفاده صحیح از Request Indexing)

شما مقاله‌ی جدید و مهمی را منتشر کرده‌اید و می‌خواهید مطمئن شوید گوگل آن را «سالم» و «سریع» می‌بیند.

1. گام اول: پس از انتشار، URL کامل مقاله را کپی کنید.
2. گام دوم: URL را در نوار URL Inspection در بالای سرچ کنسول وارد کنید.
3. گام سوم (حیاتی): قبل از اینکه روی “Request Indexing” کلیک کنید، ابتدا دکمه “Test Live URL” را بزنید.
4. گام چهارم: منتظر بمانید تا تست زنده کامل شود. به دو بخش کلیدی نگاه کنید:
   • Page indexing (ایندکس صفحه): مطمئن شوید که وضعیت “URL is available to Google” (URL برای گوگل در دسترس است) را نشان می‌دهد. اگر خطای noindex یا مسدودیت robots.txt را نشان داد، یعنی یک مشکل اساسی وجود دارد که باید قبل از ایندکس حل شود.
   • Enhancements (بهبودها): مطمئن شوید که خطای Mobile Usability یا خطای حیاتی در اسکیماها (مثل اسکیمای مقاله) وجود ندارد.
5. گام پنجم (نهایی): فقط بعد از اینکه تست زنده (Live Test) به شما چراغ سبز نشان داد و تأیید کرد که صفحه سالم است، به صفحه اصلی گزارش برگردید و روی “Request Indexing” کلیک کنید.

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

سناریو ۲: عیب‌یابی صفحه‌ای که ایندکس نمی‌شود

شما صفحه‌ای دارید که هفته‌هاست ایندکس نشده یا از ایندکس خارج شده است.

1. گام اول: URL را در ابزار وارد کنید.
2. گام دوم: به گزارش Google Index (گزارش اولیه‌ای که نمایش داده می‌شود) نگاه کنید. به احتمال زیاد وضعیت “URL is not on Google” را خواهید دید.
3. گام سوم (پیدا کردن سرنخ): دقیقاً زیر آن، «دلیل» ایندکس نشدن نوشته شده است. این دلیل، کلید حل معماست:
   • “Blocked by robots.txt”: فایل robots.txt را اصلاح کنید.
   • “Submitted with ‘noindex’ tag”: تگ noindex را از کد HTML صفحه حذف کنید.
   • “Crawled – currently not indexed”: این یک سیگنال کیفی است. گوگل صفحه را دیده اما آن را بی‌ارزش تشخیص داده. محتوا را به شکل اساسی بازبینی و غنی کنید.
   • “Discovered – currently not indexed”: گوگل صفحه را پیدا کرده اما هنوز برای خزش آن اقدام نکرده. لینک‌سازی داخلی به این صفحه را تقویت کنید تا اهمیت آن را به گوگل نشان دهید.
   • “Not found (404)”: صفحه حذف شده است. یا آن را برگردانید یا اگر آدرس جدیدی دارد، آن را 301 ریدایرکت کنید.
4. گام چهارم: پس از اعمال تغییرات روی سایت خود، به سرچ کنسول برگردید و “Test Live URL” را اجرا کنید تا مطمئن شوید مشکل از دید گوگل حل شده است.
5. گام پنجم: پس از موفقیت در تست زنده، “Request Indexing” را بزنید.

سناریو ۳: بررسی دلیل عدم نمایش ریچ ریزالت‌ها

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

1. گام اول: URL صفحه محصول را وارد کنید.
2. گام دوم: “Test Live URL” را اجرا کنید (چون می‌خواهید آخرین نسخه کد خود را بررسی کنید).
3. گام سوم: پس از اتمام تست، به پایین صفحه اسکرول کنید و بخش Enhancements را پیدا کنید.
4. گام چهارم: به دنبال اسکیمای مربوطه بگردید (مثلاً “Products” یا “Review snippets”).
5. گام پنجم (عیب‌یابی):
   • اگر اسکیما اصلاً شناسایی نشده: یعنی کد اسکیما در صفحه شما وجود ندارد یا آنقدر ساختار آن اشتباه است که گوگل اصلاً آن را تشخیص نمی‌دهد.
   • اگر “Invalid items detected” (موارد نامعتبر) را نشان می‌دهد: روی آن کلیک کنید. گوگل دقیقاً به شما می‌گوید کدام فیلد الزامی (مثل price یا name یا review) وجود ندارد یا اشتباه وارد شده است.
6. گام ششم: به سایت خود بروید، کد اسکیما را بر اساس خطای اعلام شده اصلاح کنید و مجدداً گام دوم تا پنجم را تکرار کنید تا زمانی که گزارش تست زنده، اسکیما را “Valid” (معتبر) نشان دهد.

سناریو ۴: اطمینان از رفع مشکلات موبایل پس از به‌روزرسانی

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

1. گام اول: URL یکی از صفحاتی که قبلاً می‌دانستید مشکل موبایل دارد را وارد کنید.
2. گام دوم: “Test Live URL” را اجرا کنید.
3. گام سوم: در نتایج تست زنده، به بخش “Mobile Usability” نگاه کنید.
4. گام چهارم: نتیجه باید “Page is mobile friendly” باشد.
5. گام پنجم (اگر هنوز مشکل وجود داشت): اگر هنوز خطا می‌دهد، روی آن کلیک کنید تا دلایل دقیق (مثل “Clickable elements too close”) را ببینید و به تیم فنی گزارش دهید. تست زنده به شما اجازه می‌دهد قبل از اینکه گوگل در خزش عادی خود متوجه این مشکلات شود، شما آن‌ها را پیدا و رفع کنید.

سناریو ۵: بررسی HTML رندر شده (Rendered HTML) برای یافتن مشکلات پنهان

این یک سناریوی پیشرفته، مخصوصاً برای سایت‌های JavaScript-heavy (مثل سایت‌های مبتنی بر React یا Angular) است.

• مشکل: گاهی اوقات محتوای شما یا تگ‌های مهم (مثل canonical یا noindex) توسط جاوا اسکریپت به صفحه اضافه می‌شوند. چیزی که شما در “View Source” مرورگر می‌بینید، با چیزی که گوگل پس از اجرای JS می‌بیند (Render می‌کند) متفاوت است.

1. گام اول: URL مورد نظر را وارد کرده و “Test Live URL” را اجرا کنید.
2. گام دوم: پس از اتمام تست، روی “View Tested Page” کلیک کنید.
3. گام سوم: یک پنجره در سمت راست باز می‌شود. روی تب “HTML” کلیک کنید.
4. گام چهارم (نکته طلایی): این HTML، کد منبع (Source Code) خام شما نیست؛ بلکه این HTML رندر شده (Rendered HTML) است. یعنی کدی است که گوگل پس از اجرای فایل‌های جاوا اسکریپت شما آن را می‌بیند.
5. گام پنجم (عیب‌یابی): حالا در این کد جستجو کنید (Ctrl+F).
   • آیا محتوای اصلی مقاله‌تان که با JS لود می‌شود، در این کد وجود دارد؟
   • آیا تگ noindex به اشتباه توسط یک اسکریپت به هدر اضافه شده است؟
   • آیا لینک‌های داخلی که با JS ساخته می‌شوند، به صورت تگ <a> با href واضح در این کد وجود دارند؟

این بخش به شما کمک می‌کند تا مشکلات پنهانی را پیدا کنید که در حالت عادی قابل مشاهده نیستند و مستقیماً بر سئو فنی شما تأثیر می‌گذارند.

اشتباهات رایج و نکات پیشرفته (تجربیات یک متخصص)

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

اشتباه ۱: کلیک مداوم بر روی دکمه «Request Indexing»

این شایع‌ترین و در عین حال بی‌فایده‌ترین اشتباهی است که می‌بینم. بعضی‌ها فکر می‌کنند این دکمه یک «بوستر» جادویی برای رتبه گرفتن است.

• واقعیت چیست؟ دکمه “Request Indexing” (درخواست ایندکس) فقط یک «اطلاع‌رسانی» به گوگل است. شما به گوگل می‌گویید: «سلام، من این صفحه را تغییر دادم، لطفاً در صف بررسی قرار بده».
• چرا اشتباه است؟
  1. محدودیت دارد: شما سهمیه محدودی برای استفاده از این دکمه در روز دارید.
  2. باعث آزار ربات‌ها می‌شود: کلیک مداوم روی آن برای یک URL، هیچ کمکی نمی‌کند. گوگل متوجه درخواست اول شما شده است.
  3. جایگزین راه‌حل نیست: اگر صفحه‌ی شما مشکل فنی (noindex) یا کیفی (محتوای ضعیف) داشته باشد، ۱۰۰ بار هم کلیک کنید، ایندکس نخواهد شد.
• استفاده صحیح (تجربه من): من فقط زمانی از این دکمه استفاده می‌کنم که ۱) یک صفحه جدید و مهم منتشر کرده‌ام یا ۲) یک خطای فنی بحرانی را در صفحه‌ای که قبلاً ایندکس نشده بود، برطرف کرده‌ام. و در هر دو حالت، فقط پس از اجرای “Test Live URL” و دیدن نتیجه سبز و سالم، این کار را انجام می‌دهم.

اشتباه ۲: نادیده گرفتن بخش «Page resources» در تست زنده

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

• این بخش کجاست؟ وقتی “Test Live URL” را اجرا می‌کنید و روی “View Tested Page” کلیک می‌کنید، در کنار تب‌های HTML و Screenshot، یک تب به نام “More Info” وجود دارد. در این بخش، لیستی از “Page resources” (منابع صفحه) را می‌بینید.
• چه چیزی را نشان می‌دهد؟ این بخش به شما می‌گوید که آیا گوگل هنگام رندر کردن صفحه، توانسته به تمام فایل‌های CSS، جاوا اسکریپت (JS) و تصاویر شما دسترسی پیدا کند یا خیر.
• چرا حیاتی است؟ گاهی اوقات می‌بینید که فایل‌های JS یا CSS حیاتی شما به اشتباه در robots.txt مسدود (Blocked) شده‌اند.
  • نتیجه؟ گوگل نمی‌تواند صفحه را به درستی «رندر» کند. ممکن است محتوای اصلی شما که با JS لود می‌شود را نبیند، یا ساختار صفحه را به هم ریخته تشخیص دهد و خطای “Mobile Usability” بدهد، در حالی که شما در مرورگر خود همه‌چیز را سالم می‌بینید. همیشه این بخش را برای پیدا کردن منابع “Blocked” چک کنید.

اشتباه ۳: تفاوت بین «Referring page» و «Sitemaps»

در گزارش اصلی URL Inspection (نه تست زنده)، بخشی به نام “Discovery” (کشف) وجود دارد که به شما می‌گوید گوگل اولین بار چطور این صفحه را پیدا کرده است. دو منبع اصلی در اینجا وجود دارد:

1. Sitemaps (نقشه سایت): یعنی شما به صورت مستقیم و رسمی این URL را در فایل sitemap.xml خود به گوگل معرفی کرده‌اید.
2. Referring page(s) (صفحات ارجاع‌دهنده): یعنی گوگل این URL را با دنبال کردن یک لینک از صفحه‌ی دیگری (چه داخلی و چه بک‌لینک خارجی) پیدا کرده است.

• تحلیل تجربی:
  • اگر یک URL مهم فقط در “Sitemaps” دیده می‌شود و هیچ “Referring page” ندارد، این یک زنگ خطر بزرگ برای لینک‌سازی داخلی شماست. یعنی صفحه شما یک «یتیم» است و گوگل هیچ مسیر طبیعی برای رسیدن به آن پیدا نکرده است.
  • اگر صفحه‌ای اصلاً در سایت‌مپ شما نیست اما “Referring page” دارد، یعنی گوگل آن را به صورت طبیعی کشف کرده، اما شما فراموش کرده‌اید آن را به نقشه‌های رسمی سایت اضافه کنید.

نکته پیشرفته: استفاده از API برای بازرسی انبوه URLها

ابزار URL Inspection در داخل سرچ کنسول، عالی است… اما برای بررسی تک به تک. وقتی با یک سایت بزرگ، یک مهاجرت سایت (Migration)، یا یک مشکل فنی سراسری (مثلاً آپدیت اسکیمای تمام محصولات) روبرو هستید، بررسی دستی ۱۰۰۰ صفحه غیرممکن است.

• راه‌حل چیست؟ URL Inspection API.
• این API چه کار می‌کند؟ به شما اجازه می‌دهد تمام اطلاعاتی را که به صورت دستی در سرچ کنسول می‌بینید (وضعیت ایندکس، کنونیکال، مشکلات موبایل، وضعیت اسکیما) به صورت برنامه‌نویسی شده و انبوه (Bulk) دریافت کنید.
• سناریوی عملی: فرض کنید الگوریتم robots.txt خود را تغییر داده‌اید. شما می‌توانید لیستی از ۱۰۰۰ URL نمونه از بخش‌های مختلف سایت را به این API بدهید تا در عرض چند دقیقه بفهمید که آیا تغییرات شما باعث مسدود شدن تصادفی صفحات مهم شده است یا خیر. این ابزار، سلاح مخفی سئوکاران فنی برای ممیزی‌های (Audit) بزرگ است.

جمع‌بندی (راهنمای جامع ابزار URL Inspection)

ابزار URL Inspection دیگر یک ابزار «ساده» در سرچ کنسول نیست؛ این ابزار، «چشم» شما در داخل گوگل و بهترین دوست شما برای سئو فنی است.

به جای اینکه روزها وقت صرف حدس زدن کنید که چرا صفحه‌ای ایندکس نشده، چرا ریچ ریزالت (مثل ستاره امتیاز) نمی‌گیرد، یا چرا در موبایل مشکل دارد، این ابزار به شما «داده» دقیق و قابل اعتماد می‌دهد.

یادتان باشد، تفاوت بین یک سئوکار مبتدی و یک متخصص باتجربه، دقیقاً در توانایی عیب‌یابی (Debugging) با همین داده‌هاست. از بخش «Test Live URL» نترسید، به «Rendered HTML» نگاه کنید و همیشه یک قدم از ربات‌های گوگل جلوتر باشید.