Health Check و سلامت وردپرس

Health Check و سلامت وردپرس (WordPress) یکی از موضوعاتی است که تا زمانی که سایت به‌درستی کار می‌کند، کمتر به آن توجه می‌شود؛ اما لحظه‌ای که خطایی رخ می‌دهد یا سرعت افت می‌کند، اهمیت آن چند برابر می‌شود. ابزار Site Health که از وردپرس 5.2 به هسته اضافه شد، یک چارچوب تشخیصی رسمی برای ارزیابی سلامت سایت در چند لایه ارائه می‌دهد: از نسخه PHP و MySQL گرفته تا وضعیت HTTPS، بروزرسانی‌ها، افزونه‌های غیرفعال، زمان پاسخ سرور و مسائل امنیتی. اما این ابزار فقط بخشی از تصویر است. سلامت واقعی یک سایت وردپرسی، ترکیبی از پایش مستمر، درک عمیق از معماری، تفسیر دقیق هشدارها و اقدام هدفمند است. بسیاری از مدیران سایت هشدارهای Site Health را نادیده می‌گیرند یا با اعداد آن بدون درک زمینه برخورد می‌کنند. در این نوشتار، معماری Site Health، معیارهای داخلی آن، تفاوت بین خطا و هشدار، روش‌های پایش عمیق‌تر، ابزارهای تکمیلی، و نکات پیشرفته برای مهندسان ارشد بررسی می‌شود.

در سال‌هایی که با سایت‌های وردپرسی مختلف کار کرده‌ام، یکی از اولین کارهایی که پس از تحویل یک پروژه انجام می‌دهم، بررسی دقیق Site Health است. تجربه نشان داده که این ابزار، اگرچه ساده به نظر می‌رسد، اما در بیش از نیمی از موارد، یک یا چند مشکل پنهان را آشکار می‌کند که بر سرعت، امنیت یا پایداری سایت اثر می‌گذارد. آنچه در ادامه می‌آید، چارچوبی عملی برای استفاده حرفه‌ای از این ابزار است؛ نه فقط مشاهده سطحی هشدارها، بلکه تفسیر دقیق و اقدام هدفمند.

Health Check وردپرس چیست و چه مسئله‌ای را حل می‌کند؟

Health Check (که در هسته وردپرس با نام Site Health شناخته می‌شود) یک ابزار تشخیصی داخلی است که از وردپرس 5.2 (مه ۲۰۱۹) به هسته اضافه شد. هدف این ابزار، ارائه یک تصویر کلی از وضعیت سایت در چند محور کلیدی است:

امنیت: نسخه PHP، HTTPS، بروزرسانی‌ها، کاربران با نام admin، احراز هویت دو مرحله‌ای.
عملکرد: نسخه MySQL، زمان پاسخ سرور، حافظه PHP، افزونه‌های غیرفعال.
سازگاری: سازگاری افزونه‌ها و قالب‌ها با نسخه PHP.
نگهداری: وضعیت جداول دیتابیس، ترنزینت‌های منقضی، بروزرسانی‌های در انتظار.

پیش از معرفی Site Health، مدیران سایت برای بررسی این موارد باید از ابزارهای جانبی، افزونه‌های شخص ثالث و یا بازبینی دستی استفاده می‌کردند. Site Health این فرآیند را یکپارچه، استاندارد و قابل استناد کرد.

مفهوم Health Check در دنیای نرم‌افزار، یک الگوی رایج است که به‌ویژه در معماری‌های Microservices و Kubernetes کاربرد فراوان دارد. در این معماری‌ها، سرویس‌ها دارای endpointهای سلامت (Liveness و Readiness) هستند که توسط Orchestrator بررسی می‌شوند. Site Health وردپرس، یک پیاده‌سازی خاص از همین الگو در سطح یک CMS است. برای مطالعه بیشتر درباره Health Check در معماری نرم‌افزار، می‌توان به منابع عمومی مراجعه کرد.

Site Health یک ابزار تشخیصی است، نه یک ابزار درمانی. این ابزار نشان می‌دهد که چه چیزی درست کار نمی‌کند، اما تصمیم و اقدام نهایی، وظیفه توسعه‌دهنده یا مدیر سایت است.

برای مطالعه بیشتر درباره سایر ابزارهای داخلی وردپرس، مقاله وردپرس چیست و چگونه شروع به کار با آن کنیم؟ را ببینید.

معماری Site Health در هسته وردپرس

Site Health یک زیرسیستم مستقل در هسته وردپرس است که از چند جزء تشکیل شده:

ساختار صفحه Site Health

صفحه Site Health از دو تب اصلی تشکیل شده:

Status (وضعیت): نمایش نتایج تست‌های سلامت در سه دسته (Critical، Recommended، Passed).
Info (اطلاعات): نمایش اطلاعات دقیق درباره سرور، PHP، دیتابیس، فایل‌سیستم، کاربران و غیره.

این صفحه در مسیر /wp-admin/site-health.php قرار دارد و از طریق منوی Tools > Site Health در پیشخوان قابل دسترسی است. کلاس اصلی مدیریت این صفحه، WP_Site_Health است که در فایل wp-admin/includes/class-wp-site-health.php تعریف شده.

class WP_Site_Health {
    private static $instance;
    private $mysql_min_version_check;
    private $mysql_rec_version_check;
    
    public function __construct() {
        add_action('admin_init', array($this, 'maybe_run_cron_check'));
        add_action('wp_ajax_health-check-process', array($this, 'ajax_health_check_process'));
    }
    
    public function get_tests() {
        $tests = array(
            'direct' => array(),
            'async'  => array(),
        );
        // ...
        return $tests;
    }
}

تست‌های همگام و غیرهمگام

Site Health تست‌ها را به دو دسته تقسیم می‌کند:

Direct Tests (تست‌های مستقیم): تست‌هایی که سریع اجرا می‌شوند و نتیجه آن‌ها بلافاصله در دسترس است. مانند بررسی نسخه PHP یا فعال بودن HTTPS.
Async Tests (تست‌های غیرهمگام): تست‌هایی که زمان‌بر هستند و از طریق درخواست AJAX اجرا می‌شوند. مانند بررسی بروزرسانی‌ها یا تست ارتباط با سرورهای وردپرس.

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

REST Endpoint و اجرای تست‌ها

تست‌های غیرهمگام از طریق یک endpoint AJAX اجرا می‌شوند:

add_action('wp_ajax_health-check-process', function() {
    check_ajax_referer('health-check-run-tests');
    
    if (!current_user_can('view_site_health_checks')) {
        wp_send_json_error('unauthorized');
    }
    
    $test = sanitize_text_field($_REQUEST['test'] ?? '');
    $callback = 'detect_' . $test . '_tests';
    
    if (method_exists($site_health, $callback)) {
        $results = call_user_func(array($site_health, $callback));
        wp_send_json_success($results);
    }
});

این معماری، امکان اضافه کردن تست‌های سفارشی را نیز فراهم می‌کند.

معیارهای سلامت در Site Health

Site Health تست‌ها را در سه دسته نمایش می‌دهد که هرکدام معنی و اولویت متفاوتی دارند.

مسائل بحرانی (Critical Issues)

مسائل بحرانی، آن‌هایی هستند که بر امنیت، عملکرد یا پایداری سایت اثر جدی دارند و باید در اسرع وقت رفع شوند. نمونه‌ها:

نسخه PHP قدیمی یا EOL: نسخه‌هایی که به پایان چرخه پشتیبانی رسیده‌اند.
عدم پاسخگویی سرور به درخواست‌های Loopback: معمولاً نشانه مشکل در پیکربندی فایروال یا HTTP.
عدم دسترسی REST API: می‌تواند نشانه مسدودسازی توسط افزونه امنیتی باشد.
خرابی جداول دیتابیس: نشانه‌ای از نیاز به REPAIR TABLE.
عدم پاسخگویی سایت به درخواست‌های HTTP: نشانه مشکل شبکه یا پیکربندی سرور.
خطای Fatal در اجرای Cron: معمولاً نشانه تداخل افزونه یا timeout.

بهبودهای پیشنهادی (Recommended)

این دسته، مواردی هستند که اگرچه سایت را از کار نمی‌اندازند، اما برای عملکرد، امنیت یا نگهداری بهتر توصیه می‌شوند:

افزونه‌های غیرفعال: افزونه‌هایی که نصب هستند اما فعال نیستند.
قالب‌های غیرفعال: قالب‌های اضافی که فضای دیسک را اشغال می‌کنند.
بروزرسانی‌های در انتظار: برای هسته، افزونه‌ها یا قالب‌ها.
کاربر با نام کاربری admin: یک نام کاربری که هدف رایج حملات Brute Force است.
عدم فعال بودن HTTPS: اگرچه امروز نادر است، اما هنوز در برخی سایت‌ها دیده می‌شود.
حافظه PHP کم: کمتر از ۱۲۸ مگابایت.
زمان پاسخ سرور بالا: بیش از ۶۰۰ میلی‌ثانیه.
نمایش خطاهای PHP در محیط تولید: تنظیم ناامن WP_DEBUG_DISPLAY.
عدم اجرای SQL Server در حالت Strict: در MySQL 5.7 به بعد توصیه می‌شود.

تست‌های موفق (Passed)

این دسته شامل تست‌هایی است که با موفقیت گذرانده شده‌اند. مشاهده این دسته اگرچه اطمینان‌بخش است، اما نباید به‌عنوان تأیید کامل سلامت سایت تلقی شود. Site Health فقط یک لایه از بررسی است و بسیاری از مسائل (مانند آسیب‌پذیری‌های افزونه، کوئری‌های کند، یا مشکلات دیتابیس) را نمی‌پوشاند.

بررسی نسخه PHP و MySQL

Site Health نسخه PHP و MySQL را در دو سطح بررسی می‌کند:

حداقل نسخه: نسخه‌ای که وردپرس رسماً پشتیبانی می‌کند.
نسخه پیشنهادی: نسخه‌ای که بهترین عملکرد و امنیت را ارائه می‌دهد.

public function get_test_php_version() {
    $response = '' . __('PHP is the programming language used to run WordPress.') . '';
    $result = array(
        'label' => __('Your site is running the latest version of PHP'),
        'status' => 'good',
        'badge' => array('label' => __('Performance'), 'color' => 'blue'),
    );
    
    if (version_compare(PHP_VERSION, RECOMMENDED_PHP_VERSION, '>=')) {
        return $result;
    }
    // ...
}

برای اطلاعات بیشتر درباره نسخه PHP و سازگاری، مقاله PHP Version و سازگاری وردپرس را ببینید.

بررسی HTTPS و گواهی SSL

Site Health چند جنبه از HTTPS را بررسی می‌کند:

فعال بودن HTTPS در سایت.
معتبر بودن گواهی SSL.
عدم وجود محتوای مختلط (Mixed Content).
کارکرد درست ریدایرکت HTTP به HTTPS.

اگر سایتی روی HTTP اجرا شود، Site Health هشدار می‌دهد:

Your site is not using HTTPS.

راه‌حل، نصب گواهی SSL و فعال‌سازی ریدایرکت است. برای مطالعه بیشتر، مقاله SSL چیست و چرا سایت به آن نیاز ضروری دارد؟ و انتقال HTTP به HTTPS با کد htaccess را ببینید.

بروزرسانی‌ها و وضعیت امنیتی

Site Health بروزرسانی‌های در انتظار را در چند سطح بررسی می‌کند:

هسته وردپرس: نسخه جدید یا نسخه امنیتی موجود.
افزونه‌ها: افزونه‌هایی که بروزرسانی جدید دارند.
قالب‌ها: قالب‌هایی که بروزرسانی جدید دارند.
ترجمه‌ها: فایل‌های ترجمه که بروزرسانی دارند.

همچنین Site Health وجود کاربر با نام کاربری admin را به‌عنوان یک هشدار امنیتی نشان می‌دهد:

public function get_test_username_admin() {
    $result = array(
        'label' => __('No users with the username "admin" found.'),
        'status' => 'good',
    );
    
    $user = get_user_by('login', 'admin');
    if ($user) {
        $result['status'] = 'recommended';
        $result['label'] = __('The username "admin" is used by a user.');
    }
    return $result;
}

برای مطالعه بیشتر درباره امنیت، مقاله چگونه امنیت وردپرس را تقویت کنیم؟ را ببینید.

سلامت افزونه‌ها و قالب‌ها

Site Health افزونه‌ها و قالب‌های غیرفعال را به‌عنوان «بهبود پیشنهادی» نشان می‌دهد، زیرا:

فضای دیسک را اشغال می‌کنند.
می‌توانند سطح حمله را افزایش دهند (حتی اگر غیرفعال باشند).
می‌توانند بر بارگذاری پیشخوان اثر بگذارند.
در بروزرسانی‌ها، ممکن است خطا ایجاد کنند.

افزونه‌های غیرفعال نباید به‌عنوان راهکار «کاهش مصرف» در نظر گرفته شوند، بلکه باید به‌طور کامل حذف شوند:

wp plugin delete plugin-name
wp theme delete theme-name

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

بررسی عملکرد و زمان پاسخ

Site Health چند تست عملکردی دارد:

زمان پاسخ سرور: اندازه‌گیری زمان اجرای یک درخواست به سایت.
حافظه PHP: بررسی محدودیت و مصرف حافظه.
حالت SQL Server: بررسی فعال بودن STRICT_TRANS_TABLES.
عملیات HTTP Loopback: تست ارتباط سایت با خودش.
زمان اجرای WP-Cron: بررسی کارکرد Cron.

public function get_test_http_requests() {
    $result = array(
        'label' => __('Your site is reachable over HTTP.'),
        'status' => 'good',
        'badge' => array('label' => __('Performance'), 'color' => 'blue'),
    );
    
    $loopback = $this->can_perform_loopback();
    if (!$loopback->success) {
        $result['status'] = 'critical';
        $result['label'] = __('Your site cannot complete a loopback request.');
    }
    return $result;
}

عدم توانایی در اجرای Loopback Request می‌تواند به‌دلیل فایروال، Basic Auth یا محدودیت‌های سرور باشد. این مشکل به‌ویژه بر بروزرسانی خودکار و WP-Cron اثر می‌گذارد. برای مطالعه بیشتر، مقاله WP-Cron و زمان‌بندی خودکار در وردپرس را ببینید.

Debug Information و کاربردهای آن

تب Info در Site Health، اطلاعات دقیق و ساخت‌یافته‌ای درباره محیط سایت ارائه می‌دهد که در عیب‌یابی و پشتیبانی بسیار مفید است.

محتوای Debug Info

اطلاعات Debug Info در چند دسته سازمان‌دهی شده است:

wp-core: نسخه وردپرس، زبان، URL، ذخیره‌سازی، کاربران، کرون.
wp-active-theme: اطلاعات قالب فعال.
wp-parent-theme: اطلاعات قالب والد (در صورت وجود).
wp-plugins-active: افزونه‌های فعال با نسخه و بروزرسانی.
wp-plugins-inactive: افزونه‌های غیرفعال.
wp-media: اطلاعات تصویر، GD یا Imagick.
wp-server: اطلاعات سرور، PHP، MySQL، زمان پاسخ.
wp-database: اطلاعات دیتابیس، charset، collation.
wp-constants: ثابت‌های وردپرس.
wp-filesystem: مجوزهای فایل و فایل‌سیستم.

استفاده در پشتیبانی

یکی از کاربردهای اصلی Debug Info، استفاده در فرآیند پشتیبانی است. با کلیک روی دکمه «Copy site info to clipboard»، می‌توان اطلاعات را در قالب Markdown کپی کرد و به تیم پشتیبانی ارسال کرد.

ملاحظات حریم خصوصی

Debug Info حاوی اطلاعات حساسی است:

مسیر کامل سرور
نام کاربری دیتابیس (اگرچه رمز عبور نمایش داده نمی‌شود)
نام هاست و آدرس IP
لیست کاربران ادمین
ثابت‌های حساس (اگرچه مقادیر حساس ماسک می‌شوند)

توصیه می‌شود پیش از ارسال Debug Info به هر شخص یا سرویس خارجی، محتوای آن را بررسی و اطلاعات حساس را حذف کنید. برای مطالعه بیشتر درباره امنیت، مقاله چگونه فایل wp-config را امن کنیم بدون شکستن سایت؟ را ببینید.

افزونه Health Check & Troubleshooting

علاوه بر Site Health هسته، یک افزونه رسمی از تیم وردپرس با نام Health Check & Troubleshooting وجود دارد که امکانات بیشتری ارائه می‌دهد.

حالت Troubleshooting

حالت Troubleshooting این امکان را فراهم می‌کند که:

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

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

حالت Safe Mode

حالت Safe Mode مشابه Troubleshooting است، اما ساده‌تر. در این حالت، همه افزونه‌ها غیرفعال می‌شوند و قالب پیش‌فرض فعال می‌شود. اما این تغییرات فقط برای کاربر جاری است.

// فعال‌سازی Safe Mode از طریق URL
/wp-admin/?safe-mode=1

تفاوت افزونه با هسته

افزونه Health Check & Troubleshooting چند قابلیت اضافه بر هسته دارد:

ویژگی	هسته (Site Health)	افزونه Health Check
تست‌های پایه	بله	بله
Debug Info	بله	بله
حالت Troubleshooting	خیر	بله
Safe Mode	خیر	بله
تست‌های سفارشی	محدود	بیشتر
گزارش PDF	خیر	بله

توصیه می‌شود در پروژه‌های حرفه‌ای، افزونه Health Check نصب و در زمان عیب‌یابی فعال شود.

سفارشی‌سازی و افزودن تست‌های سفارشی

Site Health امکان افزودن تست‌های سفارشی را از طریق فیلتر site_status_tests فراهم می‌کند:

add_filter('site_status_tests', function($tests) {
    $tests['direct']['my_custom_license_check'] = array(
        'label' => __('بررسی اعتبار لایسنس'),
        'test' => 'my_license_status_check',
        'skip_cron' => true,
    );
    return $tests;
});

function my_license_status_check() {
    $license_key = get_option('my_license_key');
    $valid = validate_license($license_key);
    
    if ($valid) {
        return array(
            'label' => __('لایسنس معتبر است'),
            'status' => 'good',
            'badge' => array('label' => __('امنیت'), 'color' => 'green'),
        );
    }
    
    return array(
        'label' => __('لایسنس نامعتبر یا منقضی شده است'),
        'status' => 'recommended',
        'badge' => array('label' => __('امنیت'), 'color' => 'orange'),
        'actions' => sprintf(
            '%s',
            admin_url('admin.php?page=my-license'),
            __('تمدید لایسنس')
        ),
    );
}

این رویکرد، برای پروژه‌هایی که نیازمند بررسی اختصاصی (مانند لایسنس، API خارجی، یا سازگاری با سیستم‌های داخلی) هستند، مفید است.

پایش فراتر از Site Health

Site Health یک ابزار پایه است، اما برای پروژه‌های جدی، پایش کامل‌تری نیاز است.

پایش Uptime

Site Health فقط در لحظه اجرا وضعیت را بررسی می‌کند. برای پایش مستمر، ابزارهای Uptime Monitoring ضروری هستند:

UptimeRobot: پایش رایگان با فواصل ۵ دقیقه.
Pingdom: پایش حرفه‌ای با تحلیل عمیق.
Better Uptime: پایش با هشداردهی چندکاناله.
StatusCake: پایش جامع با پلن‌های مقرون‌به‌صرفه.

این ابزارها در صورت قطع سایت، از طریق ایمیل، SMS یا Slack هشدار می‌دهند.

ابزارهای APM

برای پایش دقیق عملکرد در سطح کد، از APM (Application Performance Monitoring) استفاده کنید:

New Relic: پایش جامع با قابلیت ردیابی تراکنش‌ها.
Tideways: تخصصی برای PHP، با تمرکز بر profiling.
Blackfire: پروفایلینگ عمیق برای محیط‌های توسعه.
Sentry: پایش خطا و عملکرد با تمرکز بر کد.

برای مطالعه بیشتر، مقاله Sentry Performance برای وردپرس چطور کار می‌کند؟ را ببینید.

تحلیل لاگ

لاگ‌های سرور، PHP و MySQL منبع ارزشمندی برای شناسایی مشکلات هستند:

# خطاهای PHP
tail -100 /var/log/php/error.log

# خطاهای وب سرور
tail -100 /var/log/nginx/error.log

# خطاهای MySQL
tail -100 /var/log/mysql/error.log

# کوئری‌های کند
tail -100 /var/log/mysql/slow-query.log

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

اشتباهات رایج در استفاده از Site Health

در پروژه‌های متعدد، اشتباهات تکراری در استفاده از Site Health دیده می‌شود:

نادیده گرفتن هشدارها: فرض اینکه اگر سایت کار می‌کند، همه چیز خوب است.
عمل بدون درک زمینه: تغییرات کورکورانه بر اساس هشدارها بدون فهم ریشه.
عدم بررسی دوره‌ای: Site Health فقط یک‌بار بررسی می‌شود و سپس فراموش می‌شود.
نادیده گرفتن Debug Info: عدم استفاده از اطلاعات دقیق برای عیب‌یابی.
اشتراک‌گذاری Debug Info بدون بررسی: ارسال اطلاعات حساس به افراد یا سرویس‌های خارجی.
عدم سفارشی‌سازی تست‌ها: استفاده صرف از تست‌های پیش‌فرض، در حالی که پروژه نیازهای خاصی دارد.
فرض امنیت کامل: تصور اینکه تست‌های Site Health کافی است، در حالی که بسیاری از تهدیدات را نمی‌پوشاند.
عدم اقدام پس از هشدار: شناسایی مشکل بدون رفع آن.
مقایسه ساده با سایت‌های دیگر: فرض اینکه اگر سایت دیگری وضعیت مشابه دارد، پس مشکلی نیست.
نصب افزونه Health Check بدون نیاز: در برخی موارد، هسته کافی است و افزونه اضافی می‌تواند منبع نویز باشد.
عدم تفسیر زمان پاسخ: زمان پاسخ می‌تواند تحت تأثیر شرایط شبکه یا بار سرور باشد.
اشتباه گرفتن «بهبود پیشنهادی» با «مشکل بحرانی»: عدم تفکیک اولویت‌ها.
نادیده گرفتن محدودیت‌ها: Site Health برخی موارد را نمی‌پوشاند (مانند کوئری‌های کند، آسیب‌پذیری افزونه‌ها، مشکلات CDN).
عدم مستندسازی: ثبت نکردن وضعیت و تغییرات در طول زمان.
واکنش افراطی: تغییر همه‌چیز پس از یک هشدار کوچک.

پرسش‌های پرتکرار درباره Health Check وردپرس

در این بخش، به پرسش‌های متداول پاسخ داده می‌شود. این ساختار برای بهینه‌سازی محتوا برای موتورهای پاسخگو (Answer Engines) نیز مفید است.

Site Health در وردپرس چیست؟

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

چگونه به Site Health دسترسی داشته باشم؟

از پیشخوان وردپرس: منوی Tools > Site Health. یا از مسیر مستقیم /wp-admin/site-health.php.

تفاوت Site Health هسته و افزونه Health Check چیست؟

هسته Site Health تست‌های پایه و Debug Info را ارائه می‌دهد. افزونه Health Check & Troubleshooting امکانات اضافی مانند حالت Troubleshooting، Safe Mode و تست‌های بیشتر را اضافه می‌کند.

آیا هشدارهای Site Health اجباری هستند؟

خیر. «مسائل بحرانی» باید رفع شوند، اما «بهبودهای پیشنهادی» اختیاری هستند. توصیه می‌شود پیشنهادها نیز بررسی شوند، اما تصمیم نهایی بر اساس شرایط سایت و منابع موجود است.

چرا Site Health هشدار HTTPS می‌دهد؟

این هشدار زمانی نمایش داده می‌شود که سایت روی HTTP اجرا شود یا گواهی SSL معتبر نباشد. HTTPS برای امنیت و سئو ضروری است. برای مطالعه بیشتر، مقاله SSL چیست و چرا سایت به آن نیاز ضروری دارد؟ را ببینید.

چگونه Debug Info را کپی کنم؟

در تب Info صفحه Site Health، روی دکمه «Copy site info to clipboard» کلیک کنید. اطلاعات در قالب Markdown کپی می‌شود.

آیا اشتراک‌گذاری Debug Info امن است؟

Debug Info حاوی اطلاعات حساس مانند مسیر سرور، نام کاربری دیتابیس و لیست کاربران است. پیش از اشتراک، محتوا را بررسی و اطلاعات حساس را حذف کنید.

آیا Site Health جایگزین ابزارهای پایش است؟

خیر. Site Health یک ابزار بررسی نقطه‌ای است، نه پایش مستمر. برای پایش مداوم، ابزارهای Uptime Monitoring و APM ضروری هستند.

چگونه تست سفارشی به Site Health اضافه کنم؟

با فیلتر site_status_tests و افزودن یک callback سفارشی. این رویکرد برای بررسی‌های اختصاصی (مانند اعتبار لایسنس، API خارجی) مفید است.

آیا Site Health می‌تواند کوئری‌های کند را شناسایی کند؟

خیر، Site Health کوئری‌های کند را شناسایی نمی‌کند. برای این کار از ابزارهایی مانند Query Monitor یا MySQL Slow Query Log استفاده کنید.

آیا Site Health بر سرعت سایت اثر می‌گذارد؟

خیر، Site Health فقط در زمان اجرای تست‌ها منابع مصرف می‌کند. در حالت عادی، تأثیری بر سرعت ندارد. اما تست‌های غیرهمگام می‌توانند در پس‌زمینه منابع مصرف کنند.

چرا Site Health زمان پاسخ سرور را بالا نشان می‌دهد؟

زمان پاسخ تحت تأثیر عوامل متعدد است: بار سرور، شبکه، افزونه‌های سنگین، دیتابیس، و حتی تست‌های خود Site Health. اگر عدد به‌طور مداوم بالا باشد، باید ریشه‌یابی شود.

آیا می‌توانم تست‌های Site Health را غیرفعال کنم؟

بله، با فیلتر site_status_tests می‌توانید تست‌های ناخواسته را حذف کنید. اما توصیه می‌شود این کار با دقت انجام شود و تست‌های حیاتی حفظ شوند.

آیا Site Health آسیب‌پذیری افزونه‌ها را شناسایی می‌کند؟

خیر، Site Health فقط نسخه افزونه‌ها را بررسی می‌کند و بروزرسانی در انتظار را نشان می‌دهد. برای شناسایی آسیب‌پذیری‌های خاص، از ابزارهایی مانند WPScan، Patchstack یا Wordfence استفاده کنید.

آیا Site Health در Multisite کار می‌کند؟

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

چگونه از Site Health در CI/CD استفاده کنم؟

می‌توانید با WP-CLI یا اسکریپت‌های سفارشی، تست‌های Site Health را در pipeline CI اجرا کنید. برای مطالعه بیشتر، مقاله CI/CD برای پروژه‌های وردپرسی را ببینید.

نکات پیشرفته برای مهندسان ارشد

برای مهندسان ارشد و تیم‌های DevOps، Site Health یک نقطه شروع است، نه پایان. در ادامه، به نکات پیشرفته‌ای می‌پردازیم که در پروژه‌های بزرگ حیاتی می‌شوند.

معماری داخلی WP_Site_Health

کلاس WP_Site_Health از چند متد کلیدی استفاده می‌کند:

get_tests(): برگرداندن آرایه‌ای از تست‌های مستقیم و غیرهمگام.
get_test_*(): متدهای تست که با پیشوند get_test_ تعریف می‌شوند.
run_tests(): اجرای همه تست‌ها و برگرداندن نتایج.
get_site_health_info(): برگرداندن اطلاعات Debug Info.
can_perform_loopback(): تست ارتباط سایت با خودش.

درک این معماری، امکان توسعه تست‌های سفارشی دقیق‌تر را فراهم می‌کند.

اضافه کردن تست‌های غیرهمگام سفارشی

add_filter('site_status_tests', function($tests) {
    $tests['async']['my_api_connectivity'] = array(
        'label' => __('اتصال به API خارجی'),
        'test' => 'test_external_api_connectivity',
    );
    return $tests;
});

function test_external_api_connectivity() {
    $response = wp_remote_get('https://api.example.com/health', array(
        'timeout' => 10,
    ));
    
    if (is_wp_error($response)) {
        return array(
            'label' => __('اتصال به API خارجی برقرار نشد'),
            'status' => 'critical',
            'badge' => array('label' => __('عملکرد'), 'color' => 'red'),
            'description' => sprintf(
                '%s',
                esc_html($response->get_error_message())
            ),
        );
    }
    
    return array(
        'label' => __('اتصال به API خارجی برقرار است'),
        'status' => 'good',
    );
}

پایش سلامت با Prometheus و Grafana

در محیط‌های تولیدی، می‌توان معیارهای سلامت را به Prometheus export کرد:

add_action('rest_api_init', function() {
    register_rest_route('my-metrics/v1', '/health', array(
        'methods' => 'GET',
        'callback' => function() {
            $site_health = WP_Site_Health::get_instance();
            $tests = $site_health->get_tests();
            
            $metrics = array();
            
            // تست‌های مستقیم
            foreach ($tests['direct'] as $test) {
                $result = call_user_func($test['test']);
                $metrics[] = sprintf(
                    'wp_health_test{name="%s",status="%s"} 1',
                    $test['label'],
                    $result['status']
                );
            }
            
            return new WP_REST_Response($metrics, 200);
        },
        'permission_callback' => function() {
            return current_user_can('manage_options');
        },
    ));
});

این endpoint می‌تواند توسط Prometheus scrape شود و در داشبورد Grafana نمایش داده شود. برای مطالعه بیشتر، مقاله مانیتورینگ سرور دقیقاً چگونه انجام می‌شود؟ را ببینید.

پایش با Healthchecks.io

سرویس Healthchecks.io امکان پایش ساده و کارآمد را فراهم می‌کند:

add_action('my_daily_health_check', function() {
    $site_health = WP_Site_Health::get_instance();
    $critical_issues = 0;
    
    foreach ($site_health->get_tests()['direct'] as $test) {
        $result = call_user_func($test['test']);
        if ($result['status'] === 'critical') {
            $critical_issues++;
        }
    }
    
    $url = 'https://hc-ping.com/' . get_option('healthchecks_uuid');
    wp_remote_get(add_query_arg('issues', $critical_issues, $url));
});

if (!wp_next_scheduled('my_daily_health_check')) {
    wp_schedule_event(time(), 'daily', 'my_daily_health_check');
}

پایش امنیتی با WPScan

WPScan یک ابزار تخصصی برای شناسایی آسیب‌پذیری‌های وردپرس است که می‌تواند به‌صورت خودکار اجرا شود:

# نصب WPScan
gem install wpscan

# اجرای اسکن
wpscan --url https://example.com --api-token YOUR_TOKEN --format json --output scan.json

# تحلیل نتایج
jq '.vulnerabilities' scan.json

این ابزار را می‌توان در یک Cron سرور قرار داد تا هفتگی اجرا شود و نتایج آن به تیم امنیتی ارسال شود.

پایش عملکرد با ابزارهای Native PHP

در پروژه‌های حرفه‌ای، می‌توان از توابع Native PHP برای پایش دقیق‌تر استفاده کرد:

add_action('shutdown', function() {
    $metrics = array(
        'execution_time' => microtime(true) - $_SERVER['REQUEST_TIME_FLOAT'],
        'memory_peak' => memory_get_peak_usage(true),
        'memory_limit' => ini_get('memory_limit'),
        'included_files' => count(get_included_files()),
        'db_queries' => get_num_queries(),
    );
    
    if ($metrics['execution_time'] > 2 || $metrics['memory_peak'] > 200 * 1024 * 1024) {
        error_log('Slow request: ' . json_encode($metrics));
    }
});

این کد، درخواست‌های کند یا پرمصرف را در error log ثبت می‌کند.

مقایسه Site Health با ابزارهای تخصصی

ابزار	تمرکز	محدودیت	مناسب برای
Site Health	بررسی نقطه‌ای	عدم پایش مستمر	همه سایت‌ها
UptimeRobot	پایش Uptime	عدم بررسی عمیق	همه سایت‌ها
New Relic	APM	هزینه بالا	سایت‌های بزرگ
Sentry	پایش خطا	تمرکز بر کد	تیم‌های توسعه
Wordfence	امنیت	تمرکز بر امنیت	همه سایت‌ها
Query Monitor	دیباگ کوئری	فقط در محیط توسعه	توسعه‌دهندگان

هر ابزار، بخشی از تصویر را نشان می‌دهد. برای دیدن تصویر کامل، ترکیب چند ابزار ضروری است.

نکات کلیدی برای پایداری بلندمدت

در پایان، چند نکته کلیدی که باید در خاطر بماند:

Site Health را دوره‌ای بررسی کنید: هفتگی یا ماهانه، نه فقط در بحران.
هشدارها را درک کنید: پیش از اقدام، ریشه و تأثیر را تحلیل کنید.
Debug Info را در پشتیبانی استفاده کنید: با حذف اطلاعات حساس.
تست‌های سفارشی اضافه کنید: برای بررسی‌های اختصاصی پروژه.
پایش Uptime داشته باشید: Site Health کافی نیست.
APM را در سایت‌های جدی راه‌اندازی کنید: برای پایش عملکرد در سطح کد.
لاگ‌ها را تحلیل کنید: منبع ارزشمندی از اطلاعات.
افزونه Health Check را نصب کنید: برای قابلیت Troubleshooting.
پایش امنیتی جداگانه داشته باشید: با WPScan یا Patchstack.
معیارهای سفارشی export کنید: برای Prometheus یا Grafana.
مستندسازی کنید: وضعیت و تغییرات را ثبت کنید.
آموزش تیم: همه اعضا با Site Health و محدودیت‌های آن آشنا باشند.

اگر در پروژه‌های خود از Site Health استفاده کرده‌اید و تجربه‌ای در شناسایی مشکلات پنهان داشته‌اید، جالب است بدانم کدام تست بیشترین ارزش را برای شما داشته است. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل خلاقانه‌ای برای سفارشی‌سازی یا تکمیل تست‌های Site Health پیدا کرده‌اید که می‌تواند برای دیگران مفید باشد.