راهنمای جامع تست لایو در سرچ کنسول (Test Live URL) : از بررسی ایندکس تا خطایابی موبایل و اسکیما

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

برای دریافت آموزش رایگان سرچ کنسول کلیک کنید: آموزش رایگان سرچ کنسول

خوشبختانه، گوگل یک ابزار فوق‌العاده برای این کار دارد. قابلیت «تست لایو» (Test Live URL) که بخشی از ابزار URL Inspection در سرچ کنسول است، به ما اجازه می‌دهد در لحظه ببینیم گوگل‌بات چه چیزی را رندر می‌کند. در این راهنما، به عنوان یک همراه متخصص، به شما نشان می‌دهم چطور از این قابلیت برای عیب‌یابی فنی و جلو افتادن از مشکلات استفاده کنید.

جدول کاربردی: تفاوت تست لایو در سرچ کنسول (Test Live URL) با گزارش ایندکس

تست لایو در سرچ کنسول (Test Live URL) چیست و چرا ابزاری حیاتی برای سئوکاران است؟

سلام! «تست لایو» (Test Live URL) یکی از قابلیت‌های فوق‌العاده کاربردی در ابزار URL Inspection سرچ کنسول گوگله.

به زبان ساده، وقتی شما یک URL رو در سرچ کنسول بازرسی (Inspect) می‌کنید، گوگل اول به شما گزارش وضعیت ایندکس شده (یعنی آخرین نسخه‌ای که در حافظه‌اش ذخیره کرده) رو نشون می‌ده. اما «تست لایو» این کار رو نمی‌کنه.

وقتی دکمه «Test Live URL» رو می‌زنید، گوگل‌بات در همان لحظه (Real-time) به سرور شما مراجعه می‌کنه، صفحه رو فراخوانی (Fetch) و رندر (Render) می‌کنه و به شما میگه همین الان چه چیزی رو می‌بینه.

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

تفاوت کلیدی تست لایو در سرچ کنسول (Test Live URL) با گزارش وضعیت ایندکس (URL is on Google)

این تفاوت خیلی مهمه و اغلب باعث سردرگمی می‌شه. بیایید این دو رو با یک مثال ساده مقایسه کنیم:

• گزارش وضعیت ایندکس (URL is on Google):
  • این مثل یک «عکس فوری» قدیمی از صفحه شماست.
  • به شما نشون می‌ده که گوگل در آخرین باری که صفحه شما رو خزش (Crawl) کرده، چه چیزی دیده و در پایگاه داده خودش (ایندکس) ذخیره کرده.
  • این گزارش تاریخی (Historical) است. اگر شما ۵ دقیقه پیش تغییری در صفحه داده باشید، این گزارش اون تغییر رو نشون نمی‌ده.
• تست لایو (Test Live URL):
  • این مثل باز کردن «دوربین مداربسته زنده» یا یک «تماس تصویری» با صفحه شماست.
  • به شما نشون می‌ده که گوگل‌بات همین الان، در لحظه تست، چه چیزی رو می‌بینه.
  • این گزارش لحظه‌ای (Real-time) است. اگر همین الان تغییری ایجاد کنید و بلافاصله تست لایو بگیرید، اون تغییر رو می‌بینید.

نکته کلیدی: اگر صفحه‌ای رو به‌روزرسانی کردید (مثلاً تخصص و تجربه بیشتری به محتوا اضافه کردید )، گزارش ایندکس ممکنه هنوز نسخه قدیمی رو نشون بده، اما تست لایو نسخه جدید رو به شما نشون خواهد داد.

چه زمانی باید از قابلیت تست لایو در سرچ کنسول (Test Live URL) استفاده کنیم؟ (سناریوهای عملی)

ما به عنوان متخصص سئو، در موقعیت‌های خاصی به سراغ این ابزار می‌ریم:

۱. بعد از انتشار یا به‌روزرسانی محتوا: * شما یک مقاله جدید منتشر کردید یا یک صفحه قدیمی رو به‌روزرسانی اساسی کردید (مثلاً برای بهبود کیفیت و نگارش ). * بلافاصله «تست لایو» می‌گیرید تا مطمئن بشید گوگل می‌تونه صفحه رو ببینه، محتوای جدید رو رندر کنه و هیچ خطای فنی (مثل noindex اشتباهی) وجود نداره.

۲. عیب‌یابی (Debugging) مشکلات ایندکس: * صفحه‌ای دارید که در گزارش ایندکس با خطا مواجه شده (مثلاً “Crawled – currently not indexed” یا “Discovered – currently not indexed”). * «تست لایو» می‌گیرید تا ببینید الان وضعیت چطوره. شاید مشکل قبلاً برطرف شده باشه. این تست به شما میگه آیا صفحه «قابل ایندکس شدن» (Indexable) هست یا نه.

۳. بررسی مشکلات رندر (Render): * می‌خواید مطمئن بشید که جاوا اسکریپت سایت به درستی رندر می‌شه و گوگل محتوای اصلی رو می‌بینه. تست لایو به شما اسکرین‌شات و کدهای HTML رندر شده رو می‌ده.

۴. تست Mobile-Friendly بودن: * تست لایو به شما میگه که آیا صفحه شما از نظر گوگل‌باتِ موبایل، «Mobile-Friendly» محسوب می‌شه یا نه.

۵. بررسی وضعیت کدهای اسکیما (Rich Results): * اگر کدهای اسکیما (مثل FAQ, Product و…) اضافه کردید، تست لایو به شما میگه آیا گوگل اون‌ها رو در نسخه زنده شناسایی کرده و آیا معتبر هستن یا نه.

پیش‌نیازها: دسترسی به ابزار بازرسی URL (URL Inspection Tool) در سرچ کنسول

استفاده از این قابلیت خیلی ساده‌ست و پیش‌نیاز پیچیده‌ای نداره:

۱. شما باید به گوگل سرچ کنسول (Google Search Console) سایتی که می‌خواید بررسی کنید، دسترسی داشته باشید (حداقل دسترسی Read). ۲. وارد سرچ کنسول بشید و در نوار جستجوی بالای صفحه (که نوشته “Inspect any URL in…”)، آدرس دقیق صفحه‌ای که می‌خواید تست کنید رو وارد کنید و Enter بزنید. ۳. سرچ کنسول ابتدا گزارش وضعیت ایندکس شده (داده‌های تاریخی) رو به شما نشون می‌ده. ۴. در بالای صفحه، سمت راست، روی دکمه «TEST LIVE URL» کلیک کنید. ۵. باید چند ثانیه (گاهی تا یکی دو دقیقه) صبر کنید تا گوگل صفحه رو به صورت زنده فراخوانی و تحلیل کنه. بعد از اون، گزارش نسخه زنده به شما نمایش داده می‌شه.

آموزش گام به گام اجرای تست لایو URL در گوگل سرچ کنسول

انجام «تست لایو» (Test Live URL) در سرچ کنسول یک فرایند ساده اما حیاتی برای عیب‌یابی و اطمینان از سلامت فنی صفحات ماست. بیایید گام به گام ببینیم چطور باید این کار را انجام دهیم.

نحوه دسترسی به ابزار URL Inspection

اولین قدم، پیدا کردن خود ابزار است.

۱. وارد حساب کاربری گوگل سرچ کنسول (Google Search Console) سایتی شوید که قصد بررسی آن را دارید. ۲. در بالای صفحه، یک نوار جستجو وجود دارد که معمولاً با متن “Inspect any URL in…” (یا معادل فارسی آن) مشخص شده است. ۳. این نوار، ورودی اصلی ابزار URL Inspection شماست.

وارد کردن URL و اجرای تست اولیه (بررسی وضعیت ایندکس شده)

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

۱. URL کامل صفحه‌ای را که می‌خواهید بررسی کنید (همراه با https://www یا non-www) کپی کنید. ۲. آن را در نوار جستجوی ابزار URL Inspection که در مرحله قبل پیدا کردیم، Paste کنید. ۳. کلید Enter را بزنید. ۴. سرچ کنسول ابتدا گزارشی با عنوان “URL is on Google” (اگر صفحه ایندکس شده باشد) یا “URL is not on Google” (اگر ایندکس نشده باشد) به شما نشان می‌دهد.

نکته مهم: این گزارشی است که می‌بینید، وضعیت تاریخی (Historical) صفحه شماست؛ یعنی آخرین نسخه‌ای که گوگل آن را خزش کرده و در پایگاه داده‌اش ذخیره کرده است. این گزارش، وضعیت همین لحظه صفحه شما را نشان نمی‌دهد.

کلیک بر روی “Test Live URL” و انتظار برای نتایج زنده

حالا وقت آن است که ببینیم گوگل همین الان چه چیزی از صفحه ما می‌بیند.

• در همان صفحه‌ی گزارش اولیه (وضعیت ایندکس شده)، به دنبال دکمه‌ای در گوشه سمت راست بالای صفحه بگردید که روی آن نوشته شده: “TEST
• LIVE URL. روی این دکمه کلیک کنید.
• یک صفحه بارگذاری (Loading) ظاهر می‌شود. در این مرحله، گوگل‌بات به صورت زنده (Real-time) در حال فراخوانی (Fetch) و رندر کردن (Render) صفحه شماست. این فرایند ممکن است بین چند ثانیه تا یکی دو دقیقه طول بکشد.
• پس از اتمام تست، نتایج جدیدی به شما نشان داده می‌شود. این گزارش زنده به شما می‌گوید که آیا صفحه در همین لحظه قابل ایندکس شدن (Available for indexing) است یا خیر. همچنین اطلاعات حیاتی دیگری مثل وضعیت Mobile-Friendly بودن و شناسایی کدهای اسکیما (Rich Results) در نسخه زنده را به شما می‌دهد.

اقدام کلیدی پس از تست: درخواست ایندکس (Request Indexing)

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

۱. اگر «تست لایو» موفقیت‌آمیز بود (یعنی نشان داد که صفحه “Available” یا قابل ایندکس است) و شما: * یک صفحه جدید منتشر کرده‌اید. * یا تغییرات مهمی در یک صفحه قدیمی ایجاد کرده‌اید (مثلاً محتوای E-E-A-T را تقویت کرده‌اید یا یک خطای فنی را برطرف نموده‌اید). ۲. می‌توانید روی دکمه “Request Indexing” (درخواست ایندکس) کلیک کنید. ۳. این دکمه (که معمولاً پس از اجرای تست لایو فعال‌تر دیده می‌شود) به گوگل سیگنال می‌دهد که صفحه شما آماده بررسی مجدد است.

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

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

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

بخش ۱: بررسی قابلیت ایندکس شدن (Indexing) و خزش (Crawl)

این اولین و مهم‌ترین چیزیه که باید بهش نگاه کنیم.

در بالای گزارش تست لایو، وضعیتی به اسم “Availability” (وضعیت در دسترس بودن) وجود داره.

• وضعیت ایده‌آل (سبز): “URL is available to Google”
  • این یعنی صفحه از نظر فنی هیچ مشکلی برای خزش و ایندکس شدن نداره. گوگل می‌تونه اون رو ببینه و (اگر بخواد) ایندکسش کنه.
  • در این حالت، باید جزئیات پایین‌تر مثل “Crawl allowed?” (اجازه خزش؟) و “Indexing allowed?” (اجازه ایندکس؟) هر دو “Yes” باشن.
• وضعیت هشدار (قرمز یا خاکستری): “URL is not available to Google”
  • این یعنی یک مشکل جدی وجود داره. گوگل نمی‌تونه صفحه رو ایندکس کنه.
  • دلایل رایج:
    • Blocked by robots.txt: فایل robots.txt شما جلوی دسترسی گوگل به این URL رو گرفته.
    • ‘noindex’ detected: یک تگ meta robots با مقدار noindex در صفحه‌تون وجود داره که به گوگل دستور می‌ده این صفحه رو ایندکس نکنه. (این اشتباهی رایجه که گاهی بعد از طراحی مجدد سایت یا روی صفحات اصلی بلاگ اتفاق میفته).
    • Server error (5xx) / Not found (404): در لحظه تست، سرور شما در دسترس نبوده یا صفحه حذف شده بوده.

اگر با وضعیت قرمز مواجه شدید، قبل از هر کار دیگه‌ای، باید همین مشکل اصلی رو برطرف کنید.

بخش ۲: خطایابی قابلیت استفاده در موبایل (Mobile Usability)

از اونجایی که گوگل از ایندکس‌گذاری موبایل-اول (Mobile-First Indexing) استفاده می‌کنه، این بخش فوق‌العاده مهمه. حتی اگر صفحه شما قابل ایندکس باشه، اما در موبایل تجربه بدی ایجاد کنه، رتبه خوبی نمی‌گیره.

• وضعیت ایده‌آل (سبز): “Page is mobile friendly”
  • یعنی صفحه شما تست‌های گوگل رو پاس کرده و همه‌چیز خوبه.
• وضعیت هشدار (قرمز): “Page is not mobile friendly”
  • این یعنی صفحه شما حداقل یک خطای جدی در نمایش موبایل داره. در ادامه، رایج‌ترین خطاها رو بررسی می‌کنیم.

رایج‌ترین خطاهای موبایل (مانند Content wider than screen و Clickable elements too close) و نحوه رفع آن‌ها

وقتی گوگل میگه صفحه “Mobile-Friendly” نیست، معمولاً منظورش یکی از این موارد تجربه کاربری (UX) هست:

۱. Content wider than screen (محتوا عریض‌تر از صفحه) * مشکل چیه؟ کاربر برای خوندن متن یا دیدن کامل محتوا، مجبوره صفحه رو به چپ و راست اسکرول کنه. * علت رایج: معمولاً یک عکس با عرض ثابت (مثلاً width: 800px) یا یک جدول که در موبایل به هم نمی‌ریزه، باعث این مشکل می‌شه. * راه حل (تجربه عملی): * برای عکس‌ها: مطمئن بشید در CSS، ویژگی max-width: 100% و height: auto رو دارن تا بزرگتر از صفحه نشن. * برای جداول: بهترین راه حل اینه که جدول رو ریسپانسیو کنید، یا حداقل اون رو داخل یک div با overflow-x: auto قرار بدید تا فقط خود جدول اسکرول افقی بخوره، نه کل صفحه.

۲. Clickable elements too close together (عناصر قابل کلیک خیلی نزدیک به هم) * مشکل چیه؟ دکمه‌ها، لینک‌ها، یا آیتم‌های منو اونقدر به هم چسبیدن که کاربر (مخصوصاً با انگشت شست) نمی‌تونه به راحتی روی یکی از اون‌ها بزنه و ممکنه اشتباهی روی لینک کناری کلیک کنه. * راه حل (تجربه عملی): فضای خالی (Padding یا Margin) بین عناصر قابل کلیک رو افزایش بدید. گوگل توصیه می‌کنه که “فضای لمسی” (Tap Target) حداقل ۴۸ در ۴۸ پیکسل باشه تا کاربر راحت کلیک کنه.

۳. Text too small to read (متن برای خواندن خیلی کوچک است) * مشکل چیه؟ کاربر باید برای خوندن متن، روی صفحه زوم کنه. * راه حل (تجربه عملی): اول مطمئن بشید تگ viewport رو در <head> صفحه‌تون دارید (<meta name=”viewport” content=”width=device-width, initial-scale=1″>). بعد، یک اندازه فونت پایه مناسب (مثلاً 16px) برای متن اصلی در نظر بگیرید.

بخش ۳: اعتبارسنجی داده‌های ساختاریافته (Schema & Rich Results)

این بخش به ما میگه آیا کدهای اسکیمایی که برای گرفتن نتایج غنی (Rich Results) مثل ستاره‌دار شدن محصول، سوالات متداول (FAQ) یا دستور پخت (Recipe) اضافه کردیم، توسط گوگل به درستی دیده و فهمیده شدن یا نه.

• اگر نوشته “No items detected” یعنی گوگل در نسخه زنده هیچ اسکیمایی پیدا نکرده. (شاید اسکیما شکسته باشه یا اصلاً در صفحه نباشه).
• اگر اسکیما رو پیدا کنه، انواع اون رو لیست می‌کنه (مثلاً Product, FAQPage).

شناسایی تفاوت خطاهای اسکیما (Errors) در مقابل هشدارها (Warnings)

این تفاوت خیلی مهمه و روی نمایش نتایج غنی شما تأثیر مستقیم داره:

• Errors (خطاها – آیکون قرمز)
  • اهمیت: بسیار بالا. این‌ها مشکلات اساسی هستن که ساختار اسکیما رو می‌شکنن.
  • نتیجه: اگر حتی یک “Error” داشته باشید، گوگل اون نوع اسکیما رو به طور کامل نادیده می‌گیره و شما هیچ ریچ ریزالتی برای اون دریافت نخواهید کرد.
  • مثال: در اسکیمای Product، فیلد name (نام محصول) که اجباریه رو وارد نکردید.
  • اقدام: باید حتماً برطرف بشن.
• Warnings (هشدارها – آیکون زرد)
  • اهمیت: متوسط. این‌ها خطا نیستن، بلکه «توصیه‌هایی» برای بهبود هستن.
  • نتیجه: گوگل اسکیما رو می‌فهمه و ممکنه ریچ ریزالت رو نشون بده، اما شاید ناقص باشه.
  • مثال: در اسکیمای Product، فیلد aggregateRating (امتیاز ستاره‌ای) یا review (نقد) رو وارد نکردید. اسکیما هنوز معتبره، اما گوگل به شما هشدار می‌ده که “برای تجربه بهتر، این فیلد پیشنهادی رو اضافه کن”.
  • اقدام: برطرف کردن اون‌ها به شدت توصیه می‌شه، چون مستقیماً روی جذابیت بصری و نرخ کلیک (CTR) شما در نتایج جستجو تأثیر دارن.

مشاهده کدهای رندر شده (View Rendered Page) برای خطایابی پیشرفته جاوا اسکریپت

این یکی از ابزارهای قدرتمند برای ما سئوکارهاست، مخصوصاً وقتی با سایت‌هایی کار می‌کنیم که به شدت به جاوا اسکریپت وابسته‌ هستن.

بعد از اتمام تست لایو، لینکی وجود داره به اسم “VIEW TESTED PAGE” (مشاهده صفحه تست شده).

با کلیک روی اون، سه تب در اختیار شما قرار می‌گیره:

۱. Screenshot (اسکرین‌شات): * به شما نشون می‌ده گوگل‌بات صفحه شما رو دقیقاً چطور دیده. آیا شبیه چیزیه که کاربر می‌بینه؟ یا یک صفحه سفید یا یک آیکون لودینگ بی‌پایانه؟ (این نشونه مشکل جدی در رندر جاوا اسکریپته).

۲. HTML (کد HTML رندر شده): * نکته کلیدی: این کدی نیست که شما با زدن Ctrl+U (View Source) می‌بینید. این کدیه که بعد از اجرای جاوا اسکریپت‌ها توسط گوگل تولید شده. * کاربرد: اگر محتوای اصلی یا اسکیمای شما با جاوا اسکریپت به صفحه اضافه می‌شه، باید بیاید اینجا و با Ctrl+F جستجو کنید. آیا اون محتوا یا تگ‌های اسکیما در این کد وجود دارن؟ اگر نه، یعنی گوگل اصلاً اون‌ها رو نمی‌بینه و تمام زحمات شما برای تولید محتوا و اسکیما هدر رفته.

۳. More Info (اطلاعات بیشتر): * این بخش خطاهای کنسول جاوا اسکریپت (JavaScript console errors) و منابعی که لود نشدن (Page resources) رو نشون می‌ده. مثلاً اگر یک فایل CSS یا JS به خاطر robots.txt بلاک شده باشه، اینجا می‌تونید ببینید و مشکل رو به تیم فنی گزارش بدید.

فراتر از سرچ کنسول: ابزارهای کمکی برای اعتبارسنجی موبایل و اسکیما

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

خوشبختانه، گوگل چند ابزار کمکی عالی در اختیارمون گذاشته که می‌تونیم همزمان با سرچ کنسول ازشون استفاده کنیم، مخصوصاً برای بررسی دقیق‌تر اسکیما و وضعیت موبایل. بیایید این ابزارها رو بررسی کنیم.

استفاده همزمان از Rich Results Test (تست نتایج غنی) گوگل

این ابزار، یکی از بهترین دوستان ما برای کارهای مربوط به اسکیما (Schema) و نتایج غنی (Rich Results) است.

• کاربرد اصلی: این ابزار به صورت تخصصی روی این موضوع تمرکز داره که آیا صفحه شما واجد شرایط نمایش در نتایج غنی گوگل (مثل ستاره‌های امتیازدهی، سوالات متداول، دستور پخت و…) هست یا نه.
• چطور کار می‌کنه: شما می‌تونید URL صفحه رو بهش بدید یا مستقیماً قطعه کد (Code Snippet) اسکیما رو در اون کپی کنید.
• مزیت کلیدی (تجربه عملی):
  1. تست قبل از انتشار: شما می‌تونید کد اسکیمایی که نوشتید رو قبل از اینکه اصلاً روی سایت منتشر کنید، در این ابزار تست کنید.
  2. تست سایت رقبا: بر خلاف سرچ کنسول که فقط برای سایت خودتونه، این ابزار عمومی (Public) است. می‌تونید URL رقبای خودتون رو وارد کنید و ببینید اون‌ها از چه نوع اسکیمایی استفاده کردن و آیا خطایی دارن یا نه.
• ارتباط با سرچ کنسول: نتایجی که این ابزار در مورد اسکیما به شما نشون می‌ده، باید دقیقاً با نتایج بخش «داده‌های ساختاریافته» (Structured Data) در تست لایو سرچ کنسول یکسان باشه.

استفاده از Schema Markup Validator (اعتبارسنج رسمی نشانه گذاری اسکیما)

این ابزار کمی فنی‌تره و نباید با Rich Results Test اشتباه گرفته بشه.

• تاریخچه: این ابزار در واقع جانشین ابزار قدیمی و محبوب گوگل یعنی «Structured Data Testing Tool» شده و الان توسط خودِ مجموعه Schema.org (که استاندارد اسکیما رو تعریف می‌کنه) میزبانی می‌شه.
• تفاوت کلیدی:
  • Rich Results Test (ابزار قبلی) به شما میگه آیا اسکیمای شما برای گوگل و برای نمایش نتایج غنی معتبره یا نه.
  • Schema Markup Validator به شما میگه آیا اسکیمای شما از نظر سینتکس (Syntax) و استانداردهای کلی Schema.org معتبره یا نه، حتی اگر گوگل از اون اسکیما برای نتایج غنی استفاده نکنه.
• چه زمانی استفاده کنیم؟

• 1. وقتی می‌خواید مطمئن بشید که ساختار کلی کد شما (مثلاً JSON-LD) درسته.
  2. وقتی دارید از انواع اسکیمای خیلی خاص یا جدید استفاده می‌کنید که گوگل مستقیماً اون‌ها رو به عنوان ریچ ریزالت پشتیبانی نمی‌کنه، اما می‌خواید به هر حال اون اطلاعات معنایی رو به موتورهای جستجو بدید.
  3. برای عیب‌یابی‌های خیلی فنی و پیشرفته که چرا یک اسکیما اصلاً شناسایی نمی‌شه.

بررسی مجدد با ابزار Mobile-Friendly Test گوگل

این هم یک ابزار عمومی و بسیار پرکاربرد دیگه از طرف گوگل هست.

• کاربرد اصلی: همونطور که از اسمش پیداست، به صورت متمرکز و سریع فقط یک چیز رو بررسی می‌کنه: آیا صفحه شما از نظر گوگل «Mobile-Friendly» (سازگار با موبایل) هست یا نه.
• ارتباط با سرچ کنسول: نتایج این ابزار دقیقاً معادل همون چیزیه که در بخش «Mobile Usability» در «تست لایو» (Test Live URL) سرچ کنسول می‌بینید.
• مزیت کلیدی (تجربه عملی):
  1. سرعت: گاهی اوقات شما فقط می‌خواید سریع چک کنید که آیا اون خطای «Content wider than screen» که در CSS اصلاح کردید، برطرف شده یا نه. نیازی به باز کردن سرچ کنسول و چند مرحله کلیک اضافه نیست.
  2. ابزار عمومی: مثل Rich Results Test، این ابزار هم عمومیه. می‌تونید سریع صفحات رقبای خودتون رو از نظر موبایل-فرندلی بودن بررسی کنید.
  3. ارائه اسکرین‌شات: این ابزار هم به شما اسکرین‌شات رندر شده در موبایل رو می‌ده تا دقیقاً ببینید گوگل چه چیزی رو دیده.

استفاده ترکیبی از این ابزارها در کنار تست لایو سرچ کنسول، به ما کمک می‌کنه که یک دید ۳۶۰ درجه و بسیار دقیق از وضعیت فنی صفحاتمون داشته باشیم.

اشتباهات رایج و نکات تخصصی (Experience) در هنگام استفاده از تست لایو در سرچ کنسول (Test Live URL)

سلام! ابزار «تست لایو» (Test Live URL) یکی از بهترین ابزارهای ما برای عیب‌یابی فنیه، اما همونقدر هم می‌تونه باعث سوءتفاهم بشه. به عنوان کسی که روزانه با این ابزار کار می‌کنه، می‌خوام چند تا از اشتباهات رایج و نکات تجربی که به دست آوردم رو باهات در میون بذارم.

چرا تست لایو “سبز” است اما صفحه من هنوز ایندکس نمی‌شود؟

این رایج‌ترین و مهم‌ترین سوالیه که پیش میاد. دیدن پیام سبز “URL is available to Google” در تست لایو، حس خوبی داره، اما اغلب می‌بینیم که اون صفحه هفته‌ها در وضعیت “Crawled – currently not indexed” یا “Discovered – currently not indexed” باقی می‌مونه.

دلیلش یک تفاوت اساسیه:

• تست لایو (Live Test): فقط به سوال «آیا از نظر فنی مانعی برای دیدن این صفحه وجود دارد؟» جواب می‌ده. (مثل قفل بودن در با robots.txt یا دستور noindex).
• ایندکس شدن (Indexing): جواب گوگل به سوال «آیا این صفحه ارزش کافی برای قرار گرفتن در پایگاه داده من و نمایش به کاربران را دارد؟» هست.

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

دلایل تجربی (Experience) عدم ایندکس با وجود تست لایو سبز:

• کیفیت پایین یا عدم ارزش افزوده: گوگل صفحه رو دیده، اما تشخیص داده که این محتوا به اندازه کافی مفید نیست. شاید محتوا صرفاً بازنویسی یا خلاصه‌ای از منابع دیگه بوده و ارزش افزوده قابل توجهی ارائه نداده.
• عدم ارائه تحلیل عمیق: ممکنه محتوا اطلاعات بدیهی رو گفته باشه و تحلیل عمیق یا اطلاعات جالبی فراتر از چیزهای واضح ارائه نکرده باشه.
• عدم اعتبار (E-E-A-T): ممکنه سایت شما هنوز اعتبار کافی (Authority) در اون موضوع خاص رو نداشته باشه، یا محتوا فاقد شواهد تخصص (Expertise) یا اعتماد (Trust) باشه.
• مشکلات بودجه خزش (Crawl Budget): در سناریوی “Discovered – currently not indexed”، گوگل می‌دونه صفحه وجود داره (تست لایو هم اینو تایید می‌کنه)، اما به دلیل اعتبار پایین سایت یا ساختار لینک‌دهی داخلی ضعیف، هنوز نوبت خزش رو به اون صفحه اختصاص نداده.

پس یادت باشه: سبز بودن تست لایو فقط اجازه ورود به مسابقه است، نه برنده شدن در اون.

محدودیت‌های ابزار تست لایو (Live Test Limitations) که باید بدانید

این ابزار عالیه، اما همه‌کار نیست. باید محدودیت‌هاش رو بشناسیم:

• ایندکس را تضمین نمی‌کند: همونطور که گفتیم، این ابزار فقط «بررسی» می‌کنه، نه «ایندکس».
• از بودجه خزش شما استفاده نمی‌کند: این یک نکته مثبته. وقتی شما «Test Live URL» رو می‌زنید، این یک فراخوانی خارج از صف و با اولویت بالا برای تست هست و بودجه خزش عادی (Crawl Budget) سایت شما رو مصرف نمی‌کنه.
• تست آزمایشگاهی (Lab) است، نه میدانی (Field): این ابزار Core Web Vitals (سرعت صفحه) رو به صورت میدانی (بر اساس تجربه کاربران واقعی) تست نمی‌کنه. این یک رندر آزمایشگاهی در دیتاسنتر گوگل هست.
• سهمیه (Quota) روزانه دارد: شما نمی‌تونید در یک روز هزاران URL رو تست لایو کنید. گوگل برای هر Property (هر سایت) یک محدودیت روزانه در نظر گرفته.
• وضعیت کوکی‌ها و Location: تست لایو معمولاً از یک موقعیت جغرافیایی مشخص (معمولاً آمریکا) و بدون کوکی (مثل یک کاربر ناشناس) انجام می‌شه. اگر سایت شما محتوای متفاوتی بر اساس موقعیت مکانی یا لاگین بودن کاربر نشون می‌ده، ممکنه چیزی که تست لایو می‌بینه با چیزی که شما انتظار دارید، متفاوت باشه.

تاثیر فایل Robots.txt و تگ Noindex بر نتایج تست لایو

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

۱. تاثیر فایل Robots.txt:

• چه اتفاقی می‌افتد؟ اگر صفحه‌ای توسط robots.txt شما Disallow شده باشه، این مثل یک دیوار آجری جلوی درِ ورودی عمل می‌کنه.
• نتیجه تست لایو: تست فورا شکست می‌خوره (Fail).
• پیام: گوگل به شما پیام واضحی مثل “Crawl blocked by robots.txt” (خزش توسط robots.txt مسدود شد) یا “URL is not available to Google” می‌ده.
• نکته تجربی: در این حالت، گوگل اصلاً به محتوای صفحه دسترسی پیدا نمی‌کنه. یعنی حتی نمی‌فهمه که آیا اون صفحه تگ noindex داشته یا نه.

۲. تاثیر تگ Noindex:

• چه اتفاقی می‌افتد؟ اینجا درِ ورودی (robots.txt) بازه. گوگل‌بات وارد صفحه می‌شه، کل محتوا، کدها و تگ‌های HTML رو می‌خونه.
• نتیجه تست لایو: تست موفقیت‌آمیز (سبز) خواهد بود! (“URL is available to Google”).
• پیام: اینجاست که نکته ظریفش مشخص می‌شه. اگر بخش “Availability” رو باز کنید، می‌بینید:
  • Crawl allowed? (اجازه خزش؟) Yes
  • Indexing allowed? (اجازه ایندکس؟) No
• دلیل: گوگل به صراحت می‌نویسه: “‘noindex’ detected in ‘robots’ meta tag” (تگ noindex شناسایی شد).

خلاصه تجربی:

• Robots.txt: گوگل اصلاً صفحه رو نمی‌بینه (تست لایو قرمز).
• Noindex: گوگل صفحه رو کامل می‌بینه، اما به دستور شما احترام می‌گذاره و ایندکسش نمی‌کنه (تست لایو سبز، اما با اخطار No).

جمع‌بندی (تست لایو در سرچ کنسول (Test Live URL))

در نهایت، یادتان باشد که «تست لایو» (Test Live URL) ابزار تشخیص و عیب‌یابی شماست، نه دکمه جادویی ایندکس!

سبز بودن این تست (وضعیت “Available”) فقط به ما می‌گوید که از نظر فنی، مانعی برای ورود گوگل به صفحه وجود ندارد. اما ایندکس شدن، به کیفیت محتوا، اعتبار سایت (E-E-A-T) و ارزشی بستگی دارد که برای کاربر ایجاد می‌کنید. همان‌طور که در فایل راهنما دیدیم، محتوا باید تحلیل عمیق ارائه دهد و صرفاً بازنویسی منابع دیگر نباشد.

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