راهنمای کامل ارزیابی سلامت سایت

سلامت سایت دقیقاً یعنی چه؟

«سلامت سایت» یک نمره جادویی نیست. سایتی سالم است که کاربر بتواند بدون اصطکاک از آن استفاده کند، موتور جست‌وجو بتواند صفحه‌های درست را پیدا و تفسیر کند، زیرساخت نشانه‌های خطر جدی نداشته باشد و تیم بداند کدام مشکل را زودتر حل کند. بنابراین یک راهنمای ارزیابی سلامت سایت باید دست‌کم چهار سؤال را پاسخ دهد:

1. آیا صفحه برای کاربر واقعی سریع، پایدار و پاسخ‌گو است؟
2. آیا ربات جست‌وجو اجازه و امکان Crawl صفحه را دارد؟
3. آیا Title، توضیح متا، H1، Canonical، لینک‌ها و دادهٔ ساختاری پیام منسجمی می‌دهند؟
4. آیا یافته‌ها به ترتیب اثر و هزینهٔ اقدام مرتب شده‌اند؟

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

این نگاه، ارزیابی را از «جمع‌کردن خطا» به یک ابزار تصمیم تبدیل می‌کند.

پیش از ارزیابی: نتیجهٔ واقعی را از نمای نمونه جدا کنید

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

برای اندازه‌گیری واقعی، نتیجه را با این منابع تطبیق دهید:

• PageSpeed Insights یا Chrome DevTools برای داده آزمایشگاهی؛
• گزارش Core Web Vitals سرچ کنسول یا داده CrUX برای تجربه کاربران واقعی؛
• URL Inspection و گزارش Page Indexing برای وضعیت Crawl و Index؛
• پاسخ مستقیم سرور، HTML نهایی، robots.txt و sitemap.xml برای کنترل فنی؛
• لاگ سرور برای دیدن رفتار واقعی crawlerها در پروژه‌های حساس.

داده آزمایشگاهی و داده میدانی یک چیز نیستند. آزمایشگاه برای پیدا کردن Regression و بازتولید مشکل مناسب است؛ داده میدانی نشان می‌دهد کاربران واقعی با دستگاه و شبکه واقعی چه تجربه‌ای داشته‌اند. گوگل Core Web Vitals را با سه معیار LCP، INP و CLS تعریف می‌کند و برای ارزیابی پایدار، صدک ۷۵ بازدیدها را در نظر می‌گیرد. آستانه‌های «خوب» فعلی عبارت‌اند از:

منبع این آستانه‌ها مستند رسمی Web Vitals است. یک اجرای خوب Lighthouse مفید است، اما به‌تنهایی ثابت نمی‌کند صدک ۷۵ کاربران واقعی هم تجربه خوبی دارند.

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

گزارش ارزیابی سلامت سایت را چطور بخوانیم؟

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

۱. دسترسی و وضعیت URL

URL باید برای کاربر و crawler پاسخ مستقیم و قابل انتظار داشته باشد. صفحه‌ای که به چند Redirect وابسته است، خطای ۵xx می‌دهد یا نسخه‌های متعدد بدون مرجع روشن دارد، قبل از هر بهینه‌سازی محتوایی به اصلاح مسیر نیاز دارد. سپس این موارد را کنترل کنید:

• robots.txt دسترسی به منابع و صفحات لازم را نبسته باشد؛
• صفحه indexable دارای noindex ناخواسته نباشد؛
• Canonical مطلق و هماهنگ با URL نهایی باشد؛
• فقط URLهای Canonical و قابل ایندکس داخل Sitemap باشند؛
• لینک‌های داخلی با href واقعی به صفحه برسند.

طبق راهنمای Crawl و Index گوگل، robots.txt ابزار کنترل درخواست crawler است، نه راه مطمئن برای جلوگیری از Index. برای جلوگیری از Index یک صفحه HTML باید از دستور مناسب robots meta استفاده شود و crawler نیز امکان خواندن آن را داشته باشد.

۲. تجربه و Core Web Vitals

به نمره Performance اکتفا نکنید. عنصر LCP را پیدا کنید، تعامل کندی که INP را بالا می‌برد مشخص کنید و منشأ جابه‌جایی CLS را به یک جزء رابط نسبت دهید. برای نمونه:

• اگر تصویر Hero عنصر LCP است، ابعاد واقعی، فرمت، اولویت بارگذاری و Cache آن را بررسی کنید؛
• اگر تعامل منو یا فرم کند است، Long Task و حجم JavaScript مسیر اولیه را پیدا کنید؛
• اگر صفحه جابه‌جا می‌شود، برای تصویر، ویدئو و محتوای async فضا رزرو کنید.

برای پایش پس از انتشار نیز از ابزار پایش Core Web Vitals استفاده کنید تا اصلاح امروز با نسخه بعدی از بین نرود.

۳. سیگنال‌های On-page

Title و H1 باید هدف یکسانی داشته باشند، اما لازم نیست عین هم باشند. توضیح متا وعده صفحه را روشن می‌کند، Canonical نسخه مرجع را معرفی می‌کند و لینک داخلی رابطه این صفحه با کلاستر را نشان می‌دهد. داده ساختاری نیز باید بازتاب محتوای قابل‌مشاهده باشد، نه محلی برای افزودن ادعایی که کاربر روی صفحه نمی‌بیند.

Sitemap فهرست آرزوها نیست. گوگل توصیه می‌کند URLهای کامل و Canonical که واقعاً می‌خواهید در نتایج دیده شوند در آن قرار گیرند. جزئیات در راهنمای رسمی ساخت Sitemap آمده است.

۴. دسترس‌پذیری و امنیت پایه

نبود Alt، نام‌گذاری مبهم کنترل‌ها، Focus نامشخص و کنتراست ناکافی می‌توانند هم استفاده واقعی و هم کیفیت درک صفحه را کم کنند. بررسی خودکار فقط بخشی از مسئله را می‌بیند؛ مسیر صفحه‌کلید و خروجی Screen Reader به آزمون انسانی نیاز دارد. همین قاعده برای امنیت صادق است: وجود HSTS یا CSP سیگنال مفیدی است، اما جایگزین Threat Modeling، بررسی مجوزها یا آزمون نفوذ نیست.

از فهرست خطا به برنامه اقدام برسید

شدت ابزار را مستقیماً به اولویت Sprint تبدیل نکنید. هر یافته را با چهار عامل بسنجید:

1. اثر: چند صفحه و چند کاربر درگیر هستند و آیا مسیر درآمد یا جذب را لمس می‌کند؟
2. اطمینان: شواهد واقعی داریم یا فقط یک هشدار احتمالی است؟
3. فوریت: مشکل مانع Crawl، خرید، ثبت‌نام یا استفاده اصلی شده است؟
4. هزینه اقدام: اصلاح چقدر زمان، هماهنگی و ریسک Regression دارد؟

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

اولویت اقدام = اثر × اطمینان × فوریت، با درنظرگرفتن هزینه اجرا

ابتدا Quick winهای پراثر و کم‌هزینه را ببندید؛ سپس مشکلات ساختاری را به پروژه‌های کوچک و قابل اندازه‌گیری بشکنید. برای هر مورد یک مالک، مهلت، معیار قبل و بعد و روش بازآزمایی ثبت کنید. «بهبود سرعت» Task نیست؛ «کاهش حجم تصویر Hero به زیر بودجه و بازآزمایی LCP موبایل» قابل تحویل است.

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

یک سناریوی نمونه: صفحه‌ای با امتیاز متوسط

سناریوی زیر ساختگی است و فقط روش تصمیم را نشان می‌دهد. فرض کنید نمای گزارش برای یک Landing Page این موارد را نشان می‌دهد:

در این مثال، اصلاح Canonical ممکن است قبل از پروژه سنگین Performance انجام شود، چون شواهد روشن، هزینه پایین و اثر مستقیم بر نسخه مرجع دارد. هم‌زمان کار Performance باید به یک فرضیه فنی قابل اندازه‌گیری تبدیل شود. بعد از هر تغییر، همان URL، همان نوع دستگاه و شرایط قابل مقایسه را دوباره بررسی کنید.

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

چک‌لیست ۳۰ دقیقه‌ای ارزیابی سلامت سایت

پنج دقیقه اول: محدوده

• URL نهایی و هدف تجاری صفحه را ثبت کنید.
• موبایل یا دسکتاپ را براساس داده واقعی انتخاب کنید.
• مشخص کنید بررسی مربوط به یک URL، یک Template یا کل دامنه است.

ده دقیقه بعد: دسترسی و سیگنال

• پاسخ HTTP و Redirectها را کنترل کنید.
• robots.txt، robots meta، Canonical و Sitemap را بررسی کنید.
• یکتایی و تناسب Title، Description و H1 را بسنجید.
• لینک‌های ورودی و خروجی مهم صفحه را باز کنید.

ده دقیقه بعد: تجربه

• LCP، INP و CLS میدانی را در صورت وجود بخوانید.
• داده آزمایشگاهی را برای تشخیص عنصر یا Task مشکل‌ساز استفاده کنید.
• مسیر اصلی را با کیبورد و یک موبایل واقعی مرور کنید.

پنج دقیقه آخر: اقدام

• سه یافته اول را با شواهد و دامنه اثر بنویسید.
• برای هر مورد مالک، مهلت و معیار بازآزمایی تعیین کنید.
• نتیجه را بعد از Deploy دوباره اندازه بگیرید.

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

جمع‌بندی

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

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