Site Health مجموعه‌ای از آزمون‌های وضعیت و اطلاعات محیط است؛ امتیاز آن جای تشخیص فنی یا مانیتورینگ uptime را نمی‌گیرد. یک هشدار Critical می‌تواند قابلیت مهمی مثل REST API یا loopback را مختل کند، اما بعضی توصیه‌ها بسته به معماری شما اثر فوری ندارند. متن کامل، زمان و شرایط آزمون مهم‌تر از رنگ نشانگر است.
پاسخ کوتاه: ابتدا خطاهایی را بررسی کنید که امنیت، backup، cron، به‌روزرسانی یا مسیر تجاری سایت را متوقف کرده‌اند. سپس توصیه‌های performance و نسخه‌ها را با سازگاری پروژه بسنجید. صرفاً برای سبز شدن گزارش، سرویس امنیتی یا کنترل TLS را خاموش نکنید.
Site Health کجاست؟
در مدیریت وردپرس، بخش ابزارها یا وضعیت سلامت سایت شامل Status و Info است. Info نسخه PHP، دیتابیس، ثابت‌ها و اندازه‌ها را نشان می‌دهد و ممکن است مسیر یا داده عملیاتی داشته باشد؛ خروجی کامل را بدون پاک‌سازی عمومی نکنید.
دسته‌های مهم خطا
| دسته | اثر احتمالی | شاهد تکمیلی |
|---|---|---|
| HTTPS | cookie، mixed content، امنیت انتقال | زنجیره redirect و certificate |
| REST API | ویرایشگر و integration | status و response body |
| Loopback | cron و آزمون داخلی | DNS، firewall و PHP log |
| Scheduled events | jobهای عقب‌افتاده | فهرست cron و صف |
| PHP/Database | سازگاری و پشتیبانی | نیازمندی افزونه‌ها و vendor |
REST API و loopback را یکی ندانید
REST API مسیری برای درخواست داده است؛ loopback یعنی سرور بتواند به خود سایت درخواست بزند. هر دو ممکن است با WAF، DNS یا authentication خراب شوند، اما علت و اثرشان متفاوت است. برای خطای API، راهنمای تشخیص REST API را دنبال کنید.
Scheduled event و wp-cron
تاخیر یک event ممکن است از ترافیک کم، cron غیرفعال، lock، job طولانی یا خطای PHP باشد. اجرای دستی همه jobها بدون شناخت اثر می‌تواند ایمیل یا پردازش تکراری بسازد. نام hook، زمان برنامه‌ریزی و آخرین خطا را ثبت کنید.
نسخه قدیمی PHP یا SQL server
هشدار نسخه باید جدی برنامه‌ریزی شود، اما ارتقای مستقیم production بدون staging خطر ناسازگاری دارد. نیازمندی هسته، قالب، افزونه‌ها و extensionها را فهرست کنید، backup قابل restore بگیرید و سپس upgrade را آزمایش کنید.
Recommended improvement یعنی چه؟
این برچسب الزاماً حادثه جاری نیست. persistent object cache برای هر سایت کوچک ضروری نیست و مقدار پیشنهادی cache یا module باید با workload سنجیده شود. اقدام باید بر پایه اثر قابل اندازه‌گیری باشد، نه صرف حذف badge.
چند سناریوی رایج و مسیر بررسی آن‌ها
ویرایشگر کار می‌کند اما Site Health خطای loopback دارد
در این حالت دسترسی مرورگر به REST API احتمالاً سالم است، ولی خود سرور نمی‌تواند به دامنه سایت متصل شود. DNS داخلی، IPv4/IPv6، firewall خروجی، basic authentication و certificate chain را بررسی کنید. تغییر فایل hosts یا خاموش کردن verification بدون شناخت معماری می‌تواند نتیجه گمراه‌کننده ایجاد کند.
رویداد زمان‌بندی‌شده عقب افتاده است
نام hook و فاصله تأخیر را ثبت کنید. در سایت کم‌ترافیک، wp-cron ممکن است دیر تحریک شود؛ در سایت پرترافیک ممکن است job طولانی یا lock مشکل‌ساز باشد. قبل از اجرای دستی، مشخص کنید job چه کاری می‌کند و آیا اجرای دوباره آن سفارش، ایمیل یا صورتحساب تکراری می‌سازد.
PHP extension پیشنهادی نصب نیست
ابتدا ببینید extension برای قابلیت فعال پروژه لازم است یا صرفاً توصیه عمومی. نسخه PHP مربوط به web server ممکن است با CLI متفاوت باشد. نصب package روی سیستم نیز به تنهایی کافی نیست؛ سرویس PHP-FPM باید نسخه و پیکربندی درست را بارگذاری کند و تغییر در staging آزموده شود.
اطلاعات Status را با شواهد دیگر پیوند دهید
Site Health زمان پاسخ، کندی query یا نرخ خطای کاربران را به‌طور کامل مانیتور نمی‌کند. هشدار را با لاگ خطای وردپرس، PHP-FPM، وب‌سرور و مانیتورینگ uptime تطبیق دهید. اگر آزمون فقط گاهی شکست می‌خورد، زمان رخداد، backend پاسخ‌دهنده و میزان load را کنار هم قرار دهید.
برای نمونه، اگر گزارش REST API در ساعت پرترافیک timeout می‌شود ولی شب سالم است، تغییر permalink احتمالاً راه‌حل منطقی نیست. ابتدا duration درخواست، workerهای PHP و queryهای همان بازه را بررسی کنید. برعکس، 404 پایدار روی یک route بعد از تغییر تنظیمات وب‌سرور به rewrite نزدیک‌تر است.
چک‌لیست امن پیش از هر تغییر
- ثبت متن کامل هشدار و زمان آزمون
- تهیه backup قابل بازیابی برای تغییرات پرریسک
- آزمون تغییر نسخه PHP یا افزونه در staging
- تعریف معیار موفقیت؛ مثلاً اجرای cron یا ذخیره نوشته
- داشتن مسیر rollback و تغییر دادن یک عامل در هر مرحله
روش اولویت‌بندی
- آیا هشدار امنیت یا از دست رفتن داده دارد؟
- آیا checkout، login، backup یا update را متوقف می‌کند؟
- آیا در log و رفتار واقعی قابل بازتولید است؟
- تغییر پیشنهادی چه ریسک و rollbackی دارد؟
- آیا نتیجه پس از اصلاح اندازه‌گیری می‌شود؟
اشتباه‌های رایج
- نصب افزونه اضافی برای سبز کردن هر مورد
- افشای خروجی کامل Info
- خاموش کردن WAF یا TLS verification
- ارتقای PHP بدون تست سازگاری
- نادیده گرفتن خطا چون صفحه اصلی باز است
چه زمانی بررسی سلامت کامل لازم است؟
اگر چند هشدار به REST، cron، دیتابیس و PHP مربوط‌اند، احتمال یک علت زیرساختی مشترک وجود دارد. سرویس بررسی سلامت وردپرس برای ارزیابی منظم و اولویت‌بندی اصلاحات قابل استفاده است.
پرسش‌های متداول
آیا ۱۰۰ درصد شدن Site Health هدف درستی است؟
خیر؛ عملکرد و ریسک واقعی مهم‌تر از یک امتیاز عمومی است.
آیا هشدار object cache همیشه یعنی Redis لازم است؟
خیر. الگوی query، hosting و بار سایت باید اندازه‌گیری شود.
چرا آزمون گاهی خطا و گاهی موفق است؟
timeout، load، DNS یا چند backend می‌تواند نتیجه متناوب بسازد؛ timestamp و node را ثبت کنید.