نشانه از همینجا شروع میشود: صفحه مقاله یا خدمت شما محتوای بدی ندارد، حتی شاید از رقیب کاملتر باشد؛ اما در نتایج گوگل تکان نمیخورد. گاهی چند پله افت میکند، گاهی نرخ کلیک بد نیست ولی کاربر زود برمیگردد، و گاهی Search Console در بخش Core Web Vitals با چند URL قرمز یا زرد، آرام و بیسر و صدا هشدار میدهد.
در چنین وضعیتی اولین واکنش خیلی از تیمها این است که دوباره متن را طولانیتر کنند، چند بکلینک بخرند یا عنوان صفحه را عوض کنند. این کارها شاید در بعضی سناریوها لازم باشد، اما اگر مشکل اصلی تجربه صفحه باشد، شما دارید روی زخمی که عفونت کرده فقط چسب زخم میزنید.
الگوریتم Page Experience گوگل قرار نیست جای کیفیت محتوا، اعتبار دامنه یا تناسب با نیت جستوجو را بگیرد. اما وقتی چند نتیجه از نظر محتوایی نزدیک به هم هستند، صفحهای که سریعتر، پایدارتر، امنتر و راحتتر استفاده میشود شانس بیشتری برای حفظ جایگاه و رضایت کاربر دارد. گوگل در مستندات رسمی Core Web Vitals، سه معیار LCP، INP و CLS را برای سنجش بخش مهمی از تجربه صفحه معرفی میکند و روی اندازهگیری تجربه واقعی کاربران تاکید دارد. ([developers.google.com](https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=openai))
تشخیص سریع: اگر صفحه شما محتوای مناسبی دارد اما روی موبایل کند باز میشود، دکمهها با تأخیر واکنش میدهند یا چیدمان صفحه هنگام لود جابهجا میشود، مسئله فقط «سرعت» نیست؛ احتمالاً با یک مشکل Page Experience طرفید.
Page Experience دقیقاً چه چیزی را ارزیابی میکند؟
Page Experience یعنی کاربر پس از کلیک روی نتیجه گوگل، با صفحه شما چه تجربهای دارد. آیا صفحه سریع قابل استفاده میشود؟ آیا کاربر قبل از دیدن محتوای اصلی مجبور است با پاپآپ بجنگد؟ آیا روی موبایل متن خواناست؟ آیا دکمه خرید یا تماس هنگام لمس با تأخیر جواب میدهد؟ آیا تصویر بالای صفحه ناگهان پایین میپرد و کاربر روی لینک اشتباه کلیک میکند؟
اینها سوالهای سادهای هستند، اما پشت آنها دادههای فنی قرار دارد. گوگل Page Experience را از زاویه سیگنالهایی مثل Core Web Vitals، امن بودن اتصال، سازگاری با موبایل و نبود مزاحمتهای آزاردهنده برای کاربر بررسی میکند. البته نباید آن را با یک «دکمه جادویی رتبه» اشتباه گرفت. صفحهای که محتوای ضعیف دارد، فقط با نمره سرعت خوب رتبه نمیگیرد. اما صفحهای که محتوای خوب دارد و تجربه بدی ایجاد میکند، بخشی از ظرفیت رشدش را از دست میدهد.
برای کسبوکارهای ایرانی، اهمیت این موضوع بیشتر هم میشود. چون بسیاری از کاربران با اینترنت موبایل، دستگاههای میانرده، مرورگرهای متفاوت و گاهی اتصال ناپایدار وارد سایت میشوند. سایتی که روی لپتاپ تیم طراحی سریع به نظر میرسد، ممکن است روی گوشی مشتری واقعی، سنگین و عصبیکننده باشد.
سه علامت حیاتی: LCP، INP و CLS
اگر بخواهیم Page Experience را عیبیابی کنیم، بهتر است از سه معیار اصلی Core Web Vitals شروع کنیم. گوگل برای تجربه خوب پیشنهاد میکند LCP کمتر یا مساوی ۲.۵ ثانیه، INP کمتر یا مساوی ۲۰۰ میلیثانیه و CLS کمتر یا مساوی ۰.۱ باشد. همچنین از ۱۲ مارس ۲۰۲۴، INP جای FID را در Core Web Vitals گرفت؛ یعنی گوگل حالا واکنشپذیری صفحه را جدیتر و گستردهتر از قبل میسنجد. ([developers.google.com](https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=openai))
| معیار | چه چیزی را میسنجد؟ | نشانه خرابی در سایت | مسیر اصلاح |
|---|---|---|---|
| LCP | زمان نمایش بزرگترین محتوای قابل مشاهده | تصویر هدر دیر میآید، صفحه سفید میماند، محتوای اصلی عقب میافتد | بهینهسازی تصویر اصلی، کش، سرور سریعتر، حذف منابع مسدودکننده |
| INP | سرعت پاسخ صفحه به تعامل کاربر | دکمهها دیر واکنش میدهند، منو با مکث باز میشود، فرم سنگین است | کاهش JavaScript، شکستن تسکهای طولانی، سبکسازی اسکریپتهای ثالث |
| CLS | پایداری چیدمان صفحه هنگام بارگذاری | بنر، تصویر یا دکمه هنگام لود جابهجا میشود | تعریف عرض و ارتفاع تصاویر، رزرو فضای تبلیغ/بنر، کنترل فونت و lazy load |
نکته ظریف اینجاست: این سه عدد به تنهایی داستان کامل را نمیگویند. گاهی تست آزمایشگاهی PageSpeed Insights سبز است، اما داده میدانی کاربران واقعی در Search Console زرد یا قرمز نشان داده میشود. چرا؟ چون ابزار آزمایشگاهی در یک شرایط کنترلشده تست میگیرد، ولی داده میدانی از تجربه واقعی کاربران روی دستگاهها و شبکههای مختلف میآید.
چرا سایت با وجود محتوای خوب بالا نمیآید؟
وقتی صفحهای محتوای قابل قبول دارد اما رشد نمیکند، باید بین سه نوع مشکل فرق بگذاریم: مشکل نیت جستوجو، مشکل اعتبار و مشکل تجربه صفحه. Page Experience معمولاً مشکل سوم است، اما میتواند دو مشکل اول را هم بدتر نشان دهد.
فرض کنید کاربر عبارت «قیمت سئو سایت فروشگاهی» را جستوجو میکند و وارد صفحه شما میشود. صفحه دیر باز میشود، جدول قیمت در موبایل از کادر بیرون میزند، دکمه مشاوره بعد از لمس چند ثانیه بیواکنش میماند و یک پاپآپ تمام صفحه قبل از خواندن محتوا ظاهر میشود. کاربر چه برداشتی میکند؟ شاید محتوای شما را اصلاً نبیند. در گزارشها فقط یک بازدید کوتاه، یک تعامل ضعیف و شاید یک برگشت سریع باقی میماند.
اشتباه رایج این است که تیم سئو افت رتبه را فقط با کلمه کلیدی و لینک تحلیل میکند، در حالی که مشکل واقعی در لحظه تجربه کاربر رخ میدهد. برای همین در پروژههای حرفهای سئو فنی و محتوایی، بررسی Page Experience باید کنار تحلیل محتوا، ساختار داخلی و وضعیت ایندکس انجام شود؛ نه بعد از همه چیز و به عنوان کار تزئینی.
عیبیابی مرحلهای Page Experience
برای تشخیص درست، از حدس شروع نکنید. از داده شروع کنید. مسیر زیر کوتاه است، اما اگر دقیق اجرا شود، جلوی بسیاری از اصلاحات اشتباه را میگیرد.
۱. اول URLهای مسئلهدار را جدا کنید
در Search Console وارد گزارش Core Web Vitals شوید و ببینید مشکل روی موبایل است یا دسکتاپ. معمولاً موبایل زودتر هشدار میدهد، چون منابع دستگاه و کیفیت اتصال محدودتر است. سپس URLها را گروهبندی کنید: صفحات محصول، مقالات، صفحه اصلی، صفحات دستهبندی یا لندینگهای تبلیغاتی. اگر تمام صفحات یک قالب مشکل دارند، به احتمال زیاد ریشه در قالب، اسکریپتها یا کامپوننت مشترک است.
۲. مشکل را به معیار درست وصل کنید
اگر LCP خراب است، اول دنبال تصویر اصلی، فونت، سرور، CSS مسدودکننده و درخواستهای ابتدایی بروید. اگر INP خراب است، JavaScript و رویدادهای سنگین را بررسی کنید. اگر CLS خراب است، دنبال تصویر بدون ابعاد، بنر دیرلودشونده، فونتهایی که چیدمان را عوض میکنند و تبلیغات بدون فضای رزروشده بگردید.
۳. تست آزمایشگاهی را با داده میدانی قاطی نکنید
PageSpeed Insights، Lighthouse و WebPageTest برای تشخیص فنی عالیاند؛ اما رتبهبندی تجربه واقعی بیشتر به داده کاربران واقعی نزدیک است. اگر داده میدانی ندارید، یعنی یا سایت تازه است، یا ترافیک کافی برای گزارش وجود ندارد. در این حالت باید با تست آزمایشگاهی و مانیتورینگ داخلی جلو بروید تا داده شکل بگیرد.
۴. قبل و بعد از اصلاح را ثبت کنید
خیلی از تیمها تغییرات زیادی را همزمان انجام میدهند و بعد نمیفهمند کدام کار اثر داشته. یک جدول ساده بسازید: تاریخ، URL، مشکل، تغییر انجامشده، نتیجه تست، نتیجه Search Console. این کار شاید اداری به نظر برسد، اما در پروژههای سئو تکنیکال تفاوت بین «اصلاح واقعی» و «دستکاری بینتیجه» همین ثبت دقیق است.
اشتباهاتی که Page Experience را خراب میکنند
در عیبیابی سایتها، چند خطای تکراری زیاد دیده میشود. اول، تصویر قهرمان یا Hero با حجم بالا و بدون اولویت بارگذاری است. این تصویر معمولاً همان چیزی است که LCP را میسازد. اگر ۸۰۰ کیلوبایت یا چند مگابایت باشد، حتی بهترین متن دنیا هم دیر به چشم کاربر میرسد.
دوم، نصب بیحساب پلاگینها و اسکریپتهای ثالث است: چت آنلاین، ابزار ضبط رفتار کاربر، پاپآپ، اسلایدر، چند سرویس آنالیتیکس، ویجت شبکه اجتماعی و کدهای تبلیغاتی. هرکدام شاید به تنهایی قابل دفاع باشند، اما مجموع آنها INP را نابود میکند. صفحهای که برای واکنش به یک کلیک ساده باید چندین فایل JavaScript را پردازش کند، حس کندی و بیاعتمادی ایجاد میکند.
سوم، طراحی ریسپانسیو فقط در ظاهر است. یعنی صفحه روی موبایل کوچک میشود، اما واقعاً برای موبایل ساخته نشده. دکمهها نزدیکاند، جدولها اسکرول بد دارند، فونتها دیر میآیند و عناصر مهم بالای صفحه زیر هدر چسبان پنهان میشوند.
چهارم، جابهجایی ناگهانی محتواست. کاربر میخواهد روی «ثبت درخواست» بزند، اما درست همان لحظه بنر تخفیف یا تصویر دیرلودشده وارد صفحه میشود و کلیک اشتباه ثبت میشود. این دقیقاً همان تجربهای است که CLS میخواهد اندازه بگیرد.
پنجم، تمرکز افراطی روی نمره ۱۰۰ است. هدف کسبوکار شما گرفتن قاب افتخار از ابزار تست نیست؛ هدف این است که صفحه در شرایط واقعی سریع، پایدار و قابل استفاده باشد. گاهی رساندن نمره از ۸۹ به ۱۰۰ هزینه زیادی دارد ولی اثر تجاری ناچیز است. برعکس، کم کردن یک ثانیه از نمایش محتوای اصلی در صفحه پولساز میتواند اثر مستقیم روی لید و فروش بگذارد.
یک نمونه فنی کوچک برای بهبود LCP
اگر تصویر اصلی بالای صفحه عامل LCP باشد، یکی از اصلاحات ساده این است که آن تصویر را کوچک، فشرده، با ابعاد مشخص و با اولویت درست بارگذاری کنید. این نمونه فقط یک الگوی کوتاه است؛ قبل از اجرا باید مسیر فایل، اندازه واقعی تصویر و ساختار قالب سایت بررسی شود.
<link rel='preload' as='image' href='/assets/images/service-hero.webp' fetchpriority='high'>
<img
src='/assets/images/service-hero.webp'
width='1200'
height='630'
alt='نمای کلی خدمات'
loading='eager'
fetchpriority='high'>چرا این کد مهم است؟ چون به مرورگر میگوید تصویر کلیدی صفحه را زودتر دریافت کند و از طرف دیگر با تعریف width و height، فضای تصویر از ابتدا رزرو میشود. نتیجه احتمالی: بهبود LCP و کاهش ریسک CLS. البته اگر تصویر هنوز سنگین باشد یا سرور کند پاسخ دهد، این کد به تنهایی معجزه نمیکند.
چکلیست اصلاح برای تیم محتوا، طراحی و فنی
Page Experience فقط مسئولیت برنامهنویس نیست. طراح، نویسنده محتوا، مدیر مارکتینگ و تیم فنی هرکدام بخشی از مسئله را میسازند یا حل میکنند.
- برای تیم محتوا: پاراگراف اول را سبک و سریعخوان بنویسید، تصویرهای تزئینی سنگین را حذف کنید، و جدولها را برای موبایل قابل خواندن طراحی کنید.
- برای تیم طراحی: فضای تصاویر، بنرها و کارتها را از ابتدا مشخص کنید. هدر چسبان، پاپآپ و انیمیشنها را با وسواس استفاده کنید، نه از سر عادت.
- برای تیم فنی: منابع CSS و JavaScript مسدودکننده را کاهش دهید، کش مرورگر و سرور را تنظیم کنید، تصاویر را WebP یا AVIF کنید و اسکریپتهای ثالث را به تعویق بیندازید.
- برای مدیر سایت: هر ابزار جدیدی که به سایت اضافه میشود باید دلیل تجاری داشته باشد. اگر یک ویجت فقط «قشنگ» است اما تعامل و سرعت را خراب میکند، هزینه پنهان دارد.
- برای تیم سئو: صفحات را بر اساس ارزش تجاری اولویتبندی کنید. اول صفحههایی را اصلاح کنید که رتبه، ایمپرشن یا نرخ تبدیل مهمتری دارند.
اگر در مرحله انتخاب موضوع و تقویم محتوا هستید، ابزارهایی مثل google trends for seo میتوانند به تشخیص روند تقاضا کمک کنند؛ اما بعد از جذب کاربر، این Page Experience است که بخشی از کیفیت مواجهه او با صفحه را تعیین میکند.
از کجا بفهمیم اصلاحات جواب دادهاند؟
بعد از اعمال تغییرات، انتظار نتیجه لحظهای نداشته باشید. دادههای Core Web Vitals معمولاً بر اساس بازهای از تجربه کاربران واقعی شکل میگیرند و ممکن است چند هفته زمان لازم باشد تا اثر اصلاحات در گزارشها دیده شود. در این فاصله، تستهای آزمایشگاهی را برای کنترل فنی انجام دهید، اما تصمیم نهایی را با ترکیب دادهها بگیرید.
سه شاخص را کنار هم ببینید: تغییر وضعیت Core Web Vitals، رفتار کاربر در ابزارهای تحلیلی و عملکرد صفحه در نتایج جستوجو. اگر LCP بهتر شده اما نرخ تبدیل تغییری نکرده، شاید مشکل در پیام صفحه یا پیشنهاد تجاری باشد. اگر INP بهتر شده و کاربر بیشتر با فرم تعامل میکند، احتمالاً اصلاحات فنی اثر ملموس داشتهاند. اگر CLS کم شده اما رتبه تکان نخورده، شاید رقابت محتوایی یا اعتبار صفحه هنوز مسئله اصلی باشد.
جمعبندی تشخیصی: Page Experience را نه جدا از سئو ببینید، نه جایگزین سئو. این الگوریتم مثل معاینه علائم حیاتی صفحه است؛ به شما میگوید کاربر هنگام ورود، خواندن و تعامل با صفحه چه کیفیتی را تجربه میکند.
پرسشهای رایج درباره Page Experience گوگل
آیا Page Experience به تنهایی باعث رتبه یک گوگل میشود؟
خیر. Page Experience یک بخش از تصویر رتبهبندی است. اگر محتوا با نیت جستوجو هماهنگ نباشد یا صفحه اعتبار کافی نداشته باشد، سرعت و تجربه خوب به تنهایی کافی نیست. اما در رقابت نزدیک، تجربه بهتر میتواند مزیت جدی بسازد.
برای شروع اصلاح، اول LCP مهمتر است یا INP و CLS؟
از داده شروع کنید، نه از حدس. اگر صفحه دیر محتوای اصلی را نشان میدهد، LCP اولویت دارد. اگر کاربر هنگام کلیک و اسکرول مکث حس میکند، INP را بررسی کنید. اگر عناصر صفحه جابهجا میشوند، CLS را جلو بیندازید. در صفحات پولساز، معمولاً LCP و INP زودتر اثر تجاری نشان میدهند.
آیا قالب آماده وردپرس میتواند Page Experience را خراب کند؟
بله، مخصوصاً قالبهایی که چندین اسلایدر، فونت، انیمیشن، صفحهساز سنگین و فایل JavaScript متعدد دارند. مشکل همیشه خود وردپرس نیست؛ ترکیب قالب، افزونهها، هاست، تصاویر و نحوه پیادهسازی است.
هر چند وقت یکبار باید Page Experience را بررسی کنیم؟
برای سایتهای فعال، ماهی یکبار بررسی منظم کافی است؛ اما بعد از تغییر قالب، نصب افزونه، افزودن پاپآپ، تغییر هاست یا انتشار لندینگ مهم، باید همان هفته تست بگیرید. Page Experience چیزی نیست که یکبار اصلاح شود و برای همیشه ثابت بماند.
