عیب‌یابی سایت یعنی پیدا کردن و رفع مشکلاتی که باعث می‌شوند وب‌سایت در دسترس نباشد، کند باز شود، در گوگل دیده نشود یا کاربر نتواند کارش را کامل کند. یک عیب‌یابی درست از چهار لایه می‌گذرد: دسترس‌پذیری و سرور، سرعت، سئو و ایندکس و خطاهای سمت کاربر. لایه آخر از همه پنهان‌تر است؛ کاربر روی دکمه‌ای کلیک می‌کند، اتفاقی نمی‌افتد، صفحه را می‌بندد و هیچ گزارشی به تیم فنی نمی‌رسد. در این راهنما هر چهار لایه را گام‌به‌گام مرور می‌کنیم.
مهم‌ترین مشکلاتی که در عیب‌یابی سایت بررسی می‌شوند
| مشکل | نشانه | ابزار بررسی |
|---|---|---|
| قطعی یا خطای سرور (5xx) | سایت گاهی باز نمی‌شود یا خطای ۵۰۰ می‌دهد | پایش در دسترس بودن (Uptime) و لاگ خطای هاست |
| صفحه‌های ۴۰۴ و لینک شکسته | کاربر یا گوگل به صفحه‌ای می‌رسد که وجود ندارد | گزارش Pages در Google Search Console و ابزار بررسی لینک |
| کندی سایت | بارگذاری طولانی، پرش محتوا هنگام باز شدن صفحه | PageSpeed Insights و تب Performance مرورگر |
| ایندکس نشدن صفحه‌ها | صفحه در نتایج گوگل نیست | URL Inspection و گزارش Pages در Search Console |
| خطای جاوااسکریپت | دکمه یا فرم کار نمی‌کند، فقط در بعضی مرورگرها | Console مرورگر و سامانه رصد خطا |
| درخواست شبکه ناموفق | فرم ارسال نمی‌شود، داده بارگذاری نمی‌شود | تب Network مرورگر و سامانه رصد خطا |
| مشکل گواهی SSL یا ریدایرکت | هشدار «ناامن» یا حلقه ریدایرکت | باز کردن نسخه‌های http و www سایت و بررسی کد پاسخ |
عیب‌یابی سایت گام‌به‌گام
- در دسترس بودن: نسخه‌های http، https، با www و بدون www را باز کنید؛ همه باید با یک ریدایرکت ۳۰۱ به نشانی اصلی برسند و گواهی SSL معتبر باشد.
- خطاهای سرور: لاگ خطای هاست را برای خطاهای ۵۰۰ و ۵۰۳ بررسی کنید و ببینید در چه ساعت‌ها و روی چه صفحه‌هایی تکرار می‌شوند.
- ایندکس و ۴۰۴: در Google Search Console گزارش Pages را ببینید؛ صفحه‌های مهمی که ایندکس نشده‌اند، خطاهای ۴۰۴ و صفحه‌های بی‌ارزشی که بودجه خزش را هدر می‌دهند (مثل صدها صفحه برچسب) را جدا کنید.
- سرعت: صفحه اصلی و صفحه‌های پربازدید را در PageSpeed Insights بسنجید. شاخص‌های Core Web Vitals در وضعیت خوب این‌ها هستند: LCP حداکثر ۲.۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰.۱.
- Console و Network مرورگر: با کلید F12 ابزار توسعه‌دهنده را باز کنید؛ پیام‌های قرمز Console خطاهای جاوااسکریپت و ردیف‌های قرمز Network درخواست‌های ناموفق هستند.
- مسیرهای حیاتی: فرم تماس، ثبت‌نام، ورود، جستجو و سبد خرید را روی موبایل و دسکتاپ و در چند مرورگر واقعاً تا انتها انجام دهید.
- پایش دائمی: عیب‌یابی یک‌باره کافی نیست؛ با انتشار هر نسخه جدید خطای تازه پیدا می‌شود. برای همین رصد خودکار خطا لازم است.
ابزارهای رایگان برای عیب‌یابی و آنالیز سایت
- Google Search Console: وضعیت ایندکس، خطاهای خزش، ۴۰۴ها و نقشه سایت.
- PageSpeed Insights: سرعت و Core Web Vitals با داده واقعی کاربران و پیشنهاد بهبود.
- ابزار توسعه‌دهنده مرورگر (DevTools): خطاهای Console، درخواست‌های Network و شبیه‌سازی موبایل.
- لاگ خطای هاست یا سرور: خطاهای PHP، پایگاه داده و ۵xx.
- سامانه رصد خطا: خطاهایی که در مرورگر کاربران واقعی رخ می‌دهد و هیچ‌کدام از ابزارهای بالا نمی‌بینند.
اگر سایت شما وردپرسی است و روی ایندکس شدن مشکل دارد، معمولاً اولین قدم حذف صفحه‌های کم‌ارزش (برچسب‌ها، آرشیو نویسنده، فیدها) از ایندکس و کوچک کردن نقشه سایت است تا گوگل وقتش را صرف صفحه‌های اصلی کند.
چرا لاگ سرور کافی نیست؟
لاگ سرور فقط درخواست‌هایی را می‌بیند که به سرور رسیده‌اند. اما بخش بزرگی از مشکلات امروز در سمت مرورگر رخ می‌دهد:
- خطاهای جاوااسکریپت که یک فرم یا دکمه را از کار می‌اندازند
- درخواست‌های شبکه‌ای که در مرورگر شکست می‌خورند یا بیش از حد طول می‌کشند
- ناسازگاری با یک مرورگر یا دستگاه خاص
- خطاهایی که فقط برای کاربران با داده یا نقش خاص رخ می‌دهند
در سامانه‌های سازمانی که کاربرانش کارمندان هستند، وضع بدتر است: کاربر معمولاً به‌جای گزارش، با راه‌حل موقت کار را جلو می‌برد و مشکل ماه‌ها باقی می‌ماند.
یک سامانه رصد خطا چه چیزهایی ثبت می‌کند؟
- پیام خطا و Stack Trace: دقیقاً کدام خط کد و در چه مسیری خطا داده است.
- مسیر کاربر پیش از خطا (Breadcrumbs): کاربر قبل از خطا چه صفحه‌هایی را دیده و روی چه چیزهایی کلیک کرده است.
- مرورگر، سیستم‌عامل و نسخه برنامه: برای بازتولید خطا.
- درخواست‌های شبکه ناموفق: آدرس، کد وضعیت و زمان پاسخ.
- گروه‌بندی خطاهای مشابه: تا به‌جای هزار گزارش تکراری، یک مشکل با تعداد تکرار دیده شود.
بازخورد کاربر؛ نیمه دیگر ماجرا
همه مشکلات خطای فنی نیستند؛ گاهی کاربر فقط نمی‌فهمد چه کند یا چیزی را اشتباه می‌بیند. دکمه بازخورد درون‌برنامه‌ای که همراه با اسکرین‌شات و اطلاعات فنی صفحه ارسال شود، این گزارش‌ها را هم به همان صندوق خطاها می‌آورد و رفت و برگشت ایمیلی «دقیقاً کجا؟ چه مرورگری؟» را حذف می‌کند.
چه زمانی به رصد خطا نیاز دارید؟
- وقتی سامانه شما کاربران زیاد یا پراکنده دارد و نمی‌توانید با همه در تماس باشید.
- وقتی نسخه جدید منتشر می‌کنید و می‌خواهید خطاهای جدید را همان روز ببینید.
- وقتی تیم پشتیبانی زمان زیادی صرف جمع کردن اطلاعات گزارش‌ها می‌کند.
- وقتی فروشگاه آنلاین دارید و هر خطا در سبد خرید مستقیماً فروش را کم می‌کند.
BugMug؛ رصد خطا و بازخورد کاربر، ساخت ژابیز پردا
ژابیز پردا برای همین نیاز، سرویس ایرانی BugMug؛ سرویس رصد خطا و بازخورد کاربران را ساخته است. با افزودن یک خط کد به سایت، خطاهای جاوااسکریپت و شبکه به‌صورت خودکار ثبت می‌شوند، کاربران با یک کلیک باگ یا پیشنهاد را همراه اسکرین‌شات می‌فرستند، خطاهای مشابه گروه‌بندی می‌شوند و تیم از طریق ایمیل، اسلک یا وب‌هوک مطلع می‌شود. BugMug مستقل از فریم‌ورک است و پلن رایگان هم دارد.
ما همین رویکرد را در سامانه‌های سازمانی خود، مثل نرم‌افزار ممیزی HSE، به کار می‌بریم تا مشکلات کاربران پیش از آنکه به تماس پشتیبانی برسد دیده شود.
پرسش‌های متداول
آیا رصد خطا سرعت سایت را کم می‌کند؟
اسکریپت‌های رصد خطا معمولاً سبک هستند و به‌صورت غیرهمزمان بارگذاری می‌شوند، بنابراین تأثیر محسوسی بر سرعت بارگذاری صفحه ندارند.
اطلاعات حساس کاربران چه می‌شود؟
سرویس رصد خطا باید امکان ماسک کردن فیلدهای حساس، مثل رمز عبور و شماره کارت، را داشته باشد تا این اطلاعات هرگز ارسال نشوند. BugMug این امکان را دارد.
آنالیز سایت با عیب‌یابی سایت چه فرقی دارد؟
آنالیز سایت معمولاً یعنی بررسی کلی وضعیت سئو، سرعت و محتوا و پیدا کردن فرصت‌های بهبود. عیب‌یابی سایت روی پیدا کردن علت یک مشکل مشخص، مثل خطا، قطعی، کندی یا ایندکس نشدن، و رفع آن تمرکز دارد. در عمل این دو کنار هم انجام می‌شوند.