زمان مطالعه: 23 دقیقه

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

گوگل دقیقاً همین رفتار را دنبال می‌کند؛ نه به این معنا که یک «امتیاز تجربه کاربری» مخفی برای هر صفحه محاسبه و مستقیماً در رتبه ضرب می‌کند، بلکه به این معنا که کل اکوسیستم رتبه‌بندی گوگل حول این ایده ساخته شده که نتیجه‌ای که به کاربر نشان داده می‌شود باید هم مفید باشد و هم قابل استفاده. محتوای عالی در صفحه‌ای که تجربه بدی ارائه می‌دهد، در عمل ارزش خودش را از دست می‌دهد. این همان جایی است که مفهوم Page Experience وارد می‌شود.

در این مقاله از پیام آوا پردازش، Page Experience گوگل را از صفر تا صد بررسی می‌کنیم: تعریف دقیق آن، تفاوتش با Core Web Vitals، جایگاه واقعی‌اش در رتبه‌بندی، و مهم‌تر از همه، اینکه چگونه می‌توان آن را به‌صورت عملی بهبود داد — بدون افتادن در دام اشتباهات رایجی که خیلی از سایت‌ها و انجام آن‌ها به‌جای بهتر شدن، بدتر می‌کند.

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

در ادامه، دقیق‌تر بررسی می‌کنیم که گوگل چگونه مجموعه‌ای از سیگنال‌ها و الگوریتم های گوگل را برای ارزیابی کیفیت نتایج جست‌وجو به کار می‌گیرد و Page Experience در این میان چه جایگاهی دارد.

Page Experience گوگل چیست؟

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

نکته مهمی که باید همین ابتدا روشن شود: Page Experience یک امتیاز واحد یا یک الگوریتم مستقل نیست. هیچ عددی به نام «امتیاز Page Experience» در گزارش‌های گوگل یا در فرآیند رتبه‌بندی وجود ندارد که مستقیماً روی هر صفحه محاسبه و اعمال شود. این یک برداشت اشتباه رایج است که از دوران معرفی «Page Experience Update» در سال ۲۰۲۱ باقی مانده است.

ساختار Page Experience
Page Experience
یک امتیاز واحد نیست؛ مجموعه‌ای از سیگنال‌های تجربه صفحه است.
Core Web Vitals
عملکرد و پاسخ‌گویی
Mobile-Friendly
تجربه مناسب موبایل
HTTPS
امنیت اتصال
امنیت و تبلیغات
محتوای مخرب و مزاحمت
نکته کلیدی:
این عوامل با یک فرمول واحد ترکیب نمی‌شوند تا یک «امتیاز Page Experience» بسازند.

خود گوگل به‌صراحت این موضوع را روشن کرده: Page Experience یک «سیستم رتبه‌بندی» مستقل نیست، بلکه مجموعه‌ای از سیگنال‌ها است که توسط سیستم‌های اصلی رتبه‌بندی گوگل (مانند سیستم‌های مرتبط با کیفیت محتوا) در نظر گرفته می‌شوند. دنی سالیوان، مسئول ارتباطات جست‌وجوی گوگل، توضیح داده که حذف Page Experience از فهرست سیستم‌های رتبه‌بندی به این معنا نیست که این جنبه‌ها دیگر در نظر گرفته نمی‌شوند؛ بلکه این جنبه‌ها هرگز خودشان یک «سیستم» مستقل نبودند، بلکه سیگنال‌هایی بودند که سیستم‌های دیگر از آن‌ها استفاده می‌کنند.

به زبان ساده: Page Experience چتری است که چند عامل فنی و تجربی زیر آن قرار می‌گیرند — Core Web Vitals، سازگاری با موبایل، امنیت اتصال (HTTPS)، نبود محتوای مخرب، و نبود تبلیغات مزاحم. این عوامل به‌صورت جداگانه توسط سیستم‌های مختلف گوگل بررسی می‌شوند، نه به‌صورت یک فرمول واحد که خروجی‌اش یک عدد نهایی باشد.

Page Experience چه ارتباطی با رتبه‌بندی گوگل دارد؟

اینجا جایی است که باید بین «مهم بودن» و «تعیین‌کننده بودن» تفاوت قائل شد.

نقش سیگنال‌ها در رتبه‌بندی
Page Experience مکمل است، نه جایگزین
کیفیت و ارتباط محتوا
نقش بنیادی
Page Experience
نقش تکمیلی
تجربه صفحه می‌تواند بین صفحاتی که از نظر کیفیت و ارتباط محتوا به یکدیگر نزدیک هستند، تفاوت ایجاد کند؛ اما به‌تنهایی جای محتوای بهتر را نمی‌گیرد.

صفحه Page Experience یک سوئیچ روشن‌وخاموش نیست؛ مجموعه‌ای از ورودی‌ها است که به سیستم‌های گسترده‌تر کیفیت و رتبه‌بندی مجدد گوگل می‌رود. یعنی گوگل ابتدا صفحاتی را که از نظر محتوا، ارتباط با عبارت جست‌وجو (Relevance) و همسویی با هدف کاربر (Search Intent) واجد شرایط رتبه بالا هستند شناسایی می‌کند، و در مرحله‌ای دیگر، سیگنال‌های تجربه صفحه می‌توانند به‌عنوان یک عامل تفکیک‌کننده (Tie-breaker) بین صفحاتی که از نظر کیفیت محتوایی نزدیک به هم هستند عمل کنند.

به همین دلیل است که می‌بینیم صفحاتی با سرعت متوسط، گاهی رتبه بهتری نسبت به صفحات فوق‌سریع اما با محتوای ضعیف‌تر می‌گیرند. کیفیت، عمق و مرتبط بودن محتوا همچنان عامل غالب هستند؛ Page Experience نقش تکمیلی و تنظیم‌کننده دارد، نه بنیادین.

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

این نکته به‌ویژه بعد از بازنگری‌های گوگل در سال‌های اخیر روشن‌تر شده است. در فوریه ۲۰۲۴ و در بازنویسی مستندات مارس همان سال، گوگل تلاش کرد این تصور را که Page Experience یک «چک‌لیست برای گرفتن تیک» است کنار بگذارد و آن را به‌عنوان یک راهنمای مستمر برای بهبود کیفیت سایت معرفی کند. گزارش Page Experience هم از Google Search Console حذف شد، اما داده‌های مربوط به Core Web Vitals و HTTPS در گزارش‌های جداگانه در دسترس ماندند — یعنی حذف گزارش به معنای حذف اهمیت این سیگنال‌ها نبود.

مهم‌ترین عوامل Page Experience

Core Web Vitals

Core Web Vitals مجموعه‌ای از معیارهای کمّی هستند که گوگل برای اندازه‌گیری تجربه واقعی کاربران هنگام بارگذاری و تعامل با یک صفحه تعریف کرده است. این معیارها بر پایه داده‌های واقعی کاربران در مرورگر کروم (از طریق Chrome UX Report یا به‌اختصار CrUX) جمع‌آوری می‌شوند، نه صرفاً روی شبیه‌سازی آزمایشگاهی.


آستانه‌های Core Web Vitals

چه زمانی یک صفحه «خوب» محسوب می‌شود؟
وضعیت Core Web Vitals بر اساس داده‌های واقعی کاربران و صدک ۷۵ ارزیابی می‌شود.
LCP
بارگذاری
≤ ۲.۵ ثانیه
۲.۵ تا ۴ ثانیه: نیازمند بهبود
بیش از ۴ ثانیه: ضعیف
INP
تعامل
≤ ۲۰۰ ms
۲۰۰ تا ۵۰۰ ms: نیازمند بهبود
بیش از ۵۰۰ ms: ضعیف
CLS
پایداری
≤ ۰.۱
۰.۱ تا ۰.۲۵: نیازمند بهبود
بیش از ۰.۲۵: ضعیف
نکته مهم:
برای دریافت وضعیت «خوب»، صدک ۷۵ داده‌های واقعی کاربران باید در محدوده Good قرار داشته باشد؛ بنابراین صرفاً داشتن یک نتیجه خوب در تست آزمایشگاهی به‌تنهایی به معنای Good بودن تجربه واقعی کاربران نیست.

مهم است تاریخچه این معیارها را دقیق بدانیم: تا سال ۲۰۲۴، سه معیار اصلی LCP، FID و CLS بودند. از مارس ۲۰۲۴، معیار FID (First Input Delay) به‌طور کامل کنار گذاشته شد و جای خود را به INP (Interaction to Next Paint) داد، چون INP کل تعامل کاربر در طول عمر صفحه را می‌سنجد، نه فقط اولین ورودی. اگر منبعی هنوز از FID به‌عنوان یکی از سه Core Web Vital فعلی نام می‌برد، اطلاعات آن قدیمی است.

CORE WEB VITALS

سه معیار اصلی تجربه فنی صفحه
LCP
بارگذاری
سرعت نمایش محتوای اصلی
INP
تعامل
سرعت واکنش صفحه
CLS
پایداری
جلوگیری از جابه‌جایی محتوا

LCP (Largest Contentful Paint)

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

عوامل رایج ضعیف شدن LCP:

  • هاست کند یا زمان پاسخ سرور (TTFB) بالا
  • تصاویر حجیم و بهینه‌نشده
  • فایل‌های CSS و جاوااسکریپت مسدودکننده رندر (Render-blocking)
  • عدم استفاده از CDN برای کاربران دور از سرور اصلی
  • فونت‌های وب که با تأخیر بارگذاری می‌شوند

راهکارهای بهبود:

  • فشرده‌سازی و تبدیل تصاویر به فرمت‌های مدرن مانند WebP یا AVIF
  • استفاده از Lazy Loading برای تصاویر پایین‌تر از Viewport (نه برای تصویر اصلی صفحه)
  • به‌کارگیری CDN برای کاهش تأخیر جغرافیایی
  • کاهش حجم CSS و جاوااسکریپت اولیه (Critical CSS)
  • ارتقای زیرساخت هاست یا استفاده از کش سمت سرور
LCP دقیقاً چه چیزی را نشان می‌دهد؟
درخواست صفحه

بارگذاری منابع

نمایش محتوای اصلی

INP (Interaction to Next Paint)

INP میزان واکنش‌پذیری صفحه را در برابر تعاملات کاربر (کلیک، لمس، تایپ) در کل طول عمر بازدید اندازه می‌گیرد؛ یعنی از لحظه ورود کاربر تا لحظه خروج، هر تعاملی که کاربر انجام می‌دهد بررسی و کندترین یا نماینده‌ترین آن‌ها گزارش می‌شود. این تفاوت اصلی INP با FID قدیمی است که فقط اولین تعامل را می‌سنجید.

عوامل رایج ضعیف شدن INP:

  • اجرای جاوااسکریپت سنگین که Main Thread مرورگر را مسدود می‌کند
  • Event Listenerهای پیچیده و غیربهینه
  • استفاده افراطی از اسکریپت‌های شخص ثالث (تبلیغات، ابزارهای تحلیلی، ویجت‌های چت)
  • به‌روزرسانی‌های مکرر DOM بدون بهینه‌سازی

راهکارهای بهبود:

  • تقسیم وظایف سنگین جاوااسکریپت به قطعات کوچک‌تر (Code Splitting)
  • تأخیر در بارگذاری اسکریپت‌های غیرضروری (Defer/Async)
  • کاهش تعداد و حجم اسکریپت‌های شخص ثالث
  • استفاده از Web Workers برای پردازش‌های سنگین خارج از Main Thread

CLS (Cumulative Layout Shift)

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

صفحه پایدار
Layout Shift
رزرو نکردن فضای تصاویر، تبلیغات و محتوای پویا می‌تواند باعث جابه‌جایی ناگهانی عناصر شود.

عوامل رایج ضعیف شدن CLS:

  • تصاویر و ویدیوها بدون تعیین ابعاد (Width/Height) از پیش
  • تبلیغات یا iframeهایی که فضای خود را از پیش رزرو نمی‌کنند
  • فونت‌های وب که باعث Layout Shift هنگام بارگذاری می‌شوند (Flash of Unstyled Text)
  • تزریق پویای محتوا (مانند بنر یا اعلان) بدون فضای رزرو‌شده

راهکارهای بهبود:

  • تعیین ابعاد ثابت برای تصاویر، ویدیو و iframeها در کد HTML
  • رزرو فضای مشخص برای بلوک‌های تبلیغاتی از قبل
  • استفاده از font-display: swap همراه با فضای رزروشده برای فونت
  • اجتناب از درج محتوای پویا در بالای صفحه بدون رزرو فضا

Mobile-Friendly بودن سایت

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

یک صفحه، متناسب با هر نمایشگر
طراحی Responsive باید محتوا، دکمه‌ها، تصاویر و ساختار صفحه را بدون زوم یا اسکرول افقی با اندازه نمایشگر تطبیق دهد.
  • طراحی Responsive: چیدمان صفحه باید بدون نیاز به زوم یا اسکرول افقی، خودش را با اندازه صفحه‌نمایش کاربر تطبیق دهد.
  • خوانایی متن: اندازه فونت باید بدون نیاز به بزرگ‌نمایی قابل خواندن باشد؛ معمولاً حداقل ۱۶ پیکسل برای متن اصلی توصیه می‌شود.
  • اندازه عناصر قابل کلیک: دکمه‌ها و لینک‌ها باید فاصله و اندازه کافی داشته باشند تا با انگشت به‌راحتی و بدون فشردن اشتباه گزینه مجاور، قابل لمس باشند.
  • نمایش صحیح محتوا: محتوایی که در نسخه دسکتاپ نمایش داده می‌شود باید در موبایل هم به‌طور کامل و بدون افت کیفیت در دسترس باشد (به‌ویژه با توجه به ایندکس Mobile-First گوگل).

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

HTTPS و امنیت

HTTPS تضمین می‌کند ارتباط بین مرورگر کاربر و سرور سایت رمزنگاری‌شده است، یعنی داده‌های ردوبدل‌شده (مانند اطلاعات فرم، اطلاعات ورود، یا حتی رفتار مرور) در برابر شنود یا دستکاری توسط شخص ثالث محافظت می‌شوند. مرورگرهای مدرن مانند کروم، اتصال‌های HTTP بدون رمزنگاری را با برچسب «غیرامن» (Not Secure) مشخص می‌کنند که مستقیماً روی اعتماد کاربر تأثیر منفی می‌گذارد. HTTPS از سال‌ها پیش به‌عنوان یکی از سیگنال‌های پایه در زیرمجموعه Page Experience شناخته می‌شود؛ نبود آن یک ریسک واضح برای هم امنیت و هم تجربه کاربر است.

ارتباط رمزنگاری‌شده
HTTPS از داده‌های در حال انتقال میان مرورگر و سرور در برابر شنود و دستکاری محافظت می‌کند.

امنیت و تجربه کاربر

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

Malware

آلودگی سایت و کدهای مخرب

Phishing

تلاش برای سرقت اطلاعات کاربر

صفحات مخرب

ریدایرکت و دانلود ناخواسته

هشدار امنیتی

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

مزاحمت‌های بینابینی و تبلیغات

Interstitialها (پاپ‌آپ‌ها و لایه‌های تمام‌صفحه) در صورتی مشکل‌سازند که مانع دسترسی فوری کاربر به محتوای اصلی شوند — مثلاً وقتی کاربر از نتایج جست‌وجو وارد صفحه می‌شود و بلافاصله با یک پاپ‌آپ تمام‌صفحه که دکمه بستنش پیدا نمی‌شود روبه‌رو می‌شود.

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

اما هر Pop-up ای مشکل‌ساز نیست. مواردی که معمولاً مشکلی ایجاد نمی‌کنند:

  • پاپ‌آپ‌های قانونی مانند تأیید سن یا رضایت کوکی که استانداردهای قانونی ایجاب می‌کنند
  • پاپ‌آپ‌های ورود (Login) برای محتوایی که به‌طور ذاتی محدود به کاربران عضو است (مانند محتوای پولی)
  • بنرهای کوچک و قابل‌بستن که فضای معقولی از صفحه را اشغال می‌کنند و مانع مشاهده محتوای اصلی نمی‌شوند

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

تعامل کاربر با صفحه چه اهمیتی دارد؟

یک باور غلط رایج در جامعه سئو این است که گوگل یک «امتیاز مخفی تعامل کاربر» (مثلاً بر پایه نرخ کلیک یا Dwell Time) دارد که مستقیماً در فرمول رتبه‌بندی ضرب می‌شود. گوگل هیچ‌گاه چنین چیزی را تأیید نکرده و شواهد قابل‌اتکایی هم برای وجود چنین معیار مستقیمی در دست نیست. بنابراین بهتر است این را به‌عنوان یک فرضیه اثبات‌نشده در نظر بگیریم، نه یک واقعیت فنی.

مسیر یک تعامل خوب با صفحه
ورود

یافتن محتوا

تعامل

رسیدن به هدف
هدف UX این نیست که کاربر را با ترفندهای مصنوعی بیشتر در صفحه نگه دارد؛ هدف، حذف موانعی است که رسیدن کاربر به پاسخ یا هدفش را سخت می‌کنند.

آنچه واقعاً اهمیت دارد، تأثیر غیرمستقیم کیفیت تعامل بر رفتار کاربر و در نتیجه بر سیگنال‌های قابل‌اندازه‌گیری‌تر (مانند نرخ بازگشت به نتایج جست‌وجو یا زمان ماندگاری) است. عوامل مؤثر بر این تجربه واقعی:

  • خوانایی: فونت مناسب، کنتراست رنگی کافی، فاصله‌گذاری خطوط، و طول پاراگراف‌های قابل هضم.
  • سرعت پاسخ‌گویی: واکنش سریع صفحه به کلیک، اسکرول و تایپ (که مستقیماً با INP مرتبط است).
  • دسترسی آسان به محتوا: کاربر باید بدون اسکرول‌های بیش‌ازحد یا کلیک‌های اضافه به پاسخ سؤالش برسد.
  • Navigation: منوها و مسیرهای ناوبری باید منطقی، قابل‌پیش‌بینی و سازگار در تمام صفحات باشند.
  • تعامل با عناصر صفحه: فرم‌ها، دکمه‌ها و لینک‌ها باید به‌وضوح قابل‌شناسایی و بدون خطای عملکردی باشند.
  • اصطکاک در مسیر کاربر (Friction): هر مرحله اضافه، هر فیلد غیرضروری در فرم، یا هر تأخیر غیرمنتظره، احتمال ترک صفحه توسط کاربر را افزایش می‌دهد.

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

Core Web Vitals در مقابل Page Experience

این دو مفهوم اغلب به‌جای هم استفاده می‌شوند، در حالی‌که رابطه‌شان «جزء و کل» است، نه «برابری».

ویژگی Core Web Vitals Page Experience
ماهیت مجموعه‌ای مشخص از سه معیار کمّی (LCP، INP، CLS) یک مفهوم چتری شامل چند دسته سیگنال متفاوت
قابلیت اندازه‌گیری کاملاً قابل اندازه‌گیری با عدد و آستانه مشخص برخی اجزا قابل اندازه‌گیری (CWV، HTTPS)، برخی کیفی (تبلیغات مزاحم)
منبع داده داده واقعی کاربران کروم (CrUX) و ابزارهای آزمایشگاهی ترکیبی از CWV، بررسی‌های الگوریتمی و اعلان‌های دستی گوگل
زیرمجموعه‌ها ندارد؛ خودش یک مجموعه معیار مستقل است شامل Core Web Vitals، Mobile-Friendly، HTTPS، امنیت، و نبود Interstitial مزاحم
هدف سنجش دقیق سرعت بارگذاری، واکنش‌پذیری و ثبات بصری ارزیابی کلی‌تر از تجربه کاربر در تعامل با صفحه
وضعیت در Search Console گزارش مستقل «Core Web Vitals» هنوز فعال است گزارش مستقل «Page Experience» از Search Console حذف شده است
رابطه را این‌طور به خاطر بسپارید
Core Web Vitals یک بخش مشخص و قابل‌اندازه‌گیری از Page Experience است؛
Page Experience نگاه گسترده‌تری به کیفیت تعامل کاربر با صفحه دارد.

به‌زبان ساده: Core Web Vitals یکی از چند «فصل» کتاب Page Experience است، نه کل کتاب.

چگونه Page Experience سایت را بررسی کنیم؟

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

مسیر بررسی

از داده واقعی تا عیب‌یابی فنی
1
Search Console
تشخیص الگوهای واقعی
2
PageSpeed
Field + Lab Data
3
Lighthouse
Audit و شناسایی مشکل
4
DevTools
دیباگ عمیق فنی
ترتیب پیشنهادی:
ابتدا وضعیت واقعی را پیدا کنید، سپس علت را با ابزارهای فنی ریشه‌یابی کنید.

Google Search Console

گزارش Core Web Vitals در Search Console، عملکرد واقعی صفحات سایت را بر اساس داده‌های CrUX نشان می‌دهد و صفحات را در سه دسته «خوب»، «نیاز به بهبود» و «ضعیف» گروه‌بندی می‌کند. این گزارش برای شناسایی الگوهای گسترده در سطح گروه‌های URL بسیار کاربردی است، چون داده‌ها را بر اساس قالب‌های صفحه (مثلاً همه صفحات محصول) دسته‌بندی می‌کند. گزارش‌های جداگانه‌ای هم برای وضعیت HTTPS و سازگاری موبایل در دسترس متخصص سئو قرار دارد.

PageSpeed Insights

این ابزار هم داده‌های میدانی (Field Data از CrUX، در صورت وجود ترافیک کافی) و هم داده‌های آزمایشگاهی (Lab Data از یک اجرای شبیه‌سازی‌شده Lighthouse) را برای یک URL مشخص نمایش می‌دهد. تفاوت این دو نوع داده حیاتی است: امتیاز آزمایشگاهی صرفاً یک عکس فوری در شرایط کنترل‌شده است، در حالی‌که داده میدانی نشان‌دهنده تجربه واقعی کاربران در طول زمان است. تصمیم‌گیری سئو باید بر پایه داده میدانی باشد، نه فقط بهینه‌سازی برای عدد آزمایشگاهی.

Lighthouse

Lighthouse یک ابزار حسابرسی (Audit) است که مستقیماً در Chrome DevTools یا به‌صورت مستقل قابل اجراست و علاوه بر عملکرد، جنبه‌های دیگری مانند دسترسی‌پذیری (Accessibility)، بهترین شیوه‌ها (Best Practices) و سئوی فنی پایه را هم بررسی می‌کند. خروجی آن فهرستی دقیق از مشکلات فنی به همراه پیشنهاد رفع هرکدام است — مناسب برای مرحله عیب‌یابی فنی عمیق.

Chrome DevTools

برای تحلیل لحظه‌به‌لحظه، تب Performance در DevTools امکان ضبط دقیق فرآیند بارگذاری و تعامل صفحه را می‌دهد؛ می‌توان دقیقاً دید کدام اسکریپت Main Thread را مسدود کرده یا کدام عنصر باعث Layout Shift شده است. این سطح از جزئیات معمولاً برای دیباگ مشکلات پیچیده INP یا CLS که در گزارش‌های کلی‌تر قابل تشخیص نیستند، ضروری است.

 

اگر Page Experience ضعیف باشد چه کنیم؟

اگر وضعیت Page Experience یک سایت مطلوب نیست، بهتر است به‌جای تغییرات پراکنده، مشکل را مرحله‌به‌مرحله شناسایی، اولویت‌بندی و اصلاح کرد. این فرآیند را می‌توان در هفت مرحله انجام داد:

مسیر بهبود

از شناسایی مشکل تا مانیتورینگ
01
شناسایی مشکل
با ترکیب Search Console و PageSpeed Insights مشخص کنید کدام معیار (LCP، INP، CLS)، کدام دسته صفحات، و در کدام نوع دستگاه (موبایل یا دسکتاپ) دچار مشکل است.
02
تعیین اولویت
ابتدا روی صفحاتی تمرکز کنید که هم ترافیک بالایی دارند و هم بیشترین افت را نشان می‌دهند؛ رفع مشکل در یک صفحه کم‌بازدید اولویت پایین‌تری دارد.
03
بررسی داده‌های واقعی کاربران
به داده میدانی (Field Data) اعتماد کنید، نه فقط امتیاز آزمایشگاهی؛ گاهی امتیاز Lighthouse عالی است اما تجربه واقعی کاربران (به‌خاطر تفاوت دستگاه، شبکه یا موقعیت جغرافیایی) هنوز ضعیف است.
04
اصلاح مشکل فنی
بر اساس ریشه مشکل (کد، تصاویر، اسکریپت شخص‌ثالث، هاست) اصلاحات مشخص‌شده در بخش‌های قبل را اعمال کنید.
05
تست مجدد
پس از هر تغییر، هم با ابزار آزمایشگاهی و هم (بعد از گذشت زمان کافی برای جمع‌آوری داده) با داده میدانی نتیجه را بسنجید.
06
بررسی نسخه موبایل
اصلاحات را به‌طور جداگانه روی نسخه موبایل هم تست کنید؛ چون شرایط شبکه و پردازنده موبایل با دسکتاپ متفاوت است و ممکن است مشکلی که در دسکتاپ دیده نمی‌شود، در موبایل جدی باشد.
07
مانیتورینگ
بهبود Page Experience یک اقدام یک‌باره نیست. با هر آپدیت محتوایی، افزودن اسکریپت جدید، یا تغییر قالب سایت، دوباره وضعیت را بررسی کنید.

اشتباهات رایج در بهبود Page Experience

بهینه‌سازی Page Experience زمانی نتیجه می‌دهد که هدف، بهبود تجربه واقعی کاربر باشد؛ نه صرفاً بالا بردن یک امتیاز آزمایشگاهی. بعضی از رایج‌ترین اشتباهات دقیقاً زمانی اتفاق می‌افتند که یک Metric یا یک ابزار به هدف اصلی تبدیل می‌شود.

!
قبل از هر بهینه‌سازی، این خطاها را بررسی کنید
بهبود یک Metric نباید به قیمت خراب شدن تجربه کلی تمام شود.

01. عدد PageSpeed را هدف نگیرید

تمرکز افراطی روی رسیدن به ۱۰۰/۱۰۰ به‌جای بهبود تجربه واقعی کاربر.

02. Lab Data را مطلق ندانید

بهینه‌سازی مصنوعی برای امتیاز آزمایشگاهی بدون توجه به داده میدانی واقعی.

03. موبایل را فراموش نکنید

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

04. عناصر مفید را حذف نکنید

حذف تصاویر توضیحی یا ویدیوهای آموزشی صرفاً برای کاهش حجم صفحه.

05. کیفیت بصری را قربانی نکنید

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

06. JavaScript ضروری را کورکورانه حذف نکنید

غیرفعال کردن جاوااسکریپت‌های ضروری برای عملکرد سایت به بهانه بهبود INP.

07. Third-partyها را بررسی کنید

نادیده گرفتن تبلیغات، تحلیل، چت آنلاین و سایر اسکریپت‌های شخص ثالث که می‌توانند عامل کندی باشند.

08. یک Metric را فدای دیگری نکنید

مثلاً کاهش شدید CLS با حذف پیش‌نمایش پویا که تجربه کاربر را کسل‌کننده می‌کند.

09. کش تهاجمی را بدون بررسی اجرا نکنید

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

10. قبل و بعد را بسنجید

اجرای تغییرات فنی بدون تست A/B یا بررسی وضعیت قبل و بعد.

11. بهینه‌سازی را یک‌باره ندانید

تصور اینکه یک بار بهینه‌سازی کافی است و نیازی به مانیتورینگ مستمر نیست.

12. فقط صفحه اصلی را بررسی نکنید

نادیده گرفتن تفاوت بین صفحات مختلف سایت؛ مثلاً صفحات محصول یا مقاله.

13. افزونه‌ها را کورکورانه اعتماد نکنید

اعتماد کامل به Third-party pluginها یا افزونه‌های «بهینه‌سازی خودکار» بدون بررسی نتیجه واقعی.

14. مشکل محتوا را فراموش نکنید

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

15. امنیت را قربانی سرعت نکنید

نادیده گرفتن تجربه امنیتی، مثلاً گواهی SSL منقضی‌شده، در حالی‌که روی سرعت صفحه وقت گذاشته می‌شود.

آیا Page Experience خوب باعث رتبه ۱ گوگل می‌شود؟

پاسخ صریح: نه، به‌تنهایی نه.

تجربه صفحه خوب ≠ رتبه ۱
Page Experience یک جزء مهم از کیفیت فنی صفحه است، اما جایگزین ارتباط، کیفیت و ارزش محتوا نمی‌شود.

داشتن امتیاز عالی در Core Web Vitals یا PageSpeed، تضمینی برای رتبه اول نیست. اگر محتوای صفحه پاسخ کاملی به Search Intent کاربر ندهد، فاقد عمق و ارزش اطلاعاتی کافی باشد، یا از نظر E-E-A-T (تجربه، تخصص، اعتبار و اعتماد) ضعیف باشد، هیچ میزان بهینه‌سازی فنی نمی‌تواند آن کمبود را جبران کند. کیفیت، ارتباط و ارزش محتوا همچنان مهم‌ترین ستون موفقیت در جست‌وجو هستند؛ Page Experience نقش یک عامل تکمیلی و بعضاً تفکیک‌کننده را ایفا می‌کند، نه نقش اصلی.

روند به‌روزرسانی‌های اخیر گوگل هم همین را نشان می‌دهد: بخش قابل‌توجهی از تمرکز گوگل روی سیگنال‌های کیفیت محتوایی مانند تجربه واقعی نویسنده و اطلاعات اصیل (Information Gain) است، نه صرفاً سیگنال‌های فنی. البته سیگنال‌های فنی مانند Core Web Vitals هم در طول زمان دقیق‌تر و سخت‌گیرانه‌تر شده‌اند و نادیده گرفتن آن‌ها می‌تواند در رقابت بین صفحات مشابه هزینه‌ساز باشد؛ اما این هرگز به معنای جایگزینی محتوای باکیفیت نیست.

نکته مهم دیگر: از ادعاهایی مانند «Page Experience فلان درصد از رتبه را تعیین می‌کند» که بدون منبع رسمی از گوگل در برخی مقالات دیده می‌شود، باید با احتیاط برخورد کرد. گوگل هیچ‌گاه وزن دقیق عددی برای این سیگنال‌ها منتشر نکرده و چنین اعدادی معمولاً برآوردهای غیررسمی سایت‌های شخص ثالث هستند.

چک‌لیست Page Experience برای سئو

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

بررسی نهایی
مواردی که پیش از ارزیابی نهایی سایت باید کنترل شوند
LCP در بیشتر صفحات کلیدی (بر اساس داده میدانی) در محدوده «خوب» قرار دارد
INP در بیشتر صفحات کلیدی در محدوده «خوب» قرار دارد
CLS در بیشتر صفحات کلیدی در محدوده «خوب» قرار دارد
سایت به‌طور کامل روی HTTPS اجرا می‌شود و محتوای مختلط (Mixed Content) وجود ندارد
گواهی SSL معتبر و بدون هشدار مرورگر است
طراحی سایت به‌طور کامل Responsive است و در اندازه‌های مختلف صفحه‌نمایش تست شده
اندازه و فاصله عناصر قابل‌کلیک برای استفاده با انگشت مناسب است
هیچ Interstitial مزاحمی مانع دسترسی فوری کاربر به محتوای اصلی نمی‌شود
سایت هیچ هشدار امنیتی (بدافزار، فیشینگ) در Search Console ندارد
اسکریپت‌های شخص ثالث غیرضروری حذف یا به‌تعویق انداخته شده‌اند
تصاویر و ویدیوها بهینه‌سازی و دارای ابعاد مشخص در کد هستند
گزارش Core Web Vitals در Search Console به‌طور دوره‌ای بررسی می‌شود
نسخه موبایل به‌طور جداگانه از نسخه دسکتاپ تست شده است
یادآوری:
هدف این چک‌لیست گرفتن یک امتیاز خاص نیست؛ هدف، ساختن تجربه‌ای سریع، پایدار، امن و قابل‌استفاده برای کاربر است.

“`html

سوالات متداول Page Experience

❓ Page Experience چیست؟
مجموعه‌ای از سیگنال‌ها (نه یک امتیاز واحد) که تجربه کاربر هنگام تعامل با یک صفحه، فراتر از ارزش محتوایی آن، مانند سرعت، امنیت و سازگاری با موبایل را نشان می‌دهد.
❓ آیا Page Experience یک الگوریتم مستقل گوگل است؟
خیر. طبق توضیح خود گوگل، این یک «سیستم» رتبه‌بندی مستقل نیست، بلکه چند سیگنال است که توسط سیستم‌های دیگر رتبه‌بندی گوگل استفاده می‌شود.
❓ Core Web Vitals شامل چه معیارهایی است؟
سه معیار فعلی عبارت‌اند از LCP (سرعت بارگذاری بزرگ‌ترین عنصر)، INP (واکنش‌پذیری به تعامل کاربر) و CLS (ثبات بصری صفحه). FID دیگر جزو این مجموعه نیست.
❓ چرا FID دیگر یکی از Core Web Vitals نیست؟
چون FID فقط اولین تعامل کاربر را می‌سنجید، در حالی‌که INP کل عمر تعاملات کاربر با صفحه را در نظر می‌گیرد و تصویر دقیق‌تری از واکنش‌پذیری ارائه می‌دهد.
❓ آیا امتیاز ۱۰۰ در PageSpeed Insights تضمین رتبه بالا می‌دهد؟
خیر. امتیاز PageSpeed عمدتاً بر پایه داده آزمایشگاهی است و صرفاً یکی از سیگنال‌های کمکی رتبه‌بندی محسوب می‌شود؛ کیفیت و ارتباط محتوا همچنان عامل اصلی است.
❓ تفاوت داده میدانی و داده آزمایشگاهی در ابزارهای سرعت چیست؟
داده آزمایشگاهی (Lab Data) یک اجرای شبیه‌سازی‌شده در شرایط کنترل‌شده است؛ داده میدانی (Field Data) تجربه واقعی کاربران در طول زمان است. تصمیم‌گیری سئو باید بیشتر بر پایه داده میدانی باشد.
❓ آیا HTTPS تأثیر مستقیم روی رتبه دارد؟
HTTPS از سال‌ها پیش بخشی از سیگنال‌های پایه Page Experience است؛ نبود آن هم برای امنیت کاربر و هم برای اعتماد به سایت مشکل‌ساز است.
❓ چرا سایت من هشدار «غیرامن» در مرورگر می‌گیرد؟
معمولاً به‌دلیل نبود گواهی SSL معتبر، منقضی‌شدن گواهی، یا وجود محتوای مختلط (بارگذاری برخی منابع از طریق HTTP در یک صفحه HTTPS).
❓ آیا تبلیغات باعث افت Page Experience می‌شوند؟
فقط وقتی که به‌عنوان Interstitial مزاحم عمل کنند و دسترسی فوری کاربر به محتوای اصلی را مسدود کنند؛ تبلیغات معقول و غیرمزاحم مشکل‌ساز نیستند.
❓ چطور بفهمم صفحه من مشکل CLS دارد؟
از گزارش Core Web Vitals در Search Console یا اجرای PageSpeed Insights روی URL موردنظر استفاده کنید؛ عناصر مسئول Layout Shift هم در Lighthouse قابل مشاهده‌اند.
❓ آیا بهبود سرعت سایت به‌تنهایی رتبه را بالا می‌برد؟
نه لزوماً. سرعت یک عامل تکمیلی است؛ بدون محتوای مرتبط و باکیفیت، بهبود سرعت به‌تنهایی معمولاً تأثیر محدودی روی رتبه دارد.
❓ چرا گزارش Page Experience از Search Console حذف شد؟
گوگل این گزارش را حذف کرد تا سردرگمی بین «سیستم» و «سیگنال» را کاهش دهد، اما داده‌های مربوط به Core Web Vitals و HTTPS همچنان در گزارش‌های جداگانه در دسترس‌اند.
❓ آیا Mobile-Friendly بودن هنوز مهم است؟
بله، به‌ویژه با توجه به ایندکس Mobile-First گوگل که نسخه موبایل سایت را مبنای ارزیابی اصلی قرار می‌دهد.
❓ چند وقت یک‌بار باید Page Experience سایت را بررسی کنم؟
به‌صورت دوره‌ای (مثلاً ماهانه) و همچنین بعد از هر تغییر بزرگ در قالب، افزودن اسکریپت جدید یا انتشار محتوای حجیم.
❓ آیا استفاده از افزونه‌های بهینه‌سازی خودکار کافی است؟
این ابزارها می‌توانند کمک‌کننده باشند، اما جایگزین بررسی دستی و تست واقعی داده میدانی نیستند؛ نتیجه هر تغییر باید تأیید شود.
❓ آیا CDN برای بهبود Page Experience ضروری است؟
برای سایت‌هایی با مخاطب بین‌المللی یا جغرافیایی پراکنده، CDN معمولاً تأثیر محسوسی روی کاهش زمان بارگذاری (به‌ویژه LCP) دارد.
اشتراک گذاری این مطلب

دسته بندی مقالات

آخرین مقالات

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

مقالات مرتبط

Core Update گوگل Core Update گوگل چیست؟ بررسی علت افت رتبه و روش بازیابی

زمان مطالعه: 24 دقیقهاگر یک روز صبح وارد Google Search Console شوید و ببینید ترافیک سایت‌تان بدون هیچ تغییری در محتوا یا ساختار سایت، ناگهان افت کرده، احتمال زیادی ...

بیشتر بخوانیم
الگوریتم RankBrain الگوریتم RankBrain گوگل چیست؟ راهنمای کامل و دقیق برای متخصصان سئو

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

بیشتر بخوانیم
الگوریتم پنگوئن گوگل الگوریتم پنگوئن گوگل چیست؟ بررسی کامل Penguin و تأثیر آن بر سئو

زمان مطالعه: 32 دقیقهاگر تا امروز فکر می‌کردید رتبه‌گرفتن در گوگل فقط به «تعداد» بک‌لینک‌ها بستگی دارد، یکی از مهم ترین الگوریتم‌های گوگل یعنی الگوریتم پنگوئن دقیقاً همین باور ...

بیشتر بخوانیم

آماده یک سرمایه گذاری هوشمندانه روی برند خودتان هستید؟

برای مشاوره با ما مشخصات خود را وارد کنید تا تیم پیام آوا در سریعترین زمان با شما تماس بگیرند.